Azure-regio's selecteren voor een migratie

Wanneer u een bestaande omgeving naar Azure migreert, moet u een Azure-regio of een set regio's selecteren om de gemigreerde onderdelen te hosten. Regioselectie omvat de volgende stappen op hoog niveau:

• Bekijk de belangrijkste richtlijnen voor het selecteren van Azure-regio's om te begrijpen hoe u Azure-regio's selecteert die voldoen aan uw vereisten.
• Inventaris en documenteer de huidige status van uw omgeving.
• Implementeer een algemene benadering van uw migratie, waaronder of u in één regio wilt uitvoeren, meerdere beschikbaarheidszones wilt gebruiken of meerdere regio's wilt gebruiken.
• Proceswijzigingen evalueren die mogelijk vereist zijn.
• Plan een migratieproces.
• Proceswijzigingen optimaliseren en promoten.

Dit artikel bevat richtlijnen voor het kiezen van Azure-regio's die voldoen aan uw migratiebehoeften. Als u dat nog niet hebt gedaan, moet u mogelijk uw landingszoneregio's uitbreiden ter ondersteuning van benaderingen voor meerdere regio's .

Notitie

In dit artikel worden overwegingen behandeld die specifiek zijn voor workloadmigraties. U moet ook algemene principes begrijpen voor het selecteren van Azure-regio's voor elke organisatie of workload. Zie Azure-regio's selecteren voor meer informatie.

Documenteer de complexiteit van uw scenario

Bepaal of voor uw scenario documentatie en procesuitlijning is vereist. De volgende aanpak kan u helpen bij het beoordelen van potentiële uitdagingen en het vaststellen van een algemene actie:

• Overweeg een krachtigere gereedheid en governance-implementatie.
• Inventariseer de betrokken geografische gebieden. Compileer een lijst met de betrokken landen of regio's.
• Documenteer de gebruikersbasis. Heeft de cloudmigratie invloed op werknemers, partners of klanten in het geïdentificeerde land of de geïdentificeerde regio?
• Documenteer datacenters en assets. Bevat de migratie-inspanning assets in het geïdentificeerde land of de geïdentificeerde regio?
• Documenteer de beschikbaarheid van regionale productversies en failoververeisten.
• Documenteer uw tolerantievereisten om te bepalen of beschikbaarheidszones vereist zijn. Doorgaans overweegt u tolerantievereisten voor het hele scenario, niet voor afzonderlijke regio's.
• Documenteer uw soevereiniteitsvereisten en vereisten voor gegevenslocatie. Workloads met specifieke vereisten voor soevereiniteit of gegevenslocatie kunnen van invloed zijn op uw keuze van Azure-regio's.

Overweeg tijdens het migratieproces hoe u wijzigingen in uw verschillende scenario's en inventarissen kunt uitlijnen. In de volgende tabel ziet u een voorbeeld van het documenteren van verschillende scenario's.

Regio	Land/regio	Lokale werknemers	Lokale externe gebruikers	Lokale datacenters of assets	Vereisten voor gegevenssoevereine
Noord-Amerika	Verenigde Staten	Ja	Partners en klanten	Ja	Nr.
Noord-Amerika	Canada	Nee	Klanten	Ja	Ja
Europa	Duitsland	Ja	Partners en klanten	Nee - alleen netwerk	Ja
Azië-Pacific	Zuid-Korea	Ja	Partners	Ja	Nr.

Waarom is de locatie van gebruikers relevant?

Organisaties die gebruikers in meerdere landen of regio's ondersteunen, ontwikkelen technische oplossingen die betrekking hebben op gebruikersverkeer. In sommige gevallen hebben oplossingen betrekking op lokalisatie van assets. In andere scenario's kan de organisatie ervoor kiezen om WAN-oplossingen (Global Wide Area Network) te implementeren om verschillende gebruikersbasissen te verhelpen via netwerkgerichte oplossingen. In beide gevallen kunnen de gebruiksprofielen van verschillende gebruikers van invloed zijn op de migratiestrategie.

