Přechod z modelu Classic na modernizované zotavení po havárii VMware
Tento článek obsahuje informace o architektuře, nezbytné infrastruktuře a nejčastějších dotazech k přesunu replikací virtuálních počítačů VMware nebo fyzických počítačů z klasické na modernizovaný architekturu ochrany. Díky této funkci pro migraci můžete úspěšně přenést replikované položky z konfiguračního serveru do zařízení replikace Azure Site Recovery. Tato migrace je řízena inteligentním mechanismem replikace, který zajišťuje, že se úplná počáteční replikace neprovádí znovu pro nekritické replikované položky a přenesou se pouze rozdílová data.
Poznámka:
Plány obnovení nebudou migrovány a bude nutné je znovu vytvořit v modernizovaném trezoru služby Recovery Services.
Architektura
Komponenty, které se týkají migrace replikovaných položek virtuálního počítače VMware nebo fyzického počítače, jsou shrnuté v následující tabulce:
| Součást | Požadavek |
|---|---|
| Replikované položky v klasickém trezoru služby Recovery Services | Jedna nebo více replikovaných položek chráněných pomocí klasické architektury a konfiguračního serveru, který je v pořádku. Replikovaná položka by měla být v nekritickém stavu a musí se replikovat z místního prostředí do Azure s agentem mobility spuštěným ve verzi 9.50 nebo novější. |
| Konfigurační server používaný replikovanými položkami | Konfigurační server používaný replikovanými položkami by měl být v nekritickém stavu a jeho komponenty by se měly upgradovat na nejnovější verzi (9.50 nebo novější). |
| Trezor služby Recovery Services s modernizovaným prostředím | Trezor služby Recovery Services s modernizovaným prostředím |
| Zařízení pro replikaci Azure Site Recovery v dobrém stavu | Zařízení pro replikaci Azure Site Recovery, které může zjišťovat místní počítače se všemi jeho komponentami upgradovanými na nejnovější verzi (9.50 nebo novější). Přesné požadované verze jsou následující: Procesový server: 9.50 Proxy server: 1.35.8419.34591 Agent recovery services: 2.0.9249.0 Replikační služba: 1.35.8433.24227 |
Požadovaná infrastruktura
Ujistěte se, že pro úspěšný přesun replikované položky platí následující:
- Trezor služby Recovery Services s využitím modernizovaného prostředí
Poznámka:
Všechny nově vytvořené trezory služby Recovery Services budou mít ve výchozím nastavení zapnuté modernizované prostředí. Nemůžete přepnout na klasické prostředí, protože jeho vyřazení již bylo oznámeno.
- Zařízení pro replikaci Azure Site Recovery, které bylo úspěšně zaregistrováno do trezoru, a všechny jeho komponenty jsou v nekritickém stavu.
- Verze zařízení musí být 9.50 nebo novější. Podrobný popis verze najdete tady.
- Podrobnosti o serveru vCenter nebo hostiteli vSphere, kde se nacházejí existující replikované počítače, se přidají do zařízení, aby místní zjišťování bylo úspěšné.
Předpoklady
Příprava infrastruktury
Než přejdete z klasické architektury na modernizované architektury, nezapomeňte provést následující:
- Vytvořte trezor služby Recovery Services a ujistěte se, že se prostředí nepřepnulo na klasický.
- Nasazení zařízení pro replikaci Azure Site Recovery
- Přidejte do zařízení podrobnosti o vCenter Serveru místního počítače, aby bylo možné úspěšně provést zjišťování.
Příprava klasického trezoru služby Recovery Services
Ujistěte se, že pro replikované položky, které plánujete přesunout, následující:
- Replikovaná položka je VMware nebo fyzický počítač replikující přes konfigurační server.
- Replikace se nespravuje s účtem úložiště, ale spíše se spravovaným diskem.
- Replikace probíhá z místního prostředí do Azure a replikovaná položka není ve stavu převzetí služeb při selhání ani ve stavu navrácení služeb po obnovení.
- Replikovaná položka nereplikuje data z Azure do místního prostředí.
- Počáteční replikace neprobíhá a už byla dokončena.
- Replikovaná položka není ve stavu resynchronizace.
- Verze konfiguračního serveru je 9.50 nebo novější a její stav je v nekritickém stavu.
- Konfigurační server má dobrý prezenčních signálů.
- Verze agenta služby Mobility, nainstalovaná na zdrojovém počítači, je 9.50 nebo novější.
- Podporují se trezory služby Recovery Services s povolenou službou MSI.
- Podporují se trezory služby Recovery Services s povolenými privátními koncovými body.
- Stav replikované položky je v nekritickém stavu nebo se úspěšně vytváří jeho body obnovení.
Příprava modernizovaného trezoru služby Recovery Services
Pro modernizované nastavení architektury se ujistěte, že:
- Trezor služby Recovery Services používaný pro modernizované nastavení architektury je ve stejném zeměpisném umístění jako klasický trezor.
- Zařízení pro replikaci Azure Site Recovery se nasadí v místním prostředí s verzí 9.50 nebo novější.
- Zařízení je úspěšně zaregistrované v trezoru.
- Zařízení a všechny jeho komponenty jsou v nekritickém stavu a zařízení má funkční prezenční signál.
- Modernizovaná architektura podporuje verzi vCenter Serveru.
- Do zařízení se přidají podrobnosti o vCenter Serveru zdrojového počítače.
- Modernizovaná architektura podporuje verzi distribuce Linuxu. Další informace.
- Modernizovaná architektura podporuje verzi Windows Serveru. Další informace.
Výpočet celkového času pro přesunutí
Celková doba potřebná k přesunutí replikované položky z klasického trezoru do modernizovaného trezoru závisí na stavu replikace položky a velikosti disku.
| Stav | Čas migrace do modernizovaného trezoru |
|---|---|
| Stav ochrany replikované položky je v pořádku a poslední bod obnovení byl vytvořen před méně než 50 minutami. | Migrace se dokončí za 1 až 2 hodiny. |
| Stav ochrany replikované položky není v pořádku nebo se vytvořil poslední bod obnovení před více než 50 minutami. | Doba migrace se bude lišit a bude záviset na velikosti disku. |
Pokud stav ochrany počítačů není v pořádku, použijte následující vzorec k výpočtu přesného času pro vaše počítače:
Doba migrace = 1 hodina + 45 sekund / GiB
| Konfigurace počítače | Čas migrace |
|---|---|
| Jeden počítač se dvěma disky, oba velikosti 256 GiB | ~ 4 hodiny 15 minut [Oba disky se migrují paralelně] |
| 10 počítačů se dvěma disky, z nichž oba mají velikost 256 GiB | ~ 4 hodiny 15 minut [Všechny virtuální počítače a jejich disky se migrují paralelně] |
| Jeden počítač se čtyřmi disky, velikostí 512 GiB | ~ 7 hodin 30 minut [Oba disky se migrují paralelně] |
| 10 počítačů se čtyřmi disky, všechny velikosti 512 GiB | ~ 7 hodin 30 minut [Všechny virtuální počítače a jejich disky se migrují paralelně] |
Stejný vzorec se používá k výpočtu času migrace a zobrazuje se na portálu.
Definování požadované infrastruktury
Při migraci počítačů z modelu Classic do modernizované architektury budete muset zajistit, aby požadovaná infrastruktura už byla zaregistrovaná v modernizovaném trezoru služby Recovery Services. Informace o velikosti a kapacitě zařízení pro replikaci vám pomůžou definovat požadovanou infrastrukturu.
Obecně platí, že byste měli nastavit stejný počet zařízení replikace jako počet procesových serverů v klasickém trezoru služby Recovery Services. Pokud v klasickém trezoru existoval jeden konfigurační server a čtyři procesové servery, měli byste v modernizovaném trezoru služby Recovery Services nastavit čtyři zařízení replikace.
Ceny
Dokud nevyprší doba uchovávání všech bodů obnovení, poplatky za licenci Site Recovery se budou dál účtovat v klasickém trezoru. Jakmile se všechny body obnovení vyčistí, ceny se také zastaví v klasickém trezoru. Jakmile vyprší doba uchovávání všech bodů obnovení, replikovaná položka se automaticky odebere prostřednictvím operace vymazání aktivované systémem.
Site Recovery začne účtovat licenční poplatek za replikované položky v modernizovaném trezoru až po vygenerování prvního bodu obnovení a starší trezor se vyčistí. Pokud v klasickém trezoru čekají nějaké dny využití bezplatné zkušební verze, předají se do modernizovaného trezoru stejné informace. Ceny se spustí v modernizovaném trezoru až po uplynutí tohoto zkušebního období.
Poznámka:
V jednom okamžiku budou ceny probíhat pouze pomocí jednoho trezoru, a to buď klasického, nebo modernizovaného trezoru.
Faq
Proč mám migrovat počítače do modernizované architektury?
Je důležité si uvědomit, že klasická architektura pro zotavení po havárii bude ukončena, takže uživatelé by se měli ujistit, že přejdou na nejnovější a modernizované verze. Následující tabulka obsahuje porovnání dvou architektur, které vám pomůžou zvolit správnou možnost pro zabezpečení počítačů v případě havárie.
| Klasická architektura | Modernizovaná architektura [Nový] |
|---|---|
| Pro zjišťování místních dat je vyžadováno několik nastavení. | Centrální zjišťování místních datových center pomocí služby zjišťování |
| Velký počet kroků potřebných k počátečnímu onboardingu. | Zjednodušili jsme prostředí onboardingu tím, že automatizuje vytváření artefaktů a zavedli výchozí hodnoty pro snížení požadovaných vstupů. |
| K získání kontextu cloudu využívá ručně stažený soubor. | Zavedli jsme klíč replikace pro získání cloudového kontextu při nastavování zařízení. |
| Velký počet kroků potřebných pro jednoduchý proces povolení replikace. | Zjednodušili jsme možnosti povolení replikace snížením počtu požadovaných vstupů a opětovným definicí jednotlivých oken. |
| Konfigurační server je i nadále místní infrastrukturou s rozsáhlým nastavením pro různé komponenty. | Vylepšené zařízení převodem všech komponent na mikroslužby hostované v Azure To zjednodušuje škálování zařízení, monitorování a řešení potíží. |
| Potřeba procesového serveru se škálováním na více systémů a hlavního cílového serveru v Azure pro počítače s Linuxem je překážkou. | Byla odebrána potřeba udržovat samostatný procesový server a hlavní cílový server. |
| Použili jste statické heslo pro ověřování, které ovlivnilo obchodní požadavky zákazníka při pravidelné obměně hesel. | Zavedli jsme ověřování založené na certifikátech, které je bezpečnější a řeší problémy se zabezpečením zákazníka. |
| Upgrade na aktualizovanou verzi by se měl provést ručně a je to těžkopádný proces. | Zavedli jsme automatické upgrady pro komponenty zařízení i pro Mobility. |
| Konfigurační server nemá vysokou dostupnost a může být vystaven riziku sbalení. | Implementovali vysokou dostupnost zařízení pro zajištění odolnosti. |
| Kořenové přihlašovací údaje by se měly pravidelně aktualizovat, aby se zajistilo prostředí upgradu bez chyb. | Eliminovali jsme požadavek na údržbu kořenových přihlašovacích údajů počítače pro provádění automatických upgradů. |
| Aby se zachovalo připojení, měla by být ke konfiguračnímu serveru přiřazena statická IP adresa. | Zavedli jsme připojení založené na plně kvalifikovaném názvu domény mezi zařízením a místními počítači. |
| Měla by se použít pouze tato virtuální síť, která má povolenou síť VPN typu Site-to-Site nebo ExpressRoute. | Byla odstraněna potřeba udržovat síť VPN typu Site-to-Site nebo ExpressRoute pro zpětnou replikaci. |
| Je potřeba nastavit také nástroj Třetí strany MySQL. | Odebrali jsme závislost na všech nástrojích třetích stran. |
Jaké počítače by se měly migrovat do modernizované architektury?
Všechny virtuální počítače VMware nebo fyzické počítače replikované pomocí konfiguračního serveru by se měly migrovat do modernizované architektury.
Kde by se měl vytvořit modernizovaný trezor služby Recovery Services?
Modernizovaný trezor služby Recovery Services by se měl nacházet ve stejné oblasti a tenantovi jako klasický trezor. Může být součástí libovolného předplatného nebo skupiny prostředků.
Bude replikace pokračovat v průběhu migrace?
Ne, replikace se po určitou dobu přeruší, zatímco probíhá migrace. Během této doby bude poslední vytvořený bod obnovení v klasickém trezoru služby Recovery Services dostupný pro převzetí služeb při selhání. Po dokončení migrace se vygeneruje nový bod obnovení v modernizovaném trezoru služby Recovery Services.
Kdy bude operace migrace označena jako dokončená?
Operace migrace se označí jako dokončená pouze po úspěšném vytvoření prvního bodu obnovení v modernizovaném trezoru služby Recovery Services.
Jaké operace je možné provést z klasického trezoru služby Recovery Services po dokončení migrace?
Po migraci můžete provést převzetí služeb při selhání z klasického trezoru. Operace převzetí služeb při selhání bude dál dostupná v klasickém trezoru, dokud nevyprší platnost bodů obnovení.
Pokud je například doba uchovávání replikované položky 72 hodin (tři dny), nejnovější bod obnovení v klasickém trezoru bude po úspěšné migraci dál dostupný po dobu 72 hodin (tři dny). Po uplynutí stanovené doby azure Site Recovery automaticky aktivuje operaci vyprázdnění replikované položky a provede vyčištění všech přidružených položek úložiště a fakturace.
Co když při migraci dojde k havárii, dojde k havárii počítače?
Všechny replikované položky, u které probíhá migrace, můžou i nadále podporovat operaci převzetí služeb při selhání prostřednictvím klasického trezoru služby Recovery Services, dokud neskončila doba uchovávání pro konečný bod obnovení. Pokud se pokusíte provést operaci převzetí služeb při selhání, bude mít přednost před operací migrace a úloha migrace se přeruší. Abyste měli jistotu, že se replikovaná položka migruje, budete muset operaci migrace aktivovat znovu později.
Poznámka:
Vlastnosti výpočetních prostředků a sítě replikovaných položek je možné během migrace aktualizovat. Změny se ale nemusí replikovat do modernizovaného trezoru služby Recovery Services.
Kolik počítačů můžu migrovat z klasického do modernizovaného trezoru?
Na jednom místě můžete migrovat až 10 počítačů přes portál.
Mám znovu vytvořit virtuální sítě, účty úložiště a zásady replikace, které se mají použít v novém trezoru?
Ne, stejné prostředky, které se dříve používaly, budou také ve výchozím nastavení v modernizovaném trezoru. Ty můžete kdykoli změnit v okně Výpočty a síť replikované položky. Musíte zajistit, aby prostředky měly i nadále požadovaný přístup.
Jak se zásady replikace přesunou do modernizovaného trezoru?
Podle předpokladu vytvoří Site Recovery zásady replikace v modernizovaném trezoru se stejnou konfigurací jako v klasickém trezoru. Takže před přesunem replikované položky se přidružené zásady vytvoří v modernizovaném trezoru. Po aktivaci migrace doporučujeme vyhnout se změnám konfigurace zásad replikace v klasickém trezoru, protože tyto změny se neprojeví v modernizovaném trezoru. Před zahájením procesu migrace je nejlepší provést tyto změny.
Zásady replikace vytvořené v modernizovaném trezoru budou mít v modernizovaném trezoru změněný název. Má předponu název skupiny prostředků a název trezoru modernizovaného trezoru služby Recovery Services. Pokud tedy název zásady byl v klasickém trezoru výchozí zásadou replikace, pak v modernizovaném trezoru je default replication policy contoso-modern-vault_contoso-rgnázev této zásady , vzhledem k názvu trezoru je contoso-modern-vault a skupina prostředků trezoru je contoso-rg.
Můžu během migrace nebo po migraci v klasickém trezoru upravit zásady replikace?
Pokud už replika zásad replikace byla vytvořena v modernizovaném trezoru, všechny změny zásad v klasickém trezoru se do modernizovaného trezoru nebudou šířit.
Pokud tedy existuje 10 replikovaných položek, které se replikují pomocí zásad a rozhodnete se přesunout 5 z nich do modernizovaného prostředí, vytvoří se před zahájením migrace kopie zásady. Před migrací zbývajících pěti položek, pokud se v zásadách v klasickém trezoru provádějí nějaké změny, zásady z modernizovaného trezoru se teď neaktualizují. Tyto změny konfigurace budete muset provést i v modernizovaném trezoru.
Návody migrovat replikované položky, které se nacházejí ve skupině replikace, označované také jako skupiny konzistence více virtuálních počítačů?
Všechny replikované položky, které jsou součástí replikační skupiny, se migrují společně. Všechny můžete vybrat tak, že vyberete skupinu replikace nebo je přeskočíte. Pokud proces migrace u některých počítačů ve skupině replikace selže, ale pro jiné je úspěšný, pro neúspěšné replikované položky se provede vrácení zpět do klasického prostředí a proces migrace se pro tyto položky dá znovu aktivovat.
Můžu migrovat klasické nastavení s veřejným koncovým bodem na modernizované nastavení s privátním koncovým bodem?
Ne, můžete přesunout pouze klasické nastavení zotavení po havárii s veřejným koncovým bodem na modernizované nastavení veřejného koncového bodu. Mějte na paměti, že migrace nesoukromého koncového bodu do privátního koncového bodu se nepodporuje, ale migrace privátního koncového bodu do privátního koncového bodu se podporuje.
Další kroky
Postup přechodu z klasického na modernizované zotavení po havárii VMware