Disaster Recovery լուծումների շուկայի երիտասարդ խաղացողներից է Hystax-ը, որը ռուսական ստարտափն է 2016թ. Քանի որ աղետների վերականգնման թեման շատ տարածված է, և շուկան չափազանց մրցունակ է, ստարտափը որոշել է կենտրոնանալ տարբեր ամպային ենթակառուցվածքների միջև միգրացիայի վրա: Ապրանքը, որը թույլ է տալիս կազմակերպել պարզ և արագ միգրացիա դեպի ամպ, շատ օգտակար կլինի Onlanta-ի հաճախորդների՝ օգտատերերի համար: . Այդպես ես ծանոթացա Hystax-ին և սկսեցի փորձարկել նրա հնարավորությունները: Եվ ինչ ստացվեց, ես կպատմեմ այս հոդվածում:
Hystax-ի հիմնական առանձնահատկությունը նրա լայն ֆունկցիոնալությունն է՝ աջակցելու տարբեր վիրտուալացման պլատֆորմներին, հյուրերի ՕՀ-ին և ամպային ծառայություններին, ինչը հնարավորություն է տալիս տեղափոխել ձեր աշխատանքային բեռները ցանկացած վայրից և ցանկացած վայրից:
Սա թույլ է տալիս ստեղծել ոչ միայն DR լուծումներ՝ բարելավելու ծառայությունների սխալների հանդուրժողականությունը, այլ նաև արագ, ճկուն կերպով տեղափոխել ռեսուրսները տարբեր կայքերի և հիպերսանդղակի միջև՝ ծախսերի խնայողությունները մեծացնելու և տվյալ ծառայության համար տվյալ պահին լավագույն լուծումը ընտրելու համար: Բացի վերնագրի նկարում թվարկված հարթակներից, ընկերությունը նաև ակտիվորեն համագործակցում է ռուսաստանյան ամպային պրովայդերների հետ՝ Yandex.Cloud, CROC Cloud Services, Mail.ru և շատ ուրիշներ: Հարկ է նաև նշել, որ 2020 թվականին ընկերությունը բացել է R&D կենտրոն, որը գտնվում է Սկոլկովոյում։
Շուկայի մեծ թվով խաղացողների կողմից մեկ լուծման ընտրությունը վկայում է լավ գնային քաղաքականության և ապրանքի բարձր կիրառելիության մասին, որը մենք որոշեցինք փորձարկել գործնականում:
Այսպիսով, մեր փորձարկման առաջադրանքը բաղկացած կլինի իմ VMware թեստային կայքից և ֆիզիկական մեքենաներից դեպի մատակարարի կայք, որը նույնպես աշխատում է VMware-ից: Այո, կան բազմաթիվ լուծումներ, որոնք կարող են իրականացնել նման միգրացիա, բայց մենք Hystax-ը համարում ենք ունիվերսալ գործիք, իսկ միգրացիան բոլոր հնարավոր կոմբինացիաներում փորձարկելն ուղղակի անիրատեսական խնդիր է։ Այո, և Oncloud.ru ամպը կառուցված է հատուկ VMware-ի վրա, ուստի այս հարթակը, որպես թիրախ, մեզ ավելի մեծ չափով է հետաքրքրում։ Հաջորդը, ես նկարագրելու եմ աշխատանքի հիմնական սկզբունքը, որը, որպես ամբողջություն, կախված չէ հարթակից, և VMware-ը կարող է փոխարինվել ցանկացած կողմից այլ վաճառողի հարթակով:
Առաջին քայլը Hystax Acura-ի տեղակայումն է, որը համակարգի կառավարման վահանակն է:
Այն ընդլայնվում է կաղապարից: Չգիտես ինչու, մեր դեպքում դա ամբողջովին ճիշտ չէր, և առաջարկված 8CPU-ի փոխարեն 16 Գբ տեղակայվեց ռեսուրսների կեսով: Հետևաբար, դուք պետք է հիշեք դրանք փոխել, հակառակ դեպքում VM-ի ներսում ենթակառուցվածքը, որի վրա կառուցված է ամեն ինչ, պարզապես չի սկսվի բեռնարկղերից, և պորտալն անհասանելի կլինի: IN մանրամասն նկարագրված են անհրաժեշտ ռեսուրսները, ինչպես նաև համակարգի բոլոր բաղադրիչների պորտերը:
Եվ նաև դժվարություններ կային կաղապարի միջոցով IP հասցեն սահմանելու հետ կապված, ուստի մենք այն փոխեցինք վահանակից: Դրանից հետո կարող եք գնալ ադմինիստրատորի վեբ ինտերֆեյս և լրացնել նախնական կազմաձևման հրաշագործը:
Վերջնակետ - մեր vCenter-ի IP կամ FQDN:
Մուտք և գաղտնաբառ - այստեղ պարզ է:
Target ESXi hostname-ը մեր կլաստերի հյուրընկալողներից մեկն է, որը կկրկնօրինակվի:
Target datastore-ը մեր կլաստերի տվյալների պահեստներից մեկն է, որը կկրկնօրինակվի:
Hystax Acura Control Panel Public IP - հասցեն, որտեղ հասանելի կլինի կառավարման վահանակը:
Հոսթի և տվյալների պահեստի վերաբերյալ մի փոքր պարզաբանում է պահանջվում: Փաստն այն է, որ Hystax-ի կրկնօրինակումն աշխատում է հյուրընկալողի և տվյալների պահեստի մակարդակներում: Հաջորդը, ես ձեզ կասեմ, թե ինչպես կարող եք փոխել հյուրընկալողը և տվյալների պահեստը վարձակալի համար, բայց խնդիրն այլ է: Hystax-ը չի աջակցում ռեսուրսների միավորմանը, այսինքն. կրկնօրինակը միշտ տեղի կունենա կլաստերի արմատի հետ (այս նյութը գրելու պահին Hystax-ի տղաները թողարկեցին թարմացված տարբերակը, որտեղ նրանք արագորեն իրականացրեցին իմ գործառույթի խնդրանքը ռեսուրսների լողավազանների աջակցության վերաբերյալ): Նաև vCloud Director-ը չի աջակցվում, այսինքն. եթե, ինչպես իմ դեպքում, վարձակալը չունի ադմինիստրատորի իրավունքներ ամբողջ կլաստերի վրա, այլ միայն որոշակի ռեսուրսային ֆոնդի, և մենք մուտք ենք տվել Hystax-ին, ապա նա կկարողանա ինքնուրույն կրկնօրինակել և գործարկել այս VM-ները, բայց նա չկարողանա տեսնել դրանք VMware ենթակառուցվածքում, որին նա մուտք ունի և, համապատասխանաբար, հետագայում կառավարի վիրտուալ մեքենաները: Կլաստերի ադմինիստրատորը պետք է տեղափոխի VM-ը ճիշտ ռեսուրսների լողավազան կամ ներմուծի այն vCloud Director:
Ինչո՞ւ եմ ես այդքան կենտրոնանում այս պահերի վրա: Քանի որ, որքանով ես հասկանում եմ ապրանքի հայեցակարգը, հաճախորդը պետք է կարողանա ինքնուրույն իրականացնել ցանկացած միգրացիա կամ DR՝ օգտագործելով Acura վահանակը: Բայց մինչ այժմ VMware-ի աջակցությունը մի փոքր զիջում է նույն OpenStack-ի աջակցության մակարդակին, որտեղ արդեն իսկ ներդրվել են նման մեխանիզմներ։
Բայց վերադառնանք տեղակայմանը: Առաջին հերթին, վահանակի նախնական կարգավորումից հետո մենք պետք է ստեղծենք մեր համակարգում առաջին վարձակալը:
Այստեղ բոլոր դաշտերը պարզ են, ես ձեզ կասեմ միայն Cloud դաշտի մասին։ Մենք արդեն ունենք «կանխադրված» ամպ, որը ստեղծել ենք սկզբնական կազմաձևման ժամանակ: Բայց եթե մենք ցանկանում ենք յուրաքանչյուր վարձակալի տեղավորել իր սեփական տվյալների պահեստում և իր սեփական ռեսուրսների ֆոնդում, մենք կարող ենք դա իրականացնել՝ ստեղծելով առանձին ամպեր մեր յուրաքանչյուր հաճախորդի համար:
Նոր ամպի ավելացման տեսքով մենք նշում ենք նույն պարամետրերը, ինչ սկզբնական կազմաձևման ժամանակ (կարող ենք նույնիսկ օգտագործել նույն հոսթը), նշում ենք տվյալ հաճախորդի համար պահանջվող տվյալների պահեստը, և այժմ լրացուցիչ պարամետրերում մենք արդեն կարող ենք առանձին նշել. պահանջվող լողավազանի ռեսուրս {"resource_pool" :"YOUR_POOL_NAME"}
Ինչպես նկատեցիք, վարձակալ ստեղծելու ձևով ոչինչ չկա ռեսուրսների բաշխման կամ ինչ-որ քվոտաների մասին. համակարգում սրանից ոչինչ չկա: Դուք չեք կարող վարձակալին սահմանափակել միաժամանակյա կրկնօրինակների քանակով, կրկնօրինակման համար նախատեսված մեքենաների քանակով կամ որևէ այլ պարամետրով: Այսպիսով, մենք ստեղծել ենք առաջին վարձակալը։ Այժմ կա ոչ ամբողջովին տրամաբանական, բայց պարտադիր բան՝ Cloud գործակալի տեղադրումը։ Դա անտրամաբանական է, քանի որ գործակալը ներբեռնվում է կոնկրետ հաճախորդի էջում։
Միևնույն ժամանակ, այն կապված չէ ստեղծված վարձակալի հետ, և մեր բոլոր հաճախորդները կաշխատեն դրա միջոցով (կամ մի քանիսից հետո, եթե մենք տեղակայենք նրանց): Մեկ գործակալն աջակցում է 10 միաժամանակյա նիստերին: Մեկ նստաշրջանը համարվում է մեկ մեքենա: Կարեւոր չէ, թե քանի սկավառակ ունի: Մինչ օրս Acura-ում VMware-ի համար գործակալների մասշտաբավորման մեխանիզմ չկա: Կա ևս մեկ տհաճ պահ. մենք չենք կարող դիտել այս գործակալի «օգտագործումը» Acura վահանակից, որպեսզի եզրակացնենք, թե արդյոք պետք է ավելի շատ տեղակայել, թե ընթացիկ տեղադրումը բավարար է: Արդյունքում ստենդը ունի հետևյալ տեսքը.
Մեր հաճախորդի պորտալ մուտք գործելու հաջորդ քայլը հաշիվ ստեղծելն է (և նախ՝ նաև դեր, որը կկիրառվի այս օգտվողի համար):
Այժմ մեր հաճախորդը կարող է ինքնուրույն օգտվել պորտալից: Նրան ընդամենը պետք է ներբեռնել գործակալները պորտալից և տեղադրել դրանք իր կողքին: Գործակալների երեք տեսակ կա՝ Linux, Windows և VMware:
Առաջին երկուսը դրված են ֆիզիկայի վրա կամ վիրտուալ մեքենաների վրա՝ ցանկացած ոչ VMware հիպերվիզորի վրա: Այստեղ լրացուցիչ կոնֆիգուրացիա չի պահանջվում, գործակալը ներբեռնում է և արդեն գիտի, թե որտեղ պետք է թակել, և բառացիորեն մեկ րոպեից մեքենան տեսանելի կլինի Acura վահանակում: VMware գործակալի դեպքում իրավիճակը մի փոքր ավելի բարդ է: Խնդիրն այն է, որ Agent for VMware-ը նույնպես ներբեռնվում է արդեն պատրաստված և անհրաժեշտ կոնֆիգուրացիա ունեցող պորտալից։ Բայց VMware գործակալը, բացի մեր Acura պորտալի մասին իմանալուց, պետք է նաև իմանա վիրտուալացման համակարգի մասին, որի վրա այն կտեղակայվի:
Փաստորեն, համակարգը մեզ կխնդրի նշել այս տվյալները, երբ առաջին անգամ ներբեռնեք VMware գործակալը: Խնդիրն այն է, որ անվտանգության հանդեպ համընդհանուր սիրո մեր դարում ոչ բոլորն են ցանկանում նշել իրենց ադմինիստրատորի գաղտնաբառը ուրիշի պորտալում, ինչը միանգամայն հասկանալի է: Ներսից, տեղակայումից հետո գործակալը որևէ կերպ չի կարող կազմաձևվել (կարող եք փոխել միայն նրա ցանցի կարգավորումները): Այստեղ ես դժվարություններ եմ կանխատեսում հատկապես զգուշավոր հաճախորդների հետ։
Այսպիսով, գործակալները տեղադրելուց հետո մենք կարող ենք վերադառնալ Acura վահանակ և տեսնել մեր բոլոր մեքենաները:
Քանի որ մեկ օրից ավելի է, ինչ աշխատում եմ համակարգի հետ, ունեմ մեքենաներ տարբեր նահանգներում: Դրանք բոլորը գտնվում են Default խմբում, սակայն հնարավոր է առանձին խմբեր ստեղծել և մեքենաներ փոխանցել նրանց, ըստ անհրաժեշտության: Սա ոչ մի բանի վրա չի ազդում՝ միայն տվյալների տրամաբանական ներկայացումը և դրանց խմբավորումը ավելի հարմար աշխատանքի համար: Դրանից հետո առաջին և ամենակարևոր բանը, որ մենք պետք է անենք, միգրացիոն գործընթաց սկսելն է։ Մենք կարող ենք դա անել և՛ բռնի կերպով ձեռքով, և՛ ժամանակացույց սահմանել՝ ներառյալ զանգվածաբար բոլոր մեքենաների համար միանգամից:
Հիշեցնեմ, որ Hystax-ը դիրքավորվել է որպես միգրացիայի արտադրանք։ Հետևաբար, զարմանալի չէ, որ մեր կրկնօրինակված մեքենաները գործարկելու համար մենք պետք է ստեղծենք DR պլան: Դուք կարող եք պլան ստեղծել մեքենաների համար, որոնք արդեն Synced վիճակում են: Դուք կարող եք գեներացնել ինչպես մեկ կոնկրետ VM-ի, այնպես էլ բոլոր մեքենաների համար միանգամից:
Պարամետրերի փաթեթը DR պլան ստեղծելիս կտարբերվի՝ կախված այն ենթակառուցվածքից, ուր դուք տեղափոխվելու եք: VMware միջավայրի համար հասանելի է ընտրանքների նվազագույն փաթեթ: Մեքենաների համար կրկին IP-ն նույնպես չի ապահովվում: Այս առումով մեզ հետաքրքրում են հետևյալ կետերը՝ VM-ի նկարագրության մեջ՝ «ենթացանց» պարամետրը՝ «VMNetwork», որտեղ մենք կապում ենք VM-ը կլաստերի կոնկրետ ցանցին: Rank - տեղին է մի քանի VM-ների տեղափոխման ժամանակ, որոշում է դրանց գործարկման հաջորդականությունը: Flavour-ը նկարագրում է VM-ի կոնֆիգուրացիան, այս դեպքում՝ 1CPU, 2GB RAM: Ենթացանցերի բաժնում մենք սահմանում ենք, որ «ենթացանցը». «VMNetwork»-ը կապված է VMware-ի «VM Network»-ի հետ:
DR պլան ստեղծելիս, տարբեր տվյալների պահեստներում սկավառակները «բաժանելու» միջոց չկա: Նրանք կգտնվեն նույն տվյալների պահեստում, որը սահմանված է այս հաճախորդի ամպի համար, և եթե ունեք տարբեր դասերի սկավառակներ, դա կարող է որոշակի դժվարություններ առաջացնել մեքենան գործարկելու ժամանակ, իսկ VM-ը Hystax-ից գործարկելուց և «բաժանելուց» հետո այն նաև կառաջացնի: պահանջում են առանձին միգրացիոն սկավառակներ դեպի անհրաժեշտ տվյալների պահեստներ: Այնուհետև մենք պարզապես պետք է գործարկենք մեր DR պլանը և սպասենք, որ մեր մեքենաները բարձրանան: P2V/V2V փոխակերպման գործընթացը նույնպես ժամանակ է պահանջում: Իմ ամենամեծ 100 ԳԲ թեստային մեքենայի վրա երեք սկավառակներով դա տևեց առավելագույնը 10 րոպե:
Դրանից հետո դուք պետք է ստուգեք գործող VM-ն, դրա վրա առկա ծառայությունները, տվյալների հետևողականությունը և այլ ստուգումներ:
Այնուհետև մենք ունենք երկու տարբերակ.
- Ջնջել - ջնջել գործող DR պլանը: Այս գործողությունը պարզապես կփակի գործող VM-ն: Այս կրկնօրինակները ոչ մի տեղ չեն գնում:
- Անջատել - պոկել կրկնվող մեքենան Acura-ից, այսինքն. իրականում ավարտել միգրացիոն գործընթացը:
Լուծման առավելությունները.
- տեղադրման և կազմաձևման հեշտությունը ինչպես հաճախորդի, այնպես էլ մատակարարի կողմից.
- միգրացիայի ստեղծման հեշտությունը, DR պլանի ստեղծումը և կրկնօրինակների գործարկումը.
- աջակցությունը և մշակողները բավականին արագ են արձագանքում հայտնաբերված խնդիրներին և ուղղում դրանք հարթակի կամ գործակալի թարմացումներով:
Դեմ
- Vmware-ի անբավարար աջակցություն:
- Հարթակից վարձակալների համար որևէ քվոտայի բացակայություն:
Ես նաև ներկայացրեցի Հատկանիշի հարցում, որը մենք հանձնեցինք վաճառողին.
- օգտագործման մոնիտորինգ և տեղակայում Acura Management Console-ից Cloud Agents-ի համար;
- վարձակալների համար քվոտաների առկայությունը.
- յուրաքանչյուր վարձակալի համար միաժամանակյա կրկնությունների քանակը և արագությունը սահմանափակելու ունակություն.
- աջակցություն VMware vCloud Director-ին;
- աջակցություն ռեսուրսների լողավազաններին (իրականացվել է փորձարկման ընթացքում);
- VMware գործակալը հենց գործակալի կողմից կարգավորելու ունակություն, առանց Acura վահանակում հաճախորդի ենթակառուցվածքից հավատարմագրեր մուտքագրելու.
- DR պլան սկսելու ժամանակ VM-ի գործարկման գործընթացի «պատկերացում»:
Միակ բանը, որ մեծ դժգոհություններ առաջացրեց, փաստաթղթերն էին։ Ես իսկապես չեմ սիրում «սև արկղերը» և նախընտրում եմ, երբ առկա են մանրամասն փաստաթղթեր, թե ինչպես է արտադրանքը աշխատում ներսում: Եվ եթե AWS-ի և OpenStack-ի համար արտադրանքը նկարագրված է նույնիսկ քիչ թե շատ, ապա VMware-ի համար շատ քիչ փաստաթղթեր կան:
Կա տեղադրման ուղեցույց, որը նկարագրում է միայն Acura վահանակի տեղակայումը, և որտեղ ոչ մի խոսք չկա Cloud գործակալի անհրաժեշտության մասին: Ապրանքի տեխնիկական բնութագրերի ամբողջական փաթեթ կա, ինչը լավ է: Կան փաստաթղթեր, որոնք նկարագրում են «ից և դեպի» կարգավորումը՝ օգտագործելով AWS-ը և OpenStack-ը որպես օրինակ (չնայած դա ինձ ավելի շատ բլոգային գրառում է հիշեցնում), և կա շատ փոքր Գիտելիքի բազա:
Ընդհանրապես, սա այնքան էլ այն փաստաթղթային ձևաչափը չէ, որին ես սովոր եմ, ասենք, ավելի մեծ վաճառողներից, այնպես որ ես լիովին հարմարավետ չէի: Միևնույն ժամանակ, ես այս փաստաթղթում չգտա համակարգի «ներսում» գործողության որոշ նրբերանգների վերաբերյալ պատասխաններ. ես ստիպված էի շատ հարցեր պարզաբանել տեխնիկական աջակցությամբ, և դա բավականին ձգձգեց ստենդը և տեղադրելու գործընթացը: փորձարկում.
Ամփոփելով՝ կարող եմ ասել, որ ընդհանուր առմամբ ինձ դուր եկավ արտադրանքը և ընկերության մոտեցումը առաջադրանքի իրականացմանը։ Այո, կան թերություններ, կա ֆունկցիոնալության իսկապես կրիտիկական պակաս (VMware-ի հետ միասին): Երևում է, որ առաջին հերթին ընկերությունը դեռևս կենտրոնանում է հանրային ամպերի, մասնավորապես AWS-ի վրա, և ոմանց համար դա բավարար կլինի։ Նման պարզ և հարմար արտադրանք ունենալն այսօր, երբ շատ ընկերություններ ընտրում են բազմաֆունկցիոնալ ռազմավարություն, չափազանց կարևոր է։ Հաշվի առնելով մրցակիցների համեմատ շատ ավելի ցածր գինը, սա արտադրանքը դարձնում է չափազանց գրավիչ:
Մենք թիմ ենք փնտրում . Միգուցե դա դո՞ւ ես։
Source: www.habr.com