Välj Azure-regioner för migrering

Artikel
04/11/2024

När du migrerar en befintlig miljö till Azure måste du välja en Azure-region eller uppsättning regioner som värd för de migrerade komponenterna. Regionval omfattar följande övergripande steg:

Läs den grundläggande vägledningen för val av Azure-region för att förstå hur du väljer Azure-regioner som uppfyller dina krav.
Inventera och dokumentera miljöns aktuella tillstånd .
Implementera en allmän metod för migreringen, inklusive om du vill köra i en enda region, använda flera tillgänglighetszoner eller använda flera regioner.
Utvärdera processändringar som kan krävas.
Planera en migreringsprocess.
Optimera och främja processändringar.

Den här artikeln innehåller vägledning om hur du väljer Azure-regioner som uppfyller dina migreringsbehov. Om du inte redan har gjort det kan du behöva utöka dina landningszonregioner för att stödja metoder för flera regioner.

Kommentar

Den här artikeln beskriver överväganden som är specifika för migreringar av arbetsbelastningar. Du bör också förstå allmänna principer för att välja Azure-regioner för valfri organisation eller arbetsbelastning. Mer information finns i Välj Azure-regioner.

Dokumentera scenariokomplexiteten

Avgör om ditt scenario kräver dokumentation och processjustering. Följande metod kan hjälpa dig att bedöma potentiella utmaningar och upprätta ett allmänt tillvägagångssätt:

Överväg en mer robust beredskap och styrningsimplementering.
Inventera de berörda geografiska områden. Kompilera en lista över de berörda länderna eller regionerna.
Dokumentera användarbasen. Kommer molnmigreringen att påverka anställda, partner eller kunder i det identifierade landet eller regionen?
Dokumentera datacenter och tillgångar. Omfattar migreringsarbetet några tillgångar i det identifierade landet eller regionen?
Dokumentera tillgänglighets- och redundanskraven för regional produktversion.
Dokumentera dina återhämtningskrav för att avgöra om tillgänglighetszoner krävs. Vanligtvis överväger du återhämtningskrav för hela scenariot, inte för enskilda regioner.
Dokumentera dina suveränitetskrav och krav på datahemvist. Arbetsbelastningar som har specifika krav på suveränitet eller datahemvist kan påverka ditt val av Azure-regioner.

Under hela migreringsprocessen bör du överväga hur du justerar ändringar i dina olika scenarier och inventeringar. I följande tabell visas ett exempel på hur du dokumenterar olika scenarier.

Region	Land/region	Lokala anställda	Lokala externa användare	Lokala datacenter eller tillgångar	Krav på datasuveränitet
Nordamerika	USA	Ja	Partners och kunder	Ja	Nej
Nordamerika	Kanada	Nej	Kunder	Ja	Ja
Europa	Tyskland	Ja	Partners och kunder	Nej – endast nätverk	Ja
Asien och stillahavsområdet	Sydkorea	Ja	Partner	Ja	Nej

Varför är användarnas plats relevant?

Organisationer som stöder användare i flera länder eller regioner utvecklar tekniska lösningar som hanterar användartrafik. I vissa fall omfattar lösningar lokalisering av tillgångar. I andra scenarier kan organisationen välja att implementera WAN-lösningar (Global Wide Area Network) för att hantera olika användarbaser via nätverksfokuserade lösningar. I båda fallen kan användningsprofilerna för olika användare påverka migreringsstrategin.

Om en organisation till exempel stöder anställda, partners och kunder i Tyskland, men för närvarande inte har datacenter i Tyskland, implementerar organisationen förmodligen en hyrd lösning. Den här typen av lösning dirigerar trafik till datacenter i andra länder eller regioner. Denna omdirigering utgör en betydande risk för den upplevda prestandan hos migrerade program. Genom att mata in fler hopp i ett etablerat och finjusterat globalt WAN kan du skapa en uppfattning om underpresterande program efter migreringen. Att hitta och korrigera dessa problem kan avsevärt försena ett projekt.

Vart och ett av följande avsnitt innehåller vägledning för att hantera den här komplexiteten mellan förutsättningar och processer för att utvärdera, migrera och optimera. Det är viktigt att förstå användarprofiler i varje land eller region för att hantera den här komplexiteten korrekt.

Varför har datacentrens placering betydelse?

Placeringen av befintliga datacenter kan påverka migreringsstrategin. Överväg följande faktorer:

Arkitekturbeslut: Ett av de första stegen i utformningen av migreringsstrategin är att fastställa målregionen. Placeringen av befintliga tillgångar påverkar ofta denna bestämning. Dessutom kan tillgängligheten för molntjänster och enhetskostnaden för dessa tjänster variera mellan regioner. Krav på datahemvist, inklusive suveränitetskrav, kan också påverka arkitekturbeslutet. Att förstå var aktuella och framtida tillgångar finns påverkar arkitekturbeslut och kan påverka budgetuppskattningar.

Datacenterberoenden: I tabellen i avsnittet Dokumentera scenariokomplexitet visar exempelscenarierna att du förmodligen behöver planera för beroenden mellan olika globala datacenter. Organisationer som arbetar på den här skalan kanske inte dokumenterar eller tydligt förstår dessa beroenden. Organisationens metod för att utvärdera användarprofiler hjälper dig att identifiera några av dessa beroenden i din organisation. Ditt team bör också utforska fler utvärderingssteg som kan bidra till att minska de risker och komplexiteter som beror på beroenden.

Implementera en allmän metod

Följande metod använder en datadriven modell för att hantera globala migreringskomplexiteter. Om migreringsomfånget omfattar flera regioner bör molnimplementeringsteamet utvärdera följande beredskapsöverväganden:

Avgör om du kan uppfylla dina affärskrav: Använd flera tillgänglighetszoner för att fastställa krav för hög tillgänglighet, återhämtning, prestanda och kostnad. Om dessa krav inte uppfylls bör du överväga om du behöver en metod för flera regioner.
Utvärdera datasuveränitet: Datasuveränitet kan kräva lokalisering av vissa tillgångar, men många tillgångar styrs inte av dessa efterlevnadsbegränsningar. Tjänster som loggning, rapportering, nätverksroutning, identitet och andra centrala IT-tjänster kan vara berättigade att hanteras som delade tjänster i flera prenumerationer eller regioner. Utvärdera datasuveränitet med hjälp av en delad tjänstmodell för dessa tjänster. En översikt över den här metoden finns i referensarkitekturen för en hub-spoke-topologi med delade tjänster.
Se till att din miljö skalas: Om du distribuerar flera instanser av liknande miljöer kan du upprätta ett dedikerat team för miljöns migreringar för att skapa konsekvens, förbättra styrningen och påskynda distributionen. Styrningsguiden för komplexa företag fastställer en metod som skapar en miljö som skalar över flera regioner.

Datadrivna förutsättningar

När ditt team är bekvämt med baslinjemetoden och beredskapen är anpassad bör du tänka på följande datadrivna förutsättningar:

Fullständig allmän identifiering: Slutför tabellen i Dokumentkomplexitet för att utvärdera komplexiteten i din molnimplementeringsstrategi.
Analysera användarprofiler för varje berört land eller region: Det är viktigt att förstå allmän användarroutning tidigt i migreringsprocessen. Om du ändrar globala lånelinjer och lägger till anslutningar som Azure ExpressRoute till ett molndatacenter kan det leda till månader av nätverksfördröjningar. Hantera användarroutning så tidigt som möjligt i processen.
Slutför en inledande rationalisering av digital egendom: Om du introducerar komplexitet i en migreringsstrategi slutför du en inledande rationalisering av digital egendom. Mer information finns i Vad är en digital egendom?.
Använd taggning för krav på digital egendom: Upprätta taggningsprinciper för att identifiera alla arbetsbelastningar som påverkas av kraven på datasuveränitet. Se till att nödvändiga taggar börjar med rationalisering av digital egendom och fortsätt till migrerade tillgångar.
Utvärdera en hub-spoke-modell: Distribuerade system delar ofta gemensamma beroenden. Du kan ofta hantera delade beroenden genom att implementera en hub-spoke-modell. Även om implementeringen av en hub-spoke-modell ligger utanför omfånget för migreringsprocessen flaggar du modellen för övervägande under framtida iterationer av de färdiga processerna.
Prioritera kvarvarande migreringsuppgifter: Om du behöver nätverksändringar för att stödja produktionsdistribution av en arbetsbelastning som stöder flera regioner bör molnstrategiteamet spåra och hantera eskaleringar som beror på nätverksändringarna. Den här högre nivån av chefsstöd hjälper till att påskynda ändringen genom att frigöra strategiteamet att omprioritera kvarvarande uppgifter och se till att nätverksändringar inte blockerar globala arbetsbelastningar. Prioritera endast globala arbetsbelastningar när nätverksändringarna har slutförts.

