Netwerkoverwegingen voor Azure VMware Solution implementaties met twee regio's

  • Artikel

In dit artikel wordt beschreven hoe u netwerkconnectiviteit configureert wanneer Azure VMware Solution privéclouds worden geïmplementeerd in twee Azure-regio's voor noodtolerantie. Als er sprake is van gedeeltelijke of volledige regionale storingen, kunnen de netwerktopologie in dit artikel de overlevende onderdelen (privéclouds, azure-resources en on-premises sites) verbinding met elkaar en met internet onderhouden.

Scenario met twee regio's

Dit artikel is gericht op een typisch scenario met twee regio's, zoals weergegeven in de volgende afbeelding 1:

  • In elke regio bestaat een Azure-hub- en spoke-netwerk.
  • Er is een noodbestendige configuratie voor ExpressRoute (twee circuits op twee verschillende peeringlocaties, waarbij elk circuit is verbonden met virtuele hubnetwerken in beide regio's) geïmplementeerd. De richtlijnen in de volgende secties blijven hetzelfde in het geval er een VPN-terugvalverbinding is geconfigureerd.
  • In elke regio is een Azure VMware Solution privécloud geïmplementeerd.

Diagram van afbeelding 1, waarin het scenario met twee regio's wordt weergegeven dat in dit artikel wordt behandeld.

Notitie

In het referentiescenario van afbeelding 1 zijn de twee virtuele netwerken van de regionale hub verbonden via wereldwijde VNet-peering. Hoewel dit niet strikt noodzakelijk is, wordt deze configuratie ten zeerste aangeraden omdat verkeer tussen virtuele Azure-netwerken in de twee regio's kan worden gerouteerd via ExpressRoute-verbindingen. VNet-peering minimaliseert de latentie en maximaliseert de doorvoer, omdat er geen hairpinverkeer meer nodig is via de ExpressRoute meet-me edge-routers.

Communicatiepatronen met twee regio's

In de volgende secties worden de Azure VMware Solution netwerkconfiguratie beschreven die nodig is om in het referentiescenario met twee regio's de volgende communicatiepatronen in te schakelen:

Azure VMware Solution connectiviteit tussen regio's

Wanneer er meerdere Azure VMware Solution privéclouds bestaan, is laag 3-connectiviteit tussen deze clouds vaak een vereiste voor taken zoals het ondersteunen van gegevensreplicatie.

Azure VMware Solution biedt systeemeigen ondersteuning voor directe connectiviteit tussen twee privéclouds die zijn geïmplementeerd in verschillende Azure-regio's. Privéclouds maken verbinding met het Azure-netwerk in hun eigen regio via ExpressRoute-circuits, beheerd door het platform en beëindigd op toegewezen Meet-me-locaties van ExpressRoute. In dit artikel worden deze circuits Azure VMware Solution beheerde circuits genoemd. Azure VMware Solution beheerde circuits moeten niet worden verward met de normale circuits die klanten implementeren om hun on-premises sites te verbinden met Azure. De normale circuits die klanten implementeren, zijn door de klant beheerde circuits (zie afbeelding 2).

Directe connectiviteit tussen privéclouds is gebaseerd op ExpressRoute Global Reach-verbindingen tussen Azure VMware Solution beheerde circuits, zoals wordt weergegeven door de groene lijn in het volgende diagram. Zie Zelfstudie: On-premises omgevingen koppelen aan Azure VMware Solution voor meer informatie. In het artikel wordt de procedure beschreven voor het verbinden van een Azure VMware Solution beheerd circuit met een door de klant beheerd circuit. Dezelfde procedure is van toepassing op het verbinden van twee Azure VMware Solution beheerde circuits.

Diagram van afbeelding 2, waarin privéclouds in verschillende regio's worden weergegeven die zijn verbonden via een Global Reach-verbinding tussen beheerde ExpressRoute-circuits.

Hybride connectiviteit

De aanbevolen optie voor het verbinden van Azure VMware Solution privéclouds met on-premises sites is ExpressRoute Global Reach. Global Reach-verbindingen kunnen tot stand worden gebracht tussen door de klant beheerde ExpressRoute-circuits en Azure VMware Solution beheerde ExpressRoute-circuits. Global Reach-verbindingen zijn niet transitief, daarom is een volledige mesh (elk Azure VMware Solution beheerd circuit dat is verbonden met elk door de klant beheerd circuit) nodig voor noodtolerantie, zoals wordt weergegeven in de volgende afbeelding 3 (vertegenwoordigd door oranje lijnen).

Diagram van afbeelding 3, waarin Global Reach-verbindingen worden weergegeven die door de klant beheerde ExpressRoute-circuits verbinden met ExpressRoute-circuits van VMware Solution.

Azure Virtual Network-connectiviteit

Azure Virtual Network kan worden verbonden met Azure VMware Solution privéclouds via verbindingen tussen ExpressRoute-gateways en Azure VMware Solution beheerde circuits. Deze verbinding is precies dezelfde manier waarop Azure Virtual Network kan worden verbonden met on-premises sites via door de klant beheerde ExpressRoute-circuits. Zie Handmatig verbinding maken met de privécloud voor configuratie-instructies.

In scenario's met twee regio's raden we een volledige mesh aan voor de ExpressRoute-verbindingen tussen de twee regionale hub-Virtual Network en privéclouds, zoals wordt weergegeven in afbeelding 4 (vertegenwoordigd door gele lijnen).

Diagram van afbeelding 4, waarin wordt weergegeven dat systeemeigen Azure-resources in elke regio directe L3-connectiviteit hebben met Azure VMware Solution privéclouds.

Internetconnectiviteit

Wanneer u Azure VMware Solution privéclouds in meerdere regio's implementeert, raden we systeemeigen opties aan voor internetverbinding (Managed Source Network Address Translation (SNAT) of openbare IP-adressen tot aan de NSX-T). Beide opties kunnen tijdens de implementatie worden geconfigureerd via de Azure Portal (of via PowerShell, CLI of ARM/Bicep-sjablonen), zoals wordt weergegeven in de volgende afbeelding 5.

Diagram van afbeelding 5, met de Azure VMware Solution systeemeigen opties voor internetverbinding in de Azure Portal.

Beide opties die in afbeelding 5 zijn gemarkeerd, bieden elke privécloud een directe internetuitval in een eigen regio. De volgende overwegingen moeten bepalen welke systeemeigen internetverbindingsoptie moet worden gebruikt:

  • Beheerde SNAT moet worden gebruikt in scenario's met basisvereisten en vereisten voor alleen uitgaand verkeer (lage volumes uitgaande verbindingen en geen behoefte aan gedetailleerde controle over de SNAT-pool).
  • Openbare IP-adressen tot aan de NSX-T-rand hebben de voorkeur in scenario's met grote hoeveelheden uitgaande verbindingen of wanneer u gedetailleerde controle over NAT IP-adressen nodig hebt. Welke Azure VMware Solution VM's gebruiken bijvoorbeeld SNAT achter welke IP-adressen. Openbare IP-adressen tot aan de NSX-T-edge ondersteunen ook binnenkomende connectiviteit via DNAT. Inkomende internetverbinding wordt niet behandeld in dit artikel.

Het is mogelijk om de configuratie van de internetverbinding van een privécloud te wijzigen na de eerste implementatie. Maar de privécloud verliest de verbinding met internet, Azure Virtual Network en on-premises sites terwijl de configuratie wordt bijgewerkt. Wanneer een van de systeemeigen internetverbindingsopties in de voorgaande afbeelding 5 wordt gebruikt, is er geen extra configuratie nodig in scenario's met twee regio's (de topologie blijft hetzelfde als die in afbeelding 4). Zie Ontwerpoverwegingen voor internetconnectiviteit voor meer informatie over internetverbinding voor Azure VMware Solution.

Azure-systeemeigen internet-breakout

Als een beveiligde internetrand is gebouwd in Azure Virtual Network vóór Azure VMware Solution acceptatie, kan het nodig zijn om deze te gebruiken voor internettoegang voor Azure VMware Solution privéclouds. Het gebruik van een beveiligde internetrand op deze manier is nodig voor gecentraliseerd beheer van netwerkbeveiligingsbeleid, kostenoptimalisatie en meer. Internetbeveiligingsranden in Azure Virtual Network kunnen worden geïmplementeerd met behulp van Azure Firewall of virtuele firewall- en proxynetwerkapparaten (NVA's) van derden die beschikbaar zijn op de Azure Marketplace.

Internetverkeer dat wordt verzonden door Azure VMware Solution virtuele machines kan worden aangetrokken door een Azure-VNet door een standaardroute te genereren en deze aan te kondigen, via border gateway protocol (BGP), naar het beheerde ExpressRoute-circuit van de privécloud. Deze optie voor internetverbinding kan worden geconfigureerd via de Azure Portal (of via PowerShell-, CLI- of ARM-/Bicep-sjablonen) tijdens de implementatie, zoals wordt weergegeven in de volgende afbeelding 6. Zie Internettoegang uitschakelen of een standaardroute inschakelen voor meer informatie.

Diagram van afbeelding 6, waarin de configuratie van de Azure VMware Solution voor het inschakelen van internetverbinding via internetranden in Azure Virtual Network.

De NVA's voor internetranden kunnen afkomstig zijn van de standaardroute als ze BGP ondersteunen. Zo niet, dan moet u andere BGP-compatibele NVA's implementeren. Zie Internetconnectiviteit implementeren voor Azure VMware Solution met Azure NVA's voor meer informatie over het implementeren van uitgaande internetconnectiviteit voor Azure VMware Solution in één regio. In het scenario met twee regio's dat in dit artikel wordt besproken, moet dezelfde configuratie worden toegepast op beide regio's.

De belangrijkste overweging in scenario's met twee regio's is dat de standaardroute die afkomstig is uit elke regio, alleen via ExpressRoute moet worden doorgegeven aan de Azure VMware Solution privécloud in dezelfde regio. Door deze doorgifte hebben Azure VMware Solution workloads toegang tot internet via een lokale (in-regio) breakout. Als u echter de topologie gebruikt die wordt weergegeven in afbeelding 4, ontvangt elke Azure VMware Solution privécloud ook een standaardroute van gelijke kosten van de externe regio via de ExpressRoute-verbindingen tussen regio's. De rode stippellijnen vertegenwoordigen deze ongewenste standaardroutedoorgifte voor meerdere regio's in afbeelding 7.

Diagram van afbeelding 7, waarin de regiooverschrijdende verbindingen tussen ExpressRoute-gateways en door VMware Solution beheerde ExpressRoute-circuits moeten worden verwijderd.

Als u de Azure VMware Solution ExpressRoute-verbindingen tussen regio's verwijdert, wordt het doel bereikt om in elke privécloud een standaardroute in te voeren voor het doorsturen van internetverbindingen naar de Azure-internetrand in de lokale regio.

Als de ExpressRoute-verbindingen tussen regio's (rode stippellijnen in afbeelding 7) worden verwijderd, wordt de standaardroute nog steeds doorgegeven via Global Reach. Routes die worden doorgegeven via Global Reach hebben echter een langer AS-pad dan de lokaal afkomstige paden en worden verwijderd door het selectieproces van de BGP-route.

De doorgifte tussen regio's boven Global Reach van een minder voorkeursroute biedt tolerantie tegen fouten van de lokale internetrand. Als de internetrand van een regio offline gaat, wordt de standaardroute niet meer weergegeven. In dat geval wordt de minder voorkeursroute die is geleerd van de externe regio geïnstalleerd in de Azure VMware Solution privécloud, zodat internetverkeer wordt gerouteerd via de breakout van de externe regio.

De aanbevolen topologie voor implementaties met twee regio's met internetonderbrekingen in Azure VNets wordt weergegeven in de volgende afbeelding 8.

Diagram van afbeelding 8, waarin de aanbevolen topologie voor implementaties met twee regio's met uitgaande toegang via internet via internetranden wordt weergegeven.

Wanneer u standaardroutes in Azure uitgeeft, moet u er met name voor zorgen dat er geen on-premises sites worden doorgegeven, tenzij er een vereiste is om toegang tot internet te bieden aan on-premises sites via een internetrand in Azure. De door de klant beheerde apparaten die de door de klant beheerde ExpressRoute-circuits beëindigen, moeten worden geconfigureerd voor het filteren van standaardroutes die worden ontvangen van Azure, zoals wordt weergegeven in afbeelding 9. Deze configuratie is nodig om te voorkomen dat de toegang tot internet voor de on-premises sites wordt onderbroken.

Diagram van afbeelding 9, waarin de BGP-luidsprekers die de door de klant beheerde ExpressRoute-circuits beëindigen, de standaardroutes van Azure NVA's filteren.

Volgende stappen