Leitfaden zu VMware HCX Mobility Optimized Networking (MON)

Hinweis

VMware HCX Mobility Optimized Networking wird offiziell von VMware und Azure VMware Solution von HCX Version 4.1.0 unterstützt.

Wichtig

Bevor Sie HCX MON aktivieren, lesen Sie die folgenden Informationen über Einschränkungen und nicht unterstützte Konfigurationen:

Für HCX NE nicht unterstützte Quellkonfigurationen

Einschränkungen für alle HCX-Bereitstellungen einschließlich MON

VMware HCX Mobility Optimized Networking (MON) wird mit der Verwendung eines Drittanbietergateways nicht unterstützt. Es kann nur mit dem T1-Gateway verwendet werden, das direkt mit dem T0-Gateway verbunden ist, ohne dass eine virtuelle Anwendung (Network Virtual Anwendung, NVA) erforderlich ist. Möglicherweise können Sie diese Konfigurationsfunktion erstellen, aber wir unterstützen sie nicht.

HCX Mobility Optimized Networking (MON) ist ein optionales Feature, das bei Verwendung von HCX Network Extensions (NE) aktiviert werden kann. MON bietet in bestimmten Szenarien ein optimales Routing des Datenverkehrs, um den Posauneneffekt für das Netzwerk zwischen lokalen und cloudbasierten Ressourcen in erweiterten Netzwerken zu verhindern.

Da MON eine Unternehmensfunktion des NE-Features ist, stellen Sie sicher, dass Sie das VMware HCX Enterprise über die Azure-Portal aktiviert haben.

Während des gesamten Migrationszyklus optimiert MON die Anwendungsmobilität für Folgendes:

• Optimieren der Kommunikation zwischen virtuellen Computern (VM) und VM L2 bei Verwendung von Stretchingnetzwerken

• Optimieren und Vermeiden asymmetrischer Datenverkehrsflüsse zwischen lokalen Standorten, Azure VMware Solution und Azure

In diesem Artikel erfahren Sie mehr über die azure VMware Solution-spezifischen Anwendungsfälle für MON.

Optimieren von Datenverkehrsflüssen über Standard- und Stretchingsegmente auf der Seite der privaten Cloud

In diesem Szenario wird VM1 mithilfe der NE in die Cloud migriert, was eine optimale VM-zu-VM-Latenz bietet. Daher benötigt VM1 eine geringe Latenz zu VM3 im lokalen Azure VMware Solution-Segment. Wir migrieren das VM1-Gateway vom lokalen Standort zu Azure VMware Solution (Cloud), um einen optimalen Pfad für den Datenverkehr (blaue Linie) sicherzustellen. Wenn das Gateway am lokalen Standort verbleibt (rote Linie), werden ein Posauneneffekt und eine höhere Latenz beobachtet.

Hinweis

Wenn Sie MON aktivieren, ohne das VM-Gateway zur Cloud zu migrieren, wird kein optimaler Pfad für den Datenverkehrsfluss sichergestellt. Außerdem ist die Auswertung von Richtlinienrouten nicht zulässig.

Optimieren und Vermeiden asymmetrischer Datenverkehrsflüsse

In diesem Szenario wird davon ausgegangen, dass ein virtueller Computer von der lokalen Bereitstellung zu Azure VMware Solution migriert wird und an L2 teilnimmt, und L3-Datenverkehr fließt zurück zur lokalen Umgebung, um auf Dienste zuzugreifen. Wir gehen auch davon aus, dass eine VM-Kommunikation von Azure (im mit Azure VMware Solution verbundenen virtuellen Netzwerk) in die private Azure VMware Solution-Cloud gelangen könnte.

Wichtig

Hier geht es vor allem darum, asymmetrische Verkehrsdatenflüsse sorgfältig zu planen und zu vermeiden.

