Nätverksöverväganden för azure VMware Solution-distributioner med dubbla regioner
Den här artikeln beskriver hur du konfigurerar nätverksanslutningar när privata Moln i Azure VMware Solution distribueras i två Azure-regioner i katastrofåterställningssyfte. Om det uppstår partiella eller fullständiga regionala avbrott tillåter nätverkstopologin i den här artikeln att de kvarvarande komponenterna (privata moln, Azure-inbyggda resurser och lokala platser) kan upprätthålla anslutningen med varandra och med Internet.
Scenario med dubbla regioner
Den här artikeln fokuserar på ett typiskt scenario med dubbla regioner som visas i följande bild 1:
- Det finns ett Azure nätverksarkitektur med hubb och ekrar i varje region.
- En haveriberedskapskonfiguration för Azure ExpressRoute (två kretsar på två olika peeringplatser, där varje krets är ansluten till virtuella hubbnätverk i båda regionerna) har distribuerats. Vägledningen i följande avsnitt förblir densamma om reserv-VPN-anslutning har konfigurerats.
- Ett privat Azure VMware Solution-moln har distribuerats i varje region.
bild 1: Ett scenario med dubbla regioner som visar hur global peering för virtuella nätverk ansluter två virtuella nätverk i olika regioner
Not
I referensscenariot i bild 1 är de två regionala virtuella hubbnätverken anslutna via global VNet-peering. Även om det inte är absolut nödvändigt, eftersom trafik mellan virtuella Azure-nätverk i de två regionerna kan dirigeras via ExpressRoute-anslutningar, rekommenderar vi starkt den här konfigurationen. VNet-peering minimerar svarstiden och maximerar dataflödet, eftersom det tar bort behovet av hårnålstrafik via ExpressRoute meet-me edge-routrarna.
Kommunikationsmönster med dubbla regioner
I nästa avsnitt beskrivs nätverkskonfigurationen för Azure VMware Solution som krävs för att i referensscenariot med dubbla regioner aktivera följande kommunikationsmönster:
- Azure VMware Solution till Azure VMware Solution (beskrivs i avsnittet Azure VMware Solution anslutning mellan regioner);
- Azure VMware Solution till lokala platser som är anslutna via ExpressRoute (beskrivs i avsnittet Hybridanslutning);
- Azure VMware Solution to Azure Virtual Network (beskrivs i avsnittet Azure Virtual Network-anslutning);
- Azure VMware Solution to Internet (beskrivs i avsnittet Internetanslutning).
Anslutning mellan regioner i Azure VMware Solution
När det finns flera privata Moln i Azure VMware Solution är Layer 3-anslutning mellan dem ofta ett krav för uppgifter som att stödja datareplikering.
Azure VMware Solution har inbyggt stöd för direkt anslutning mellan två privata moln som distribueras i olika Azure-regioner. Privata moln ansluter till Azure-nätverket i sin egen region via ExpressRoute-kretsar, hanteras av plattformen och avslutas på dedikerade ExpressRoute-mötesplatser. I den här artikeln kallas dessa kretsar för Azure VMware Solution-hanterade kretsar. Hanterade Azure VMware Solution-kretsar bör inte förväxlas med de normala kretsar som kunder distribuerar för att ansluta sina lokala platser till Azure. De normala kretsar som kunder distribuerar är kundhanterade kretsar (se bild 2).
Direktanslutning mellan privata moln baseras på ExpressRoute Global Reach anslutningar mellan hanterade Azure VMware Solution-kretsar, vilket visas av den gröna linjen i följande diagram. Mer information finns i Självstudie: Anslut lokala miljöer till Azure VMware Solution. I artikeln beskrivs hur du ansluter en hanterad Azure VMware Solution-krets med en kundhanterad krets. Samma procedur gäller för att ansluta två hanterade Azure VMware Solution-kretsar.
Bild 2: Det här referensscenariot visar privata moln i Azure VMware Solution i olika regioner. En Global Reach-anslutning ansluter direkt molnen mellan deras hanterade ExpressRoute-kretsar.
Hybridanslutning
Det rekommenderade alternativet för att ansluta privata Azure VMware Solution-moln till lokala platser är ExpressRoute Global Reach. Globala Reach-anslutningar kan upprättas mellan kundhanterade ExpressRoute-kretsar och Azure VMware Solution-hanterade ExpressRoute-kretsar. Global Reach-anslutningar är inte transitiva, därför krävs ett fullständigt nät (varje hanterad Azure VMware Solution-krets som är ansluten till varje kundhanterad krets) för katastrofåterhämtning, vilket visas i följande bild 3 (representerad av orange linjer).
bild 3: Det här referensscenariot visar globala Reach-anslutningar mellan kundhanterade ExpressRoute-kretsar och Azure VMware Solution ExpressRoute-kretsar.
Azure Virtual Network-anslutning
Azure Virtual Network kan anslutas till privata Azure VMware Solution-moln via anslutningar mellan ExpressRoute-gatewayer och hanterade Azure VMware Solution-kretsar. Den här anslutningen är exakt på samma sätt som Azure Virtual Network kan anslutas till lokala platser via kundhanterade ExpressRoute-kretsar. Se Anslut till det privata molnet manuellt för konfigurationsinstruktioner.
I scenarier med dubbla regioner rekommenderar vi ett fullständigt nät för ExpressRoute-anslutningarna mellan de två regionala hubbens virtuella nätverk och privata moln, enligt bild 4 (representeras av gula linjer).
bild 4: Det här referensscenariot visar azure-interna resurser i varje region som har direkt L3-anslutning till privata Azure VMware Solution-moln.
Internetanslutning
När du distribuerar privata Azure VMware Solution-moln i flera regioner rekommenderar vi interna alternativ för internetanslutning (SNAT (Managed Source Network Address Translation) eller offentliga IP-adresser ned till NSX-T). Båda alternativen kan konfigureras via Azure-portalen (eller via PowerShell-, CLI- eller ARM/Bicep-mallar) vid distributionstillfället, enligt följande bild 5.
bild 5: Den här skärmbilden visar Azure VMware Solution-inbyggda alternativ för internetanslutning i Azure-portalen.
Båda alternativen som är markerade i bild 5 ger varje privat moln ett direkt internetutbrott i sin egen region. Följande överväganden bör ligga till grund för beslutet om vilket internetanslutningsalternativ som ska användas:
- Hanterad SNAT bör användas i scenarier med grundläggande och utgående krav (låga volymer av utgående anslutningar och inget behov av detaljerad kontroll över SNAT-poolen).
- Offentliga IP-adresser ned till NSX-T gränsen bör föredras i scenarier med stora volymer av utgående anslutningar eller när du behöver detaljerad kontroll över NAT IP-adresser. Till exempel, vilka virtuella Azure VMware Solution-datorer använder SNAT bakom vilka IP-adresser. Offentliga IP-adresser ned till NSX-T gränsen stöder också inkommande anslutningar via DNAT. Inkommande internetanslutning beskrivs inte i den här artikeln.
Det går att ändra ett privat molns internetanslutningskonfiguration efter den första distributionen. Men det privata molnet förlorar anslutningen till Internet, Azure Virtual Network och lokala platser medan konfigurationen uppdateras. När något av internetanslutningsalternativen i föregående bild 5 används krävs ingen extra konfiguration i scenarier med dubbla regioner (topologin förblir densamma som den som visas i bild 4). Mer information om Internetanslutning för Azure VMware Solution finns i designöverväganden för Internetanslutning.
Azure-inbyggt internetutbrott
Om en säker Internet edge skapades i Azure Virtual Network innan Azure VMware Solution implementerades kan det vara nödvändigt att använda den för internetåtkomst för privata Moln i Azure VMware Solution. Att använda en säker Internet edge på det här sättet är nödvändigt för centraliserad hantering av nätverkssäkerhetsprinciper, kostnadsoptimering med mera. Internetsäkerhetskanter i Azure Virtual Network kan implementeras med hjälp av Azure Firewall eller brandväggs- och proxybaserade nätverksvirtuella apparater (NVA) från tredje part som finns tillgängliga på Azure Marketplace.
Internetbunden trafik som genereras av virtuella Azure VMware Solution-datorer kan lockas till ett virtuellt Azure-nätverk genom att komma från en standardväg och meddela den via BGP (Border Gateway Protocol) till det privata molnets hanterade ExpressRoute-krets. Det här internetanslutningsalternativet kan konfigureras via Azure-portalen (eller via PowerShell-, CLI- eller ARM/Bicep-mallar) vid distributionstillfället, enligt följande bild 6. Mer information finns i Inaktivera internetåtkomst eller aktivera en standardväg.
bild 6: Den här skärmbilden visar konfigurationen av Azure VMware-lösningen som du måste välja för att aktivera Internetanslutning via Internetkanter i virtuellt nätverk.
NVA:erna vid internetkanten kan generera standardrutten om de stöder BGP. Annars måste du distribuera andra BGP-kompatibla NVA:er. Mer information om hur du implementerar utgående Internetanslutningar för Azure VMware Solution i en enda region finns i Implementera internetanslutning för Azure VMware Solution med Azure NVAs. I scenariot med dubbla regioner som beskrivs i den här artikeln måste samma konfiguration tillämpas på båda regionerna.
Det viktigaste i scenarier med dubbla regioner är att standardvägen som kommer från varje region ska spridas via ExpressRoute endast till det privata Azure VMware Solution-molnet i samma region. Den här spridningen gör det möjligt för Azure VMware Solution-arbetsbelastningar att komma åt Internet via en lokal (i-region) breakout. Men om du använder topologin som visas i bild 4 får varje privat Azure VMware Solution-moln också en standardväg med samma kostnad från fjärrregionen över ExpressRoute-anslutningarna mellan regioner. De röda streckade linjerna representerar den här oönskade vägspridningen mellan regioner i bild 7.
Figur 7: Det här referensscenariot visar anslutningar mellan regioner mellan ExpressRoute-gatewayer och ExpressRoute-kretsar som hanteras av Azure VMware Solution som du måste ta bort för att förhindra spridning av standardrouten mellan regioner.
Om du tar bort ExpressRoute-anslutningar mellan regioner i Azure VMware Solution uppnår du målet att i varje privat moln mata in en standardväg för att vidarebefordra internetbundna anslutningar till Azure Internet Edge i den lokala regionen.
Observera att om ExpressRoute-anslutningarna mellan regioner (röda streckade linjer i bild 7) tas bort, sker spridning mellan regioner för standardvägen fortfarande över Global Räckvidd. Vägar som sprids via Global Reach har dock en längre AS-sökväg än de lokalt skapade och tas bort av BGP-vägvalsprocessen.
Spridningen mellan regioner över Global Räckvidd för en mindre prioriterad standardväg ger motståndskraft mot fel i den lokala internetgränsen. Om en regions internetkant går offline slutar den att generera standardrutten. I så fall installeras den mindre föredragna standardvägen från fjärrregionen i det privata Azure VMware Solution-molnet, så att internettrafik dirigeras via fjärrregionens utgångspunkt.
Den rekommenderade topologin för distributioner med dubbla regioner med internetbrytningar i virtuella Azure-nätverk visas i följande bild 8.
bild 8: Det här referensscenariot visar den rekommenderade topologin för distributioner med dubbla regioner som har utgående internetåtkomst via Internetkanter i Azure Virtual Network.
När du skapar standardvägar i Azure måste du vara särskilt noga med att undvika spridning till lokala platser, såvida det inte finns ett krav på att tillhandahålla internetåtkomst till lokala platser via en "internet edge" i Azure. De kunddrivna enheter som avslutar de kundhanterade ExpressRoute-kretsarna måste konfigureras för att filtrera standardvägar som tas emot från Azure, enligt bild 9. Den här konfigurationen är nödvändig för att undvika att störa internetåtkomsten för de lokala platserna.
bild 9: Det här referensscenariot visar Border Gateway Protocol-högtalarna som avslutar de kundhanterade ExpressRoute-kretsarna och filtrerar standardvägarna för Azure Network Virtual Appliances.
Nästa steg
Mer information om nätverksfunktioner för Azure VMware Solution finns i Azure VMware Solution-nätverks- och sammanlänkningskoncept.
För mer information om internetanslutning för Azure VMware Solution, se designöverväganden gällande Internetanslutning.