Antaŭ proksimume 7 jaroj, la plej unuaj projektoj translokiĝis al nia nubo simple kaj senpretende. Virtualaj maŝinbildoj estis alŝutitaj al FTP-servilo, aŭ ili estis liveritaj sur durdiskoj. Tiam, per speciala importa servilo, la VM-oj estis alŝutitaj al la nubo.
Se ne estas problemo por la kliento malŝalti la virtualan maŝinon dum unu aŭ du tagoj (aŭ ne ekzistas aliaj ebloj), tiam ĉi tio povas esti farita. Sed se la malfunkcio devus esti maksimume unu horo, tiam ĉi tiu metodo ne funkcios. Hodiaŭ mi rakontos al vi, kiaj iloj helpos vin migri al la nubo kun minimuma malfunkcio kaj kiel nia migra procezo mem funkcias.
Migrado kun Veeam Backup kaj Replication
Ĉiuj konas Veeam Backup and Replication kiel ilon por krei sekurkopiojn kaj kopiojn. Ni uzas ĝin por migrado inter niaj retejoj kaj por transporti klientojn de privata virtualigo al nia nubo. La virtualaj maŝinoj de la kliento estas reproduktitaj al nia vCenter, post kio la inĝeniero aldonas ilin al vCloud Director.
Primara reproduktado okazas sur funkciigita virtuala maŝino. Je la interkonsentita tempo, la klientflanka maŝino estas malŝaltita. Reproduktado denove funkcias por porti ŝanĝojn kiuj okazis ekde la unua reproduktado. Post ĉi tio, la virtuala maŝino komenciĝas en nia nubo.
Tipe, de la momento, kiam la maŝino estas malŝaltita sur la infrastrukturo de la kliento, ĝis la momento, kiam ĝi estas ŝaltita en nia nubo, ne pasas pli ol duonhoro, sed prefere 15-20 minutoj.
En ĉi tiu kazo, la originala virtuala maŝino restas sur la klienta retejo. Se subite io misfunkcias, vi ĉiam povas reiri kaj ŝalti ĝin. Ĉi tiu metodo ankaŭ estas oportuna por la kliento ĉar ĝi ne postulas, ke li havu Veeam.
Kazo 1
La kliento havis sian propran virtualan infrastrukturon bazitan sur VMware - 40 VMs kun kapablo de 30 TB. La ekipaĵo sur kiu la areto estis deplojita jam estis malmoderna, kaj la kliento decidis ne ĝeni aĉeti novajn kaj translokiĝis al la publika nubo. La malfunkciopostulo por kritikaj sistemoj estis ne pli ol unu horo. Veeam Replication estis elektita kiel la ilo. Alia pluso estis, ke la interreta provizanto de la kliento ĉeestis en nia datumcentro, kio ebligis organizi bonan kanalon. La migrado daŭris proksimume monaton, malfunkcio dum ŝanĝado estis ĝis 30 minutoj por grupo de virtualaj maŝinoj.
Migru kun Veeam Cloud Connect
Veeam Cloud Connect estas ilo kiu helpas vin agordi virtualan maŝinreproduktadon kaj lanĉi kopiojn en la nubo de la servoprovizanto. Post ĝisdatigo al jaro, fariĝis eble reprodukti virtualajn maŝinojn rekte al vCloud Director. La sola kondiĉo estas, ke ĉe la klienta flanko, Veeam Backup kaj Replication devas esti deplojitaj almenaŭ versio 9. Mallonge (detala versio ), tiam la tuta procezo aspektas tiel.
En vCloud Director, organizo estas kreita kun la necesaj rimedoj kaj retoj. En Veeam Cloud Connect, ni kreas konton, la kliento konektas al ĝi de sia Veeam B&R, elektas DataLine-provizanton kaj organizon, kaj agordas taskojn por reproduktado. Krom la fakto, ke dum tia migrado, malfunkcio estos ene de 15-20 minutoj, la kliento neniel dependas de la teknika subteno de la provizanto kaj administras la tutan procezon sendepende: kreas reproduktajn taskojn, la reproduktado mem malŝaltas. la maŝinojn kaj lanĉas ilin sur la nova retejo.
Kazo 2
La infrastrukturo de la kliento, de kie la migrado estis planita, situis en Belorusio. Necesis transporti 90 VM-ojn kun totala volumo de 27 TB, malgraŭ la fakto, ke la interreta kanalo estis 100 Mbit/sec. Se vi faras sekurkopion kaj tuj alŝutas ĝin al nia nubo, tiam por iuj VM-oj necesus plurajn tagojn. Dum ĉi tiu tempo, granda delto estus kreskinta sur la VM, kaj ĉi tio povus havi negativan efikon sur la agado de la maŝinoj aŭ, eĉ pli malbone, la spaco en la datumvendejo elĉerpiĝus. Ni procedis jene: unue, la kliento faris lokan plenan sekurkopion kaj transdonis kopion de ĝi al nia nubo per Veeam Cloud Connect. Tiam mi faris kaj translokigis la pliigon al la nubo. La origina virtuala maŝino daŭre funkciis. Post fermi la VM, la kliento faris alian pliigon kaj ankaŭ transdonis ĝin al la nubo. Niaflanke, ni deplojis virtualan maŝinon de plena sekurkopio, kaj poste ruliĝis du pliigojn sur ĝin. Ĉi tiu skemo finfine ebligis minimumigi malfunkcion al 2 horoj dum ŝanĝado al nia retejo.
Migrado kun VMware vCloud Havebleco
En marto de ĉi tiu jaro, VMware publikigis vCloud Availability 3.0, kiu ebligas al vi migri virtualajn maŝinojn inter malsamaj nuboj (vCloud Director - vCloud Director) kaj de privataj klientaj virtualigo standoj al la nubo (vCenter - vCloud Director). La ĉefa oportuno estas integriĝo kun la interfaco de vCloud Director. Ĉi tio multe simpligas la reproduktan administradprocezon kaj minimumigas malfunkcion dum ŝanĝoj.
Uzante ĉi tiun ilon, ni migris unu el la klientoj de nia Moskva nubo al nia nubo en Sankt-Peterburgo. Necesis transporti 18 virtualajn maŝinojn kun totala kapablo de 14 TB. Organizo estis kreita por la kliento en la Sankt-Peterburga nubo kaj la necesaj retoj estis organizitaj. Poste, de la interfaco de vCloud Director, la kliento iris al la agordoj de vCloud Availability, kreis reproduktajn laborojn kaj ŝanĝis al la retejo de Sankt-Peterburgo en oportuna tempo por li. Malfunkcio dum ŝanĝado estis 12 minutoj.
Migradoskemo inter DataLine-nuboj en Sankt-Peterburgo kaj Moskvo.
vCloud Availability havas mekanismon por migri VMs de la retejo de la kliento al nia nubo. Por fari tion, speciala aplikaĵo de vCloud Availability estas deplojita en la vCenter de la kliento. Post simpla agordo, vi konektas al la nubo kaj agordas migrajn taskojn. La kliento ankaŭ administras la tutan procezon sendepende kaj migrada tempo estas minimumigita.
Skemo por migrado de virtualaj maŝinoj de privata instalaĵo al la nubo.
VMware vCloud Availability havas multajn aliajn uzkazojn; ni parolos pri ili en aparta artikolo baldaŭ.
Preparante por migrado
Por elekti ilon kaj efektive ekmigri, vi devas decidi pri la sekvaj punktoj:
De kie ni migras? Se vi migras de privata solvo, tiam vi havas plenan liberecon elekti ilojn. Se vi malproksimiĝas de via provizanto, tiam ĝi estas pli komplika. Plej verŝajne, ligi la infrastrukturojn de du provizantoj kaj simple treni kaj faligi VM ne funkcios pro sekurecaj kialoj. Foje la provizanto, kiun la kliento estas rifuzonta, komencas esti malica kaj bremsas tempon. Vi povas malproksimigi de la provizanto laŭmoda maniero: alŝutante VM-ojn al diskoj kaj FTP, aŭ migrante ĉe la aplika nivelo. La nomo de ĉi-lasta estas kondiĉa, kaj ĝi aspektas kiel ĉi tio.
Kazo 3
Necesis migri la SAP-sistemon de la kliento de eŭropa provizanto: 34 VM-oj kun kapablo de 54 TB. La kliento ricevis rimedojn en nia nubo. Reta konektebleco estis organizita inter ni kaj la infrastrukturo de la eŭropa provizanto. La aplikaĵserviloj estis re-deplojitaj, kun la necesaj agordoj rulitaj. Grandaj datumbazoj estis migritaj per alŝutado de sekurkopioj al nia nubo. Poste, reproduktado estis agordita inter la datumbazoj sur nia kaj la originalaj retejoj. Je la interkonsentita tempo, ni ŝanĝis al datumbazoj en nia nubo.
Volumo de datumoj kaj interreta kanalo. Ni kutime petas al la kliento provizi alŝuton per sistemo kun memoro, CPU kaj disko-parametroj. Ni taksas ĉu la kanalo sufiĉas por rekte sendi kopiojn aŭ sekurkopiojn de virtualaj maŝinoj.
Akceptebla malfunkcio. Por malsamaj sistemoj kaj, sekve, virtualaj maŝinoj, ĝi povas esti malsama depende de ilia komerca kritiko. Kutime la kliento venas kun pretaj postuloj por malfunkcio dum migrado, kaj surbaze de tio ni elektas la taŭgan ilon kaj migradan planon. Ni provas plani la finan ŝanĝon nokte aŭ semajnfine por ke eĉ negrava malfunkcio ne rimarku la finuzantoj de la kliento.
Surbaze de ĉi tiuj datumoj, vi povas elekti ilon kaj komenci la migradon mem. Jen kio okazas poste.
- Agordi retan konekteblecon. Ni organizas retan konekteblecon inter nia nubo kaj la infrastrukturo de la kliento. Virtualaj maŝinoj estos kopiitaj tra ĉi tiu reto. Se Veeam Backup and Replication estas uzata, tiam ĉi tiu estas dediĉita kanalo, malpli ofte VPN-kanalo. Se Veeam Cloud Connect, tiam ĉio iras per la Interreto aŭ la sama dediĉita kanalo.
Tiam la reto estas agordita por la VM en la nubo. Aŭtoj kutime moviĝas en grupoj kaj dum pli ol unu tago. Post kiam la VM-oj estas alportitaj al ni kaj lanĉitaj, ili devas komuniki kun la maŝinoj, kiuj ankoraŭ restas ĉe la origina retejo.
- Migrada horaro. Kiam estas multaj aŭtoj, estas senco dividi ilin en grupojn kaj transporti ilin en aroj. Kune kun la kliento, ni konsentas pri plano, en kiu ni specifas kiam kaj kiuj maŝinoj moviĝos kaj kiam la fina reproduktado kaj transiro al la nova retejo estos farita.
- Prova migrado. Ni migras la provan virtualan maŝinon kaj kontrolas ĉu ĉio estas agordita ĝuste: retkonektebleco inter ejoj, havebleco de la virtuala maŝino al maŝinoj sur la fonto-ejo, kontrajtoj, ktp. Ĉi tiu testo helpas eviti problemojn ĉe la batala migra stadio.
Tio estas ĉio por mi. En la komentoj, demandu kaj diru al ni pri via migrada sperto.
fonto: www.habr.com