Als een organisatie bijvoorbeeld werknemers, partners en klanten in Duitsland ondersteunt, maar momenteel geen datacenters in Duitsland heeft, implementeert de organisatie waarschijnlijk een leaseoplossing . Dit type oplossing routeert verkeer naar datacenters in andere landen of regio's. Deze bestaande routering vormt een aanzienlijk risico op de waargenomen prestaties van gemigreerde toepassingen. Het injecteren van meer hops in een gevestigde en afgestemde wereldwijde WAN kan de perceptie creëren van onderbewerkende toepassingen na de migratie. Het opsporen en oplossen van deze problemen, kan voor extra grote vertragingen van een project zorgen.

Elk van de volgende secties bevat richtlijnen voor het aanpakken van deze complexiteit voor vereisten en processen voor het beoordelen, migreren en optimaliseren van deze complexiteit. Inzicht in gebruikersprofielen in elk land of elke regio is essentieel voor het goed beheren van deze complexiteit.

Waarom is de locatie van datacenters relevant?

De locatie van bestaande datacenters kan van invloed zijn op een migratiestrategie. Houd rekening met de volgende factoren:

Architectuurbeslissingen: een van de eerste stappen in het migratiestrategieontwerp is het bepalen van de doelregio. De locatie van bestaande activa is vaak van invloed op deze bepaling. Bovendien kunnen de beschikbaarheid van cloudservices en de eenheidskosten van deze services per regio verschillen. Vereisten voor gegevenslocatie, inclusief soevereiniteitsvereisten, kunnen ook van invloed zijn op de architectuurbeslissing. Inzicht in waar huidige en toekomstige assets zich bevinden, is van invloed op architectuurbeslissingen en kan invloed hebben op budgetramingen.

Datacenterafhankelijkheden: In de tabel in de sectie Uw scenariocomplexiteit documenteren, laten de voorbeeldscenario's zien dat u waarschijnlijk afhankelijkheden tussen verschillende wereldwijde datacenters moet plannen. Organisaties die op deze schaal werken, kunnen deze afhankelijkheden mogelijk niet documenteren of duidelijk begrijpen. De benadering van uw organisatie voor het evalueren van gebruikersprofielen helpt u bij het identificeren van een aantal van deze afhankelijkheden in uw organisatie. Uw team moet ook meer evaluatiestappen verkennen waarmee u de risico's en complexiteit van afhankelijkheden kunt beperken.

Een algemene benadering implementeren

De volgende benadering maakt gebruik van een gegevensgestuurd model om complexe migraties van de wereld aan te pakken. Als het migratiebereik meerdere regio's omvat, moet het cloudacceptatieteam de volgende overwegingen voor gereedheid evalueren:

• Bepaal of u aan uw bedrijfsvereisten kunt voldoen: gebruik meerdere beschikbaarheidszones om vereisten te bepalen voor hoge beschikbaarheid, tolerantie, prestaties en kosten. Als niet aan deze vereisten wordt voldaan, kunt u overwegen of u een benadering voor meerdere regio's nodig hebt.

• Gegevenssoevereine evalueren: gegevenssoevereine kan lokalisatie van sommige assets vereisen, maar veel assets vallen niet onder deze nalevingsbeperkingen. Services zoals logboekregistratie, rapportage, netwerkroutering, identiteit en andere centrale IT-services komen mogelijk in aanmerking voor het hosten als gedeelde services voor meerdere abonnementen of regio's. Evalueer gegevenssoevereine met behulp van een gedeeld servicemodel voor deze services. Zie de referentiearchitectuur voor een stertopologie met gedeelde services voor een overzicht van deze benadering.

• Zorg ervoor dat uw omgeving wordt geschaald: als u meerdere exemplaren van vergelijkbare omgevingen implementeert, kunt u een speciaal team opzetten voor de migraties van de omgeving om consistentie te creëren, governance te verbeteren en de implementatie te versnellen. De governancehandleiding voor complexe ondernemingen biedt een benadering waarbinnen een omgeving wordt gemaakt waarmee de schaal in meerdere regio's kan worden toegepast.

Vereisten op basis van gegevens

Wanneer uw team vertrouwd is met de basislijnbenadering en gereedheid is afgestemd, moet u rekening houden met deze gegevensgestuurde vereisten:

