Designöverväganden för privata moln i Azure VMware Solution generation 2

Den här artikeln beskriver viktiga designöverväganden för privata moln i Azure VMware Solution generation 2 (Gen 2). Den förklarar de funktioner som den här generationen ger till VMware-baserade privata molnmiljöer, vilket ger åtkomst för dina program från både lokal infrastruktur och Azure-baserade resurser. Det finns flera saker att tänka på innan du konfigurerar ditt privata Azure VMware Solution Gen 2-moln. Den här artikeln ger lösningar för användningsfall som du kan stöta på när du använder den privata molntypen.

Begränsningar

Under denna tid är följande funktionalitet begränsad. Dessa begränsningar kommer att lyftas i framtiden.

• Du kan inte ta bort resursgruppen som innehåller ditt privata moln. Du måste ta bort det privata molnet först innan du tar bort resursgruppen.
• Du kan bara distribuera ett privat moln per Azure-virtuellt nätverk.
• Du kan bara skapa ett privat moln per resursgrupp. Flera privata moln i en enskild resursgrupp stöds inte.
• Ditt privata moln och virtuella nätverk för ditt privata moln måste finnas i samma resursgrupp.
• Du kan inte flytta ditt privata moln från en resursgrupp till en annan när det privata molnet har skapats.
• Du kan inte flytta ditt privata moln från en klientorganisation till en annan när det privata molnet har skapats.
• Om du behöver ExpressRoute FastPath eller Global Virtual Network Peering för ditt privata AVS-moln skapar du ett supportärende via Azure-portalen.
• Tjänsteslutpunkter direktanslutning för arbetsbelastningar från Azure VMware Solution stöds inte.
• Privata slutpunkter som är globalt sammankopplade mellan regioner anslutna till Azure VMware Solution stöds inte.
• vCloud Director med privata slutpunkter stöds. vCloud Director som använder offentliga slutpunkter stöds inte dock.
• vSAN Stretch Clusters stöds inte.
• Offentlig IP hela vägen till VMware NSX Microsoft Edge för internetkonfiguration stöds inte. Du hittar vilka Internetalternativ som stöds i Alternativ för Internetanslutning.
• Vid oplanerat underhåll – till exempel ett maskinvarufel på en värd – på någon av de fyra första värdarna i ditt programvarudefinierade datacenter (SDDC) kan du uppleva ett tillfälligt avbrott i North-South-nätverksanslutningen för vissa arbetslaster, som varar i upp till 30 sekunder. North-South-anslutning refererar till trafik mellan dina AVS VMware-arbetsbelastningar och externa slutpunkter utöver NSX-T Nivå 0 (T0) Edge, till exempel Azure tjänster eller lokala miljöer. Den här begränsningen har tagits bort i specifika Azure regioner. Bekräfta om din region påverkas av den här begränsningen genom att kontrollera med Azure Support.  
• Nätverkssäkerhetsgrupper som är associerade med det privata molnvärdens virtuella nätverk måste skapas i samma resursgrupp som det privata molnet och dess virtuella nätverk.
• Referenser över resursgrupper och mellan prenumerationer från kunders virtuella nätverk till det virtuella nätverket i Azure VMware Solution stöds inte som standard. Detta omfattar resurstyper som: Användardefinierade vägar (UDR), DDoS Protection-planer och andra länkade nätverksresurser. Om ett virtuellt kundnätverk är associerat med en av dessa referenser som finns i en annan resursgrupp eller prenumeration än det Azure VMware Solution virtuella nätverket kan nätverksprogrammering (till exempel spridning av NSX-segment) misslyckas. För att undvika problem bör kunderna se till att det Azure VMware Solution virtuella nätverket inte är anslutet till resurser i en annan resursgrupp eller prenumeration. Innan du fortsätter tar du bort sådana anslutningar, till exempel DDoS-skyddsplaner, från det virtuella nätverket.
  • För att behålla referensen över resursgrupper skapar du en rolltilldelning från din resursgrupp över resurser eller din prenumeration och ger "AzS VIS Prod App" rollen "AVS on Fleet VIS Role". Med rolltilldelningen kan du använda referensen och se till att den tillämpas korrekt för ditt privata moln i Azure VMware Solution.
