Průvodce rozhodováním o oblastech Azure

Při návrhu strategie migrace do Azure si můžete vybrat z mnoha oblastí Azure po celém světě. Každá oblast Azure má specifické charakteristiky, díky kterým je výběr správné oblasti pro vaše prostředky Azure nezbytný. Mezi důležité informace patří dostupné služby, kapacita, omezení a suverenita:

• Dostupné služby: Služby Azure, které můžete nasadit v každé oblasti, se liší v závislosti na různých faktorech. Vyberte oblast pro službu, kterou potřebujete pro úlohu. Další informace najdete v tématu Dostupné produkty v jednotlivých oblastech.
• Kapacita: Každá oblast má maximální kapacitu. Maximální kapacita oblasti může ovlivnit, jaké typy předplatných můžou nasazovat a za jakých okolností. Místní kapacita se liší od kvóty předplatného. Pokud plánujete rozsáhlou migraci datacentra do Azure, možná se budete chtít poradit s místním týmem Azure field nebo se svým správcem účtů Azure, abyste si ověřili, že můžete provést nasazení v požadovaném měřítku.
• Omezení: Určitá omezení jsou kladena na nasazení služeb v určitých oblastech. Například některé oblasti jsou k dispozici pouze pro zálohování nebo převzetí služeb při selhání. Mezi další důležitá omezení, která je potřeba zmínit, patří požadavky na suverenitu dat.
• Suverenita: Určité oblasti jsou vyhrazené pro konkrétní suverénní entity. I když jsou všechny oblasti oblastmi Azure, jsou tyto suverénní oblasti izolované od zbytku Azure. Nemusí je nutně spravovat Microsoft a můžou být omezené na určité typy zákazníků. Jde o tyto suverénní oblasti:
  • Azure (Čína) 21Vianet
  • Azure (Německo)
    Azure Pro Německo se vyřazuje ve prospěch standardních oblastí Azure, které nejsou v Německu nadřízené.
  • Azure Government – USA

Provoz v několika geografických oblastech

Organizace může pracovat v několika geografických oblastech, aby dosáhla odolnosti, která je pro její provoz nezbytná. Operace v několika geografických oblastech přináší potenciální složitost v následujících formách:

• Distribuce prostředků
• Profily přístupu uživatelů
• Požadavky na dodržování předpisů
• Regionální odolnost

Výběr oblasti je klíčovou součástí celkové strategie přechodu na cloud. Začněte aspekty sítě.

Důležité informace z hlediska využívání sítě

Každé robustní cloudové nasazení vyžaduje dobře promyšlenou síť, která bere v úvahu rozdíly v oblastech Azure. Měli byste zohlednit následující faktory:

• Spárované oblasti Azure. Každá oblast je spárovaná s jinou oblastí ve stejné geopolitické hranici, aby byla zajištěna odolnost v případě katastrofického selhání oblasti. Jednou z výjimek je Brazil South, který je spárovaný s South Central US.

  Zvažte nasazení do spárovaných oblastí jako primární a sekundární strategii odolnosti. Tady jsou další informace, které byste měli zvážit:

  • Azure Storage podporuje geograficky redundantní úložiště (GRS). Ve službě Azure Storage GRS jsou tři kopie vašich dat uložené ve vaší primární oblasti a tři další kopie jsou uložené ve spárované oblasti. Nemůžete změnit párování úložiště pro GRS.
  • Tuto možnost spárované oblasti mohou využít služby, které se spoléhají na GRS služby Azure Storage. Vaše aplikace a síť musí být nakonfigurované tak, aby podporovaly spárované oblasti.
  • Pokud nemáte v úmyslu používat GRS k podpoře potřeb v oblasti odolnosti, neměli byste spárovanou oblast používat jako sekundární. Pokud dojde k selhání oblasti, je při migraci prostředků kladen velký tlak na prostředky ve spárované oblasti. Takovému tlaku se můžete vyhnout obnovením do alternativní lokality a získáním rychlosti během obnovení.

  Upozornění

  Nepokoušejte se používat Azure Storage GRS k zálohování nebo obnovení virtuálních počítačů. Místo toho použijte Azure Backup, Azure Site Recovery a spravované disky Azure, abyste podpořili odolnost úloh infrastruktury jako služby (IaaS).

  Další informace najdete v tématu Spárované oblasti Azure.

