Բեռնվածության հավասարակշռում Openstack-ում

Խոշոր ամպային համակարգերում հատկապես սուր է հաշվողական ռեսուրսների վրա բեռի ավտոմատ հավասարակշռման կամ համահարթեցման հարցը։ Tionix-ը (ամպային ծառայությունների մշակող և օպերատոր, Ռոստելեկոմ ընկերությունների խմբի մաս) նույնպես հոգացել է այս հարցը։

Եվ քանի որ մեր հիմնական զարգացման հարթակը Openstack-ն է, և մենք, ինչպես բոլոր մարդիկ, ծույլ ենք, որոշվեց ընտրել արդեն հարթակի մեջ ներառված ինչ-որ պատրաստի մոդուլ։ Մեր ընտրությունը ընկավ Watcher-ի վրա, որը մենք որոշեցինք օգտագործել մեր կարիքների համար:

Նախ, եկեք նայենք տերմիններին և սահմանումներին:

Տերմիններ և սահմանումներ

Նպատակ մարդու կողմից ընթեռնելի, դիտելի և չափելի վերջնական արդյունք է, որին պետք է հասնել: Յուրաքանչյուր նպատակին հասնելու համար կա մեկ կամ մի քանի ռազմավարություն: Ռազմավարությունը ալգորիթմի իրականացումն է, որն ի վիճակի է լուծում գտնել տվյալ նպատակի համար:

Գործողություն տարրական խնդիր է, որը փոխում է OpenStack կլաստերի թիրախային կառավարվող ռեսուրսի ներկայիս վիճակը, օրինակ՝ վիրտուալ մեքենայի տեղափոխում (միգրացիա), հանգույցի հզորության վիճակի փոփոխություն (change_node_power_state), nova ծառայության վիճակի փոփոխություն (change_nova_service_state): ), համի փոփոխություն (չափափոխել), NOP հաղորդագրությունների գրանցում (nop), գործողության բացակայություն որոշակի ժամանակի համար՝ դադար (քնում), սկավառակի փոխանցում (volume_migrate):

Գործողության պլան - կոնկրետ նպատակին հասնելու համար որոշակի կարգով իրականացվող գործողությունների կոնկրետ հոսք: Գործողությունների ծրագիրը պարունակում է նաև գնահատված գլոբալ կատարողականություն՝ կատարողականի մի շարք ցուցանիշներով: Watcher-ի կողմից հաջող աուդիտի արդյունքում ստեղծվում է գործողությունների ծրագիր, որի արդյունքում օգտագործված ռազմավարությունը լուծում է գտնում նպատակին հասնելու համար: Գործողությունների պլանը բաղկացած է հաջորդական գործողությունների ցանկից:

Աուդիտ կլաստերի օպտիմալացման խնդրանք է: Օպտիմալացումն իրականացվում է տվյալ կլաստերում մեկ նպատակին հասնելու համար: Յուրաքանչյուր հաջող աուդիտի համար Watcher-ը ստեղծում է Գործողությունների պլան:

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

Աուդիտի ձևանմուշ — աուդիտ սկսելու համար պահված կարգավորումների հավաքածու: Կաղապարներ են անհրաժեշտ նույն կարգավորումներով մի քանի անգամ աուդիտներ իրականացնելու համար: Կաղապարն անպայման պետք է պարունակի աուդիտի նպատակը, եթե ռազմավարությունները հստակեցված չեն, ապա ընտրվում են ամենահարմար գոյություն ունեցող ռազմավարությունները:

Կլաստեր ֆիզիկական մեքենաների հավաքածու է, որոնք ապահովում են հաշվողական, պահեստային և ցանցային ռեսուրսներ և կառավարվում են նույն OpenStack կառավարման հանգույցի կողմից:

Կլաստերային տվյալների մոդել (CDM) կլաստերի կողմից կառավարվող ռեսուրսների ներկայիս վիճակի և տոպոլոգիայի տրամաբանական ներկայացումն է:

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

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

Գնահատող շարժիչ գործարկվող ֆայլ է, որն ունի հստակ սահմանված մուտքեր, լավ սահմանված ելքեր և կատարում է զուտ մաթեմատիկական առաջադրանք: Այսպիսով, հաշվարկը անկախ է այն միջավայրից, որտեղ այն իրականացվում է. այն նույն արդյունքը կտա ցանկացած վայրում:

Watcher Planner - Watcher որոշումների կայացման շարժիչի մի մասը: Այս մոդուլը վերցնում է ռազմավարության կողմից ստեղծված գործողությունների մի շարք և ստեղծում աշխատանքային հոսքի պլան, որը սահմանում է, թե ինչպես ժամանակին պլանավորել այս տարբեր գործողությունները և յուրաքանչյուր գործողության համար, որոնք են նախապայմանները:

Watcher-ի նպատակներն ու ռազմավարությունները

Նպատակ
ստրատեգիա

Կեղծ գոլ
Կեղծ ռազմավարություն 

Կեղծ ռազմավարություն՝ օգտագործելով գնահատման շարժիչների նմուշները

Կեղծ ռազմավարություն՝ չափափոխելով

Փրկելու Էներգիա
Էներգախնայողության ռազմավարություն

Սերվերի համախմբում
Հիմնական անցանց սերվերի համախմբում

VM ծանրաբեռնվածության համախմբման ռազմավարություն

Աշխատանքային ծանրաբեռնվածության հավասարակշռում
Աշխատանքային ծանրաբեռնվածության հավասարակշռման միգրացիոն ռազմավարություն

Պահպանման հզորության հաշվեկշռի ռազմավարություն

Աշխատանքի ծանրաբեռնվածության կայունացում

Աղմկոտ հարեւան
Աղմկոտ հարեւան

Ջերմային օպտիմիզացում
Ելքի ջերմաստիճանի վրա հիմնված ռազմավարություն

Օդի հոսքի օպտիմալացում
Օդի հոսքի միգրացիայի միասնական ռազմավարություն

Սարքավորումների սպասարկում
Գոտու միգրացիա

Unclassified
Actuator

Կեղծ գոլ — վերապահված նպատակ, որն օգտագործվում է թեստավորման նպատակով:

Առնչվող ռազմավարություններ. Կեղծ ռազմավարություն, կեղծ ռազմավարություն՝ օգտագործելով գնահատման շարժիչների նմուշները և չափափոխվող կեղծ ռազմավարությունը: Dummy ռազմավարությունը կեղծ ռազմավարություն է, որն օգտագործվում է Tempest-ի միջոցով ինտեգրման փորձարկման համար: Այս ռազմավարությունը չի ապահովում որևէ օգտակար օպտիմալացում, դրա միակ նպատակը Tempest թեստերի օգտագործումն է:

Կեղծ ռազմավարություն՝ օգտագործելով նմուշների գնահատման շարժիչներ - ռազմավարությունը նման է նախորդին, միակ տարբերությունը նմուշի «գնահատման շարժիչի» օգտագործումն է, որն իրականացնում է հաշվարկներ՝ օգտագործելով մեքենայական ուսուցման մեթոդները:

Կեղծ ռազմավարություն չափափոխման հետ - ռազմավարությունը նման է նախորդին, միակ տարբերությունը համը փոխելու օգտագործումն է (միգրացիա և չափափոխում):

Արտադրության մեջ չի օգտագործվում։

Փրկելու Էներգիա - նվազագույնի հասցնել էներգիայի սպառումը: Այս նպատակի Էներգիայի խնայողության ռազմավարությունը, VM Workload Consolidation Strategy-ի հետ միասին (Server Consolidation), ի վիճակի է էներգիայի դինամիկ կառավարման (DPM) գործառույթների, որոնք խնայում են էներգիան՝ դինամիկ կերպով համախմբելով աշխատանքային բեռները նույնիսկ ռեսուրսների ցածր օգտագործման ժամանակաշրջաններում. վիրտուալ մեքենաները տեղափոխվում են ավելի քիչ հանգույցներ: , և անհարկի հանգույցներն անջատված են: Համախմբումից հետո ռազմավարությունը որոշում է կայացնում միացնել/անջատել հանգույցները նշված պարամետրերին համապատասխան. «min_free_hosts_num» - անվճար ակտիվացված հանգույցների թիվը, որոնք սպասում են բեռնմանը, և «free_used_percent»՝ անվճար միացված հոսթների տոկոսը հանգույցների թիվը, որոնք զբաղեցնում են մեքենաները. Որպեսզի ռազմավարությունն աշխատի, պետք է լինի միացրեց և կազմաձևեց Ironic-ը հանգույցների վրա հոսանքի ցիկլը կարգավորելու համար:

Ռազմավարության պարամետրեր

պարամետր
Тип
լռելյայն
описание

free_used_percent
Թիվ
10.0
ազատ հաշվողական հանգույցների քանակի հարաբերակցությունը վիրտուալ մեքենաներով հաշվողական հանգույցների թվին