• Gen 2 privata moln distributioner kan misslyckas om Azure principer tillämpar strikta regler för nätverkssäkerhetsgrupper eller routningstabeller (till exempel specifika namngivningskonventioner). Dessa policybegränsningar kan blockera nödvändiga skapanden av Azure VMware-lösningens nätverkssäkerhetsgrupp och routetabell vid distribution. Du måste ta bort dessa principer från det Azure VMware Solution virtuella nätverket innan du distribuerar ditt privata moln. När ditt privata moln har distribuerats kan dessa principer läggas till i ditt Azure VMware Solution privata moln.
• Om du använder Private DNS för ditt privata Azure VMware Solution Gen 2-moln stöds inte Anpassad DNS i det virtuella nätverket där ett privat Azure VMware Solution Gen 2-moln distribueras. Anpassad DNS bryter livscykelåtgärder som skalning, uppgraderingar och korrigeringar.
• Om du tar bort ditt privata moln och vissa resurser som har skapats av Azure VMware Solution inte tas bort, kan du försöka att ta bort det privata Azure VMware Solution-molnet igen med hjälp av Azure CLI.
• Azure VMware Solution Gen 2 använder en HTTP-proxy för att skilja mellan kund- och hanteringsnätverkstrafik. Vissa VMware-molntjänstslutpunkter kanske inte följer samma nätverkssökväg eller proxyregler som allmän vCenter-hanterad trafik. Exempel är: "scapi.vmware" och "apigw.vmware". VAMI-proxyn styr vCenter Server Appliances (VCSA) allmänna utgående Internetåtkomst, men inte alla interaktionsflöden för tjänstslutpunkter via den här proxyn. Vissa interaktioner kommer direkt från användarens webbläsare eller från integreringskomponenter, som i stället följer arbetsstationens proxyinställningar eller initierar anslutningar oberoende av varandra. Därför kan trafik till VMware-molntjänstslutpunkter kringgå VCSA-proxyn helt och hållet.
• HCX RAV och bulkmigreringar på Gen 2 kan få försämrad prestanda till följd av stopp under faserna Base Sync och Online Sync. Kunder bör planera för längre migreringsfönster och schemalägga vågor i enlighet med detta för tillfället. För lämpliga arbetsbelastningar erbjuder vMotion ett snabbare alternativ med låg omkostnad när värd- och nätverksvillkoren tillåter det.
• Virtual HUB-peering (virtual WAN): För att upprätta en peering-anslutning mellan ett virtuellt Gen-2-nätverk och en virtuell hubb (virtual WAN) måste den virtuella hubben finnas i samma region som det virtuella Gen-2-nätverket. Om du behöver peer-koppla med en virtuell hubb i en annan region måste du skapa ett supportärende via Azure-portalen.
• /32-routemål från peer-kopplat virtuellt nätverk (VNET): Om du annonserar /32-rutter från NSX (till exempel HCX MON-rutter eller rutter till DNS-vidarebefordrare) och behöver åtkomst till det /32-routemålet från ett peer-kopplat virtuellt nätverk måste du öppna ett supportärende i Azure-portalen. Anslutningen till /32-målet fungerar korrekt från det lokala virtuella nätverket.
• VNET Peer Sync-undernätsannons och Azure UDR-association (Route Table) – Azure VMware Solution Gen 2 använder två interna arkitekturer. Den aktuella arkitekturen synkroniserar både specifika undernät och det bredare Azure-adressutrymmet för rutter för NSX-segment eller undernät med peer-anslutna virtuella Azure-nätverk. Med Gen 2:s aktuella arkitektur kan du därför behöva konfigurera Azure routningstabeller (UDR) med mer specifika NSX-segmentundernätsvägar i stället för att använda allmänna adressutrymmesvägar för Azure VMware Solution arbetsbelastningssegment.