• Voltooi algemene detectie: voltooi de tabel in Documentcomplexiteit om de complexiteit van uw strategie voor cloudimplementatie te evalueren.

• Gebruikersprofielen analyseren voor elk betrokken land of elke betrokken regio: het is belangrijk om algemene gebruikersroutering vroeg in het migratieproces te begrijpen. Als u globale leaselijnen wijzigt en verbindingen zoals Azure ExpressRoute toevoegt aan een clouddatacenter, kan dit leiden tot maanden aan netwerkvertragingen. Adressering van gebruikers zo vroeg mogelijk in het proces.

• Voltooi een eerste rationalisering van digitale activa: als u complexiteit in een migratiestrategie introduceert, voltooit u een eerste rationalisering van digitale activa. Zie Wat is een digitaal onroerend goed? voor meer informatie.

• Gebruik taggen voor vereisten voor digitale activa: stel tagbeleid in om elke workload te identificeren die wordt beïnvloed door vereisten voor gegevenssoevereine. Zorg ervoor dat de vereiste tags beginnen met rationalisering van digitale activa en doorvoeren naar gemigreerde assets.

• Een hub-spoke-model evalueren: gedistribueerde systemen delen vaak algemene afhankelijkheden. U kunt vaak gedeelde afhankelijkheden aanpakken door een hub-spoke-model te implementeren. Hoewel het implementeren van een hub-spoke-model buiten het bereik van het migratieproces valt, markeert u het model voor overweging tijdens toekomstige iteraties van de gereede processen.

• Prioriteit geven aan de migratieachterstand: als u netwerkwijzigingen nodig hebt om de productie-implementatie van een workload te ondersteunen die ondersteuning biedt voor meerdere regio's, moet het cloudstrategieteam escalaties bijhouden en beheren die het gevolg zijn van de netwerkwijzigingen. Dit hogere ondersteuningsniveau helpt de wijziging te versnellen door het strategieteam te bevrijden om de achterstand te herpriritiseren en ervoor te zorgen dat netwerkwijzigingen globale workloads niet blokkeren. Pas prioriteit geven aan globale workloads wanneer netwerkwijzigingen zijn voltooid.

Deze vereisten helpen bij het vaststellen van processen die de complexiteit kunnen aanpakken tijdens de uitvoering van de migratiestrategie.

Proceswijzigingen evalueren

Als uw migratiescenario globale asset- en gebruikersbasiscomplexiteiten omvat, voegt u belangrijke activiteiten toe om uw migratiekandidaten te beoordelen. Deze activiteiten produceren gegevens om obstakels en resultaten voor globale gebruikers en assets te verduidelijken.

Voorgestelde acties tijdens het evaluatieproces

Afhankelijkheden tussen datacenters evalueren: de hulpprogramma's voor afhankelijkheidsanalyse in Azure Migrate kunnen u helpen afhankelijkheden vast te stellen. Gebruik deze hulpprogramma's voordat u met de migratie begint. Als uw scenario globale complexiteit omvat, is het evalueren van afhankelijkheden een noodzakelijke stap in het evaluatieproces. U kunt afhankelijkheidsgroepering gebruiken om afhankelijkheden te visualiseren en de IP-adressen en poorten te identificeren van alle assets die nodig zijn om de workload te ondersteunen.

Belangrijk

• U hebt een deskundige (SME) nodig die inzicht heeft in de plaatsing van activa en IP-adresschema's om assets te identificeren die zich in een secundair datacenter bevinden.
• Evalueer downstreamafhankelijkheden en clients in de visualisatie om inzicht te hebben in bidirectionele afhankelijkheden.

Globale gebruikersimpact identificeren: de uitvoer van de vereiste analyse van gebruikersprofielen moet elke workload identificeren die wordt beïnvloed door globale gebruikersprofielen. Als een migratiekandidaat in de lijst met betrokken workloads staat, moet de migratiearchitect het netwerk- en operationele MKB raadplegen. Deze experts helpen bij het valideren van netwerkrouterings- en prestatie verwachtingen. De architectuur moet minimaal een ExpressRoute-verbinding bevatten tussen het dichtstbijzijnde netwerkbewerkingscentrum en Azure. De referentiearchitectuur voor ExpressRoute-verbindingen kan u helpen bij het configureren van de benodigde netwerkverbindingen.

