日本リージョンで東西間のフェールオーバーを試す!

いいね!!

遂に登場!!
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の強みだと思います。