Azure Site Recovery‎で自然災害に備えてDRを

2019年、台風の猛威によって日本全国に被害が生じました。予測を超えた記録的な豪雨と暴風で、各地方では氾濫した河川などの復旧作業に追われました。自然災害の対策、いわゆるディザスターリカバリー（Disaster Recovery：DR）は、大企業から中小企業まで取り組まなければならない課題です。

Azureには、DRのサービスとして「Azure Site Recovery」がAzureに組み込まれ、「DRaaS（サービスとしてのディザスターリカバリー）」として提供されています。

ここでは、Azure Site Recoveryの概要とメリット、そしてAzureからAzure、オンプレミスからAzure、VMwareからAzureなど、さまざまなパターンにおけるシステムの復旧について解説します。

Azure Site Recoveryの基礎知識とメリット

インターネットとクラウドは現在、いわば電力や水道と同じように社会のライフラインのひとつに位置づけられるでしょう。企業では自然災害や予期しないシステムの停止において、短時間で復旧できるか、ビジネスを持続的に運用できるか、損害を最小限にとどめることができるか、という課題に対する取り組みが重要です。

リカバリーに必要な「アーカイブ」「バックアップ」「レプリケーション」の基礎知識

通常、企業においてITシステムおよびデータ資産の保管と復旧には「アーカイブ」「バックアップ」「レプリケーション」という3つの方法があります。まずこの用語について、それぞれを定義して違いを明らかにします。

アーカイブ

長期的な保管のためにデータをコピーする方法で、アーカイブされたデータは変更できません。主に法令遵守の目的で使われ、メールの場合は改ざんしないことを条件に最大7年間保管します。アーカイブ用のサーバーやストレージなど外部記憶装置が必要です。情報漏えいなどが起きたとき、アーカイブから履歴を遡って調査などを行うときに使われます。

バックアップ

定期的なスケジュールなどによって、ある時点のデータをコピーします。システム障害時にデータを直近の状態に戻すことが目的です。全体と差分だけのバックアップがあり、後者は変更や追加された部分を保存する方法です。記録メディアやディスクにコピーして保存します。ただ、復元のためのリストア時間がかかるデメリットがあります。

レプリケーション

サーバーのデータをリアルタイムで別のサーバーにコピーします。コピー先のサーバーはネットワーク内だけでなく、遠隔地のサーバーを利用することも可能です。障害時にダウンタイムがなく事業を継続できます。ただし、常時コピーを行うためサーバーに負荷がかかるとともに、システム自体に問題があった場合はその問題も同期されます。

Azure Site Recoveryは、上記のうちレプリケーションをメインとしたサービスです。フェイルオーバー（予備のシステムに切り替えること）によって復旧させます。低コストで信頼性の高いDRの実現が可能です

Azure Site Recoveryの具体的なメリットとしては、以下があります。

Azure Portalを用いてデプロイの簡易化と復旧の自動化

Azure Portalを使って、異なるリージョンの仮想マシンにレプリケーションすることが可能です。このときレプリケーション側でも新しい機能が自動的に更新されます。複数の仮想マシンで実行されている多層のアプリケーションを順序付けして、復旧を最小限に抑えられます。

Azureのバックアップは「Azure Backup」によって行われます。Azure Backupでは、オンプレミスのサーバー、仮想マシンに加えて、仮想化ワークロード、SQL Server、SharePointサーバーなどのデータを保護できます。ランサムウェアやヒューマンエラーからもデータを守ることができ、セキュリティ面でも安心です。

社内でDRを計画している段階においては、運用中のマシンやエンドユーザーに影響を与えずにテストできるため、法令遵守も配慮されています。オンプレミスからAzure へ、Azure から別のリージョンに自動的に復旧する機能によって、障害が起きたときにも通常レベルの運用を維持します。

レプリケーション用の物理的サーバーが不要、コスト削減

