Před asi 7 lety se první projekty přesouvaly do našeho cloudu jednoduše a bez komplikací. Obrazy virtuálních strojů se nahrávaly na FTP server nebo se přivážely na pevných discích. Poté se pomocí speciálního importního serveru VM nahrávaly do cloudu.
Pokud není pro klienta problém vypnout virtuálku na den nebo dva (nebo to nejsou jiné možnosti), lze to udělat takto. Ale pokud by měl být prostoje maximálně hodinu, tento způsob se nehodí. Dnes vám povím, jaké nástroje pomohou migraci do cloudu s minimálním prostoje a jak samotný proces migrace u nás probíhá.
Migrace pomocí Veeam Backup and Replication
Veeam Backup and Replication je znám jako nástroj pro vytváření záloh a replik. Používáme ho pro migraci mezi našimi lokalitami a pro převoz klientů z privátní virtualizace k nám do cloudu. Virtuální stroje klienta se replikují na našem vCenter, poté inženýr je přidá do vCloud Director.
Počáteční replikace se provádí na zapnutém virtuálním stroji. V dohodnutém čase se stroj na straně klienta vypne. Replikace se spustí znovu, aby se přenesly změny, které nastaly od první replikace. Poté se virtuální stroj spustí již v našem cloudu.
Obvykle od okamžiku vypnutí stroje na infrastruktuře klienta do okamžiku zapnutí v našem cloudu uběhne maximálně půl hodiny, spíše 15–20 minut.
Na místě klienta zůstává původní virtuální stroj. Pokud se něco pokazí, vždy se lze vrátit a zapnout ho. Pro klienta je tento způsob také výhodný, protože nevyžaduje přítomnost Veeamu.
Případ 1
Klient měl vlastní virtuální infrastrukturu na bázi VMware – 40 VM o velikosti 30 TB. Hardware, na kterém byl rozvinut klastr, již zastarával, a klient se rozhodl nezapojovat se do nákupu nového a přestěhovat se do veřejného cloudu. Požadavek na prostoje kritických systémů činil maximálně hodinu. Jako nástroj byla zvolena Veeam Replication. Výhodou také bylo, že internetový poskytovatel klienta byl přítomen v našem datovém centru, což umožnilo zorganizovat dobrý kanál. Migrace trvala zhruba měsíc, prostoje při přepnutí činily až 30 minut na jednu skupinu virtuálních strojů.
Migrace pomocí Veeam Cloud Connect
Veeam Cloud Connect – nástroj, který pomáhá nastavovat replikaci virtuálních strojů a spouštět repliky v cloudu poskytovatele služeb. Po aktualizaci v roce se objevila možnost replikovat virtuální stroje přímo do vCloud Director. Jedinou podmínkou je, že na straně klienta musí být nasazen vlastní Veeam Backup and Replication verze 9 nebo vyšší. Pokud to shrneme (podrobná verze ), celý proces vypadá následovně.
Ve vCloud Director se vytvoří organizace s potřebnými zdroji a sítěmi. V Veeam Cloud Connect vytvoříme účet, klient se k němu připojuje ze svého Veeam B&R, vybírá poskytovatele DataLine a organizaci, nastavuje úkoly pro replikaci. Kromě toho, že doba odstávky při takové migraci bude v rozmezí 15–20 minut, klient není závislý na technické podpoře poskytovatele a řídí celý proces sám: vytváří úkoly na replikaci, samotnou replikaci, vypíná stroje a spouští jejich start na nové platformě.
Případ 2
Infrastruktura klienta, odkud byla plánována migrace, se nacházela v Bělorusku. Bylo třeba převést 90 VMs s celkovým objemem 27 TB, přičemž internetový kanál byl 100 mbit/s. Pokud bychom dělali zálohu a hned ji nahrávali k nám do cloudu, některé VMs by to trvalo několik dní. Během této doby by na VMs vznikla velká delta, což by mohlo negativně ovlivnit výkon strojů nebo, což je ještě horší, by došlo místo na datastoru. Postupovali jsme následovně: nejprve klient provedl lokální kompletní zálohu a přenesl její kopii k nám do cloudu pomocí Veeam Cloud Connect. Poté vytvořil a přenesl do cloudu inkrementální zálohu. Původní virtuální stroj pokračoval v práci. Po vypnutí VMs klient provedl další inkrement a také přenesl do cloudu. Na své straně jsme nasadili virtuální stroj z kompletní zálohy a poté doplnili dva inkrementy. Tento postup umožnil nakonec minimalizovat odstávku na 2 hodiny při přepnutí na naši platformu.
Migrace pomocí VMware vCloud Availability
V březnu letošního roku společnost VMware uvedla vCloud Availability 3.0, který umožňuje migrovat virtuální stroje mezi různými cloudy (vCloud Director – vCloud Director) a z privátních virtualizačních stání klienta do cloudu (vCenter – vCloud Director). Hlavní výhodou je integrace s rozhraním vCloud Director. To výrazně zjednodušuje proces správy replikace a minimalizuje prostoje při přepínání.
Pomocí tohoto nástroje jsme migrovali jednoho z klientů z našeho moskevského cloudu do našeho cloudu v Petrohradu. Bylo třeba přenést 18 virtuálních strojů s celkovou kapacitou 14 TB. Pro klienta byla vytvořena organizace v petrohradském cloudu a byly zorganizovány potřebné sítě. Následně z rozhraní vCloud Director klient přešel k nastavením vCloud Availability, vytvořil úkoly replikace a ve vhodnou dobu se přepnul na petrohradskou lokalitu. Prostoje při přepínání činily 12 minut.
Schéma migrace mezi cloudy DataLine v Petrohradu a Moskvě.
Ve vCloud Availability existuje mechanismus migrace VM z plochy klienta do našeho cloudu. K tomu se na vCenter klienta nasazuje speciální appliance vCloud Availability. Po jednoduchém nastavení se provede připojení k cloudu a nastavují se úkoly migrace. Klient také samořiditelně řídí celý proces, a čas migrace se minimalizuje.
Schéma migrace virtuálních strojů z privátní instalace do cloudu.
VMware vCloud Availability má mnoho dalších scénářů použití, brzy o nich podrobněji uvedeme v samostatném článku.
Příprava na migraci
Abychom vybrali nástroj a mohli se pustit do migrace, je třeba si ujasnit následující body:
Odkud migrujeme. Pokud migrujete z privátního řešení, máte úplnou svobodu ve výběru nástrojů. Pokud se přestěhujete od poskytovatele, je to složitější. Pravděpodobně nebude možné propojit infrastruktury dvou poskytovatelů a jednoduše přetáhnout VM z důvodu bezpečnostních obav. Někdy poskytovatel, od kterého se klient hodlá odpojit, začne škodit a zdržovat. Přestěhování od poskytovatele lze provést klasicky: prostřednictvím exportu VM na disky a FTP nebo migrací na úrovni aplikace. Název posledního je podmíněný, a vypadá to přibližně tak.
Případ 3
Bylo potřeba migrovat SAP systém klienta od evropského poskytovatele: 34 VM o objemu 54 TB. Klientovi byly přiděleny zdroje v našem cloudu. Mezi námi a infrastrukturou evropského poskytovatele byla zajištěna síťová konektivita. Aplikační servery byly znovu nasazeny s potřebnými konfiguracemi. Velké databáze byly migrovány prostřednictvím nahrání záloh do našeho cloudu. Následně byla nastavena replikace mezi databázemi v našem a původním prostředí. V dohodnutém čase jsme přepnuli na databáze v našem cloudu.
Objem dat a internetový kanál. Obvykle žádáme klienta, aby nám poskytl výstup podle systémů s parametry paměti, CPU a disků. Odhadujeme, zda bude kanál dostatečný pro přímé odesílání replik nebo záloh virtuálních strojů.
Přijatelný výpadek. Pro různé systémy a odpovídající virtuální stroje může být jiný v závislosti na jejich kritičnosti pro business. Obvykle klient přichází s připravenými požadavky na výpadek při migraci, na jejichž základě vybíráme vhodný nástroj a plán migrace. Snažíme se naplánovat finální přepnutí na noční hodiny nebo víkendy, aby i nepatrný výpadek nebyl pro koncové uživatele klienta znatelný.
Na základě těchto dat můžeme vybírat nástroj a přistoupit k samotné migraci. Tady je, co se děje dále.
- Nastavení síťové konektivity. Organizujeme síťovou konektivitu mezi naším cloudem a infrastrukturou klienta. Po této síti budou kopírovány virtuální stroje. Pokud se používá Veeam Backup and Replication, tak to je vyhrazený kanál, méně často – VPN kanál. Pokud Veeam Cloud Connect, tak všechno probíhá přes internet nebo ten stejný vyhrazený kanál.
Poté se nastaví síť pro VM v cloudu. Stroje obvykle migrují skupinově a ne za jeden den. Jakmile byly VM převedeny k nám a spuštěny, musí interagovat se stroji, které ještě zůstávají v původním prostředí.
- Plán migrace. Když je strojů hodně, je rozumné je rozdělit do skupin a přepravovat po partiích. Společně s klientem domlouváme plán, ve kterém specifikujeme, kdy a jaké stroje se přesunou a kdy bude provedena finální replikace a přepnutí na nové prostředí.
- Testovací migrace. Migrace testovací virtuální stroje a ověření, zda je vše správně nastaveno: síťová konektivita mezi lokalitami, dostupnost virtuálního stroje pro stroje na původní lokalitě, práva účtu a další. Takový test pomáhá vyhnout se zpožděním během fáze výrobní migrace.
To je ode mě vše. V komentářích se ptejte a podělte se o své zkušenosti s migrací.
Zdroj: habr.com
