Výběr oblastí Azure pro migraci

Při migraci existujícího prostředí do Azure musíte vybrat oblast Azure nebo sadu oblastí pro hostování migrovaných komponent. Výběr oblasti zahrnuje následující základní kroky:

• Projděte si základní pokyny k výběru oblastí Azure, abyste pochopili, jak vybrat oblasti Azure, které splňují vaše požadavky.
• Inventarizace a zdokumentování aktuálního stavu vašeho prostředí
• Implementovat obecný přístup k migraci, včetně toho, jestli se má spustit v jedné oblasti, používat více zón dostupnosti nebo používat více oblastí.
• Vyhodnocení změn procesů, které mohou být vyžadovány.
• Naplánujte proces migrace.
• Optimalizujte a propagujte změny procesů.

Tento článek obsahuje pokyny k výběru oblastí Azure, které vyhovují vašim potřebám migrace. Pokud jste to ještě neudělali, možná budete muset rozšířit oblasti cílové zóny tak, aby podporovaly přístupy k více oblastem.

Poznámka:

Tento článek se věnuje aspektům, které jsou specifické pro migrace úloh. Měli byste také porozumět obecným principům pro výběr oblastí Azure pro jakoukoli organizaci nebo úlohu. Další informace najdete v tématu Výběr oblastí Azure.

Zdokumentujte složitost scénáře

Určete, jestli váš scénář vyžaduje dokumentaci a sladění procesů. Následující přístup vám může pomoct vyhodnotit potenciální výzvy a vytvořit obecný postup:

• Zvažte robustnější připravenost a implementaci zásad správného řízení.
• Inventarizace ovlivněných zeměpisných oblastí Zkompilujte seznam ovlivněných zemí nebo oblastí.
• Zdokumentujte uživatelskou základnu. Ovlivní migrace do cloudu zaměstnance, partnery nebo zákazníky v identifikované zemi nebo oblasti?
• Zdokumentovat datacentra a prostředky Zahrnuje migrace nějaké prostředky v identifikované zemi nebo oblasti?
• Zdokumentovat dostupnost regionální verze produktu a požadavky na převzetí služeb při selhání
• Zdokumentujte požadavky na odolnost a určete, jestli jsou zóny dostupnosti povinné. Obvykle zvažujete požadavky na odolnost pro celý scénář, ne pro jednotlivé oblasti.
• Zdokumentujte své požadavky na suverenitu a požadavky na rezidenci dat. Úlohy, které mají konkrétní požadavky na suverenitu nebo rezidenci dat, můžou ovlivnit vaši volbu oblastí Azure.

V průběhu procesu migrace zvažte, jak sladit změny v různých scénářích a inventářích. Následující tabulka ukazuje příklad, jak zdokumentovat různé scénáře.

Oblast	Země/oblast	Místní zaměstnanci	Místní externí uživatelé	Místní datová centra nebo prostředky	Požadavky na suverenitu dat
Severní Amerika	USA	Ano	Partneři a zákazníci	Yes	No
Severní Amerika	Kanada	No	Zákazníci	Ano	Yes
Evropě	Německo	Ano	Partneři a zákazníci	Ne – pouze síť	Ano
Asie a Tichomoří	Jižní Korea	Ano	Partneři	Yes	No

Proč je umístění uživatelů relevantní?

Organizace, které podporují uživatele ve více zemích nebo oblastech, vyvíjejí technická řešení, která řeší provoz uživatelů. V některých případech řešení zahrnují lokalizaci prostředků. V jiných scénářích se organizace může rozhodnout implementovat globální řešení sítě WAN (Wide Area Network), která budou řešit různorodé uživatelské základny prostřednictvím řešení zaměřených na síť. V obou případech můžou profily využití různorodých uživatelů ovlivnit strategii migrace.

Pokud například organizace podporuje zaměstnance, partnery a zákazníky v Německu, ale v současné době nemá datacentra v Německu, organizace pravděpodobně implementuje zapůjčené řešení. Tento typ řešení směruje provoz do datacenter v jiných zemích nebo oblastech. Toto existující směrování představuje významné riziko pro vnímaný výkon migrovaných aplikací. Vkládání dalších segmentů směrování do zavedené a vyladěné globální sítě WAN může po migraci způsobit vnímání nedostatečného výkonu aplikací. Hledání a oprava těchto problémů může způsobit významné zpoždění projektu.

Každá z následujících částí obsahuje pokyny pro řešení této složitosti napříč požadavky a procesy posouzení, migrace a optimalizace. Pro správnou správu této složitosti je důležité porozumět profilům uživatelů v jednotlivých zemích nebo oblastech.