Standardmäßig und ohne Verwendung von MON kann eine VM in Azure VMware Solution in einem Stretchingnetzwerk ohne MON über den bevorzugten ExpressRoute-Pfad wieder mit dem lokalen Standort kommunizieren. Basierend auf Kundennutzungsfällen sollte man bewerten, wie ein virtueller Computer in einem mit MON aktivierten Azure VMware-Lösungssegment sowohl über die Netzwerkerweiterung als auch das T0-Gateway über expressRoute durchlaufen und gleichzeitig symmetrisch datenverkehrssymmetrisch bleibt.

Wenn Sie z. B. den NE-Pfad auswählen, müssen die MON-Richtlinienrouten das Subnetz speziell auf der lokalen Seite adressieren. andernfalls wird die Standardroute 0.0.0.0/0 verwendet. Richtlinienrouten finden Sie unter dem NE-Segment, indem Sie "Erweitert" auswählen.

Standardmäßig sind alle RFC 1918-IP-Adressen in der MON-Richtlinienroutendefinition enthalten.

Dies führt dazu, dass alle RFC 1918-Ausgangsdaten über den NE-Pfad getunnelt werden und alle Internet- und öffentlichen Datenverkehr an das T0-Gateway weitergeleitet werden.

Richtlinienrouten werden nur ausgewertet, wenn das VM-Gateway in die Cloud migriert wird. Diese Konfiguration bewirkt, dass alle übereinstimmenden Subnetze für das Ziel über die NE-Appliance getunnelt werden. Wenn keine Übereinstimmung besteht, werden sie über das T0-Gateway weitergeleitet.

Hinweis

Ein besonderer Aspekt bei der Verwendung von MON in Azure VMware Solution besteht darin, den Peers die /32-Routen, die über BGP angekündigt werden, zu gewähren. Dies schließt lokale und Azure-Verbindungen über die ExpressRoute-Verbindung ein. Beispielsweise lernt eine VM in Azure den Pfad zu einer Azure VMware Solution-VM auf einem für MON-aktiviertem Azure VMware Solution-Segment. Sobald der Rückgabedatenverkehr erwartungsgemäß an das T0-Gateway zurückgesendet wird, wird der Datenverkehr anstelle des T0 erzwungen, wenn das Rückgabesubnetz eine RFC 1918-Übereinstimmung ist. Dann erfolgt die Ausgabe des Datenverkehrs über ExpressRoute zurück zu Azure auf der lokalen Seite. Dies kann zu Verwirrung bei zustandsbehafteten Firewalls in der Mitte und zu asymmetrischem Routingverhalten führen. Außerdem empfiehlt es sich, zu bestimmen, wie VMs in NE MON-Segmenten entweder über das T0-Gateway in Azure VMware Solution oder nur über das NE zurück zur lokalen Bereitstellung auf das Internet zugreifen müssen. Im Allgemeinen sollten alle Standardrichtlinienrouten entfernt werden, um asymmetrischen Datenverkehr zu vermeiden. Aktivieren Sie Richtlinienrouten nur, wenn die Netzwerkinfrastruktur so konfiguriert wurde, dass asymmetrischer Datenverkehr berücksichtigt und verhindert wird.

Die MON-Richtlinienrouten können mit keinem definierten Gelöscht werden. Dies führt dazu, dass der gesamte Ausgehende Datenverkehr an das T0-Gateway weitergeleitet wird.

Die MON-Richtlinienrouten können mit einer Standardroute (0.0.0.0/0/0) aktualisiert werden. Dies führt dazu, dass der gesamte Ausgangsverkehr über den NE-Pfad getunnelt wird.

Wie in den obigen Diagrammen beschrieben, ist es wichtig, eine Richtlinienroute an jedes erforderliche Subnetz zuzuordnen. Andernfalls wird der Verkehr über den T0 geleitet und nicht über das NE getunnelt.

Weitere Informationen zu Richtlinienrouten finden Sie unter Mobility Optimized Networking-Richtlinienrouten.