Regio's voor landingszones

In dit artikel wordt uitgelegd hoe landingszones Azure-regio's gebruiken. De architectuur van de Azure-landingszone is regioneutraal, maar u moet Azure-regio's opgeven om uw Azure-landingszonearchitectuur te implementeren. In de volgende richtlijnen wordt beschreven hoe u een regio toevoegt aan een bestaande landingszone en ook overwegingen biedt voor het migreren van uw Azure-estate naar een andere regio.

In sommige situaties moet u toepassingen implementeren in meerdere Azure-regio's ter ondersteuning van uw bedrijfsvereisten voor hoge beschikbaarheid en herstel na noodgevallen. Mogelijk hebt u niet direct behoefte aan toepassingen met meerdere regio's, maar moet u uw Azure-landingszoneplatform ontwerpen ter ondersteuning van meerdere regio's, met name voor connectiviteits-, identiteits- en beheerservices. Zorg ervoor dat u snel landingszones voor toepassingen met meerdere regio's kunt inschakelen en ondersteunen.

Zie Azure-regio's selecteren voor meer informatie.

Landingszones en Azure-regio's

Azure-landingszones bestaan uit een set resources en configuratie. Sommige van deze items, zoals beheergroepen, beleidsregels en roltoewijzingen, worden op tenant- of beheergroepniveau opgeslagen in de architectuur van de Azure-landingszone. Deze resources worden niet geïmplementeerd in een bepaalde regio en worden in plaats daarvan wereldwijd geïmplementeerd. U moet echter nog steeds een implementatieregio opgeven omdat Azure enkele van de metagegevens van resources in een regionaal metagegevensarchief bijhoudt.

Andere resources worden regionaal geïmplementeerd. Afhankelijk van de configuratie van uw eigen landingszone hebt u mogelijk enkele of alle volgende regionaal geïmplementeerde resources:

• Een Werkruimte voor Azure Monitor-logboeken, met inbegrip van geselecteerde oplossingen
• Een Azure Automation-account
• Resourcegroepen voor de andere resources

Als u een netwerktopologie implementeert, moet u ook een Azure-regio selecteren waarnaar u de netwerkresources wilt implementeren. Deze regio kan afwijken van de regio die u gebruikt voor de resources die in de voorgaande lijst worden vermeld. Afhankelijk van de topologie die u selecteert, kunnen de netwerkresources die u implementeert, het volgende omvatten:

• Azure Virtual WAN, met inbegrip van een Virtual WAN-hub
• Virtuele netwerken van Azure
• VPN Gateway
• Azure ExpressRoute-gateway
• Azure Firewall
• Azure DDoS Protection-abonnementen
• Privé-DNS-zones van Azure, inclusief zones voor Azure Private Link
• Resourcegroepen, om de voorgaande resources te bevatten

Notitie

Als u het effect van regionale storingen wilt minimaliseren, raden we u aan resources in dezelfde regio als de resourcegroep te plaatsen. Zie Locatie-uitlijning van resourcegroep voor meer informatie.

Een nieuwe regio toevoegen aan een bestaande landingszone

U moet een strategie voor meerdere regio's overwegen, hetzij vanaf het begin van uw cloudtraject, of door zich uit te breiden naar meer Azure-regio's nadat u de eerste implementatie van uw Azure-landingszonearchitectuur hebt voltooid. Als u bijvoorbeeld Azure Site Recovery gebruikt om herstel na noodgevallen voor uw virtuele machines in te schakelen, kunt u ze repliceren naar een andere Azure-regio. Als u Azure-regio's wilt toevoegen binnen uw Azure-landingszonearchitectuur, moet u rekening houden met de volgende aanbevelingen:

Gebied	Aanbeveling
Beheergroepen	Geen actie nodig. Beheergroepen zijn niet gekoppeld aan een regio. U moet geen structuur voor beheergroepen maken op basis van regio's.
Abonnementen	Abonnementen zijn niet gekoppeld aan een regio.
Azure Policy	Breng wijzigingen aan in Azure Policy als u beleidsregels hebt toegewezen om resource-implementatie naar alle regio's te weigeren door een lijst met 'toegestane' Azure-regio's op te geven. Werk deze toewijzingen bij om resource-implementaties toe te staan in de nieuwe regio die u wilt inschakelen.
Op rollen gebaseerd toegangsbeheer (RBAC)	Geen actie nodig. Azure RBAC is niet gekoppeld aan een regio.
Controle en logboekregistratie	Bepaal of u één Azure Monitor-logboekwerkruimte wilt gebruiken voor alle regio's of meerdere werkruimten wilt maken om verschillende geografische regio's te behandelen. Elke benadering heeft voor- en nadelen, waaronder potentiële netwerkkosten voor meerdere regio's. Zie Een Log Analytics-werkruimtearchitectuur ontwerpen voor meer informatie.
Netwerken	Als u een netwerktopologie, Virtual WAN of traditionele hub en spoke implementeert, vouwt u het netwerk uit naar de nieuwe Azure-regio. Maak een andere netwerkhub door de vereiste netwerkresources te implementeren in het bestaande Verbinding maken iviteitsabonnement in de nieuwe Azure-regio. Azure Virtual Network Manager kan het eenvoudiger maken om virtuele netwerken op schaal uit te breiden en te beheren in meerdere regio's. Vanuit het perspectief van Domain Name System (DNS) wilt u mogelijk ook doorstuurservers implementeren in de nieuwe Azure-regio als u ze gebruikt. Gebruik doorstuurservers voor virtuele spoke-netwerken in de nieuwe regio voor oplossing. Azure DNS-zones zijn globale resources en zijn niet gekoppeld aan één Azure-regio, zodat ze geen actie hoeven te ondernemen.
Identiteit	Als u Active Directory-domein Services of Microsoft Entra Domain Services hebt geïmplementeerd in uw identiteitsabonnement of spoke, vouwt u de service uit naar de nieuwe Azure-regio.

