Návrh architektury úloh před migrací

Tento článek popisuje proces a aspekty návrhu zamýšleného migrovaného stavu úlohy v cloudu. Článek kontroluje aktivity, které jsou součástí definování architektury úlohy v rámci iterace.

Článek o přírůstkové racionalizaci označuje, že některé architektonické předpoklady jsou součástí jakékoli obchodní transformace, která zahrnuje migraci. Tento článek vysvětluje typické předpoklady. Odkazuje také na několik překážek, kterým se můžete vyhnout, a identifikuje příležitosti ke zrychlení obchodní hodnoty náročnými předpoklady architektury. Tento přírůstkový model pro návrh architektury pomáhá týmům rychleji přesouvat a získávat obchodní výsledky dříve.

Návrh základní architektury na základě běžných předpokladů

Následující předpoklady jsou typické při každé migraci:

• Předpokládejme úlohu infrastruktury jako služby (IaaS). Migrace úloh primárně zahrnuje přesun serverů z fyzického datacentra do cloudového datacentra prostřednictvím migrace IaaS. Tento proces obvykle vyžaduje minimální opětovné nasazení nebo rekonfiguraci. Tento přístup se označuje jako migrace metodou "lift and shift" .
• Udržujte architekturu konzistentní. Provádění změn základní architektury během migrace výrazně zvyšuje složitost. Ladění změněného systému na nové platformě přináší řadu proměnných, které můžou být obtížně oddělitelné. Úlohy by během migrace měly procházet pouze menší změny a všechny změny by se měly důkladně testovat.
• Naplánujte změnu velikosti prostředků. Předpokládejme, že několik místních prostředků plně využívá jakýkoli prostředek. Před migrací nebo během migrace se prostředky mění tak, aby co nejlépe vyhovovaly skutečným požadavkům na využití. Nástroje, jako je Azure Migrate a Modernizace, poskytují velikost na základě skutečného použití.
• Zachyťte požadavky na provozní kontinuitu a zotavení po havárii (BCDR). Pokud máte odsouhlasenou smlouvu o úrovni služeb (SLA) pro úlohu, která už s firmou vyjednávala, po migraci do Azure pokračujte v používání smlouvy SLA. Pokud smlouva SLA ještě není nastavená, nadefinujte ji před návrhem úlohy v cloudu, abyste měli jistotu, že je navrhujete správně.
• Naplánujte výpadek migrace. Stejně jako selhání splnění požadavků smlouvy SLA může mít výpadek, ke kterým dochází při povýšení úlohy do produkčního prostředí, nepříznivý vliv na firmu. Někdy řešení, která musí přecházet s minimálními výpadky, potřebují změny architektury. Než začnete s plánováním vydávání verzí, předpokládejme, že je zaveden obecný přehled o požadavcích na prostoje.
• Definujte vzory provozu uživatelů a aplikací. Stávající řešení můžou záviset na existujících vzorech a řešeních směrování sítě. Identifikujte prostředky, které potřebujete k podpoře aktuálního využití sítě.
• Naplánujte, abyste se vyhnuli konfliktům sítě. Když datacentra konsolidujete do jednoho poskytovatele cloudu, pravděpodobně budete vytvářet konflikty v systému DNS (Domain Name System) nebo jiných síťových strukturách. Během migrace je důležité navrhnout, aby nedocházelo k těmto konfliktům, aby nedocházelo k přerušení produkčních systémů hostovaných v cloudu.
• Plánování směrovacích tabulek Pokud konsolidujete sítě nebo datacentra, ujistěte se, že váš projekt obsahuje plán úprav směrovacích tabulek. Zvažte požadavky na směrování mezi datovými centry.

Návrh architektury pro cílovou zónu

Ve fázi připravenosti architektury přechodu na cloud nasadila vaše organizace služby sdílené platformy jako součást přechodu na cílové zóny Azure. V části Připraveno cílové zóny pro migraci jste připravili cílovou zónu pro příjem migrovaných úloh.

Na základě tohoto plánování můžete předpokládat, že jsou splněny následující součásti migrace:

