Azure 仮想マシン ディザスター リカバリーでのネットワークの概要

  • [アーティクル]

この記事では、Azure Site Recovery を使用してリージョン間で Azure 仮想マシンをレプリケートするときの、プラットフォーム接続性のためのネットワーク ガイダンスについて説明します。

開始する前に

このシナリオに対して、Site Recovery でどのようにディザスター リカバリーを提供するかについて説明します。

一般的なネットワーク インフラストラクチャ

次のダイアグラムは、Azure 仮想マシンで実行しているアプリケーションの一般的な Azure 環境を示しています。

Azure 仮想マシンで実行されるアプリケーションの一般的な Azure 環境を示すダイアグラム。

オンプレミス ネットワークから Azure への接続に Azure ExpressRoute または VPN 接続を使用している場合、環境は次のようになります。

customer-environment

通常、ネットワークは、ファイアウォールやネットワーク セキュリティ グループ (NSG) を使用して保護されます。 ネットワーク接続を制御するには、サービス タグを使用する必要があります。 NSG では、送信接続を制御するために複数のサービス タグを許可する必要があります。

重要

認証済みプロキシを使用してネットワーク接続を制御することは、Site Recoery ではサポートされておらず、レプリケーションを有効にすることはできません。

注意

  • IP アドレス ベースのフィルター処理を実行して、送信接続を制御することはできません。
  • 送信接続を制御するために Azure Site Recovery IP アドレスを Azure ルーティング テーブルに追加しないでください。

URL に対する送信接続

送信接続を制御するために URL ベースのファイアウォール プロキシを使用している場合、以下の Site Recovery の URL を許可してください。

URL 詳細
*.blob.core.windows.net 仮想マシンからソース リージョンのキャッシュ ストレージ アカウントにデータを書き込むことができるようにするために必要です。 お使いの仮想マシンのすべてのキャッシュ ストレージ アカウントを把握している場合、*.blob.core.windows.net ではなく、特定のストレージ アカウントの URL (例: cache1.blob.core.windows.net と cache2.blob.core.windows.net) へのアクセスを許可することができます
login.microsoftonline.com Site Recovery サービス URL に対する承認と認証に必要です。
*.hypervrecoverymanager.windowsazure.com 仮想マシンから Site Recovery サービス通信を実行できるようにするために必要です。
*.servicebus.windows.net 仮想マシンから Site Recovery の監視および診断データを書き込むことができるようにするために必要です。
*.vault.azure.net ADE が有効な仮想マシンのレプリケーションをポータルを介して有効にするためのアクセスを許可します
*.automation.ext.azure.com レプリケートされる項目に対してモビリティ エージェントの自動アップグレードをポータルを介して有効にすることを許可します

サービスタグを使用した送信接続

URL の制御とは別に、サービス タグを使用して接続を制御することもできます。 これを行うには、まず、Azure 内でネットワーク セキュリティ グループ を作成する必要があります。 作成したら、既存のサービス タグを使用し、Azure Site Recovery サービスへのアクセスを許可する NSG ルールを作成する必要があります。

サービス タグを使用して接続を制御する利点は、IP アドレスを使用した接続の制御と比べ、特定の IP アドレスに対するハードの依存関係なしで、サービスへの接続を維持できることです。 このようなシナリオでは、いずれかのサービスの IP アドレスが変更されても、お使いのマシンに対して実行中のレプリケーションは影響を受けません。 一方、ハード コーディングされた IP アドレスに対する依存関係があると、レプリケーションの状態がクリティカルになり、システムが危険にさらされます。 さらに、サービス タグを使用すると、ハード コーディングされた IP アドレスより優れたセキュリティ、安定性、回復性が保証されます。

NSG を使用して送信接続を制御すると同時に、次のサービス タグを許可する必要があります。

  • ソース リージョンのストレージ アカウントの場合:
    • ソース リージョンに対してストレージ サービス タグに基づく NSG ルールを作成します。
    • 仮想マシンからキャッシュ ストレージ アカウントにデータを書き込むことができるように、これらのアドレスを許可します。
  • Microsoft Entra ID に対応するすべての IP アドレスへのアクセスを許可するには、Microsoft Entra サービス タグ ベースの NSG 規則を作成します。
  • EventsHub サービス タグ ベースの NSG ルールをターゲット リージョンに対して作成し、Site Recovery 監視へのアクセスを許可します。
  • 任意のリージョンでの Site Recovery サービスへのアクセスを許可するために、Azure Site Recovery サービス タグ ベースの NSG ルールを作成します。
  • AzureKeyVault サービス タグ ベースの NSG ルールを作成します。 これは、ADE が有効になっている仮想マシンのレプリケーションを、ポータルを介して有効にする場合にのみ必要です。
  • GuestAndHybridManagement サービス タグ ベースの NSG ルールを作成します。 これは、レプリケートされる項目に対してモビリティ エージェントの自動アップグレードをポータルを介して有効にする場合にのみ必要です。
  • 必要な NSG ルールをテスト NSG に作成し、問題がないことを確認してから、運用環境の NSG にルールを作成することをお勧めします。

