Aspekty návrhu pro privátní cloudy Řešení Azure VMware generace 2

Tento článek popisuje klíčové aspekty návrhu pro privátní cloudy Řešení Azure VMware generace 2 (Gen2). Vysvětluje možnosti, které tato generace přináší do prostředí privátního cloudu založeného na VMware a umožňuje přístup k vašim aplikacím z místní infrastruktury i Azure prostředků. Před nastavením privátního cloudu Řešení Azure VMware Gen2 je potřeba zvážit několik aspektů. Tento článek obsahuje řešení pro případy použití, se kterými se můžete setkat, když používáte typ privátního cloudu.

Poznámka:

Generace 2 je dostupná v konkrétních Azure veřejných oblastech. Pokud chcete potvrdit pokrytí, obraťte se na tým účtu Microsoft nebo podpora Microsoftu.

Omezení

Během této doby jsou následující funkce omezené. Tato omezení budou v budoucnu zrušena:

  • Nemůžete odstranit Skupinu prostředků, která obsahuje váš privátní cloud. Před odstraněním skupiny prostředků musíte nejprve odstranit privátní cloud.
  • Na jednu Azure virtuální síť můžete nasadit jenom 1 privátní cloud.
  • Pro každou skupinu prostředků můžete vytvořit pouze 1 privátní cloud. Více privátních cloudů v jedné skupině prostředků se nepodporuje.
  • Váš privátní cloud a virtuální síť pro tento privátní cloud musí být ve stejné skupině prostředků.
  • Po vytvoření privátního cloudu nemůžete přesunout privátní cloud z jedné skupiny prostředků do jiné.
  • Po vytvoření privátního cloudu nemůžete přesunout privátní cloud z jednoho tenanta do druhého.
  • Pokud potřebujete ExpressRoute FastPath nebo Global Virtual Network Peering pro privátní cloud AVS, vytvořte případ podpory prostřednictvím portálu Azure.
  • Service Endpoints nepodporují přímé připojení z úloh Řešení Azure VMware.
  • Koncové body privátní, které jsou globálně propojeny napříč oblastmi připojenými k Řešení Azure VMware, nejsou podporovány.
  • vCloud Director s podporou privátních koncových bodů je podporován. Použití vCloud Director s veřejnými koncovými body ale není podporováno.
  • Roztažené clustery vSAN se nepodporují.
  • Public IP až k VMware NSX Microsoft Edge pro konfiguraci internetu není podporováno. Jaké možnosti internetu jsou podporované v možnostech připojení k internetu.
  • Během neplánované údržby , jako je selhání hardwaru hostitele , na některém z prvních čtyř hostitelů ve vašem softwarově definovaném datovém centru (SDDC) můžete zaznamenat dočasné přerušení připojení k síti North-South u některých úloh, které trvají až 30 sekund. North-South připojení odkazuje na provoz mezi úlohami AVS VMware a externími koncovými body nad rámec hraniční sítě NSX-T vrstvy 0 (T0), jako jsou služby Azure nebo místní prostředí. Toto omezení bylo odebráno v konkrétních Azure oblastech. Zkontrolujte, jestli je vaše oblast tímto omezením ovlivněná, a to tak, že zkontrolujete Azure podporu.  
  • Skupiny zabezpečení sítě přidružené k virtuální síti hostitele privátního cloudu musí být vytvořeny ve stejné skupině prostředků jako privátní cloud a jeho virtuální síť.
  • Odkazy mezi skupinami prostředků a mezi předplatnými ze zákaznických virtuálních sítí do virtuální sítě Řešení Azure VMware se ve výchozím nastavení nepodporují. Patří sem typy prostředků, jako jsou trasy definované uživatelem, plány ochrany DDoS a další propojené síťové prostředky. Pokud je k jedné z těchto odkazů přidružená virtuální síť zákazníka, která se nachází v jiné skupině prostředků nebo předplatném, než je Řešení Azure VMware virtuální síť, může selhat programování sítě (například šíření segmentu NSX). Aby se zákazníci vyhnuli problémům, měli by se ujistit, že Řešení Azure VMware virtuální síť není připojená k prostředkům v jiné skupině prostředků nebo předplatném. Než budete pokračovat, odeberte z virtuální sítě veškerá taková připojení, jako jsou například plány ochrany před útoky DDoS.
    • Chcete-li zachovat odkaz napříč skupinami prostředků, vytvořte ve své skupině prostředků nebo předplatném přiřazení role a aplikaci „AzS VIS Prod App“ přiřaďte roli „AVS on Fleet VIS Role“. Toto přiřazení role vám umožní použít referenci a zajistí, že se správně uplatní pro váš privátní cloud Řešení Azure VMware.
  • Privátní cloud Gen 2 deployments může selhat, pokud zásady Azure vynucují přísná pravidla pro skupiny zabezpečení sítě nebo směrovací tabulky (například konkrétní zásady vytváření názvů). Tato omezení zásad můžou blokovat požadované skupiny zabezpečení sítě Řešení Azure VMware a vytváření směrovacích tabulek během nasazování. Před nasazením privátního cloudu je nutné tyto zásady odebrat z virtuální sítě Řešení Azure VMware. Po nasazení privátního cloudu je možné tyto zásady přidat zpět do vašeho Řešení Azure VMware privátního cloudu.
  • Pokud pro privátní cloud Řešení Azure VMware Gen 2 používáte Privátní DNS, použití Custom DNS ve virtuální síti, ve které je privátní cloud Řešení Azure VMware Gen 2 nasazen, není podporováno. Vlastní DNS přeruší operace životního cyklu, jako je škálování, upgrady a opravy.
  • Pokud odstraňujete privátní cloud a některé prostředky vytvořené službou Řešení Azure VMware se neodstraní, můžete odstranění privátního cloudu Řešení Azure VMware zopakovat pomocí Azure CLI.
  • Řešení Azure VMware Gen2 používá k rozlišení síťového provozu zákazníka a správy proxy server HTTP. Některé koncové body cloudové služby VMware nemusí dodržovat stejná pravidla síťové cesty nebo proxy serveru jako obecný provoz spravovaný vCenter. Mezi příklady patří: "scapi.vmware" a "apigw.vmware". Proxy VAMI řídí obecný odchozí internetový přístup zařízení vCenter Server (VCSA), ale ne všechny interakce koncových bodů služby procházejí tímto proxy serverem. Některé interakce pocházejí přímo z prohlížeče uživatele nebo z komponent integrace, které místo toho dodržují nastavení proxy serveru pracovní stanice nebo inicializuje připojení nezávisle. V důsledku toho může provoz do koncových bodů cloudové služby VMware zcela obejít proxy server VCSA.
  • HCX RAV a hromadné migrace na Gen 2 mohou vykazovat nižší výkon kvůli prodlevám během fází Base Sync a Online Sync. Zákazníci by teď měli plánovat delší časové období migrace a plánovat vlny odpovídajícím způsobem. Pro vhodné úlohy nabízí vMotion rychlejší možnost s nízkou režijní zátěží, pokud to umožňují podmínky hostitele a sítě.
  • Partnerské propojení Virtual HUB (virtual WAN): Chcete-li vytvořit partnerské propojení mezi virtuální sítí Gen-2 a virtuálním rozbočovačem (virtual WAN), musí být virtuální rozbočovač ve stejné oblasti jako virtuální síť Gen-2. Pokud potřebujete vytvořit partnerský vztah s virtuálním centrem v jiné oblasti, musíte vytvořit případ podpory prostřednictvím portálu Azure.
  • /32 cíl trasy z propojené virtuální sítě (VNET): Pokud oznamujete trasy /32 z NSX (například trasy HCX MON nebo trasy DNS forwarderu) a potřebujete přístup k tomuto cíli /32 z propojené virtuální sítě, musíte na webu Azure Portal vytvořit žádost o podporu. Připojení k cíli /32 funguje správně z místní virtuální sítě.
  • Oznamování podsítě VNET Peer Sync a přidružení ke směrovací tabulce Azure (UDR) – Řešení Azure VMware Gen 2 využívá dvě interní architektury. Aktuální architektura synchronizuje konkrétní podsítě i širší adresní prostor Azure pro segment NSX nebo trasy podsítí s partnerskými Azure virtuálními sítěmi. Díky současné architektuře Gen 2 možná budete muset nakonfigurovat Azure směrovací tabulky (UDR) s konkrétnějšími trasami podsítě segmentu NSX, a ne pomocí obecných tras adresního prostoru pro segmenty úloh Řešení Azure VMware.
  • Azure NAT gateway není podporován pro Gen-2 workloady.
  • Azure Subnet peering není podporován u privátních cloudových subnetů generace 2.

