Tervezési szempontok Azure VMware Solution 2. generációs magánfelhőkhöz

Ez a cikk a Azure VMware Solution 2. generációs (Gen 2) magánfelhők legfontosabb tervezési szempontjait ismerteti. Ismerteti, hogy ez a generáció milyen képességeket biztosít a VMware-alapú magánfelhő-környezetekhez, lehetővé téve az alkalmazások elérését a helyszíni infrastruktúrából és Azure-alapú erőforrásokból is. A Azure VMware Solution Gen 2 magánfelhő beállítása előtt több szempontot is figyelembe kell venni. Ez a cikk olyan használati esetekre nyújt megoldást, amelyekkel a magánfelhő-típus használatakor találkozhat.

Megjegyzés

A 2. generáció bizonyos Azure nyilvános régiókban érhető el. A lefedettség megerősítéséhez forduljon a Microsoft Account csapatához vagy a Microsoft támogatáshoz.

Korlátozások

Ez idő alatt az alábbi funkciók korlátozottak. Ezek a korlátozások a jövőben megszűnnek:

• A magánfelhőt tartalmazó erőforráscsoport nem törölhető. Az erőforráscsoport törlése előtt először törölnie kell a magánfelhőt.
• A 1 magánfelhő csak Azure virtuális hálózatonként telepíthető.
• Erőforráscsoportonként csak 1 magánfelhő hozható létre. Egy erőforráscsoportban több privát felhő nem támogatott.
• A magánfelhőhöz tartozó magánfelhőnek és virtuális hálózatnak ugyanabban az erőforráscsoportban kell lennie.
• A magánfelhő létrehozása után nem helyezheti át a magánfelhőt az egyik erőforráscsoportból a másikba.
• A magánfelhő létrehozása után nem helyezheti át a magánfelhőt egyik bérlőről a másikra.
• Ha ExpressRoute FastPath vagy Global Virtual Network társviszony-létesítést szeretne az AVS privát felhőjéhez, hozzon létre támogatási esetet az Azure portálon keresztül.
• Szolgáltatásvégpontok Azure VMware Solution számítási feladatok közvetlen kapcsolata nem támogatott.
• Private-végpontok globális társviszony esetén az Azure VMware Solution csatlakoztatott régiók között nem támogatottak.
• A vCloud Director magán végpontok használatával támogatott. Azonban a nyilvános végpontokat használó vCloud Director nem támogatott.
• A vSAN stretched clusters nem támogatott.
• A VMware NSX Microsoft Edge-ig terjedő nyilvános IP-cím használata az internetkapcsolat konfigurálásához nem támogatott. Az internetkapcsolat beállításaiban megtalálja, hogy milyen internetes beállítások támogatottak.
• A szoftveralapú adatközpont (SDDC) első négy gazdagépén a nem tervezett karbantartás során – például egy gazdagép hardverhibáján – átmeneti North-South hálózati kapcsolati megszakadást tapasztalhat bizonyos számítási feladatok esetében, amely akár 30 másodpercig is eltarthat. North-South kapcsolat az AVS VMware-számítási feladatok és a NSX-T 0. réteg (T0) Edge-en kívüli külső végpontok közötti forgalomra utal, például Azure szolgáltatások vagy helyszíni környezetek között. Ez a korlátozás bizonyos Azure régiókban megszűnt. Ellenőrizze, hogy a régióra hatással van-e ez a korlátozás a Azure támogatásával.  
• A magánfelhő gazdagép virtuális hálózatához társított hálózati biztonsági csoportokatugyanabban az erőforráscsoportban kell létrehozni, mint a magánfelhőt és annak virtuális hálózatát.
• Az erőforráscsoportok és előfizetések közötti hivatkozások az ügyfél virtuális hálózatai és az Azure VMware Solution virtuális hálózata között alapértelmezés szerint nem támogatottak. Ide tartoznak az olyan erőforrástípusok, mint például a felhasználó által definiált útvonalak (UDR-ek), a DDoS Protection-tervek és más csatolt hálózati erőforrások. Ha egy ügyfél virtuális hálózata olyan hivatkozáshoz van társítva, amely a Azure VMware Solution virtuális hálózattól eltérő erőforráscsoportban vagy előfizetésben található, a hálózati programozás (például az NSX-szegmens propagálása) meghiúsulhat. A problémák elkerülése érdekében az ügyfeleknek gondoskodniuk kell arról, hogy a Azure VMware Solution virtuális hálózat ne kapcsolódjon egy másik erőforráscsoport vagy előfizetés erőforrásaihoz. A folytatás előtt távolítsa el az ilyen kapcsolatokat, például a DDoS Protection-terveket a virtuális hálózatról.
  • Az erőforráscsoportok közötti hivatkozás megőrzéséhez hozzon létre egy szerepkör-hozzárendelést a másik erőforráscsoportból vagy előfizetésből, és rendelje hozzá az „AzS VIS Prod App” alkalmazáshoz az „AVS on Fleet VIS Role” szerepkört. A szerepkör-hozzárendelés lehetővé teszi a hivatkozás használatát, és biztosítja, hogy a hivatkozás helyesen legyen alkalmazva az Azure VMware Solution privát felhőjére.