Ontwerp voor naleving: de uitvoer van de vereiste gebruikersprofielanalyse moet ook elke workload identificeren die wordt beïnvloed door vereisten voor gegevenssoevereiniteit. Tijdens de architectuuractiviteiten van het beoordelingsproces moet de toegewezen architect de nalevings-KMO's raadplegen. Deze experts kunnen de architect helpen alle vereisten voor migratie en implementatie in meerdere regio's te begrijpen. Deze vereisten zijn van invloed op ontwerpstrategieën. De volgende referentiearchitecturen kunnen u helpen bij het ontwerp:

• Zone-redundante webtoepassingen
• Webtoepassingen voor meerdere regio's
• Toepassingen met meerdere regio's n lagen
• Workloadsjablonen voor een onafhankelijke landingszone

Waarschuwing

Als u de referentiearchitectuur voor ExpressRoute of de referentiearchitecturen voor toepassingen gebruikt, moet u mogelijk specifieke gegevenselementen uitsluiten van replicatieprocessen om te voldoen aan vereisten voor gegevenssoevereine. De taak om specifieke gegevenselementen uit te sluiten, voegt een stap toe aan het promotieproces.

Wijzigingen in migratieproces

Als u een toepassing migreert die in meerdere regio's moet worden geïmplementeerd, moet het cloudacceptatieteam rekening houden met nog enkele overwegingen. Het ontwerp van Azure Site Recovery-kluizen en configuratie- en processervers zijn twee van deze overwegingen. Twee andere overwegingen zijn ontwerpen voor netwerkbandbreedte en gegevenssynchronisatie.

Voorgestelde acties tijdens het migratieproces

Site Recovery-kluisontwerp: Site Recovery is het voorgestelde hulpprogramma voor cloudeigen replicatie en synchronisatie van digitale assets naar Azure. Site Recovery repliceert gegevens over elke asset naar een Site Recovery-kluis. Deze kluis is gebonden aan een specifiek abonnement in een specifieke regio en een Azure-datacenter. Als u assets repliceert naar een tweede regio, hebt u mogelijk ook een tweede Site Recovery-kluis nodig.

Configuratie- en processerverontwerp: Site Recovery werkt met een lokaal exemplaar van een configuratie- en processerver die is gebonden aan één Site Recovery-kluis. Wanneer u deze configuratie gebruikt, moet u mogelijk tweede exemplaren van deze servers installeren in het broncentrum om de replicatie te vergemakkelijken.

Ontwerp van netwerkbandbreedte: Tijdens de replicatie en doorlopende synchronisatie verplaatst u binaire gegevens via het netwerk van het brondatacentrum naar de Site Recovery-kluis in het Azure-doeldatacenter. Het replicatie- en synchronisatieproces verbruikt bandbreedte. Het dupliceren van de werkbelasting naar een tweede regio verdubbelt de hoeveelheid verbruikte bandbreedte.

In sommige scenario's is de bandbreedte beperkt. In andere bestaat een workload uit een aanzienlijke configuratie of gegevensdrift. In dergelijke gevallen kan het repliceren van gegevens naar een tweede regio de tijd verstoren die nodig is om de migratie te voltooien. Belangrijker is dat deze beperkingen van invloed kunnen zijn op de ervaring van gebruikers of toepassingen die nog steeds afhankelijk zijn van de bandbreedte die beschikbaar was in het broncentrum.

Gegevenssynchronisatie: de grootste bandbreedte is vaak afkomstig van het synchroniseren van het gegevensplatform. Als u in meerdere beschikbaarheidszones implementeert, kunt u mogelijk zone-redundante gegevensservices gebruiken waarmee uw gegevens automatisch worden gesynchroniseerd in meerdere beschikbaarheidszones. Implementatie in meerdere regio's vereist vaak gegevenssynchronisatie om toepassingen op elkaar af te stemmen. Deze benadering wordt gedefinieerd in de referentiearchitecturen voor webtoepassingen in meerdere regio's en toepassingen met meerdere regio's n-laag.

