Delen via

Azure-regio's selecteren

  • Artikel

Wanneer u uw strategie ontwerpt voor het gebruik van Microsoft Azure, kunt u kiezen uit veel Azure-regio's over de hele wereld. Regioselectie is een belangrijk onderdeel van uw algehele strategie voor cloudimplementatie. Elke Azure-regio heeft specifieke kenmerken, dus het is essentieel om de beste regio's voor uw Azure-resources te kiezen.

Inzicht in Azure-regioarchitecturen en -tolerantie

Verschillende Azure-regio's hebben verschillende kenmerken. Twee veelvoorkomende manieren waarop Azure-regio's variëren, zijn beschikbaarheidszones en gekoppelde regio's. Sommige regio's worden ook beheerd door soevereine entiteiten in bepaalde landen. De regioarchitectuur verwijst naar de wijze waarop een specifieke regio is ontworpen en de algemene regionale mogelijkheden die deze biedt.

Zie Wat zijn Azure-regio's en beschikbaarheidszones voor meer informatie over hoe Azure-regio's werken.

Beschikbaarheidszones

Veel Azure-regio's bevatten beschikbaarheidszones, die fysiek gescheiden locaties binnen een regio zijn. Met behulp van beschikbaarheidszones kunt u hogere beschikbaarheid en tolerantie in uw implementaties bereiken. Zie beschikbaarheidszone en regionale ondersteuning voor meer informatie over beschikbaarheidszones en voor een lijst met Azure-regio's en -services die beschikbaarheidszones ondersteunen.

Gekoppelde regio's

Sommige regio's zijn gekoppeld aan een andere regio, waarbij beide regio's zich meestal in hetzelfde geopolitieke gebied bevinden. Regiokoppeling biedt tolerantie tijdens onherstelbare regiofouten. Regiokoppeling wordt meestal gebruikt voor geografisch redundante opslag (GRS) en andere Azure-services die afhankelijk zijn van Azure Storage voor replicatie.

Nieuwere regio's worden niet gekoppeld. In plaats daarvan gebruiken ze beschikbaarheidszones voor hoge beschikbaarheid en tolerantie. Verderop in dit artikel vindt u meer informatie over het gebruik van deze regiotypen.

Tip

Zie Aanbevelingen voor het gebruik van beschikbaarheidszones voor meer informatie over het ontwerpen van een workload die gebruikmaakt van regio's en beschikbaarheidszones.

Soevereine regio's

Sommige regio's zijn toegewezen aan specifieke onafhankelijke entiteiten. Hoewel alle regio's Azure-regio's zijn, worden deze soevereine regio's geïsoleerd van de rest van Azure. Microsoft beheert ze niet noodzakelijkerwijs en ze kunnen worden beperkt tot bepaalde soorten klanten. Deze onafhankelijke regio's zijn Azure China 21Vianet en Azure Government - VS. Onafhankelijke regio's zijn gebouwd op dezelfde standaarden voor tolerantie als andere Azure-regio's.

Overweeg beschikbaarheid en capaciteit van regioservices

Azure biedt twee typen regio's:

  • Aanbevolen regio's zijn geschikt voor de meeste workloads.
  • Alternatieve regio's zijn niet geoptimaliseerd voor primaire workloads. In plaats daarvan zijn alternatieve regio's alleen beschikbaar voor back-up of failover, of alleen voor klanten met een aanwezigheid van een bedrijf binnen een gedefinieerd land/regio.

Bij het kiezen van een regio is het een goed idee om een aanbevolen regio te selecteren, indien mogelijk, vanwege de volgende voordelen:

  • Aanbevolen regio's hebben doorgaans een hogere capaciteit. Vanwege de grotere capaciteit kunnen aanbevolen regio's uw langetermijngroei vaak beter ondersteunen dan alternatieve regio's.
  • Lagere kosten. Veel aanbevolen regio's bieden lagere kosten voor een reeks Azure-services. Door aanbevolen regio's te gebruiken, kunt u de totale Azure-factuur verminderen.
  • Krijg vroege toegang tot de nieuwste aanbiedingen. Ai-mogelijkheden en GPU-resources zijn bijvoorbeeld doorgaans eerder beschikbaar in aanbevolen regio's dan in andere regio's. 