NSG 構成の例

この例は、レプリケートする仮想マシンに対して NSG ルールを構成する方法を示しています。

  • NSG ルールを使用して送信接続を制御している場合は、必要なすべての IP アドレス範囲のポート 443 に対して "HTTPS 送信を許可" ルールを使用します。
  • この例では、仮想マシン ソースの場所は "米国東部" であり、ターゲットの場所は "米国中部" であるとします。

NSG ルール - 米国東部

  1. 次のスクリーンショットで示すように、NSG 上の "Storage.EastUS" に対して送信方向の HTTPS (443) セキュリティ規則を作成します。

    Storage.EastUS のネットワーク セキュリティ グループの [送信セキュリティ規則の追加] を示すスクリーンショット。

  2. 次のスクリーンショットで示すように、NSG 上の "AzureActiveDirectory" に対して送信方向の HTTPS (443) セキュリティ規則を作成します。

    Microsoft Entra ID のネットワーク セキュリティ グループの [送信セキュリティ規則の追加] を示すスクリーンショット。

  3. 上記のセキュリティ規則と同様に、ターゲットの場所に対応する NSG 上の "EventHub.CentralUS" に対して送信方向の HTTPS (443) セキュリティ規則を作成します。 これにより、Site Recovery 監視にアクセスできるようになります。

  4. NSG 上の "Azure Site Recovery" に対して送信方向の HTTPS (443) セキュリティ規則を作成します。 これにより、任意のリージョンの Site Recovery Service にアクセスできます。

NSG ルール - 米国中部

フェールオーバー後にターゲット リージョンからソース リージョンへのレプリケーションが有効になるようにするには、次のルールが必要です。

  1. NSG 上の "Storage.CentralUS" に対して、送信方向の HTTPS (443) セキュリティ ルールを作成します。

  2. NSG 上の "AzureActiveDirectory" に対して送信方向の HTTPS (443) セキュリティ規則を作成します。

  3. セキュリティ規則と同様に、ソースの場所に対応する NSG 上の "EventHub.EastUS" に対して送信方向の HTTPS (443) セキュリティ規則を作成します。 これにより、Site Recovery 監視にアクセスできるようになります。

  4. NSG 上の "Azure Site Recovery" に対して送信方向の HTTPS (443) セキュリティ規則を作成します。 これにより、任意のリージョンの Site Recovery Service にアクセスできます。

ネットワーク仮想アプライアンスの構成

ネットワーク仮想アプライアンス (NVA) を使って仮想マシンからの送信方向のネットワーク トラフィックを制御する場合、すべてのレプリケーション トラフィックが NVA を通過すると、アプライアンスが調整される可能性があります。 レプリケーション トラフィックが NVA に送られないように、"ストレージ" 用の仮想ネットワーク内にネットワーク サービス エンドポイントを作成することをお勧めします。

ストレージ用のネットワーク サービス エンドポイントを作成する

レプリケーション トラフィックが Azure 境界から外に出ないように、"ストレージ" 用の仮想ネットワーク内にネットワーク サービス エンドポイントを作成することができます。

  • お使いの Azure 仮想ネットワークを選択し、[サービス エンドポイント] を選択します。

    storage-endpoint

  • [追加] を選択して、[サービス エンドポイントの追加] タブを開きます。

  • [サービス] で Microsoft.Storage、[サブネット] フィールドで必要なサブネットを選択して、[追加] を選択します。

Note

ファイアウォールが有効なキャッシュ ストレージ アカウントまたはターゲット ストレージ アカウントを使用している場合は必ず、'信頼できる Microsoft サービスを許可' してください。 また、ソース Vnet の少なくとも 1 つ以上のサブネットにアクセスできることを確認してください。

強制トンネリング

0.0.0.0/0 アドレス プレフィックスの Azure の既定のシステム ルートを カスタム ルートでオーバーライドし、VM トラフィックをオンプレミス ネットワーク仮想アプライアンス (NVA) に転送することもできますが、この構成は Site Recovery レプリケーションにはお勧めしません。 カスタム ルートを使用している場合、レプリケーション トラフィックが Azure 境界から外に出ないように、"ストレージ" 用の仮想ネットワーク内に仮想ネットワーク サービス エンドポイントを作成することをお勧めします。

次のステップ