Plánování migrace prostředků IaaS z nasazení Classic do Azure Resource Manageru

  • Článek

Platí pro: ✔️ Virtuální počítače s Linuxem ✔️ a Windows

Důležité

V současnosti přibližně 90 % virtuálních počítačů IaaS používá Azure Resource Manager. Od 28. února 2020 jsou klasické virtuální počítače zastaralé a 6. září 2023 budou zcela vyřazeny. Přečtěte si další informace o tomto vyřazení a o tom, jak vás ovlivňuje.

I když Azure Resource Manager nabízí řadu úžasných funkcí, je důležité naplánovat cestu k migraci, abyste měli jistotu, že vše proběhne hladce. Když strávíte čas plánováním, zajistíte, že při provádění aktivit migrace nebudete mít problémy.

Poznámka

K následujícím pokynům významně přispěl tým zákaznického poradenství Azure a architekti cloudových řešení, kteří se zákazníky pracují na migraci rozsáhlých prostředí. Proto se tento dokument bude i nadále aktualizovat s tím, jak se objevují nové vzory úspěchu, proto se čas od času vraťte a podívejte se, jestli neexistují nějaká nová doporučení.

Cesta k migraci má čtyři obecné fáze:

Fáze migrace

Plánování

Technické aspekty a kompromisy

V závislosti na velikosti technických požadavků, zeměpisných oblastech a provozních postupech můžete zvážit:

  1. Proč je azure Resource Manager pro vaši organizaci žádoucí? Jaké jsou obchodní důvody migrace?
  2. Jaké jsou technické důvody azure Resource Manager? Jaké další služby Azure (pokud nějaké) chcete používat?
  3. Která aplikace (nebo sady virtuálních počítačů) je součástí migrace?
  4. Jaké scénáře rozhraní API pro migraci podporuje? Projděte si nepodporované funkce a konfigurace.
  5. Budou teď vaše provozní týmy podporovat aplikace/virtuální počítače v classic i azure Resource Manager?
  6. Jak (pokud vůbec) Azure Resource Manager mění procesy nasazení, správy, monitorování a vytváření sestav virtuálních počítačů? Je potřeba aktualizovat skripty nasazení?
  7. Jaký je komunikační plán, který upozorní účastníky (koncové uživatele, vlastníky aplikací a vlastníky infrastruktury)?
  8. Měla by v závislosti na složitosti prostředí existovat období údržby, kdy bude aplikace nedostupná koncovým uživatelům a vlastníkům aplikace? Pokud ano, jak dlouho?
  9. Jaký je plán školení, který zajistí, aby účastníci měli znalosti a dovednosti v Azure Resource Manager?
  10. Jaký je plán řízení programu nebo řízení projektů pro migraci?
  11. Jaké jsou časové osy migrace azure Resource Manager a další související technologické roadmapy? Jsou optimálně zarovnané?

Vzory úspěchu

Úspěšní zákazníci mají podrobné plány, na kterých se probírají, dokumentují a řídí předchozí otázky. Zajistěte, aby byly plány migrace široce sděleny sponzorům a zúčastněným stranám. Vybavit se znalostmi o možnostech migrace; Doporučujeme si přečíst následující sadu dokumentů k migraci.

Nástrahy, kterým je třeba se vyhnout

  • Nepovedlo se naplánovat. Technologické kroky této migrace jsou prověřené a výsledek je předvídatelný.
  • Předpoklad, že rozhraní API pro migraci podporované platformou bude zohledňovat všechny scénáře. Přečtěte si nepodporované funkce a konfigurace a seznamte se s podporovanými scénáři.
  • Neplánuje se potenciální výpadek aplikace pro koncové uživatele. Naplánujte dostatek vyrovnávací paměti, abyste odpovídajícím způsobem upozornili koncové uživatele na potenciálně nedostupný čas aplikace.

Laboratorní test

Replikace prostředí a testovací migrace

Poznámka

