VMware HCX Mobility Optimized Networking (MON) – útmutató

Feljegyzés

A VMware HCX mobilitásoptimalizált hálózatkezelést a VMware és az Azure VMware Solution hivatalosan is támogatja a HCX 4.1.0-s verziójából.

Fontos

A HCX MON engedélyezése előtt olvassa el az alábbi korlátozásokat és nem támogatott konfigurációkat:

A HCX NE nem támogatott forráskonfigurációi

A HCX-üzemelő példányokra vonatkozó korlátozások, beleértve a MON-t is

A VMware HCX Mobility Optimized Networking (MON) nem támogatott külső átjárók használatával. Csak a T0 átjáróhoz közvetlenül csatlakozó T1 átjáróval használható hálózati virtuális berendezés (NVA) nélkül. Lehetséges, hogy ezt a konfigurációs függvényt el tudja végezni, de nem támogatjuk.

A HCX Mobility Optimized Networking (MON) egy opcionális funkció, amely a HCX Hálózati bővítmények (NE) használatakor engedélyezhető. A MON optimális forgalomirányítást biztosít bizonyos helyzetekben, hogy megakadályozza a hálózat harsonálását a helyszíni és a felhőalapú erőforrások között a kiterjesztett hálózatokon.

Mivel a MON a NE szolgáltatás nagyvállalati képessége, győződjön meg arról, hogy engedélyezte a VMware HCX Enterprise szolgáltatást az Azure Portalon keresztül.

A migrálási ciklus során a MON optimalizálja az alkalmazások mobilitását a következő célokra:

  • Optimalizálás virtuális gépek (VM) és VM L2 közötti kommunikációra kifeszített hálózatok használatakor

  • A helyszíni, az Azure VMware Solution és az Azure közötti aszimmetrikus forgalom optimalizálása és elkerülése

Ebben a cikkben megismerheti a MON-hoz készült Azure VMware-megoldásspecifikus használati eseteket.

Forgalom optimalizálása standard és elosztott szegmensekben a magánfelhő oldalán

Ebben a forgatókönyvben a VM1 a NE használatával migrálódik a felhőbe, amely optimális virtuális gépet biztosít a virtuális gépek késéséhez. Ennek eredményeképpen a VM1-nek alacsony késésre van szüksége a VM3-hoz a helyi Azure VMware Solution szegmensben. Migráljuk a VM1-átjárót a helyszíniről az Azure VMware Solutionbe (felhőbe), hogy biztosíthassuk a forgalom optimális útvonalát (kék vonal). Ha az átjáró a helyszínen marad (piros vonal), a rendszer harsonaeffektust és nagyobb késést figyel meg.

Feljegyzés

Ha úgy engedélyezi a MON-t, hogy nem migrálja a virtuálisgép-átjárót a felhőbe, az nem biztosítja a forgalom optimális útvonalát. A szabályzatútvonalak kiértékelését sem teszi lehetővé.

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

Az aszimmetrikus forgalmi folyamatok optimalizálása és elkerülése

Ebben a forgatókönyvben feltételezzük, hogy egy helyszíni virtuális gép migrálva lesz az Azure VMware Solutionbe, és részt vesz az L2-ben, és az L3 forgalom visszafolyik a helyszínire a szolgáltatások elérése érdekében. Feltételezzük továbbá, hogy az Azure-ból (az Azure VMware Solutionhez csatlakoztatott virtuális hálózaton) keresztüli virtuálisgép-kommunikáció az Azure VMware Solution magánfelhőjéhez is eljut.

Fontos

A lényeg itt az, hogy gondosan tervezze meg és kerülje el az aszimmetrikus forgalom áramlását.

Alapértelmezés szerint és a MON használata nélkül az Azure VMware Solutionben lévő virtuális gépek a MON nélküli, kifeszített hálózaton az ExpressRoute által előnyben részesített útvonal használatával tudnak visszaküldni a helyszínre. Az ügyfélhasználati esetek alapján ki kell értékelni, hogy a MON használatával engedélyezett Azure VMware Solution-szegmensben lévő virtuális gépek hogyan térjenek vissza a helyszínire, akár a hálózati bővítményen, akár a T0-átjárón keresztül az ExpressRoute-on keresztül, miközben a forgalomáramlások szimmetrikusak maradnak.

Ha például a NE elérési utat választja, a MON-szabályzat útvonalainak kifejezetten a helyszíni oldalon kell kezelniük az alhálózatot; ellenkező esetben a 0.0.0.0/0 alapértelmezett útvonal lesz használva. A házirend-útvonalak a NE szegmensben találhatók a speciális kijelöléssel.

Alapértelmezés szerint az összes RFC 1918 IP-cím szerepel a MON szabályzatútvonalak definíciójában.

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

Ez azt eredményezi, hogy az összes RFC 1918 kimenő forgalom a NE útvonalon, valamint az összes internetes és nyilvános forgalom a T0 átjáróhoz lesz irányítva.

Diagram showing the RFC 1918 egress and egress traffic flow.

A szabályzatútvonalak csak akkor lesznek kiértékelve, ha a virtuálisgép-átjárót a felhőbe migrálják. Ennek a konfigurációnak az a hatása, hogy a célnak megfelelő alhálózatok bújtatva lesznek a NE-berendezésen. Ha nem egyezik, a rendszer a T0 átjárón keresztül irányítja át őket.

Feljegyzés

A MON azure-beli VMware-megoldásban való használatának különleges szempontja, hogy a BGP-n keresztül meghirdetett /32 útvonalakat átadják a társaiknak; Ez magában foglalja a helyszíni és az Azure-t az ExpressRoute-kapcsolaton keresztül. Az Azure-beli virtuális gépek például megismerik egy Azure VMware Solution virtuális gép elérési útját egy Azure VMware Solution MON-kompatibilis szegmensben. Miután a visszatérési forgalmat a várt módon visszaküldte a T0 átjárónak, ha a visszatérési alhálózat egy RFC 1918-as egyezés, a forgalom a T0 helyett az NE-n lesz kényszerítve. Ezután az ExpressRoute-on keresztül visszatér az Azure-ba a helyszíni oldalon. Ez zavart okozhat a középső és az aszimmetrikus útválasztási viselkedés állapotalapú tűzfalainál. Azt is érdemes meghatározni, hogy a NE MON-szegmensekben lévő virtuális gépeknek hogyan kell majd hozzáférnie az internethez az Azure VMware Solution T0-átjáróján keresztül, vagy csak a NE-n keresztül a helyszínire. Általában az összes alapértelmezett házirend-útvonalat el kell távolítani az aszimmetrikus forgalom elkerülése érdekében. Csak akkor engedélyezze a házirend-útvonalakat, ha a hálózati infrastruktúra úgy van konfigurálva, hogy figyelembe lehessen venni és megelőzni az aszimmetrikus forgalmat.

A MON-szabályzat útvonalai törölhetők úgy, hogy nincs definiálva. Ez azt eredményezi, hogy az összes kimenő forgalom a T0 átjáróhoz lesz irányítva.

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

A MON-szabályzat útvonalai alapértelmezett útvonallal frissíthetők (0.0.0.0/0). Ez azt eredményezi, hogy az összes kimenő forgalom bújtatása a NE útvonalon keresztül történik.

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

A fenti ábrákban leírtak szerint a fontosság az, hogy az egyes szükséges alhálózatokhoz igazodjon egy szabályzatútvonal. Ellenkező esetben a forgalom a T0-en keresztül lesz irányítva, és nem bújtatható át a NE-n.

A szabályzatútvonalakról további információt a mobilitásra optimalizált hálózati házirend-útvonalak című témakörben talál.