Sdílet prostřednictvím

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

  • Článek

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

Důležité

V současnosti používá Azure Resource Manager přibližně 90 % virtuálních počítačů IaaS. Od 28. února 2020 byly klasické virtuální počítače zastaralé a 6. září 2023 budou plně 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í celou řadu úžasných funkcí, je důležité naplánovat cestu k migraci, abyste měli jistotu, že všechno půjde hladce. Čas strávený plánováním zajistí, že při provádění aktivit migrace nenarazíte na problémy.

Poznámka:

Následující doprovodné materiály výrazně přispěl tým Azure Customer Advisory a architekti cloudových řešení, kteří pracují se zákazníky na migraci velkých prostředí. Tento dokument se bude dál aktualizovat, jakmile se objeví nové vzory úspěchu, a proto se čas od času vraťte, abyste zjistili, jestli existují nějaká nová doporučení.

Existují čtyři obecné fáze cesty migrace:

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 Manageru? Co (pokud nějaké) jiné služby Azure chcete použít?
  3. Která aplikace (nebo sady virtuálních počítačů) je součástí migrace?
  4. Které scénáře se podporují s rozhraním API pro migraci? Projděte si nepodporované funkce a konfigurace.
  5. Budou vaše provozní týmy nyní podporovat aplikace nebo virtuální počítače v modelu Classic i Azure Resource Manager?
  6. Jak (pokud vůbec) Azure Resource Manager změní vaše procesy nasazení, správy, monitorování a vytváření sestav virtuálních počítačů? Je potřeba aktualizovat skripty nasazení?
  7. Jaký je plán komunikace pro upozorňování zúčastněných stran (koncoví uživatelé, vlastníci aplikací a vlastníci infrastruktury)?
  8. V závislosti na složitosti prostředí by měla existovat doba údržby, kdy aplikace není k dispozici koncovým uživatelům a vlastníkům aplikací? Pokud ano, jak dlouho?
  9. Jaký je plán školení, který zajistí, aby účastníci měli znalosti a znalosti v Azure Resource Manageru?
  10. Co je plán řízení programů nebo plánu řízení projektů pro migraci?
  11. Jaké jsou časové osy migrace Azure Resource Manageru a dalších souvisejících technologických roadmap? Jsou optimálně sladěné?

Vzory úspěchu

Úspěšní zákazníci mají podrobné plány, kde jsou popsány, zdokumentované a řízené předchozí otázky. Ujistěte se, že plány migrace jsou široce oznámeny sponzorům a zúčastněným stranám. Pořiďte si znalosti o možnostech migrace; projděte si následující sadu dokumentů migrace, která je vysoce doporučená.

Nástrahy, kterým se chcete vyhnout

  • Plánování se nezdařilo. Technologické kroky této migrace jsou prověřené a výsledek je předvídatelný.
  • Předpokládá se, ž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 potenciální výpadek aplikace pro koncové uživatele. Naplánujte dostatečnou vyrovnávací paměť, abyste odpovídajícím způsobem upozornili koncové uživatele na potenciálně nedostupnou dobu aplikace.

Testovací test

Replikace prostředí a testování migrace

Poznámka:

Přesná replikace stávajícího prostředí se provádí pomocí nástroje, který přispěl komunitou, který podpora Microsoftu oficiálně nepodporuje. Je to proto volitelný krok, ale je to nejlepší způsob, jak zjistit problémy bez zásahu do produkčních prostředí. Pokud použití nástroje, který přispěl komunitou, není možnost, přečtěte si níže uvedené doporučení Ověřit/ Připravit/Přerušit dry Run.

Nejlepší způsob, jak zajistit bezproblémovou migraci, je provedení testovacího testu vašeho přesného scénáře (výpočetních prostředků, sítí a úložiště). To vám pomůže zajistit:

  • Zcela samostatné testovací prostředí nebo existující neprodukční prostředí, které se má testovat. Doporučujeme zcela samostatnou testovací prostředí, které lze migrovat opakovaně a může být destruktivní. Níže jsou uvedeny skripty pro shromažďování a hydrataci metadat ze skutečných předplatných.

  • Je vhodné vytvořit testovací prostředí v samostatném předplatném. Důvodem je, že testovací prostředí bude opakovaně odtrhnuto a samostatné izolované předplatné sníží pravděpodobnost, že se omylem odstraní něco skutečného.

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