min_free_hosts_num
Int
1
անվճար հաշվողական հանգույցների նվազագույն քանակը

Ամպը պետք է ունենա առնվազն երկու հանգույց: Օգտագործված մեթոդը հանգույցի հզորության վիճակի փոփոխությունն է (change_node_power_state): Ռազմավարությունը չի պահանջում չափումների հավաքում:

Սերվերի համախմբում - նվազագույնի հասցնել հաշվողական հանգույցների քանակը (համախմբում): Այն ունի երկու ռազմավարություն՝ Basic Offline Server Consolidation և VM Workload Consolidation Strategy:

Հիմնական Offline Server Consolidation ռազմավարությունը նվազագույնի է հասցնում օգտագործվող սերվերների ընդհանուր թիվը և նաև նվազագույնի է հասցնում միգրացիաների քանակը:

Հիմնական ռազմավարությունը պահանջում է հետևյալ չափումները.

չափումներ
ծառայություն
պլագիններ
մեկնաբանություն

compute.node.cpu.percent
օդաչափ
ոչ մեկը
 

cpu_util
օդաչափ
ոչ մեկը
 

Ռազմավարության պարամետրեր. migration_ttempts - կոմբինացիաների քանակ՝ անջատման համար պոտենցիալ թեկնածուների որոնման համար (կանխադրված, 0, առանց սահմանափակումների), ժամանակաշրջան - ժամանակային միջակայքը վայրկյաններով՝ մետրային տվյալների աղբյուրից ստատիկ ագրեգացիա ստանալու համար (կանխադրված, 700):

Օգտագործված մեթոդներ՝ միգրացիա, նովայի ծառայության վիճակի փոփոխություն (change_nova_service_state):

VM Workload Consolidation Strategy-ը հիմնված է առաջին պիտանի էվրիստիկայի վրա, որը կենտրոնանում է CPU-ի չափված ծանրաբեռնվածության վրա և փորձում է նվազագույնի հասցնել այն հանգույցները, որոնք չափազանց շատ կամ շատ քիչ բեռ ունեն՝ հաշվի առնելով ռեսուրսների հզորության սահմանափակումները: Այս ռազմավարությունը լուծում է տալիս, որը հանգեցնում է կլաստերի ռեսուրսների ավելի արդյունավետ օգտագործմանը՝ օգտագործելով հետևյալ չորս քայլերը.

1. Բեռնաթափման փուլ - գերօգտագործված ռեսուրսների վերամշակում;
2. Համախմբման փուլ - չօգտագործված ռեսուրսների կառավարում;
3. Լուծման օպտիմիզացում - միգրացիաների քանակի կրճատում;
4. Չօգտագործված հաշվողական հանգույցների անջատում:

Ռազմավարությունը պահանջում է հետևյալ չափանիշները.

չափումներ
ծառայություն
պլագիններ
մեկնաբանություն

հիշողություն
օդաչափ
ոչ մեկը
 

disk.root.size
օդաչափ
ոչ մեկը
 

Հետևյալ չափորոշիչները կամընտիր են, բայց առկայության դեպքում կբարելավեն ռազմավարության ճշգրտությունը.

չափումներ
ծառայություն
պլագիններ
մեկնաբանություն

հիշողություն.բնակիչ
օդաչափ
ոչ մեկը
 

cpu_util
օդաչափ
ոչ մեկը
 

Ռազմավարության պարամետրեր. ժամանակաշրջան — ժամանակային ընդմիջում վայրկյաններով՝ մետրային տվյալների աղբյուրից ստատիկ ագրեգացիա ստանալու համար (կանխադրված՝ 3600):

Օգտագործում է նույն մեթոդները, ինչ նախորդ ռազմավարությունը: Ավելի մանրամասն այստեղ.

Աշխատանքային ծանրաբեռնվածության հավասարակշռում — հավասարակշռել աշխատանքային բեռը հաշվողական հանգույցների միջև: Նպատակն ունի երեք ռազմավարություն՝ աշխատանքային ծանրաբեռնվածության մնացորդի միգրացիոն ռազմավարություն, ծանրաբեռնվածության կայունացում, պահեստային կարողությունների մնացորդի ռազմավարություն:

Աշխատանքային ծանրաբեռնվածության մնացորդի միգրացիոն ռազմավարությունն իրականացնում է վիրտուալ մեքենաների միգրացիաներ՝ հիմնված հյուրընկալող վիրտուալ մեքենայի ծանրաբեռնվածության վրա: Միգրացիայի որոշումը կայացվում է, երբ հանգույցի CPU-ի կամ RAM-ի % օգտագործումը գերազանցում է նշված շեմը: Այս դեպքում տեղափոխված վիրտուալ մեքենան պետք է հանգույցը մոտեցնի բոլոր հանգույցների միջին ծանրաբեռնվածությանը։

Պահանջներ

• Ֆիզիկական պրոցեսորների օգտագործում;
• Առնվազն երկու ֆիզիկական հաշվարկային հանգույց;
• Տեղադրեց և կազմաձևեց Ceilometer բաղադրիչը՝ ceilometer-agent-compute, որն աշխատում է յուրաքանչյուր հաշվարկային հանգույցի վրա, և Ceilometer API-ն, ինչպես նաև հավաքելով հետևյալ չափումները.

չափումներ
ծառայություն
պլագիններ
մեկնաբանություն

cpu_util
օդաչափ
ոչ մեկը
 

հիշողություն.բնակիչ
օդաչափ
ոչ մեկը
 

Ռազմավարության պարամետրեր.

պարամետր
Тип
լռելյայն
описание

չափումներ
String
'cpu_util'
Հիմնական չափանիշներն են՝ «cpu_util», «memory.resident»:

շեմը
Թիվ
25.0
Աշխատանքային ծանրաբեռնվածության շեմը միգրացիայի համար:

ժամանակաշրջան
Թիվ
300
Կուտակային ժամանակաշրջան Ceilometer.

Օգտագործված մեթոդը միգրացիան է։

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

Պահանջներ

• Ֆիզիկական պրոցեսորների օգտագործում;
• Առնվազն երկու ֆիզիկական հաշվարկային հանգույց;
• Տեղադրեց և կազմաձևեց Ceilometer բաղադրիչը՝ ceilometer-agent-compute, որն աշխատում է յուրաքանչյուր հաշվարկային հանգույցի վրա, և Ceilometer API-ն, ինչպես նաև հավաքելով հետևյալ չափումները.

չափումներ
ծառայություն
պլագիններ
մեկնաբանություն

cpu_util
օդաչափ
ոչ մեկը
 

հիշողություն.բնակիչ
օդաչափ
ոչ մեկը
 

Storage Capacity Balance Strategy (ռազմավարությունն իրականացվում է Queens-ից սկսած) - ռազմավարությունը փոխանցում է սկավառակներ՝ կախված Cinder լողավազանների ծանրաբեռնվածությունից: Փոխանցման որոշում է կայացվում, երբ լողավազանի օգտագործման մակարդակը գերազանցում է սահմանված շեմը: Տեղափոխվող սկավառակը պետք է մոտեցնի լողավազանը բոլոր Cinder լողավազանների միջին ծանրաբեռնվածությանը:

Պահանջներ և սահմանափակումներ

• Առնվազն երկու Cinder լողավազան;
• Սկավառակի միգրացիայի հնարավորություն։
• Կլաստերային տվյալների մոդել - Cinder կլաստերի տվյալների մոդելի հավաքիչ:

Ռազմավարության պարամետրեր.

պարամետր
Тип
լռելյայն
описание

ծավալի_շեմ
Թիվ
80.0
Սկավառակների շեմային արժեքը ծավալների հավասարակշռման համար:

Օգտագործված մեթոդը սկավառակի միգրացիա է (volume_migrate):

