Multiregion-netwerkontwerp

In dit artikel wordt uitgelegd hoe u Azure netwerken ontwerpt die meerdere regio's omvatten. Een netwerk met meerdere regio's biedt hoge beschikbaarheid tegen regionale storingen, bedient geografisch gedistribueerde gebruikers met een lagere latentie en biedt ondersteuning voor vereisten voor de locatie van regelgeving voor gegevens.

Wat in dit artikel wordt behandeld

In dit artikel wordt aandacht besteed aan zone versus regionale redundantie, strategieën voor routering tussen regio's, opties voor hubtopologie voor implementaties met meerdere regio's, actief-actief versus actief-passieve failoverpatronen en overwegingen met betrekking tot replicatielatentie.

Wie heeft dit artikel nodig

Lees dit artikel als uw omgeving overeenkomt met een van deze voorwaarden:

  • Uw workload vereist disaster recovery-bescherming tegen het uitvallen van een volledige Azure-regio.
  • U dient gebruikers in meerdere geografische gebieden te bedienen en de netwerklatentie te minimaliseren.
  • Wettelijke of nalevingsvereisten verplichten dat gegevens binnen specifieke geografische grenzen blijven.
  • Uw bedrijfscontinuïteitsdoelstellingen definiëren een beoogde hersteltijd (RTO) waaraan één regio niet alleen kan voldoen.

Als uw workload werkt in één regio en zone-redundante implementaties voldoet aan uw beschikbaarheidsvereisten, hebt u mogelijk nog geen ontwerp voor meerdere regio's nodig. Begin met een hub-and-spoke-topologie of Virtual WAN in één regio en breid later uit.

Lift-and-shiftfocus: Bestaande workloads kunnen vaak niet in een active-active-configuratie over meerdere regio’s heen draaien. Plan herstel na noodgevallen met Azure Site Recovery en een hub in de herstelregio in plaats van een volledig actief-actief ontwerp.

Focus moderniseren: Implementeer klantgerichte apps actief-actief in twee regio's met zone-redundante SKU's, met behulp van niet-overlappende adresruimte, zodat regio's indien nodig peering kunnen uitvoeren.

Focus op cloudoverschrijdende connectiviteit: Gebruik Azure Virtual WAN om meerdere regio's en vestigingen te verbinden, en plan routering over regio's heen naast uw cloudoverschrijdende transit.

Azure services en functies

De volgende tabel bevat de Azure services en functies waarmee netwerken met meerdere regio's mogelijk zijn:

Service ofwel functie Rol in ontwerp voor meerdere regio's Meer informatie
Azure Traffic Manager Op DNS gebaseerde verkeersroutering tussen regio's voor elk protocol Overzicht van Traffic Manager
Azure Front Door (een cloudgebaseerde dienst voor netwerkbeveiliging en contentlevering) Globale TAAKVERDELING van HTTP/HTTPS met CDN en WAF aan de rand Overzicht van Front Door
Globale VNet-peering Privéverbinding met hoge bandbreedte tussen virtuele netwerken in verschillende regio's Peering op virtueel netwerk
ExpressRoute Global Reach On-premises sites met elkaar verbinden via de Azure backbone ExpressRoute Global Reach
Azure Virtual WAN (meerdere hubs) Microsoft beheerde wereldwijde doorvoer met automatische routering tussen hubs Virtual WAN wereldwijde overdracht
Azure Virtual Network Manager (AVNM) Automatiseert peeringtopologie in meerdere regio's en netwerkgroepsbeheer Overzicht van AVNM

Waarom voor meerdere regio's meerdere virtuele netwerken zijn vereist

Een virtueel netwerk (VNet) omvat één regio. Subnetten binnen dat VNet omvatten alle beschikbaarheidszones in de regio, maar het VNet zelf kan niet worden uitgebreid over regiogrenzen. Netwerken met meerdere regio's betekent daarom het implementeren van meerdere VNets, een of meer per regio en het verbinden met services tussen regio's.

