Delen via


Netwerkoverwegingen voor azure VMware Solution-implementaties met twee regio's

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

Scenario voor twee regio's

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

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

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

afbeelding 1: Een scenario met twee regio's waarin wordt getoond hoe wereldwijde peering van virtueel netwerk twee virtuele netwerken in verschillende regio's verbindt

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 sterk aangeraden omdat verkeer tussen virtuele Azure-netwerken in de twee regio's kan worden gerouteerd via ExpressRoute-verbindingen. Met VNet-peering wordt de latentie geminimaliseerd en wordt de doorvoer gemaximaliseerd, omdat er geen verkeer meer hoeft te worden teruggestuurd via de ExpressRoute meet-me edge-routers.

Communicatiepatronen tussen twee regio's

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

Connectiviteit tussen regio's in Azure VMware Solution

Wanneer er meerdere Azure VMware Solution-privéclouds bestaan, is laag 3-connectiviteit er vaak een vereiste voor taken zoals ondersteunende 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 specifieke meet-me locaties voor de ExpressRoute-verbinding. In dit artikel worden deze circuits aangeduid als Azure VMware Solution-beheerde circuits. Beheerde Azure VMware Solution-circuits moeten niet worden verward met de gewone circuits die klanten uitrollen om hun on-premises sites met Azure te verbinden. 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 door Azure VMware Solution beheerde circuits, zoals wordt weergegeven door de groene lijn in het volgende diagram. Voor meer informatie, zie Handleiding: On-premises omgevingen verbinden met Azure VMware Solution. In het artikel wordt de procedure beschreven voor het verbinden van een beheerd azure VMware Solution-circuit met een door de klant beheerd circuit. Dezelfde procedure geldt voor het verbinden van twee door Azure VMware Solution beheerde circuits.

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

Afbeelding 2: In dit referentiescenario ziet u privéclouds van Azure VMware Solution in verschillende regio's. Een Global Reach-verbinding verbindt de clouds rechtstreeks tussen hun beheerde ExpressRoute-circuits.

Hybride connectiviteit

De aanbevolen optie voor het verbinden van privéclouds van Azure VMware Solution met on-premises sites is ExpressRoute Global Reach. Wereldwijde Reach-verbindingen kunnen tot stand worden gebracht tussen door de klant beheerde ExpressRoute-circuits en beheerde ExpressRoute-circuits van Azure VMware Solution. Global Reach-verbindingen zijn niet transitief, dus een volledige mesh (elk beheerd Azure VMware Solution-circuit dat is verbonden met elk door de klant beheerd circuit) is 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 waarmee door de klant beheerde ExpressRoute-circuits en VMware Solution ExpressRoute-circuits worden verbonden.

afbeelding 3: In dit referentiescenario ziet u global Reach-verbindingen tussen door de klant beheerde ExpressRoute-circuits en Azure VMware Solution ExpressRoute-circuits.

Azure Virtual Network-connectiviteit

Azure Virtual Network kan worden verbonden met azure VMware Solution-privéclouds via verbindingen tussen ExpressRoute-gateways en beheerde Azure VMware Solution-circuits. Azure Virtual Network werkt op exact dezelfde manier als verbindingen met on-premises locaties 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.

afbeelding 4: In dit referentiescenario ziet u systeemeigen Azure-resources in elke regio met directe L3-connectiviteit met azure VMware Solution-privéclouds.

Internetverbinding

Bij het implementeren van Azure VMware Solution-privéclouds in meerdere regio's raden we systeemeigen opties aan voor internetverbinding (SNAT (Managed Source Network Address Translation) of openbare IP-adressen tot aan het NSX-T). U kunt deze optie configureren via Azure Portal (of via PowerShell-, CLI- of ARM-/Bicep-sjablonen) tijdens de implementatie, zoals wordt weergegeven in de volgende afbeelding 5.

diagram van afbeelding 5, waarin de systeemeigen azure VMware Solution-opties voor internetverbinding in Azure Portal worden weergegeven.

afbeelding 5: In deze schermopname worden de systeemeigen opties van Azure VMware Solution voor internetconnectiviteit in Azure Portal gemarkeerd.

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

  • Beheerde SNAT moet worden gebruikt in scenario's met basis- en enkel uitgaande vereisten (lage aantallen uitgaande verbindingen en geen fijnmazige controle over de SNAT-pool).
  • Openbare IP-adressen tot aan de NSX-T edge moeten de voorkeur krijgen 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 bijvoorbeeld SNAT gebruiken achter welke IP-adressen. Openbare IP-adressen tot aan de NSX-T edge ondersteunen ook binnenkomende connectiviteit via DNAT. In dit artikel wordt geen inkomende internetverbinding behandeld.