Nepodporované integrace

Následující vlastní a třetí strany integrace nejsou k dispozici:

  • Zerto Disaster Recovery

Delegovaná podsítě a skupiny zabezpečení sítě pro Gen 2

Když je nasazen privátní cloud Řešení Azure VMware (AVS) Gen2, Azure automaticky vytvoří několik delegovaných podsítí v rámci hostitelské virtuální sítě privátního cloudu. Tyto podsítě slouží k izolaci a ochraně komponent správy privátního cloudu.

Zákazníci můžou spravovat přístup k těmto podsítím pomocí skupin zabezpečení sítě (NSG), které jsou viditelné na portálu Azure nebo prostřednictvím Azure CLI/PowerShellu. Kromě NSG, které může spravovat zákazník, AVS používá na kritická rozhraní pro správu také další NSG spravované systémem. Tyto skupiny zabezpečení sítě spravované systémem nejsou viditelné ani upravovatelné zákazníky a existují, aby se zajistilo, že privátní cloud zůstane ve výchozím nastavení zabezpečený.

Jako součást výchozího stavu zabezpečení:

  • Přístup k internetu je pro privátní cloud zakázaný, pokud ho zákazník explicitně nepovolí.
  • K platformovým službám je povolen přístup pouze pro nezbytný provoz správy.