Microsoft beoordeelt regelmatig de regio's die we aanbevelen. Als u wilt profiteren van de voordelen van nieuw aanbevolen regio's, kunt u overwegen een strategie voor meerdere regio's te gebruiken. Deze strategie helpt ervoor te zorgen dat u klaar bent voor het gebruik van meer regio's voor uw eigen workloads.

De services die u in een regio kunt implementeren, zijn onder andere afhankelijk van het type regio. Voor meer informatie raadpleegt u de volgende bronnen:

Sommige regio's zijn gereserveerd voor klanten die noodherstel in hun land/regio nodig hebben. Als u toegang wilt aanvragen tot deze gereserveerde toegangsregio's, maakt u een nieuwe ondersteuningsaanvraag.

Azure is een zeer schaalbaar platform, maar elke regio heeft een maximale capaciteit. De maximale capaciteit van een regio kan van invloed zijn op welke typen abonnementen kunnen worden geïmplementeerd welke typen services en onder welke omstandigheden. Regionale capaciteit verschilt van een abonnementsquotum. Als u een implementatie of migratie naar Azure plant, is het een goed idee om te spreken met uw lokale Azure-veldteam of uw Azure-accountmanager. Vraag om bevestiging dat u kunt implementeren op de schaal die u nodig hebt.

Wanneer u regio's gebruikt voor herstel na noodgevallen, moet u overwegen of de doelregio de capaciteit biedt die u nodig hebt om uw workloads te ondersteunen. Voor workloads die zijn gebaseerd op virtuele machines (VM's), kunt u capaciteitsreservering gebruiken om de beschikbaarheid van capaciteit in de regio's te garanderen die u gebruikt.

Informatie over gegevenslocatie

Over de hele wereld zijn overheidsorganisaties begonnen met het vaststellen van gegevenssoevereine en regelgeving voor gegevensprivacy. Voor dit soort nalevingsvereisten is vaak lokalisatie in een specifiek land/specifieke regio vereist om de burgers op die locatie te beschermen. In sommige gevallen moeten gegevens die betrekking hebben op klanten, werknemers of partners, worden opgeslagen op een cloudplatform in dezelfde regio als de gebruiker.

Zorg ervoor dat u uw eigen vereisten voor gegevenslocatie begrijpt. Controleer ook of de Azure-regio's die u selecteert zich in geografische locaties bevinden die voldoen aan uw vereisten. Zie Gegevenslocatie en gegevensbescherming inschakelen in Microsoft Azure-regio's voor meer informatie.

Het aanpakken van problemen met gegevenslocatie is een belangrijke motivatie voor organisaties die op wereldwijde schaal werken om naar de cloud te migreren. Om de naleving van gegevenssoevereine te behouden, kiezen sommige organisaties ervoor om dubbele IT-assets te implementeren in cloudproviders in hun geselecteerde regio.

Microsoft Cloud for Sovereignty is een oplossing waarmee overheden workloads in de Microsoft Cloud kunnen implementeren en tegelijkertijd kunnen voldoen aan hun specifieke soevereiniteit, naleving, beveiliging en beleidsvereisten. Microsoft Cloud for Sovereignty maakt softwaregrenzen in de cloud om de extra bescherming te bepalen die overheden nodig hebben, met behulp van vertrouwelijkheid en versleutelingscontroles op basis van hardware. Zie Mogelijkheden Microsoft Cloud for Sovereignty voor meer informatie.

Overweeg regionabijheid

Gebruikers of services die toegang nodig hebben tot uw Azure-services, bevinden zich mogelijk in verschillende geografische gebieden wereldwijd. Op dezelfde manier moeten uw Azure-services mogelijk services gebruiken uit externe bronnen die zich in verschillende geografische gebieden bevinden. Of uw services moeten mogelijk verbinding maken met uw on-premises systemen.