Přesná replikace stávajícího prostředí se provádí pomocí nástroje, kterým přispěla komunita, který podpora Microsoftu oficiálně nepodporuje. Proto se jedná o volitelný krok, ale je to nejlepší způsob, jak zjistit problémy bez zásahu do produkčního prostředí. Pokud není možné použít nástroj, který přispívá komunitou, přečtěte si níže uvedené doporučení k ověření, přípravě nebo přerušení zkušebního běhu.

Provedení laboratorního testování konkrétního scénáře (výpočetních prostředků, sítí a úložiště) je nejlepším způsobem, jak zajistit plynulou migraci. To vám pomůže zajistit:

  • Zcela oddělené testovací prostředí nebo existující neprodukční prostředí k testování. Doporučujeme zcela samostatné testovací prostředí, které je možné migrovat opakovaně a destruktivně upravit. Níže jsou uvedeny skripty pro shromažďování nebo hydrataci metadat ze skutečných předplatných.

  • Testovací prostředí je vhodné vytvořit v samostatném předplatném. Důvodem je to, že testovací prostředí bude opakovaně vyřazeno a samostatné izolované předplatné sníží šanci, že dojde k náhodnému odstranění něčeho skutečného.

    Toho lze dosáhnout pomocí nástroje AsmMetadataParser. Další informace o tomto nástroji najdete tady.

Vzory úspěchu