Աղմկոտ հարևան - Բացահայտեք և տեղափոխեք «աղմկոտ հարևանին»՝ ցածր առաջնահերթության վիրտուալ մեքենա, որը բացասաբար է անդրադառնում բարձր առաջնահերթ վիրտուալ մեքենայի աշխատանքի վրա՝ IPC-ի առումով՝ գերօգտագործելով Վերջին մակարդակի քեշը: Սեփական ռազմավարություն. Noisy Neighbor (ռազմավարության պարամետրը օգտագործվում է cache_threshold (կանխադրված արժեքը 35 է), երբ կատարողականությունը իջնում ​​է նշված արժեքին, միգրացիան սկսվում է: Որպեսզի ռազմավարությունը աշխատի, միացված է: ՍՊԸ (Վերջին մակարդակի քեշ) չափումներ, վերջին Intel սերվերը CMT աջակցությամբ, ինչպես նաև հավաքելով հետևյալ ցուցանիշները.

չափումներ
ծառայություն
պլագիններ
մեկնաբանություն

cpu_l3_cache
օդաչափ
ոչ մեկը
Պահանջվում է Intel CMT.

Կլաստերային տվյալների մոդել (լռելյայն). Nova կլաստերային տվյալների մոդելի հավաքիչ: Օգտագործված մեթոդը միգրացիան է։

Այս նպատակի հետ աշխատելը Dashboard-ի միջոցով ամբողջությամբ չի իրականացվում Queens-ում:

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

Որպեսզի ռազմավարությունն աշխատի, ձեզ անհրաժեշտ է սերվեր, որտեղ տեղադրված և կազմաձևված է Intel Power Node Manager-ը 3.0 կամ ավելի ուշ, ինչպես նաև հավաքելով հետևյալ ցուցանիշները.

չափումներ
ծառայություն
պլագիններ
մեկնաբանություն

hardware.ipmi.node.outlet_temperature
օդաչափ
IPMI
 

Ռազմավարության պարամետրեր.

պարամետր
Тип
լռելյայն
описание

շեմը
Թիվ
35.0
Միգրացիայի ջերմաստիճանի շեմը.

ժամանակաշրջան
Թիվ
30
Ժամանակային միջակայքը, վայրկյաններով, մետրային տվյալների աղբյուրից վիճակագրական ագրեգացիա ստանալու համար:

Օգտագործված մեթոդը միգրացիան է։

Օդի հոսքի օպտիմալացում - Օպտիմալացնել օդափոխության ռեժիմը: Սեփական ռազմավարություն - միասնական օդային հոսք՝ օգտագործելով կենդանի միգրացիա: Ռազմավարությունը խթանում է վիրտուալ մեքենայի միգրացիան, երբ սերվերի օդափոխիչից օդի հոսքը գերազանցում է սահմանված շեմը:

Որպեսզի ռազմավարությունն աշխատի, ձեզ հարկավոր է.

• Սարքավորում. հաշվողական հանգույցներ < աջակցող NodeManager 3.0;
• Առնվազն երկու հաշվողական հանգույց;
• Յուրաքանչյուր հաշվողական հանգույցի վրա տեղադրված և կազմաձևված ceilometer-agent-comute և Ceilometer API բաղադրիչը, որը կարող է հաջողությամբ հաղորդել այնպիսի չափումներ, ինչպիսիք են օդի հոսքը, համակարգի հզորությունը, մուտքի ջերմաստիճանը.

չափումներ
ծառայություն
պլագիններ
մեկնաբանություն

hardware.ipmi.node.airflow
օդաչափ
IPMI
 

hardware.ipmi.node.temperature
օդաչափ
IPMI
 

hardware.ipmi.node.power
օդաչափ
IPMI
 

Որպեսզի ռազմավարությունն աշխատի, ձեզ հարկավոր է սերվեր, որը տեղադրված է և կազմաձևված է Intel Power Node Manager 3.0 կամ ավելի նոր տարբերակով:

Սահմանափակումներ. Հայեցակարգը նախատեսված չէ արտադրության համար:

Առաջարկվում է օգտագործել այս ալգորիթմը շարունակական աուդիտով, քանի որ մեկ կրկնության համար նախատեսվում է տեղափոխել միայն մեկ վիրտուալ մեքենա:

Հնարավոր են կենդանի միգրացիաներ։

Ռազմավարության պարամետրեր.

պարամետր
Тип
լռելյայն
описание

շեմ_օդային հոսք
Թիվ
400.0
Միգրացիոն միավորի օդային հոսքի շեմը 0.1CFM է

threshold_inlet_t
Թիվ
28.0
Մուտքի ջերմաստիճանի շեմը միգրացիայի որոշման համար

շեմ_իշխանություն
Թիվ
350.0
Համակարգի հզորության շեմը միգրացիայի որոշման համար

ժամանակաշրջան
Թիվ
30
Ժամանակային միջակայքը, վայրկյաններով, մետրային տվյալների աղբյուրից վիճակագրական ագրեգացիա ստանալու համար:

Օգտագործված մեթոդը միգրացիան է։

Սարքավորումների սպասարկում - ապարատային սպասարկում: Այս նպատակին առնչվող ռազմավարությունը գոտիների միգրացիան է: Ռազմավարությունը գործիք է վիրտուալ մեքենաների և սկավառակների արդյունավետ ավտոմատ և նվազագույն միգրացիայի համար՝ սարքավորումների պահպանման անհրաժեշտության դեպքում: Ռազմավարությունը կառուցում է գործողությունների պլան՝ կշիռներին համապատասխան. գործողությունների մի շարք, որոնք ավելի մեծ կշիռ ունեն, ծրագրվելու են մյուսներից առաջ: Կազմաձևման երկու տարբերակ կա՝ action_weights և parallelization:

Սահմանափակումներ. գործողությունների կշիռները և զուգահեռացումը պետք է կազմաձևվեն:

Ռազմավարության պարամետրեր.

պարամետր
Тип
լռելյայն
описание

հաշվողական_հանգույցներ
դասավորություն
Ոչ մեկը
Հաշվարկեք հանգույցները միգրացիայի համար:

պահեստային_լողավազաններ
դասավորություն
Ոչ մեկը
Պահպանման հանգույցներ միգրացիայի համար:

զուգահեռ_ընդհանուր
ամբողջ թիվ
6
Գործողությունների ընդհանուր թիվը, որոնք պետք է կատարվեն զուգահեռ:

զուգահեռ_մեկ_հանգույց
ամբողջ թիվ
2
Յուրաքանչյուր հաշվողական հանգույցի համար զուգահեռ կատարված գործողությունների քանակը:

parallel_per_pool
ամբողջ թիվ
2
Յուրաքանչյուր պահեստային լողավազանի համար զուգահեռ կատարված գործողությունների քանակը:

առաջնություն
օբյեկտ
Ոչ մեկը
Վիրտուալ մեքենաների և սկավառակների առաջնահերթությունների ցանկը:

հետ_կցված_հատորով
բուլյան
Կեղծ
Սխալ. վիրտուալ մեքենաները կփոխանցվեն բոլոր սկավառակների տեղափոխումից հետո: Ճիշտ է. վիրտուալ մեքենաները կփոխանցվեն բոլոր միացված սկավառակների տեղափոխումից հետո:

Հաշվողական հանգույցների զանգվածի տարրեր.

պարամետր
Тип
լռելյայն
описание

src_node
լարային
Ոչ մեկը
Հաշվարկային հանգույց, որտեղից վիրտուալ մեքենաները տեղափոխվում են (պահանջվում է):

dst_node
լարային
Ոչ մեկը
Հաշվարկեք այն հանգույցը, որտեղ վիրտուալ մեքենաները տեղափոխվում են:

Պահպանման հանգույցի զանգվածի տարրեր.

պարամետր
Тип
լռելյայն
описание

src_pool
լարային
Ոչ մեկը
Պահեստային ավազան, որտեղից սկավառակները տեղափոխվում են (պահանջվում է):

dst_pool
լարային
Ոչ մեկը
Պահեստային լողավազան, որտեղ սկավառակները տեղափոխվում են:

src_type
լարային
Ոչ մեկը
Բնօրինակ սկավառակի տեսակը (պարտադիր է):

dst_type
լարային
Ոչ մեկը
Ստացված սկավառակի տեսակը (պահանջվում է):

Օբյեկտի առաջնահերթ տարրեր.

պարամետր
Тип
լռելյայն
описание

նախագիծ
դասավորություն
Ոչ մեկը
Նախագծերի անվանումները.

հաշվողական_հանգույց
դասավորություն
Ոչ մեկը
Հաշվարկեք հանգույցների անունները:

պահեստային_լողավազան
դասավորություն
Ոչ մեկը
Պահպանման լողավազանների անունները.

հաշվարկել
թվարկել
Ոչ մեկը
Վիրտուալ մեքենայի պարամետրերը [«vcpu_num», «mem_size», «disk_size», «created_at»]:

պահեստ
թվարկել
Ոչ մեկը
Սկավառակի պարամետրերը [«չափ», «created_at»]:

Օգտագործված մեթոդներն են վիրտուալ մեքենայի միգրացիան, սկավառակի միգրացիան:

Unclassified - օժանդակ նպատակ, որն օգտագործվում է ռազմավարության մշակման գործընթացը հեշտացնելու համար: Չի պարունակում առանձնահատկություններ և կարող է օգտագործվել, երբ ռազմավարությունը դեռ կապված չէ գոյություն ունեցող նպատակի հետ: Այս նպատակը կարող է օգտագործվել նաև որպես անցումային կետ: Այս նպատակին առնչվող ռազմավարությունը Actuator-ն է:   

Նոր նպատակի ստեղծում

Watcher Decision Engine ունի «արտաքին նպատակ» հավելվածի ինտերֆեյս, որը հնարավորություն է տալիս ինտեգրել արտաքին նպատակ, որը կարելի է հասնել ռազմավարության միջոցով:

Նախքան նոր նպատակ ստեղծելը, դուք պետք է համոզվեք, որ գոյություն ունեցող ոչ մի նպատակ չի համապատասխանում ձեր կարիքներին:

Նոր փլագինի ստեղծում

Նոր թիրախ ստեղծելու համար պետք է՝ ընդլայնել թիրախային դասը, ներդնել դասի մեթոդ ստանալ_անուն () վերադարձնելու նոր թիրախի եզակի ID-ն, որը ցանկանում եք ստեղծել: Այս եզակի նույնացուցիչը պետք է համապատասխանի մուտքի կետի անվանը, որը դուք կհայտարարեք ավելի ուշ:

Հաջորդը դուք պետք է իրականացնեք դասի մեթոդը get_display_name () վերադարձնելու թիրախի թարգմանված ցուցադրական անունը, որը ցանկանում եք ստեղծել (մի օգտագործեք փոփոխական թարգմանված տողը վերադարձնելու համար, որպեսզի այն ավտոմատ կերպով հավաքվի թարգմանության գործիքի կողմից):

Իրականացնել դասի մեթոդ get_translatable_display_name()վերադարձնելու ձեր նոր թիրախի թարգմանության բանալին (իրականում ցուցադրվող անգլերեն անունը): Վերադարձվող արժեքը պետք է համապատասխանի get_display_name() թարգմանված տողին:

Իրականացրեք նրա մեթոդը get_efficacy_specification ()վերադարձնելու արդյունավետության բնութագրերը ձեր թիրախի համար: Get_efficacy_specification() մեթոդը վերադարձնում է Watcher-ի կողմից տրամադրված Unclassified() օրինակը: Այս կատարողականի ճշգրտումը օգտակար է ձեր նպատակը մշակելու գործընթացում, քանի որ այն համապատասխանում է դատարկ ճշգրտմանը:

→ Կարդալ ավելին այստեղ

Watcher ճարտարապետություն (ավելի մանրամասն) այստեղ).