Vzory úspěchu

V mnoha větších migracích byly zjištěny následující problémy. Nejedná se o vyčerpávající seznam a další podrobnosti najdete v nepodporovaných funkcích a konfiguracích . Tyto technické problémy se vám můžou nebo nemusí vyskytnout, ale pokud je řešíte před pokusem o migraci, zajistíte plynulejší prostředí.

  • Proveďte možnost Ověřit/Připravit/Přerušit suchý běh – je to možná nejdůležitější krok k zajištění úspěchu migrace Classic na Azure Resource Manager. Rozhraní API pro migraci má tři hlavní kroky: Ověření, příprava a potvrzení. Ověřte, že přečte stav klasického prostředí a vrátí výsledek všech problémů. Vzhledem k tomu, že v zásobníku Azure Resource Manageru můžou existovat některé problémy, ověření nezachytí všechno. Další krok v procesu migrace vám pomůže tyto problémy zveřejnit. Příprava přesune metadata z modelu Classic do Azure Resource Manageru, ale ne potvrzení přesunu a neodebere ani nezmění nic na straně Classic. Suchý 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í suchého spuštění je zobrazit všechna metadata v zásobníku Azure Resource Manageru, prozkoumat ho (prostřednictvím kódu programu nebo na portálu) a ověřit, že všechno migruje správně a pracuje s technickými problémy. Poskytne vám také představu o době trvání migrace, abyste mohli odpovídajícím způsobem naplánovat výpadek. Ověření/příprava/přerušení nezpůsobí žádný výpadek uživatele; proto není nerozrušující na využití aplikace.

    • Níže uvedené položky bude potřeba vyřešit před suchým spuštěním, ale test suchého běhu také bezpečně vyprázdní tyto přípravné kroky, pokud se zmešká. Během migrace podniku jsme zjistili, že suchý běh představuje bezpečný a neocenitelný způsob, jak zajistit připravenost na migraci.
    • Při přípravě se řídicí rovina (operace správy Azure) uzamkne pro celou virtuální síť, takže během ověřování nebo přípravy/přerušení není možné provádět žádné změny metadat virtuálních počítačů. Jinak ale nebudou ovlivněny žádné funkce aplikace (RD, využití virtuálního počítače atd.). Uživatelé virtuálních počítačů nebudou vědět, že se spouští suchý běh.

  • Okruhy ExpressRoute a SÍŤ VPN. Brány Express Route s autorizačními odkazy se momentálně 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 model nasazení 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 až 1 až 2 dny, takže odpovídajícím způsobem naplánujte. K hlášení stavu rozšíření virtuálního počítače spuštěných virtuálních počítačů je potřeba funkční agent Azure. Pokud se stav vrátí jako špatný pro spuštěný virtuální počítač, zastaví se migrace. Samotný agent nemusí být v funkčním pořadí pro povolení migrace, ale pokud na virtuálním počítači existují rozšíření, bude pro migraci potřeba jak pracovní agent, tak odchozí připojení k internetu (s DNS).

    • Pokud během migrace dojde ke ztrátě připojení k serveru DNS, je potřeba před přípravou migrace nejprve odebrat všechna rozšíření virtuálních počítačů kromě BGInfo verze 1.* Před přípravou migrace je potřeba nejprve odebrat všechna rozšíření virtuálních počítačů s výjimkou BGInfo v1.* a po migraci z Azure Resource Manageru je potřeba ho znovu přidat zpět na virtuální počítač. To platí jenom pro virtuální počítače, které běží. Pokud jsou virtuální počítače zastavené, není potřeba odebrat rozšíření virtuálních počítačů. Poznámka: Mnoho rozšíření, jako je diagnostika Azure a monitorování v programu Defender pro cloud, se po migraci 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ě. Pro migraci rozšíření virtuálních počítačů do Azure Resource Manageru je potřeba odchozí přístup k internetu (a DNS).

    • Existují dvě verze rozšíření BGInfo: v1 a v2. Pokud byl virtuální počítač vytvořen pomocí webu Azure Portal nebo PowerShellu, bude mít virtuální počítač pravděpodobně rozšíření v1. Toto rozšíření není potřeba odebrat a rozhraní API pro migraci se přeskočí (nemigruje). Pokud se ale klasický virtuální počítač vytvořil pomocí nového webu Azure Portal, pravděpodobně bude mít verzi BGInfo založenou na formátu JSON, kterou je možné migrovat do Azure Resource Manageru za předpokladu, že agent funguje a má odchozí internetový přístup (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 přeinstalujte rozšíření virtuálních počítačů.

    • Možnost nápravy 2. Pokud jsou rozšíření virtuálních počítačů příliš velká, další možností je vypnout nebo uvolnit všechny virtuální počítače před migrací. Migrujte uvolněné virtuální počítače a restartujte je na straně Azure Resource Manageru. Výhodou je, že rozšíření virtuálních počítačů se budou migrovat. Nevýhodou je, že všechny veřejně přístupné virtuální IP adresy budou ztraceny (může to být ne starter) a virtuální počítače se samozřejmě vypnou, což způsobí mnohem větší dopad na pracovní aplikace.

      Poznámka:

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

  • Skupiny dostupnosti – Aby se virtuální síť (virtuální síť) migrovala do Azure Resource Manageru, musí být virtuální počítače s klasickým nasazením (tj. cloudovou službou) v jedné skupině dostupnosti nebo 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 Managerem a zastaví migraci. Kromě toho některé virtuální počítače ve skupině dostupnosti nejsou a některé virtuální počítače nejsou ve skupině dostupnosti. Pokud chcete tento problém vyřešit, budete muset opravit nebo znovu prohodíte cloudovou službu. Plánujte odpovídajícím způsobem, protože to může být časově náročné.

  • Nasazení webových nebo pracovních rolí – Cloudové služby obsahující webové role a role pracovních procesů se nedají migrovat do Azure Resource Manageru. Před zahájením migrace musí být z virtuální sítě nejprve odebrány webové role nebo role pracovního procesu. Typickým řešením je přesunout instance webových rolí nebo rolí pracovního procesu do samostatné klasické virtuální sítě, která je také propojená s okruhem ExpressRoute, nebo migrovat kód do novější služby PaaS App Services (tato diskuze je nad rámec tohoto dokumentu). V bývalém případu opětovného nasazení vytvořte novou klasickou virtuální síť, přesuňte nebo znovu nasaďte role webu nebo pracovního procesu do této nové virtuální sítě a odstraňte nasazení z přesunuté virtuální sítě. Nevyžaduje se žádné změny kódu. Novou funkci peeringu virtuálních sítí je možné použít k vytvoření partnerského vztahu klasické virtuální sítě obsahující role webu nebo pracovního procesu a dalších virtuálních sítí ve stejné oblasti Azure, jako je migrace virtuální sítě (po dokončení migrace virtuálních 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 sankcí za latenci nebo šířku pásma. Vzhledem k přidání partnerského vztahu virtuálních sítí je teď možné nasazení rolí webu nebo pracovního procesu snadno zmírnit a neblokovat migraci do Azure Resource Manageru.

  • Kvóty Azure Resource Manageru – Oblasti Azure mají samostatné kvóty nebo limity pro Classic i Azure Resource Manager. I když ve scénáři migrace se nevyužívají nový hardware (prohodíme stávající virtuální počítače z modelu Classic na Azure Resource Manager), kvóty Azure Resource Manageru musí být ještě před zahájením migrace dostatek kapacity. Níže jsou uvedené hlavní limity, na které jsme narazili, že problémy způsobují. Otevřete lístek podpory kvóty a zvyšte limity.

    Poznámka:

    Tyto limity musí být vyvolány 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 Manageru můžete zkontrolovat pomocí následujících příkazů s nejnovější verzí Azure CLI.

      Výpočty (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

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

      az storage account show-usage

  • Limity omezování rozhraní API Azure Resource Manageru – 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 Manageru narazit na výchozí limity omezování 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 pro zvýšení tohoto limitu pro vaše předplatné.

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

  • Stav virtuálního počítače RoleStateUnknown – Pokud se migrace zastaví kvůli neznámé chybové zprávě 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í (nevyžaduje se žádná náprava) a často se jedná o přechodný typ, který se často projevuje při spuštění virtuálního počítače, zastavení, restartování. Doporučený postup: Po několika minutách zkuste migraci zopakovat.

  • Cluster prostředků infrastruktury neexistuje – V některých případech se některé virtuální počítače nedají migrovat z různých lichých důvodů. Jedním z těchto známých případů je, že se virtuální počítač nedávno vytvořil (během posledního týdne nebo tak) a došlo k vytvoření clusteru Azure, který ještě není vybavený pro úlohy Azure Resource Manageru. Zobrazí se chyba s informací , že cluster prostředků infrastruktury neexistuje a virtuální počítač nejde migrovat. Čekání na několik dní obvykle vyřeší tento konkrétní problém, protože cluster brzy povolí Azure Resource Manager. Jedním z okamžitého alternativního řešení je virtuální stop-deallocate počítač, pak pokračovat v migraci a po migraci spustit zálohování virtuálního počítače v Azure Resource Manageru.

Nástrahy, kterým se chcete vyhnout

  • Nepoužívejte klávesové zkratky a vynechejte migrace ověření/přípravy/přerušení suchého spuštění.
  • Většina, pokud ne všechny, potenciální problémy se objeví během kroků ověření, přípravy nebo přerušení.

Migrace

Technické aspekty a kompromisy

Teď jste připraveni, protože jste probrali 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ší jednotku migrace) se zvýšenou prioritou. Nejprve proveďte jednoduché virtuální sítě a pokračujte v složitějších virtuálních sítích.
  2. Většina zákazníků bude mít neprodukční a produkční prostředí. Naplánovat produkční prostředí jako poslední.
  3. (VOLITELNÉ) V případě neočekávaných problémů naplánujte výpadek údržby s velkým množstvím vyrovnávací paměti.
  4. V případě problémů komunikujte s týmy podpory a v souladu s nimi.

Vzory úspěchu

Technické pokyny z výše uvedené části Testovací testování by se měly zvážit a zmírnit před skutečnou migrací. S dostatečným testováním je migrace ve skutečnosti událostí, která není. V produkčních prostředích může být užitečné mít další podporu, jako je důvěryhodný partner Microsoftu nebo služby Microsoft Premier.

Nástrahy, kterým se chcete vyhnout

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

Mimo migraci

Technické aspekty a kompromisy

Teď, když jste v Azure Resource Manageru, maximalizujte platformu. Přečtěte si přehled Azure Resource Manageru a seznamte se s dalšími výhodami.

Co je potřeba vzít v úvahu:

  • Sdružování migrace s další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 Manageru, jako je šifrování a migrace do Spravované disky.
  • Znovu se můžete vrátit k technickým a obchodním důvodům Azure Resource Manageru; povolte další služby dostupné jenom v Azure Resource Manageru, které platí pro vaše prostředí.
  • Modernizujte své prostředí pomocí služeb PaaS.

Vzory úspěchu

Mějte účelné informace o tom, jaké služby teď chcete povolit v Azure Resource Manageru. Mnoho zákazníků má pro svá prostředí Azure následující přesvědčivé informace:

Nástrahy, kterým se chcete vyhnout

Nezapomeňte, proč jste tuto cestu migrace z Modelu Classic na Azure Resource Manager spustili. Jaké byly původní obchodní důvody? Dosáhli jste obchodního důvodu?

Další kroky