VMware HCX Mobility Optimized Networking (MON) のガイダンス

  • [アーティクル]

Note

VMware HCX Mobility Optimized Networking は、HCX バージョン 4.1.0 の VMware および Azure VMware Solution によって正式にサポートされています。

重要

HCX MON を有効にする前に、下の制限とサポートされていない構成をお読みください。

HCX NE のサポートされていないソース構成

MON を含む HCX 展開の制限事項

VMware HCX Mobility Optimized Networking (MON) は、サード パーティ ゲートウェイの使用ではサポートされていません。 ネットワーク仮想アプライアンス (NVA) なしで T0 ゲートウェイに直接接続されている T1 ゲートウェイでのみ使用できます。 この構成機能を作成することはできますが、サポートされていません。

HCX Mobility Optimized Networking (MON) は、HCX Network Extension (NE) を使用する場合に有効にする、オプションの機能です。 MON を使用すると、特定のシナリオで最適なトラフィック ルーティングが提供され、拡張ネットワーク上のオンプレミスとクラウドベースのリソース間のネットワーク トロンボーンが回避されます。

MON は NE 機能のエンタープライズ機能であるため、Azure portal を使用して VMware HCX Enterprise を有効にしてください。

移行サイクル全体を通して、MON を使用することで次のアプリケーション モビリティが最適化されます。

  • ストレッチ ネットワーク使用時の仮想マシン (VM) から VM L2 への通信の最適化

  • オンプレミス、Azure VMware Solution、Azure の間での非対称トラフィック フローの最適化と回避

この記事では、MON の Azure VMware Solution 固有のユース ケースについて説明します。

プライベート クラウド側で標準とストレッチのセグメント全体のトラフィック フローを最適化する

このシナリオでは、VM1 が NE を使用してクラウドに移行されます。これにより、VM から VM への最適な待機時間が提供されます。 その結果、VM1 からローカルの Azure VMware Solution セグメント上の VM3 までの低遅延が求められます。 トラフィックの最適なパス (青い線) を確保するために、VM1 ゲートウェイをオンプレミスから Azure VMware Solution (クラウド) に移行します。 ゲートウェイがオンプレミス (赤い線) のままである場合は、トロンボーン効果と待機時間の増加が観察されます。

Note

VM ゲートウェイをクラウド側に移行せずに MON を有効にしても、トラフィック フローの最適なパスは保証されません。 また、ポリシー ルートの評価もできません。

Diagram showing the optimization for VM to VM L2 communication when using stretched networks.

非対称トラフィック フローを最適化して回避する

このシナリオでは、オンプレミスの VM が Azure VMware Solution に移行され、L2 に参加し、L3 トラフィックがオンプレミスに戻ってサービスにアクセスすることを前提としています。 また、(Azure VMware Solution に接続された仮想ネットワーク内の) Azure からの VM 通信の一部が、Azure VMware Solution プライベート クラウドに到達する可能性があることを前提としています。

重要

ここでの要点は、非対称トラフィック フローを慎重に計画し、回避することです。

既定で MON を使用しない場合、MON を使用しないストレッチ ネットワーク上の Azure VMware Solution 内の VM は、ExpressRoute 優先パスを使用してオンプレミスと通信できます。 お客様のユース ケースに基づいて、MON で有効になっている Azure VMware Solution ストレッチ セグメント上の VM が、トラフィック フローを対称に保ちながら、ネットワーク拡張機能または ExpressRoute 経由の T0 ゲートウェイ経由でオンプレミスに戻る方法を評価する必要があります。

たとえば NE パスを選択する場合、MON ポリシー ルートは、オンプレミス側のサブネットを具体的にアドレス指定する必要があります。それ以外の場合は、0.0.0.0/0 の既定のルートが使用されます。 ポリシー ルートは、詳細を選択することで NE セグメントの下にあります。

既定では、すべての RFC 1918 IP アドレスが MON ポリシー ルート定義に含まれます。

Screenshot showing the egress traffic flow with default policy-based routes.

これにより、すべての RFC 1918 エグレス トラフィックが NE パス経由でトンネリングされ、すべてのインターネットおよびパブリック トラフィックが T0 ゲートウェイにルーティングされます。

Diagram showing the RFC 1918 egress and egress traffic flow.

ポリシー ルートは、VM ゲートウェイがクラウドに移行された場合にのみ評価されます。 この構成の効果は、宛先に一致するすべてのサブネットが NE アプライアンスを通してトンネリングされるという結果です。 一致しない場合は、T0 ゲートウェイ経由でルーティングされます。

Note

Azure VMware Solution で MON を使用する際の特別な考慮事項は、BGP を使用してアドバタイズされた /32 ルートをピアに提供することです。これには、オンプレミスおよび ExpressRoute 接続を使用した Azure が含まれます。 たとえば、Azure 上の VM は、Azure VMware Solution MON が有効なセグメント上の Azure VMware Solution VM へのパスを学習します。 リターン トラフィックが想定どおりに T0 ゲートウェイに送り返されると、リターン サブネットが RFC 1918 の一致である場合、トラフィックは T0 ではなく NE 経由で強制されます。 その後、ExpressRoute を使用してオンプレミス側の Azure へのエグレスが行われます。 これにより、中間および非対称のルーティング動作でステートフル ファイアウォールの混乱が発生する可能性があります。 また、NE MON セグメント上の VM が、Azure VMware Solution の T0 ゲートウェイを介して、または NE 経由でのみオンプレミスに戻って、インターネットにアクセスする方法を決定することをお勧めします。 一般に、非対称トラフィックを回避するには、すべての既定のポリシー ルートを削除する必要があります。 ネットワーク インフラストラクチャが、非対称トラフィックを考慮して防止するように構成されている場合にのみ、ポリシー ルートを有効にします。

MON ポリシー ルートは、定義されていない状態で削除できます。 これにより、すべてのエグレス トラフィックが T0 ゲートウェイにルーティングされます。

Screenshot showing the egress traffic flow with no policy-based routes.

MON ポリシー ルートは、既定のルート (0.0.0.0/0) で更新できます。 これにより、すべてのエグレス トラフィックが NE パス経由でトンネリングされます。

Screenshot showing the egress traffic flow with a 0.0.0.0/0 policy-based route.

上の図で説明したように、重要なのは、必要な各サブネットへのポリシー ルートを照合することです。 それ以外の場合、トラフィックは T0 経由でルーティングされ、NE 経由でトンネリングされません。

ポリシー ルートの詳細については、「Mobility Optimized Networking Policy Routes」(Mobility Optimized Networking ポリシー ルート) を参照してください。