Landningszonregioner

Den här artikeln beskriver hur landningszoner använder Azure-regioner. Arkitekturen i Azure-landningszonen är regionagnostisk, men du måste ange Azure-regioner för att distribuera din Arkitektur för Azure-landningszoner. Följande vägledning beskriver hur du lägger till en region i en befintlig landningszon och ger även överväganden för när du migrerar din Azure-egendom till en annan region.

I vissa situationer bör du distribuera program till flera Azure-regioner för att stödja dina affärskrav för hög tillgänglighet och haveriberedskap. Du kanske inte har ett omedelbart behov av program i flera regioner, men du bör utforma din Plattform för Azure-landningszoner för att stödja flera regioner, särskilt för anslutningar, identiteter och hanteringstjänster. Se till att du snabbt kan aktivera och stödja programlandningszoner för flera regioner.

Mer information finns i Välj Azure-regioner.

Landningszoner och Azure-regioner

Azure-landningszoner består av en uppsättning resurser och konfigurationer. Vissa av dessa objekt, till exempel hanteringsgrupper, principer och rolltilldelningar, lagras antingen på klient- eller hanteringsgruppsnivå i Azure-landningszonens arkitektur. Dessa resurser distribueras inte till en viss region och distribueras i stället globalt. Du måste dock fortfarande ange en distributionsregion eftersom Azure spårar vissa av resursmetadata i ett regionalt metadatalager.

Andra resurser distribueras regionalt. Beroende på konfigurationen av din egen landningszon kan du ha några eller alla följande regionalt distribuerade resurser:

• En Arbetsyta för Azure Monitor-loggar, inklusive valda lösningar
• Ett Azure Automation-konto
• Resursgrupper för de andra resurserna

Om du distribuerar en nätverkstopologi måste du också välja en Azure-region att distribuera nätverksresurserna till. Den här regionen kan skilja sig från den region som du använder för de resurser som anges i föregående lista. Beroende på vilken topologi du väljer kan de nätverksresurser som du distribuerar innehålla:

• Azure Virtual WAN, inklusive en Virtual WAN-hubb
• Virtuella Azure-nätverk
• VPN gateway
• Azure ExpressRoute-gateway
• Azure Firewall
• Azure DDoS Protection-planer
• Privata DNS-zoner i Azure, inklusive zoner för Azure Private Link
• Resursgrupper som ska innehålla föregående resurser

Lägga till en ny region i en befintlig landningszon

Du bör överväga en strategi för flera regioner, antingen från början av din molnresa eller genom att expandera till fler Azure-regioner när du har slutfört den första distributionen av azure-landningszonens arkitektur. Om du till exempel använder Azure Site Recovery för att aktivera haveriberedskap för dina virtuella datorer kanske du vill replikera dem till en annan Azure-region. Tänk på följande rekommendationer för att lägga till Azure-regioner i azure-landningszonens arkitektur:

Microsoft Cloud for Sovereignty har riktlinjer för att begränsa tjänster och regioner. Du kan använda dessa riktlinjer för att framtvinga tjänstkonfiguration för att hjälpa kunder att uppnå sina behov av datahemvist .

Metod på hög nivå

När du expanderar en Azure-landningszon till en ny region bör du överväga att följa stegen i de här avsnitten. Innan du börjar måste du bestämma dig för en ny Azure-region, eller flera Azure-regioner, att expandera till.

Nätverk

Traditionell hub-and-spoke-arkitektur

1. Bestäm om du behöver en ny plattformslandningszonprenumeration. Vi rekommenderar att de flesta kunder använder sina befintliga Anslut ivity-prenumerationer, även när de använder flera regioner.

2. I prenumerationen skapar du en ny resursgrupp i den nya målregionen.

3. Skapa ett nytt virtuellt hubbnätverk i den nya målregionen.

4. Om tillämpligt distribuerar du Azure Firewall eller virtuella nätverksinstallationer (NVA) till ditt nya virtuella hubbnätverk.

5. Om tillämpligt distribuerar du virtuella nätverksgatewayer för VPN- eller ExpressRoute-anslutning och upprättar anslutningar. Se till att dina ExpressRoute-kretsar och lokala platser följer Microsofts återhämtningsrekommendationer. Mer information finns i Designa för haveriberedskap med privat ExpressRoute-peering.

6. Upprätta peering för virtuella nätverk mellan det nya virtuella hubbnätverket och de andra virtuella hubbnätverken.

7. Skapa och konfigurera all nödvändig routning, till exempel Azure Route Server eller användardefinierade vägar.

8. Om det behövs distribuerar du DNS-vidarebefordrare för den nya målregionen och länkar till privata DNS-zoner för att aktivera namnmatchning.

   • Vissa kunder kan konfigurera namnmatchning på sina Windows Server Active Directory-domänkontrollanter i prenumerationen för landningszonen Identity Platform.

Som värd för dina arbetsbelastningar kan du sedan använda peering för virtuella nätverk för att ansluta ekrar i programlandningszonen till det nya virtuella hubbnätverket i den nya regionen.

Virtual WAN-arkitektur

