Umbes 7 aastat tagasi kolisid esimesed projektid meie pilvesse lihtsalt ja vaevatult. Virtuaalmasinate kujutised laaditi FTP-serverisse või toodi kõvaketastel. Seejärel laaditi VM-d pilve spetsiaalse impordi serveri kaudu.
Kui kliendi jaoks ei ole probleem virtuaalmasinat päevaks või kaheks välja lülitada (või pole muid võimalusi), siis saab ka nii. Kuid kui seisak ei tohi olla pikem kui tund, siis selline meetod ei sobi. Täna räägin, millised tööriistad aitavad pilve migreerimise protsessis minimaalset seisakut saavutada ja kuidas meie migratsiooniprotsess ise töötab.
Migreerimine Veeam Backup and Replication abil
Veeam Backup and Replication on tuntud kui tööriist varukoopiate ja replikatsioonide loomiseks. Kasutame seda oma platvormide vahel migreerimiseks ja klientide viimiseks privaatvirtualiseerimiselt meie pilve. Kliendi virtuaalmasinad replitseeritakse meie vCenterisse, seejärel lisab insener need vCloud Directori.
Esialgne replikatsioon toimub sisse lülitatud virtuaalmasinas. Kindlaksmääratud ajal lülitub masin kliendi poole välja. Replikatsioon käivitub uuesti, et üle kanda muudatused, mis on toimunud alates esimesest replikatsioonist. Pärast seda alustab virtuaalmasin tööd juba meie pilves.
Tavaliselt ei pruugi ajavahemik masina väljalülitamise hetkest kliendi infrastruktuuris kuni selle sisselülitamiseni meie pilves ületada pool tundi, pigem 15–20 minutit.
Kliendi platvormil jääb alles algne virtuaalmasin. Kui midagi peaks valesti minema, saab alati tagasi pöörduda ja selle sisse lülitada. Kliendile on see meetod kasulik ka seetõttu, et see ei nõua Veeami olemasolu.
Juhtum 1
Kliendil oli oma virtuaalne infrastruktuur VMware baasil – 40 virtuaalmasinat 30 TB mahuga. Varustus, millel klaster oli loodud, oli juba vananenud, ja klient otsustas mitte osta uut ning minna üle avalikku pilve. Kriitiliste süsteemide seiskumise nõue ei tohtinud ületada tundi. Tööriistana valiti Veeam Replication. Positiivne oli ka see, et kliendi internetiteenuse pakkuja oli meie andmekeskuses, mis võimaldas korraldada hea kanal. Migratsioon kestis umbes kuu aega, vahepealne seiskumine vahetamisel oli kuni 30 minutit ühe virtuaalmasinagrupi kohta.
Migratsioon Veeam Cloud Connecti abil
Veeam Cloud Connect on tööriist, mis aitab seadistada virtuaalmasinate replikatsiooni ja käivitada replikaid teenusepakkuja pilves. Pärast uuendust aastal tuli võimalus replitseerida virtuaalmasinaid otse vCloud Directorisse. Ainus tingimus on, et kliendi poolel peab olema seadistatud oma Veeam Backup and Replication, mille versioon on vähemalt 9. Lühidalt (üksikasjalik versioon ), näeb kogu protsess välja järgmine.
vCloud Directoris luu organisatsiooni koos vajalike ressursside ja võrkudega. Veeam Cloud Connectis loome konto, millele klient ühendub oma Veeam B&R-st, valib DataLine'i teenusepakkuja ja organisatsiooni ning seadistab replikatsiooniülesanded. Lisaks sellele, et sellise migreerimise aeg jääb 15–20 minuti piiridesse, ei sõltu klient teenusepakkuja tugiteenustest ja juhib kogu protsessi iseseisvalt: loob replikatsiooniülesanded, viib läbi replikatsiooni, sulgeb masinad ja käivitab nende käivitamise uuel platsil.
Juhtum 2
Kliendi infrastruktuur, millelt migratsioon plaaniti, asus Valgevenes. Oli vaja üle viia 90 virtuaalmasinat kogumahtuga 27 TB, samal ajal kui internetiühendus oli 100 Mbit/s. Kui teha varukoopia ja kohe laadida see meie pilve, siis mõne virtuaalmasina jaoks oleks see kestnud mitu päeva. Selle aja jooksul oleks virtuaalmasinal tekkinud suur deltavahe, mis oleks võinud negatiivselt mõjutada masinate jõudlust või, veelgi hullem, andmestoori ruum oleks lõppenud. Tegutsesime järgmiselt: esmalt tegi klient kohaliku täisvarukoopia ja edastas selle koopia meie pilve läbi Veeami Cloud Connect. Seejärel tegi ta ja edastas pilve inkremente. Algne virtuaalmasin jätkas töötamist. Pärast virtuaalmasina väljalülitamist tegi klient veel ühe inkreendi ja edastas selle samuti pilve. Meie poolel lõime virtuaalmasina täisvarukoopiest ja seejärel lisasime sellele kaks inkreenti. See skeem võimaldas lõpuks minimeerida seiskumist kuni 2 tunni võrra, kui lülitusime meie platvormile.
Migratsioon VMware vCloud Availability abil
Sel aastal märtsis viis VMware välja vCloud Availability 3.0, mis võimaldab virtuaalmasinate migreerimist erinevate pilvede (vCloud Director – vCloud Director) ja kliendi privaatsete virtualiseerimisseisundite vahel pilve (vCenter – vCloud Director). Peamine mugavus on integreerimine vCloud Directori liidesega. See lihtsustab oluliselt replikatsiooni haldamise protsessi ja vähendab lülitusperioodi.
Selle tööriista abil migreerisime ühe kliendi meie Moskva pilvest meie Peterburi pilve. Kulus 18 virtuaalmasina edasiviimiseks, mille kogumaht oli 14 TB. Kliendile loodi organisatsioon Peterburi pilves ning korraldati vajalikud võrgud. Edasi liikus klient vCloud Directori liideses vCloud Availability seadistuste juurde, lõi replikatsioonitööd ja lülitus Peterburi platvormile talle sobival ajal. Lülitusperiood kestis 12 minutit.
DataLine pilvede vahelise migratsiooni skeem Peterburis ja Moskvas.
vCloud Availability-s on mehhanism, mis võimaldab VM-i migreerida kliendi platvormilt meie pilve. Selleks paigaldatakse kliendi vCenterisse spetsiaalne vCloud Availability appliance. Pärast lihtsat seadistust luuakse ühendus pilvega ja seadistatakse migratsiooniülesanded. Klient haldab kogu protsessi iseseisvalt, ning migratsiooni aeg on minimaalne.
Virtuaalmasinate migreerimise skeem privaatinstalleerimisest pilve.
VMware vCloud Availability-l on palju muid kasutusstsenaariume, millest räägime peagi eraldi artiklis.
Valmistumine migreerimiseks
Et valida tööriist ja alustada migreerimist, tuleb kindlaks määrata järgmised punktid:
Kust me migreerime. Kui te migreerite privaatlahenduselt, on teil täielik vabadus valida tööriistu. Kui lahkute teenusepakkujast, on olukord keerulisem. Tõenäoliselt ei õnnestu kahe teenusepakkuja infrastruktuure siduda ning lihtsalt VM-i üle kanda turvakaalutlustest tingituna. Mõnikord hakkab teenusepakkuja, kelle teenust soovite lõpetada, käituma ebameeldivalt ja venitab aega. Teenusepakkujast lahkumine võib toimuda vanamoodi: VM-i eksportimise kaudu ketastele ja FTP-le või rakendustasandil migreerimise kaudu. Viimase nimetamine on tinglik ja see näeb välja enam-vähem nii.
Juhtum 3
Tuli migreerida kliendi SAP-süsteem Euroopa teenusepakkujast: 34 VM-i mahus 54 TB. Kliendile eraldati ressursid meie pilves. Meie ja Euroopa teenusepakkuja infrastruktuuri vahel organiseeriti võrguühendus. Rakenduste serverid paigaldati uuesti koos vajalike konfiguratsioonide rakendamisega. Suured andmebaasid migratsiooniti meie pilve tagavarade laadimise teel. Edasi seadistati replikeerimine andmebaaside vahel meie ja algse platvormi vahel. Kokku lepitud ajal vahetasime meie pilve andmebaaside peale.
Andmete maht ja internetiühendus. Palume klientidelt tavaliselt süsteemide mäluparametrite, CPU ja kõvaketaste eksportimist. Hindame, kas kanal on piisav, et otse edastada virtuaalmasinate koopiaid või varukoopiaid.
Lubatud seisev aeg. Erinevate süsteemide ja seega ka virtuaalmasinate seisev aeg võib sõltuda nende äri kriitilisusest. Tüüpiliselt tuleb klient valmis nõuetega seisev aeg migreerimise ajal, mille alusel valime sobiva tööriista ja migreerimise plaani. Püüame planeerida lõpliku ülemineku öiseks ajaks või nädalavahetuseks, et isegi väike seisak ei oleks lõppkasutajatele nähtav.
Nende andmete põhjal saab valida tööriista ja alustada migreerimisega. Siin on, mis edasi toimub.
- Võrguühenduse seadistamine. Korrastame võrguühenduse meie pilve ja kliendi infrastruktuuri vahel. Selle võrgu kaudu kopeeritakse virtuaalmasinad. Kui kasutatakse Veeam Backup and Replication, siis on see erakanal, harvem – VPN-kanal. Kui Veeam Cloud Connect, siis kõik toimub interneti või sama erakanali kaudu.
Seejärel seadistatakse võrguühendus VM-ide jaoks pilves. Masinad liiguvad tavaliselt rühmades ning sellele kulub mitu päeva. Pärast seda, kui VM-id on meie juurde üle kantud ja käivitatud, peavad nad suhtlema masinatega, mis jäävad endiselt algsesse asukohta.
- Migreerimise ajakava. Kui masinasid on palju, on mõistlik jagada need rühmadesse ja transportida neid partiitena. Koostöös kliendiga lepime kokku plaani, milles täpsustame, millal ja millised masinad kolivad ning millal toimub lõplik replikatsioon ja üleminek uuele asukohale.
- Testmigreerimine. Migreerime testvirtual masin ja kontrollime, kas kõik on õigesti seadistatud: võrguühendus erinevate asukohtade vahel, virtuaalse masina ligipääsetavus masinatele algses asukohas, konto õigused ja muu. Selline test aitab vältida viivitusi tootmisprotsessi jooksul.
Sellega ongi kõik. Küsimuste korral kirjutage kommentaaridesse ja jagage oma migreerimiskogemust.
Allikas: habr.com