Dessa förutsättningar hjälper till att upprätta processer som kan hantera komplexiteten under genomförandet av migreringsstrategin.

Utvärdera processändringar

Om ditt migreringsscenario omfattar globala tillgångar och användarbaskomplexiteter lägger du till viktiga aktiviteter för att utvärdera dina migreringskandidater. Dessa aktiviteter skapar data som hjälper dig att klargöra hinder och resultat för globala användare och tillgångar.

Föreslagna åtgärder under utvärderingsprocessen

Utvärdera beroenden mellan datacenter: Verktygen för beroendeanalys i Azure Migrate kan hjälpa dig att hitta beroenden. Använd dessa verktyg innan du påbörjar migreringen. Om ditt scenario omfattar global komplexitet är utvärdering av beroenden ett nödvändigt steg i utvärderingsprocessen. Du kan använda beroendegruppering för att visualisera beroenden och identifiera IP-adresser och portar för alla tillgångar som krävs för att stödja arbetsbelastningen.

Viktigt!

Du behöver en ämnesexpert (SME) som förstår tillgångsplacering och IP-adressscheman för att identifiera tillgångar som finns i ett sekundärt datacenter.
Utvärdera underordnade beroenden och klienter i visualiseringen för att förstå dubbelriktade beroenden.

Identifiera global användarpåverkan: Utdata från den nödvändiga användarprofilanalysen bör identifiera alla arbetsbelastningar som påverkas av globala användarprofiler. Om en migreringskandidat finns med i listan över berörda arbetsbelastningar bör migreringsarkitekten konsultera nätverk och drifts-små och medelstora företag. Dessa experter hjälper till att verifiera nätverksroutning och prestandaförväntningar. Arkitekturen bör minst innehålla en ExpressRoute-anslutning mellan närmaste nätverksdriftscenter och Azure. Referensarkitekturen för ExpressRoute-anslutningar kan hjälpa dig att konfigurera nödvändiga nätverksanslutningar.

Design för efterlevnad: Utdata från den nödvändiga användarprofilanalysen bör också identifiera alla arbetsbelastningar som påverkas av kraven på datasuveränitet. Under utvärderingsprocessens arkitekturverksamhet bör den tilldelade arkitekten samråda med små och medelstora företag för efterlevnad. Dessa experter kan hjälpa arkitekten att förstå alla krav för migrering och distribution i flera regioner. Dessa krav påverkar designstrategierna avsevärt. Följande referensarkitekturer kan hjälpa dig med designen:

Varning

Om du använder referensarkitekturen för ExpressRoute eller referensarkitekturerna för program kan du behöva undanta specifika dataelement från replikeringsprocesser för att uppfylla kraven på datasuveränitet. Uppgiften att exkludering av specifika dataelement lägger till ett steg i befordransprocessen.

Ändringar i migreringsprocessen

Om du migrerar ett program som måste distribueras till flera regioner måste molnimplementeringsteamet ta hänsyn till några fler överväganden. Designen av Azure Site Recovery-valv och konfigurations- och processservrar är två av dessa överväganden. Två andra överväganden är design av nätverksbandbredd och datasynkronisering.

Föreslagna åtgärder under migreringsprocessen

Design av Site Recovery-valv: Site Recovery är det föreslagna verktyget för molnbaserad replikering och synkronisering av digitala tillgångar till Azure. Site Recovery replikerar data om varje tillgång till ett Site Recovery-valv. Det här valvet är bundet till en specifik prenumeration i en specifik region och Ett Azure-datacenter. Om du replikerar tillgångar till en andra region kan du också behöva ett andra Site Recovery-valv.

Konfiguration och processserverdesign: Site Recovery fungerar med en lokal instans av en konfigurations- och processserver som är bunden till ett enda Site Recovery-valv. När du använder den här konfigurationen kan du behöva installera andra instanser av dessa servrar i källcentret för att underlätta replikeringen.

Design av nätverksbandbredd: Under replikering och pågående synkronisering flyttar du binära data över nätverket från källdatacentret till Site Recovery-valvet i azure-målcentret. Replikerings- och synkroniseringsprocessen förbrukar bandbredd. Duplicering av arbetsbelastningen till en andra region fördubblar mängden förbrukad bandbredd.

