🥇Flexiant Cloud Orchestrator. ինչով ուտել այն

IaaS (Վիրտուալ տվյալների կենտրոն) ծառայություններ տրամադրելու համար մենք Ռուսոնիքս մենք օգտագործում ենք կոմերցիոն նվագախումբ Flexiant Cloud Orchestrator (FCO): Այս լուծումն ունի բավականին յուրահատուկ ճարտարապետություն, որն այն տարբերում է լայն հանրությանը հայտնի Openstack-ից և CloudStack-ից։

KVM-ը, VmWare-ը, Xen-ը, Virtuozzo6/7-ը, ինչպես նաև նույն Virtuozzo-ի կոնտեյներները աջակցվում են որպես հաշվողական հանգույցների հիպերվիզորներ: Աջակցվող պահեստավորման տարբերակները ներառում են տեղական, NFS, Ceph և Virtuozzo Storage:

FCO-ն աջակցում է մի քանի կլաստերների ստեղծմանը և կառավարմանը մեկ ինտերֆեյսից: Այսինքն՝ դուք կարող եք կառավարել Virtuozzo կլաստերը և KVM + Ceph կլաստերը՝ անցնելով դրանց միջև մկնիկի սեղմումով։

Իր հիմքում FCO-ն համապարփակ լուծում է ամպային պրովայդերների համար, որը, բացի կազմակերպումից, ներառում է նաև բիլինգ՝ բոլոր կարգավորումներով, վճարման հավելավճարներով, հաշիվ-ապրանքագրերով, ծանուցումներով, վերավաճառողներով, սակագներով և այլն: Այնուամենայնիվ, բիլինգային մասը ի վիճակի չէ լուսաբանել ռուսական բոլոր նրբությունները, ուստի մենք հրաժարվեցինք դրա օգտագործումից՝ հօգուտ այլ լուծման։

Ես շատ գոհ եմ բոլոր ամպային ռեսուրսների վրա իրավունքների բաշխման ճկուն համակարգից՝ պատկերներ, սկավառակներ, ապրանքներ, սերվերներ, firewall-ներ. Յուրաքանչյուր հաճախորդ կարող է ստեղծել մի քանի անկախ տվյալների կենտրոններ իր ամպում և կառավարել դրանք մեկ կառավարման վահանակից:

Ճարտարապետական առումով FCO-ն բաղկացած է մի քանի մասերից, որոնցից յուրաքանչյուրն ունի իր անկախ ծածկագիրը, իսկ որոշներն ունեն իրենց տվյալների բազան։