Nabijheid is een belangrijke factor die u moet overwegen wanneer u een Azure-regio selecteert. Als u Azure ExpressRoute gebruikt om verbinding te maken met uw on-premises systemen, kunt u de netwerkverbinding optimaliseren en latentie verminderen met behulp van een regio die zich dicht bij uw on-premises systemen bevindt. Volgende verbindingen tussen Azure-regio's maken gebruik van het wereldwijde Microsoft-netwerk met hoge snelheid.

Zie de statistieken over latentie tussen Azure-regio's en andere geografische gebieden voor meer informatie over latentie tussen Azure-regio's en andere geografische gebieden.

Werken in meerdere geografische regio's

Het is gebruikelijk dat een organisatie in meerdere geografische regio's werkt. Een organisatie kan de volgende voordelen krijgen met behulp van meerdere Azure-regio's:

  • Verschillende workloads uitvoeren in verschillende regio's. Deze reden is van toepassing wanneer u dicht bij een specifiek klantenbestand of een specifieke zakelijke partner wilt zijn. Het is ook relevant wanneer u Azure-services wilt gebruiken die niet beschikbaar zijn in een specifieke Azure-regio.
  • Ondersteuning bieden voor een geografisch verspreide gebruikersbasis. Als u in meerdere landen werkt of als uw klanten uw services uit meerdere landen gebruiken, kan het zinvol zijn om Azure-resources op elke locatie te hebben. U kunt ook overwegen om één regio te gebruiken en vervolgens Azure Front Door te gebruiken om wereldwijd verkeer naar die regio te versnellen.
  • Voldoen aan vereisten voor gegevenssoevereine. Uw organisatie kan onderhevig zijn aan limieten voor de geografische gebieden waar u bepaalde gegevens kunt opslaan.
  • Hoge tolerantie bereiken, met name voor bedrijfskritieke workloads. Bedrijfskritieke workloads vereisen de voordelen die beschikbaarheidszones bieden, zoals hoge beschikbaarheid en bescherming tegen storingen en rampen in de hele regio.
  • Netwerkconnectiviteit en prestaties verbeteren. In een hybride of multicloudscenario kan het gebruik van meerdere Azure-regio's helpen uw netwerkprestaties te verbeteren. Verkeer kan het high-speed Microsoft backbone-netwerk binnenkomen en verlaten op locaties die zich dicht bij uw on-premises systemen of op de locaties van een andere cloudprovider bevinden. Zie Verbinding maken iviteit voor andere cloudproviders voor meer informatie over multicloudoplossingen.
  • Kosten optimaliseren. Verschillende Azure-resourcetypen kunnen verschillende prijzen hebben in verschillende regio's. Wanneer u hulpprogramma's zoals de prijscalculator en de prijsinformatie van de Azure-service gebruikt, moet u ervoor zorgen dat u de juiste regio selecteert om nauwkeurige prijsinformatie weer te geven. Soms kunt u kosten verlagen door uw ontwikkel- en testomgevingen in een andere regio te implementeren. Maar u moet ervoor zorgen dat de regio de mogelijkheden en services biedt die u in uw productieregio gebruikt.
  • Schaal verder dan resourcequota. Sommige Azure-resources hebben quota en limieten die het aantal exemplaren van een resource beperken dat u in elke regio onder elk abonnement kunt maken. Als u deze limieten wilt overschrijden, moet u mogelijk extra abonnementen of meerdere regio's gebruiken.
  • Vermijd capaciteitsbeperkingen. Af en toe gelden er capaciteitsbeperkingen voor regio's. Als u meerdere regio's gebruikt, is het waarschijnlijk eenvoudiger voor u om een regio te vinden en te gebruiken die ondersteuning biedt voor de services die u wilt implementeren. Als u één regio gebruikt en moet uitbreiden naar een tweede regio om capaciteitsbeperkingen te voorkomen, kan het langer duren voordat u uw resources voorbereidt en implementeert.
  • Verminder de complexiteit ten opzichte van implementaties met meerdere clouds. De complexiteit van het beheren van implementaties in meerdere regio's is doorgaans minder dan implementaties met meerdere clouds, en u kunt vaak vergelijkbare beschikbaarheids- en tolerantievoordelen krijgen. De keuze tussen de twee benaderingen is echter afhankelijk van de specifieke doelstellingen van uw organisatie.

