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]から順にフェールオーバーされます。
※フェールオーバー / フェールバックの手順は同様です。