Umbes 7 aastat tagasi kolisid esimesed projektid meie pilve lihtsalt ja probleemideta. Virtuaalmasinate pildid laaditi FTP-serverisse või toodi kohale kõvaketastel. Seejärel laaditi VM-id pilvesse spetsiaalse impordiserveri kaudu.
Kui kliendile ei ole probleemiks virtuaalmasina väljalülitamine päevaks või kaheks (või pole teisigi võimalusi), siis võib see ka nii olla. Kuid kui seiskamine peab olema maksimaalselt tunni, siis selline meetod ei sobi. Täna räägin, millised tööriistad aitavad migreerida pilve minimaalsete seisuaegadega ja kuidas meie migreerimisprotsess ise toimub.
Migreerimine Veeam Backup and Replication abil
Veeam Backup and Replication on tuntud kui vahend varukoopiate ja replikate loomiseks. Me kasutame seda migreerimiseks meie platvormide vahel ja klientide viimiseks privaatvirtualiseerimisest meie pilve. Klientide virtuaalmasinad replitseeritakse meie vCenterisse ja seejärel lisab insener need vCloud Directorisse.
Esialgne replikatsioon toimub sisse lülitatud virtuaalmasinal. Koos kokkulepitud ajal klientpoolne masin välja lülitatakse. Replikatsioon käivitatakse veel kord, et edastada muudatused, mis on toimunud alates esimesest replikatsioonist. Pärast seda käivitab virtuaalmasin juba meie pilves.
Tavaliselt ei kesta aeg masinast klientinfrastruktuuris välja lülitamisest meie pilves sisselülitamiseni rohkem kui pool tundi, pigem 15–20 minutit.
Samuti jääb kliendi platvormile algne virtuaalmasin. Kui äkki midagi läheb valesti, saab alati tagasi minna ja selle sisse lülitada. Kliendi jaoks on see meetod mugav, kuna see ei nõua Veeami olemasolu.
Juhtum 1
Kliendil oli oma virtuaalne infrastruktuur VMware baasil – 40 VM-i mahuga 30 TB. Varustus, millel klaster oli käitatud, oli juba vananenud ning klient otsustas, et ei hakka uut seadme ostmisega vaeva nägema ning kolib avalikku pilve. Kriitiliste süsteemide seisuaegade nõue oli mitte üle tunni. Vahendina valiti Veeam Replication. Plussiks oli see, et kliendi internetteenuse pakkuja oli meie andmekeskuses, mis võimaldas korraldada hea kanali. Migratsioon kestis umbes kuu, vahetuse seisuaeg oli kuni 30 minutit ühele virtuaalmasinate grupile.
Migreerimine Veeam Cloud Connect abil
Veeam Cloud Connect – tööriist, mis aitab seadistada virtuaalmasinate replikatsiooni ja käivitada replikaid teenusepakkuja pilves. Pärast uuendust aastal ilmnes võimalus replikaate edastada otse vCloud Directorisse. Ainus tingimus on, et kliendi poolel peab olema seadistatud oma Veeam Backup and Replication, mis ei tohi olla madalam kui versioon 9. Lühidalt (täpsem versioon ), siis kogu protsess näeb välja järgmine.
vCloud Directoris luuakse organisatsioon vajalike ressursside ja võrkudega. Veeam Cloud Connectis loome konto, klient ühendub sellele oma Veeam B&R-st, valib DataLine teenusepakkuja ja organisatsiooni ning seadistab replikatsiooniülesanded. Lisaks sellele, et sellisel kolimisel on seisak aega 15–20 minuti piires, ei sõltu klient teenusepakkuja tehnilisest toest ning juhib kogu protsessi iseseisvalt: loob replikatsiooniülesandeid, teostab replikatsiooni, lõpetab masinad ja käivitab need uuel platsil.
Juhtum 2
Kliendi infrastruktuur, kust oli kavandatud migratsioon, asus Valgevenes. Vajalik oli üle tuua 90 VM kokku 27 TB ulatuses, samas kui Interneti kanal oli 100 Mbit/s. Kui teha varukoopia ja kohe laadida see meie pilve, tooks see mõne VM jaoks aega mitu päeva. Selle aja jooksul oleks VM-il kasvanud suur delta, mis oleks juba võinud negatiivselt mõjutada masinate jõudlust või, veel halvem, ruum datastores oleks otsa saanud. Käitusime järgmiselt: esmalt tegi klient lokaalset täieliku varukoopia ja edastas selle koopia meie pilve Veeam Cloud Connecti kaudu. Siis tegi ja edastas pilve inkrementaali. Algne virtuaalmasin jätkas tööd. Pärast VM-i väljalülitamist tegi klient veel ühe inkrementaali ja edastas selle samuti pilve. Meie poolel seadistasime virtuaalmasina täielikust varukoopiast, seejärel edastasime sellele kaks inkrementaali. Selline skeem võimaldas lõpuks minimeerida seisakut kuni 2 tunni võrra meie platsile ülemisel.
Migratsioon VMware vCloud Availability abil
Sel aastal märtsis vabastas VMware vCloud Availability 3.0, mis võimaldab migreerida virtuaalmasinaid erinevate pilvede vahel (vCloud Director – vCloud Director) ja klientide privaatsetelt virtualiseerimise seadmetelt pilve (vCenter – vCloud Director). Peamine mugavus on integreerimine vCloud Director'i liidesega. See lihtsustab replikatsiooni haldamise protsessi ja vähendab seisaku aega ülemineku ajal minimaalselt.
Selle tööriista abil migreerisime ühe meie kliendi meie Moskva pilvest meie Peterburi pilve. Pidi üle viima 18 virtuaalmasinat kokku 14 TB mahuga. Kliendile loodi Peterburi pilves organisatsioon ja korraldati vajalikud võrgud. Edasi liikus klient vCloud Director'i liidestest vCloud Availability seadete juurde, lõi replikatsiooniülesandeid ja kasutas soovitud ajal ülemineku Peterburi keskkonda. Ülemineku seisakuks oli 12 minutit.
Migrateerimise skeem DataLine'i pilvede vahel Peterburis ja Moskvas.
vCloud Availability's on mehhanism VM-ide migreerimiseks kliendi saidilt meie pilve. Selleks paigaldatakse kliendi vCenter'is spetsiaalne vCloud Availability seadmed. Pärast lihtsat seadistamist toimub ühendamine pilve ja seadistatakse migreerimise ülesanded. Klient haldab kogu protsessi ise ja migreerimise aeg jääb minimaalseks.
Skeem virtuaalmasinate migreerimiseks privaatinstalatsioonist pilve.
VMware vCloud Availability'l on palju muid kasutusskeeme, varsti tutvustame neist mõnda eraldi artiklis.
Valmistumine migreerimiseks
Tööriista valimiseks ja migreerimiseks tuleb otsustada järgmiste punktide üle:
Kust migreerime. Kui migreerite privaatlahenduselt, on teil täielik vabadus tööriistade valikul. Kui lahkute teenusepakkujalt, on see keerulisem. Tõenäoliselt ei õnnestu kahe teenusepakkuja infrastruktuuride sidumine ja lihtsalt VM-i tõstmine turvakaalutlustel. Mõnikord hakkab teenusepakkuja, kellelt klient kavatseb loobuda, isegi lohisema ja venitama aega. Teenusepakkujalt lahkumine võib toimuda vanamoodsalt: VM-i väljavõtmise ja FTP kaudu või migreerimisel rakenduse tasandil. Viimane on tinglik ja näeb välja ligikaudu nii.
Juhtum 3
Kliendi SAP-süsteemi migreerimine Euroopa teenusepakkujalt: 34 virtuaalmasinat mahuga 54 TB. Kliendile eraldati ressursid meie pilves. Meie ja Euroopa teenusepakkuja infrastruktuuri vahel korraldati võrguside. Rakendusserverid seadistati uuesti koos vajalike seadistustega. Suured andmebaasid migreeriti varukoopiate laadimise kaudu meie pilve. Edasi seadistati replikatsioon meie ja algsete andmebaaside vahel. Kokku lepitud ajal lülitasime andmebaasid meie pilve.
Andmemahu ja internetiühendus. Küsimus on tavaliselt, et klient esitaks süsteemide väljaanded, millel on mälu, CPU ja ketaste parameetrid. Hindame, kas kanal on piisav, et otse replikaid või virtuaalmasinate varukoopiaid saata.
Lubatud seiskumine. Erinevate süsteemide ja vastavalt virtuaalmasinate puhul võib see sõltuda nende ärikriitilisusest. Tüüpiliselt tuleb klient koos valmis nõudmistega seiskumise osas migreerimise ajal, ja selle alusel valime sobiva tööriista ja migreerimise plaani. Püüame planeerida lõpliku ülemineku öisele ajale või nädalavahetustele, et isegi väike seiskumine ei oleks lõppkasutajatele nähtav.
Selle teabe põhjal saab valida tööriista ja alustada migreerimist. Siin toimub edasi.
- Võrguside seadistamine. Korraldame võrguside meie pilve ja kliendi infrastruktuuri vahel. Selle võrguga kopeeritakse virtuaalmasinad. Kui kasutatakse Veeam Backup and Replication, siis on see eraldi kanal, harvem – VPN-kanal. Kui Veeam Cloud Connect, siis kõik käib interneti kaudu või sama eraldi kanali kaudu.
Siis seadistatakse pilves virtuaalmasinate jaoks võrk. Masinad liiguvad tavaliselt gruppides ja mitte ühe päeva jooksul. Pärast seda, kui virtuaalmasinad on meie juurde üle viidud ja käivitatud, peavad nad suhtlema masinatega, mis jäävad endiselt algsesse asukohta.
- Migreerimise ajakava. Kuna masinate arv on suur, on mõistlik jagada need rühmadesse ja transportida parteid. Koos kliendiga lepime kokku plaani, milles määratleme, millal ja millised masinad liiguvad ning millal toimub lõplik replikatsioon ja üleminek uude asukohta.
- Katsetus migreerimine. Migrime testvirtual masina ja kontrollime, kas kõik on õigesti seadistatud: võrguühendus platvormide vahel, virtuaalse masina kättesaadavus algses platvormis, kontoõigused ja muu. Selline test aitab vältida takistusi tootmisfaasi migreerimisel.
Sellega on mul kõik. Kommentaarides esitage küsimusi ja rääkige oma migreerimiskogemustest.
Allikas: habr.com