Houd rekening met de volgende factoren wanneer u een cloudomgeving gebruikt die is verspreid over meerdere geografische regio's:

  • Operationele complexiteit. Wanneer u meerdere resources in verschillende regio's hebt, kan er extra operationele overhead zijn. Mogelijk moet u ook extra kosten betalen wanneer u resources dupliceren tussen regio's.
  • Gegevenssynchronisatie. Begrijp of u gegevens tussen regio's moet synchroniseren of repliceren. Als u dat doet, moet u weten of u dit asynchroon of synchroon moet doen. Het configureren van een opslaglaag voor gegevens in meerdere regio's kan complex zijn. U moet rekening houden met tolerantie, prestaties en kosten.
  • Wereldwijde netwerktopologie. Azure biedt veel verschillende netwerkservices. Azure biedt ook ondersteuning voor de implementatie van verschillende wereldwijde netwerktopologieën om te voldoen aan verschillende vereisten en verschillende compromissen te bieden. U kunt bijvoorbeeld Azure-netwerken uitbreiden naar meerdere regio's met behulp van Azure Virtual WAN of u kunt een traditioneel hub-and-spoke-model gebruiken met extra inspanning.
  • Profielen voor gebruikerstoegang. Als één gebruiker met onderdelen in meerdere regio's werkt, begrijpt u hoe u hun identiteiten en toegangsprofielen in verschillende regio's beheert.
  • Nalevingsvereisten. Controleer of elke regio voldoet aan uw nalevingsvereisten, inclusief vereisten voor gegevenssoevereine.
  • Regionale tolerantie. Hoewel het gebruik van een architectuur met meerdere regio's helpt om de tolerantie te vergroten, moet u ook uw oplossing ontwerpen om maximaal beschikbaar te zijn binnen elke regio. Gebruik beschikbaarheidszones waar u kunt en zorg ervoor dat u bedenkt hoe u een hoge tolerantie binnen elke regio kunt bereiken.
  • Failover. Wanneer u meerdere regio's gebruikt voor tolerantiedoeleinden, kunt u uw oplossing ontwerpen om een actief-passieve benadering te gebruiken. Voor deze aanpak moet u regionale storingen detecteren en een failover uitvoeren voor verkeer tussen regio's. Het kan even duren voordat een failoverproces een storing en volledige verkeersroutering detecteert, wat kan leiden tot downtime voor uw services. Sommige organisaties kiezen er in plaats daarvan voor om te implementeren in een actief-actief patroon om te voorkomen dat er gebruik wordt gemaakt van failover. De voordelen van het gebruik van een actief-actief patroon zijn wereldwijde taakverdeling, verhoogde fouttolerantie en prestatieverbeteringen in het netwerk. Als u wilt profiteren van dit patroon, moeten uw toepassingen ondersteuning bieden voor gelijktijdig uitvoeren in meerdere regio's.

Verplaatsen tussen regio's

Soms moet u resources of workloads mogelijk verplaatsen van de ene Azure-regio naar de andere. Wijzigingen in bedrijfsvereisten, bedrijfsaankopen, wetten voor gegevenslocatie en andere factoren zijn redenen om te verhuizen.

Tip

Het verplaatsen van resources tussen regio's kan complex zijn. Probeer uw resources vanaf het begin in de juiste regio te implementeren.