• A Gen 2 magánfelhő telepítések meghiúsulhatnak, ha az Azure szabályzatok szigorú szabályokat kényszerítenek ki a hálózati biztonsági csoportokra vagy útvonaltáblákra (például adott elnevezési konvenciókra). Ezek a szabályzatkorlátozások blokkolhatják a szükséges Azure VMware Solution hálózati biztonsági csoport és útvonaltábla létrehozását az üzembe helyezés során. A magánfelhő üzembe helyezése előtt el kell távolítania ezeket a szabályzatokat a Azure VMware Solution virtuális hálózatról. A magánfelhő üzembe helyezése után ezek a szabályzatok újra hozzáadhatók a Azure VMware Solution magánfelhőhöz.
• Ha saját DNS-t használ a Azure VMware Solution Gen 2 magánfelhőjéhez, a Custom DNS a virtuális hálózaton, ahol egy Azure VMware Solution Gen 2 magánfelhő van üzembe helyezve, nem támogatott. Az egyéni DNS megszakítja az életciklus-műveleteket, például a skálázást, a frissítéseket és a javításokat.
• Ha törli a magánfelhőjét, és az Azure VMware Solution által létrehozott egyes erőforrások nem távolíthatók el, az Azure CLI használatával ismét megkísérelheti az Azure VMware Solution magánfelhő törlését.
• Azure VMware Solution Gen 2 HTTP-proxyval különbözteti meg az ügyfelek és a felügyeleti hálózati forgalmat. Előfordulhat, hogy egyes VMware felhőszolgáltatás-végpontok nem ugyanazt a hálózati útvonalat vagy proxyszabályokat követik, mint az általános vCenter által felügyelt forgalom. Ilyen például a "scapi.vmware" és az "apigw.vmware". A VAMI-proxy szabályozza a vCenter Server Appliance (VCSA) általános kimenő internet-hozzáférését, de nem minden szolgáltatásvégpont-interakció halad keresztül ezen a proxyn. Egyes interakciók közvetlenül a felhasználó böngészőjéből vagy integrációs összetevőkből származnak, amelyek ehelyett a munkaállomás proxybeállításait követik, vagy egymástól függetlenül kezdeményeznek kapcsolatokat. Ennek eredményeképpen a VMware felhőszolgáltatás végpontjai felé irányuló forgalom teljes mértékben megkerülheti a VCSA-proxyt.
• A Gen 2 rendszeren végzett HCX RAV- és tömeges migrációk lassabb teljesítményt mutathatnak a Base Sync és Online Sync fázisok során fellépő megakadások miatt. Az ügyfeleknek egyelőre hosszabb migrálási ablakokat kell tervezni, és ennek megfelelően kell ütemezni a hullámokat. A megfelelő számítási feladatokhoz a vMotion gyorsabb, alacsony terhelésű lehetőséget kínál, ha a gazdagép és a hálózati feltételek lehetővé teszik.
• Virtuális központ (virtual WAN) társviszony-létesítése: A Gen-2 virtuális hálózat és a virtuális központ (virtual WAN) közötti társviszony létesítéséhez a virtuális központnak ugyanabban a régióban kell lennie, mint a Gen-2 virtuális hálózat. Ha egy másik régióban lévő virtuális központtal kell társviszonyt létesítenie, támogatási esetet kell létrehoznia a Azure portálon keresztül.
• /32-es útvonal célja társviszonyban lévő virtuális hálózatból (VNET): Ha /32-es útvonalakat hirdet az NSX-ből (például HCX MON-útvonalakat vagy DNS-továbbítói útvonalakat), és egy társviszonyban lévő virtuális hálózatból kell elérnie ezt a /32-es célt, támogatási kérelmet kell nyitnia az Azure Portalon. A /32-célhoz való csatlakozás megfelelően működik a helyi virtuális hálózaton belülről.
• A VNET Peer Sync alhálózat közzététele és az Azure útvonaltábla (UDR) hozzárendelése – Az Azure VMware Solution Gen 2 két belső architektúrát használ. A jelenlegi architektúra szinkronizálja az egyes alhálózatokat és a tágabb Azure-címtartományt az NSX-szegmens- vagy alhálózatútvonalakhoz a peeringkapcsolattal rendelkező Azure-beli virtuális hálózatokkal. Ennek eredményeképpen a Gen 2 jelenlegi architektúrájával előfordulhat, hogy Azure útvonaltáblákat (UDR) kell konfigurálnia konkrétabb NSX-szegmens alhálózati útvonalakkal, nem pedig általános címtér-útvonalakat kell használnia Azure VMware Solution számítási feladatok szegmenseihez.

