Landningszonregioner

Själva azure-landningszonens arkitektur är regionagnostisk. Du uppmanas dock att ange Azure-regioner för att distribuera din Arkitektur för Azure-landningszoner. Den här artikeln beskriver hur landningszoner använder Azure-regioner. Den förklarar också hur du lägger till en region i en befintlig landningszon och några överväganden när du migrerar din Azure-egendom till en annan region.

Mer information om hur du väljer Azure-regioner finns i Välj Azure-regioner.

Så här använder landningszoner 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, så 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:

• Log Analytics-arbetsyta (inklusive valda lösningar)
• 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 Virtual WAN Hub)
• Virtuella Azure-nätverk
• VPN gateway
• ExpressRoute-gateway
• Azure Firewall
• Azure DDoS Protection-planer
• Azure Privat DNS-zoner, inklusive för Azure Private Link
• Resursgrupper som ska innehålla de resurser som anges ovan

Kommentar

För att minimera effekten av regionala avbrott rekommenderar vi att du placerar resurser i samma region som resursgruppen. Mer information finns i Resursgruppsplatsjustering.

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 molnresan eller genom att expandera till fler Azure-regioner när du har slutfört den första distributionen av din Azure-landningszonarkitektur. Om du till exempel aktiverar haveriberedskap för dina virtuella datorer med hjälp av Azure Site Recovery kanske du vill replikera dem till en annan Azure-region. Tänk på följande områden och rekommendationer för att lägga till Azure-regioner i Azure-landningszonens arkitektur:

Ytdiagram	Rekommendation
Hanteringsgrupper	Ingen åtgärd krävs. Hanteringsgrupper är inte knutna till en region och det är inte en bra idé att skapa en hanteringsgruppsstruktur baserat på regioner.
Prenumerationer	Prenumerationer är inte knutna till en region.
Azure Policy	Gör ändringar här om du har tilldelat principer för att neka resursdistribution till alla regioner genom att ange en lista över "tillåtna" Azure-regioner. Dessa tilldelningar måste uppdateras för att tillåta resursdistributioner till den nya region som du vill aktivera.
Rollbaserad åtkomstkontroll	Ingen åtgärd krävs. Azure RBAC är inte kopplat till en region.
Övervakning och loggning	Bestäm om du vill använda en enda Log Analytics-arbetsyta för alla regioner eller skapa flera arbetsytor för att täcka olika geografiska regioner. Det finns fördelar och nackdelar med varje metod, inklusive potentiella nätverksavgifter mellan regioner. Mer information finns i Designa en Log Analytics-arbetsytearkitektur.
Nätverk	Om du har distribuerat en nätverkstopologi, Virtual WAN eller en traditionell hubb och eker expanderar du nätverket till den nya Azure-regionen. Skapa en annan nätverkshubb genom att distribuera nödvändiga nätverksresurser till den befintliga Anslut ivity-prenumerationen i den nya Azure-regionen. Azure Virtual Network Manager kan göra det enklare att expandera och hantera virtuella nätverk i stor skala i flera regioner. Ur ett DNS-perspektiv kanske du också vill distribuera vidarebefordrare, om de används, till den nya Azure-regionen. Använd vidarebefordrare för virtuella ekernätverk i den nya regionen för lösning. Azure DNS-zoner är globala resurser och inte knutna till en enda Azure-region, så inget behöver göras åt dem.
Identitet	Om du har distribuerat Active Directory-domän Services eller Microsoft Entra Domain Services till din identitetsprenumeration/-eker expanderar du tjänsten till den nya Azure-regionen.

Kommentar

Du bör också använda tillgänglighetszoner för hög tillgänglighet i en region. Kontrollera om tillgänglighetszoner stöds i dina valda regioner och för de tjänster som du vill använda.

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 hubb- och ekerarkitektur

Dricks

Granska designområdet för Azure-landningszonen för traditionell hubb- och ekerarkitektur.

1. Bestäm om en ny plattformslandningszonprenumeration behövs. 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- och/eller ExpressRoute-anslutningar 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 aktiverar du namnmatchning genom att distribuera DNS-vidarebefordrare för den nya målregionen och länka till privata DNS-zoner.
   • Vissa kunder kan konfigurera namnmatchning på sina Active Directory-domänkontrollanter i prenumerationen för landningszonen Identity Platform.

Som värd för dina arbetsbelastningar kan du sedan ansluta programlandningszonens ekrar till det nya virtuella hubbnätverket i den nya regionen med hjälp av peering för virtuella nätverk.

Dricks

Azure Virtual Network Manager kan göra det enklare att expandera och hantera virtuella nätverk i stor skala i flera regioner.

Virtual WAN-arkitektur

Dricks

Granska designområdet för Azure-landningszonen för Virtual WAN-arkitektur.

1. I ditt befintliga virtuella 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 Azure Virtual WAN-routnings- och routningsprinciper för att dirigera trafik via den nya skyddade virtuella hubben.
3. Om tillämpligt distribuerar du virtuella nätverksgatewayer för VPN- och/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. Om tillämpligt skapar och konfigurerar du andra routning 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 anslutning till ett virtuellt nätverk, enligt tilläggsmönstret för virtuell hubb.

Som värd för dina arbetsbelastningar kan du sedan ansluta programlandningszonens ekrar till det virtuella WAN:s nya virtuella hubb i den nya regionen med hjälp av virtuella nätverksanslutningar.

Identitet

Dricks

Granska designområdet för Azure-landningszonen för identitets- och åtkomsthantering.

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/en angränsande region och sedan startar en ny Azure-region i ditt hemland/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.

Kommentar

Det här dokumentet innehåller endast information om hur du migrerar komponenterna i din egendom i landningszonen. Mer information om hur du flyttar dina arbetsbelastningskomponenter finns i Flytta molnarbetsbelastningar.

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 vissa Azure-resurser inte kan flyttas mellan regioner. Tänk på följande metod:

1. Lägg till målregionen som ytterligare en region i landningszonen. Följ riktlinjerna i Lägg till en ny region i en befintlig landningszon.
2. Distribuera centraliserade komponenter i målregionen. Distribuera till exempel en ny Log Analytics-arbetsyta i målregionen så att arbetsbelastningar kan börja använda den nya komponenten när de migreras.
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, Log Analytics-arbetsyta och andra regionala resurser.
4. Inaktivera resurserna i källregionen när migreringen är klar.

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

• Använd infrastruktur som kod: Komplex konfiguration, till exempel regler för Azure Firewall, kan exporteras och importeras igen med hjälp av Bicep, ARM-mallar, Terraform, skript eller en liknande metod.
• Azure Automation: Azure Automation ger vägledning och skript för att hjälpa till med migrering mellan regioner av Azure Automation-resurser.
• ExpressRoute: Överväg om du kan använda ExpressRoute Local i målregionen. Om dina lokala miljöer ligger inom samma storstadsområde som din Azure-region kan ExpressRoute Local ge ett billigare alternativ än andra ExpressRoute-SKU:er.

Nästa steg

Förbättra styrningen av landningszoner