Azure biedt verschillende hulpprogramma's en verschillende herlocatiemogelijkheden, maar de details variëren voor elke Azure-service. Sommige resourcetypen kunnen rechtstreeks worden verplaatst tussen regio's en andere kunnen worden verplaatst met behulp van Azure Resource Mover. Sommige resourcetypen kunnen niet worden verplaatst en moeten opnieuw worden geïmplementeerd.

Zie Cloudworkloads verplaatsen voor meer informatie over het verplaatsen naar verschillende regio's.

Hoge beschikbaarheid en herstel na noodgevallen tussen regio's

Azure-regio's zijn maximaal beschikbaar. Azure-serviceovereenkomsten worden toegepast op de services die in specifieke regio's worden uitgevoerd. Deze sectie bevat enkele overwegingen die van toepassing zijn als u ervoor kiest om te implementeren in meerdere regio's om uw tolerantie te vergroten.

Waarschuwing

Wanneer u bedrijfskritieke workloads ontwerpt, moet u altijd plannen voor regionale storingen en implementatie in één regio voorkomen. U moet ook stappen voor herstel en risicobeperking oefenen. Zie Bedrijfskritieke workloads voor meer informatie.

Meer informatie over tolerantiefuncties voor Azure-services

Veel PaaS-services (Platform as a Service) zijn afhankelijk van hun eigen regionale tolerantieoplossingen. Wanneer u bijvoorbeeld Azure SQL Database en Azure Cosmos DB implementeert, kunt u uw gegevens eenvoudig repliceren naar meer regio's. Andere services worden geïmplementeerd in één regio en u moet ze handmatig implementeren in andere regio's. Sommige Azure-services, zoals Azure DNS en Azure Front Door, worden ook wereldwijd geïmplementeerd en hebben geen regionale afhankelijkheden.

Voor elke Azure-service die u voor uw cloudimplementatieproces overweegt, begrijpt u de vereiste failovermogelijkheden en herstelstappen.

Implementaties van Azure-resourcegroepen plannen

Voor het meest betrouwbare scenario en om het effect van regionale storingen te minimaliseren, raden we u aan resources in dezelfde regio te plaatsen als de resourcegroep. Zie Locatie-uitlijning van resourcegroep voor meer informatie.

Als u resources in verschillende regio's binnen dezelfde resourcegroep hebt, kunt u overwegen om uw resources te verplaatsen naar een nieuwe resourcegroep of een nieuw abonnement.

Als u wilt bepalen of uw resource ondersteuning biedt voor het verplaatsen naar een andere resourcegroep, moet u uw resources inventariseren door ze kruislings te raadplegen. Zorg ervoor dat u voldoet aan de juiste vereisten.

Tip

Implementeer indien mogelijk resourcegroepen in een regio met meerdere beschikbaarheidszones. Beschikbaarheidszones helpen bij het minimaliseren van het risico van regionale storingen die de beschikbaarheid van uw resource verminderen en beheerbewerkingen ook niet beschikbaar maken.

In sommige gevallen omvatten resources in een resourcegroep meerdere regio's. Als een hele regio niet beschikbaar is, kunnen alle beheerbewerkingen die betrekking hebben op resources in de resourcegroepen van de niet-beschikbare regio mislukken. Maar resources die in een andere regio zijn geïmplementeerd, blijven mogelijk beschikbaar, ook al kunnen ze niet worden beheerd. In sommige scenario's kunt u, om ervoor te zorgen dat resources altijd beschikbaar blijven, een resourcegroep in meerdere regio's plaatsen. Deze benadering heeft beperkingen, maar behoudt de beschikbaarheid van resources tijdens een tijdelijke storing.

GRS gebruiken in gekoppelde regio's

Als u implementeert in een regio met een gekoppelde gekoppelde regio, kunt u de gekoppelde regio gebruiken als onderdeel van uw tolerantiestrategie voor meerdere regio's. Met gekoppelde regio's kunt u primaire en secundaire regio's gebruiken.