Բաղադրիչներ

Watcher API - բաղադրիչ, որն իրականացնում է Watcher-ի տրամադրած REST API-ը: Փոխազդեցության մեխանիզմներ՝ CLI, Horizon plugin, Python SDK:

Watcher DB - Watcher տվյալների բազա:

Watcher Applier — բաղադրիչ, որն իրականացնում է Watcher Decision Engine բաղադրիչի կողմից ստեղծված գործողությունների պլանի կատարումը:

Watcher Decision Engine - Բաղադրիչ, որը պատասխանատու է աուդիտի նպատակին հասնելու համար հնարավոր օպտիմալացման գործողությունների մի շարք հաշվարկելու համար: Եթե ​​ռազմավարությունը նշված չէ, բաղադրիչն ինքնուրույն ընտրում է ամենահարմարը:

Watcher Metrics Publisher - Բաղադրիչ, որը հավաքում և հաշվարկում է որոշ չափումներ կամ իրադարձություններ և դրանք հրապարակում է CEP-ի վերջնական կետում: Բաղադրիչի ֆունկցիոնալությունը կարող է տրամադրվել նաև Ceilometer հրատարակչի կողմից:

Իրադարձությունների մշակման համալիր (CEP) շարժիչ — շարժիչ բարդ իրադարձությունների մշակման համար: Կատարման նկատառումներից ելնելով, կարող են լինել CEP Engine-ի մի քանի օրինակներ, որոնք աշխատում են միաժամանակ, որոնցից յուրաքանչյուրը մշակում է որոշակի տեսակի չափման/իրադարձություն: Watcher համակարգում CEP-ը գործարկում է երկու տեսակի գործողություններ. - ուղարկել համապատասխան իրադարձություններ Watcher Decision Engine-ին, երբ այս իրադարձությունը կարող է ազդել ընթացիկ օպտիմալացման ռազմավարության արդյունքի վրա, քանի որ Openstack կլաստերը ստատիկ համակարգ չէ:

Բաղադրիչները փոխազդում են՝ օգտագործելով AMQP արձանագրությունը:

→ Watcher-ի կարգավորում

Watcher-ի հետ փոխգործակցության սխեման

Watcher թեստի արդյունքները

1. Օպտիմալացում - Գործողությունների պլաններ 500 էջում (ինչպես մաքուր Queens-ում, այնպես էլ Tionix մոդուլներով ստենդում) այն հայտնվում է միայն աուդիտի մեկնարկից և գործողությունների պլան ստեղծելուց հետո, դատարկը բացվում է սովորաբար:
2. Գործողությունների մանրամասների ներդիրում կան սխալներ, հնարավոր չէ ստանալ աուդիտի նպատակն ու ռազմավարությունը (ինչպես մաքուր Queens-ում, այնպես էլ Tionix մոդուլներով ստենդում):
3. Dummy-ի (փորձարկման) նպատակով աուդիտները ստեղծվում և մեկնարկում են նորմալ, ստեղծվում են գործողությունների պլաններ:
4. Չդասակարգված նպատակի աուդիտները չեն ստեղծվում, քանի որ նպատակը ֆունկցիոնալ չէ և նախատեսված է նոր ռազմավարություններ ստեղծելիս միջանկյալ կազմաձևման համար:
5. Աշխատանքային ծանրաբեռնվածության հավասարակշռման (Պահեստային հզորության հաշվեկշռի ռազմավարություն) նպատակով աուդիտները հաջողությամբ ստեղծվում են, սակայն գործողությունների պլան չի ստեղծվում: Պահեստային լողավազանի օպտիմալացում չի պահանջվում:
6. Աշխատանքային ծանրաբեռնվածության հավասարակշռման նպատակի համար (Workload Balance Migration Strategy) աուդիտները հաջողությամբ ստեղծվում են, սակայն գործողությունների ծրագիր չի ստեղծվում:
7. Աշխատանքային ծանրաբեռնվածության հավասարակշռման (աշխատանքային կայունացման ռազմավարություն) ստուգումները ձախողվում են:
8. Աղմկոտ հարևան թիրախի աուդիտները հաջողությամբ են ստեղծվում, սակայն գործողությունների ծրագիր չի ստեղծվում:
9. Սարքավորումների սպասարկման նպատակով աուդիտները հաջողությամբ ստեղծվում են, գործողությունների պլանն ամբողջությամբ չի ստեղծվում (ստեղծվում են կատարողականի ցուցանիշներ, բայց գործողությունների ցանկն ինքնին չի ստեղծվում):
10. nova.conf կոնֆիգուրացիաներում (կանխադրված բաժնում compute_monitors = cpu.virt_driver) հաշվարկների և կառավարման հանգույցներում կատարված փոփոխությունները չեն ուղղում սխալները:
11. Սերվերի համախմբմանը (հիմնական ռազմավարությունը) ուղղված աուդիտները նույնպես ձախողվում են:
12. Սերվերի համախմբման նպատակով ստուգումները (VM ծանրաբեռնվածության համախմբման ռազմավարություն) ձախողվում են սխալմամբ: Տեղեկամատյաններում սխալ կա աղբյուրի տվյալների ստացման հարցում: Սխալի քննարկում, մասնավորապես այստեղ.
    Մենք փորձեցինք նշել Watcher-ը կազմաձևման ֆայլում (դա չօգնեց. Օպտիմիզացման բոլոր էջերի սխալի հետևանքով, կազմաձևման ֆայլի սկզբնական բովանդակությանը վերադառնալը չի ​​շտկում իրավիճակը).
    [watcher_strategies.basic] տվյալների աղբյուր = ceilometer, gnocchi