• Azure Backup a Azure Site Recovery spolu s návrhem vaší sítě zajišťují regionální odolnost pro potřeby zálohování dat a IaaS. Ujistěte se, že je síť optimalizovaná, aby přenosy dat zůstaly v páteřní síti Microsoftu a pokud je to možné, používají partnerský vztah virtuálních sítí. Některé větší organizace, které mají globální nasazení, můžou místo toho používat Azure ExpressRoute Premium ke směrování provozu mezi oblastmi a potenciálně ušetřit poplatky za místní výchozí přenos dat.

• Skupiny prostředků Azure jsou specifické pro oblasti Azure. Prostředky ve skupině prostředků ale často pokrývají více oblastí. Při selhání oblasti operace řídicí roviny proti skupině prostředků selžou v ovlivněné oblasti, ale prostředky v jiných oblastech v této skupině prostředků dál fungují. Odolnost skupin prostředků podle oblasti může ovlivnit způsob návrhu sítě a skupiny prostředků.

• Mnoho služeb typu platforma jako služba (PaaS) v koncových bodech služby podpora Azure nebo Azure Private Link. Obě tato řešení můžou významně ovlivnit způsob návrhu sítě, protože berete v úvahu regionální odolnost, migraci a zásady správného řízení.

• Řada služeb PaaS se spoléhá na vlastní řešení regionální odolnosti. Například v nasazeních pro Azure SQL Database a Azure Cosmos DB můžete snadno replikovat do více oblastí. Některé služby Azure, jako je Azure DNS, nemají místní závislosti. Při zvažování, které služby budete v procesu přechodu na cloud používat, se ujistěte, že jasně rozumíte možnostem převzetí služeb při selhání a krokům obnovení, které můžou být pro každou službu Azure, kterou používáte, vyžadovány.

• Kromě nasazení do několika oblastí pro podporu zotavení po havárii se mnoho organizací rozhodne nasadit ve vzoru aktivní-aktivní, aby se zabránilo spoléhání na převzetí služeb při selhání. Mezi výhody použití modelu aktivní-aktivní patří globální vyrovnávání zatížení, zvýšená odolnost proti chybám a zvýšení výkonu sítě. Aby bylo možné tento model využít, musí vaše aplikace podporovat spouštění aktivní-aktivní ve více oblastech.

Upozornění

Oblasti Azure jsou vysoce dostupné konstruktory. Smlouvy o úrovni služeb Azure se vztahují na služby spuštěné v konkrétních oblastech. Nikdy byste neměli nasazovat se závislostí na klíčových aplikacích v jedné oblasti. Vždy naplánujte regionální selhání a procvičte si kroky obnovení a zmírnění rizik.

Zdokumentujte složitost scénáře.

Po zvážení topologie sítě určete, jestli je potřeba více dokumentace a sladění procesů. Následující přístup vám může pomoct vyhodnotit potenciální výzvy a stanovit obecný postup:

• Zvažte robustnější připravenost a implementaci zásad správného řízení.
• Sepište si ovlivněné geografické oblasti. Sestavte seznam ovlivněných zemí nebo oblastí.
• Zdokumentujte si požadavky na suverenitu dat. Mají určené země nebo oblasti požadavky na dodržování předpisů, které řídí suverenitu dat?
• Zdokumentujte si uživatelskou základnu. Ovlivní migrace do cloudu zaměstnance, partnery nebo zákazníky v určené zemi nebo oblasti?
• Zdokumentujte si datacentra a prostředky. Existují v určené zemi nebo oblasti prostředky, které by mohly být zahrnuty do úsilí o migraci?
• Zdokumentujte regionální dostupnost jednotek SKU a požadavky převzetí služeb při selhání.

Zarovnejte změny v průběhu procesu migrace, abyste vyřešili počáteční inventář. Následující tabulka ukazuje příklady scénářů, které vám můžou pomoct zdokumentovat vaše zjištění:

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

Znalost požadavků na suverenitu dat

