Vägledning för VMware HCX Mobility Optimized Networking (MON)
Kommentar
VMware HCX Mobility Optimized Networking stöds officiellt av VMware och Azure VMware Solution från HCX version 4.1.0.
Viktigt!
Innan du aktiverar HCX MON läser du nedanstående begränsningar och konfigurationer som inte stöds:
Källkonfigurationer som inte stöds för HCX NE
Begränsningar för alla HCX-distributioner, inklusive MON
VMware HCX Mobility Optimized Networking (MON) stöds inte med hjälp av en gateway från tredje part. Den får endast användas med T1-gatewayen direkt ansluten till T0-gatewayen utan en virtuell nätverksinstallation (NVA). Du kanske kan göra den här konfigurationsfunktionen, men vi stöder den inte.
HCX Mobility Optimized Networking (MON) är en valfri funktion som du kan aktivera när du använder HCX-nätverkstillägg (NE). MON tillhandahåller optimal trafikroutning i vissa scenarier för att förhindra nätverkstromboning mellan lokala och molnbaserade resurser i utökade nätverk.
Eftersom MON är en företagsfunktion för NE-funktionen kontrollerar du att du har aktiverat VMware HCX Enterprise via Azure-portalen.
Under hela migreringscykeln optimerar MON programmobiliteten för:
Optimera för virtuell dator (VM) till VM L2-kommunikation när du använder utsträckta nätverk
Optimera och undvika asymmetriska trafikflöden mellan lokalt, Azure VMware Solution och Azure
I den här artikeln får du lära dig mer om Azure VMware Solution-specifika användningsfall för MON.
Optimera trafikflöden över standard- och stretchsegment på den privata molnsidan
I det här scenariot migreras VM1 till molnet med hjälp av NE, vilket ger optimal svarstid för virtuell dator till virtuell dator. Därför behöver VM1 låg svarstid till VM3 i det lokala Azure VMware Solution-segmentet. Vi migrerar VM1-gatewayen från en lokal plats till Azure VMware Solution (molnet) för att säkerställa en optimal väg för trafik (blå linje). Om gatewayen förblir lokal (röd linje) observeras en tromboningseffekt och högre svarstid.
Kommentar
När du aktiverar MON utan att migrera den virtuella datorgatewayen till molnsidan säkerställer det inte en optimal sökväg för trafikflödet. Det tillåter inte heller utvärdering av principvägar.
Optimera och undvika asymmetriska trafikflöden
I det här scenariot antar vi att en virtuell dator från den lokala miljön migreras till Azure VMware Solution och deltar i L2- och L3-trafikflöden tillbaka till den lokala miljön för att få åtkomst till tjänster. Vi förutsätter också att viss VM-kommunikation från Azure (i azure VMware Solution connected virtual network) kan nå ner till det privata Azure VMware Solution-molnet.
Viktigt!
Huvudpunkten här är att planera och undvika asymmetriska trafikflöden noggrant.
Som standard och utan att använda MON kan en virtuell dator i Azure VMware Solution i ett utsträckt nätverk utan MON kommunicera tillbaka till den lokala miljön med hjälp av önskad ExpressRoute-sökväg. Baserat på kundens användningsfall bör man utvärdera hur en virtuell dator på ett Azure VMware Solution-segment som är aktiverat med MON ska gå tillbaka till den lokala miljön, antingen via nätverkstillägget eller T0-gatewayen via ExpressRoute samtidigt som trafikflödena hålls symmetriska.
Om du till exempel väljer NE-sökvägen måste MON-principvägarna specifikt adressera undernätet på den lokala sidan. annars används standardvägen 0.0.0.0/0. Du hittar principvägar under NE-segmentet genom att välja avancerat.
Som standard ingår alla RFC 1918 IP-adresser i definitionen av MON-principvägar.
Detta resulterar i att all utgående RFC 1918-trafik tunnelförs över NE-sökvägen och all Internet- och offentlig trafik dirigeras till T0-gatewayen.
Principvägar utvärderas endast om den virtuella datorgatewayen migreras till molnet. Effekten av den här konfigurationen är att alla matchande undernät för målet får tunneltrafik över NE-installationen. Om de inte matchas dirigeras de via T0-gatewayen.
Kommentar
Särskilt att tänka på när du använder MON i Azure VMware Solution är att ge de /32-vägar som annonseras via BGP till sina peer-datorer. Detta inkluderar lokalt och Azure via ExpressRoute-anslutningen. En virtuell dator i Azure lär sig till exempel vägen till en virtuell Azure VMware Solution-dator i ett Azure VMware Solution MON-aktiverat segment. När returtrafiken skickas tillbaka till T0-gatewayen som förväntat, om returundernätet är en RFC 1918-matchning, tvingas trafiken över NE i stället för T0. Sedan går ut över ExpressRoute tillbaka till Azure på den lokala sidan. Detta kan orsaka förvirring för tillståndskänsliga brandväggar i mitten och asymmetriskt routningsbeteende. Det är också en bra idé att avgöra hur virtuella datorer i NE MON-segment behöver komma åt Internet, antingen via T0-gatewayen i Azure VMware Solution eller bara via NE tillbaka till den lokala miljön. I allmänhet bör alla standardprincipvägar tas bort för att undvika asymmetrisk trafik. Aktivera endast principvägar om nätverksinfrastrukturen har konfigurerats på ett sådant sätt att du kan ta hänsyn till och förhindra asymmetrisk trafik.
MON-principvägarna kan tas bort utan att någon har definierats. Detta resulterar i att all utgående trafik dirigeras till T0-gatewayen.
MON-principvägarna kan uppdateras med en standardväg (0.0.0.0/0). Detta resulterar i att all utgående trafik tunneleras över NE-sökvägen.
Som beskrivs i diagrammen ovan är det viktigt att matcha en principväg till varje obligatoriskt undernät. Annars dirigeras trafiken över T0 och dirigeras inte över NE.
Mer information om principvägar finns i Mobilitetsoptimerade nätverksprincipvägar.