Následující problémy byly zjištěny při mnoha větších migracích. Tento seznam není vyčerpávající a podrobnější informace najdete v nepodporovaných funkcích a konfiguracích . K těmto technickým problémům může dojít, ale pokud je vyřešíte před pokusem o migraci, zajistíte tím plynulejší prostředí.

  • Provést ověření, přípravu nebo přerušení zkušebního spuštění – toto je možná nejdůležitější krok k zajištění úspěšné migrace z modelu Classic do Azure Resource Manager. Rozhraní API pro migraci má tři hlavní kroky: ověření, přípravu a potvrzení. Funkce Validate přečte stav klasického prostředí a vrátí výsledek všech problémů. Vzhledem k tomu, že ve službě Azure Resource Manager stack může docházet k určitým problémům, funkce Validate nezachytí všechno. Dalším krokem v procesu migrace je příprava, který vám pomůže tyto problémy odhalit. Příprava přesune metadata z modelu Classic do Azure Resource Manager, ale nepotvrdí přesun a neodebere ani nezmění nic na straně Classic. Zkušební běh zahrnuje přípravu migrace a následné přerušení (ne potvrzení) přípravy migrací. Cílem ověření, přípravy nebo přerušení zkušebního spuštění je zobrazit všechna metadata ve službě Azure Resource Manager stack, prozkoumat je (programově nebo na portálu) a ověřit, že se všechno správně migruje a řeší technické problémy. Získáte také představu o době trvání migrace, abyste mohli odpovídajícím způsobem naplánovat výpadek. Ověření, příprava nebo přerušení nezpůsobí žádný výpadek uživatele. proto je nedisruptivní vzhledem k používání aplikace.

    • Následující položky bude potřeba vyřešit před zkušebním během, ale test zkušebního běhu bezpečně vyprázdní i tyto přípravné kroky, pokud je vynecháte. Během podnikové migrace jsme zjistili, že zkušební běh je bezpečným a neocenitelným způsobem, jak zajistit připravenost na migraci.
    • Po spuštění přípravy se řídicí rovina (operace správy Azure) uzamkne pro celou virtuální síť, takže během ověřování, přípravy nebo přerušení nebude možné provádět žádné změny metadat virtuálního počítače. V opačném případě ale nebude mít vliv žádná funkce aplikace (VZDÁLENÁ PLOCHA, využití virtuálních počítačů atd.). Uživatelé virtuálních počítačů nebudou vědět, že se provádí zkušební běh.

  • Okruhy ExpressRoute a síť VPN. Brány Express Route s autorizačními odkazy se v současné době nedají migrovat bez výpadků. Alternativní řešení najdete v tématu Migrace okruhů ExpressRoute a přidružených virtuálních sítí z modelu nasazení Classic na Resource Manager.

  • Rozšíření virtuálních počítačů – Rozšíření virtuálních počítačů jsou potenciálně jedním z největších překážek migrace spuštěných virtuálních počítačů. Náprava rozšíření virtuálních počítačů může trvat více než 1 až 2 dny, proto podle toho naplánujte. K hlášení stavu rozšíření virtuálních počítačů spuštěných virtuálních počítačů je potřeba funkční agent Azure. Pokud se stav spuštěného virtuálního počítače vrátí jako špatný, zastaví se tím migrace. Samotný agent nemusí být v funkčním stavu, aby bylo možné migraci povolit, ale pokud na virtuálním počítači existují rozšíření, bude k migraci potřeba jak funkční agent, tak i odchozí připojení k internetu (s DNS).

    • Pokud během migrace dojde ke ztrátě připojení k serveru DNS, všechna rozšíření virtuálních počítačů s výjimkou BGInfo v1. * je potřeba před přípravou migrace nejprve z každého virtuálního počítače odebrat a následně je po migraci do Azure Resource Manager znovu přidat. To platí jenom pro virtuální počítače, které jsou spuštěné. Pokud se virtuální počítače zastaví, rozšíření virtuálních počítačů není potřeba odebírat. Poznámka: Řada rozšíření, jako je diagnostika Azure a monitorování Defenderu pro cloud, se po migraci sama přeinstaluje, takže jejich odebrání není problém.

    • Kromě toho se ujistěte, že skupiny zabezpečení sítě neomezují odchozí přístup k internetu. K tomu může dojít u některých konfigurací skupin zabezpečení sítě. K migraci rozšíření virtuálních počítačů do Azure Resource Manager je potřeba odchozí internetový přístup (a DNS).

    • Existují dvě verze rozšíření BGInfo: v1 a v2. Pokud byl virtuální počítač vytvořen pomocí Azure Portal nebo PowerShellu, bude mít pravděpodobně rozšíření v1. Toto rozšíření není potřeba odebírat a rozhraní API pro migraci ho přeskočí (nemigruje). Pokud se ale klasický virtuální počítač vytvořil pomocí nového Azure Portal, bude mít pravděpodobně verzi BGInfo v2 založenou na formátu JSON, kterou je možné migrovat do Azure Resource Manager za předpokladu, že agent funguje a má odchozí přístup k internetu (a DNS).

    • Možnost nápravy 1. Pokud víte, že vaše virtuální počítače nebudou mít odchozí přístup k internetu, funkční službu DNS a funkční agenty Azure na virtuálních počítačích, odinstalujte všechna rozšíření virtuálních počítačů v rámci migrace před přípravou a po migraci rozšíření virtuálních počítačů znovu nainstalujte.

    • Možnost nápravy 2. Pokud jsou rozšíření virtuálních počítačů příliš velká, další možností je před migrací vypnout nebo uvolnit všechny virtuální počítače. Migrujte uvolněné virtuální počítače a restartujte je na straně Azure Resource Manager. Výhodou je, že rozšíření virtuálních počítačů se budou migrovat. Nevýhodou je, že dojde ke ztrátě všech veřejně přístupných virtuálních IP adres (to nemusí být počáteční) a samozřejmě dojde k vypnutí virtuálních počítačů, což bude mít mnohem větší dopad na fungující aplikace.

      Poznámka

      Pokud je pro spuštěné migrované virtuální počítače nakonfigurovaná Microsoft Defender pro zásady cloudu, je potřeba před odebráním rozšíření zastavit zásady zabezpečení, jinak se rozšíření monitorování zabezpečení po odebrání na virtuálním počítači automaticky přeinstaluje.

  • Skupiny dostupnosti – Aby se virtuální síť (vNet) migrovala do Azure Resource Manager, musí nasazení Classic (tj. cloudová služba) obsahovat všechny virtuální počítače v jedné skupině dostupnosti nebo všechny virtuální počítače nesmí být v žádné skupině dostupnosti. Více než jedna skupina dostupnosti v cloudové službě není kompatibilní s Azure Resource Manager a zastaví migraci. Kromě toho nemůžou být některé virtuální počítače ve skupině dostupnosti a některé virtuální počítače ve skupině dostupnosti nejsou. Pokud chcete tento problém vyřešit, musíte cloudovou službu opravit nebo přemístit. Podle toho naplánujte, protože to může být časově náročné.

  • Nasazení webových rolí nebo rolí pracovního procesu – Cloud Services obsahující webové role a role pracovního procesu nejde migrovat do Azure Resource Manager. Než bude možné zahájit migraci, je potřeba nejprve z virtuální sítě odebrat webové role nebo role pracovního procesu. Typickým řešením je přesun instancí webových rolí nebo rolí pracovního procesu do samostatné klasické virtuální sítě, která je také propojená s okruhem ExpressRoute, nebo migrace kódu do novějších služeb PaaS App Services (tato diskuze je nad rámec tohoto dokumentu). V případě předchozího opětovného nasazení vytvořte novou klasickou virtuální síť, přesuňte nebo znovu nasaďte webové role nebo role pracovního procesu do nové virtuální sítě a pak odstraňte nasazení z přesouvané virtuální sítě. Nevyžadují se žádné změny kódu. Novou funkci Virtual Network Peering je možné použít ke vzájemnému propojení klasické virtuální sítě, která obsahuje webové role nebo role pracovního procesu, a dalších virtuálních sítí ve stejné oblasti Azure, jako je migrovaná virtuální síť (po dokončení migrace virtuální sítě, protože partnerské virtuální sítě není možné migrovat), a poskytuje tak stejné funkce bez ztráty výkonu a bez omezení latence nebo šířky pásma. Vzhledem k přidání Virtual Network peeringu je teď možné nasazení webových rolí nebo rolí pracovního procesu snadno zmírnit a neblokovat migraci do Azure Resource Manager.

  • Kvóty Azure Resource Manager – oblasti Azure mají samostatné kvóty nebo limity pro Azure Resource Manager i Classic. I když se ve scénáři migrace nespotřebovává nový hardware (prohodíme stávající virtuální počítače z Modelu Classic do Azure Resource Manager), musí být kvóty Azure Resource Manager stále ještě před zahájením migrace zavedeny s dostatečnou kapacitou. Níže jsou uvedené hlavní limity, u které jsme zaznamenali, že způsobují problémy. Otevřete lístek podpory kvóty a zvyšte limity.

    Poznámka

    Tato omezení je potřeba zvýšit ve stejné oblasti, ve které se má migrovat vaše aktuální prostředí.

    • Síťová rozhraní

    • Nástroje pro vyrovnávání zatížení

    • Veřejné IP adresy

    • Statické veřejné IP adresy

    • Cores

    • Network Security Groups (Skupiny zabezpečení sítě)

    • Směrovací tabulky

      Aktuální kvóty Azure Resource Manager můžete zkontrolovat pomocí následujících příkazů s nejnovější verzí Azure CLI.

      Compute(jádra, skupiny dostupnosti)

      az vm list-usage -l <azure-region> -o jsonc

      Síť(virtuální sítě, statické veřejné IP adresy, veřejné IP adresy, skupiny zabezpečení sítě, síťová rozhraní, nástroje pro vyrovnávání zatížení, směrovací tabulky)

      az network list-usages -l <azure-region> -o jsonc

      Storage(účet úložiště)

      az storage account show-usage

  • Limity omezování rozhraní API Resource Manager Azure – Pokud máte dostatečně velké prostředí (např. > 400 virtuálních počítačů ve virtuální síti), můžete v Azure Resource Manager narazit na výchozí limity omezení pro rozhraní API pro zápisy (aktuálně 1200 zápisů za hodinu). Před zahájením migrace byste měli vytvořit lístek podpory a zvýšit tento limit pro vaše předplatné.

  • Stav virtuálního počítače s vypršením časového limitu zřizování – pokud u některého virtuálního počítače došlo k vypršení časového limitu zřizování, je potřeba tento problém vyřešit před migrací. Jediný způsob, jak to udělat, je výpadek zrušením zřízení nebo opětovným zřízením virtuálního počítače (odstranění, zachování disku a opětovné vytvoření virtuálního počítače).

  • RoleStateUnknown Stav virtuálního počítače – Pokud se migrace zastaví kvůli chybové zprávě o neznámém stavu role , zkontrolujte virtuální počítač pomocí portálu a ujistěte se, že je spuštěný. Tato chyba obvykle po několika minutách zmizí sama o sobě (nevyžaduje se žádná náprava) a často se jedná o přechodný typ, ke kterém často dochází během operací spuštění, zastavení a restartování virtuálního počítače. Doporučený postup: Zkuste migraci znovu po několika minutách.

  • Cluster prostředků infrastruktury neexistuje – V některých případech některé virtuální počítače není možné migrovat z různých podivných důvodů. Jedním z těchto známých případů je to, že se virtuální počítač nedávno vytvořil (během posledního týdne) a přistál v clusteru Azure, který ještě není vybavený pro úlohy Azure Resource Manager. Zobrazí se chyba s informací, že cluster prostředků infrastruktury neexistuje a virtuální počítač nejde migrovat. Po několika dnech se obvykle tento konkrétní problém vyřeší, protože cluster brzy povolí Azure Resource Manager. Jedním z okamžitých alternativních řešení je však použít stop-deallocate virtuální počítač, pak pokračovat v migraci a po migraci spustit virtuální počítač v Azure Resource Manager.