De internetverbindingsconfiguratie van een privécloud wijzigen nadat de eerste implementatie mogelijk is. Maar de privécloud verliest connectiviteit 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 in afbeelding 4). Zie ontwerpoverwegingen voor internetconnectiviteitvoor meer informatie over de internetverbinding voor Azure VMware Solution.

Systeemeigen internetuitval van Azure

Als een beveiligde internetrand is gebouwd in Azure Virtual Network vóór de overstap naar Azure VMware Solution, kan het nodig zijn om deze te gebruiken voor internettoegang voor privéclouds van Azure VMware Solution. 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 firewall- en proxynetwerk-VM's (NVA's) van derden die beschikbaar zijn op Azure Marketplace.

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

diagram van afbeelding 6, waarin de azure VMware Solution-configuratie wordt weergegeven om internetverbinding mogelijk te maken via internetranden in Azure Virtual Network.

afbeelding 6: In deze schermopname wordt de Azure VMware Solution-configuratie gemarkeerd die u moet selecteren om internetverbinding via internetranden in virtual network in te schakelen.

De NVAs aan de internetrand kunnen de standaardroute initiëren als ze BGP ondersteunen. Zo niet, dan moet u andere NVA's met BGP-functionaliteit implementeren. Zie Internetconnectiviteit implementeren voor Azure VMware Solution met Azure NVA'svoor 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 van elke regio, alleen moet worden doorgegeven via ExpressRoute naar de privécloud van Azure VMware Solution in dezelfde regio. Met deze propagatie kunnen Azure VMware Solution-workloads via een lokale (in-regio) internetdoorbraak toegang krijgen tot internet. 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.

Het diagram van afbeelding 7, waarin de verbindingen tussen ExpressRoute-gateways en door VMware Solution beheerde ExpressRoute-circuits worden getoond, moet worden verwijderd.

Afbeelding 7: Dit referentiescenario toont de verbindingen tussen ExpressRoute-gateways en ExpressRoute-circuits die worden beheerd door Azure VMware Solution, en die u moet verwijderen om de verspreiding van de standaardroute tussen regio's te voorkomen.

Door de ExpressRoute-verbindingen tussen regio's van Azure VMware Solution te verwijderen, wordt in elke privécloud een standaardroute voor het doorsturen van internetverbindingen naar de Azure-internetrand in de lokale regio bereikt.

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

De interregionale propagatie via Global Reach van een minder geprefereerde standaardroute biedt veerkracht tegen storingen van de lokale internetverbinding. Als de internetgrens van een regio offline gaat, houdt deze op met het verschaffen van de standaardroute. In dat geval wordt de minder geprefereerde standaardroute uit de afgelegen regio geïnstalleerd in de privécloud van Azure VMware Solution, zodat internetverkeer wordt gerouteerd via de uitgang van de afgelegen 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 van twee regio's met uitgaande toegang via internet via internetranden wordt weergegeven.

afbeelding 8: In dit referentiescenario ziet u de aanbevolen topologie voor implementaties in twee regio's met uitgaande internettoegang via internetranden in Azure Virtual Network.

Wanneer u standaardroutes in Azure gebruikt, moet u speciale aandacht verlenen om doorgifte naar on-premises sites te voorkomen, tenzij er een vereiste is om internettoegang te bieden tot 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 om standaardroutes te filteren die afkomstig zijn van Azure, zoals wordt weergegeven in afbeelding 9. Deze configuratie is nodig om te voorkomen dat internettoegang voor de on-premises sites wordt onderbroken.

Diagram van Figuur 9, dat de BGP-luidsprekers toont die de door de klant beheerde ExpressRoute-circuits beëindigen. De standaardroutes van Azure NVA's worden gefilterd.

afbeelding 9: In dit referentiescenario ziet u de Border Gateway Protocol-sprekers waarmee de door de klant beheerde ExpressRoute-circuits worden beëindigd en standaardroutes voor virtuele Azure-netwerkapparaten worden gefilterd.

Volgende stappen