Poznámka:

Na portálu Azure se může zobrazit upozornění, které značí, že některé porty se zobrazují jako přístupné z internetu. K tomu dochází, protože portál vyhodnocuje pouze konfiguraci skupiny zabezpečení sítě (NSG) viditelnou zákazníkem. Řešení Azure VMware ale také použije další skupiny zabezpečení sítě spravované systémem, které nejsou na portálu viditelné. Tyto skupiny zabezpečení sítě spravované systémem blokují příchozí provoz, pokud nebyl explicitně povolen přístup prostřednictvím konfigurace Řešení Azure VMware.

Tento návrh udržuje prostředí AVS ve výchozím nastavení zabezpečené a oddělené a zároveň umožňuje zákazníkům spravovat a upravovat síťový přístup tak, aby vyhovoval jejich potřebám.

Úvahy o směrování a podsítích

privátní cloudy Řešení Azure VMware Gen2 poskytují prostředí privátního cloudu VMware přístupné uživatelům a aplikacím z místních a Azure prostředí nebo prostředků. Připojení se dodává prostřednictvím standardních Azure sítí. K povolení těchto služeb se vyžadují konkrétní rozsahy síťových adres a porty brány firewall. Tato část vám pomůže nakonfigurovat sítě tak, aby fungovaly s Řešení Azure VMware.

Privátní cloud se připojuje k virtuální síti Azure pomocí standardních Azure sítí. Řešení Azure VMware privátní cloudy Gen2 vyžadují pro podsítě minimálně blok síťových adres CIDR /22. Tato síť doplňuje vaše místní sítě, takže by se blok adres neměl překrývat s bloky adres používanými v jiných virtuálních sítích ve vašem předplatném a místních sítích. Sítě pro správu, vMotion a Replikaci se v rámci tohoto bloku adresy zřizují automaticky jako podsítě ve vaší virtuální síti.

Poznámka:

Povolené rozsahy pro váš blok adres jsou privátní adresní prostory RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), s výjimkou 172.17.0.0/16. Síť replikace není použitelná pro uzly AV64 a je plánována k obecnému vyřazení v budoucnu.

Nepoužívejte následující schéma PROTOKOLU IP vyhrazené pro použití VMware NSX:

  • 169.254.0.0/24 – používá se pro interní tranzitní síť
  • 169.254.2.0/23 – používá se pro tranzitní síť inter-VRF
  • 100.64.0.0/16 – slouží k internímu připojení bran T1 a T0
  • 100.73.x.x – používá se v síti pro správu Microsoftu.

Poznámka:

Většina podsítí uvedených v tabulce se zobrazí jako podsítě v rámci Azure virtuální sítě. Neprovádějte prosím ruční změny konfigurace podsítě na nich, protože jsou spravovány řídicí rovinou Řešení Azure VMware a jakékoli úpravy by mohly mít negativní důsledky.

Příklad /22 blok síťové adresy CIDR 10.31.0.0/22 je rozdělen do následujících podsítí:

Poznámka:

Síťový adresní blok /22 CIDR je vyhrazen výhradně pro interní správu a řídicí plochu Řešení Azure VMware. Nepoužívejte žádné jeho podsítě k jiným účelům, včetně případů použití privátního cloudu.

Využití sítě Subnet Description Příklad
Síť VMware NSX /27 Síť NSX Manager. 10.31.0.0/27
Síť vCSA /27 Síť vCenter Serveru. 10.31.0.32/27
avs-mgmt /27 Zařízení pro správu (vCenter Server, správce NSX a správce cloudu HCX) jsou za podsítí avs-mgmt, naprogramovaná jako sekundární rozsahy IP adres v této podsíti. Pokud se síťový provoz pro vaše správní zařízení musí směrovat přes NVA nebo bránu firewall, možná budete muset upravit směrovací tabulky přidružené k této podsíti. 10.31.0.64/27
avs-vnet-sync /27 Používá se Řešení Azure VMware Gen 2 k programování tras vytvořených ve VMware NSX do virtuální sítě. 10.31.0.96/27
avs-services /27 Používá se pro služby poskytovatele Řešení Azure VMware Gen2. Používá se také ke konfiguraci soukromého rozlišení DNS pro váš privátní cloud. 10.31.0.224/27
AVS-NSX-GW, AVS-NSX-GW-1 /27 Dvě podsítě avs-nsx-gw zpracovávají veškerý odchozí provoz z Řešení Azure VMware do Virtual Network a dál. Proto by ve všech scénářích měly být na tyto podsítě aplikovány směrovací tabulky Azure (UDR) a skupiny zabezpečení sítě (NSG). V počátečních privátních cloudech AVS Gen-2 tyto podsítě také spravují příchozí provoz se všemi podsítěmi segmentů NSX nakonfigurovanými jako sekundární IP adresy. V aktuálních privátních cloudech AVS Gen-2 se přidá třetí podsíť označovaná jako "avs-network-infra-gw" pro zpracování veškerého příchozího provozu. Nyní jsou všechny segmenty NSX přiřazeny k této podsíti místo podsítí avs-nsx-gw. 10.31.0.128/27, 10.31.0.160/27
avs-network-infra-gw /26 Pokud je tato podsíť přítomna, obsluhuje příchozí provoz pro všechny úlohy NSX z VNET a správa řešení Řešení Azure VMware ji používá ke konfiguraci podsítí segmentů NSX jako sekundárních adres IP. Vyhněte se přidružení žádné Azure směrovací tabulky k této podsíti. Místo toho použijte podsíť avs-nsx-gw ke správě odchozích přenosů AVS, například k Azure Firewall nebo síťovým virtuálním zařízením (NVA) třetích stran. 10.31.2.128/26
esx-mgmt-vmk1 /25 vmk1 je rozhraní pro správu používané zákazníky pro přístup k hostiteli. IP adresy z rozhraní vmk1 pocházejí z těchto podsítí. Veškerý provoz vmk1 pro všechny hostitele pochází z tohoto rozsahu podsítí. 10.31.1.0/25
esx-vmotion-vmk2 /25 rozhraní vMotion VMkernel. 10.31.1.128/25
esx-vsan-vmk3 /25 rozhraní vSAN VMkernel a komunikace uzlů 10.31.2.0/25
Rezervováno /27 Rezervované místo. 10.31.0.128/27
Rezervováno /27 Rezervované místo. 10.31.0.192/27

Poznámka:

Pro nasazení Řešení Azure VMware Gen2 teď zákazníci musí přidělit dvě další podsítě /24 pro správu a odesílání HCX, kromě /22 zadané během nasazování SDDC. V AVS Gen 2 jsou vyžadovány pouze podsítě HCX mgmt a HCX uplink. Sítě vMotion a replikace se pro AVS Gen2 nevyžadují.

NSX Směruje programování do Azure Virtual Network

