Maždaug prieš 7 metus patys pirmieji projektai paprastai ir nepretenzingai persikėlė į mūsų debesį. Virtualios mašinos vaizdai buvo įkelti į FTP serverį arba pristatyti į standųjį diską. Tada per specialų importavimo serverį VM buvo įkeltos į debesį.
Jei klientui nekyla problemų išjungti virtualią mašiną dienai ar dviem (arba nėra kitų galimybių), tai galima padaryti. Bet jei prastovos trukmė turėtų trukti ne ilgiau kaip valandą, šis metodas neveiks. Šiandien papasakosiu, kokie įrankiai padės pereiti prie debesies su minimaliomis prastovomis ir kaip veikia pats perkėlimo procesas.
Perkėlimas naudojant Veeam atsarginę kopiją ir replikaciją
Visi žino Veeam atsarginę kopiją ir replikaciją kaip atsarginių kopijų ir kopijų kūrimo įrankį. Mes naudojame jį perkėlimui tarp mūsų svetainių ir klientų perkėlimui iš privačios virtualizacijos į mūsų debesį. Kliento virtualios mašinos yra kopijuojamos į mūsų „vCenter“, o po to inžinierius jas prideda prie „vCloud Director“.
Pirminis replikavimas vyksta įjungtoje virtualioje mašinoje. Sutartu laiku kliento pusės aparatas išjungiamas. Replikacija paleidžiama dar kartą, kad būtų perkelti pakeitimai, įvykę po pirmosios replikacijos. Po to virtualioji mašina paleidžiama mūsų debesyje.
Paprastai nuo to momento, kai aparatas išjungiamas kliento infrastruktūroje iki to momento, kai jis įjungiamas mūsų debesyje, praeina ne daugiau kaip pusvalandis, o veikiau 15–20 minučių.
Tokiu atveju originali virtuali mašina lieka kliento svetainėje. Jei staiga kažkas negerai, visada galite atsukti ir įjungti. Šis metodas klientui patogus ir tuo, kad jam nereikia turėti Veeam.
1 atvejis
Klientas turėjo savo virtualią infrastruktūrą, paremtą VMware – 40 VM, kurių talpa 30 TB. Įranga, kurioje buvo įdiegtas klasteris, jau buvo pasenusi, todėl klientas nusprendė nesivarginti pirkti naujų ir perėjo į viešąjį debesį. Kritinių sistemų prastovos reikalavimas buvo ne daugiau kaip valanda. „Veeam Replication“ buvo pasirinktas kaip įrankis. Kitas pliusas buvo tai, kad mūsų duomenų centre buvo kliento interneto tiekėjas, o tai leido organizuoti gerą kanalą. Perkėlimas truko apie mėnesį, prastovos perjungimo metu buvo iki 30 minučių vienai virtualių mašinų grupei.
Perkelkite naudodami Veeam Cloud Connect
Veeam Cloud Connect yra įrankis, padedantis nustatyti virtualios mašinos replikaciją ir paleisti kopijas paslaugų teikėjo debesyje. Atnaujinus į metais atsirado galimybė virtualias mašinas replikuoti tiesiai į vCloud Director. Vienintelė sąlyga yra ta, kad kliento pusėje „Veeam Backup and Replication“ turi būti įdiegta bent 9 versija. Trumpai tariant (išsami versija ), tada visas procesas atrodo taip.
„vCloud Director“ sukuriama organizacija su reikiamais ištekliais ir tinklais. „Veeam Cloud Connect“ sukuriame paskyrą, klientas prisijungia prie jos iš savo Veeam B&R, pasirenka „DataLine“ tiekėją ir organizaciją bei sukonfigūruoja replikacijos užduotis. Be to, kad tokios migracijos metu prastovos bus per 15–20 minučių, klientas niekaip nepriklauso nuo tiekėjo techninio palaikymo ir visą procesą valdo savarankiškai: sukuria replikacijos užduotis, pačią replikaciją, išsijungia. mašinas ir paleidžia jas naujoje svetainėje.
2 atvejis
Kliento infrastruktūra, iš kurios buvo planuojama migracija, buvo Baltarusijoje. Reikėjo pervežti 90 VM, kurių bendras tūris 27 TB, nepaisant to, kad interneto kanalas buvo 100 Mbit/sek. Jei sukursite atsarginę kopiją ir iš karto įkelsite ją į mūsų debesį, kai kurioms VM tai užtruktų kelias dienas. Per tą laiką VM būtų išaugusi didelė delta, o tai gali turėti neigiamos įtakos mašinų veikimui arba, dar blogiau, būtų išeikvota vietos duomenų saugykloje. Mes elgėmės taip: pirmiausia klientas padarė vietinę pilną atsarginę kopiją ir perkėlė jos kopiją į mūsų debesį per Veeam Cloud Connect. Tada padariau ir perkėliau prieaugį į debesį. Pradinė virtuali mašina toliau veikė. Išjungęs VM, klientas padarė dar vieną prieaugį ir taip pat perkėlė jį į debesį. Iš savo pusės įdiegėme virtualią mašiną iš visos atsarginės kopijos, o tada į ją įtraukėme du žingsnius. Ši schema galiausiai leido sumažinti prastovos laiką iki 2 valandų pereinant į mūsų svetainę.
Perkėlimas naudojant „VMware vCloud“ prieinamumą
Šių metų kovą VMware išleido vCloud Availability 3.0, leidžiančią perkelti virtualias mašinas tarp skirtingų debesų (vCloud Director – vCloud Director) ir iš privačių klientų virtualizacijos stendų į debesį (vCenter – vCloud Director). Pagrindinis patogumas yra integracija su vCloud Director sąsaja. Tai labai supaprastina replikacijos valdymo procesą ir sumažina prastovų perjungimo metu.
Naudodami šį įrankį perkėlėme vieną iš klientų iš Maskvos debesies į debesį Sankt Peterburge. Reikėjo pervežti 18 virtualių mašinų, kurių bendra talpa 14 TB. Sankt Peterburgo debesyje klientui buvo sukurta organizacija ir sutvarkyti reikalingi tinklai. Toliau iš „vCloud Director“ sąsajos klientas nuėjo į „vCloud Availability“ nustatymus, sukūrė replikacijos užduotis ir jam patogiu metu persijungė į Sankt Peterburgo svetainę. Prastova perjungimo metu buvo 12 minučių.
Migracijos schema tarp DataLine debesų Sankt Peterburge ir Maskvoje.
„vCloud Availability“ turi VM perkėlimo iš kliento svetainės į mūsų debesį mechanizmą. Norėdami tai padaryti, kliento vCenter yra įdiegta speciali „vCloud Availability“ programa. Atlikę paprastą sąranką, prisijungiate prie debesies ir konfigūruojate perkėlimo užduotis. Klientas taip pat valdo visą procesą savarankiškai, o perkėlimo laikas yra minimalus.
Virtualių mašinų perkėlimo iš privataus įrenginio į debesį schema.
„VMware vCloud Availability“ turi daug kitų naudojimo atvejų; apie juos netrukus pakalbėsime atskirame straipsnyje.
Pasiruošimas migracijai
Norėdami pasirinkti įrankį ir iš tikrųjų pradėti perkėlimą, turite nuspręsti dėl šių dalykų:
Iš kur mes migruojame? Jei pereinate nuo privataus sprendimo, turite visišką laisvę rinktis įrankius. Jei nutolsite nuo savo paslaugų teikėjo, tai bus sudėtingiau. Greičiausiai dviejų tiekėjų infrastruktūrų susiejimas ir tiesiog VM vilkimas ir nuleidimas neveiks dėl saugumo priežasčių. Kartais paslaugų teikėjas, kurio klientas ketina atsisakyti, pradeda išdykauti ir trukdo laikui. Galite atsitraukti nuo teikėjo senamadišku būdu: įkeldami VM į diskus ir FTP arba perkeldami programos lygiu. Pastarojo pavadinimas yra sąlyginis ir atrodo maždaug taip.
3 atvejis
Reikėjo migruoti kliento SAP sistemą iš Europos tiekėjo: 34 VM, kurių talpa 54 TB. Klientui buvo skirti ištekliai mūsų debesyje. Tinklo ryšys buvo organizuotas tarp mūsų ir Europos tiekėjo infrastruktūros. Programų serveriai buvo įdiegti iš naujo, perkeliant reikiamas konfigūracijas. Didelės duomenų bazės buvo perkeltos įkeliant atsargines kopijas į mūsų debesį. Tada buvo sukonfigūruotas replikavimas tarp mūsų ir pradinių svetainių duomenų bazių. Sutartu laiku perėjome prie duomenų bazių savo debesyje.
Duomenų apimtis ir interneto kanalas. Paprastai prašome kliento pateikti įkėlimą pagal sistemą su atminties, procesoriaus ir disko parametrais. Įvertiname, ar kanalo pakanka tiesiogiai siųsti virtualių mašinų kopijas ar atsargines kopijas.
Priimtinas prastovos laikas. Skirtingoms sistemoms ir atitinkamai virtualioms mašinoms jis gali skirtis priklausomai nuo jų verslo kritiškumo. Paprastai klientas pateikia paruoštus reikalavimus dėl prastovos migracijos metu ir pagal tai parenkame tinkamą įrankį ir migracijos planą. Galutinį perjungimą stengiamės suplanuoti naktį arba savaitgaliais, kad net ir nedidelės prastovos nepastebėtų kliento galutiniai vartotojai.
Remdamiesi šiais duomenimis, galite pasirinkti įrankį ir pradėti patį perkėlimą. Štai kas vyksta toliau.
- Tinklo ryšio nustatymas. Organizuojame tinklo ryšį tarp mūsų debesies ir kliento infrastruktūros. Virtualios mašinos bus nukopijuotos per šį tinklą. Jei naudojamas Veeam atsarginis kopijavimas ir replikacija, tai yra skirtas kanalas, rečiau VPN kanalas. Jei „Veeam Cloud Connect“, tada viskas vyksta internetu arba tuo pačiu tam skirtu kanalu.
Tada tinklas sukonfigūruojamas VM debesyje. Automobiliai dažniausiai juda grupėmis ir ilgiau nei vieną dieną. Kai VM atvežamos ir paleidžiamos, jos turi susisiekti su mašinomis, kurios vis dar liko pradinėje vietoje.
- Migracijos grafikas. Kai automobilių yra daug, prasminga juos suskirstyti į grupes ir vežti partijomis. Kartu su klientu susitariame dėl plano, kuriame nurodome, kada ir kokios mašinos pajudės bei kada bus atliktas galutinis replikavimas ir perjungimas į naują svetainę.
- Išbandyti migraciją. Perkeliame bandomąją virtualiąją mašiną ir patikriname, ar viskas sukonfigūruota teisingai: tinklo ryšys tarp svetainių, virtualios mašinos prieinamumas šaltinio svetainėje esančioms mašinoms, paskyros teisės ir kt. Šis testas padeda išvengti kliūčių kovinės migracijos etape.
Tai viskas man. Komentaruose užduokite klausimus ir papasakokite apie savo migracijos patirtį.
Šaltinis: www.habr.com