Proč hraje roli místo, kde se nachází datacentra?

Umístění existujících datacenter může mít vliv na strategii migrace. Vezměte v úvahu následující faktory:

Rozhodnutí o architektuře: Jedním z prvních kroků návrhu strategie migrace je určení cílové oblasti. Umístění stávajících prostředků často ovlivňuje toto určení. Dostupnost cloudových služeb a jednotkové náklady na tyto služby se také můžou mezi oblastmi lišit. Požadavky na rezidenci dat, včetně požadavků na suverenitu, mohou také ovlivnit rozhodnutí o architektuře. Pochopení, kde se nacházejí aktuální a budoucí prostředky, ovlivňuje rozhodování o architektuře a může ovlivnit odhady rozpočtu.

Závislosti datacenter: V tabulce v části Dokumentovat složitost scénáře ukazují ukázkové scénáře, že pravděpodobně potřebujete naplánovat závislosti mezi různými globálními datovými centry. Organizace, které pracují s tímto škálováním, nemusí dokumentovat ani jasně porozumět těmto závislostem. Přístup vaší organizace k vyhodnocení profilů uživatelů vám pomůže identifikovat některé z těchto závislostí ve vaší organizaci. Váš tým by měl také prozkoumat další kroky posouzení, které vám můžou pomoct zmírnit rizika a složitosti vyplývající ze závislostí.

Implementace obecného přístupu

Následující přístup používá model řízený daty k řešení složitostí globální migrace. Pokud rozsah migrace zahrnuje více oblastí, měl by tým přechodu na cloud vyhodnotit následující aspekty připravenosti:

• Určete, jestli můžete splnit své obchodní požadavky: Pomocí několika zón dostupnosti určete požadavky na vysokou dostupnost, odolnost, výkon a náklady. Pokud tyto požadavky nejsou splněné, zvažte, jestli potřebujete přístup s více oblastmi.

• Vyhodnocení suverenity dat: Suverenita dat může vyžadovat lokalizaci některých prostředků, ale mnoho prostředků se neřídí těmito omezeními dodržování předpisů. Služby, jako je protokolování, vytváření sestav, směrování sítě, identita a další centrální IT služby, můžou být hostované jako sdílené služby napříč několika předplatnými nebo oblastmi. Vyhodnoťte suverenitu dat pomocí modelu sdílené služby pro tyto služby. Přehled tohoto přístupu najdete v referenční architektuře hvězdicové topologie se sdílenými službami.

• Ujistěte se, že se vaše prostředí škáluje: Pokud nasadíte více instancí podobných prostředí, můžete vytvořit vyhrazený tým pro migrace prostředí, který vám pomůže vytvořit konzistenci, zlepšit zásady správného řízení a urychlit nasazení. Průvodce zásadami správného řízení pro komplexní firmy zavádí přístup pro vytvoření prostředí, které se škáluje v rámci více oblastí.

Požadavky řízené daty

Pokud váš tým vyhovuje základnímu přístupu a připravenosti, zvažte tyto požadavky řízené daty:

• Dokončení obecného zjišťování: Dokončete tabulku ve složitosti dokumentu a vyhodnoťte složitost strategie přechodu na cloud.

• Analýza profilů uživatelů pro každou ovlivněnou zemi nebo oblast: Je důležité pochopit obecné směrování uživatelů v rané fázi procesu migrace. Změna globálních zapůjčení a přidání připojení, jako je Azure ExpressRoute, do cloudového datacentra může vést ke zpoždění v měsících sítě. Vyřešte směrování uživatelů co nejdříve v procesu.

• Dokončení počáteční racionalizace digitálních aktiv: Pokud do strategie migrace zavedete složitost, dokončete počáteční racionalizaci digitálních aktiv. Další informace najdete v tématu Co je digitální aktiva?

• Používejte označování pro požadavky na digitální aktiva: Vytvořte zásady označování, které identifikují všechny úlohy ovlivněné požadavky na suverenitu dat. Ujistěte se, že požadované značky začínají racionalizací digitálních aktiv a přenášejí se do migrovaných prostředků.

• Vyhodnocení hvězdicového modelu: Distribuované systémy často sdílejí společné závislosti. Sdílené závislosti můžete často řešit implementací hvězdicového modelu. Přestože implementace hvězdicového modelu je mimo rozsah procesu migrace, označte model příznakem pro zvážení během budoucích iterací připravených procesů.

