オンプレミスからAzureへのHyper-V Recovery Managerレプリケーションを実行してみました。
設定手順は以下のサイトに画面付きで詳しく書いてあり、この通り実行してあまり迷うところ無いと思います。設定は難しく無いです。
Azure Site Recovery のデプロイ:オンプレミスと Azure 間の保護
前提条件はこちらです。
http://msdn.microsoft.com/ja-jp/library/dn469078.aspx
なお、第2世代のHyper-V仮想マシンには対応してないので、Azure Site RecoveryでDR対象にしたい仮想マシンは第1世代で作成する必要があります。Hyper-Vの仮想マシンの世代に関しては日立さんがホワイトペーパーで公開してくれています。
上記のリンクの手順に沿って設定を行うと、設定した仮想マシンがAzure上で保護対象の仮想マシンとして表示されます。ここで表示されるのはSCVMM側の仮想マシン名と同じ名前です。
上記の画面は初期レプリケーションの状態です。設定後にオンプレミスからAzureに対して初期レプリケーションが走ります。ディスクのサイズにもよりますが、時間がかかる処理の一つです。手元の環境では10GBのディスクでおおよそ1時間かかりました。
レプリケーションのタイミングなどはHyper-Vレプリカと近い設定が可能です。コピーの頻度は30秒、5分、15分から選択できます。整合性のとれたスナップショットは1時間～12時間の間から頻度を選択可能です。フェールオーバの際には、どのポイントに戻すのかを選択可能です。
ソースシステムであるオンプレミスと、レプリケーション対象になるAzure側の設定はこのような比較画面が用意されています。
Azure側にレプリケート後のサイズですが、設定としては小さいサイズも指定できますが、実際にはLサイズより小さいサイズは以下のエラーが発生し指定できません。
Could not update the Azure VM size. (Error code: 70114) Copy
Possible causes The VM size cannot be less than ExtraLarge.
Recommendation Resolve the issue and retry the operation.
Azure側にフェールオーバーされた時のマシンサイズや、どの仮想ネットワークに紐付くか、どのストレージアカウントにVHDが格納されるかなどが確認できます。フェールオーバー後の環境がわかりやすくなっています。
なお、レプリケーション実行後に対象のストレージアカウントのコンテナの中を見るとHyper-Vレプリカのように乱数のようなオブジェクト名で仮想マシンの同期データが保存されています。
テストフェールオーバー
通常のフェールオーバの部分はこちらに詳しく書いてあります。
Microsoft Azureの最新機能を速攻レビュー！：Azure Site Recoveryは災害対策の“切り札”となるか？ (1/5) - ＠IT
Azure Site RecoveryにはHyper-Vレプリカと同様テストフェールオーバー機能があるので、ここでは、テストフェールオーバーをしてみます。
テストフェールオーバーを選択すると、テストフェールオーバーされた仮想マシンが紐付く仮想ネットワークが選択可能です。仮想ネットワーク接続「なし」も選択できます。他には暗号化に必要なPFXファイルが必要となります。Azure Site Recoveryの設定手順の中でダウンロードしたPFXファイルを使います。(DataEncryptionCertificate_xxxx_xxxx.pfx)
ここで仮想ネットワークを選択するには、正規のフェールオーバー時に紐付く仮想ネットワークと別の仮想ネットワークを作成しておく必要があります。例えば画像のようにフェールオーバーテスト用の仮想ネットワークを作るなどしておいても良いかもしれません。
テストフェールオーバーを実行するジョブが開始されます。テストフェールオーバーが完了した時点でジョブはテスト結果の待機状態になります。それぞれの処理を見てみると仮想マシンの作成にもっとも時間がかかっています。
なお、一つステップが文字化けしてますが、英語で入り直してみたところ「Add to cloud and attach network」のステップのようです。
では、テストフェールオーバの結果を確認してみましょう。テストフェールオーバーでフェールオーバーしてきた仮想マシンが見えるようになっているはずです。「仮想マシン名-test」という名前になるようです。
仮想ネットワーク上に別仮想マシンが存在していたり、VPNで仮想ネットワークにつないでいたりしない場合はRemote Desktopなどテストに必要なエンドポイントを作ってあげて、ログオンなどフェールオーバーができているかのテストをしてみましょう。
テストが完了したら待機中のジョブをテスト完了としてあげます。
テストのメモとテスト環境のクリーンアップする設定してジョブを続行します。
これで後続の処理が走りまして、テストフェールオーバーで作成された仮想マシンなどの環境もクリーンアップされました。
復旧計画
フェールオーバーでDRと一言で言っても、災害発生時に、ただAzure上でデータ同期済みのサーバを起動すればDRが完了するわけではありません。実際には複雑な復旧手順があることが多いと思います。復旧計画という機能は、この複雑なDR手順を自動化する助けになる機能です。
具体的には自分で定義したアクションを設定した順序で実行してくれます。
定義できるアクションには以下のようなものがあります。
- グループ
サーバーをグループに割り当てることで、フェールオーバー時の起動順序を制御します。例えばADなど基盤系のサーバーグループを最初に起動してから、業務系のサーバーグループを起動するなどの制御が可能です。
Azure Automationの機能を利用して自動化スクリプトを流すことが可能です。
http://azure.microsoft.com/ja-jp/documentation/services/automation/
- 手動アクション
あるサーバーグループの起動が終わったところで、マニュアル作業が必要な場合などに利用します。
隔離ネットワークにテストフェールオーバーすることなども可能なので、現行の運用に影響を与えずフェールオーバーのテストができるので、とても便利です。
復旧計画機能なども活用し、定期的なDR訓練などでDRの品質を上げる運用なども可能になりそうです。今後DRを検討する時には是非検討に挙げたい機能だと思います。