Nem támogatott integrációk

A következő első fél és harmadik fél integrációk nem érhetők el:

• Zerto DR

2. generációs delegált alhálózatok és hálózati biztonsági csoportok

A Azure VMware Solution (AVS) Gen 2 magánfelhő üzembe helyezésekor Azure automatikusan létrehoz több delegált alhálózatot a magánfelhő gazdagép virtuális hálózatán belül. Ezek az alhálózatok a magánfelhő felügyeleti összetevőinek elkülönítésére és védelmére szolgálnak.

Az ügyfelek a Azure portálon vagy a Azure CLI/PowerShellen keresztül látható hálózati biztonsági csoportok (NSG-k) használatával kezelhetik az alhálózatokhoz való hozzáférést. Az ügyfél által kezelhető NSG-k mellett az AVS további rendszer által felügyelt NSG-ket is alkalmaz a kritikus fontosságú felügyeleti felületekre. Ezek a rendszer által felügyelt NSG-k nem láthatók vagy szerkeszthetők az ügyfelek számára, és azért léteznek, hogy a magánfelhő alapértelmezés szerint biztonságos maradjon.

Az alapértelmezett biztonsági helyzet részeként:

• Az internet-hozzáférés le van tiltva a magánfelhő esetében, hacsak az ügyfél nem engedélyezi azt.
• Csak a szükséges felügyeleti forgalom érheti el a platformszolgáltatásokat.

Megjegyzés

Előfordulhat, hogy a Azure portálon figyelmeztetés jelenik meg, amely azt jelzi, hogy bizonyos portok láthatóan elérhetők az interneten. Ez azért fordul elő, mert a portál csak az ügyfél által látható hálózati biztonsági csoport (NSG) konfigurációját értékeli ki. A Azure VMware Solution azonban további, a portálon nem látható, rendszer által felügyelt hálózati biztonsági csoportokat is alkalmaz. Ezek a rendszer által felügyelt hálózati biztonsági csoportok blokkolják a bejövő forgalmat, kivéve, ha a hozzáférés explicit módon engedélyezve van Azure VMware Solution konfiguráción keresztül.

Ez a kialakítás alapértelmezés szerint biztonságosan és elkülönítve tartja az AVS-környezetet, miközben továbbra is lehetővé teszi az ügyfelek számára a hálózati hozzáférés kezelését és módosítását az igényeiknek megfelelően.