Տեսանելի հորիզոն - ադմինիստրատոր և օգտագործողի միջերես
չարչարել - բիզնեսի տրամաբանություն, բիլինգ, առաջադրանքների կառավարում
Վագր – ծառայության համակարգող, ղեկավարում և համակարգում է բիզնես տրամաբանության և կլաստերների միջև տեղեկատվության փոխանակումը:
XVPMմենեջեր – կլաստերի տարրերի կառավարում` հանգույցներ, պահեստավորում, ցանց և վիրտուալ մեքենաներ:
XVPA գործակալ – հանգույցների վրա տեղադրված գործակալ՝ XVPManager-ի հետ փոխազդելու համար

Մենք նախատեսում ենք հոդվածաշարում ներառել յուրաքանչյուր բաղադրիչի ճարտարապետության մասին մանրամասն պատմություն, եթե, իհարկե, թեման հետաքրքրություն առաջացնի։

FCO-ի հիմնական առավելությունը բխում է նրա «արկղային» բնույթից: Պարզությունն ու մինիմալիզմը ձեր ծառայության մեջ են: Կառավարման հանգույցի համար Ubuntu-ում հատկացված է մեկ վիրտուալ մեքենա, որի մեջ տեղադրված են բոլոր անհրաժեշտ փաթեթները։ Բոլոր կարգավորումները տեղադրվում են կազմաձևման ֆայլերում՝ փոփոխական արժեքի տեսքով.

# cat /etc/extility/config/vars
…
export LIMIT_MAX_LIST_ADMIN_DEFAULT="30000"
export LIMIT_MAX_LIST_USER_DEFAULT="200"
export LOGDIR="/var/log/extility"
export LOG_FILE="misc.log"
export LOG_FILE_LOG4JHOSTBILLMODULE="hostbillmodule.log"
export LOG_FILE_LOG4JJADE="jade.log"
export LOG_FILE_LOG4JTL="tigerlily.log"
export LOG_FILE_LOG4JXVP="xvpmanager.log"
export LOG_FILE_VARS="misc.log"
…

Ամբողջ կոնֆիգուրացիան սկզբում խմբագրվում է կաղապարներով, այնուհետև գործարկվում է գեներատորը
#build-config, որը կստեղծի vars ֆայլ և կհրավիրի ծառայություններին նորից կարդալ կազմաձևը: Օգտվողի միջերեսը գեղեցիկ է և հեշտությամբ կարելի է բրենդավորել:

Ինչպես տեսնում եք, ինտերֆեյսը բաղկացած է վիջեթներից, որոնք կարող են կառավարվել օգտագործողի կողմից: Նա կարող է հեշտությամբ ավելացնել/հեռացնել վիջեթներ էջից՝ դրանով իսկ ստեղծելով իրեն անհրաժեշտ վահանակը։

Չնայած իր փակ բնույթին, FCO-ն խիստ հարմարեցվող համակարգ է: Այն ունի մեծ թվով պարամետրեր և մուտքի կետեր աշխատանքային հոսքը փոխելու համար.

Աջակցվում են հատուկ պլագիններ, օրինակ՝ կարող եք գրել ձեր սեփական վճարման եղանակը կամ ձեր սեփական արտաքին ռեսուրսը՝ օգտվողին տրամադրելու համար։
Աջակցվում են որոշակի իրադարձությունների հատուկ գործարկիչներ, օրինակ՝ առաջին վիրտուալ մեքենան հաճախորդին ավելացնելով, երբ այն ստեղծվի
Աջակցվում են ինտերֆեյսի հարմարեցված վիդջեթները, օրինակ՝ YouTube-ի տեսանյութի տեղադրումն անմիջապես օգտատիրոջ միջերեսում:

Բոլոր հարմարեցումները գրված են FDL-ով, որը հիմնված է Lua-ի վրա: Եթե դուք ճանաչում եք Լուային, ապա FDL-ի հետ խնդիրներ չեն լինի:

Ահա մեր կողմից օգտագործվող ամենապարզ գործարկիչներից մեկի օրինակը: Այս գործարկիչը թույլ չի տալիս օգտվողներին կիսվել իրենց սեփական պատկերներով այլ հաճախորդների հետ: Մենք դա անում ենք, որպեսզի մեկ օգտատեր չստեղծի վնասակար պատկեր այլ օգտատերերի համար:

function register()
    return {"pre_user_api_publish"}
end
   
function pre_user_api_publish(p)  
    if(p==nil) then
        return{
            ref = "cancelPublishImage",
            name = "Cancel publishing",
            description = "Cancel all user’s images publishing",
            triggerType = "PRE_USER_API_CALL",
            triggerOptions = {"publishResource", "publishImage"},
            api = "TRIGGER",
            version = 1,
        }
    end

    -- Turn publishing off
    return {exitState = "CANCEL"}
   
end

Գրանցման գործառույթը կկանչվի FCO միջուկի կողմից: Այն կվերադարձնի կանչվող ֆունկցիայի անունը: Այս ֆունկցիայի «p» պարամետրը պահպանում է կանչի համատեքստը, և առաջին անգամ կանչվելիս այն դատարկ կլինի (զրոյական): Ինչը մեզ թույլ կտա գրանցել մեր ձգան: TriggerType-ում մենք նշում ենք, որ գործարկիչը գործարկվել է ԱՌԱՋ հրապարակման գործողությունից և ազդում է միայն օգտատերերի վրա: Իհարկե, մենք թույլ ենք տալիս համակարգի ադմինիստրատորներին հրապարակել ամեն ինչ: TriggerOptions-ում մենք մանրամասնում ենք այն գործողությունները, որոնց համար գործարկվելու է գործարկիչը:

Եվ գլխավորը վերադարձն է {exitState = “CANCEL”}, ինչի պատճառով էլ մշակվել է ձգան: Այն կվերադարձնի ձախողումը, երբ օգտվողը փորձի կիսել իր պատկերը կառավարման վահանակում:

FCO ճարտարապետության մեջ ցանկացած օբյեկտ (սկավառակ, սերվեր, պատկեր, ցանց, ցանցային ադապտեր և այլն) ներկայացված է որպես ռեսուրսների միավոր, որն ունի ընդհանուր պարամետրեր.

Ռեսուրս UUID
ռեսուրսի անվանումը
ռեսուրսի տեսակը
Ռեսուրսի սեփականատեր UUID
ռեսուրսի կարգավիճակը (ակտիվ, ոչ ակտիվ)
ռեսուրսների մետատվյալներ
ռեսուրսների բանալիներ
Ապրանքի UUID, որին պատկանում է ռեսուրսը
ռեսուրս VDC

Սա շատ հարմար է API-ով աշխատելիս, երբ բոլոր ռեսուրսներն աշխատում են նույն սկզբունքով։ Ապրանքները կազմաձևվում են մատակարարի կողմից և պատվիրվում են հաճախորդի կողմից: Քանի որ մեր հաշիվը կողքից է, հաճախորդը կարող է ազատորեն ցանկացած ապրանք պատվիրել վահանակից: Այն կհաշվարկվի ավելի ուշ բիլինգում: Ապրանքը կարող է լինել ժամում IP հասցե, մեկ ժամում լրացուցիչ ԳԲ սկավառակ կամ պարզապես սերվեր:

Բանալիները կարող են օգտագործվել որոշակի ռեսուրսներ նշելու համար՝ դրանց հետ աշխատելու տրամաբանությունը փոխելու համար: Օրինակ՝ Weight ստեղնով մենք կարող ենք նշել երեք ֆիզիկական հանգույց և նույն բանալիով նշել որոշ հաճախորդներ՝ այդպիսով այդ հանգույցներն անձամբ հատկացնելով այս հաճախորդներին: Մենք օգտագործում ենք այս մեխանիզմը VIP հաճախորդների համար, ովքեր չեն սիրում իրենց VM-ի կողքին գտնվող հարեւաններին: Ֆունկցիոնալությունը ինքնին կարող է օգտագործվել շատ ավելի լայնորեն:

Լիցենզավորման մոդելը ներառում է վճարում ֆիզիկական հանգույցի յուրաքանչյուր պրոցեսորային միջուկի համար: Արժեքի վրա ազդում է նաև կլաստերի տեսակների քանակը: Եթե դուք նախատեսում եք միասին օգտագործել KVM և VMware, օրինակ, լիցենզիայի արժեքը կբարձրանա:

FCO-ն լիարժեք արտադրանք է, նրա ֆունկցիոնալությունը շատ հարուստ է, ուստի մենք նախատեսում ենք պատրաստել միանգամից մի քանի հոդված՝ ցանցի մասի գործունեության մանրամասն նկարագրությամբ:

Մի քանի տարի աշխատելով այս նվագախմբի հետ՝ կարող ենք այն նշել որպես շատ հարմար։ Ավաղ, արտադրանքը առանց թերությունների չէ.

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

ԸՆԴԱՄԵՆԸ: Ընդհանուր առմամբ, արտադրանքի տպավորությունները լավ են: Մենք մշտական կապի մեջ ենք նվագախմբի մշակողների հետ։ Տղաները տրամադրված են կառուցողական համագործակցության։

Չնայած իր պարզությանը, FCO-ն ունի լայն ֆունկցիոնալություն: Հետագա հոդվածներում մենք նախատեսում ենք ավելի խորանալ հետևյալ թեմաների մեջ.

ցանցեր FCO-ում
ապահովելով կենդանի վերականգնման և FQP արձանագրություն
գրել ձեր սեփական պլագինները և վիդջեթները
միացնելով լրացուցիչ ծառայություններ, ինչպիսիք են Load Balancer-ը և Acronis-ը
կրկնօրինակում
հանգույցների կազմաձևման և կազմաձևման միասնական մեխանիզմ
վիրտուալ մեքենայի մետատվյալների մշակում

ԶՅ Գրեք մեկնաբանություններում, եթե ձեզ հետաքրքրում է այլ ասպեկտներ։ Մնացեք մեզ հետ!

Source: www.habr.com

Flexiant Cloud Orchestrator. ինչով է այն գալիս

Добавить комментарий Չեղարկել պատասխանել