• Určete prioritu backlogu migrace: Pokud potřebujete změny sítě pro podporu produkčního nasazení úlohy, která podporuje více oblastí, tým cloudové strategie by měl sledovat a spravovat eskalace, které vyplývají ze změn sítě. Tato vyšší úroveň podpory vedoucích pracovníků pomáhá urychlit změnu uvolněním týmu strategie, aby přepsal backlog a zajistil, že změny sítě neblokují globální úlohy. Upřednostnit globální úlohy pouze v době, kdy jsou změny sítě dokončeny.

Tyto požadavky pomáhají vytvářet procesy, které mohou řešit složitost během provádění strategie migrace.

Změny procesu posouzení

Pokud váš scénář migrace zahrnuje globální složitost prostředků a uživatelských základů, přidejte klíčové aktivity pro vyhodnocení kandidátů na migraci. Tyto aktivity vytvářejí data, která vám pomůžou objasnit překážky a výsledky pro globální uživatele a prostředky.

Navrhované akce během procesu posouzení

Vyhodnocení závislostí mezi datovými centry: Nástroje pro analýzu závislostí ve službě Azure Migrate vám můžou pomoct určit závislosti. Než začnete s migrací, použijte tyto nástroje. Pokud váš scénář zahrnuje globální složitost, vyhodnocení závislostí je nezbytným krokem procesu posouzení. Pomocí seskupení závislostí můžete vizualizovat závislosti a identifikovat IP adresy a porty všech prostředků, které jsou potřeba k podpoře úlohy.

Důležité

• K identifikaci prostředků umístěných v sekundárním datacentru potřebujete odborníka na danou problematiku (SME).
• Vyhodnoťte podřízené závislosti a klienty ve vizualizaci, abyste porozuměli obousměrným závislostem.

Identifikovat dopad globálního uživatele: Výstup z požadované analýzy profilů uživatelů by měl identifikovat všechny úlohy ovlivněné globálními profily uživatelů. Pokud je kandidát na migraci v seznamu ovlivněných úloh, měl by architekt migrace konzultovat se sítěmi a provozními msp. Tito odborníci pomáhají ověřit očekávání směrování sítě a výkonu. Architektura by minimálně měla zahrnovat připojení ExpressRoute mezi nejbližším síťovým provozním centrem a Azure. Referenční architektura pro připojení ExpressRoute vám může pomoct s konfigurací potřebných síťových připojení.

Návrh pro dodržování předpisů: Výstup z požadované analýzy profilů uživatelů by měl také identifikovat všechny úlohy ovlivněné požadavky na suverenitu dat. Během činností architektury procesu posouzení by přiřazený architekt měl konzultovat s msp v oblasti dodržování předpisů. Tito odborníci můžou architektu pomoct pochopit všechny požadavky na migraci a nasazení napříč několika oblastmi. Tyto požadavky významně ovlivňují strategie návrhu. S návrhem vám můžou pomoct následující referenční architektury:

• Zónově redundantní webové aplikace
• Webové aplikace s více oblastmi
• Vícevrstvé aplikace ve více oblastech
• Šablony úloh pro suverénní cílovou zónu

Upozorňující

Pokud používáte referenční architekturu pro ExpressRoute nebo referenční architektury pro aplikace, možná budete muset vyloučit konkrétní datové prvky z procesů replikace, aby splňovaly požadavky na suverenitu dat. Úloha vyloučení konkrétních datových prvků přidá krok procesu povýšení.

Změny procesu migrace

Pokud migrujete aplikaci, která se musí nasadit do více oblastí, musí tým přechodu na cloud vzít v úvahu několik dalších aspektů. Návrh trezorů Azure Site Recovery a konfigurace a procesových serverů jsou dva z těchto aspektů. Dalšími faktory jsou návrhy šířky pásma sítě a synchronizace dat.

Navrhované akce během procesu migrace

Návrh trezoru Site Recovery: Site Recovery je navrhovaný nástroj pro replikaci nativní pro cloud a synchronizaci digitálních prostředků do Azure. Site Recovery replikuje data o jednotlivých prostředcích do trezoru Site Recovery. Tento trezor je vázán na konkrétní předplatné v konkrétní oblasti a datacentru Azure. Pokud replikujete prostředky do druhé oblasti, možná budete potřebovat také druhý trezor Site Recovery.

Návrh konfiguračního a procesového serveru: Site Recovery pracuje s místní instancí konfiguračního a procesového serveru, který je svázaný s jedním trezorem Site Recovery. Při použití této konfigurace možná budete muset nainstalovat druhé instance těchto serverů ve zdrojovém datacentru, aby se usnadnila replikace.