Integreringar som inte stöds

Följande integreringar från första part och tredje part är inte tillgängliga:

• Zerto DR

Delegerade undernät och nätverkssäkerhetsgrupper för Gen 2

När ett privat Azure VMware Solution (AVS) Gen 2 distribueras skapar Azure automatiskt flera delegerade undernät i det privata molnets virtuella värdnätverk. Dessa undernät används för att isolera och skydda det privata molnets hanteringskomponenter.

Kunder kan hantera åtkomst till dessa undernät med hjälp av nätverkssäkerhetsgrupper (NSG:er) som visas i Azure-portalen eller via Azure CLI/PowerShell. Förutom kundhanterade NSG:er tillämpar AVS extra systemhanterade NSG:er på kritiska hanteringsgränssnitt. Dessa systemhanterade NSG:er är inte synliga eller redigerbara av kunder och finns för att säkerställa att det privata molnet förblir säkert som standard.

Som en del av standardsäkerhetsstatusen:

• Internetåtkomst är inaktiverat för det privata molnet om inte kunden uttryckligen aktiverar det.
• Endast nödvändig hanteringstrafik tillåts nå plattformstjänster.

Den här designen håller AVS-miljön säker och separerad som standard, samtidigt som kunderna kan hantera och justera nätverksåtkomsten så att den passar deras behov.

Routnings- och undernätsöverväganden

Azure VMware Solution Privata Moln i Gen 2 tillhandahåller en privat VMware-molnmiljö som är tillgänglig för användare och program från lokala och Azure-baserade miljöer eller resurser. Anslutningen levereras via standardnätverk Azure. Specifika nätverksadressområden och brandväggsportar krävs för att möjliggöra dessa tjänster. Det här avsnittet hjälper dig att konfigurera nätverket så att det fungerar med Azure VMware Solution.

Det privata molnet ansluter till ditt Azure virtuella nätverk med hjälp av standardnätverk Azure. Azure VMware Solution privata moln i generation 2 kräver minst ett /22 CIDR-nätverksadressblock för subnät. Detta nätverk kompletterar dina lokala nätverk, så adressblocket bör inte överlappa med adressblock som används i andra virtuella nätverk inom din prenumeration och i lokala nätverk. Hanterings-, vMotion- och replikeringsnätverk etableras automatiskt i det här adressblocket som undernät i det virtuella nätverket.

Undvik att använda följande IP-schema som är reserverat för VMware NSX-användning:

• 169.254.0.0/24 - används för internt transitnätverk
• 169.254.2.0/23 - används för transitnätverk mellan olika VRF
• 100.64.0.0/16 - används för att ansluta T1- och T0-gateways internt
• 100.73.x.x – används av Microsofts hanteringsnätverk

Exempel /22 CIDR-nätverksadressblock 10.31.0.0/22 är indelat i följande undernät:

NSX Dirigerar programmering till Azure Virtual Network

Azure VMware Solution Gen-2 NSX-vägar integreras i Azure genom att använda adressutrymme och tilldela dem som sekundära IP-adresser i det systemskapade systemundernätet "avs-network-infra-gw", vilket möjliggör smidig anslutning mellan Azure- och AVS-kundarbetsbelastningar. När NSX Tier-0 annonserar en väg baserat på användarinställningar, till exempel att skapa segment, lägga till statiska vägar eller använda virtuella HCX MON-datorer, kontrollerar Azure VMware Solution kontrollplanet om routningsprefixet finns i det virtuella nätverkets adressutrymme. Om den inte gör det skapar den adressutrymmet och lägger till routningsprefixet som sekundära IP-adresser i undernätet "avs-network-infra-gw". För nivå 0-annonserade /32-vägar, till exempel HCX MON-vägar, anges inte sekundära IP-adresser, men dataplanet är internt konfigurerat för att säkerställa anslutning till /32-mål på Azure VMware Solution.

