Richtlijnen voor VMware HCX Mobility Optimized Networking (MON)

Notitie

VMware HCX Mobility Optimized Networking wordt officieel ondersteund door VMware en Azure VMware Solution van HCX versie 4.1.0.

Belangrijk

Lees de onderstaande beperkingen en niet-ondersteunde configuraties voordat u HCX MON inschakelt:

Niet-ondersteunde bronconfiguraties voor HCX NE

Beperkingen voor elke HCX-implementatie, inclusief MON

VMware HCX Mobility Optimized Networking (MON) wordt niet ondersteund met het gebruik van een gateway van derden. Deze kan alleen worden gebruikt met de T1-gateway die rechtstreeks is verbonden met de T0-gateway zonder een virtueel netwerkapparaat (NVA). Mogelijk kunt u deze configuratiefunctie maken, maar deze wordt niet ondersteund.

HCX Mobility Optimized Networking (MON) is een optionele functie die u kunt inschakelen wanneer u HCX-netwerkextensies (NE) gebruikt. MON biedt optimale verkeersroutering onder bepaalde scenario's om netwerk tromboning tussen de on-premises en cloudresources op uitgebreide netwerken te voorkomen.

Aangezien MON een bedrijfsmogelijkheid van de NE-functie is, moet u ervoor zorgen dat u de VMware HCX Enterprise hebt ingeschakeld via Azure Portal.

Tijdens de migratiecyclus optimaliseert MON de toepassingsmobiliteit voor:

• Optimaliseren voor virtuele machine (VM) naar VM L2-communicatie bij het gebruik van stretched netwerken

• Asymmetrische verkeersstromen tussen on-premises, Azure VMware Solution en Azure optimaliseren en vermijden

In dit artikel vindt u meer informatie over de azure VMware Solution-specifieke use cases voor MON.

Verkeersstromen optimaliseren in standaardsegmenten en stretched segmenten aan de zijde van de privécloud

In dit scenario wordt VM1 gemigreerd naar de cloud met behulp van de NE, wat optimale VM-naar-VM-latentie biedt. Als gevolg hiervan heeft VM1 een lage latentie voor VM3 nodig in het lokale Azure VMware Solution-segment. We migreren de VM1-gateway van on-premises naar Azure VMware Solution (cloud) om een optimaal pad voor verkeer (blauwe lijn) te garanderen. Als de gateway on-premises (rode lijn) blijft, wordt een tromboning-effect en een hogere latentie waargenomen.

Notitie

Wanneer u MON inschakelt zonder de VM-gateway naar de cloudzijde te migreren, zorgt dit niet voor een optimaal pad voor de verkeersstroom. Ook wordt de evaluatie van beleidsroutes niet toegestaan.

Asymmetrische verkeersstromen optimaliseren en voorkomen

In dit scenario wordt ervan uitgegaan dat een virtuele machine van on-premises wordt gemigreerd naar Azure VMware Solution en deelneemt aan L2, en L3-verkeer teruggaat naar on-premises om toegang te krijgen tot services. We gaan er ook vanuit dat sommige VM-communicatie vanuit Azure (in het verbonden virtuele netwerk van Azure VMware Solution) kan worden bereikt in de privécloud van Azure VMware Solution.

Belangrijk

Het belangrijkste punt hier is om asymmetrische verkeersstromen zorgvuldig te plannen en te voorkomen.

Standaard en zonder MON kan een VIRTUELE machine in Azure VMware Solution in een stretched netwerk zonder MON via het voorkeurspad van ExpressRoute naar on-premises communiceren. Op basis van gebruiksscenario's van klanten moet worden geëvalueerd hoe een VM in een stretched segment van Azure VMware Solution dat is ingeschakeld met MON, moet worden doorgestuurd naar on-premises, via de netwerkextensie of de T0-gateway via de ExpressRoute, terwijl verkeer symmetrisch blijft.

Als u bijvoorbeeld het NE-pad kiest, moeten de MON-beleidsroutes specifiek het subnet aan de on-premises kant aanpakken; anders wordt de standaardroute 0.0.0.0/0 gebruikt. U vindt beleidsroutes onder het NE-segment door geavanceerd te selecteren.

Standaard worden alle RFC 1918-IP-adressen opgenomen in de definitie van MON-beleidsroutes.

Dit resulteert in alle RFC 1918 uitgaand verkeer dat via het NE-pad wordt getunneld en al het internet- en openbaar verkeer dat naar de T0-gateway wordt gerouteerd.

Beleidsroutes worden alleen geëvalueerd als de VM-gateway naar de cloud wordt gemigreerd. Het effect van deze configuratie is dat alle overeenkomende subnetten voor de bestemming worden getunneld via het NE-apparaat. Als deze niet overeenkomen, worden ze doorgestuurd via de T0-gateway.

Notitie

Speciale overweging voor het gebruik van MON in Azure VMware Solution is het geven van de /32 routes die via BGP worden geadverteerd aan de peers; dit omvat on-premises en Azure via de ExpressRoute-verbinding. Een VIRTUELE machine in Azure leert bijvoorbeeld het pad naar een Azure VMware Solution-VM in een azure VMware Solution MON-segment. Zodra het retourverkeer wordt teruggestuurd naar de T0-gateway zoals verwacht, wordt verkeer afgedwongen via de NE in plaats van de T0 als het retoursubnet een RFC 1918-overeenkomst is. Vervolgens gaat u via de ExpressRoute terug naar Azure aan de on-premises zijde. Dit kan leiden tot verwarring bij stateful firewalls in het midden en asymmetrisch routeringsgedrag. Het is ook een goed idee om te bepalen hoe VM's in NE MON-segmenten toegang moeten hebben tot internet, ofwel via de T0-gateway in Azure VMware Solution of alleen via de NE terug naar on-premises. Over het algemeen moeten alle standaardbeleidsroutes worden verwijderd om asymmetrisch verkeer te voorkomen. Schakel beleidsroutes alleen in als de netwerkinfrastructuur zodanig is geconfigureerd dat er asymmetrisch verkeer wordt voorkomen.

De MON-beleidsroutes kunnen worden verwijderd met geen gedefinieerd. Dit resulteert in alle uitgaande verkeer dat naar de T0-gateway wordt gerouteerd.

De MON-beleidsroutes kunnen worden bijgewerkt met een standaardroute (0.0.0.0/0). Dit resulteert in alle uitgaande verkeer dat via het NE-pad wordt getunneld.

Zoals beschreven in de bovenstaande diagrammen, is het belangrijk om een beleidsroute te koppelen aan elk vereist subnet. Anders wordt het verkeer via de T0 gerouteerd en niet getunneld via de NE.

Zie Routes voor geoptimaliseerd netwerkbeleid voor Mobiliteit voor meer informatie over beleidsroutes.