Azure Site Recoveryは災害対策の“切り札”となるか？：Microsoft Azure最新機能フォローアップ（1）（4/5 ページ）

マイクロソフトが「Microsoft Azure Site Recovery」のプレビュー提供を開始した。このサービスは、オンプレミスの仮想マシンのレプリカをMicrosoft Azure上に作成してバックアップする災害対策ソリューションになる。

[山市良，テクニカルライター]

復旧計画を作成する

　初期レプリケーションが完了したら、VMMクラウドの保護の構成で設定した頻度（30秒、5分、15分）で、オンプレミス側の仮想ハードディスクの変更差分がMicrosoft Azure側にレプリケーションされ同期される。

　この状態になったら、Microsoft Azure管理ポータルでVMMクラウドの「復旧計画」を作成できるようになる。復旧計画とは、フェイルオーバー時の復旧ステップを定義するもので、ワンクリックでのフェイルオーバー開始を可能にするものだ（画面17）。

画面17　クラウド・ツー・Azureのフェイルオーバーおよびフェールバックを自動化するための復旧計画を作成する

　復旧計画では、復旧対象とする仮想マシンをグループ化して、グループ単位で仮想マシンの起動順序を指定することも可能だ（画面18）。また、手動アクション（ステップの一時停止）を追加して、フェイルオーバーのステップを一時停止し、続行のために管理者の対話を要求したりできる（画面19）。

画面18　既定のグループ（グループ1）に含める復旧対象の仮想マシンを選択する。複数の仮想マシンがある場合は、復旧計画をカスタマイズして、仮想マシンをグループ化し、グループごとに起動順序を指定できる

画面19　復旧計画を使用してフェイルオーバーをワンクリックで開始し、オンプレミスのVMMクラウドをMicrosoft Azureに切り替える

　オンプレミス・ツー・オンプレミスの拠点間レプリケーションの場合は、グループのステップの前後にスクリプト（VMMライブラリに格納されたPowerShellスクリプト（.ps1））を自動実行するように構成することもできるが、オンプレミス・ツー・Azureの復旧計画ではスクリプトの実行はサポートされていない。なお、復旧計画を作成しなくても、仮想マシンごとのフェイルオーバーは実行できる。

仮想マシン単位の計画的なフェイルオーバーを試す

　今回は、FreeBSD 10 x64の仮想マシンが1台しかないので、復旧計画ではなく仮想マシン単位のフェイルオーバーを実行してみよう。仮想マシンおよび復旧計画のフェイルオーバーには、次の3種類の方法がある。

フェイルオーバー > 計画されたフェイルオーバー

　オンプレミスのVMMクラウドが正常な状態の場合に実行可能。仮想マシンが稼働中の場合はシャットダウンして、レプリケーションを完全に同期させてから、フェイルオーバーを開始する。フェイルオーバーが完了するとレプリケーションが反転する。

フェイルオーバー > 計画されていないフェイルオーバー

　オンプレミスのVMMクラウドの状態に関係なく、最新の復旧ポイントを使用して仮想マシンを起動する。オプションでシャットダウンと最新データの同期を試行させることもできる。

テストフェイルオーバー

　ネットワークに接続せずに、あるいは運用ネットワークとは別のテスト用ネットワークに接続した状態で仮想マシンを起動する。運用中の仮想マシンやレプリケーション保護には影響しない。

　仮想マシン単位のフェイルオーバーを実行するには、Microsoft Azure管理ポータルで保護対象となるクラウドの「仮想マシン」ページを開き、「フェイルオーバー」または「テストフェイルオーバー」をクリックする。今回は、「フェイルオーバー」から「計画されたフェイルオーバー」を実行した（画面20）。なお、復旧計画を使用してフェイルオーバーを実行するには、「復旧計画」ページから復旧計画を選択して「フェイルオーバー」または「テストフェイルオーバー」をクリックすることになる。

画面20　仮想マシンに対して「計画されたフェイルオーバー」を選択すると、「OK」のワンクリックでフェイルオーバーを開始できる。初めてのフェイルオーバーは、必ずオンプレミスからMicrosoft Azureへの方向となる