Nástrahy, kterým je třeba se vyhnout

  • Nepoužívejte klávesové zkratky a vynechejte migrace ověření, přípravy nebo přerušení zkušebního běhu.
  • Většina potenciálních problémů, pokud ne všechny, se objeví během postupu ověření, přípravy nebo přerušení.

Migrace

Technické aspekty a kompromisy

Teď jste připraveni, protože jste si prošli známé problémy s vaším prostředím.

U skutečných migrací můžete zvážit:

  1. Naplánujte a naplánujte virtuální síť (nejmenší jednotka migrace) se zvýšenou prioritou. Nejprve proveďte jednoduché virtuální sítě a pokračujte ve složitějšíchvirtuálních
  2. Většina zákazníků bude mít neprodukční a produkční prostředí. Naplánujte výrobu na poslední.
  3. (VOLITELNÉ) Naplánujte výpadek údržby s velkým množstvím vyrovnávací paměti pro případ, že dojde k neočekávaným problémům.
  4. Komunikujte se svými týmy podpory a vyrovnejte se s nimi v případě, že dojde k problémům.

Vzory úspěchu

Technické pokyny uvedené výše v části Testovací testování byste měli zvážit a zmírnit před skutečnou migrací. Při odpovídajícím testování je migrace ve skutečnosti událostí, která není událostí. Pro produkční prostředí může být užitečné mít další podporu, například důvěryhodného partnera Microsoftu nebo služby Microsoft Premier.