Azure Storage ondersteunt GRS. In Storage GRS worden drie kopieën van uw gegevens opgeslagen in uw primaire regio en worden er nog drie kopieën opgeslagen in de gekoppelde regio. U kunt de opslagkoppeling voor GRS niet wijzigen. Andere Azure-services die afhankelijk zijn van Storage, profiteren vaak van deze gekoppelde regio-mogelijkheid. Uw toepassingen en uw netwerk moeten zijn geconfigureerd om gekoppelde regio's te ondersteunen en GRS-opslag op de juiste wijze te kunnen gebruiken.

Probeer geen opslag te gebruiken met GRS-replicatie voor uw VM-back-ups. Gebruik in plaats daarvan Azure Backup-, Azure Site Recovery- en Azure Managed Disks om tolerantie voor uw IaaS-workloads (Infrastructure as a Service) te ondersteunen.

Tip

Oplossingen voor meerdere regio's hoeven geen opslag-GRS te gebruiken. In plaats daarvan zijn er verschillende andere opties beschikbaar:

  • Voer uw toepassingslaag uit voor toegang tot meerdere regio's.
  • Gebruik een wereldwijd gedistribueerde databaseservice, zoals Azure Cosmos DB of SQL Database.
  • Gebruik blobobjectreplicatie.
  • Gebruik een andere implementatiebenadering voor meerdere regio's.

Wanneer u in deze scenario's een secundaire regio selecteert, kunt u overwegen een regio te gebruiken die niet de gekoppelde regio is. Als er een regionale fout optreedt in uw primaire regio, wordt er intensieve druk uitgeoefend op resources in de gekoppelde regio wanneer resources worden gemigreerd en failover tussen regio's plaatsvindt. U kunt die druk vermijden door te herstellen naar een alternatieve regio, wat betekent dat u tijdens uw herstel snelheid krijgt.

Implementeren in regio's zonder een paar

Nieuwere Azure-regio's hebben geen regionaal paar. Ze bereiken hoge beschikbaarheid met behulp van beschikbaarheidszones. Dergelijke regio's volgen richtlijnen voor gegevenslocatie die de mogelijkheid bieden om gegevens in de regio op te slaan.

Wanneer u deze regio's gebruikt, kunt u lokaal redundante opslag (LRS) of zone-redundante opslag (ZRS) gebruiken. Regio's zonder paar bieden geen ondersteuning voor GRS. Voor services zoals Back-up met een afhankelijkheid van Storage moet u mogelijk ook ZRS- of LRS-opslag gebruiken. Indien mogelijk is het een goede gewoonte om ZRS te gebruiken om uw tolerantie binnen uw regio te verbeteren.

Als u zich wilt voorbereiden op de zeldzame gebeurtenis dat een hele Azure-regio niet beschikbaar is, moet u plannen voor herstel na noodgevallen tussen regio's. Het is ten minste een goede gewoonte om uw infrastructuur te implementeren met behulp van automatiseringsmethoden en om een back-up te maken van uw gegevens in verschillende regio's. Als er een storing in de volledige regio optreedt, kunt u uw resources handmatig opnieuw implementeren en uw back-ups herstellen. Voor sommige scenario's moet u mogelijk andere alternatieven overwegen om uw potentiële hersteltijd en gegevensverlies te verminderen. Zie beschikbaarheidszoneservice en regionale ondersteuning en Azure Resiliency – Bedrijfscontinuïteit en herstel na noodgevallen voor meer informatie.

Houd rekening met uw behoeften voor gegevenstolerantie. Ongeacht waar uw gegevens zich bevinden, kunt u uw gegevens verplaatsen, kopiëren of openen vanaf elke locatie wereldwijd.

Sommige Azure-services bieden een manier om uw gegevens in meerdere regio's op te slaan of te repliceren zonder dat de regio's worden gekoppeld. Voorbeeld:

Volgende stappen

Wanneer u bestaande workloads migreert van een on-premises datacenter naar Azure, zijn er enkele andere overwegingen voor regioselectie waarmee u rekening moet houden. Zie Azure-regio's selecteren voor een migratie voor meer informatie.