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
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 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:
| Ytdiagram | Rekommendation |
|---|---|
| Hanteringsgrupper | Ingen åtgärd krävs. Hanteringsgrupper är inte knutna till en region. Du bör inte skapa en hanteringsgruppsstruktur baserat på regioner. |
| Prenumerationer | Prenumerationer är inte knutna till en region. |
| Azure Policy | Gör ändringar i Azure Policy om du har tilldelat principer för att neka resursdistribution till alla regioner genom att ange en lista över "tillåtna" Azure-regioner. Uppdatera dessa tilldelningar för att tillåta resursdistributioner till den nya region som du vill aktivera. |
| Rollbaserad åtkomstkontroll (RBAC) | 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 Arbetsyta för Azure Monitor-loggar för alla regioner eller om du vill skapa flera arbetsytor som täcker olika geografiska regioner. Varje metod har fördelar och nackdelar, inklusive potentiella nätverksavgifter mellan regioner. Mer information finns i Designa en Log Analytics-arbetsytearkitektur. |
| Nätverk | Om du distribuerar 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 anslutningsprenumerationen 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. Från ett DNS-perspektiv (Domain Name System) kanske du också vill distribuera vidarebefordrare, om du använder dem, 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 är inte knutna till en enda Azure-region, så de kräver ingen åtgärd. |
| Identitet | Om du har distribuerat Active Directory-domän Services eller Microsoft Entra Domain Services till din identitetsprenumeration eller 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 dina Azure-regioner stöder tillgänglighetszoner och hur de tjänster du använder stöder tillgänglighetszoner.
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
Dricks
Bestäm om du behöver en ny plattformslandningszonprenumeration. Vi rekommenderar att de flesta kunder använder sina befintliga anslutningsprenumerationer , även när de använder flera regioner.
I prenumerationen skapar du en ny resursgrupp i den nya målregionen.
Skapa ett nytt virtuellt hubbnätverk i den nya målregionen.
Om tillämpligt distribuerar du Azure Firewall eller virtuella nätverksinstallationer (NVA) till ditt nya virtuella hubbnätverk.
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.
Upprätta peering för virtuella nätverk mellan det nya virtuella hubbnätverket och de andra virtuella hubbnätverken.
Skapa och konfigurera all nödvändig routning, till exempel Azure Route Server eller användardefinierade vägar.
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.
Dricks
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
Se en Virtual WAN-arkitektur.
I ditt befintliga Virtual WAN skapar du en ny virtuell hubb i den nya målregionen.
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.
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.
Skapa och konfigurera andra routningar som du behöver, till exempel statiska vägar för virtuell hubb.
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
Dricks
Granska designområdet för Azure-landningszonen för identitets- och åtkomsthantering.
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.
Skapa en ny resursgrupp i den nya målregionen.
Skapa ett nytt virtuellt nätverk i den nya målregionen.
Upprätta peering för virtuella nätverk tillbaka till det nyligen skapade virtuella nätverket för den regionala hubben i anslutningsprenumerationen.
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.
Kommentar
Den här artikeln innehåller information om hur du migrerar komponenterna i din egendom i landningszonen. Mer information 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 du inte kan flytta vissa Azure-resurser mellan regioner. Tänk på följande metod:
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.
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.
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.
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.