　フェイルオーバーの進行状況は「ジョブ」ページの「仮想マシン名（計画フェイルオーバー）」で確認できる（画面21）。初めてフェイルオーバーを実行した場合は、「フェイルオーバーの準備中」のステップで、フェイルオーバー先になるMicrosoft Azure仮想マシンにレプリカ仮想マシンが作成されているようだ。最初からフェイルオーバーを実行するのではなく、事前にテストフェイルオーバーを実行しておいてレプリカ仮想マシンの作成を完了しておくと時間を短縮できるかもしれない。

画面21　計画されたフェイルオーバーのジョブステップ。シャットダウン後に最新データが同期され、レプリカ仮想マシンを作成後（作成されていない場合）、レプリカ仮想マシンが起動する

　「計画された」および「計画されていない」フェイルオーバーを実行した場合、フェイルオーバーのジョブが完了すると“コミット待ち”状態になる（画面22）。ここでフェイルオーバーをコミットすることで、フェイルオーバーが完了し、計画されたフェイルオーバーの場合は、レプリケーションのプライマリとレプリカの関係が反転する。つまり、Microsoft Azure仮想マシンのレプリカ仮想マシンがプライマリ仮想マシンとなり、オンプレミスの仮想マシンがレプリカになって、Microsoft Azureからオンプレミスの方向にレプリケーションが開始することになる。

画面22　フェイルオーバーのジョブが完了すると、“コミット待ち”状態になる。コミットしなければ、フェイルオーバーはキャンセルされる

　計画されていないフェイルオーバーの場合は、VMMクラウドが復旧したあと、レプリケーションの反転を手動で実行し、最新データを同期させた後で、今度は計画されたフェイルオーバーを実行してレプリカとプライマリの関係を元に戻すという運用になるだろう。

　ここでフェイルオーバーをコミットした後の状況を確認しておく。Microsoft Azure管理ポータルで保護対象の仮想マシンのプロパティページを参照すると、Microsoft Azureストレージ内の仮想ハードディスクを使用して、事前に選択したインスタンスサイズのMicrosoft Azureに仮想マシンが作成され、クラウドのリソースマッピングでマップしたMicrosoft Azure仮想ネットワークに仮想マシンが接続されている状態を確認できる（画面23）。

画面23　フェイルオーバー実行後の保護対象の仮想マシンのプロパティ

　すでに何度も言及しているが、Azure Site Recoveryはレプリカ仮想マシンをMicrosoft Azure仮想マシンおよびMicrosoft Azure仮想ネットワークのサービスを利用してホストする。Microsoft Azure管理ポータルでMicrosoft Azure仮想マシンのページを開くと、Azure Site Recoveryのフェイルオーバーで作成された仮想マシンが動作していることを確認できる。

　オンプレミスの社内ネットワークとMicrosoft Azure仮想ネットワークがサイト間（S2S）VPN接続されていれば、Microsoft Azure仮想ネットワークで割り当てられたIPアドレス、または動的DNSの名前解決によって、社内ネットワークを同じようにMicrosoft Azure側の仮想マシンと通信できるはずだ。

　今回は、オンプレミスと接続されていないMicrosoft Azure仮想ネットワークに接続したため、そのままでは仮想マシンに接続することができない。そこで、パブリックIPのエンドポイントとしてSSHポート（Windows Server仮想マシンの場合はRDPポートなど）を開き、インターネット経由で仮想マシンのSSH接続してみた（画面24）。エンドポイントを開く機能は、Azure Site Recoveryではなく、完全にMicrosoft Azure仮想マシンのサービスの機能である。

画面24　Microsoft Azure仮想マシンとしてフェイルオーバーされたFreeBSD 10 x64仮想マシンに、Microsoft Azure仮想マシンのエンドポイントの機能を利用してインターネット経由でSSH接続してみた

　もう1点、ここで指摘しておきたいのは、オンプレミスの保護対象の仮想マシンは、容量可変タイプのVHDXで作成された仮想マシンだということである。Microsoft Azure仮想マシンの標準機能として、オンプレミスで準備したイメージをアップロードして展開することもできるが、その場合、現状は容量固定タイプのVHD形式のみがサポートされている（容量可変タイプはアップロード時に容量固定タイプに変換される、VHDX形式は非サポート）。Azure Site RecoveryはMicrosoft Azure仮想マシンを利用してはいるが、オンプレミス側の仮想マシンに関してはMicrosoft Azure仮想マシンの仮想ハードディスクの制約に合わせる必要がないのである。