I vissa scenarier är bandbredden begränsad. I andra fall innebär en arbetsbelastning betydande konfiguration eller dataavvikelse. I dessa fall kan replikering av data till en andra region störa den tid det tar att slutföra migreringen. Ännu viktigare är att dessa begränsningar kan påverka upplevelsen för användare eller program som fortfarande är beroende av den bandbredd som var tillgänglig i källcentret.

Datasynkronisering: Den största bandbreddsavrinningen kommer ofta från synkronisering av dataplattformen. Om du distribuerar över flera tillgänglighetszoner kanske du kan använda zonredundanta datatjänster som automatiskt synkroniserar dina data mellan flera tillgänglighetszoner. Distribution över flera regioner kräver ofta datasynkronisering för att hålla programmen justerade. Den här metoden definieras i referensarkitekturerna för webbprogram i flera regioner och n-nivåprogram i flera regioner.

Om du vill synkronisera program är det drifttillstånd du vill använda för dina program kanske du vill synkronisera källdataplattformen med varje molnplattform. Utför den här synkroniseringen innan du migrerar programmet och tillgångar på mellannivå.

Haveriberedskap för Azure-till-Azure: Ett alternativt alternativ kan ytterligare minska komplexiteten. Om du använder en tvåstegsdistribution för att uppfylla tidslinje- och datasynkroniseringsbehoven kan azure-till-Azure-haveriberedskap vara en acceptabel lösning. I det här scenariot migrerar du arbetsbelastningen till det första Azure-datacentret med hjälp av ett enda Site Recovery-valv och konfiguration och processserverdesign. När du har testat arbetsbelastningen kan du återställa arbetsbelastningen till ett andra Azure-datacenter från de migrerade tillgångarna.

Den här metoden minskar effekten på resurser i källdatacentret. Haveriberedskap i Azure till Azure drar också nytta av snabba överföringshastigheter och höga bandbreddsgränser mellan Azure-datacenter.

Kommentar

Haveriberedskapsmetoden för Azure-till-Azure kan öka kostnaderna för kortsiktig migrering genom högre avgifter för utgående bandbredd.

Ändringar i versionsprocessen

När du hanterar global komplexitet under optimering och befordran kan du kräva identiska insatser i varje region som du distribuerar till. Om du använder en enda region kan du fortfarande behöva replikera affärstestnings- och affärsändringsplaner.

Föreslagna åtgärder under lanseringsprocessen

Förtestoptimering: Inledande automatiseringstestning kan identifiera potentiella optimeringsmöjligheter, som med alla migreringsinsatser. För globala arbetsbelastningar ska du oberoende testa arbetsbelastningen i varje region. Mindre konfigurationsändringar i nätverket eller i det valda Azure-datacentret kan påverka prestandan.

Affärsändringsplaner: Skapa en affärsändringsplan för alla komplexa migreringsscenarion. En affärsändringsplan hjälper till att säkerställa tydlig kommunikation om ändringar i affärsprocesser och användarupplevelser. Planen hjälper också till att säkerställa tydlig kommunikation om tidpunkten för de ansträngningar som krävs för att integrera ändringar. I en global migreringsinsats bör planen innehålla överväganden för användare i varje berört geografiskt område.

Affärstestning: Varje region kan också kräva affärstestning. Företagstestning hjälper till att säkerställa tillräcklig prestanda och efterlevnad av ändrade nätverksroutningsmönster.

Befordran: Befordran sker ofta som en enda aktivitet och produktionstrafiken omdirigeras omedelbart till de migrerade arbetsbelastningarna. I ett globalt lanseringsarbete bör du leverera befordran i fördefinierade samlingar av användare som kallas flyg. Upphöjningsflygningar ger molnstrategiteamet och molnimplementeringsteamet en möjlighet att observera prestanda och förbättra stödet för användare i varje region. Du kan styra befordran på nätverksnivå. Mer specifikt kan du ändra routningen av specifika IP-intervall från källarbetsbelastningstillgångarna till de nyligen migrerade tillgångarna. När du har migrerat en angiven samling användare kan du omdirigera nästa grupp igen.

Flygoptimering: En fördel med uppflyttningsflygningar är att de ger dig djupare observationer och en möjlighet att optimera de distribuerade tillgångarna. När den första flygningen använder produktion under en kort tid kan du förfina de migrerade tillgångarna när IT-åtgärdsprocedurerna stöder den.

Dela via