Vládní organizace po celém světě začaly zakládat suverenitu dat a předpisy na ochranu osobních údajů v datech. Tyto typy požadavků na dodržování předpisů často kvůli ochraně občanů v dané lokalitě vyžadují lokalizaci v konkrétní zemi nebo oblasti. V některých případech musí být data týkající se zákazníků, zaměstnanců nebo partnerů uložená na cloudové platformě ve stejné oblasti jako uživatel.

Řešení tohoto problému bylo významnou motivací pro migrace do cloudu pro organizace, které působí v globálním měřítku. Kvůli zachování dodržování předpisů pro suverenitu dat se některé organizace rozhodly nasadit duplicitní IT prostředky pro poskytovatele cloudu v dané oblasti. V předchozí tabulce je dobrým příkladem scénář s Německem. Scénář zahrnuje zákazníky, partnery a zaměstnance, ale ne aktuální it souhlasy v Německu. Tato organizace se může rozhodnout nasadit některé prostředky do datacentra v oblasti regulace suverenity dat, případně pomocí německých datacenter Azure. Znalost dat ovlivněných předpisy o suverenitě dat v jednotlivých oblastech by pomohla týmu přechodu na cloud pochopit nejlepší přístup k migraci pro organizaci.

Proč je poloha uživatelů relevantní?

Organizace, které podporují uživatele v několika zemích nebo oblastech, vyvinuly 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í wan (Wide Area Network), která řeší různorodé uživatelské základny prostřednictvím řešení zaměřených na síť. V obou případech může být strategie migrace ovlivněna profily použití různorodých uživatelů.

Pokud organizace podporuje zaměstnance, partnery a zákazníky v Německu, aniž by v současné době měla datacentra v Německu, pravděpodobně implementovala řešení s pronajatou linkou. 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í. Vložení dalších segmentů směrování do zavedené a vyladěné globální sítě WAN může po migraci vyvolat dojem nedostatečného výkonu aplikací. Hledání a oprava těchto problémů může způsobit významné zpoždění projektu.

V každém z následujících procesů jsou pokyny k řešení této složitosti zahrnuty v rámci požadavků a procesů posouzení, migrace a optimalizace. Pro správnou správu této složitosti je důležité porozumět profilům uživatelů v každé zemi nebo oblasti.

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

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

Rozhodnutí o architektuře: Určení cílové oblasti je jedním z prvních kroků při návrhu strategie migrace. Toto určení je často ovlivněno umístěním existujících prostředků. Dostupnost cloudových služeb a jednotkové náklady na tyto služby se můžou v jednotlivých oblastech lišit. Pochopení umístění aktuálních a budoucích prostředků ovlivňuje rozhodování o architektuře a může ovlivnit odhady rozpočtu.

Závislosti datacentra: Ukázkové scénáře v tabulce složitosti dokumentu ukazují, že pravděpodobně budete muset naplánovat závislosti mezi různými globálními datovými centry. Závislosti nemusí být v mnoha organizacích, které pracují v tomto měřítku, jasně zdokumentované nebo srozumitelné. 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 také měl prozkoumat další kroky posouzení, které vám můžou pomoct zmírnit rizika a složitost vyplývající ze závislostí.

Implementace obecného přístupu

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

• Suverenita dat může vyžadovat lokalizaci některých prostředků, ale mnoho prostředků nemusí být těmito omezeními dodržování předpisů řízeno. Položky jako protokolování, vytváření sestav, směrování sítě, identita a další centrální IT služby můžou mít nárok na hostování jako sdílené služby napříč několika předplatnými nebo několika oblastmi. Tým přechodu na cloud by měl vyhodnotit suverenitu dat pomocí modelu sdílených služeb pro tyto služby, jak je uvedeno v referenční architektuře hvězdicové topologie se sdílenými službami.
• Když nasazujete více instancí podobných prostředí, můžete pomocí objektu pro vytváření prostředí 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 je tým obeznámený se základním přístupem a připraveností je v souladu, zvažte několik požadavků založených na datech:

• Dokončení obecného zjišťování: Vyplňte tabulku složitosti dokumentu a vyhodnoťte složitost strategie přechodu na cloud.
• Analýza profilů uživatelů v každé ovlivněné zemi nebo oblasti: Je důležité pochopit obecné směrování uživatelů v rané fázi procesu migrace. Změna globálních pronajatých linek a přidávání připojení, jako je ExpressRoute, do cloudového datového centra může vyžadovat zpoždění v řádu měsíců. Adresujte směrování uživatelů co nejdříve v procesu.
• Dokončení počáteční racionalizace digitálních aktiv: Když strategie migrace zavádí složitost, měli byste dokončit počáteční racionalizaci digitálních aktiv. Další informace najdete v tématu Co je digitální aktiva?
• Použití označování pro požadavky na digitální aktiva: Vytvořte zásady označování k identifikaci všech úloh, které jsou ovlivněné požadavky na suverenitu dat. Požadované značky by měly začínat racionalizací digitálních aktiv a projít až k migrovaným prostředkům.
• 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 je implementace hvězdicového modelu mimo rozsah procesu migrace, označte model příznakem, který se má zvážit během budoucích iterací připravených procesů.
• Stanovení priority backlogu migrace: Pokud se kvůli podpoře produkčního nasazení úlohy, která podporuje více oblastí, vyžadují změny sítě, měl by tým cloudové strategie sledovat a spravovat eskalace, které jsou výsledkem změn sítě. Vyšší úroveň podpory vedoucích pracovníků pomáhá urychlit změnu tím, že uvolní tým strategie, aby změnil prioritu backlogu a zajistil, že změny sítě neblokují globální úlohy. Upřednostnit globální úlohy pouze po dokončení změn sítě.

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

Vyhodnocení změn procesu

Když se vaše organizace ve scénáři migrace potýká s globálními problémy s prostředky a uživatelskou základnou, měli byste přidat několik klíčových aktivit, abyste posoudili kandidáty na migraci. Tyto aktivity vytvářejí data, která objasňují překážky a výsledky pro globální uživatele a prostředky.

Navrhovaná akce během procesu vyhodnocení

Vyhodnocení závislostí mezi datovými centry: Nástroje pro vizualizaci závislostí ve službě Azure Migrate vám můžou pomoct určit závislosti. Osvědčeným postupem je použít tyto nástroje před zahájením migrace. Pokud se jedná o globální složitost, stane se nezbytným krokem v procesu hodnocení. Vizualizace závislostí vám může prostřednictvím seskupování závislostí pomoct identifikovat IP adresy a porty všech prostředků, které jsou potřeba k podpoře úloh.

Důležité

• Odborník na danou problematiku, který rozumí schématům umístění prostředků a IP adres, musí identifikovat prostředky umístěné v sekundárním datacentru.
• Vyhodnoťte podřízené závislosti i klienty ve vizualizaci, abyste porozuměli obousměrným závislostem.

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

Návrh pro dodržování předpisů: Výstupy z analýzy požadovaného profilu uživatele by také měly identifikovat všechny úlohy, které jsou ovlivněné požadavky na suverenitu dat. Během činností architektury procesu posouzení by měl přiřazený architekt konzultovat odborníky na danou problematiku dodržování předpisů. Tito odborníci můžou architektu pomoct pochopit všechny požadavky na migraci a nasazení v různých oblastech. Tyto požadavky výrazně ovlivňují strategie návrhu. S návrhem vám můžou pomoct referenční architektury pro webové aplikace s více oblastmi a n-vrstvé aplikace ve více oblastech .

Upozornění

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

Změny procesu migrace

Při migraci aplikace, která se musí nasadit do více oblastí, musí tým přechodu na cloud vzít v úvahu několik dalších aspektů. Aspekty zahrnují návrh trezoru Azure Site Recovery, návrh konfigurace a procesového serveru, návrhy šířky pásma sítě a synchronizaci dat.

Navrhovaná akce během procesu migrace

Návrh trezoru Azure Site Recovery: Azure Site Recovery je navrhovaný nástroj pro replikaci a synchronizaci digitálních prostředků do Azure nativní pro cloud. Site Recovery replikuje data o daném prostředku do trezoru Site Recovery, který je vázán na konkrétní předplatné v konkrétní oblasti a datacentru Azure. Při replikaci prostředků do druhé oblasti můžete potřebovat také druhý Site Recovery trezoru.

Návrh konfiguračního a procesového serveru: Site Recovery funguje s místní instancí konfiguračního a procesového serveru, který je vázaný na jeden Site Recovery trezor. Konfigurace znamená, že možná budete muset nainstalovat druhou instanci těchto serverů ve zdrojovém datacentru, aby se usnadnila replikace.