Útválasztási és alhálózati szempontok

Azure VMware Solution Gen 2 magánfelhők olyan VMware privát felhőkörnyezetet biztosítanak, amely a helyszíni és Azure-alapú környezetekből vagy erőforrásokból származó felhasználók és alkalmazások számára érhető el. A kapcsolat a szabványos Azure hálózatkezelésen keresztül valósul meg. A szolgáltatások engedélyezéséhez meghatározott hálózati címtartományokra és tűzfalportokra van szükség. Ez a szakasz segít konfigurálni a hálózatkezelést a Azure VMware Solution való működéshez.

A magánfelhő szabványos Azure hálózatkezeléssel csatlakozik a Azure virtuális hálózathoz. Azure VMware Solution Gen 2 magánfelhőkhöz legalább /22 CIDR hálózati címblokk szükséges az alhálózatokhoz. Ez a hálózat kiegészíti a helyszíni hálózatokat, így a címblokk nem fedheti át az előfizetés és a helyszíni hálózatok más virtuális hálózataiban használt címblokkokat. A felügyeleti, vMotion- és replikációs hálózatok automatikusan ki vannak építve ezen a címblokkon belül alhálózatként a virtuális hálózaton belül.

Megjegyzés

A címblokk engedélyezett tartományai az RFC 1918 privát címterek (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), kivéve a 172.17.0.0/16-ot. A replikációs hálózat nem alkalmazható az AV64-csomópontokra, és egy későbbi időpontban általános elavulás várható.

Ne használja a következő, VMware NSX-használathoz fenntartott IP-sémát:

• 169.254.0.0/24 – belső tranzithálózathoz használatos
• 169.254.2.0/23 – VRF közötti tranzithálózathoz használatos
• 100.64.0.0/16 – T1 és T0 átjárók belső csatlakoztatására szolgál
• 100.73.x.x – a Microsoft felügyeleti hálózata használja

Megjegyzés

A táblázatban felsorolt alhálózatok többsége alhálózatként jelenik meg a Azure virtuális hálózaton belül. Ezeken ne módosítsa manuálisan az alhálózat konfigurációját, mivel azokat a Azure VMware Solution vezérlősík kezeli, és a módosítások negatív következményekkel járhatnak.

A /22 CIDR hálózati címblokk 10.31.0.0/22 példája a következő alhálózatokra van osztva:

Hálózathasználat	Alhálózat	Leírás	Example
VMware NSX-hálózat	/27	NSX Manager-hálózat.	10.31.0.0/27
vCSA-hálózat	/27	vCenter Server-hálózat.	10.31.0.32/27
avs-mgmt	/27	A felügyeleti berendezések (vCenter Server, NSX manager és HCX cloud manager) az "avs-mgmt" alhálózat mögött találhatók, és másodlagos IP-tartományokként vannak programozva ezen az alhálózaton. Előfordulhat, hogy módosítania kell az alhálózathoz társított útvonaltáblákat, ha a hálózati forgalomnak a felügyeleti berendezésekhez NVA-n vagy tűzfalon keresztül kell haladnia	10.31.0.64/27
avs-vnet-sync	/27	A 2. generációs Azure VMware Solution használja a VMware NSX-ben létrehozott útvonalak programozásához a virtuális hálózatba.	10.31.0.96/27
avs-services	/27	Azure VMware Solution Gen 2 szolgáltatói szolgáltatásokhoz használatos. Privát DNS-feloldás konfigurálására is használható a magánfelhőhöz.	10.31.0.224/27
avs-nsx-gw, avs-nsx-gw-1	/27	A két avs-nsx-gw alhálózat kezeli az Azure VMware Solutionből a virtuális hálózatba és azon túl irányuló összes kimenő forgalmat. Ezért minden esetben Azure útvonaltáblákat (UDR) és hálózati biztonsági csoportokat (NSG) kell alkalmazni ezekre az alhálózatokra. A kezdeti AVS Gen-2 magánfelhőkben ezek az alhálózatok a bejövő forgalmat is kezelik, az összes NSX-szegmens alhálózata másodlagos IP-címként van konfigurálva. A jelenlegi AVS Gen-2 magánfelhőkben a rendszer hozzáad egy harmadik, "avs-network-infra-gw" nevű alhálózatot az összes bejövő forgalom kezeléséhez. Most az összes NSX-szegmens ehhez az alhálózathoz van rendelve az avs-nsx-gw alhálózatok helyett.	10.31.0.128/27, 10.31.0.160/27
avs-network-infra-gw	/26	Ha ez az alhálózat jelen van, a VNET összes NSX számítási feladatának bejövő forgalmát kezeli, és Azure VMware Solution felügyelet használja az NSX-szegmensalhálózatok másodlagos IP-címekként való konfigurálására. Kerülje a Azure útvonaltáblák társítását ezzel az alhálózattal; ehelyett használja az "avs-nsx-gw" alhálózatot a kimenő AVS-forgalom kezelésére, például Azure Firewall vagy külső hálózati virtuális berendezések (NVA) kezelésére.	10.31.2.128/26
esx-mgmt-vmk1	/25	A vmk1 az ügyfelek által a kiszolgálóhoz való hozzáféréshez használt felügyeleti felület. A vmk1 interfész ip-címei ezekből az alhálózatokból származnak. Minden gazdagép vmk1-forgalma ebből az alhálózati tartományból származik.	10.31.1.0/25
esx-vmotion-vmk2	/25	vMotion VMkernel interfészek.	10.31.1.128/25
esx-vsan-vmk3	/25	vSAN VMkernel-interfészek és csomópont-kommunikáció.	10.31.2.0/25
Fenntartott	/27	Fenntartott hely.	10.31.0.128/27
Fenntartott	/27	Fenntartott hely.	10.31.0.192/27

Megjegyzés

A 2. generációs Azure VMware Solution üzemelő példányok esetében az ügyfeleknek mostantól két további /24 alhálózatot kell lefoglalni a HCX-felügyelethez és a kimenő kapcsolatokhoz, az SDDC üzembe helyezése során megadott /22 mellett. A 2. generációs AVS-ben csak a HCX mgmt és a HCX kimenő alhálózatokra van szükség. A vMotion és a replikációs hálózatok nem szükségesek a 2. generációs AVS-hez.

NSX-útvonalak programozása az Azure-beli virtuális hálózatra

Az Azure VMware Solution Gen-2 NSX-útvonalakat a címtér használatával integrálják az Azure-ba, és másodlagos IP-címként rendelik hozzá őket a rendszer által létrehozott „avs-network-infra-gw” alhálózathoz, lehetővé téve ezzel a zökkenőmentes kapcsolatot az Azure és az AVS ügyfélmunkaterhelések között. Ha az NSX Tier-0 felhasználói beállításokon alapuló útvonalat hirdet – például szegmenseket hoz létre, statikus útvonalakat ad hozzá vagy HCX MON virtuális gépeket használ –, a Azure VMware Solution vezérlősík ellenőrzi, hogy az útvonalelőtag megtalálható-e a virtuális hálózati címtérben. Ha nem, létrehozza a címteret, és hozzáadja az útvonalelőtagot másodlagos IP-címként az "avs-network-infra-gw" alhálózaton. A 0. rétegben meghirdetett /32 útvonalak, például a HCX MON-útvonalak esetében a másodlagos IP-címek nincsenek beállítva, de az adatsík belsőleg konfigurálva van, hogy biztosítsa a kapcsolatot a /32 célhelyekkel a Azure VMware Solution.

Az NSX-útvonalak címterének és alhálózati frissítésének mellett van egy belső programozás, amellyel az ügyfeleknek tisztában kell lenniük, különösen az alacsonyabb alhálózati maszkok használata esetén támogatott skálázás tekintetében. A méretezési szemponttal kapcsolatos további információkért lásd: Az Azure VMware Solution 2. generációjának útvonal-architektúrája

Azure útvonaltábla (UDR) társítási szempontok