Utöver uppdateringen av adressutrymme och undernät för NSX-rutter finns det intern logik som kunder bör känna till, särskilt när det gäller vilken skalning som stöds när mindre undernätsmasker används. Mer information om skalningsaspekten finns i Route-arkitektur för Azure VMware Solution Gen 2

Att tänka på vid association av Azure-routningstabell (UDR)

Azure VMware Solution Gen-2 innehåller två interna arkitekturer, med liten variation. Några av de första privata Gen-2-molnen använder den ursprungliga interna arkitekturen. Dessa uppdateras till den aktuella arkitekturen via schemalagt underhåll, samordnat med kunden. Det finns dock en förändring i beteendet i den aktuella arkitekturen jämfört med den ursprungliga arkitekturen, vilket kan påverka vissa överväganden kring nätverksdesign, enligt beskrivningen nedan.

Första privata Gen-2-moln:

• Azure VNET har två basgatewayundernät med namnet "avs-nsx-gw" och har inte undernätet "avs-network-infra-gw" som i den aktuella arkitekturen.
• Alla AVS NSX-segmentundernät programmeras under undernätet "avs-nsx-gw" som ytterligare IPv4-adress för att ansluta Azure till NSX-arbetsbelastningar.
• Routningstabellen (UDR) eller Azure NSG:n för trafik från AVS till Azure VNet och vidare (till exempel lokalt) måste tillämpas på undernätet "avs-nsx-gw".

Nuvarande privata Gen-2-moln:

Observera den här ändringen av beteendet.

• Azure VNET skulle se ytterligare undernät med prefixet "avs-network-infra-gw" tillsammans med två basgatewayundernät med namnet "avs-nsx-gw" som i den ursprungliga arkitekturen.
• Alla AVS NSX-segmentundernät är nu programmerade under det här undernätet som sekundär IPv4-adress för att ansluta Azure till NSX-arbetsbelastningar. Detta ändrar inte kundens nätverksanslutning.
• VNET-peering meddelar både adressutrymmet och undernäten till det peer-kopplade virtuella nätverket, vilket skiljer sig från den ursprungliga arkitekturen eller Azures inbyggda VNET-synkronisering där endast adressutrymmet synkroniseras.

Designöverväganden på grund av ändringar i intern arkitektur i Gen-2

• Kunder observerar ytterligare effektiva vägar för AVS-undernät i det peerkopplade virtuella nätverket på grund av ändringar i VNET-peersynkroniseringsbeteendet.
• Om en kund använder en Azure routningstabell (UDR) för att skicka trafik från lokal till AVS via en brandvägg eller en virtuell nätverksinstallation bör de uppdatera UDR för att använda specifika NSX-undernätsvägar i stället för det breda supernätadressintervall som användes tidigare. Detta krävs för att förhindra att trafik avsedd för AVS följer mer specifika VNET-undernätsrutter och därmed kringgår den avsedda brandväggen på grund av beteendet för längsta prefixmatchning i Azures routning. Annars kan detta resultera i asymmetrisk routning, vilket kan orsaka anslutningsproblem.
• Routningstabellen (UDR) eller Azure NSG för trafik från AVS till Azure VNET och senare (till exempel lokalt) skulle dock fortsätta att tillämpas på undernäten "avs-nsx-gw", inte "avs-network-infra-gw". Kunder bör inte använda routningstabellen (UDR) i undernätet "avs-network-infra-gw", även om NSX-segmentundernät konfigureras där som sekundära IP-adresser.

Nästa steg

• Kom igång med att konfigurera ditt Azure VMware Solution tjänsthuvud som ett krav. För att lära dig hur, se kom-igång-guiden Enabling Azure VMware Solution service principal.

• Följ en självstudiekurs för Skapa ett Azure VMware Gen 2 Private Cloud