SIte recovery ナレッジまとめ（MSへの確認結果など）
- 1. はじめに
- 2. レプリケーションに要した時間の確認方法
- 3. 再保護に要する時間を類推する方法
- 4. Site recoveryとAzure Backupの相互運用可否について
- 5. Site RecoveryをサポートしているVMについて
- 6. ASRの対象VMは、最新windows update適用とルート証明書の最新化が必要
- 7. 必要なルート証明書について（詳細）
- 8. 復旧ポイントの保存期間について
- 9. フェールオーバ実施時におけるフォールオーバー元VMのシャットダウンの実施要否について
- 10. ASR試験時の大元のVMが停止するタイミング
- 11. リージョン崩壊時の再保護操作の可否
- 12. 再保護実施時に、VMに関連づけられているパブリックIP、NSGは関連付けを外す必要があるか
- 13. 東日本→西日本へフェールバックを実施した際に、東日本のVMが削除されるタイミング
- 14. ASR関連のログ（トラブルシュートに使えるログ）のありか
- 15. MSドキュメント（作業手順）について補足
- 16. アプリケーション整合性復旧ポイント
- 17. その他注意事項など
はじめに
一部の文章にて、「Site recovery = ASR」 と略して記載しています。
前提条件
以下の状況を前提条件（シナリオ）としてます
・西日本リージョンのAzure VM
・SQL仮想マシン（SQL server 2022 standard on windows server 2022 v64 gen2)
・西日本リージョン全体の障害が発生しVMのデータが完全損失した際でも、復元できるようにするため
西日本→東日本へＡＳＲを実施し、西リージョンが復旧した際に、東日本にバックアップした
データから、西日本リージョンに障害発生時のＶＭを復旧させる
レプリケーションに要した時間の確認方法
Azure portal > Recovery Services コンテナー > Site Recovery ジョブから確認できます。
“レプリケーション有効化" (または再保護) の開始時間と、"復旧バーチャル マシンの保護の最終処理" の “プロバイダー状態の更新中" の開始時間+期間 の差をとっていただくことで、レプリケーション有効化 (または再保護) に要した時間を確認いただけます。
再保護に要する時間を類推する方法
(フェールオーバー時に利用したディスクの種類や、VM のサイズ、VM リソースの使用状況が同一の場合) フェールオーバー実施後、データ変更が無い状況で再保護を実施した場合は、西日本から東日本へのレプリケーション有効化時間と再保護の時間がおおよそ同等になると考えられます。
ただし、利用状況等に依存しますので、あくまで参考程度に考えていただけますと幸いです。
Site recoveryとAzure Backupの相互運用可否について
同じAzure VMに対して、同時にSite recoveryとAzure Backupを適用できるか確認した結果
質問
試験として、運用環境のサーバにおいて
西→東→西
のsite recoveryによる一連の復旧プロセスを実施予定なのですが、プロセスのどこかで、何か不具合にヒットして、西側で復旧できなくなることを懸念しています。
（可能性は低いと思いますが、復旧できなかくなった時のリスクが大なので検討事項に入れています）
対象のVMについてはsite recoveryの対象としながらもAzure backupの対象にすることも可能なのでしょううか。
Site recoveryにっちもさっちもいかない状況になった時（フェールバックもうまくいかないし、回復ポイント変更もできない状況など）にAzure backupから復旧させることができると思いました。
回答
Azure Site Recovery と Azure Backup は相互運用可能です。
ただし次の表の通り、ディスクの復元や VM の復元を行う際は、レプリケーション停止および再レプリケーションが必要でございます。
ご参考) Azure Site Recovery と Azure Backup の使用
https://learn.microsoft.com/ja-jp/azure/site-recovery/site-recovery-backup-interoperability
ドキュメントには「現在サポートされていません」と記載されており、わかりずらいですが、こちらは、Azure Site Recovery と Azure Backup を併用している環境にて次の操作を行った場合、Azure Site Recoveryによる継続したレプリケーションをサポートしないことを示しております。(*)
・ バックアップしたディスクの復元
・ VM または VM グループの復元
復元操作を実施後も引き続きレプリケーションを行いたい場合は、一度 VM のレプリケーションを無効にした後、再度レプリケーションを有効化していただく必要がございます。
(*)Azure Site Recovery ではディスクから変更データ ブロックを追跡する仕組みとなっております。
そのため、復元が行われますと変更ブロックを追うことができず、継続してレプリケーションを実施することが不可でございます。
質問
試験時は①②を実施したのちに、ASRのフェールオーバ、再保護、フェールバックを実施予定です。
① ASRにて西VMを東のコンテナにレプリケーションを実施
②Azurebackupにて、西VMを、西のコンテナにバックアップ実施
「①② を実施したのちに、ASRのフェールオーバ、再保護、フェールバックを実施する手順」
と「①のみ実施したのちに、ASRのフェールオーバ、再保護、フェールバックを実施する手順」
で何か手順に違いは発生しますでしょうか。
回答
1 と 2 の違いによる ASR によるフェールオーバー、再保護、フェールバックの操作の変化はございません。
ディスクの復元や VM の復元を伴わない場合は、Azure Backup と Azure Site Recovery の併用において、追加で操作すべきことはございません。
※西日本へのフェールバック後も、ディスクの復元や VM の復元を伴わない場合は引き続き Azure Backup によるバックアップの取得および Azure Site Recovery によるレプリケーションを継続可能です。
ご参考) Azure Site Recovery と Azure Backup の使用
https://learn.microsoft.com/ja-jp/azure/site-recovery/site-recovery-backup-interoperability
Site RecoveryをサポートしているVMについて
Azure VMがトラステッド起動している場合、Site Recoveryの対象にできない
https://learn.microsoft.com/ja-jp/azure/virtual-machines/trusted-launch#unsupported-features
質問
SQL 仮想マシンを、トラステッド起動で作成した場合、Site Recovery の対象 VM として選定できないと認識しておりますが、
VM 作成後、「トラステッド起動⇒standard」に変更することは可能でしょうか
回答
現在 VM 作成後にトラステッド起動から Standard へ変更することはできません。
Azure Site Recovery のご利用を検討する場合、 VM 作成時に Standard を選択するよう、ご注意いただけますようお願いいたします。
ASRの対象VMは、最新windows update適用とルート証明書の最新化が必要
質問
以下のページに
https://learn.microsoft.com/ja-jp/azure/site-recovery/azure-to-azure-tutorial-enable-replication
———————————————————
Windows VM:最新のすべての Windows 更新プログラムを VM にインストールして、すべての信頼されたルート証明書をマシンに用意します。 非接続環境では、自社の標準プロセスに従って、Windows Update および証明書の更新を実施してください。
Linux VM:Linux ディストリビューターから提供されるガイダンスに従って、最新の信頼されたルート証明書と証明書失効リスト (CRL) を取得します。
———————————————————
と記載がありますが、上記状態にしておく必要があるのは、対象 VM のレプリケーションを有効にするタイミングのみという理解であっておりますでしょうか
（レプリケーションを有効にできた後は、特に上記の状態にしておく必要はないという認識であっておりますでしょうか）
回答
レプリケーション有効後も更新プログラムの適用や証明書の更新は必要でございます。
Windows Update の実施、および証明書の取得が実施されていない場合、レプリケーションの停止といった事象が発生する場合がございます。
証明書の期限が切れている場合は、レプリケーションの有効化自体ができません。
更新プログラムに関しては、最新でなくとも有効化は可能ですが、長期間に渡り更新プログラムを適用しない場合、レプリケーションの停止といった事象が発生する可能性もありますので基本的に最新の更新プログラムを適用いただけますと幸いです。
必要なルート証明書について（詳細）
質問
https://learn.microsoft.com/ja-jp/azure/site-recovery/azure-to-azure-tutorial-enable-replication
こちらのサイトに前提条件として以下の記載がございます。
「Windows VM:最新のすべての Windows 更新プログラムを VM にインストールして、すべての信頼されたルート証明書をマシンに用意します。 非接続環境では、自社の標準プロセスに従って、Windows Update および証明書の更新を実施してください。」
以前、御社プレミアSRで問い合わせさせていただいたところ以下の回答をいただいております。
———————————————————————————————————-
TLS/SSL 認証の成否につきましては、通常、TLS/SSL 認証は、Azure から提示される証明書が、クライアントの “信頼できるルート証明書のリスト” に含まれていれば成功します。
(*) Azure から提示される証明書について
以下現在 Azure サービス で必要となる証明書です。
◆ルート証明書
ルート証明書名 証明書の拇印
—————————————————–
DigiCert Global Root G2 df3c24f9bfd666761b268073fe06d1cc8d4f82a4
DigiCert Global Root CA a8985d3a65e5e5c4b2d7d66d40c6dd2fb19c5436
Baltimore CyberTrust Root d4de20d05e66fc53fe1a50882c78db2852cae474
D-TRUST Root Class 3 CA 2 2009 58e8abb0361533fb80f79b1b6d29d3ff8d5f00f0
Microsoft RSA Root Certificate Authority2017 73a5e64a3bff8316ff0edccc618a906e4eae4d74
Microsoft ECC Root Certificate Authority 2017 999a64c37ff47d9fab95f14769891460eec4c3c5
◆ 中間証明書
中間証明書名 証明書の拇印
—————————————————–
Microsoft RSA TLS CA 01 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a
Microsoft RSA TLS CA 02 b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75
———————————————————————————————————-
対象VMの証明書ストアを確認し、Site recoveryのルート証明書要件を満たすか確認しようと思いますが、
上記の「ルート証明書名」「中間証明書名」が証明書ストアに存在すればよろしいでしょうか。
証明書の拇印が上記値と一致しているかの確認は不要でしょうか。
また、他にもしあれば、Site recoveryのルート証明書要件を満たすかを確認すべき箇所をご教示ください。
ちなみに、対象VMでは「ルート証明書更新プログラム」は利用されておりません。
回答
以下手順にて、Windows OS での証明書のインポート状況をご確認いただけますようお願いいたします。
ご質問内容に記載いただいた各種証明書がインポートされておりましたら、Azure Site Recovery を利用する上での SSL/TLS 証明書の要件は満たしております。
<証明書の確認手順>
1. 対象サーバーに管理者権限でサインインします。
2. [スタート] – [ファイル名を指定して実行] から、certlm.msc と入力して、[Enter]キーを押します。
3. UAC が起動しますので管理者権限での実行を許可します。
4. 左側の [証明書 (ローカル コンピューター)]を展開して、 [信頼されたルート証明機関] – [証明書] を開きます。
5. 上記 ◆証明書 の 6 つの証明書が含まれていて、かつ [詳細] タブより、サムプリント (拇印) が一致するかご確認くださいませ
6. 続けて左側の [中間証明機関] – [証明書] を開きます。
7. 上記 ◆中間証明書 の 2 つの証明書が含まれて、かつ [詳細] タブより、サムプリント (拇印) が一致するかご確認くださいませ
ご参考) certlm の画面
もし上記の証明書が確認できない、拇印が更新されていない場合、以下手順によりインポートをご検討いただけますと幸いです。
<ルート証明書のインポート手順>
——————————–
1. 証明書をエクスポートしたいマシンに、管理者権限でログインします。
2. [スタート] – [ファイル名を指定して実行] から、certlm.msc と入力して、[Enter]キーを押します。
3. UAC が起動しますので管理者権限での実行を許可します。
4. 左側の [証明書 (ローカル コンピューター)]を展開して、 [信頼されたルート証明機関] – [証明書] を開きます。
5. [証明書] を右クリックし [すべてのタスク] – [インポート] と選択します。
6. 証明書のインポートウィザードが起動しますので以下の様に進めます。
・ 「証明書のインポート ウィザードの開始」画面で [次へ] をクリック。
・ インポートする証明書のファイル -> (下記公開情報よりダウンロードした各証明書を保存したパス)
・ 証明書ストア -> (“信頼されたルート証明機関" となっていることを確認)
7. 「信頼されたルート証明機関」証明書ストアに証明書がインポートされた事を確認します。
ご参考) 手順 5. の [インポート]
※ 中間証明書のインポート手順は、上記の「信頼されたルート証明機関」の箇所を「中間証明機関」にお読み替えいただけますようお願いいたします。
<証明書に関する公開情報>
『Azure TLS 証明書の変更』
https://docs.microsoft.com/ja-jp/azure/security/fundamentals/tls-certificate-changes
『中間証明書のご参考) Azure Storage TLS: Changes are coming! (…and why you care) (英語) 』
https://techcommunity.microsoft.com/t5/azure-storage/azure-storage-tls-changes-are-coming-and-why-you-care/ba-p/1705518
質問
—-
D-TRUST Root Class 3 CA 2 2009 58e8abb0361533fb80f79b1b6d29d3ff8d5f00f0
こちらが[信頼されたルート証明機関] – [証明書]にインポートされておりませんでしたので、
いただいた手順で、証明書ダウンロードとインポートをしたところ
[信頼されたルート証明機関] – [証明書]に
D-TRUST Root Class 3 CA 2 2009
D-TRUST Root Class 3 CA 2 2009
のように同じものが２つエントリーされておりましたが、
特に問題はないでしょうか。（サムプリント (拇印)も値が同じでした）
回答
問題ございません。[信頼されたルート証明機関] – [証明書] では、ユーザーで利用可能な証明書を表示するため、複数の場所にルート証明書が存在する場合等で複数表示される場合もございます。
対処は必要ございません。そのままご利用いただければと存じます。
復旧ポイントの保存期間について
質問
「過去のどの時点まで遡って復旧できますか?」
https://learn.microsoft.com/ja-jp/azure/site-recovery/site-recovery-faq#——————–
今回マネージドディスクを使用しています
フェールオーバー操作の復旧ポイントを選択する際に、フェールオーバーを実施しようとしている時点から過去15日の復旧ポイントしか選択できないという理解であっておりますでしょうか
西日本リージョンが崩壊（タイミングAとする）する少し前の状態にVMを戻そうとすると、、タイミングAから15日以内に東日本でフェールオーバーをしないと、フェールオーバー自体ができなくなってしまう
という理解であっておりますでしょうか。（西日本リージョンが崩壊するくらいの障害ですと、フェールオーバーできる作業者がいなくなるなどの不測の事態が考えられるので、フェールオーバーする際のタイムリミットがあるのかという点が気になりました）
回答
リージョン障害等でレプリケーションが停止してからフェールオーバーの実施について、期間の制限はございません。
リージョン障害等の問題が発生し、復旧ポイントの生成ができなくなった場合、古い復旧ポイントは残り続けるため、その復旧ポイントを使用することでフェールオーバーは実施可能でございます。
ご参考) 問題が発生し、Site Recovery で 1 日以上復旧ポイントを生成できなくなった場合、どうなりますか? 以前の復旧ポイントはなくなりますか?
フェールオーバ実施時におけるフォールオーバー元VMのシャットダウンの実施要否について
質問
> こちらに[フェールオーバーを開始する前にマシンをシャットダウンします]とありますが、
> シャットダウンをした方がよい（推奨する）などありますでしょうか。どのようなケースで
> こちらにチェックを入れるべきかがわかっておりません。
回答
シャットダウンの必要性について、特に推奨はございません。
お客様のユース ケースに合わせて本機能を利用し、フェールオーバー後のソース 側マシンのシャットダウンを制御いただければと存じます。
利用されるケースとしては、フェールオーバー後に移行元の VM を継続利用しないため、VM のコストを抑止するために、シャットダウンする等がございます。
ASR試験時の大元のVMが停止するタイミング
質問
>災害時を想定して、一通り試験をしようとしています。
・西から東へレプリケーション有効化～フェールオーバー～再保護～西でフェールバック
という一連のプロセスの中で、元の西のＶＭに通信断が発生するタイミングはありますでしょうか。
本試験を、運用中にして実施してもよいか、それとも、運用時間外に実施すべきかを決めたいと考えております。
回答
フェールオーバー後、再保護のタイミングで西日本のソース VM は割り当て解除 (シャットダウン) されるため、その後西日本へフェールバックするまで通信断は発生します。
このため、運用時間外に実施することを推奨いたします。
また、フェールオーバーの前にはテスト フェールオーバーをご実施いただき、移行後の VM が正常に動作するか確認いただくことを推奨しております。
ご参考) Azure へのテスト フェールオーバー (ディザスター リカバリー訓練) を実行する
https://learn.microsoft.com/ja-jp/azure/site-recovery/site-recovery-test-failover-to-azure
リージョン崩壊時の再保護操作の可否
質問
・東→西の再保護の操作をしようとしたタイミングで、
大規模障害により西日本リージョンが復旧していない場合、再保護の操作自体はできますでしょうか。それともできないでしょうか。
できない場合、システム管理者は何を契機に再保護ができるようになったと認識できるのでしょうか（Azure portal上の●●の部分が、「OK」となっていたら、再保護可と判断できる など）
回答
西日本リージョンに障害が発生している場合、通常、障害のため再保護操作はできないと存じます。
下記 Azure の状態をご確認いただき、リソースが正常に利用されましたら再保護を実施していただけますようお願いいたします。
障害情報上正常であっても、再保護できない場合は、お手数ですが弊社サポートまでご連絡下さい。
Azure の状態
https://azure.status.microsoft/ja-jp/status
再保護実施時に、VMに関連づけられているパブリックIP、NSGは関連付けを外す必要があるか
質問
西→東へフェールオーバーした後、東のVMにRDP/SSH接続するにはパブリックIPアドレスの設定およびNSGの設定が必要だと認識しておりますが、再保護をする前に、東のVMに設定したパブリックIPアドレスおよびNSGはVMからの関連付けを外しておくべきでしょうか。
それとも、再保護には関係ないので、関連付けを外す必要はないでしょうか
回答
再保護時に、ターゲット VM (東日本) のパブリック IP やNSGの関連付けを削除する必要はございません。
Azure Site Recovery としては、以下の接続の要件が満たされていれば問題ございません。
ご参考) 接続の要件
東日本→西日本へフェールバックを実施した際に、東日本のVMが削除されるタイミング
質問
・東→西のフェールバック後に、東日本のVMが削除されるのはどのタイミングでしょうか。
（フェールバックのコミットボタンを押したタイミングでしょうか）
回答
フェールバック後、コミットし、さらに再保護後を行ったタイミングで東日本 (ターゲット リージョン上 の VM) が削除されます。
ASR関連のログ（トラブルシュートに使えるログ）のありか
質問
西→東→西のフェールバックまでの一連の作業を実施する際に、取得すしておくべきログなどありますでしょうか。
イメージとしては、一連の作業のどこかで何か問題が発生した場合に御社（マイクロソフト）サポートに原因究明のご依頼をさせていただくことになると思いますがその際、お渡しするログとして何か用意しておくべきか？というのが質問意図となります。
回答
よろしければトラブルの際には、以下のフォルダのコピーを zip ファイルとしてご用意いただけますと幸いです。これらのログは、特に設定せずに Azure Site Recovery によるレプリケーションを構成した際に、自動的にログが蓄積されます。
■windowsの場合
・ C:\ProgramData\ASRLogs
・ C:\ProgramData\ASRSetupLogs
・ C:\ProgramData\Microsoft Azure Site Recovery
・ C:\Program Files (x86)\Microsoft Azure Site Recovery\agent
・ C:\WindowsAzure\Logs
・ C:\Windows\System32\winevt\logs
■Linuxの場合
RHEL のログ出力先 :
- /var/log 配下
- /var/log 配下を全てアップロードいただくのが難しい場合は、まずは以下のログ ファイルを採取いただけますと幸いです。
・ /var/log/Waagent.log
・ /var/log/AzureRcmCli.log
・ /var/log/ua_install.log
・ /var/log/azure/
・ /var/log/InstallerError.json
・ /var/log/ApplicationPolicyLogs/Vacp.log
——————————-
MSドキュメント（作業手順）について補足
質問
こちらの手順によるとフェールバック時はテストフェールオーバを実施していないですが
フェールバック時はテストフェールオーバーは不要という認識であっておりますでしょうか。
回答
フェールバック時も念のためテスト フェールオーバーを実施することを推奨いたします。
質問
こちらの手順を見ますと、フェールバック後に、コミットせずに
再保護しておりますが、コミットは不要という認識であっておりますでしょうか。
回答
恐れ入りますが、コミットを実施後に再保護を行っていただけますようお願いいたします。
コミットを実施せずに再保護を実施する際、選択可能なストレージ アカウントがソース リージョンではなく、ターゲット リージョンのものとなっている事象を確認しております。
(例として、西日本から東日本にフェールオーバー後に再保護を行う場合は、東日本上のストレージ アカウントを選択する必要がありますが、現在 portal上では西日本のストレージ アカウントが表示されてしまう事象を確認しております。)
このため、コミットを実施せずに再保護を実施した場合は、ソース VM と同じリージョンのストレージ アカウントが指定されないため、再保護のフェーズでエラーが発生します。
アプリケーション整合性復旧ポイント
長くなるので、別ページにまとめています。
Site recoveryのアプリケーション整合性復旧ポイント – mitsurublog
その他注意事項など
- 検証を実施する際は、お客様環境に極力合わせて検証を実施すること（VMサイズ、VMディスク搭載状況、VM設定、リージョンなど） → 少しでも条件が違うと、検証環境で動いても、本番で動かない可能性があります
- 西のVMを保護したい場合、Recovery Serviceコンテナは、西以外のリソースグループを使い、西以外のリージョンに作成する必要がある
- フェールオーバー後、対象VMにはパブリックIP、NSGが関連づけられていないため、リモートアクセスしたい場合は、設定が必要
- フェールバック実施後は、元のVMのパブリックIP、NSGが関連付けられるため、対応不要（NSGはサブネットに適用されており、そのサブネットに復旧させたため、対応不要だった）