Azure VMware Solution Gen-2 két belső architektúrát tartalmaz, kis eltéréssel. A kezdeti Gen-2 magánfelhők némelyike a kezdeti belső architektúrát használja. Ezek az ügyféllel koordinált ütemezett karbantartással frissülnek az aktuális architektúrára. A jelenlegi architektúra viselkedése azonban megváltozik a kezdeti architektúrához képest, ami hatással lehet bizonyos hálózattervezési szempontokra az alábbiakban leírtak szerint.

Első Gen-2 magánfelhő:

• Az Azure virtuális hálózat két alapértelmezett, „avs-nsx-gw” nevű átjáró-alhálózata van, és a jelenlegi architektúrával ellentétben nem tartalmazza az „avs-network-infra-gw” alhálózatot.
• Az összes AVS NSX-szegmens alhálózat az "avs-nsx-gw" alhálózat alatt van beprogramozva további IPv4-címként a Azure NSX-számítási feladatokhoz való csatlakoztatásához.
• Az útvonaltáblát (UDR) vagy Azure NSG-t az AVS-ből Azure virtuális hálózatba és azon túlra irányuló forgalomhoz (például helyszíni) az "avs-nsx-gw" alhálózatra kell alkalmazni.

A Gen-2 jelenlegi magánfelhői:

Mindenképpen jegyezze fel ezt a viselkedésbeli változást.

• Az Azure virtuális hálózatban egy további, „avs-network-infra-gw” előtagú alhálózat jelenne meg, valamint két, az eredeti architektúrához hasonló „avs-nsx-gw” nevű alap átjáró-alhálózat.
• Az AVS NSX-szegmens alhálózatai mostantól az alhálózat alatt másodlagos IPv4-címként vannak beprogramozva a Azure NSX-számítási feladatokhoz való csatlakoztatásához. Ez nem változtatja meg az ügyfél hálózati kapcsolatát.
• A VNET-társítás a címterületet és az alhálózatokat is meghirdeti a társított VNET számára, ami eltér a kezdeti architektúrától vagy az Azure natív VNET-szinkrontól, ahol csak a címterület szinkronizálódik.

Tervezési szempontok a Gen-2 belső architektúra változásai miatt

• Az ügyfelek a társhálózaton belüli AVS-alhálózatok további hatékony útvonalait figyelik meg a virtuális hálózatok társszinkronizálási viselkedésének változása miatt.
• Ha egy ügyfél egy Azure útvonaltáblát (UDR) használ a helyszíni forgalom AVS-be tűzfalon vagy hálózati virtuális berendezésen keresztül történő továbbításához, akkor az UDR-t úgy kell frissítenie, hogy az adott NSX-alhálózati útvonalakat használjon a korábban használt széles szuperhálózati címtartomány helyett. Ez azért szükséges, hogy megakadályozza, hogy az AVS-be irányuló forgalom a specifikusabb VNET-alhálózati útvonalakat használja, és ezzel megkerülje a kívánt tűzfalat, a leghosszabb előtag egyezésének az Azure útválasztásában alkalmazott működése miatt. Ellenkező esetben ez aszimmetrikus útválasztást eredményezhet, ami csatlakozási problémákat okozhat.
• Azonban az útvonaltáblát (UDR) vagy Azure NSG-t az AVS-ből Azure virtuális hálózatba és azon túlra irányuló forgalomra (például helyszíni) továbbra is alkalmazni kell az "avs-nsx-gw" alhálózatokra, nem pedig az "avs-network-infra-gw" alhálózatokra. Az ügyfelek nem használhatják az útválasztási táblát (UDR) az "avs-network-infra-gw" alhálózaton, még akkor sem, ha az NSX szegmens alhálózatai másodlagos IP-címekként vannak konfigurálva.

Következő lépések

• Kezdje el beállítani az Azure VMware Solution szolgáltatás-megbízottat előfeltételként. A Azure VMware Solution szolgáltatásnév engedélyezése gyors útmutatóban többet megtudhat.

• Kövesse az Azure VMware Gen 2 magánfelhő létrehozása oktatóanyagot.