Notitie

U moet ook beschikbaarheidszones gebruiken voor hoge beschikbaarheid binnen een regio. Controleer of uw regio's en services beschikbaarheidszones ondersteunen.

Microsoft Cloud for Sovereignty heeft richtlijnen voor het beperken van services en regio's. U kunt deze richtlijnen gebruiken om serviceconfiguratie af te dwingen om klanten te helpen hun gegevenslocatiebehoeften te bereiken.

Benadering op hoog niveau

Wanneer u een Azure-landingszone uitvouwt in een nieuwe regio, kunt u overwegen de stappen in deze secties uit te voeren. Voordat u begint, moet u beslissen over een nieuwe Azure-regio of meerdere Azure-regio's om uit te breiden.

Netwerken

Traditionele hub-and-spoke-architectuur

Tip

Bekijk een traditionele hub-and-spoke-architectuur.

1. Bepaal of u een nieuw platformlandingszoneabonnement nodig hebt. We raden aan dat de meeste klanten hun bestaande Verbinding maken iviteitsabonnementen gebruiken, zelfs wanneer ze meerdere regio's gebruiken.

2. Maak binnen het abonnement een nieuwe resourcegroep in de nieuwe doelregio.

3. Maak een nieuw virtueel hubnetwerk in de nieuwe doelregio.