Diagram met een active-active-topologie in twee regio's, waarbij Azure Front Door en WAF wereldwijd inkomend verkeer routeren naar de regio's West-Europa en Oost-VS, die elk een hub-VNet met Azure Firewall en Azure Bastion bevatten, gekoppeld aan een workload-spoke-VNet, met globale VNet-peering via de Microsoft-backbone die de twee regio's verbindt.

Deze fundamentele beperking vormen elk ontwerp voor meerdere regio's:

  • Elke regio heeft een eigen VNet-adresruimte nodig (niet overlappend met andere regio's voor peering).
  • Verkeer tussen regio's vereist een expliciet connectiviteitsmechanisme: Globale VNet-peering, Virtual WAN inter-hub of routering op basis van gateways.
  • Globale taakverdelingsservices (Traffic Manager of Front Door) leiden gebruikers naar de juiste regionale implementatie.

Zie IP-adresplanning voor richtlijnen over subnet- en adresplanning.

Beschikbaarheidszones versus regionale redundantie

Voordat u een topologie met meerdere regio's ontwerpt, begrijpt u de twee niveaus van infrastructuurredundantie in Azure:

Level Beschermt tegen Mechanisme Example
Beschikbaarheidszones Uitval van één datacenter binnen een regio Fysiek gescheiden datacenters met onafhankelijke voeding, koeling en netwerken Zone-redundante Azure Firewall geïmplementeerd in drie zones
Regionale redundantie Volledige regiofout (natuurramp, wijdverspreide storing) Workloads implementeren in twee of meer Azure regio's Actief-actieve webtoepassing in VS - oost en VS - west

Begin met zoneredundantie. Zone-redundante implementaties beschermen tegen de meest voorkomende foutscenario's (problemen met één datacenter) zonder de complexiteit van routering in meerdere regio's. Voeg regionale redundantie toe wanneer uw bedrijf bescherming nodig heeft tegen storingen in de hele regio of wanneer u geografisch gedistribueerde gebruikers moet bedienen.

Naslaginformatie over zoneredundante netwerkservices

De volgende tabel bevat zone-redundante implementatieopties voor kernnetwerkservices. Implementeer deze in elke regio waar u workloads uitvoert:

Dienst Zone-redundante optie Aantekeningen
Azure Firewall Implementeren in beschikbaarheidszones Verdeelt over alle 3 zones in de regio
Standaard Load Balancer Zone-redundante frontend Standaardgedrag voor Standard-SKU
Application Gateway v2 Zone-redundante implementatie Vereist de Standard_v2- of WAF_v2-SKU
VPN Gateway Actief-actief met zone-redundante SKU's Gebruik SKU’s met het achtervoegsel AZ (VpnGw1AZ, VpnGw2AZ, enz.)
ExpressRoute Gateway Zonaal redundante SKU’s ErGw1AZ, ErGw2AZ of ErGw3AZ gebruiken
Azure Bastion Zone-redundant (preview) Basic-, Standard- en Premium-SKU’s
NAT-gateway (StandardV2) Zone-redundant StandardV2-SKU vereist; Standard-SKU is alleen zonegebonden

Hoe kiest u een aanpak voor verkeersroutering tussen regio's?

Gebruik de volgende beslissingstabel om de juiste service te selecteren voor het routeren van verkeer tussen regio's:

Uw behoeften Aanbevolen service Hoe werkt het?
Multiregio-failover of taakverdeling voor elk protocol (HTTP, TCP, UDP) Azure Traffic Manager Retourneert het beste IP-adres van het eindpunt via DNS-omzetting. Client maakt rechtstreeks verbinding met het eindpunt. Failoversnelheid is afhankelijk van DNS TTL (meestal 30-300 seconden).
Wereldwijde HTTP/HTTPS-taakverdeling met CDN, WAF en snelle failover Azure Front Door (een cloudgebaseerde dienst voor netwerkbeveiliging en contentlevering) Beëindigt verbindingen op edge points of presence (PoP's). Routeert aanvragen naar de dichtstbijzijnde goede back-end. Biedt failover op verbindingsniveau (seconden, niet DNS-TTL afhankelijk).
Privé-back-endverkeer tussen regio's (replicatie, interne API's) Globale VNet-peering Verbindt VNets tussen regio's via de Microsoft backbone. Peering is niet transitief; elke peeringrelatie is expliciet. Kosten voor gegevensoverdracht per GB gelden.
On-premises site-naar-site-connectiviteit via Azure ExpressRoute Global Reach Verbindt twee ExpressRoute-circuits, zodat on-premises locaties communiceren via de Microsoft backbone zonder hubrouters te doorlopen.

Tip

Combineer deze services. Gebruik bijvoorbeeld Front Door voor gebruikersgericht HTTP-verkeer en globale VNet-peering voor back-endreplicatie tussen regio's.

Een multiregion-hubtopologie kiezen

Nadat u hebt besloten uw netwerk uit te breiden tussen regio's, kiest u een hubpatroon voor het beheren van connectiviteit tussen regio's:

Factor Hub-per-regio (traditioneel) Virtual WAN multi-hub
Connectiviteit tussen regio's De klant configureert globale VNet-peering tussen regionale hubs en beheert UDR's Automatische routering tussen hubs: alle Virtual WAN hubs zijn standaard onderling verbonden
Management Volledige klantcontrole over routering, firewallregels en peering Microsoft beheerde hubinfrastructuur met op beleid gebaseerd beheer
Ideaal voor Organisaties die gedetailleerde routeringsbeheer, aangepaste NVA's of bestaande hubinvesteringen nodig hebben Organisaties met veel regio's, meer dan 30 filialen of voorkeur voor beheerde infrastructuur
Wereldwijde overdracht Vereist expliciete peering + UDR-configuratie tussen elk hubpaar Ingebouwd: verkeer tussen willekeurige twee hubs wordt automatisch gerouteerd
Scaling Hubs en peerings handmatig toevoegen (AVNM kan automatiseren) Hubs toevoegen via Virtual WAN configuratie: routeringsupdates automatisch
Kostenmodel Hub VNet-resources (firewall, gateway, peering) apart gefactureerd Virtual WAN-eenheidsprijzen plus gekoppelde resources

Zie hub-and-spoke-topologie en Virtual WAN voor een gedetailleerde vergelijking van hub-and-spoke-topologie en Virtual WAN in één regio.

Ontwerpoverwegingen

Focus op lift-and-shift-ontwerp voor meerdere regio's

  • Voor bestaande workloads die zich niet over zones of regio's kunnen uitstrekken, kiest u beter voor een ontwerp gericht op noodherstel dan voor actief-actief: repliceer met Azure Site Recovery naar een herstelregio.
  • Bouw een hub in de herstelregio die de primaire hub spiegelt, zodat failoververkeer dezelfde gedeelde services heeft.
  • Gebruik Azure Traffic Manager of DNS-failover om gebruikers om te leiden tijdens een regionale storing.
  • Zorg ervoor dat de adresruimte van de herstelregio niet overlapt met de primaire regio om conflicten tijdens failover en latere peering te voorkomen.

Focus voor ontwerp voor meerdere regio's moderniseren

  • Implementeer klantgerichte workloads actief-actief over twee regio's met zone-redundante SKU's voor een zo hoog mogelijke weerbaarheid.
  • Wijs niet-overlappende adresbereiken toe aan primaire en back-upregio’s, zodat active-active spokes later globale VNet-peering kunnen gebruiken zonder de adressering opnieuw te hoeven uitvoeren.
  • Kies uw leveringslaag per app-type: Azure Front Door voor web-apps en Traffic Manager voor niet-web-apps, die over regionale openbare eindpunten worden gedistribueerd.
  • Zorg ervoor dat de openbare eindpunten van elke regio worden geïnspecteerd met de hubfirewall (SNAT en DNAT), zodat binnenkomend verkeer wordt gecontroleerd voordat back-ends worden bereikt.

Focus van het ontwerp voor cloudoverschrijdende multiregio-architectuur

  • Gebruik Azure Virtual WAN om meerdere Azure regio's, vertakkingen en cloudranden te verbinden met automatische any-to-any-routering.
  • Plan geaggregeerde, niet-overlappende adresbereiken over regio's en cloudomgevingen heen, zodat transit-routing eenvoudig blijft.
  • Beëindig IPsec-verbindingen tussen clouds op regionale beveiligde hubs en laat Virtual WAN routering tussen hubs afhandelen.
  • Verdeel openbaar inkomend verkeer over regio's met behulp van Front Door of Traffic Manager, en laat inspectie plaatsvinden op de firewall van elke regionale hub.

Prerequisites

Voordat u een netwerk met meerdere regio's ontwerpt, moet u het volgende doen:

  • Een topologie met één regio geïmplementeerd en getest. Begin met hub-and-spoke of Virtual WAN.
  • Gedefinieerde vereisten voor hoge beschikbaarheid en herstel na noodgevallen: RTO, beoogde herstelpunten (RPO) en nalevingsmandaten.
  • Er is een niet-overlappend IP-adresplan gemaakt in alle regio's. Zie planning van IP-adressen.
  • Geïdentificeerd welke workloads alleen regionale redundantie en zoneredundantie nodig hebben.

Actief-actief versus actief-passieve implementatiepatronen

Uw implementatiemodel voor meerdere regio's bepaalt hoe verkeer stroomt tijdens normale werking en tijdens een regionale storing:

Active-active

Beide regio's verwerken tegelijkertijd verkeer. Een globale load balancer, zoals Traffic Manager of Front Door, distribueert aanvragen over regio's op basis van nabijheid, prestaties of gewicht.

Wanneer gebruikt u active-active:

  • Uw toepassing kan aanvragen in elke regio verwerken zonder regiospecifieke statusafhankelijkheden.
  • U hebt het laagst mogelijke RTO nodig (failover is onmiddellijk omdat de goed functionerende regio al verkeer afhandelt).
  • U wilt capaciteit in beide regio's gebruiken tijdens normale werking (kostenefficiëntie).

Aandachtspunten voor netwerken:

  • Beide regio's moeten een identieke netwerkinfrastructuur hebben, waaronder firewalls, gateways en load balancers.
  • Gegevensreplicatie tussen regio's moet beide implementaties actueel houden.
  • Dns-TTL- en statustestintervallen bepalen hoe snel Traffic Manager verkeer verplaatst. Front Door biedt snellere failover op verbindingsniveau.

Active-passive

Eén regio (primair) verwerkt al het verkeer. De secundaire regio blijft gereed, maar verwerkt geen gebruikersverzoeken totdat er een failover plaatsvindt.

Wanneer moet u actief-passief gebruiken:

  • Uw toepassing heeft strikte vereisten voor schrijfregio's of kan de status niet eenvoudig repliceren.
  • Kostenbeperkingen voorkomen dat volledige capaciteit in twee regio's tegelijk wordt uitgevoerd.
  • Uw RTO-tolerantie biedt ruimte voor de tijd die nodig is om de secundaire regio te activeren.

Aandachtspunten voor netwerken:

  • De netwerkinfrastructuur van de passieve regio kan kleinere serviceniveaus of verlaagde capaciteit gebruiken totdat failover plaatsvindt.
  • Voor automatische failover zijn statustests met de juiste drempelwaarden vereist (vermijd flapping).
  • Test de failover regelmatig. Netwerkconfiguraties in de passieve regio kunnen afdrijven als ze niet zijn gevalideerd.
  • Routetabellen en NSG-regels gesynchroniseerd houden tussen regio's. Gebruik sjablonen voor infrastructuur als code om ervoor te zorgen dat de passieve regio overeenkomt met het beveiligingspostuur van de primaire regio.
  • Vooraf inrichten van VPN- of ExpressRoute-gateways in de passieve regio. Het inrichten van de gateway kan 20 tot 45 minuten duren. Dat is te langzaam voor de meeste RTO-doelen.

Kiezen tussen actief-actief en actief-passief netwerken

De keuze tussen actief-actief en actief-passief netwerken is van invloed op netwerkgrootte, kosten en operationele complexiteit:

Consideratie Active-active Active-passive
Netwerkcapaciteit Volledige capaciteit in beide regio's Verminderde capaciteit in passieve regio (schaal bij failover)
Gatewayinrichting Altijd ingeschakeld in beide regio's Vooraf ingericht, maar kan kleinere niveaus gebruiken
Gegevenssynchronisatie tussen regio's Doorlopend, bidirectioneel replicatieverkeer Eenrichtings asynchrone replicatie naar de standbyserver
Firewall-regels Identieke regelsets, beide actief afgedwongen Identieke regelsets, maar de passieve set wordt zelden gebruikt
IP-adressering Beide regio's adverteren aan een wereldwijde load balancer Alleen de primaire regio adverteert tot failover
Operationeel risico Lager niveau: beide paden worden continu gebruikt Hoger: passief pad kan afwijken of niet-geteste configuraties hebben

Gegevensreplicatie en latentie

Replicatie tussen regio's introduceert netwerklatentie die van invloed is op het toepassingsontwerp. Azure regio's binnen dezelfde geografie vertonen doorgaans 1-10 ms retourlatentie voor paren in de buurt (bijvoorbeeld VS - oost naar VS - oost 2) en 30-70 ms voor verre paren (bijvoorbeeld VS - oost naar VS - west). Trans-Atlantische of transpacific regioparen kunnen groter zijn dan 100 ms.

Belangrijke overwegingen voor ontwerp:

  • Replicatietopologie: Kies alleen synchrone replicatie voor regioparen met lage latentie (< 10 ms). Gebruik asynchrone replicatie voor verre paren om te voorkomen dat de prestaties van toepassingen afnemen.
  • Bandbreedteplanning: Schat de benodigde replicatiedoorvoer en houd rekening met de kosten voor gegevensoverdracht per GB voor wereldwijde VNet-peering. Replicatie van grote volumes tussen verre regio's kan aanzienlijke kosten voor uitgaand verkeer genereren.
  • Conflictoplossing: Actief-actieve patronen met bidirectionele schrijfbewerkingen vereisen conflictoplossingsstrategieën in de toepassings- of databaselaag. Het netwerk biedt connectiviteit, maar toepassingen moeten schrijfconflicten afhandelen.
  • Privé-eindpunten voor PaaS-replicatie: Wanneer u Azure SQL, Cosmos DB of Opslag tussen regio's repliceert, gebruikt u privé-eindpunten in elke regio om replicatieverkeer op de Microsoft backbone te houden en blootstelling aan openbaar internet te voorkomen.

Kostenoverwegingen

Netwerken met meerdere regio's verhogen de kosten door middel van gedupliceerde infrastructuur en gegevensoverdracht tussen regio's. Plan uw budget rond deze primaire kostenfactoren:

  • Gegevensoverdracht tussen regio's: Voor Global VNet-peering en Virtual WAN-inter-hubverkeer worden kosten per GB in rekening gebracht wanneer gegevens regiogrenzen overschrijden. Verkeer binnen een regio tussen gekoppelde VNets in dezelfde regio brengt geen extra kosten met zich mee binnen dezelfde zone en wordt voor verkeer tussen zones tegen een lager tarief in rekening gebracht.
  • Gedupliceerde netwerkapparaten: Voor elke regio zijn eigen firewall-, load balancer- en gateway-exemplaren vereist. Actief-actieve implementaties verdubbelen deze kosten. Actief-passieve implementaties kunnen de kosten verlagen door kleinere lagen in de stand-byregio te gebruiken en omhoog te schalen tijdens een failover.
  • Algemene taakverdelingskosten: Zowel Traffic Manager als Front Door worden in rekening gebracht op basis van DNS-query's of aanvragen die zijn verwerkt. Front Door brengt extra kosten in rekening voor gegevensoverdracht van Edge PoPs naar back-ends.
  • ExpressRoute en VPN Gateway: ontwerpen met meerdere regio's vereisen vaak gatewayexemplaren in elke regio. ExpressRoute-circuits die meerdere regio's verbinden, voegen maandelijkse poortkosten en kosten per GB met datalimiet toe.
  • Optimaliseren met verkeerslocatie: Toepassingslagen ontwerpen om aanroepen tussen regio's te minimaliseren. Houd leesreplica's per regio dicht bij de compute om de replicatiebandbreedte te verlagen en de latentie voor latentiegevoelige query's te verminderen.

Beveiligingsoverwegingen

Een netwerk met meerdere regio's introduceert beveiligingsoverwegingen buiten implementaties in één regio:

  • Verkeer blijft op de Microsoft backbone. Al het verkeer tussen regio's via wereldwijde VNet-peering of Virtual WAN connectiviteit tussen hubs doorkruist het Microsoft backbone-netwerk, niet het openbare internet.
  • Zone-redundante firewalls implementeren in elke regio. Elke regionale hub heeft een eigen firewallinstantie nodig voor verkeersinspectie. Implementeer firewalls in beschikbaarheidszones om de beveiliging tijdens zonefouten te behouden.
  • Front Door WAF biedt edge-beveiliging. Wanneer u Front Door gebruikt, inspecteert het geïntegreerde Web Application Firewall verkeer voordat deze een regionale implementatie bereikt. Dit biedt een eerste verdedigingslaag aan de netwerkrand.
  • Plan de DNS-failover zorgvuldig. Traffic Manager-failover is afhankelijk van DNS TTL. Kortere TTLs maken snellere failover mogelijk, maar vergroten het DNS-queryvolume. Front Door biedt failover op verbindingsniveau die niet afhankelijk is van het verlopen van de DNS-cache van de client.
  • ExpressRoute Global Reach-verkeer blijft privé. Verkeer tussen on-premises sites die zijn verbonden via Global Reach raakt nooit het openbare internet aan. Het blijft op het Microsoft-backbone-netwerk tussen de circuits.
  • Beveiligde replicatiekanalen tussen regio's. Replicatieverkeer van de back-end via Global VNet Peering is standaard niet-openbaar, maar pas netwerkbeveiligingsgroepen toe en gebruik versleuteling voor gevoelige gegevens tijdens overdracht.

Als uw ontwerp voor meerdere regio's specifieke scenario's omvat die elders in deze handleiding worden behandeld, raadpleegt u:

Meer informatie

Zie de volgende bronnen voor meer informatie over de services en concepten die in dit artikel worden besproken:

Volgende stappen 

Tip

Zelf verkennen? Ga terug naar de overzichtsnavigator om uw volgende artikel per mogelijkheid te vinden.

De volgende stap in uw lift-and-shift-traject:

Maak verbinding met uw on-premises netwerk: na de planning voor herstel na noodgevallen moet u een VPN- of ExpressRoute-verbinding met on-premises maken.

Vervolgens in uw moderniseringstraject:

Ontwerp uw patronen voor inkomend internetverkeer: Bepaal hoe klantverkeer uw applicaties bereikt via uw primaire en back-upregio's.

De volgende stap in uw cross-cloudtraject:

Versleutelde tunnels instellen voor uw andere clouds: na de planning van meerdere regio's configureert u vpn-connectiviteit tussen clouds.

  • Last updated on