• Hybridní připojení propojuje vaše sítě Azure s místními sítěmi.
• Zařízení zabezpečení sítě, jako je Azure Firewall, zpracovávají kontrolu provozu mimo vaši úlohu.
• Zásady Azure pro vynucení postupů správného řízení, jako jsou požadavky na protokolování, povolené oblasti, nepovolené služby a další ovládací prvky, jsou aktivní.
• Pracovní prostor protokolů služby Azure Monitor pro sdílené protokolování je nastavený ve službě Azure Monitor.
• Navazují se prostředky sdílených identit pro podporu serverů připojených k doméně nebo jiných potřeb identit.

Pokud tyto základní informace o migraci nejsou vytvořené, měla by se vaše organizace okamžitě vrátit do fáze Připraveno, aby tyto potřeby vyřešila. Bez těchto komponent bude vaše migrace pravděpodobně zpožďovat a zpožďovat a být méně úspěšná.

Úloha, kterou navrhujete, má přiřazené předplatné, v ideálním případě prostřednictvím procesu správa předplatného. Předplatné může obsahovat několik úloh nebo jenom jednu úlohu v závislosti na tom, jak vaše organizace dokončila organizaci prostředků pro úlohy. Pokud migrujete úlohu s mnoha aplikačními prostředími, můžete mít dokonce více předplatných na základě pokynů pro aplikační prostředí.

Návrh síťové architektury úloh

Naplánujte nasazení prostředků specifických pro aplikaci do konkrétního předplatného a naplánujte návrh vyhrazené virtuální sítě pro danou úlohu. Další informace najdete v doprovodných materiálech k návrhu síťové architektury. Měli byste se zaměřit zejména na segmentování virtuálních sítí.

Vaše síť pravděpodobně potřebuje prostředky, jako jsou nástroje pro vyrovnávání zatížení a další prostředky pro doručování aplikací. K plánování těchto prostředků v Azure můžete použít průvodce n-úrovňovou architekturou.

Návrh závislostí úloh

Nástroje pro posouzení migrace by vám měly poskytnout způsob analýzy závislostí, jako je analýza závislostí ve službě Azure Migrate a modernizace. Tento nástroj vám pomůže identifikovat vzájemné závislosti mezi servery.

Kromě plánování architektury pro samotnou úlohu možná budete muset zvážit závislosti mezi úlohami. Některé úlohy můžou například vyžadovat častou komunikaci. Pokud ano, plánování vln migrace a závislostí pro tento požadavek pomůže úspěšně provést migraci.

Pokyny můžete použít v Centru architektury Azure, například pro paprskové sítě, a navrhnout tak, jak propojené úlohy po migraci fungují.

Příprava na přijetí důvěrných výpočetních prostředků

Podmnožina úloh s požadavky na suverenitu může vést k používání důvěrných výpočtů. V rámci nasazení suverénní cílové zóny se vytvoří skupiny pro správu důvěrných výpočtů.

V kontextu suverenity vyžaduje použití důvěrných výpočetních prostředků službu Azure Key Vault a klíče spravované zákazníkem jako podpůrnou službu. Další informace najdete v tématu Šifrování pomocí klíčů spravovaných zákazníkem v Microsoft Cloudu pro suverenitu.

Aktualizace počátečního odhadu cloudu

Při dokončení návrhu architektury se znovu obraťte na odhad cloudu, abyste měli jistotu, že jste stále v rámci plánovaného rozpočtu. Při přidávání podpůrných služeb, jako jsou nástroje pro vyrovnávání zatížení nebo zálohy, se můžou náklady měnit. I když můžete k podrobným cvičením správy nákladů použít nástroje, jako jsou obchodní případy ve službě Azure Migrate a Modernizace, měli byste se při úpravě návrhu architektury pravidelně znovu vrátit k odhadům.

Pokud znáte tradiční procesy zajišťování IT, může se odhad prostředků v cloudu zdát cizí. Při přechodu na cloudové technologie se získání posune od modelu pevných strukturovaných kapitálových výdajů na model proměnlivých provozních nákladů. Plánování migrace do cloudu je často prvním výskytem této změny v organizaci nebo it týmu.

V tradičním modelu kapitálových výdajů se IT tým pokusí kombinovat kupní sílu pro více úloh v různých programech. Tento přístup centralizuje fond sdílených IT prostředků, které můžou podporovat každé z těchto řešení. V cloudovém modelu provozních nákladů je možné náklady přímo přiřadit potřebám jednotlivých úloh, týmů nebo obchodních jednotek. Poskytuje organizaci přímější atribuci nákladů interním zákazníkům a obchodním cílům, které podporují. Tento dynamičtější přístup k finanční správě se často označuje jako finanční operace (FinOps). I když FinOps není konkrétním aspektem Azure, může být užitečné mít rozšířené znalosti FinOps. Další informace najdete v tématu Co je FinOps?.