Nástrahy, kterým je třeba se vyhnout

Úplné testování může způsobit problémy a zpoždění migrace.

Nad rámec migrace

Technické aspekty a kompromisy

Teď, když jste v Azure Resource Manager, maximalizujte platformu. Přečtěte si přehled azure Resource Manager, kde se dozvíte o dalších výhodách.

Co je potřeba zvážit:

  • Sdružování migrace s jinými aktivitami. Většina zákazníků se rozhodne pro časové období údržby aplikace. Pokud ano, můžete tento výpadek použít k povolení dalších funkcí Azure Resource Manager, jako je šifrování a migrace do Spravované disky.
  • Projděte si technické a obchodní důvody pro Azure Resource Manager; povolte další služby dostupné pouze v Azure Resource Manager, které platí pro vaše prostředí.
  • Modernizujte své prostředí pomocí služeb PaaS.

Vzory úspěchu

Cílevědomě zjistěte, jaké služby teď chcete v Azure Resource Manager povolit. Pro mnoho zákazníků jsou následující možnosti pro jejich prostředí Azure zajímavé:

Nástrahy, kterým je třeba se vyhnout

Vzpomeňte si, proč jste zahájili tuto cestu migrace classic do Azure Resource Manager. Jaké byly původní obchodní důvody? Dosáhli jste obchodního důvodu?

Další kroky