Ga naar inhoud

Regio-uitbreiding

Hoe je beslist of je een Azure-regio aan het platform toevoegt, en welke. De technische stappen staan in Een regio toevoegen. Deze pagina gaat over de beslissing.

Wanneer overweeg je een nieuwe regio

Typische aanleidingen:

  • de huidige regio heeft capaciteitsbeperkingen die deployments of beschikbaarheid raken,
  • de wens voor betere geografische redundantie of een disaster-recovery-doel,
  • eisen aan data residency of latency van een workload,
  • een service die je nodig hebt is niet beschikbaar in de huidige regio's.

Criteria

Vergelijk kandidaat-regio's op dezelfde lijst. Gebruik per criterium actuele informatie van Microsoft.

Criterium Vragen
Beschikbaarheid en volwassenheid van services Zijn de services die je gebruikt beschikbaar, nu en op de roadmap? (Check de services die je workloads gebruiken, bijvoorbeeld Kubernetes, databases en de Application Gateway SKU.)
Capaciteit en groei Heeft de regio capaciteitsuitbreiding laten zien, en is er meer gepland?
Latency Latency binnen de regio en naar je bestaande regio's. Lage latency tussen regio's is belangrijk voor disaster recovery en voor synchrone replicatie.
Redundantie Zijn er availability zones (drie of meer)? Is de regio geografisch onafhankelijk genoeg van de bestaande om te beschermen tegen een regionale storing?
Netwerkkosten Kosten voor data egress en transfer tussen regio's voor het verkeer dat je verwacht
Connectiviteit Kwaliteit van de connectiviteit naar je on-premises locaties en naar internet
Platformkosten Een nieuwe virtual hub, firewall en gateways hebben vaste maandelijkse kosten

Richtlijnen

  • Voeg één regio tegelijk toe, naast de bestaande, in plaats van een regio in één keer te vervangen. Zo kun je geselecteerde workloads geleidelijk verplaatsen en blijven de kosten beperkt.
  • Plaats workloads in de nieuwe regio wanneer aan de eisen voor capaciteit en services is voldaan. Gebruik hem alleen als failoverdoel als hij onafhankelijk genoeg is van de andere.
  • Houd firewallregels consistent tussen regio's, zodat een failover werkt. Zie Indeling van firewallregels.
  • Wijs de adresbereiken toe uit het IP-plan voordat je begint, en houd ze vrij van overlap met andere regio's en spokes.
  • Kies de korte regionaam zorgvuldig. Die wordt gebruikt in elke resourcenaam en in de state keys, en sommige resourcenamen hebben een lengtelimiet (Naamgeving en tags).

Gevolgen

Effect Detail
Kosten Een nieuwe virtual hub in de Virtual WAN met een firewall, DNS resolver en optionele gateways. Mogelijk kosten voor datatransfer tussen regio's voor workloads die over regio's heen praten.
Complexiteit Drie regio's beheren is complexer dan twee: meer routering, meer regelsets, meer plekken voor drift
Routering De routering kan aanpassingen nodig hebben zodat verkeer correct stroomt, ook naar on-premises netwerken
Plaatsing Geeft je een extra plek om workloads te plaatsen

Voorbeeld

Een platform draaide in twee regio's (een primaire en een failover). Vanwege capaciteitsbeperkingen in de primaire regio en de wens voor betere redundantie vergeleek het team meerdere kandidaat-regio's op bovenstaande criteria en koos één extra regio met een centrale ligging, een recente capaciteitsuitbreiding, een breed serviceaanbod, drie of meer availability zones en ruwweg 10 tot 15 ms latency naar de primaire regio. Hij werd naast de bestaande regio's toegevoegd, zodat workloads geleidelijk konden verhuizen. Dit is een voorbeeld van de redenering, geen aanbeveling voor een bepaalde regio.