遂に登場！！
Azure上の仮想マシンを別リージョンにフェールオーバーが出来るようになりました！！
これで、西日本～東日本間の冗長化問題が解消されます。
※ASRの詳細はこちらをご覧下さい。
現時点での気になるところ
・Windows 2016に未対応 ←対応しました！！
・Managed Diskに未対応 ←対応しました！！
・ディスクへの変更点が、常時６MB/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の強みだと思います。