オンプレミスのサーバーをレプリケーションする場合は、同じ仕様と環境の物理的なサーバーや周辺機器などを用意しなければなりません。しかし、Azureであればオンプレミスによる予備システムの構築と管理が不要です。したがって、デプロイをはじめとして、監視やパッチ処理など維持コストの削減が可能です。また、Azureは従量課金制のため、利用した機能分だけの請求になります。

ISO 27001など産業規制に準拠したリカバリーでダウンタイムを縮小

複数のリージョンでAzure Site Recoveryを利用すると、ISO 27001などに準拠したDRを実現できます。ビジネスに必要なアプリケーションに合わせて、レプリケーションの規模を柔軟に設定することが可能です。

オンプレミスやVMwareから、さまざまなDRが可能

Azure Site Recoveryは、Azureの仮想マシンから仮想マシンへ、オンプレミスからAzureの仮想マシンへ、Hyper-VやVMwareの仮想マシンからAzureの仮想マシン、Azure Stackによるレプリケーションなど、さまざまなバックアップと普及のための対策システムを構築できます。以下に概要をまとめました。

Azureの仮想マシンからAzureの仮想マシンへ

Azureの仮想マシンでリージョン間のレプリケーションを行う場合には、まずネットワーク環境を準備する必要があります。このとき、内部ロードバランサー、パブリックIP、サブネットとNICの両方のネットワークセキュリティグループのリソース構成に対して、Azure Site Recoveryとフェイルオーバーの待機側の仮想マシンが確実に適用されるようにします。さらにネットワークマッピングとIPアドレスを設定します。

Azure ExpressRouteを利用すると、プロバイダーが提供しているプライベート接続を通じて、オンプレミスで構築した社内のネットワークをAzureのクラウドに拡張できます。ただし、ExpressRouteを使用しているときにAzureの仮想マシンをレプリケートならびにフェイルオーバーする場合においては、注意すべきことがあります。

オンプレミスもしくはVMware仮想化環境からAzureの仮想マシンへ

DRのためにオンプレミスの物理的サーバーをAzureにレプリケーションする場合は、事前にDR戦略を立案すること、要件、容量、リソースなどについて十分に検討しておくことが重要です。自然災害などが発生したときには、多数のオンプレミスのマシンやワークロードをAzureでフェイルオーバーできる状態にする必要があります。このとき注意しなければならないのは「フェイルオーバーの上限」です。

Hyper-VからAzureの仮想マシンへ

オンプレミスの仮想化にはVMwareのほかHyper-Vがあります。DR対策のために物理的なオンプレミスのサーバーをHyper-Vの仮想環境にレプリケーションしている場合もあるでしょう。このときオンプレミスのHyper-Vサーバーから直接、Azureにレプリケーションできます。オンプレミスの仮想化環境からクラウドのAzureにフェイルオーバーする場合は、仮想マシン内のネットワークインターフェイスはすべて、同じ仮想ネットワークに接続しなければならないことがポイントです。

Azure StackからAzureの仮想マシンへ

Azure StackはHCI（Hyper Converged Infrastructure）として、サーバー、ストレージ、ネットワークと仮想化ソフトウェアや管理ツールを垂直統合して、いわばオンプレミスでAzureを利用できる製品です。Azure Stackの仮想化環境からもAzureにレプリケーションできます。ただし、物理的サーバーの前提条件などがあります。

まとめ

備えあれば憂いなしといわれますが、DR戦略を立案するとともに、どれぐらいの規模とコストで対策を行うのか、災害を想定した計画が重要です。大企業が運営する大規模のシステムと、中小企業のオンプレミスベースのシステムでは、DRのポリシーもシステム設計も異なったものになります。したがって、企業やシステムの規模や要件に合わせて、最適化されたDRが求められます。

自社のDRに求める要件や復旧計画を明確にしたうえで、システムに関しては信頼できるパートナーにコンサルティングを依頼し、ノウハウを共有しながら最適なDR環境を整えることが「もしもの場合」に効力を発揮します。