4. Implementeer, indien van toepassing, virtuele Azure Firewall- of netwerkapparaten (NVA's) in uw nieuwe virtuele hubnetwerk.

5. Implementeer, indien van toepassing, virtuele netwerkgateways voor VPN- of ExpressRoute-connectiviteit en maak verbindingen. Zorg ervoor dat uw ExpressRoute-circuits en on-premises locaties de aanbevelingen voor tolerantie van Microsoft volgen. Zie Ontwerpen voor herstel na noodgevallen met persoonlijke ExpressRoute-peering voor meer informatie.

6. Peering van virtuele netwerken tot stand brengen tussen het nieuwe hub-virtuele netwerk en de andere virtuele hubnetwerken.

7. Maak en configureer alle vereiste routering, zoals Azure Route Server of door de gebruiker gedefinieerde routes.

8. Implementeer indien nodig DNS-doorstuurservers voor de nieuwe doelregio en koppel deze aan privé-DNS-zones om naamomzetting in te schakelen.

   • Sommige klanten kunnen naamomzetting configureren op hun Windows Server Active Directory-domeincontrollers binnen het abonnement op de landingszone voor identiteitsplatforms .

Als u uw workloads wilt hosten, kunt u vervolgens peering van virtuele netwerken gebruiken om toepassingslandingszone-spokes te verbinden met het nieuwe virtuele hubnetwerk in de nieuwe regio.

Tip

Virtual Network Manager kan het eenvoudiger maken om virtuele netwerken op schaal uit te breiden en te beheren in meerdere regio's.

Virtuele WAN-architectuur

Tip

Bekijk een Virtual WAN-architectuur.

1. Maak in uw bestaande Virtuele WAN een nieuwe virtuele hub in de nieuwe doelregio.

2. Implementeer Azure Firewall of andere ondersteunde virtuele netwerkapparaten (NVA's) in uw nieuwe virtuele hub. Configureer de intentie van Virtual WAN-routering en routeringsbeleid om verkeer te routeren via de nieuwe beveiligde virtuele hub.

3. Implementeer, indien van toepassing, virtuele netwerkgateways voor VPN- of ExpressRoute-connectiviteit in de nieuwe virtuele hub en maak verbindingen. Zorg ervoor dat uw ExpressRoute-circuits en on-premises locaties de aanbevelingen voor tolerantie van Microsoft volgen. Zie Ontwerpen voor herstel na noodgevallen met persoonlijke ExpressRoute-peering voor meer informatie.

4. Maak en configureer eventuele andere routering die u nodig hebt, zoals statische routes voor virtuele hubs.

5. Implementeer indien van toepassing DNS-doorstuurservers voor de nieuwe doelregio en koppel deze aan privé-DNS-zones om omzetting mogelijk te maken.

   • Sommige klanten kunnen naamomzetting configureren op hun Active Directory-domeincontrollers binnen het abonnement op de landingszone van het identiteitsplatform .

   • In Virtual WAN-implementaties moet dit zich in een virtueel spoke-netwerk bevinden dat is verbonden met de virtuele hub via een virtuele netwerkverbinding, volgens het patroon van de virtuele hubextensie.

Als u uw workloads wilt hosten, kunt u vervolgens peering van virtuele netwerken gebruiken om toepassingslandingszone-spokes te verbinden met het nieuwe virtuele hubnetwerk in de nieuwe regio.

Identiteit

Tip

Bekijk het ontwerpgebied van de Azure-landingszone voor identiteits- en toegangsbeheer.

1. Bepaal of u een nieuw platformlandingszoneabonnement nodig hebt. We raden de meeste klanten aan hun bestaande identiteitsabonnement te gebruiken, zelfs wanneer ze meerdere regio's gebruiken.

2. Maak een nieuwe resourcegroep in de nieuwe doelregio.

3. Maak een nieuw virtueel netwerk in de nieuwe doelregio.

4. Maak peering van virtuele netwerken terug naar het zojuist gemaakte regionale hub-virtuele netwerk in het Verbinding maken iviteitsabonnement.

5. Implementeer identiteitsworkloads, zoals virtuele machines van de Active Directory-domeincontroller, in het nieuwe virtuele netwerk.

   • Mogelijk moet u meer instellingen van de workloads uitvoeren zodra deze zijn ingericht, zoals de volgende configuratiestappen:

     • Promoot de virtuele machines van de Active Directory-domeincontroller naar het bestaande Active Directory-domein.

     • Maak nieuwe Active Directory-sites en -subnetten.

     • Dns-serverinstellingen configureren, zoals voorwaardelijke doorstuurservers.

Uw Azure-estate verplaatsen naar een nieuwe regio

Mogelijk moet u af en toe uw hele Azure-estate verplaatsen naar een andere regio. Stel dat u uw landingszone en workloads hebt geïmplementeerd in een Azure-regio in een naburig land of een naburige regio en vervolgens een nieuwe Azure-regio start in uw land of regio. U kunt ervoor kiezen om al uw workloads naar de nieuwe regio te verplaatsen om de communicatielatentie te verbeteren of om te voldoen aan de vereisten voor gegevenslocatie.

Notitie

Dit artikel bevat informatie over het migreren van de onderdelen van de landingszone van uw estate. Zie Cloudworkloads verplaatsen voor meer informatie.

Algemene configuratie van landingszone

De meeste configuratie van de wereldwijd geïmplementeerde landingszone hoeft doorgaans niet te worden gewijzigd wanneer u regio's verplaatst. Zorg er echter voor dat u controleert op beleidstoewijzingen die regio-implementaties beperken en het beleid bijwerken om implementaties in de nieuwe regio toe te staan.

Resources voor regionale landingszones

Regiospecifieke landingszoneresources vereisen vaak meer aandacht, omdat u sommige Azure-resources niet tussen regio's kunt verplaatsen. Houd rekening met de volgende aanpak:

1. Voeg de doelregio toe als een extra regio aan uw landingszone: Zie Een nieuwe regio toevoegen aan een bestaande landingszone voor meer informatie.

2. Gecentraliseerde onderdelen implementeren in de doelregio: implementeer bijvoorbeeld een nieuwe Azure Monitor-logboekwerkruimte in uw doelregio, zodat workloads het nieuwe onderdeel kunnen gaan gebruiken nadat u de workload hebt gemigreerd.

3. Migreer uw workloads van de bronregio naar de doelregio: tijdens het migratieproces van de werkbelasting configureert u de resources opnieuw om de netwerkonderdelen, identiteitsonderdelen, de werkruimte Azure Monitor-logboeken en andere regionale resources te gebruiken.

4. De resources uit bedrijf nemen in de bronregio nadat u de migratie hebt voltooid.

Houd rekening met de volgende tips wanneer u resources voor landingszones migreert tussen regio's:

• Infrastructuur als code gebruiken: Bicep, Azure Resource Manager-sjablonen (ARM-sjablonen), Terraform, scripting of een vergelijkbare benadering voor het exporteren en opnieuw importeren van complexe configuraties, zoals regels voor Azure Firewall.

• Automatisering: Gebruik scripts om Automation-resources tussen regio's te migreren.

• ExpressRoute: Overweeg of u de lokale ExpressRoute-SKU in uw doelregio kunt gebruiken. Als uw on-premises omgevingen zich binnen hetzelfde grootstedelijke gebied bevinden als uw Azure-regio, kan ExpressRoute Local een goedkopere optie bieden in vergelijking met andere ExpressRoute-SKU's.

Volgende stap

Governance van landingszones verbeteren