リージョン冗長 Azure Site Recovery (ASR) を試す!

ASRが登場した頃は、オンプレミス~Azure、Azure~AzureなどDR構成と言えば、ASR一択でしたが、最近では状況が変わってきております。

・Azureリージョン間のDRには、Azure Site Recovery
・オンプレミスからのDRには、Azure Migrate
・仮想マシンのバックアップには、Azure Backup Center

と、棲み分けされつつあります。
今回はASRと言うことで、Azureリージョン間でのDR構成を試してみたいと思います。

しくみは簡単

①保護対象となる仮想マシンに、Mobility Serviceをインストールする。
②Mobility Serviceを通して、変更点をキャッシュ用Blobへ保存する。
③BlobからReplica DiskへHTTPSにて送信される。
④Replica DiskからManaged Diskを作成する。
⑤Managed Diskから仮想マシンを作成する。

・同一テナント、別サブスクリプションOK
・プライベートエンドポイント対応
・Azure Site Recovery と Azure Backup は同時設定が可能
※ただし、Backupから復元した際には、再度レプリケーション設定が必要

【復旧ポイント】
クラッシュ整合性:ディスクのスナップショットを取得する。メモリは対象外。5分ごとに作成される(変更不可)。
アプリ整合性:ディスク+メモリ+実行中トランザクションのスナップショット(VSS)を取得する。パフォーマンスに影響あり。

【レプリケーションポリシー】
復旧ポイントの保持期間:0~72時間 ※0は最新の復旧ポイントのみ保持します。
アプリ整合性スナップショットの頻度:Off~12時間(1時間単位) ※Offは作成しません。

レプリケーショングループ(マルチVM)
複数のサーバーで同じ[クラッシュ整合性/アプリ整合性]を共有するグループ

ASRに必要なVMからのアウトバウンド通信を許可する必要があります。
※許可が必要なインバウンド通信は無い

【URLの場合】
*.blob.core.windows.net
login.microsoftonline.com
*.hypervrecoverymanager.windowsazure.com
*.servicebus.windows.net
*.vault.azure.net
*.automation.ext.azure.com

【サービスタグの場合】
Storage
AzureActiveDirectory
EventsHub
AzureSiteRecovery
AzureKeyVault
GuestAndHybridManagement

【レプリケーショングループ利用時】
Port 20004





全体の流れ

Step1:Recovery Service コンテナーの作成
Step2:レプリケーションの有効化
Step3:テストフェイルオーバーの実施
Step4:フェールオーバーの実施
Step5:フェールバックの実施

今回は、東日本の仮想マシンを西日本にレプリケーションします。


Step1:Recovery Service コンテナーの作成

[+リソースの作成]ー[検索:Azure Site Recovery]ー[作成]を選択

サブスクリプション:Azureサービスの提供範囲
リソースグループ:グループ名(複数のリソースを1つにグループ化する機能)
資格情報のコンテナー名:表示名
リージョン:メタデータの置き場所 ※DR元となるリージョン以外から選択

[Recovery Service コンテナー]が作成されます。


Step2:レプリケーションの有効化

[Site Recoveryを有効にする]を選択

[レプリケーションを有効にする]を選択

ソースの場所:保護対象となるVMが存在するリージョンを選択
Azure仮想マシンのデプロイメントモデル:リソースマネージャーを選択
ソース サブスクリプション:保護対象となるVMが存在するサブスクリプションを選択
ソース リソースグループ:保護対象となるVMが存在するリソースグループを選択
可用性ゾーン間のディザスターリカバリーを行いますか?:
可用性ゾーン:ゾーン[1 / 2 / 3]から選択

保護対象のVMを選択

ターゲットの場所:DR先のリージョンを選択
ターゲットサブスクリプション:DR先のサブスクリプションを選択
リソースグループ、ネットワーク、ストレージ、可用性:DR先の環境を選択
レプリケーションポリシー:レプリケーショングループの作成が可能
拡張機能の設定:Mobility Service の自動更新 ※再起動不要
※Mobility Service がインストールされるので、VMは起動しておく事

[リソースグループ、ネットワーク、ストレージ、可用性]のカスタマイズ

[レプリケーションポリシー]のカスタマイズ
※レプリケーショングループの新規作成やVM追加はここで行います。
※追加した仮想マシンをフェールオーバーするには、復旧計画が必要です。

有効化するとジョブが実行されます。
・保護の有効化に関する前提条件の確認
・モビリティ サービスをインストールしてターゲットを準備しています
・レプリケーションを有効にする
・初期レプリケーションの開始中
・プロバイダー状態の更新中

東日本にキャッシュ用のBlob(v1)が作成される





Step3:テストフェールオーバーの実施

※テストフェールオーバーは本番環境に影響を与えません。

[レプリケーションされたアイテム]ー[保護対象のVM]を選択

[テストフェールオーバー]を選択

復旧ポイント:
最新(最低RPO):送信されたデータを利用して復旧
最後に処理された時点(低RTO):最新のクラッシュ整合性を利用
最新のアプリ整合性:最新のアプリ整合性を利用
最新のマルチVM処理:レプリケーショングループに対して最新のクラッシュ整合性を利用
最新のマルチVMアプリ整合性:レプリケーショングループに対して最新のアプリ整合性利用
カスタム:保持しているクラッシュ整合性から選択
Azure仮想ネットワーク:DR先の仮想ネットワークを選択

西日本側に移行(複製)されているので、動作テストなどが行える。

テストを終了するには、[テストフェールオーバーのクリーンアップ]を選択

仮想マシンは削除され、レプリケーション用ディスクだけが残る。


Step4:フェールオーバーの実施

[フェールオーバー]を選択

復旧ポイント:
最新(最低RPO):送信されたデータを利用して復旧
最後に処理された時点(低RTO):最新のクラッシュ整合性を利用
最新のアプリ整合性:最新のアプリ整合性を利用
最新のマルチVM処理:レプリケーショングループに対して最新のクラッシュ整合性を利用
最新のマルチVMアプリ整合性:レプリケーショングループに対して最新のアプリ整合性利用
カスタム:保持しているクラッシュ整合性から選択

東日本側のVMは”割り当て解除”となる。

西日本に移行した事が確認できます。

再び、東日本に移行できるように準備するには、[再保護]を選択

西日本側では、レプリカディスクが消える。

東日本側にレプリカディスクが作成されている。 ※VMは割り当て解除済みのまま





Step5:フェールバックの実施

※フェールオーバーと同じ手順となります。

先ずは、テストフェールオーバーを実施

テスト終了後に[テストフェールオーバーのクリーンアップ]を実施

再び、東日本に移行するために、[フェールオーバー]を選択

東日本に移行した事が確認できます。


おまけ 復旧計画の作成

復旧計画とは、最大100台までのサーバーを1度の操作で順序よくフェールオーバーしてくれる便利なグルーピング機能です。
※レプリケーショングループに含まれていない仮想マシンも追加可能

[Recovery Plan]ー[復旧計画]を選択

名前:表示名
ソース:レプリケーション元リージョン
ターゲット:レプリケーション先リージョン
デプロイモデルでアイテムを許可:リソースマネージャー
選択された項目:復旧計画に追加する仮想マシンを選択

フェールオーバーの順序を設定する

[グループ1]から順にフェールオーバーされます。

※フェールオーバー / フェールバックの手順は同様です。