Azure VMware Solution のネットワーク設計に関する考慮事項
Azure VMware Solution は、オンプレミスおよび Azure ベースの環境またはリソースからユーザーやアプリケーションがアクセスできる VMware プライベート クラウド環境を提供します。 Azure ExpressRoute や仮想プライベート ネットワーク (VPN) 接続などのネットワーク サービスが、接続性を提供します。
Azure VMware Solution 環境を設定する前に、ネットワークに関するいくつかの考慮事項を確認する必要があります。 この記事では、Azure VMware Solution を使用してネットワークを構成するときに発生する可能性があるユース ケースの解決策について説明します。
Azure VMware Solution と AS-Path プリペンドの互換性
Azure VMware Solution には、冗長な ExpressRoute 構成での AS-Path プリペンドの使用に関する考慮事項があります。 オンプレミスと Azure の間で 2 つ以上の ExpressRoute パスを実行している場合は、Azure VMware Solution から ExpressRoute GlobalReach 経由でオンプレミスに向かうトラフィックに与える影響について、次のガイダンスを考慮してください。
非対称ルーティングを原因とする接続性の問題は、Azure VMware Solution が AS-Path プリペンドを監視せず、等コスト マルチパス (ECMP) ルーティングを使用して両方の ExpressRoute 回線を介して環境にトラフィックを送信する場合に発生します。 この動作により、既存の ExpressRoute 回線の背後に配置されたステートフル ファイアウォール検査デバイスで問題が発生する可能性があります。
前提条件
AS-Path プリテンドの場合、次の前提事項を考慮してください。
- 重要なポイントは、パブリック ASN 番号を付加して、Azure VMware Solution がトラフィックをオンプレミスにルーティングする方法に影響を与える必要があるということです。 "プライベート" ASN を使用してプリテンドする場合、Azure VMware Solution ではそのプリテンドを無視し、前述の ECMP 動作が発生します。 オンプレミスでプライベート BGP ASN を運用している場合でも、Azure VMware Solution との互換性を確保するために、送信ルートでプリペンドするときに、パブリック ASN を利用するようにオンプレミス デバイスを構成できます。
- Azure VMware Solution によって受け入れられるようにするため、パブリック ASN の後にプライベート ASN がくるようにトラフィック パスを設計します。 Azure VMware Solution ExpressRoute 回線では、パブリック ASN の処理後にパスに存在するプライベート ASN は削除されません。
- 両方またはすべての回線が、Azure ExpressRoute Global Reach を介して Azure VMware Solution に接続されます。
- 同じ netblock が2つ以上の回線からアドバタイズされている。
- AS-Path プリペンドを使用して、Azure VMware Solution に別の回線よりも 1 つの回線を優先させることができます。
- 2 バイトまたは 4 バイトのパブリック ASN 番号を使用します。
管理 VM とオンプレミスからの既定のルート
重要
Azure VMware Solution 管理仮想マシン (VM) は、宛先が RFC1918 の場合、オンプレミスからの既定のルートを受け入れません。
Azure にアドバタイズされた既定のルートのみを使用してオンプレミス ネットワークに再度ルーティングする場合、vCenter Server と NSX Manager VM からプライベート IP アドレスが指定されたオンプレミスへ向けて使用されるトラフィックは、そのルートに従いません。
オンプレミスから vCenter Server および NSX Manager に到達するには、具体的なルートを指定して、トラフィックでそれらのネットワークへのリターン パスが使用されるようにします。 たとえば、RFC1918 の概要 (10.0.0.0/8、172.16.0.0/12、192.168.0.0/16) をアドバタイズします。
インターネット トラフィック検査のための Azure VMware Solution への既定のルート
特定のデプロイでは、Azure VMware Solution からインターネットへのすべてのエグレス トラフィックを検査する必要があります。 Azure VMware Solution でネットワーク仮想アプライアンス (NVA) を作成することはできますが、これらのアプライアンスが Azure に既に存在する場合は、Azure VMware Solution からのインターネット トラフィックを検査するために適用できるユース ケースがあります。 この場合、既定のルートを Azure の NVA から挿入して、Azure VMware Solution からのトラフィックを引き付け、パブリック インターネットに送信する前にトラフィックを検査することができます。
次の図は、ExpressRoute を介して Azure VMware Solution クラウドとオンプレミス ネットワークに接続された基本的なハブ アンド スポーク トポロジを示しています。 この図は、Azure の NVA が既定のルート (0.0.0.0/0) をどのように生成するかを示しています。 Azure Route Server は、ExpressRoute を介してルートを Azure VMware Solution に伝達します。
重要
NVA によってアドバタイズされた既定のルートは、オンプレミス ネットワークに伝達されます。 Azure VMware Solution からのトラフィックが NVA 経由で転送されるように、ユーザー定義ルート (UDR) を追加する必要があります。
「オンプレミス環境を Azure VMware Solution にピアリングする」で説明されているように、通常、Azure VMware Solution とオンプレミス ネットワーク間の通信は ExpressRoute Global Reach を介して行われます。
Azure VMware Solution とオンプレミス ネットワークの間の接続性
サード パーティーの NVA を介した Azure VMware Solution とオンプレミス ネットワークの間の接続性に関するシナリオは、主に次の 2 つがあります。
- 組織が、NVA (通常はファイアウォール) を介して Azure VMware Solution とオンプレミス ネットワークの間でトラフィックを送信する必要がある。
- 特定のリージョンで、Azure VMware Solution の ExpressRoute 回線とオンプレミス ネットワークを相互接続するために、ExpressRoute Global Reach を使用できない。
これらのシナリオのすべての要件を満たすために適用できるトポロジは、スーパーネットとトランジット スポーク仮想ネットワークの 2 つがあります。
重要
Azure VMware Solution およびオンプレミス環境に接続する場合の推奨されるオプションは、ExpressRoute Global Reach の直接接続です。 この記事で説明するパターンによって、環境が複雑になります。
スーパーネット設計トポロジ
両方の ExpressRoute 回線 (Azure VMware Solution に対するものと、オンプレミスに対するもの) が同じ ExpressRoute ゲートウェイで終了している場合、ゲートウェイによってそれらの間でパケットがルーティングされると想定できます。 しかし、ExpressRoute ゲートウェイは、それを行うようには設計されていません。 トラフィックをルーティングできる NVA にトラフィックを折り返す必要があります。
ネットワーク トラフィックを NVA へ折り返すには、次の 2 つの要件があります。
NVA は、Azure VMware Solution とオンプレミスのプレフィックスのスーパーネットをアドバタイズする必要があります。
Azure VMware Solution とオンプレミスの両方のプレフィックスを含むスーパーネットを使用できます。 または Azure VMware Solution とオンプレミスの個別のプレフィックスを使用できます (常に ExpressRoute 経由でアドバタイズされる実際のプレフィックスほど具体的ではありません)。 Route Server にアドバタイズされるすべてのスーパーネット プレフィックスは、Azure VMware Solution とオンプレミスの両方に伝達されることに留意してください。
Azure VMware Solution とオンプレミスからアドバタイズされたプレフィックスと正確に一致するゲートウェイ サブネット内の UDR が、ゲートウェイ サブネットから NVA へトラフィックを折り返します。
このトポロジにより、時間の経過と伴って変化する大規模なネットワークの管理オーバーヘッドが増加します。 次の制限事項を考慮してください。
- Azure VMware Solution でワークロード セグメントが作成されるたびに、Azure VMware Solution からのトラフィックが NVA 経由で通過されるように UDR を追加する必要がある場合があります。
- オンプレミス環境で多数のルートが変更されている場合は、スーパーネット内の Border Gateway Protocol (BGP) と UDR の構成を更新する必要がある場合があります。
- 1 つの ExpressRoute ゲートウェイが双方向のネットワーク トラフィックを処理するため、パフォーマンスが制限される可能性があります。
- Azure Virtual Network の UDR は 400 個に制限されています。
次の図は、NVA が、オンプレミスと Azure VMware Solution のネットワークを含む、より汎用的な (あまり具体的ではない) プレフィックスをアドバタイズする必要があることを示しています。 このアプローチには注意してください。 NVA は、より広い範囲 (10.0.0.0/8 ネットワーク全体など) をアドバタイズしているため、本来避けるべきトラフィックを引き付ける可能性があります。
トランジット スポーク仮想ネットワーク トポロジ
Note
前述の制限により、あまり具体的でないプレフィックスをアドバタイズできない場合は、2 つの個別の仮想ネットワークを使用する代替設計を実装できます。
このトポロジでは、トラフィックを ExpressRoute ゲートウェイに引き付けるためにあまり具体的でないルートを伝達するのではなく、別々の仮想ネットワーク内の 2 つの異なる NVA が相互にルートを交換できます。 仮想ネットワークは、BGP と Azure Route Server を介して、これらのルートをそれぞれの ExpressRoute 回線に伝達できます。 各 NVA では、それぞれの ExpressRoute 回線に伝達されるプレフィックスを完全に制御できます。
次の図は、単一の 0.0.0.0/0 ルートが Azure VMware Solution にアドバタイズされる方法を示しています。 また、個々の Azure VMware Solution プレフィックスがオンプレミス ネットワークに伝達される方法も示します。
重要
NVA 間には VXLAN や IPsec などの何らかのカプセル化プロトコルが必要です。 NVA ネットワーク アダプター (NIC) がネクスト ホップとして NVA を使用して Azure Route Server からのルートを学習し、ルーティング ループを作成するため、カプセル化が必要になります。
オーバーレイの代替手段もあります。 Azure Route Server からのルートを学習しないセカンダリ NIC を NVA に適用します。 次に、Azure がその NIC 上でリモート環境にトラフィックをルーティングできるように UDR を構成します。 詳細については、Azure VMware Solution のエンタープライズ規模のネットワーク トポロジと接続に関する記事を参照してください。
このトポロジには、複雑な初期設定が必要です。 その後、トポロジは期待どおりに動作し、管理オーバーヘッドを最小限に抑えることができます。 次の点で、設定が複雑になります。
- Azure Route Server、ExpressRoute ゲートウェイ、および別の NVA を含む別のトランジット仮想ネットワークを追加するために、追加のコストがかかります。 NVA では、スループット要件を満たすために大きな VM サイズを使用する必要がある場合もあります。
- 2 つの NVA 間には IPSec または VxLAN トンネリングが必要です。つまり、NVA もデータパスに存在します。 使用している NVA の種類によっては、それらの NVA に対するカスタム構成と複雑な構成が発生する可能性があります。
次のステップ
Azure VMware Solution のネットワーク設計に関する考慮事項について学習したら、次の記事を参照するようにしてください。