Návrh šířky pásma sítě: Během replikace a průběžné synchronizace přesunete binární data přes síť ze zdrojového datacentra do trezoru Site Recovery v cílovém datacentru Azure. Proces replikace a synchronizace spotřebovává šířku pásma. Duplikování úlohy do druhé oblasti zdvojnásobí využitou šířku pásma.

V některých scénářích je šířka pásma omezená. V jiných případech úloha zahrnuje podstatnou konfiguraci nebo posun dat. V těchto případech může replikace dat do druhé oblasti kolidovat s dobou potřebnou k dokončení migrace. Důležitější je, že tato omezení můžou ovlivnit zkušenosti uživatelů nebo aplikací, které stále závisejí na šířce pásma, která byla dostupná ve zdrojovém datacentru.

Synchronizace dat: Největší vyprázdnění šířky pásma často pochází z synchronizace datové platformy. Pokud nasazujete napříč několika zónami dostupnosti, možná budete moct používat zónově redundantní datové služby, které automaticky synchronizují vaše data napříč několika zónami dostupnosti. Nasazení napříč několika oblastmi často vyžaduje synchronizaci dat, aby aplikace byly v souladu. Tento přístup je definován v referenčních architekturách pro webové aplikace s více oblastmi a vícevrstvé aplikace.

Pokud se aplikace synchronizují, je provozní stav, který chcete pro své aplikace použít, můžete chtít synchronizovat zdrojovou datovou platformu s každou cloudovou platformou. Tuto synchronizaci proveďte před migrací aplikací a prostředků střední vrstvy.

Zotavení po havárii Azure do Azure: Alternativní možnost může dále snížit složitost. Pokud ke splnění požadavků na časovou osu a synchronizaci dat použijete dvoustupňové nasazení, může být řešením zotavení po havárii Azure do Azure. V tomto scénáři provedete migraci úlohy do prvního datacentra Azure pomocí jednoho trezoru Site Recovery a konfigurace a návrhu procesového serveru. Po otestování úlohy můžete z migrovaných prostředků obnovit úlohu do druhého datacentra Azure.

Tento přístup snižuje vliv na prostředky ve zdrojovém datacentru. Zotavení po havárii Azure-to-Azure také využívá rychlé přenosové rychlosti a vysoké limity šířky pásma mezi datacentry Azure.

Poznámka:

Přístup zotavení po havárii Azure do Azure může zvýšit krátkodobé náklady na migraci prostřednictvím vyšších poplatků za šířku pásma výchozího přenosu dat.

Změny procesu vydávání verzí

Při řešení globální složitosti během optimalizace a povýšení můžete vyžadovat stejné úsilí v každé oblasti, do které nasadíte. Pokud používáte jednu oblast, možná budete muset replikovat obchodní testování a plány obchodních změn.

Navrhované akce během procesu vydání

Předběžná optimalizace: Počáteční automatizační testování dokáže identifikovat potenciální příležitosti optimalizace, stejně jako při jakékoli migraci. U globálních úloh nezávisle testujte úlohy v jednotlivých oblastech. Menší změny konfigurace ve vaší síti nebo ve zvoleném datacentru Azure můžou ovlivnit výkon.

Plányobchodních Plán obchodních změn pomáhá zajistit jasnou komunikaci o změnách obchodních procesů a uživatelských prostředí. Plán také pomáhá zajistit jasnou komunikaci o načasování úsilí potřebného k integraci změn. V globálním úsilí o migraci by plán měl zahrnovat aspekty pro uživatele v jednotlivých ovlivněných zeměpisných oblastech.

Obchodní testování: Každá oblast může také vyžadovat obchodní testování. Obchodní testování pomáhá zajistit odpovídající výkon a dodržování upravených vzorů směrování sítě.

Lety povýšení: Povýšení často probíhá jako jedna aktivita a produkční provoz se okamžitě znovu směruje na migrované úlohy. V rámci globálního úsilí o vydání byste měli zajistit povýšení v předdefinovaných kolekcích uživatelů, kteří volali lety. Lety povýšení poskytují týmu cloudové strategie a týmu přechodu na cloud příležitost sledovat výkon a zlepšit podporu pro uživatele v jednotlivých oblastech. Můžete řídit povýšení letů na úrovni sítě. Konkrétně můžete změnit směrování konkrétních rozsahů IP adres ze zdrojových prostředků úloh na nově migrované prostředky. Po migraci zadané kolekce uživatelů můžete nasměrovat další skupinu.

Optimalizace letů: Jednou z výhod povýšení letů je, že poskytují hlubší pozorování a příležitost optimalizovat nasazené prostředky. Po úspěšném dokončení prvního letu po krátkou dobu použijete produkční prostředí, můžete migrované prostředky upřesnit, když je podporují provozní postupy IT.