Návrh šířky pásma sítě: Během replikace a probíhající synchronizace přesouváte binární data přes síť ze zdrojového datacentra do Site Recovery trezoru v cílovém datacentru Azure. Proces replikace a synchronizace spotřebovává šířku pásma. Duplikováním úlohy do druhé oblasti zdvojnásobíte využitou šířku pásma. Pokud je šířka pásma omezená nebo úloha zahrnuje značnou konfiguraci nebo posun dat, může replikace dat do druhé oblasti narušit dobu potřebnou k dokončení migrace. Ještě důležitější je, že tato omezení můžou ovlivnit prostředí uživatelů nebo aplikací, které stále závisejí na šířce pásma dostupné ve zdrojovém datacentru.

Synchronizace dat: Největší vyčerpání šířky pásma často pochází ze synchronizace datové platformy. Jak je definováno v referenčních architekturách pro webové aplikace ve více oblastech a n-vrstvé aplikace ve více oblastech, synchronizace dat je často nutná k zajištění sladění aplikací. Pokud je udržování synchronizace aplikací provozním stavem, který chcete pro vaše aplikace, můžete chtít synchronizovat zdrojovou datovou platformu s každou cloudovou platformou. Měli byste to udělat před migrací aplikace a prostředků střední vrstvy.

Zotavení po havárii Azure do Azure: Alternativní možnost může složitost dále snížit. Pokud časová osa a synchronizace dat znamenají, že možná budete muset provést dvoustupňové nasazení, může být zotavení po havárii z Azure do Azure přijatelné řešení. Ve scénáři migrujete úlohu do prvního datacentra Azure pomocí jednoho trezoru Site Recovery a návrhu konfiguračního nebo 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 a využívá rychlejší přenosovou rychlost a omezení šířky pásma mezi datovými centry Azure.

Poznámka

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

Změny procesu optimalizace a povýšení

Při řešení globální složitosti během optimalizace a povýšení můžete vyžadovat stejné úsilí v každé z ostatních oblastí. Pokud je přijatelné jedno nasazení, možná budete muset replikovat obchodní testování a plány obchodních změn.

Navrhovaná akce během procesu optimalizace a povýšení

Optimalizace před testováním: Počáteční automatické testování může identifikovat potenciální příležitosti k optimalizaci, stejně jako u jakéhokoli úsilí o migraci. V případě globálních úloh nezávisle otestujte úlohy v každé oblasti. Menší změny konfigurace ve vaší síti nebo v datovém centru Azure, které zvolíte, můžou mít vliv na výkon.

Plány obchodních změn: Pro jakýkoli složitý scénář migrace vytvořte plán obchodních změn. Použití plánu obchodních změn pomáhá zajistit jasnou komunikaci o změnách obchodních procesů a uživatelského prostředí a o načasování úsilí potřebného k integraci změn. V rámci globální migrace by plán měl zahrnovat aspekty týkající se uživatelů v každé ovlivněné geografické oblasti.

Obchodní testování: Kromě plánu obchodních změn může být v každé oblasti vyžadováno obchodní testování. Obchodní testování v každé oblasti pomáhá zajistit odpovídající výkon a dodržování upravených vzorů síťového směrování.

Testovací verze povýšení: Povýšení často probíhá jako jedna aktivita a produkční provoz je okamžitě přesměrován na migrované úlohy. V rámci globálních vydání byste měli poskytovat povýšení v testovacích verzích, což jsou předdefinované kolekce uživatelů. Použití testovacích verzí povýšení dává týmu cloudové strategie a týmu přechodu na cloud příležitost sledovat výkon a vylepšovat podporu uživatelů v každé oblasti. Propagační lety se často řídí na úrovni sítě změnou 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ů je možné směrovat další skupinu.

Optimalizace letů: Jednou z výhod použití propagačních testovacích verzí je, že máte hlubší pozorování a možnost optimalizovat nasazené prostředky. Jakmile první testovací verze po krátkou dobu úspěšně použije produkční prostředí, můžete migrované prostředky upřesnit, jakmile to provozní postupy IT podporují.