Směrovací trasy NSX Gen-2 ve službě Řešení Azure VMware jsou integrovány do Azure pomocí adresního prostoru a jejich přiřazením jako sekundárních IP adres v systémem vytvořené podsíti „avs-network-infra-gw“, což umožňuje bezproblémovou konektivitu mezi Azure a zákaznickými úlohami AVS. Když NSX Tier-0 na základě uživatelského nastavení oznamuje trasu, například při vytváření segmentů, přidávání statických tras nebo použití virtuálních počítačů HCX MON, řídicí rovina Řešení Azure VMware ověří, zda předpona trasy existuje v adresním prostoru virtuální sítě. Pokud neexistuje, vytvoří adresní prostor a přidá prefix trasy jako sekundární IP adresy v podsíti „avs-network-infra-gw“. U inzerovaných tras /32 úrovně 0, jako jsou trasy HCX MON, nejsou nastavené sekundární IP adresy, ale rovina dat je interně nakonfigurovaná tak, aby se zajistilo připojení k cílům /32 v Řešení Azure VMware.

Kromě adresního prostoru a aktualizace podsítě pro trasy NSX existuje interní programování, o které by zákazníci měli vědět, zejména pokud jde o podporované škálování při použití nižších masek podsítě. Další informace o aspektu škálování najdete v tématu o architektuře Route pro Řešení Azure VMware Gen 2

Informace o přidružení směrovací tabulky Azure (UDR)

Řešení Azure VMware Gen-2 zahrnuje dvě interní architektury s mírnou variací. Některé z počátečních privátních cloudů Gen-2 používají počáteční interní architekturu. Tyto aktualizace se aktualizují na aktuální architekturu prostřednictvím plánované údržby, která je koordinovaná se zákazníkem. V současné architektuře se ale mění chování oproti počáteční architektuře, které můžou mít vliv na určité aspekty návrhu sítě, jak je popsáno níže.

Počáteční privátní cloud Gen-2:

  • Azure VNET má dvě základní podsítě brány s názvem „avs-nsx-gw“ a na rozdíl od aktuální architektury neobsahuje podsíť „avs-network-infra-gw“.
  • Všechny podsítě segmentu NSX AVS jsou naprogramované v podsíti avs-nsx-gw jako další IPv4 adresa pro připojení Azure k úlohám NSX.
  • Směrovací tabulku (UDR) nebo Azure NSG pro provoz z AVS do Azure Virtual Network (VNET) a dále (například do místního prostředí) je třeba použít na podsíť „avs-nsx-gw“.

Soukromý cloud Current Gen-2:

Nezapomeňte si tuto změnu v chování poznamenat.

  • V síti Azure VNET by se zobrazila další podsíť s předponou „avs-network-infra-gw“ spolu se dvěma základními podsítěmi brány s názvem „avs-nsx-gw“, stejně jako v původní architektuře.
  • Všechny podsítě segmentů AVS NSX jsou teď naprogramované v rámci této podsítě jako sekundární IPv4 adresa pro připojení Azure k úlohám NSX. Tím se nezmění síťové připojení zákazníka.
  • Partnerské propojení virtuálních sítí oznamuje partnerské virtuální síti jak adresní prostor, tak i podsítě, což se liší od původní architektury nebo nativní synchronizace virtuálních sítí v Azure, kde se synchronizuje pouze adresní prostor.

Diagram znázorňující nativní podsítě brány Gen-2

Aspekty návrhu kvůli změnám interní architektury Gen-2

  • Zákazníci zaznamenávají další efektivní trasy pro podsítě AVS v partnersky propojené virtuální síti kvůli změně chování synchronizace partnerských vztahů virtuálních sítí.
  • Pokud zákazník používá směrovací tabulku Azure (UDR) k odesílání provozu z místního prostředí do AVS přes bránu firewall nebo síťové virtuální zařízení, měl by tabulku UDR aktualizovat tak, aby používala konkrétní trasy pro podsítě NSX místo dříve používaného širokého rozsahu adres supernetu. To je nutné, aby se zabránilo tomu, že provoz určený pro AVS bude využívat specifičtější trasy podsítě VNET a obcházet zamýšlený firewall kvůli chování směrování Azure při výběru podle nejdelší shody prefixu . Jinak to může vést k asymetrickým směrováním, což může způsobit problémy s připojením.
  • Nicméně směrovací tabulka (UDR) nebo Azure NSG pro provoz z AVS do Azure VNET a dále (například do místního prostředí) by se nadále uplatňovala na podsítě „avs-nsx-gw“, nikoli „avs-network-infra-gw“. Zákazníci by neměli používat směrovací tabulku (UDR) v podsíti "avs-network-infra-gw", i když jsou podsítě segmentů NSX nakonfigurované jako sekundární IP adresy.

Další kroky

  • Last updated on