Ontwerpoverwegingen voor Azure VMware Solution privéclouds van de tweede generatie

In dit artikel worden belangrijke ontwerpoverwegingen beschreven voor privéclouds van Azure VMware Solution generatie 2 (Gen 2). In dit artikel worden de mogelijkheden van deze generatie uitgelegd in VMware-omgevingen voor privéclouds, waardoor toegang voor uw toepassingen mogelijk is vanuit zowel on-premises infrastructuur als Azure-resources. Er zijn verschillende overwegingen die u moet bekijken voordat u uw Azure VMware Solution Gen 2-privécloud instelt. Dit artikel bevat oplossingen voor gebruiksvoorbeelden die u kunt tegenkomen wanneer u het type privécloud gebruikt.

Beperkingen

De volgende functionaliteit is gedurende deze periode beperkt. Deze beperkingen worden in de toekomst opgeheven:

• U kunt uw resourcegroep, die uw privécloud bevat, niet verwijderen. U moet eerst de privécloud verwijderen voordat u de resourcegroep verwijdert.
• U kunt alleen 1 privécloud implementeren per Azure Virtual Network.
• U kunt slechts één privécloud maken per resourcegroep. Meerdere privéclouds in één resourcegroep worden niet ondersteund.
• Uw privécloud en virtueel netwerk voor uw privécloud moeten zich in dezelfde resourcegroep bevinden.
• U kunt uw privécloud niet van de ene resourcegroep naar de andere verplaatsen nadat de privécloud is gemaakt.
• U kunt uw privécloud niet van de ene tenant naar de andere verplaatsen nadat de privécloud is gemaakt.
• Als u ExpressRoute FastPath of Global Virtual Network Peering voor uw AVS-privécloud nodig hebt, maakt u een ondersteuningsaanvraag via de Azure-portal.
• Service-eindpunten directe connectiviteit voor Azure VMware Solution workloads wordt niet ondersteund.
• Private-eindpunten die globaal gepaird zijn tussen regio's die zijn verbonden met Azure VMware Solution, worden niet ondersteund.
• vCloud Director met behulp van privé-eindpunten wordt ondersteund. vCloud Director met behulp van openbare eindpunten wordt echter niet ondersteund.
• vSAN Stretched Clusters wordt niet ondersteund.
• Public IP tot aan de VMware NSX Microsoft Edge voor internetconfiguratie wordt niet ondersteund. U kunt vinden welke internetopties worden ondersteund in opties voor internetverbinding.
• Tijdens niet-gepland onderhoud , zoals een hosthardwarefout, op een van de eerste vier hosts in uw Software Defined Data Center (SDDC), kan er een tijdelijke North-South netwerkverbindingsonderbreking optreden voor sommige workloads, die maximaal 30 seconden duren. North-South verbinding verwijst naar verkeer tussen uw AVS VMware-workloads en externe eindpunten buiten de NSX-T Tier-0 (T0) Edge, zoals Azure Services of on-premises omgevingen. Deze beperking is verwijderd in specifieke Azure regio's. Controleer of uw regio wordt beïnvloed door deze beperking door te controleren op Azure Ondersteuning.  
• Netwerkbeveiligingsgroepen die zijn gekoppeld aan het virtuele netwerk van de privécloudhost moeten worden gemaakt in dezelfde resourcegroep als de privécloud en het bijbehorende virtuele netwerk.
• Verwijzingen tussen resourcegroepen en tussen abonnementen van virtuele klantnetwerken naar het virtuele Azure VMware Solution-netwerk worden standaard niet ondersteund. Dit omvat resourcetypen zoals: door de gebruiker gedefinieerde routes (UDR's), DDoS-beveiligingsplannen en andere gekoppelde netwerkresources. Als een virtueel netwerk van een klant is gekoppeld aan een van deze verwijzingen die zich in een andere resourcegroep of een ander abonnement bevinden dan het Azure VMware Solution virtuele netwerk, kan netwerkprogrammering (zoals NSX-segmentdoorgifte) mislukken. Om problemen te voorkomen, moeten klanten ervoor zorgen dat het Azure VMware Solution virtueel netwerk niet is verbonden met resources in een andere resourcegroep of een ander abonnement. Voordat u doorgaat, verwijdert u dergelijke verbindingen, zoals DDoS-beveiligingsplannen, uit het virtuele netwerk.
  • Als u uw resourcegroepoverschrijdende verwijzing wilt behouden, maakt u een roltoewijzing vanuit uw resourcegroep of abonnement voor resourcegroepoverschrijdende verwijzingen en geeft u de 'AzS VIS Prod App' de 'AVS on Fleet VIS Role'. Met de roltoewijzing kunt u de verwijzing gebruiken, zodat deze correct wordt toegepast op uw Azure VMware Solution-private cloud.
• Gen 2-privécloud deployments kunnen mislukken als Azure-beleidsregels strikte regels afdwingen voor netwerkbeveiligingsgroepen of routetabellen, bijvoorbeeld specifieke naamconventies. Deze beleidsbeperkingen kunnen de vereiste Azure VMware Solution netwerkbeveiligingsgroep en het maken van routetabellen tijdens de implementatie blokkeren. U moet dit beleid verwijderen uit het Azure VMware Solution virtuele netwerk voordat u uw privécloud implementeert. Zodra uw privécloud is geïmplementeerd, kunnen deze beleidsregels worden toegevoegd aan uw Azure VMware Solution privécloud.
• Als u Privé-DNS gebruikt voor uw Azure VMware Solution Gen 2-privécloud, wordt Custom DNS op het virtuele netwerk waarop een Azure VMware Solution Gen 2-privécloud wordt geïmplementeerd, niet ondersteund. Aangepaste DNS onderbreken levenscyclusoperaties zoals schalen, upgrades en patchen.
• Als u uw privécloud verwijdert en sommige door Azure VMware Solution gemaakte resources niet worden verwijderd, kunt u het verwijderen van de Azure VMware Solution-privécloud opnieuw uitvoeren met de Azure CLI.
• Azure VMware Solution Gen 2 maakt gebruik van een HTTP-proxy om onderscheid te maken tussen klant- en beheernetwerkverkeer. Bepaalde VMware-cloudservice-eindpunten volgen mogelijk niet hetzelfde netwerkpad of dezelfde proxyregels als algemeen door vCenter beheerd verkeer. Voorbeelden zijn: 'scapi.vmware' en 'apigw.vmware'. De VAMI-proxy bepaalt de algemene uitgaande internettoegang van het vCenter Server-apparaat (VCSA), maar niet alle interacties tussen service-eindpunten via deze proxy. Sommige interacties zijn rechtstreeks afkomstig van de browser van de gebruiker of van integratieonderdelen, die in plaats daarvan de proxy-instellingen van het werkstation volgen of verbindingen onafhankelijk initiëren. Als gevolg hiervan kan verkeer naar VMware-cloudservice-eindpunten de VCSA-proxy volledig omzeilen.
• HCX RAV en bulkmigraties op Gen 2-systemen kunnen trager zijn als gevolg van vertragingen tijdens de fasen Base Sync en Online Sync. Klanten moeten nu rekening houden met langere migratievensters en de golven dienovereenkomstig inplannen. Voor geschikte workloads biedt vMotion een snellere optie voor lage overhead wanneer host- en netwerkomstandigheden zijn toegestaan.
• Virtual HUB-peering (virtual WAN): als u een peeringverbinding tot stand wilt brengen tussen een virtueel gen-2-netwerk en een virtuele hub (virtual WAN), moet de virtuele hub zich in dezelfde regio bevinden als het virtuele Gen-2-netwerk. Als u wilt peeren met een virtuele hub in een andere regio, moet u een ondersteuningsaanvraag maken via de Azure-portal.
• /32-routebestemming vanuit een gekoppeld Virtual Network (VNET): Als u /32-routes vanuit NSX adverteert (zoals HCX MON-routes of DNS-doorstuurroutes) en toegang nodig hebt tot die /32-bestemming vanuit een gekoppeld Virtual Network, moet u in de Azure-portal een supportaanvraag openen. De verbinding met de /32-bestemming werkt correct vanuit het lokale VNET.
• VNET Peer Sync Subnet-advertentie en Azure UDR-koppeling (Route Table): Azure VMware Solution Gen2 maakt gebruik van twee interne architecturen. De huidige architectuur synchroniseert zowel specifieke subnetten als de bredere Azure adresruimte voor NSX-segment- of subnetroutes met gekoppelde Azure virtuele netwerken. Als gevolg hiervan moet u met de huidige architectuur van Gen 2 mogelijk Azure routetabellen (UDR) configureren met specifiekere NSX-segmentsubnetroutes in plaats van algemene adresruimteroutes te gebruiken voor Azure VMware Solution workloadsegmenten.

Niet-ondersteunde integraties

De volgende integraties van de eerste partij en derden zijn niet beschikbaar:

• Zerto DR

Gedelegeerde subnetten en netwerkbeveiligingsgroepen voor Gen 2

Wanneer een Azure VMware Solution (AVS) Gen 2-privécloud wordt geïmplementeerd, maakt Azure automatisch verschillende gedelegeerde subnetten binnen het virtuele hostnetwerk van de privécloud. Deze subnetten worden gebruikt om de beheeronderdelen van de privécloud te isoleren en te beveiligen.

Klanten kunnen de toegang tot deze subnetten beheren met behulp van netwerkbeveiligingsgroepen (NSG's) die zichtbaar zijn in de Azure-portal of via Azure CLI/PowerShell. Naast klantbeheerbare NSG's past AVS extra door het systeem beheerde NSG's toe op kritieke beheerinterfaces. Deze door het systeem beheerde NSG's zijn niet zichtbaar of bewerkbaar door klanten en bestaan om ervoor te zorgen dat de privécloud standaard veilig blijft.

Als onderdeel van de standaardbeveiligingspostuur:

• Internettoegang is uitgeschakeld voor de privécloud, tenzij de klant deze expliciet inschakelt.
• Alleen vereist beheerverkeer is toegestaan om platformservices te bereiken.

Met dit ontwerp blijft de AVS-omgeving standaard beveiligd en gescheiden, terwijl klanten de netwerktoegang nog steeds kunnen beheren en aanpassen aan hun behoeften.

Overwegingen voor routering en subnetten

Azure VMware Solution Gen 2-privéclouds bieden een VMware-privécloudomgeving die toegankelijk is voor gebruikers en toepassingen vanuit on-premises en Azure omgevingen of resources. Connectiviteit wordt geleverd via standaard Azure Netwerken. Specifieke netwerkadresbereiken en firewallpoorten zijn vereist om deze services in te schakelen. In deze sectie kunt u uw netwerken configureren voor gebruik met Azure VMware Solution.

nl-NL: De privécloud maakt verbinding met uw Azure-virtuele netwerk met behulp van standaard Azure-netwerken. Voor Azure VMware Solution Gen 2-Privéclouds is een minimaal /22 CIDR-netwerkadresblok vereist voor subnetten. Dit netwerk vormt een aanvulling op uw on-premises netwerken, dus het adresblok mag niet overlappen met adresblokken die worden gebruikt in andere virtuele netwerken in uw abonnement en on-premises netwerken. Beheer-, vMotion- en replicatienetwerken worden automatisch ingericht binnen dit adresblok als subnetten in uw virtuele netwerk.

Vermijd het gebruik van het volgende IP-schema dat is gereserveerd voor VMware NSX-gebruik:

• 169.254.0.0/24 - gebruikt voor intern doorvoernetwerk
• 169.254.2.0/23 - gebruikt voor inter-VRF-transitnetwerk
• 100.64.0.0/16 - wordt gebruikt om intern verbinding te maken met T1- en T0-gateways
• 100.73.x.x – gebruikt door het beheernetwerk van Microsoft

Voorbeeld /22 CIDR-netwerkadresblok 10.31.0.0/22 is onderverdeeld in de volgende subnetten:

NSX-routes programmeren in het Azure Virtual Network

Azure VMware Solution Gen-2 NSX-routes zijn geïntegreerd in Azure door gebruik te maken van adresruimte en deze toe te wijzen als secundaire IP-adressen op het door het systeem gemaakte subnet avs-network-infra-gw, waardoor een soepele verbinding tussen Azure en AVS-klantworkloads mogelijk is. Wanneer NSX Tier-0 een route adverteert op basis van gebruikersinstellingen, zoals het maken van segmenten, het toevoegen van statische routes of het gebruik van virtuele HCX MON-machines, controleert het Azure VMware Solution besturingsvlak of het routevoorvoegsel bestaat in de adresruimte van het virtuele netwerk. Als dat niet het geval is, wordt de adresruimte gemaakt en wordt het routeprefix toegevoegd als secundaire IP-adressen op het subnet "avs-network-infra-gw". Voor geadverteerd /32-routes in laag-0, zoals HCX MON-routes, worden secundaire IP-adressen niet ingesteld, maar het gegevensvlak is intern geconfigureerd om connectiviteit met /32-bestemmingen op Azure VMware Solution te garanderen.

Naast de adresruimte en subnetupdate voor NSX-routes, is er interne programmering waar klanten rekening mee moeten houden, met name wat betreft ondersteunde schaal wanneer lagere subnetmaskers worden gebruikt. Zie Route-architectuur voor Azure VMware Solution Gen 2

Overwegingen bij de koppeling van Azure Route Table (UDR)

Azure VMware Solution Gen-2 bevat twee interne architecturen, met lichte variatie. Sommige van de eerste Gen-2-privéclouds maken gebruik van de initiële interne architectuur. Deze worden bijgewerkt naar de huidige architectuur via gepland onderhoud, gecoördineerd met de klant. Er is echter een wijziging in het gedrag met de huidige architectuur, vergeleken met de eerste architectuur, die van invloed kan zijn op bepaalde overwegingen bij het ontwerpen van netwerken, zoals hieronder wordt beschreven.

Eerste Gen-2 private clouds:

• Azure VNET heeft twee basis-subnetten voor gateways met de naam "avs-nsx-gw" en beschikt niet over het subnet "avs-network-infra-gw", zoals in de huidige architectuur.
• Alle AVS NSX-segmentsubnetten worden geprogrammeerd onder het subnet avs-nsx-gw als extra IPv4-adres voor het verbinden van Azure met NSX-workloads.
• De routetabel (UDR) of Azure NSG voor verkeer van AVS naar Azure VNET en verder (bijvoorbeeld on-premises) moet worden toegepast op het subnet avs-nsx-gw.

Huidige Gen-2-privécloud:

Noteer deze wijziging in gedrag.

• Azure VNET zou een extra subnet met het voorvoegsel "avs-network-infra-gw" bevatten, samen met twee basisgatewaysubnets met de naam "avs-nsx-gw", zoals in de oorspronkelijke architectuur.
• Alle AVS NSX-segmentsubnetten worden nu geprogrammeerd onder dit subnet als secundair IPv4-adres voor het verbinden van Azure met NSX-workloads. Hiermee wordt de netwerkverbinding van de klant niet gewijzigd.
• VNET-peering maakt zowel de adresruimte als de subnetten bekend aan het gepeerde VNET, wat verschilt van de oorspronkelijke architectuur of de systeemeigen VNET-synchronisatie van Azure, waarbij alleen de adresruimte wordt gesynchroniseerd.

Ontwerpoverwegingen vanwege wijzigingen in interne gen-2-architectuur

• Klanten observeren aanvullende effectieve routes voor AVS-subnetten binnen het gekoppelde VNET vanwege een wijziging in het gedrag van VNET-peersynchronisatie.
• Als een klant een Azure routetabel (UDR) gebruikt om verkeer van on-premises naar AVS te verzenden via een firewall of virtueel netwerkapparaat, moeten ze de UDR bijwerken om specifieke NSX-subnetroutes te gebruiken in plaats van het brede adresbereik voor supernetten dat eerder is gebruikt. Dit is vereist om te voorkomen dat verkeer dat bestemd is voor AVS via de specifiekere VNET-subnetroutes wordt geleid en daarmee de beoogde firewall omzeilt, vanwege het gedrag van Azure-routering op basis van de langste prefixovereenkomst. Anders kan dit leiden tot asymmetrische routering, waardoor er mogelijk verbindingsproblemen ontstaan.
• De routetabel (UDR) of Azure NSG voor verkeer van AVS naar Azure VNET en verder (bijvoorbeeld on-premises) blijft echter toegepast op de subnetten avs-nsx-gw, niet 'avs-network-infra-gw'. Klanten mogen de routetabel (UDR) niet gebruiken in het subnet avs-network-infra-gw, zelfs als subnetten van het NSX-segment daar zijn geconfigureerd als secundaire IP-adressen.

Volgende stappen

• Begin met het configureren van uw Azure VMware Solution service-principal als een voorvereiste. Zie de quickstart Enabling Azure VMware Solution service-principal voor instructies over het inschakelen van Azure VMware Solution service-principal.

• Volg een zelfstudie voor Creating an Azure VMware Gen 2 Private Cloud