Při návrhu architektury úloh pro migraci můžete pomocí cenové kalkulačky s informacemi o posouzení porozumět ceně celé úlohy.

Po migraci úloh byste také měli dál pracovat na optimalizaci nákladů na úlohy. Další informace o tom, jak mohou organizace zdokonalit své dovednosti správy nákladů, najdete v tématu Zlepšení disciplíny správy nákladů.

Zjištění, kdy změnit architekturu

Migrace se obvykle zaměřují na údržbu stávající architektury a přechod na cloudovou platformu. V některých případech ale možná budete muset změnit architekturu úloh, a to i při migraci. Tento seznam uvádí příklady, kdy je možné, že před migrací budete muset provést změny architektury:

• Placení technických dluhů. Některé stárnoucí úlohy mají vysoký technický dluh. Technický dluh může vést k dlouhodobým výzvám zvýšením nákladů na hostování u libovolného poskytovatele cloudu. Pokud technický dluh nepřirozeně zvyšuje náklady na hostování, měli byste vyhodnotit alternativní architektury.
• Zlepšení spolehlivosti. Standardní směrné plány operací poskytují míru spolehlivosti a obnovení v cloudu. Některé týmy úloh můžou vyžadovat vyšší smlouvy SLA, což může vést ke změnám architektury.
• Úlohy s vysokými náklady. Během migrace byste měli optimalizovat všechny prostředky tak, aby odpovídaly velikosti skutečnému využití. Některé úlohy můžou vyžadovat úpravy architektury, aby se vyřešily konkrétní problémy s náklady.
• Požadavky na výkon Pokud výkon úloh přímo ovlivňuje obchodní vliv, může se vyžadovat další aspekty architektury.
• Zabezpečené aplikace. Požadavky na zabezpečení se obvykle implementují centrálně a obvykle se aplikují na všechny úlohy v portfoliu. Některé úlohy můžou mít specifické požadavky na zabezpečení, které můžou vést ke změnám architektury.

Každé z těchto kritérií slouží jako ukazatel potenciálního překážky migrace. Ve většině případů můžete kritérium vyřešit po migraci úlohy pomocí serverů se správnou velikostí, přidáním nových serverů nebo provedením dalších změn. Pokud se ale některá z těchto kritérií vyžaduje před migrací úlohy, odeberte ji z vlny migrace a vyhodnoťte ji jednotlivě.

Dobře navržená architektura Azure a dobře navržená kontrola Azure vám můžou pomoct vést konverzace s technickým vlastníkem konkrétní úlohy, aby jim pomohly zvážit alternativní možnosti nasazení úlohy.

Úloha se pak v plánu přechodu na cloud klasifikuje jako změna architektury nebo úsilí o modernizaci. Vzhledem k delšímu času, který trvá změna architektury úlohy, zvažte tyto alternativní cesty přechodu na úlohy odděleně od procesu migrace.

Kontrolní seznam architektury

Pomocí následujícího kontrolního seznamu se ujistěte, že se zabýváte důležitými aspekty architektury:

• Ověřte, že vaše architektura splňuje smlouvy SLA pro dostupnost, zotavení po havárii a obnovení dat.
• Ověřte, že jste na návrh sítě použili postupy segmentace sítě.
• Ověřte, že jste plánovali monitorování a zachytávání protokolů.
• Ověřte, že vaše virtuální počítače mají správnou velikost pro skutečnou výpočetní dobu, kterou potřebujete.
• Ověřte, že jsou vaše disky vhodné pro skutečnou velikost a výkon, které potřebujete.
• Ověřte, že jste plánovali služby vyrovnávání zatížení, pokud jsou potřeba. Služby můžou zahrnovat instance Azure Load Balanceru, Aplikace Azure Gateway, Azure Front Door nebo Azure Traffic Manageru.
• Ověřte, že jste plánovali požadavky na suverenitu a důvěrné výpočetní operace, pokud jsou potřeba.

Další krok

Nasazení úloh migrace