Pokyny k sítím optimalizovaným pro VMware HCX Mobility (MON)
Poznámka:
VMware HCX Mobility Optimized Networking oficiálně podporuje řešení VMware a Azure VMware z HCX verze 4.1.0.
Důležité
Než povolíte HCX MON, přečtěte si následující omezení a nepodporované konfigurace:
Nepodporované zdrojové konfigurace pro NE HCX
Omezení pro jakékoli nasazení HCX, včetně MON
VMware HCX Mobility Optimized Networking (MON) se nepodporuje při použití brány třetí strany. Dá se použít pouze s bránou T1 přímo připojenou k bráně T0 bez síťového virtuálního zařízení (NVA). Tuto funkci konfigurace možná budete moct nastavit, ale tuto funkci nepodporujeme.
HCX Mobility Optimized Networking (MON) je volitelná funkce, která se povolí při použití síťových rozšíření HCX (NE). MON poskytuje optimální směrování provozu v určitých scénářích, aby se zabránilo tromboningu sítě mezi místními a cloudovými prostředky v rozšířených sítích.
Vzhledem k tomu, že mon je funkce NE podniková, ujistěte se, že jste povolili VMware HCX Enterprise prostřednictvím webu Azure Portal.
V průběhu cyklu migrace optimalizuje MON mobilitu aplikací pro:
Optimalizace komunikace virtuálních počítačů do virtuálního počítače L2 při použití roztažených sítí
Optimalizace a zabránění asymetrickým tokům provozu mezi místním prostředím, Azure VMware Solution a Azure
V tomto článku se dozvíte o případech použití pro MON specifické pro řešení Azure VMware.
Optimalizace toků provozu napříč standardními a roztaženými segmenty na straně privátního cloudu
V tomto scénáři se virtuální počítač 1 migruje do cloudu pomocí NE, který poskytuje optimální latenci virtuálního počítače. V důsledku toho virtuální počítač 1 potřebuje nízkou latenci pro VM3 v místním segmentu řešení Azure VMware. Bránu virtuálního počítače 1 migrujeme z místního prostředí do Azure VMware Solution (cloud), abychom zajistili optimální cestu pro provoz (modrá čára). Pokud brána zůstane místně (červená čára), zjistí se efekt tromboningu a vyšší latence.
Poznámka:
Když povolíte MON bez migrace brány virtuálního počítače na cloudovou stranu, nezajistí optimální cestu pro tok provozu. Nepovoluje také vyhodnocení tras zásad.
Optimalizace a zabránění asymetrickým tokům provozu
V tomto scénáři předpokládáme, že se virtuální počítač z místního prostředí migruje do Azure VMware Solution a účastní se L2 a provoz L3 se vrací zpět do místního prostředí pro přístup ke službám. Předpokládáme také, že se některá komunikace virtuálních počítačů z Azure (ve virtuální síti připojené k řešení Azure VMware Solution) může spojit s privátním cloudem Azure VMware Solution.
Důležité
Hlavním bodem je naplánovat a vyhnout se asymetrickým tokům provozu pečlivě.
Ve výchozím nastavení a bez použití MON může virtuální počítač v Azure VMware Solution v roztažené síti bez MON komunikovat zpět do místního prostředí pomocí upřednostňované cesty ExpressRoute. V závislosti na případech použití zákazníka byste měli vyhodnotit, jak by měl virtuální počítač v roztaženém segmentu řešení Azure VMware s MON přecházet zpět do místního prostředí, a to buď přes síťové rozšíření, nebo bránu T0 přes ExpressRoute a současně udržovat toky provozu symetrické.
Pokud například zvolíte cestu NE, trasy zásad MON musí konkrétně řešit podsíť na místní straně; Jinak se použije výchozí trasa 0.0.0.0/0. Trasy zásad najdete v rámci segmentu NE tak, že vyberete pokročilé.
Ve výchozím nastavení jsou všechny IP adresy RFC 1918 zahrnuté v definici tras zásad MON.
Výsledkem je tunelování veškerého odchozího provozu RFC 1918 přes cestu NE a veškerý internetový a veřejný provoz směrovaný do brány T0.
Trasy zásad se vyhodnocují jenom v případě, že se brána virtuálního počítače migruje do cloudu. Výsledkem této konfigurace je, že všechny odpovídající podsítě pro cíl se tunelují přes zařízení NE. Pokud se neshodují, směrují se přes bránu T0.
Poznámka:
Zvláštní pozornost při používání MON v Řešení Azure VMware je poskytnout trasám /32 inzerovaným přes protokol BGP svým partnerským uzlům; to zahrnuje místní prostředí a Azure přes připojení ExpressRoute. Například virtuální počítač v Azure se učí cestu k virtuálnímu počítači Azure VMware Solution v segmentu s povoleným prostředím AZURE VMware Solution MON. Jakmile se návratový provoz odešle zpět do brány T0 podle očekávání, pokud je návratová podsíť shoda RFC 1918, provoz se místo T0 vynutí přes ne. Pak se výchozí přenos dat přes ExpressRoute vrátí do Azure na místní straně. To může způsobit nejasnosti stavových bran firewall uprostřed a asymetrického směrování chování. Je také vhodné určit, jak budou virtuální počítače v segmentech NE MON potřebovat přístup k internetu, a to buď přes bránu T0 v Řešení Azure VMware, nebo jenom přes ne zpět do místního prostředí. Obecně platí, že všechny výchozí trasy zásad by se měly odebrat, aby nedocházelo k asymetrickým přenosům. Povolte trasy zásad pouze v případě, že je síťová infrastruktura nakonfigurovaná tak, aby se zohlednila asymetrické přenosy a zabránila tak asymetrickým přenosům.
Trasy zásad MON je možné odstranit bez definované definice. Výsledkem je směrování veškerého odchozího provozu do brány T0.
Trasy zásad MON je možné aktualizovat na výchozí trasu (0.0.0.0/0). Výsledkem je tunelování veškerého odchozího provozu přes cestu NE.
Jak je popsáno v předchozích diagramech, důležitostí je spárovat trasu zásad do každé požadované podsítě. V opačném případě se provoz směruje přes T0 a ne tuneluje přes ne.
Další informace o trasách zásad najdete v tématu Trasy zásad optimalizované pro sítě mobility.