1. I ditt befintliga Virtual WAN skapar du en ny virtuell hubb i den nya målregionen.

2. Distribuera Azure Firewall eller andra virtuella nätverksinstallationer som stöds till din nya virtuella hubb. Konfigurera avsikt och routningsprinciper för Virtual WAN för att dirigera trafik genom den nya skyddade virtuella hubben.

3. Om tillämpligt distribuerar du virtuella nätverksgatewayer för VPN- eller ExpressRoute-anslutning i den nya virtuella hubben och upprättar anslutningar. Se till att dina ExpressRoute-kretsar och lokala platser följer Microsofts återhämtningsrekommendationer. Mer information finns i Designa för haveriberedskap med privat ExpressRoute-peering.

4. Skapa och konfigurera andra routningar som du behöver, till exempel statiska vägar för virtuell hubb.

5. Om tillämpligt distribuerar du DNS-vidarebefordrare för den nya målregionen och länkar till eventuella privata DNS-zoner för att aktivera matchning.

   • Vissa kunder kan konfigurera namnmatchning på sina Active Directory-domänkontrollanter i prenumerationen för landningszonen Identity Platform.

   • I Virtual WAN-distributioner måste detta finnas i ett virtuellt ekernätverk som är anslutet till den virtuella hubben via en virtuell nätverksanslutning, enligt mönstret för tillägg för virtuell hubb.

Som värd för dina arbetsbelastningar kan du sedan använda peering för virtuella nätverk för att ansluta ekrar i programlandningszonen till det nya virtuella hubbnätverket i den nya regionen.

Identitet

1. Bestäm om du behöver en ny plattformslandningszonprenumeration. Vi rekommenderar att de flesta kunder använder sin befintliga identitetsprenumeration , även när de använder flera regioner.

2. Skapa en ny resursgrupp i den nya målregionen.

3. Skapa ett nytt virtuellt nätverk i den nya målregionen.

4. Upprätta peering för virtuella nätverk tillbaka till det nyligen skapade virtuella nätverket för regional hubb i Anslut ivity-prenumerationen.

5. Distribuera identitetsarbetsbelastningar, till exempel virtuella Active Directory-domänkontrollantdatorer, till det nya virtuella nätverket.

   • Du kan behöva utföra mer konfiguration av arbetsbelastningarna när de har etablerats, till exempel följande konfigurationssteg:

     • Höj upp de virtuella Active Directory-domänkontrollantdatorerna till den befintliga Active Directory-domänen.

     • Skapa nya Active Directory-platser och undernät.

     • Konfigurera DNS-serverinställningar som villkorsstyrda vidarebefordrare.

Flytta din Azure-egendom till en ny region

Ibland kan du behöva flytta hela din Azure-egendom till en annan region. Anta till exempel att du distribuerade din landningszon och dina arbetsbelastningar till en Azure-region i ett grannland eller en region, och sedan startar en ny Azure-region i ditt hemland eller din region. Du kan välja att flytta alla dina arbetsbelastningar till den nya regionen för att förbättra kommunikationssvarstiden eller för att uppfylla kraven på datahemvist.

Konfiguration av global landningszon

De flesta av de globalt distribuerade konfigurationerna för landningszoner behöver vanligtvis inte ändras när du flyttar regioner. Kontrollera dock att du söker efter principtilldelningar som begränsar regiondistributioner och uppdaterar principen för att tillåta distributioner till den nya regionen.

Resurser för regional landningszon

Regionspecifika landningszonresurser kräver ofta mer hänsyn eftersom du inte kan flytta vissa Azure-resurser mellan regioner. Tänk på följande metod:

1. Lägg till målregionen som ytterligare en region i landningszonen: Mer information finns i Lägga till en ny region i en befintlig landningszon.

2. Distribuera centraliserade komponenter i målregionen: Distribuera till exempel en ny Arbetsyta för Azure Monitor-loggar i målregionen så att arbetsbelastningar kan börja använda den nya komponenten när du har migrerat arbetsbelastningen.

3. Migrera dina arbetsbelastningar från källregionen till målregionen: Under arbetsbelastningsmigreringen konfigurerar du om resurserna så att de använder målregionens nätverkskomponenter, identitetskomponenter, Arbetsytan Azure Monitor-loggar och andra regionala resurser.

4. Inaktivera resurserna i källregionen när du har slutfört migreringen.

Tänk på följande tips när du migrerar landningszonresurser mellan regioner:

• Använd infrastruktur som kod: Använd Bicep, Azure Resource Manager-mallar (ARM-mallar), Terraform, skript eller en liknande metod för att exportera och importera om komplexa konfigurationer, till exempel regler för Azure Firewall.

• Automation: Använda skript för att migrera Automation-resurser mellan regioner.

• ExpressRoute: Överväg om du kan använda den lokala ExpressRoute-SKU:n i målregionen. Om dina lokala miljöer ligger inom samma storstadsområde som din Azure-region kan ExpressRoute Local ge ett billigare alternativ jämfört med andra ExpressRoute-SKU:er.

Gå vidare