はじめに
AzureにおけるBCP（事業継続計画）の実現手段のひとつとして、「Azure Site Recovery (ASR)」が注目されています。ASRを利用すれば、Azure内でのフェールオーバーが比較的容易に実現でき、Microsoftのバックボーンを介して継続的にレプリケーションが行われるため、障害発生時には迅速な切り替えが可能です。
しかし、構築より前に DR（ディザスタリカバリー）に最適な構成設計を十分に検討しておかないと、後工程で手戻りが発生します。本記事では、ASRを用いたDR環境構築時に直面しがちな技術的な課題と、それらを解決するためのポイントを整理し、具体的な構成例を交えて解説します。
特に記述がない限り、Azure から Azure 、東日本リージョンから西日本リージョンへのフェールオーバーを使用したシナリオについて述べています。
やりたかったこと
本記事で取り扱う環境の全体構成図（概要）と、このPJで実現したかったことは以下の通りです。
- 通常運用は東日本で行います
- 可用性を確保するため、各ゾーンにVMを分散配置します
- パフォーマンスが必要なVMは近接配置グループに配置して可用性セットを構成します
- 災害対策としてASR でディスクのレプリケーションを非同期的に行います
被災時は
- リカバリーサービスコンテナーにアクセスしてフェールオーバーを実施
これによりASRはあらかじめ設定していた可用性セットやVNET、およびレプリケートされたディスクを用いてVMをデプロイされます。
要件定義
フェールオーバー前と同等の環境を実現する難しさ
ASR は、DR環境に同構成の仮想マシンを短時間で立ち上げることができる機能を持っています。
そのため、「フェールオーバー後に本来の運用環境と同等の性能・可用性を確保すること」のように、要件や前提として求められることがあります。
しかし実際は各リージョンごとにクラウドプロバイダーから提供される機能には差異があるので、東西リージョン間で同等の機能を確保するための設計が別途必要です。またASR自体にも「対応しているVMサイズ」などの制限があります。
東西リージョン間の差異で問題となったのが、可用性ゾーンです。
東日本リージョンでは可用性ゾーンを利用できるため高い可用性を実現できますが、西日本リージョンでは可用性セットの利用が必要となります。
可用性セットがサポートしていない機能を本番環境で使用していた場合、DR環境は性能と可用性どちらかが犠牲になります。
DR設計の初期段階でフェールオーバー後に必要な機能、性能、可用性の要件を十分に洗い出し、各リージョンの特性を踏まえた設計を行うことが重要です。
東日本でしかサポートしていないサービス
例えばこのようなAzureリソースが西日本リージョンでサポートされていません(2025年2月現在)：
- 可用性
- 可用性ゾーン ※ 今後対応予定あり
- ASRによるゾーン間DR
- サービス
- Azure Container Apps
- Azure OpenAI Service
- SQL Server - Azure Arc
- Microsoft Graph
- Microsoft Purview
- ストレージアカウント
- Premium SSD v2
- Ultra Disk Storage
- Premium Tier for Azure Data Lake Storage
- 仮想マシン
- VirtualMachine(Bpsv2-series)
- VirtualMachineA8 ～ A11 (Compute Intensive)
- mdsv2
他多数
以下にも記載はありますが、すべて網羅されているわけではありません。
例えば、Availability Zone の項目は「可用性ゾーン」のドキュメントに制限が記載されています。
Product Availability by Region
https://azure.microsoft.com/en-us/explore/global-infrastructure/products-by-region/table
可用性ゾーンをサポートする Azure リージョン
https://learn.microsoft.com/ja-jp/azure/reliability/availability-zones-region-support
これらの違いを踏まえ、DR環境の設計時には「フェールオーバー前と同等」の状態を実現するための調整が不可欠となります。
調査について
ドキュメントはすべての制限を網羅していないので、可能であればPOC(概念検証、実現可能性検証)は機能が限定される環境で行うとよいでしょう。
今回の例では西日本リージョンで要件を満たすことを確認します。
オンデマンド容量予約(VMの起動を保証する仕組み)
Azureデータセンターでは通常時、十分なリソースが確保されていますが、大規模災害時には多くの利用者が西日本リージョンで同時にVMの起動を試みるため、リソースが不足する可能性があります。
この問題に対処するための仕組みが オンデマンド容量予約 です。
オンデマンド容量予約は、災害時に必要なVMの起動に対して、あらかじめ必要なリソース容量を予約する機能です。
これにより、災害発生時でも必要な数のVMを確実に起動することが可能になります。ただし、追加費用が発生し、同時に他のリソースと使用できない制約もあります。この点を予算計画時に十分考慮する必要があります。
On-demand Capacity Reservation in Azure - Azure Virtual Machines | Microsoft Learn
オンデマンド容量予約を利用することで、DR環境におけるリソース不足のリスクを低減できます。
「オンデマンド容量予約」と「Azureの予約／予約インスタンス」の違い
現場では容量予約が「コスト削減を目的とした予約機能」と混同されがちなので注意しましょう。
- オンデマンド容量予約(On-demand Capacity Reservation)
- 災害時のVM起動を保証するために、必要なリソースを事前に予約する仕組み
- 指定席のようなイメージで、乗車は一定範囲で保証される
- お金払うから、その分は他の人に使わせないでね！
- 災害があったときにはそのVMを起動できるように確保しておいてね！
- Azureの予約/予約インスタンス(Azure Reserved Virtual Machine Instances)
- 長期利用を前提としたコスト削減のための予約機能
- 定期券のようなイメージで、乗車や着座は保証されない
- この製品やVMを1年(3年)使うので、その分ちょっとお安くしてね！
- 毎月請求金額が変わると困るので、毎月(毎年)定額で請求してね！
オンデマンド容量予約と予約インスタンスの合わせ技も可能です。しかし、予約インスタンス自体は仮想マシンの起動は保証しません。
なお、 Azure Backup Storage容量予約 は、「オンデマンド容量予約」ではなく「Azureの予約」の一種です。
https://learn.microsoft.com/ja-jp/azure/virtual-machines/capacity-reservation-overview
設計
設計段階でも「容量予約」がハマりどころでした。
- 可用性セットとの排他なので通常運用時の可用性に影響
- 近接配置グループと排他なのでパフォーマンスに影響
- 「オンデマンド容量予約」と「Azureの予約」という似た用語による混乱
- 可能な限り予算を下げる設計が欲しいという要望の対応
などです。
同時に利用できない機能が要件に影響する
メインサイトと同様の可用性と高性能なものを、災害時にもデプロイもできることを求められましたが、以下の制約によりできずその調整に難航しました。
オンデマンド容量予約と同時に使用できない機能
- 可用性セット
- 近接配置グループ
- 更新ドメイン
- Ultra Disk, Premium SSD v2
可用性と同時に使用できない機能
- 可用性ゾーン
- オンデマンド容量予約
- Ultra Disk, Premium SSD v2
ディスクはそもそもASRが対応していないので問題とはならなかったものの、可用性や性能の劣化が問題になりました。
まとめると以下のような関係になります。
全組み合わせのマトリクスです。
2024年10月現在、現実的な構成は「可用性セット＋近接配置(高可用性・高性能)」か「容量予約(デプロイ保証)」の二択です。
| 容量予約 | 可用性セット | 可用性ゾーン | 近接配置 | 構成可否 | デプロイ保証 | 高可用性 | 高性能 |
|---|---|---|---|---|---|---|---|
| ― | ― | ― | ― | ○ | ― | ― | ― |
| ― | ― | ― | ✔ | ○ | ― | ― | ✔ |
| ― | ― | ✔ | ✔ | ○ | ― | ✔※ | ✔ |
| ― | ― | ✔ | ― | ○ | ― | ― | ― |
| ― | ✔ | ― | ― | ○ | ― | ― | ― |
| ― | ✔ | ― | ✔ | ○ | ― | ✔ | ✔ |
| ― | ✔ | ✔ | ― | × | ― | ― | ― |
| ― | ✔ | ✔ | ✔ | × | ― | ― | ― |
| ✔ | ― | ― | ― | ○ | ✔ | ― | ― |
| ✔ | ― | ― | ✔ | × | ― | ― | ― |
| ✔ | ― | ✔ | ― | ○ | ✔ | ✔ | ― |
| ✔ | ― | ✔ | ✔ | × | ― | ― | ― |
| ✔ | ✔ | ― | ― | × | ― | ― | ― |
| ✔ | ✔ | ― | ✔ | × | ― | ― | ― |
| ✔ | ✔ | ✔ | ― | × | ― | ― | ― |
| ✔ | ✔ | ✔ | ✔ | × | ― | ― | ― |
※ 同一の近接配置グループに属するVMは異なる可用性ゾーンに配置できないため、うまくゾーン分けする必要がある。
可能な限り予算を下げる設計をどうするか？
災害発生するまでは課金したくないが、発生したら可能な限り高い期待値で仮想マシンを西日本にフェールオーバーしたい…そんな要望の調整がずっと行われることになります。
仮に私が実装するなら、こんなのが妥協点ではないかと思いました。
容量予約グループと紐づけだけしておき、最速で容量を確保します。
- あらかじめ容量予約グループを作っておく
- 容量予約はインスタンスサイズだけ定義して数をゼロにする
- ASRと容量予約グループとの紐づけは済ませておく
- 災害発生したら、現場判断で即応してオンデマンド容量予約のインスタンスを確保する
- 体制解除になったらインスタンスサイズをゼロに戻す
構築
構築時は以下のような問題が起きました。
- 作業者に割り当てる権限の問題
- ASRのレプリケーション再有効化の頻発
- OSから初期化していなかったディスクは以後レプリケートされない
- 初期レプリケーションが進まない
- OSのIP固定によるフェールオーバー後操作不能
作業者に割り当てる権限の問題
初回のレプリケーション構成では、「所有者」または「ユーザーアクセス管理者」といったより高い権限が必須となります。
これはリカバリーサービスコンテナーで最初にレプリケーションを構成時、かつVM内のASRのエージェントの更新を許可する場合に必要です。
Automation アカウントの作成とVM 内エージェントの更新に対する権限を付与するために使用されます。
この権限は「共同作成者」では足りず「所有者」または「ユーザーアクセス管理者」といったより高い権限が必須でした。
一度レプリケーションが有効化された後は低い権限でも作業可能です。しかし初回は権限不足で作業が進まず、エラーメッセージが表示されました。
エラーメッセージには「サインインしたアカウントが共同作成者に割り当てられていることを確認してから、再試行します」と表示されるものの、実際には高い権限が求められていたため、権限を持ったユーザーでサインインし、「<コンテナ> - Site Recovery インフラストラクチャ- 拡張機能の更新の設定」から適切な権限を付与する対応が必要でした。
ASR のレプリケーション再有効化の頻発
ASR の構成後も、スケジュールに余裕を持っておく必要があります。
仮想マシンの構成が完全に確定する前に ASR を有効化すると、後からの構成変更（NIC の付け替え、高速ネットワークの有効化、ディスク枚数の変更、またはソース VM 自体の再作成など）により、何度もレプリケーションの無効化と再有効化を余儀なくされました。
これにより、運用上の負荷が増すだけでなく、RPO（復旧時点目標）の悪化や、既存の複製情報が失われるリスクも伴いました。
構成をできるだけ固定してから ASR を有効にすることが望ましいものの、実際には変更が避けられず、再構成作業が頻発しました。
ASRの再構成要因と、発生した理由について例を挙げます。
仮想マシンの再作成による作業のやり直し
仮想マシンの再作成が必要になると、単に作業時間が延びるだけでなく、RPO の悪化や 既存の複製が削除される という問題が発生します。
では、どのようなときにVMの再作成が発生するでしょうか。
-
リソースグループやサブスクリプションの移動
クォーターや管理、請求の単位などでこれらが起こりえます。
VMのリソースグループ間の移動はサポートされていますが、検証の結果これができないことも多々あります。 -
VNET の移動
VMは仮想ネットワークと密接に関連しているため、VNETの移動もVM再作成が必要です。 -
可用性セットの変更（再参加）
これは同じ可用性セットへの再参加、というケースでも発生します。
原因の一つが、障害ドメインの偏りです。
例えば複数のVMをデプロイするとき。コスト削減のために使用していないVMはシャットダウンして、1台ずつVMをデプロイする可用性セットに参加させる、というのはやりがちだと思います。
しかしそうすると、全ての VM が同一の障害ドメインに配置されることがあります。
https://jpaztech.github.io/blog/vm/plwv-bt0/
- トラステッド起動の VM 誤作成
仮想マシンをデプロイするとき、既定でトラステッド起動のオプションが有効になります。
トラステッド起動のVMは、ASRに対応していません。
これを後からOFFにすることができないため、再作成が発生します。
- キャッシュストレージアカウント・レプリカマネージドディスクの変更
レプリカマネージドディスク既定値はソースVMのディスクと同一です。
構築中はディスクのプランを安いものにするというケースは要注意。
VMの削除前に必ず情報を連携してもらってレプリケーションを事前に無効化してもらうよう体制を組んでおきましょう。
レプリケーション構成が壊れます。最悪、Azureの中の人に依頼して修復してもらうことになります。
接続ディスクの初期化状態によるレプリケーション問題
レプリケーションの有効化時に、接続ディスクがOS上からフォーマット（初期化）されていない場合、そのディスクはレプリケーション対象になりません。
構築時には、各 VM にログインして diskmgmt.msc でディスクの状態を確認し、必要に応じた初期化作業を事前に実施することが重要です。
以下は、ディスクの初期化前後の状態例です。
この画面で「はい」にしても、OS上で初期化されていないと複製対象とならない。
このように、データディスクが存在しない状態になる。
ログインして diskmgmt.msc を見る。この状態だとNG
ここで初期化が必要。
その際に The RPC server is unavailable エラーとなるなら diskmgmt.msc の再起動を何度か試す。
パーティションのフォーマットまでは不要。ここまでできていればOK。
15分間隔くらいでエージェントの情報がAzureに送られている印象。15分ほど待つと上記のように「保護なし」の状態表記で登場する。ディスク名をクリックするとソースディスクの詳細とともに「レプリケーションを有効にする」ボタンが表示されるので、それをクリックすることで複製対象となる。
最初のリカバリーポイントの作成が完了すると、状態は「保護」となる。
ネットワークの疎通問題と初期レプリケーションの遅延
ASRはVMの構築だけでなく、ネットワークの疎通も重要です。
各VMは、ASR関連のURLにプロキシ経由無しで到達可能であることが必要です。
また、ネットワークのスペシャリストと密に連携が取れるよう名体制も必要です。
初期レプリケーションが進まない主な原因として、ファイアウォールやプロキシの設定によるネットワーク疎通の問題が挙げられます。
特にプロキシを経由する場合、SSL インスペクションによる証明書エラーが発生し、ディスクへの書き込み通信がプロキシ経由で全て処理されるため、プロキシやファイアウォールに過大な負荷がかかることがありました。
各 VM に ASR 用の設定ファイルを配置するなど、プロキシを経由しない通信経路の確保と、事前のネットワーク接続確認が必須となります。
エラーメッセージは明示されないこと多く、いつまでたっても同期が終わらないので調べてみたら…ということも良くあります。複製対象のディスクサイズとかかる時間が比例しないので、異常の発見は遅れがちです。
毎日定期的にアラートを確認し、一晩っても進まないなら調査や問い合わせをするといった運用になりがちです。
VMに配置するプロキシ設定ファイル 「ProxyInfo.conf」のエンコードは BOMなしutf-8 , ANSI で機能するもののBOMあり UTF-8 では機能しませんでした。Powershellや「コマンド実行」機能などで配布する際は要注意。
参考情報:
Azure から Azure へのディザスター リカバリーのためにモビリティ サービスのプロキシ設定を構成する
Azure 仮想マシン ディザスター リカバリーでのネットワークの概要 URL に対する送信接続
プロセス サーバーのトラブルシューティング ※ VMWareとあるがAzureVMでも応用できる
OS 上の固定 IP を必要とするミドルウェアの問題
Azure の仮想マシンでは、OS 上で静的 IP を設定する運用は非推奨です。
フェールオーバー時に固定 IP 設定が原因で SSH 等のアクセスが不能になるリスクがあるため、DHCP の利用や cloud-init の設定を有効にする必要があります。
固定 IP を必要とするミドルウェアが存在する場合は、ASR の対象から除外するか、運用フローの見直しを検討することが求められます。
各種構成変更やシステム移行の前には、関係者間で十分な調整と事前テストを実施し、構築作業中のトラブルを未然に防ぐ体制を整えましょう。最悪の場合、Azure サポートへの依頼が必要となるケースもあるため、運用フローと権限管理、ベンダーとの連携法の確立が重要です。
試験について考慮すべきこと
フェールオーバーテストを実施する際、いくつかの重要な点が明らかになりました。主な課題は、VM のクォーター枯渇と、テストフェールオーバー（TFO）機能の活用不足です。
VM のクォーター枯渇
フェールオーバーテスト実施前に、各リージョンおよびサブスクリプション単位での VM クォーター状況を十分に確認し、必要に応じて余裕を持った上限増強の申請を行うことが必須です。
背景と実例
-
テスト実施の背景:
コスト削減のため通常は VM をシャットダウン状態にして運用していました。
構築も1台ずつ行い、ある程度出来上がったらシャットダウンしていきます。
しかし、ASR の有効化とフェールオーバーのテストの際に、関連する機能のVMを一斉に起動する必要が生じたところ、既存のクォーター上限に達してしまいました。 -
要因:
- 同一の機能群に属する VM が集中し、サイズも偏っていたため、クォーター枯渇が発生。
- クォーターはリージョン単位だけでなくサブスクリプション単位でも管理されるため、東西双方で上限増強のリクエストを行ったものの、後日増えることになった西日本の一部サブスクリプションに対しての申請が漏れていました。
-
影響:
結果、全 VM のフェールオーバーテスト実施時に一部の仮想マシンが起動できず、即日の上限解放申請ができずサポートリクエスト対応となる事態に陥りました。
対策
-
事前確認:
各リージョン・サブスクリプションごとのクォーター状況を事前にチェックする。 -
余裕を持った申請:
必要なリソース数を見越して、十分な余裕を持ったクォーター上限増強の申請を実施する。 -
リードタイムの確保:
即日対応ができないものと考えた方がよく、試験前に余裕を持った計画と申請が必要です。
テストフェールオーバー（TFO）機能の活用不足
テストフェールオーバー とは
ASR のテストフェールオーバー機能は、ソース VM を停止せずに、指定したネットワーク（VNET）上にフェールオーバー先の VMのコピーを展開できる仕組みです。
レプリケートも継続して行われ、クリーンアップも容易に実施可能です。
この機能により、本番環境に影響を与えることなく、ミドルウェアやアプリケーションの動作確認が可能となります。
課題と実例
-
利用前提の不足:
本プロジェクトでは専用のテスト用 VNET を用意する余裕がなく、他環境を巻き込んだテスト計画を策定できなかったため、テストフェールオーバー先には本番と同じVNETを指定していました。
このため本番環境に近いテストができるというメリットが構築時にはあったものの、構築が進むと本番環境への影響を鑑みてテストフェールオーバーを行うことができなくなり、TFO 機能を十分に活用できませんでした。
- 結果:
- フェールオーバー後のミドルウェアのテスト等ができなくなります。
- 試験工程では大規模にシステム全体をフェールオーバーしなければならなかった
- フェールオーバー後のキャンセル機能はないため、切り戻しにはレプリケーションの破棄、手動での関連リソースの調査と削除、再レプリケーションといった作業が必要となった
- 本番環境へやスケジュールへの影響を抑える検証が困難となった
対策
-
専用テスト環境の構築:
TFO 機能を有効活用するためには、専用のテスト用 VNET を準備し、本番環境と同等のネットワーク構成を模した検証環境を整備する必要があります。設計の初期段階で提案が必要です。 -
テスト計画の策定:
TFO の機能とそれを利用した検証計画を関係者間で共有し、実施手順や影響範囲を明確にしておくことが望まれます。 -
事前検証の実施:
本番フェールオーバーテストの前段階として、TFO 機能を使った動作確認を実施することで、万が一のトラブル時に迅速に対応できる体制を整えることが重要です。
以上の経験から、フェールオーバーテストを実施する際は、VM のクォーター管理とテストフェールオーバー機能の前提条件整備が不可欠であると感じました。
各リージョン・サブスクリプションごとのクォーター状況の事前チェックと、TFO 機能を活用した専用テスト環境の整備により、今後のフェールオーバーテストの精度と迅速な対応が期待できます。
おわりに
この記事は、AzureのDR設計における問題点とその対処方法について詳述しています。
今後のDR設計の参考になれば幸いです。