Azure Site Recovery(ASR)を利用して東日本-西日本でフェールオーバー可能な構成をとることはよくあることだと思います。ASRもPaaSサービスのため、いつもの"閉域化"の対象となります。
基本的にはDocsが整備されているのでそのイメージ通りに進んでいけば構成できるかと思います。ただ、幾つか見落としがちな注意点が含まれていたりするのでまとめておきます。
この記事ではAzure-to-Azureのシナリオのみ扱います。
Azure Site Recovery
前提
-
前提としてターゲットリージョンにデプロイ
- ソースリージョンが落ちると一緒に落ちてしまうため
-
キャッシュストレージはソースリージョンに配置
-
DR先のIaaS以外のリソースについては事前に作成しておく
- VNet
- PaaS系サービス
-
DRは経営判断
- 基本手動で行う
- DBとかサーバレベルの自動フェールオーバーとは意味合いが異なる
ASRのManaged IDへのRBACロール付与
-
キャッシュストレージアカウントに対して下記権限が必要
- "共同作成者"
- "ストレージBLOBデータ共同作成者"
-
付与されていないとエラー
-
再保護・フェールバックをする場合には、ターゲットリージョン側のキャッシュストレージアカウントにも同様にRBACロールを付与
キャッシュストレージアカウント
ASRのレプリケーション設定
- どこでキャッシュストレージを設定するかわかりづらいので、設定を忘れるとキャッシュストレージが新規作成されてしまう
- ASRのMIDへのRBACロール付与ができていない状態となりエラー終了する
- キャッシュストレージの設定はここ
- 再保護(=フェールバック)をする場合、ターゲットリージョン側にストレージアカウントが必要
リソース設定
- "論理的な削除"が有効だとエラーになるため無効化
NSG
Azure Active Directryへの経路確保
- インターネット接続拒否のルールを利用している場合にはエラーが出る
- NSGの送信規則にて、サービスタグ:AzureActiveDirectoryに対してHTTPS接続を許可する規則を追加
Private Endpoint
- Private Link Centerから作成する必要なし、リソース側からでOK
- Private Endpoint経由にさせたい場合には、ターゲットネットワーク側にもRecovery Servicesコンテナーおよび再保護用のキャッシュストレージアカウントへのPrivate Endpointを作成する
- Private Endpointを設定していないと、再保護時にエラーが発生
- Private Endpointを設定していないと、再保護時にエラーが発生
ジョブ状態の監視
- 上記のハマりポイントに気を付けるとおそらくジョブはすべて成功する
レプリケーション完了
再保護
- ASRでフェールオーバーをポチっと実行すると、ASRに保護されていないVMがターゲットリージョンに立ち上がる
- このVMを"再保護"することによって、"ソースVM"として扱うことができるようになる
- もともとのソースとターゲットが逆転するイメージ
- アクティブな場所がJapan Westになっている
- 再保護した状態でフェールオーバーをすると、逆向きに実行され、もともとのリージョンでVMが立ち上がる
- その繰り返し
- 再保護の有効化には、ターゲットリージョン側にキャッシュストレージアカウントが必要
- 必要に応じてPrivate Endpoint
- ASRのMIDに対するRBACロールは必要
- ASRでPrivate Endpointを有効化している場合には、ターゲットリージョン側のPrivate Endpointが必要
GitHubで編集を提案
Discussion