Als het synchroniseren van toepassingen de gewenste operationele status voor uw toepassingen is, wilt u het brongegevensplatform mogelijk synchroniseren met elk cloudplatform. Voer deze synchronisatie uit voordat u de assets van de toepassing en de middelste laag migreert.

Herstel na noodgevallen van Azure naar Azure: een alternatieve optie kan de complexiteit verder verminderen. Als u een implementatie in twee stappen gebruikt om te voldoen aan de tijdlijn en de behoeften voor gegevenssynchronisatie, kan herstel na noodgevallen van Azure naar Azure een acceptabele oplossing zijn. In dit scenario migreert u de workload naar het eerste Azure-datacenter met behulp van één Site Recovery-kluis en -configuratie en processerverontwerp. Nadat u de workload hebt getest, kunt u de workload herstellen naar een tweede Azure-datacenter vanuit de gemigreerde assets.

Deze benadering vermindert het effect op resources in het broncentrum. Herstel na noodgevallen van Azure naar Azure maakt ook gebruik van snelle overdrachtssnelheden en hoge bandbreedtelimieten tussen Azure-datacenters.

Notitie

De benadering voor herstel na noodgevallen van Azure naar Azure kan de kosten voor migratie op de korte termijn verhogen door hogere bandbreedtekosten voor uitgaand verkeer.

Wijzigingen in releaseproces

Bij het aanpakken van wereldwijde complexiteit tijdens optimalisatie en promotie hebt u mogelijk identieke inspanningen nodig in elke regio waarin u implementeert. Als u één regio gebruikt, moet u mogelijk nog steeds bedrijfstests en bedrijfswijzigingsplannen repliceren.

Voorgestelde acties tijdens het releaseproces

Optimalisatie vooraf testen: initiële automatiseringstests kunnen potentiële optimalisatiekansen identificeren, net als bij elke migratie-inspanning. Test de workload in elke regio onafhankelijk voor globale workloads. Kleine configuratiewijzigingen in uw netwerk of in het gekozen Azure-datacenter kunnen van invloed zijn op de prestaties.

Bedrijfswijzigingsplannen: Maak een bedrijfswijzigingsplan voor elk complex migratiescenario. Een bedrijfswijzigingsplan zorgt voor duidelijke communicatie over wijzigingen in bedrijfsprocessen en gebruikerservaringen. Het plan helpt ook duidelijke communicatie te garanderen over de timing van inspanningen die nodig zijn om wijzigingen te integreren. Bij een wereldwijde migratie moet het plan overwegingen bevatten voor gebruikers in elke betrokken geografie.

Bedrijfstests: voor elke regio is mogelijk ook bedrijfstests vereist. Bedrijfstests zorgen voor adequate prestaties en naleving van gewijzigde netwerkrouteringspatronen.

Promotievluchten: Promotie vindt vaak plaats als één activiteit en productieverkeer wordt onmiddellijk omgeleid naar de gemigreerde workloads. In een wereldwijde release-inspanning moet u promotie leveren in vooraf gedefinieerde verzamelingen gebruikers die vluchten worden genoemd. Promotievluchten bieden het cloudstrategieteam en het cloudacceptatieteam de mogelijkheid om prestaties te observeren en de ondersteuning voor gebruikers in elke regio te verbeteren. U kunt promotievluchten beheren op netwerkniveau. U kunt met name de routering van specifieke IP-bereiken wijzigen van de bronworkloadassets in de zojuist gemigreerde assets. Nadat u een opgegeven verzameling gebruikers hebt gemigreerd, kunt u de volgende groep omleiden.

Vluchtoptimalisatie: Een voordeel van promotievluchten is dat ze u diepere waarnemingen en een mogelijkheid bieden om de geïmplementeerde assets te optimaliseren. Nadat de eerste vlucht gedurende korte tijd productie heeft gebruikt, kunt u de gemigreerde assets verfijnen wanneer IT-bewerkingsprocedures deze ondersteunen.