«Միգրացիա» գործողություն. ինչպես տեղափոխվել DataLine ամպ

Մոտ 7 տարի առաջ հենց առաջին նախագծերը տեղափոխվեցին մեր ամպը պարզապես և ոչ հավակնոտ: Վիրտուալ մեքենայի պատկերները վերբեռնվել են FTP սերվերի վրա, կամ դրանք առաքվել են կոշտ սկավառակների վրա: Այնուհետև ներմուծման հատուկ սերվերի միջոցով VM-ները վերբեռնվեցին ամպի մեջ։

Եթե ​​հաճախորդի համար խնդիր չէ մեկ-երկու օրով անջատել վիրտուալ մեքենան (կամ այլ տարբերակներ չկան), ապա դա կարելի է անել։ Բայց եթե պարապուրդը պետք է լինի առավելագույնը մեկ ժամ, ապա այս մեթոդը չի աշխատի: Այսօր ես ձեզ կասեմ, թե ինչ գործիքներ կօգնեն ձեզ տեղափոխել ամպ նվազագույն ժամանակով և ինչպես է աշխատում մեր միգրացիոն գործընթացը:

Միգրացիա Veeam Backup-ի և Replication-ի միջոցով

Բոլորը գիտեն Veeam Backup and Replication որպես կրկնօրինակներ և կրկնօրինակներ ստեղծելու գործիք: Մենք այն օգտագործում ենք մեր կայքերի միջև միգրացիայի և հաճախորդներին մասնավոր վիրտուալացումից մեր ամպ տեղափոխելու համար: Հաճախորդի վիրտուալ մեքենաները կրկնօրինակվում են մեր vCenter-ին, որից հետո ինժեները դրանք ավելացնում է vCloud Director-ում:

Առաջնային կրկնօրինակումը տեղի է ունենում միացված վիրտուալ մեքենայի վրա: Պայմանավորված ժամին հաճախորդի կողմից մեքենան անջատված է: Կրկնօրինակումը նորից գործարկվում է առաջին կրկնօրինակումից հետո տեղի ունեցած փոփոխությունները փոխադրելու համար: Դրանից հետո վիրտուալ մեքենան սկսում է մեր ամպում:

Սովորաբար, այն պահից, երբ մեքենան անջատվում է հաճախորդի ենթակառուցվածքում, մինչև այն միանում է մեր ամպում, անցնում է ոչ ավելի, քան կես ժամ, այլ ավելի շուտ 15–20 րոպե:

Այս դեպքում բնօրինակ վիրտուալ մեքենան մնում է հաճախորդի կայքում: Եթե ​​հանկարծ ինչ-որ բան սխալ լինի, դուք միշտ կարող եք հետ գլորվել և միացնել այն: Այս մեթոդը հաճախորդի համար հարմար է նաև նրանով, որ չի պահանջում Veeam ունենալ:

Դեպք 1
Հաճախորդն ուներ իր սեփական վիրտուալ ենթակառուցվածքը՝ հիմնված VMware-ի վրա՝ 40 VM՝ 30 ՏԲ հզորությամբ: Սարքավորումը, որի վրա տեղադրվել էր կլաստերը, արդեն հնացել էր, և հաճախորդը որոշեց չանհանգստացնել նորերը գնելու համար և տեղափոխվեց հանրային ամպ: Կրիտիկական համակարգերի պարապուրդի պահանջը մեկ ժամից ոչ ավելի էր: Որպես գործիք ընտրվել է Veeam Replication: Մեկ այլ գումարած այն էր, որ հաճախորդի ինտերնետ մատակարարը ներկա էր մեր տվյալների կենտրոնում, ինչը հնարավորություն տվեց լավ ալիք կազմակերպել: Միգրացիան տևեց մոտ մեկ ամիս, անջատման ժամանակ դադարը մինչև 30 րոպե էր՝ վիրտուալ մեքենաների յուրաքանչյուր խմբի համար:

Տեղափոխել Veeam Cloud Connect-ի միջոցով

Veeam Cloud Connect-ը գործիք է, որն օգնում է ձեզ կարգավորել վիրտուալ մեքենայի կրկնօրինակումը և գործարկել կրկնօրինակները ծառայություններ մատուցողի ամպում: Թարմացումից հետո 2019 տարի, հնարավոր դարձավ վիրտուալ մեքենաները վերարտադրել անմիջապես vCloud Director-ին: Միակ պայմանն այն է, որ հաճախորդի կողմից Veeam Backup-ը և Replication-ը պետք է տեղակայվեն առնվազն 9-րդ տարբերակը: Կարճ ասած (մանրամասն տարբերակ այստեղ), ապա ամբողջ գործընթացը այսպիսի տեսք ունի.

vCloud Director-ում կազմակերպություն է ստեղծվում անհրաժեշտ ռեսուրսներով և ցանցերով։ Veeam Cloud Connect-ում մենք ստեղծում ենք հաշիվ, հաճախորդը միանում է դրան իր Veeam B&R-ից, ընտրում է DataLine մատակարար և կազմակերպություն և կարգավորում է առաջադրանքները կրկնօրինակման համար: Բացի այն, որ նման միգրացիայի ժամանակ պարապուրդը կլինի 15–20 րոպեի ընթացքում, հաճախորդը որևէ կերպ կախված չէ մատակարարի տեխնիկական աջակցությունից և ինքնուրույն կառավարում է ամբողջ գործընթացը. մեքենաները և գործարկում դրանք նոր կայքում:

Դեպք 2
Հաճախորդի ենթակառուցվածքը, որտեղից նախատեսվում էր միգրացիան, գտնվում էր Բելառուսում: Անհրաժեշտ էր տեղափոխել 90 VM՝ 27 ՏԲ ընդհանուր ծավալով, չնայած այն հանգամանքին, որ ինտերնետ կապուղին 100 Մբիթ/վրկ էր։ Եթե ​​դուք կրկնօրինակեք և անմիջապես վերբեռնեք այն մեր ամպում, ապա որոշ VM-ների համար դա մի քանի օր կպահանջի: Այս ընթացքում VM-ի վրա մեծ դելտա կմեծանար, և դա կարող է բացասաբար ազդել մեքենաների աշխատանքի վրա կամ, ավելի վատ, տվյալների պահեստի տարածքը սպառվել է: Մենք գործեցինք հետևյալ կերպ. նախ հաճախորդը պատրաստեց տեղական ամբողջական կրկնօրինակում և դրա պատճենը փոխանցեց մեր ամպին Veeam Cloud Connect-ի միջոցով: Հետո ես պատրաստեցի և ավելացումը փոխանցեցի ամպին։ Բնօրինակ վիրտուալ մեքենան շարունակեց աշխատել: VM-ն անջատելուց հետո հաճախորդը ևս մեկ ավելացում կատարեց և այն նույնպես փոխանցեց ամպին: Մեր կողմից մենք տեղադրեցինք վիրտուալ մեքենա ամբողջական կրկնօրինակից, այնուհետև երկու քայլ գլորեցինք դրա վրա: Այս սխեման, ի վերջո, հնարավորություն ընձեռեց նվազագույնի հասցնել անգործության ժամանակը մինչև 2 ժամ մեր կայք անցնելիս:

Միգրացիա VMware vCloud Availability-ով

Այս տարվա մարտին VMware-ը թողարկեց vCloud Availability 3.0-ը, որը թույլ է տալիս վիրտուալ մեքենաներ տեղափոխել տարբեր ամպերի միջև (vCloud Director - vCloud Director) և մասնավոր հաճախորդի վիրտուալիզացիայի դիրքերից դեպի ամպ (vCenter - vCloud Director): Հիմնական հարմարությունը vCloud Director ինտերֆեյսի հետ ինտեգրումն է: Սա մեծապես հեշտացնում է վերարտադրման կառավարման գործընթացը և նվազագույնի է հասցնում անջատումների ժամանակ անցումները:

Օգտագործելով այս գործիքը, մենք հաճախորդներից մեկին տեղափոխեցինք մեր Մոսկվայի ամպից Սանկտ Պետերբուրգի մեր ամպ: Անհրաժեշտ էր տեղափոխել 18 ՏԲ ընդհանուր հզորությամբ 14 վիրտուալ մեքենաներ։ Հաճախորդի համար Սանկտ Պետերբուրգի ամպում ստեղծվել է կազմակերպություն և կազմակերպվել են անհրաժեշտ ցանցերը։ Հաջորդը, vCloud Director ինտերֆեյսից, հաճախորդը գնաց vCloud Availability կարգավորումներ, ստեղծեց կրկնօրինակման աշխատանքներ և իր համար հարմար ժամանակ անցավ Սանկտ Պետերբուրգի կայք: Անջատման ժամանակահատվածը 12 րոպե էր:

Սանկտ Պետերբուրգում և Մոսկվայում DataLine ամպերի միջև միգրացիոն սխեման:

vCloud Availability-ն ունի VM-ները հաճախորդի կայքից մեր ամպ տեղափոխելու մեխանիզմ: Դա անելու համար հաճախորդի vCenter-ում տեղադրվում է հատուկ vCloud Availability հավելված: Պարզ կարգավորումից հետո դուք միանում եք ամպին և կարգավորում միգրացիոն առաջադրանքները: Հաճախորդը նաև ինքնուրույն է կառավարում ամբողջ գործընթացը, և միգրացիայի ժամանակը նվազագույնի է հասցվում:

Վիրտուալ մեքենաների մասնավոր տեղադրումից ամպ տեղափոխելու սխեման:

VMware vCloud Availability-ն ունի բազմաթիվ այլ օգտագործման դեպքեր, դրանց մասին մենք շուտով կխոսենք առանձին հոդվածում:

Պատրաստվում է միգրացիայի

Գործիք ընտրելու և իրականում միգրացիան սկսելու համար դուք պետք է որոշեք հետևյալ կետերը.

Որտեղի՞ց ենք գաղթում: Եթե ​​դուք արտագաղթում եք մասնավոր լուծումից, ապա դուք ունեք գործիքներ ընտրելու լիակատար ազատություն: Եթե ​​հեռանում եք ձեր մատակարարից, ապա դա ավելի բարդ է: Ամենայն հավանականությամբ, երկու պրովայդերների ենթակառուցվածքները միացնելը և VM-ը պարզապես քաշելն ու թողնելը չի ​​աշխատի անվտանգության նկատառումներից ելնելով: Երբեմն մատակարարը, որից հաճախորդը պատրաստվում է հրաժարվել, սկսում է չարաճճի լինել և ժամանակի հետ կանգնել: Դուք կարող եք հեռանալ մատակարարից հնաոճ ձևով՝ VM-ներ վերբեռնելով սկավառակների և FTP-ի վրա կամ տեղափոխելով հավելվածի մակարդակով: Վերջինիս անունը պայմանական է, և այն ունի մոտավորապես այսպիսի տեսք.

Դեպք 3
Անհրաժեշտ էր տեղափոխել հաճախորդի SAP համակարգը եվրոպական մատակարարից՝ 34 VM՝ 54 ՏԲ հզորությամբ: Հաճախորդին հատկացվել են ռեսուրսներ մեր ամպում: Ցանցային կապ է կազմակերպվել մեր և եվրոպական պրովայդերի ենթակառուցվածքի միջև։ Հավելվածի սերվերները վերաբաշխվել են, անհրաժեշտ կոնֆիգուրացիաները վերափոխվել են: Խոշոր տվյալների շտեմարանները տեղափոխվել են մեր ամպի վրա կրկնօրինակների վերբեռնման միջոցով: Հաջորդը, կրկնօրինակումը կազմաձևվեց մեր և սկզբնական կայքերի տվյալների բազաների միջև: Պայմանավորված ժամանակին մենք անցանք տվյալների բազաներին մեր ամպում:

Տվյալների ծավալը և ինտերնետ ալիքը: Մենք սովորաբար խնդրում ենք հաճախորդին տրամադրել վերբեռնում ըստ համակարգի՝ հիշողության, պրոցեսորի և սկավառակի պարամետրերով: Մենք գնահատում ենք, թե արդյոք ալիքը բավարար է ուղղակիորեն վիրտուալ մեքենաների կրկնօրինակներ կամ կրկնօրինակներ ուղարկելու համար:

Ընդունելի պարապուրդ: Տարբեր համակարգերի և, համապատասխանաբար, վիրտուալ մեքենաների համար այն կարող է տարբեր լինել՝ կախված դրանց բիզնեսի կարևորությունից: Սովորաբար հաճախորդը գալիս է միգրացիայի ընթացքում պարապուրդի պատրաստի պահանջներով, և դրա հիման վրա մենք ընտրում ենք համապատասխան գործիքը և միգրացիոն պլանը: Մենք փորձում ենք վերջնական անցումը պլանավորել գիշերը կամ հանգստյան օրերին, որպեսզի հաճախորդի վերջնական օգտագործողների համար նկատելի չլինի նույնիսկ աննշան խափանումները:

Այս տվյալների հիման վրա դուք կարող եք ընտրել գործիք և սկսել ինքնին միգրացիան: Ահա թե ինչ է տեղի ունենում հետո.

1. Ցանցային կապի կարգավորում: Մենք կազմակերպում ենք ցանցային կապ մեր ամպի և հաճախորդի ենթակառուցվածքի միջև: Վիրտուալ մեքենաները պատճենվելու են այս ցանցի միջոցով: Եթե ​​օգտագործվում է Veeam Backup and Replication, ապա սա նվիրված ալիք է, ավելի հազվադեպ՝ VPN ալիք: Եթե ​​Veeam Cloud Connect, ապա ամեն ինչ գնում է ինտերնետի կամ նույն նվիրված ալիքի միջոցով:

   Այնուհետև ցանցը կարգավորվում է ամպի մեջ գտնվող VM-ի համար: Մեքենաները սովորաբար շարժվում են խմբերով և մեկ օրից ավելի: Երբ VM-ները բերվեն մեզ մոտ և գործարկվեն, նրանք պետք է շփվեն այն մեքենաների հետ, որոնք դեռևս մնում են սկզբնական կայքում:

2. Միգրացիայի ժամանակացույց. Երբ մեքենաները շատ են, իմաստ ունի դրանք բաժանել խմբերի և տեղափոխել խմբաքանակով: Հաճախորդի հետ միասին մենք համաձայնում ենք պլանի շուրջ, որտեղ մենք նշում ենք, թե երբ և որ մեքենաները կտեղափոխվեն, և երբ կիրականացվի վերջնական կրկնօրինակումը և անցումը նոր կայք:
3. Փորձնական միգրացիա. Մենք տեղափոխում ենք փորձնական վիրտուալ մեքենան և ստուգում, թե արդյոք ամեն ինչ ճիշտ է կազմաձևված՝ կայքերի միջև ցանցային միացում, վիրտուալ մեքենայի առկայությունը սկզբնաղբյուր կայքում գտնվող մեքենաներին, հաշվի իրավունքներ և այլն: Այս թեստը օգնում է խուսափել մարտական ​​միգրացիայի փուլում խոչընդոտներից:

Ինձ համար այսքանն է: Մեկնաբանություններում տվեք հարցեր և պատմեք մեզ ձեր միգրացիայի փորձի մասին:

Source: www.habr.com