13. Էներգախնայողության ստուգումները ձախողվում են: Դատելով գերաններից՝ խնդիրը շարունակում է մնալ Ironic-ի բացակայությունը, այն չի աշխատի առանց baremetal ծառայության։
14. Ջերմային օպտիմալացման ստուգումները ձախողվում են: Հետագծումը նույնն է, ինչ սերվերի համախմբման համար (VM ծանրաբեռնվածության համախմբման ռազմավարություն) (աղբյուրի տվյալների սխալ)
15. Օդային հոսքի օպտիմալացման նպատակով ստուգումները ձախողվում են սխալմամբ:

Հանդիպում են նաև աուդիտի ավարտման հետևյալ սխալները. Հետագծում որոշում-engine.log տեղեկամատյաններում (կլաստերի վիճակը սահմանված չէ):

→ Սխալի քննարկում այստեղ

Ամփոփում

Մեր երկամսյա հետազոտության արդյունքը միանշանակ եզրակացություն էր, որ լիարժեք, աշխատանքային բեռների հավասարակշռման համակարգ ձեռք բերելու համար մենք այս մասում պետք է սերտորեն աշխատենք Openstack պլատֆորմի գործիքների կատարելագործման վրա:

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

Բայց այս մասին ավելի շատ՝ շարքի հաջորդ հոդվածներում:

Source: www.habr.com