SDN マルチサイトとは
適用対象: Azure Local バージョン 23H2
適用対象: Windows Server 2025
この記事では、SDN マルチサイトの概要について説明します。これには、その利点と現在の制限事項が含まれます。 これをガイドとして使用して、ネットワーク トポロジとディザスター リカバリー計画を設計できます。
SDN マルチサイトを使用すると、さまざまな物理的な場所にデプロイされた従来の SDN の機能を拡張できます。 SDN マルチサイトを使用すると、仮想化されたワークロードに対して、異なる物理的な場所でネイティブレイヤー 2 とレイヤー 3 の接続が可能になります。 この記事では、サイトへのすべての参照は物理的な場所を意味します。
メリット
SDN マルチサイトを使用する利点を次に示します。
- 統合ポリシー管理システム。 共有仮想ネットワークとポリシー構成を使用すると、任意のサイトからマルチサイト ネットワークを管理および構成できます。
- シームレスなワークロード移行。 IP アドレスを再構成したり、既存のネットワーク セキュリティ グループ (NSG) を作成したりすることなく、物理サイト間でワークロードをシームレスに移行できます。
- 新しい VM への自動到達可能性。 仮想ネットワーク上で新しく作成された仮想マシン (VM) に対する自動到達可能性と、物理的な場所にまたがる関連する NSG への自動管理を実現します。
制限事項
現在、SDN マルチサイト機能にはいくつかの制限があります。
- 2 つのサイト間でのみサポートされます。
- インターネット経由で接続されているサイトの暗号化サポートは提供されていないため、サイトはプライベート ネットワーク経由で接続する必要があります。
- 内部負荷分散はクロスサイトではサポートされていません。
マルチサイト ピアリング
マルチサイトでは、仮想ネットワーク ピアリングのように開始されるサイト間のピアリングが必要です。 両方のサイトで Windows Admin Center 経由で接続が自動的に開始されます。 接続が確立されると、ピアリングが成功します。 ピアリングを確立する方法については、「ピアリングの確立を参照してください。
マルチサイトでは、仮想ネットワーク ピアリングのように開始されるサイト間のピアリングが必要です。 両方のサイトで Windows Admin Center 経由で接続が自動的に開始されます。 接続が確立されると、ピアリングが成功します。 ピアリングを確立する方法については、「ピアリングの確立を参照してください。
以降のセクションでは、マルチサイト環境内の各サイトの役割と、サイト間でのリソースの処理方法と同期方法について説明します。
プライマリ サイトとセカンダリ サイトの役割
マルチサイト SDN 環境では、1 つのサイトがプライマリとして、もう 1 つのサイトがセカンダリとして指定されます。 プライマリ サイトはリソースの同期を処理します。 マルチサイト ピアリング中にプライマリ サイトが自動的に選択され、後で Windows Admin Center を使用して変更できます。
リソースの処理
プライマリ サイトに到達できない場合、グローバル検証またはグローバルカスタマー アドレス (CA) の割り当てを必要とするグローバル リソースとリソースは、セカンダリ サイト経由で更新できません。 ただし、他のローカル リソースはセカンダリ サイトを介して更新できます。
グローバル検証を必要とするリソースの例を次に示します。
- MAC プール。
- 論理ネットワーク/IP プール。
グローバル CA 割り当ての例を次に示します。
- 仮想サブネットの内部負荷分散。 現時点では、これはマルチサイトではサポートされていません。
- 仮想サブネットのゲートウェイ接続。
セカンダリ サイトに到達できない場合は、プライマリ サイトを介してリソースを更新できます。 ただし、接続が復元されるまで、セカンダリ サイトに古いリソースが含まれている可能性があります。 接続が復元されると、同期が再開されます。
プライマリ サイトがダウンした場合は、セカンダリ サイトを新しいプライマリ サイトとして指定して、ネットワーク セキュリティ グループと仮想ネットワークの更新を実行できます。 ただし、古いプライマリ サイトからの保留中のデータ同期は失われます。 この問題に対処するには、古いプライマリ サイトがオンラインに戻ったら、それらの同じ変更を新しいプライマリ サイトに適用します。 ただし、グローバル CA 割り当ての競合につながる可能性もあります。
リソースの同期
SDN マルチサイトを有効にすると、各サイトのすべてのリソースがすべてのサイトで同期されるわけではありません。 同期され、同期されていないリソースの一覧を次に示します。
同期されたリソース
これらのリソースは、ピアリングが確立された後、すべてのサイトで同期されます。 これらのリソースは、プライマリでもセカンダリでも、任意のサイトから更新できます。 ただし、プライマリ サイトは、これらのリソースがサイト間で適用および同期されるようにする役割を担います。 これらのリソースを管理するためのガイドラインと手順は、単一サイトの SDN 環境と同じです。
- 仮想ネットワーク。 仮想ネットワークを管理する方法については、「テナント仮想ネットワークの管理を参照してください。 論理ネットワークはサイト間で同期されません。 ただし、仮想ネットワークが論理ネットワークを参照している場合は、同じ名前の論理ネットワークが両方のサイトに存在する必要があります。
- ネットワーク セキュリティ グループ (NSG) 。 Windows Admin Center と PowerShell を使用して NSG を構成する方法については、「 ネットワーク セキュリティ グループを Windows Admin Center で構成する および PowerShell でネットワーク セキュリティ グループを構成する するを参照してください。
- ユーザー定義のルーティング。 ユーザー定義ルーティングの使用方法については、「 仮想ネットワーク上のネットワーク仮想アプライアンスを使用する」を参照してください。
同期されたリソース
これらのリソースは、ピアリングが確立された後、すべてのサイトで同期されます。 これらのリソースは、プライマリでもセカンダリでも、任意のサイトから更新できます。 ただし、プライマリ サイトは、これらのリソースがサイト間で適用および同期されるようにする役割を担います。 これらのリソースを管理するためのガイドラインと手順は、単一サイトの SDN 環境と同じです。
- 仮想ネットワーク。 仮想ネットワークを管理する方法については、「テナント仮想ネットワークの管理を参照してください。 論理ネットワークはサイト間で同期されません。 ただし、仮想ネットワークが論理ネットワークを参照している場合は、同じ名前の論理ネットワークが両方のサイトに存在する必要があります。
- ネットワーク セキュリティ グループ (NSG) 。 Windows Admin Center と PowerShell を使用して NSG を構成する方法については、「 ネットワーク セキュリティ グループを Windows Admin Center で構成する および PowerShell でネットワーク セキュリティ グループを構成する するを参照してください。
- ユーザー定義のルーティング。 ユーザー定義ルーティングの使用方法については、「 仮想ネットワーク上のネットワーク仮想アプライアンスを使用する」を参照してください。
同期されていないリソース
ピアリングが確立された後、これらのリソースは同期されません。
- 負荷分散ポリシー。
- 仮想 IP アドレス (VIP)。
- ゲートウェイ ポリシー。
- 論理ネットワーク。 論理ネットワークはサイト間で同期されませんが、IP プールで重複がチェックされ、その重複は許可されません。
これらのポリシーはローカル サイトに作成されます。他のサイトで同じポリシーが必要な場合は、手動で作成する必要があります。 負荷分散ポリシー用のバックエンド VM が 1 つのサイトに配置されている場合、SLB 経由の接続は、追加の構成なしで正常に動作します。 ただし、バックエンド VM が 1 つのサイトから別のサイトに移動することが予想される場合、既定では、接続はローカル サイトの VIP の背後にバックエンド VM がある場合にのみ機能します。 すべてのバックエンド VM が別のサイトに移動すると、その VIP 経由の接続は失敗します。
東西トラフィック フローとサブネット共有
マルチサイトを使用すると、SDN がデプロイされた異なるサイト上の VM は、SDN ゲートウェイ接続を設定しなくても、同じサブネット経由で通信できます。 これにより、ネットワーク トポロジが簡略化され、より多くの VM とサブネットの必要性が軽減されます。 異なるサイト上の VM 間のデータ パスは、基になる物理インフラストラクチャに依存します。
次のシナリオでは、従来の SDN セットアップと SDN マルチサイト セットアップの 2 つの物理サイト間で VM 通信がどのように確立されるかを比較します。
SDN マルチサイトを使用しない VM 間の通信
2 つの物理サイトに SDN をデプロイした従来のセットアップでは、サイト間通信のために L3 または GRE ゲートウェイ接続を確立する必要があります。 また、アプリケーションにさらにサブネットを提供する必要があります。 たとえば、各サイトがフロントエンド アプリケーションをホストする場合は、10.1/16 や 10.6/16 などの個別のサブネット範囲を割り当てます。 さらに、ゲートウェイ接続を設定する場合は、ゲートウェイ VM にさらに VM を割り当てて、その後管理する必要もあります。
SDN マルチサイトとの VM 間通信
2 つの物理的な場所にまたがる SDN マルチサイトを使用すると、サイト間通信用のネイティブレイヤー 2 接続を使用できます。 これにより、両方の場所にまたがるアプリケーションに 1 つのサブネット範囲を設定できるため、SDN ゲートウェイ接続を設定する必要がなくなります。 たとえば、次の図に示すように、両方の場所のフロントエンド アプリケーションでは、2 つの個別のサブネットを維持する代わりに、同じサブネット (10.1/16 など) を使用できます。 このセットアップにより、ある VM から別の VM へのデータ フローは、基になる物理インフラストラクチャのみに依存するため、別の SDN ゲートウェイ VM を走査する必要がなくなります。
ソフトウェア ロード バランサーとその制限事項
現在、ソフトウェア ロード バランサーは各物理サイトのローカル リソースです。 つまり、負荷分散ポリシーと構成は、マルチサイトを介してサイト間で同期されません。 SDN マルチサイトセットアップで VM をある場所から別の場所に移行する場合は、この点に注意してください。
SDN マルチサイトでの負荷分散: シナリオの例
次のセクションでは、ワークロード VM の有無と移行の両方を示すシナリオ例を通じて、マルチサイトでの負荷分散について説明します。 SDN マルチサイトが有効になっている 2 つの Azure Local インスタンスがあり、それぞれに独自の SDN インフラストラクチャがデプロイおよび構成されているとします。 このシナリオでは、クライアントは IP アドレス 10.0.0.5 と VIP が 11.0.0.5 の VM1 に到達する必要があります。
ワークロード VM を移行しない SDN マルチサイトでの負荷分散
SDN マルチサイトでは、場所間に VM の移行がない場合、従来の SDN セットアップと同様に、通常どおりデータ パケットが転送されます。 次のアニメーションは、クラスター 2 の SLB MUX1 を介してクライアント コンピューターから VM1 へのデータ パスを示しています。
ワークロード VM の移行による SDN マルチサイトでの負荷分散
1 つの VM または VIP の背後にあるすべての VM を別のサイトに移行する場合、アクセスしようとしている VM が場所によっては VIP 経由で到達不能になる場合があります。 これは、ロード バランサーリソースが各 Azure Local インスタンスに対してローカルであるために発生します。 ワークロード VM が移動すると、MUXes 上の構成はグローバルではなく、他のサイトでは移行が認識されません。 次のアニメーションは、クラスター 2 からクラスター 1 への VM の移行と、移行後にデータ パケットのパスが失敗する方法を示しています。
この制限を回避するには、外部ロード バランサーを使用して、各サイト上のバックエンド VM の可用性を確認し、それに応じてトラフィックをルーティングします。 ワークロード VM の移行 マルチサイトでの外部ロード バランサーの使用に関するページを参照してください。
ワークロード VM の移行でマルチサイトで外部ロード バランサーを使用する
外部ロード バランサーを有効にして、いずれかのサイトでロード バランサーの背後にバックエンド VM があるかどうかを確認できます。 ロード バランサーの背後にバックエンド VM がない場合、MUX の VIP は外部ロード バランサーにアドバタイズされず、送信された正常性プローブは失敗します。 この外部ロード バランサーは、VM がサイト間を移動した場合でも、ワークロードへの接続を保証します。
ただし、外部ロード バランサーをデプロイできない場合は、「ワークロード VM を移行せずに SDN マルチサイトで 負荷分散を行う」の説明に従って、ソフトウェア負荷分散ソリューションを使用します ワークロード VM を移行する必要はありません。
ゲートウェイとその制限事項
SDN マルチサイトでは、サイト間のゲートウェイ接続などのローカル リソースは同期されません。 各サイトには、独自のゲートウェイ VM とゲートウェイ接続があります。 ワークロード VM が作成またはサイトに移行されると、ゲートウェイ ルートなどのローカル ゲートウェイ構成が取得されます。 あるサイトで特定の仮想ネットワークのゲートウェイ接続を作成した場合、そのサイトの VM は、他のサイトへの移行時にゲートウェイ接続を失います。 VM が移行時にゲートウェイ接続を保持するには、他のサイトの同じ仮想ネットワークに対して個別のゲートウェイ接続を構成する必要があります。