Azure から Azure へのディザスター リカバリー アーキテクチャ
この記事では、Azure Site Recovery サービスを使用して Azure 仮想マシン (VM) 用のディザスター リカバリーをデプロイするときに使用されるアーキテクチャ、コンポーネント、プロセスについて説明します。 ディザスター リカバリーが設定されていると、Azure VM によって別のターゲット リージョンへのレプリケートが継続的に行われます。 障害が発生した場合は、セカンダリ リージョンに VM をフェールオーバーし、そこからそれらにアクセスできます。 すべてが再び正常に動作するようになったら、フェールバックして、プライマリの場所で作業を続行できます。
アーキテクチャ コンポーネント
Azure VM のディザスター リカバリーに関連するコンポーネントを次の表にまとめます。
| コンポーネント | 必要条件 |
|---|---|
| ソース リージョンの VM | サポートされているソース リージョン内の 1 つ以上の Azure VM。 VM は、サポートされているオペレーティング システムのうちのどれを実行していてもかまいません。 |
| ソース VM ストレージ | Azure VM では、マネージド ディスクでも、複数のストレージ アカウントに分散するアンマネージド ディスクでも使用できます。 サポートされる Azure ストレージについてはこちらをご覧ください。 |
| ソース VM ネットワーク | VM は、ソース リージョンの仮想ネットワーク (VNet) 内の 1 つまたは複数のサブネット内に存在できます。 ネットワークの要件についてはこちらをご覧ください。 |
| キャッシュ ストレージ アカウント | ソース ネットワークにはキャッシュ ストレージ アカウントが必要です。 レプリケーション中に、VM の変更は、ターゲット ストレージに送信される前に、キャッシュに格納されます。 キャッシュを使用することにより、VM で実行されている運用アプリケーションへの影響を最小限に抑えられます。 キャッシュ ストレージの要件について詳しくは、こちらをご覧ください。 |
| ターゲット リソース | ターゲット リソースは、レプリケーション中およびフェールオーバーの発生時に使用されます。 ターゲット リソースは、Site Recovery によって既定で設定することも、作成/カスタマイズすることもできます。 ターゲット リージョンでは、VM を作成できること、および必要な VM サイズをサポートするのに十分なリソースがサブスクリプションにあることを確認します。 |
ターゲット リソース
VM のレプリケーションを有効にすると、Site Recovery でターゲット リソースを自動的に作成できます。
| ターゲット リソース | 既定の設定 |
|---|---|
| ターゲット サブスクリプション | ソース サブスクリプションと同じです。 |
| ターゲット リソース グループ | フェールオーバー後に VM が所属するリソース グループです。 ソース リージョンを除く任意の Azure リージョンに作成できます。 Site Recovery では "asr" というサフィックスを持つターゲット リージョンに、新しいリソース グループが作成されます。 |
| ターゲット VNet | フェールオーバー後、レプリケートされた VM が配置される仮想ネットワーク (VNet) です。 ソース仮想ネットワークとターゲット仮想ネットワークの間にネットワーク マッピングが作成されます (または、その逆)。 Site Recovery では、"asr" というサフィックスを持つ新しい VNet とサブネットが作成されます。 |
| ターゲット ストレージ アカウント | VM でマネージド ディスクが使用されていない場合、このストレージ アカウントにデータがレプリケートされます。 Site Recovery によってターゲット リージョンに新しいストレージ アカウントが作成されて、ソース ストレージ アカウントがミラーリングされます。 |
| レプリカ マネージド ディスク | VM でマネージド ディスクが使用されている場合、このマネージド ディスクにデータがレプリケートされます。 Site Recovery によりストレージ リージョンにソースをミラーリングするレプリカ マネージド ディスクが作成されます。 |
| ターゲット可用性セット | フェールオーバー後、レプリケートされた VM が配置される可用性セット。 Site Recovery では、ソースの場所の可用性セットに配置されている VM 用に、"asr" というサフィックスでターゲット リージョンに可用性セットが作成されます。 可用性セットが存在する場合はそれが使用され、新しくは作成されません。 |
| ターゲット可用性ゾーン | ターゲット リージョンで可用性ゾーンがサポートされている場合、ソース リージョンと同じゾーン数が Site Recovery によって割り当てられます。 |
ターゲット リソースの管理
次のようにターゲット リソースを管理できます。
- レプリケーションを有効にするときに、ターゲットの設定を変更できます。 ターゲット リージョン VM の既定の SKU は、ソース VM SKU (または、ソース VM SKU と比較して、次に最適な使用できる SKU) と同じであることにご注意ください。 ドロップダウン リストには、ソースの VM と同じファミリの関連 SKU だけが表示されます (Gen 1 または Gen2)。
- レプリケーションが既に動作した後で、ターゲットの設定を変更できます。 ターゲット リソース グループ、ターゲット名などのその他のリソースと同様に、ターゲット リージョン VM SKU は、レプリケーションの進行後に更新することもできます。 可用性の種類 (1 つのインスタンス、セット、またはゾーン) は、更新できないリソースです。 この設定を変更するには、レプリケーションを無効にして、設定を変更し、再度有効にする必要があります。
Replication policy
既定では、Azure VM レプリケーションを有効にすると、Site Recovery によって次の表に示す既定の設定で新しいレプリケーション ポリシーが作成されます。
| ポリシーの設定 | 詳細 | [Default] |
|---|---|---|
| 復旧ポイントの保持期間 | Site Recovery で復旧ポイントを保持する長さを指定します。 | 1 日 |
| アプリ整合性スナップショットの頻度 | Site Recovery でアプリ整合性スナップショットを取得する頻度。 | 0 時間 (無効) |
レプリケーション ポリシーの管理
既定のレプリケーション ポリシーの設定を、次のように変更し、管理することができます。
- レプリケーションを有効にするときに、設定を変更できます。
- いつでもレプリケーション ポリシーを作成でき、レプリケーションを有効にするときに適用することができます。
Note
復旧ポイントのリテンション期間を長くすると、より多くの復旧ポイントを保存する必要が生じ、ストレージ コストに影響する可能性があります。
マルチ VM 整合性
複数の VM を一緒にレプリケートし、フェールオーバー時にクラッシュ整合性復旧ポイントとアプリ整合性復旧ポイントを共有する場合は、レプリケーション グループにまとめることができます。 マルチ VM 整合性はワークロードのパフォーマンスに影響を与えるので、すべてのマシン間で整合性を必要とするワークロードを実行している VM にのみ使用する必要があります。
スナップショットと復旧ポイント
復旧ポイントは、特定の時点で取得された VM のディスクのスナップショットから作成されます。 VM をフェールオーバーするときは、復旧ポイントを使用してターゲットの場所に VM を復元します。
フェールオーバーでは、通常、破損やデータ損失なしで VM が起動し、オペレーティング システムおよび VM で実行されるアプリについて VM のデータが一貫していることが必要です。 これは、作成されるスナップショットの種類に依存します。
Site Recovery では、次のようにスナップショットが作成されます。
- Site Recovery では、既定でデータのクラッシュ整合性スナップショットが作成され、ユーザーが頻度を指定するとアプリ整合性スナップショットが作成されます。
- 復旧ポイントはスナップショットから作成されて、レプリケーション ポリシーでの保持期間の設定に従って格納されます。
一貫性
次の表で、整合性の種類について説明します。
クラッシュ整合性
| 説明 | 詳細 | 推奨 |
|---|---|---|
| クラッシュ整合性スナップショットでは、スナップショットが作成されたときにディスクに存在していたデータがキャプチャされます。 メモリ内のものは含まれません。 スナップショットが作成された瞬間に VM がクラッシュしたり、電源コードがサーバーから抜かれたりした場合にディスク上に存在していたデータと同じものが含まれます。 クラッシュ整合性では、オペレーティング システムや VM 上のアプリのデータ整合性は保証されません。 |
Site Recovery では、既定で 5 分ごとにクラッシュ整合性復旧ポイントが作成されます。 この設定を変更することはできません。 |
現在、ほとんどのアプリでは、クラッシュ整合性ポイントから十分に復旧できます。 クラッシュ整合性復旧ポイントは、オペレーティング システム、および DHCP サーバーやプリント サーバーなどのアプリのレプリケーションに十分です。 |
アプリ整合性
| 説明 | 詳細 | 推奨 |
|---|---|---|
| アプリ整合性復旧ポイントは、アプリ整合性スナップショットから作成されます。 アプリ整合性スナップショットには、クラッシュ整合スナップショット内のすべての情報に加えて、メモリ内のすべてのデータと進行中のトランザクションが含まれます。 |
アプリ整合性スナップショットでは、ボリューム シャドウ コピー サービス (VSS) が使用されます。 1) Azure Site Recovery では、コピーのみのバックアップ (VSS_BT_COPY) 方法が使用されます。これは、Microsoft SQL のトランザクション ログのバックアップ時刻およびシーケンス番号を変更しません。 2) スナップショットが開始されると、VSS によってボリュームでコピーオンライト (COW) 操作が実行されます。 3) COW を実行する前、VSS はマシン上のすべてのアプリに、メモリ常駐データをディスクにフラッシュする必要があることを通知します。 4) その後、VSS は、バックアップ/ディザスター リカバリー アプリ (このケースでは Site Recovery) にスナップショット データを読み取って続行することを許可します。 |
アプリ整合性スナップショットはユーザーが指定した頻度に従って作成されます。 この頻度は常に、復旧ポイントを保持するための設定より短くする必要があります。 たとえば、復旧ポイントを既定の設定の 24 時間を使用して保持する場合、頻度を 24 時間未満に設定する必要があります。 クラッシュ整合性スナップショットより複雑で、完了に時間がかかります。 レプリケーションが有効な VM で実行されているアプリのパフォーマンスに影響します。 |
レプリケーション プロセス
Azure VM でレプリケーションを有効にすると、次のことが行われます。
- Site Recovery モビリティ サービス拡張機能が、VM に自動的にインストールされます。
- 拡張機能は、VM を Site Recovery に登録します。
- 継続的なレプリケーションが VM に対して開始されます。 ディスクへの書き込みは、ソースの場所のキャッシュ ストレージ アカウントにすぐに転送されます。
- キャッシュ内のデータは Site Recovery によって処理され、ターゲット ストレージ アカウントまたはレプリカ マネージド ディスクに送信されます。
- データが処理された後、クラッシュ整合性復旧ポイントが 5 分ごとに生成されます。 アプリ整合性復旧ポイントは、レプリケーション ポリシーで指定された設定に従って生成されます。
レプリケーション プロセス
接続の要件
レプリケートする Azure VM では、送信接続が必要です。 Site Recovery には、VM への受信接続は不要です。
送信接続 (URL)
VM の送信アクセスが URL で制御されている場合は、次の URL を許可します。
| 名前 | 商用 | 政府 | 説明 |
|---|---|---|---|
| ストレージ | *.blob.core.windows.net |
*.blob.core.usgovcloudapi.net |
ソース リージョンのキャッシュ ストレージ アカウントに、VM からデータが書き込まれるよう許可します。 |
| Microsoft Entra ID | login.microsoftonline.com |
login.microsoftonline.us |
Site Recovery サービス URL に対する承認と認証を提供します。 |
| レプリケーション | *.hypervrecoverymanager.windowsazure.com |
*.hypervrecoverymanager.windowsazure.us |
VM と Site Recovery サービスの通信を許可します。 |
| Service Bus | *.servicebus.windows.net |
*.servicebus.usgovcloudapi.net |
VM による Site Recovery の監視および診断データの書き込みを許可します。 |
| Key Vault | *.vault.azure.net |
*.vault.usgovcloudapi.net |
ADE が有効な仮想マシンのレプリケーションをポータルを介して有効にするためのアクセスを許可します |
| Azure Automation | *.automation.ext.azure.com |
*.azure-automation.us |
レプリケートされる項目に対してモビリティ エージェントの自動アップグレードをポータルを介して有効にすることを許可します |
IP アドレス範囲に対する送信接続
IP アドレスを使用して VM の送信接続を制御するには、次のアドレスを許可します。 ネットワーク接続要件の詳細については、ネットワークに関するホワイト ペーパーを参照してください。
ソース リージョンのルール
| Rule | 詳細 | サービス タグ |
|---|---|---|
| HTTPS の送信を許可する: ポート 443 | ソース リージョンのストレージ アカウントに対応する範囲を許可します | ストレージ。<リージョン名> |
| HTTPS の送信を許可する: ポート 443 | Microsoft Entra ID に対応する範囲を許可します | AzureActiveDirectory |
| HTTPS の送信を許可する: ポート 443 | ターゲットリージョンのイベントハブに対応する範囲を許可します。 | EventHub.<region-name> |
| HTTPS の送信を許可する: ポート 443 | Azure Site Recovery に対応する範囲を許可します。 | AzureSiteRecovery |
| HTTPS の送信を許可する: ポート 443 | Azure Key Vault に対応する範囲を許可します (これは、ADE が有効になっている仮想マシンのレプリケーションを、ポータルを介して有効にする場合にのみ必要です) | AzureKeyVault |
| HTTPS の送信を許可する: ポート 443 | Azure Automation コントローラーに対応する範囲を許可します (これは、レプリケートされる項目に対してモビリティ エージェントの自動アップグレードをポータルを介して有効にする場合にのみ必要です) | GuestAndHybridManagement |
ターゲット リージョンのルール
| Rule | 詳細 | サービス タグ |
|---|---|---|
| HTTPS の送信を許可する: ポート 443 | ターゲット リージョンのストレージ アカウントに対応する範囲を許可します。 | ストレージ。<リージョン名> |
| HTTPS の送信を許可する: ポート 443 | Microsoft Entra ID に対応する範囲を許可します | AzureActiveDirectory |
| HTTPS の送信を許可する: ポート 443 | ソースリージョンのイベントハブに対応する範囲を許可します。 | EventHub.<region-name> |
| HTTPS の送信を許可する: ポート 443 | Azure Site Recovery に対応する範囲を許可します。 | AzureSiteRecovery |
| HTTPS の送信を許可する: ポート 443 | Azure Key Vault に対応する範囲を許可します (これは、ADE が有効になっている仮想マシンのレプリケーションを、ポータルを介して有効にする場合にのみ必要です) | AzureKeyVault |
| HTTPS の送信を許可する: ポート 443 | Azure Automation コントローラーに対応する範囲を許可します (これは、レプリケートされる項目に対してモビリティ エージェントの自動アップグレードをポータルを介して有効にする場合にのみ必要です) | GuestAndHybridManagement |
ネットワーク セキュリティ グループ規則を使用してアクセスを制御する
ネットワーク セキュリティ グループ規則を使用して、Azure のネットワーク/サブネットが送受信するトラフィックをフィルタリングすることによって VM の接続を制御する場合、次の要件に注意してください。
- ソース Azure リージョンのネットワーク セキュリティ グループ規則では、レプリケーション トラフィックのアウトバウンド アクセスを許可する必要があります。
- 運用環境に配置する前に、テスト環境でルールを作成することをお勧めします。
- 個々の IP アドレスを許可するのではなく、サービス タグを使用します。
- サービス タグは IP アドレス プレフィックスのグループを表し、セキュリティ規則の作成の複雑さを最小限に抑えます。
- Microsoft は、時間の経過と共に、サービス タグを自動的に更新します。
詳しくは、Site Recovery のアウトバウンド接続に関する記事、およびネットワーク セキュリティ グループによる接続の制御に関する記事をご覧ください。
マルチ VM 整合性の接続
マルチ VM 整合性を有効にすると、レプリケーション グループ内のマシンは、ポート 20004 を介して相互に通信します。
- ポート 20004 経由での VM 間の内部通信をブロックするファイアウォール アプライアンスがないことを確認します。
- Linux VM をレプリケーション グループに含めるには、ポート 20004 の送信トラフィックが、特定の Linux バージョンのガイダンスに従って手動で開かれていることを確認します。
フェールオーバー プロセス
フェールオーバーの開始時、VM は、ターゲット リソース グループ、ターゲット仮想ネットワーク、ターゲット サブネット、およびターゲット可用性セットに作成されます。 フェールオーバー中は、任意の復旧ポイントを使用できます。
次のステップ
- Azure VM をセカンダリ リージョンに迅速にレプリケートします。