遂に登場!!
Azure上の仮想マシンを別リージョンにフェールオーバーが出来るようになりました!!
これで、西日本~東日本間の冗長化問題が解消されます。
※ASRの詳細はこちらをご覧下さい。
現時点での気になるところ
・Windows 2016に未対応 ←対応しました!!
・Managed Diskに未対応 ←対応しました!!
・ディスクへの変更点が、常時6MB/sec以上の仮想マシン
さっそく、試してみましょ~
今回は、西日本にある仮想マシンを東日本にフェールオーバーしてみます。
※Backup and Site Recovery(OMS)はターゲットリージョンに作成して下さい。
ソース:Azure
ソースの場所:リージョンを選択
Azure 仮想マシンのデプロイメントモデル:リソースマネージャー
ソース リソースグループ:リソースグループを選択
フェールオーバー対象の仮想マシンを選択
※仮想マシンが起動していること。
ターゲットの場所:ターゲット リージョンを選択
リソースグループ、ネットワーク、ストレージ、可用性セット:デフォルトは新規作成
レプリケーションポリシー:作成後も変更可能
“リソースグループ、ネットワーク、ストレージ、可用性セット”で[カスタマイズ]を選択した場合。作成済みのリソースグループ、ネットワーク、ストレージに変更可能。
名前:表示名
復旧ポイントの保持期間:0~72時間。0は最新のみとなる。
アプリ整合性スナップショットの頻度:オフ、1~12時間
[レプリケーションを有効にする]を選択
以上で完了です。
それでは、東日本に作成されたリソースグループを見てみましょう。
仮想ネットワークは、作成したサブネット含め、同じアドレスレンジで作成されています。
ストレージアカウント[tushigamiarchiveasr]
ストレージアカウント[tushigamiarchivecacheasr]
~synsessionlock:保護処理およびリカバリ ポイント作成処理に用いるロック ファイル。Azureでは隠しファイルが作れないので見えるのです。
差分データが保存されている。アプリ整合性の間隔でVHDファイルにマージされる。
対象の仮想マシンには、エージェントがインストールされているのが確認できます。
テストフェールオーバーしてみましょう!
[テストフェールオーバー]を選択 ※元のサーバーには影響ありません。
[復旧ポイントを選択してください]
最新(最低RPO)
最後に処理があった時点(低RTO)
最新のアプリ整合性
カスタム:お好きなRPOを選択
問題がなければ、[テストフェールオーバーのクリーンアップが保留中]と表示されます。この状態は Azure上で仮想マシンの作成が完了した事を意味します。
仮想マシンが作成されているのが確認できます。
ストレージアカウント[tushigamiarchiveasr]
コンテナー名[wahv~]で始まるものが、テストフェールオーバー用コンテナーになります。
テストフェールオーバー実行時にレプリケーションされたデータからコピーし作成されます。VHDファイル名に[copied~]と付きます。
一通り、テストした後は、[テストフェールオーバーのクリーンアップ]を選択し、テストフェールオーバーを終了させて下さい。
フェールオーバーしてみましょう!
[フェールオーバー]を選択
[復旧ポイントを選択してください]
最新(最低RPO)
最後に処理があった時点(低RTO)
最新のアプリ整合性
カスタム:お好きなRPOを選択
以上。10分ほどでフェールオーバーが完了します。
~フェールオーバー後~
復旧ポイントの変更:フェールオーバー後にも、RPOの変更が可能
コミット:現時点でのフェールオーバー(RPO)を確定し、残りのRPOを破棄する。
再保護:再度フェールオーバー対象とする。
※今回の場合、西日本からフェールオーバーし、東日本に移動した。その後、”再保護”を行うと西日本にフェールオーバーさせる事ができる。いわゆる、フェールバック。
レプリケーションの無効化:ASRの保護対象から外す。仮想マシンを削除するわけではない。
最後に
いや~、やはりオンプレASRに比べて格段に簡単ですね。低コスト、スピーディー、簡単にBCP対策を始められるのもパブリッククラウドの魅力ですね!
今のところ、こんな事ができるのは”Microsoft Azure”だけでは無いでしょうか?
国内に東西リージョンがあるAzureの強みだと思います。