Jak nejlépe migrovat do Azure II

Jak nejlépe migrovat do Azure II

středa , říjen 25, 2023

V prvním článku o migraci do cloudu jsme otevřeli základní otázky k zodpovězení a ukázali si 5 "R" strategií převodu do Azure. Nyní se podíváme podrobně na jednotlivé fáze migrace, na co si dát pozor a jaký software nám k tomu pomůže.

 První fází migrace je zjistit vše co mám v on-prem řešení

Discover - Co všechno mám?

Jaké mám servery, železo, počty CPU a RAM, jaké mi na nich běží operační systémy a jaké aplikace? Prostě a jednoduše si zjistit co všechno mi doma běží. 

Jaký je výkon jednotlivých aplikací? V on-premise světě ve velkém instalujeme hardware, který je předimenzovaný, protože ho chceme na dalších několik let a nevíme, jaké budou nároky aplikace za dva roky. Tudíž koupíme více RAM a CPU, než aktuálně aplikace potřebuje. V cloudu ale můžeme jednoduše přidávat RAM i CPU podle spotřeby a tudíž se můžeme řídit tím, co aplikace v daný moment opravdu využije

Cloud obvykle nedimenzujeme na stejný hardware, na kterým byl nasazený v on-premise světě!

Dalším podstatným bodem jsou závislosti. Musíte si přesně najít a uvědomit si, jaké závislosti má Vaše aplikace a podle toho zvolit jaké komponenty budou migrovány a jaké ne. 

Zvykem je migrovat aplikaci i s její databází kvůli latenci!
Přesunutí "jen" databáze není vždy výhodné

Na obrázku jasně vidíte, že když máte aplikaci a k ní přiřazenou databázi, která ji má nadosah a latence je minimální, tak v rámci zachování ideální latence musíme převést do Azure jak aplikaci tak databázi. 

Další fází je posouzení toho, co mám a jestli to mohu převést do cloudu:

Assess - posouzení

Mohu zdroje, které mám na on-premise a zjistil jsem jaké mám, vůbec převádět do cloudu? možná existují závislosti, které nám bohužel nedovolují převod do cloudu, možná je hardware tak specifický, že nepůjde převést do cloudu. 

Umění posoudit jaký výpočetní výkon (right-sizing) budu potřebovat, je poměrně velká alchymie. Určitě je dobré se zamyslet nad tím, jaký výkon bude potřebovat moje virtuálka. Jde to zjistit z prvního bodu fáze migrace, kde dostanu přesná čísla využití RAM a CPU. Určitě je dobré započítat do toho i sezónnost jako je jeden den v týdnu, každý víkend či páteční večery.  

Na základě závislostí, které jsem objevil v předchozím bodě, mohu vytvořit skupiny zdrojů (grouping), které jsou na sobě závislé a potřebují být u sebe. Jako vhodné řešení je zde PPG (Proximity placement group)

Na základě našeho prvního článku o migraci, kde jsme si vysvětlovali migrační strategie pět "R" můžeme posoudit jaké "R" je nejvhodnější pro naši situaci a zdroje, které chceme převést. 

Vybereme tu nejlepší migrační strategii

Teď už se dostáváme k samotné migraci:

Migrace do cloudu

Nejdříve si stanovíme plán, podle kterého budeme převádět aplikace do cloudu. Bude migrace offline nebo online? To mám bude ovlivňovat downtime. Součástí plánu bude samozřejmě i testování, samotná migrace a následná optimalizace podle toho jakou máte strategii z předchozích fází. Pokud je to strategická aplikace, pak je ideální ji převést a pak začít pracovat na přepsání do cloudového prostředí a začít naplno využívat Azure služby.

Závěr

V dnešním pokračujícím článku jsme se podívali na další fáze migrace a co vše je zapotřebí udělat před samotným převodem. Zjistit si co mám doma, jaký mám hardware a software, posoudit podle toho co převedu, do čeho převedu a na jaký výpočetní výkon a poté převést podle toho jaké si zvolím "R" strategii převodu.

Zatím žádné komentáře
Vyhledávání