Opennebula. Կարճ նշումներ

Բարեւ բոլորին. Այս հոդվածը գրվել է նրանց համար, ովքեր դեռևս տարված են վիրտուալացման պլատֆորմներ ընտրելու միջև և կարդալուց հետո «Մենք տեղադրել ենք proxmox և ընդհանուր առմամբ ամեն ինչ կարգին է, առանց մեկ ընդմիջման» շարքի հոդվածը կարդալուց հետո: Բայց այս կամ այն ​​լուծումը տեղադրելուց հետո հարց է առաջանում՝ ինչպե՞ս կարող եմ սա շտկել այստեղ, որպեսզի մոնիտորինգն ավելի հասկանալի լինի, իսկ այստեղ՝ վերահսկել կրկնօրինակները…: Եվ հետո գալիս է ժամանակը, և հասկանում ես, որ ուզում ես ինչ-որ ավելի ֆունկցիոնալ բան, կամ ուզում ես, որ քո համակարգի ներսում ամեն ինչ պարզ դառնա, և ոչ թե այս սև արկղը, կամ ուզում ես օգտագործել ավելին, քան հիպերվիզորն ու մի խումբ վիրտուալ մեքենաներ: Այս հոդվածը կպարունակի որոշ մտքեր և պրակտիկա՝ հիմնված Opennebula հարթակի վրա. ես ընտրեցի այն, որովհետև: այն ռեսուրսների նկատմամբ պահանջկոտ չէ, և ճարտարապետությունն այնքան էլ բարդ չէ:

Եվ այսպես, ինչպես տեսնում ենք, շատ ամպային պրովայդերներ աշխատում են kvm-ի վրա և արտաքին կապեր են ստեղծում կառավարող մեքենաների հետ։ Հասկանալի է, որ խոշոր հոսթերները գրում են իրենց շրջանակները ամպային ենթակառուցվածքի համար, օրինակ նույն ՅԱՆԴԵՔՍ-ը։ Ինչ-որ մեկը օգտագործում է openstack-ը և կապ է հաստատում դրա հիման վրա՝ SELECTEL, MAIL.RU: Բայց եթե դուք ունեք ձեր սեփական սարքաշարը և մասնագետների փոքր անձնակազմը, ապա սովորաբար ընտրում եք պատրաստի ինչ-որ բան՝ VMWARE, HYPER-V, կան անվճար և վճարովի լիցենզիաներ, բայց դա այն չէ, ինչի մասին մենք հիմա խոսում ենք: Եկեք խոսենք էնտուզիաստների մասին. սրանք նրանք են, ովքեր չեն վախենում առաջարկել և փորձել ինչ-որ նոր բան, չնայած այն հանգամանքին, որ ընկերությունը հստակ ասել է. ? Սարսափելի»: Բայց դուք կարող եք նախ կիրառել այս լուծումները փորձարկման նստարանին, և եթե դա բոլորին դուր է գալիս, ապա կարող եք բարձրացնել հետագա զարգացման և ավելի լուրջ միջավայրերում օգտագործելու հարցը:

Ահա նաև զեկույցի հղումը www.youtube.com/watch?v=47Mht_uoX3A այս հարթակի մշակման ակտիվ մասնակցից։

Թերևս այս հոդվածում ինչ-որ բան ավելորդ և արդեն հասկանալի կլինի փորձառու մասնագետի համար, և որոշ դեպքերում ես ամեն ինչ չեմ նկարագրի, քանի որ նմանատիպ հրամաններ և նկարագրություններ հասանելի են ինտերնետում: Սա պարզապես իմ փորձն է այս հարթակի հետ: Հուսով եմ, որ ակտիվ մասնակիցները մեկնաբանություններում կավելացնեն, թե ինչ կարելի է ավելի լավ անել և ինչ սխալներ եմ թույլ տվել։ Բոլոր գործողությունները տեղի են ունեցել տնային ստենդում, որը բաղկացած է տարբեր բնութագրերով 3 ԱՀ-ից: Բացի այդ, ես հատուկ չեմ նշել, թե ինչպես է աշխատում այս ծրագիրը և ինչպես տեղադրել այն: Ոչ, միայն վարչարարության փորձը և իմ հանդիպած խնդիրները: Թերևս դա ինչ-որ մեկին օգտակար կլինի իր ընտրության մեջ:

Այսպիսով, եկեք սկսենք: Որպես համակարգի ադմինիստրատոր, ինձ համար կարևոր են հետևյալ կետերը, առանց որոնց ես դժվար թե օգտագործեմ այս լուծումը։

1. Տեղադրման կրկնելիություն

Opennebula-ի տեղադրման հրահանգները շատ են, ոչ մի խնդիր չպետք է լինի։ Տարբերակից տարբերակ հայտնվում են նոր գործառույթներ, որոնք միշտ չէ, որ կաշխատեն տարբերակից տարբերակ տեղափոխելիս:

2. Մոնիտորինգ

Մենք վերահսկելու ենք հանգույցը, kvm-ը և opennebula-ն: Բարեբախտաբար, այն արդեն պատրաստ է։ Կան բազմաթիվ տարբերակներ Linux հոսթների մոնիտորինգի վերաբերյալ, նույն Zabbix-ը կամ հանգույց արտահանողը, ով ավելի լավ է սիրում, այս պահին ես դա սահմանում եմ որպես մոնիտորինգի համակարգի չափումներ (ջերմաստիճանը, որտեղ այն կարելի է չափել, սկավառակի զանգվածի հետևողականությունը), zabbix-ի միջոցով: , իսկ ինչ վերաբերում է Prometheus արտահանողի միջոցով հայտերին։ ԿՎՄ մոնիտորինգի համար, օրինակ, կարող եք վերցնել նախագիծը github.com/zhangjianweibj/prometheus-libvirt-exporter.git ու դրեք, որ այն աշխատի systemd-ի միջոցով, բավականին լավ է աշխատում և ցույց է տալիս kvm չափիչները, կա նաև պատրաստի վահանակ grafana.com/grafana/dashboards/12538.

Օրինակ, ահա իմ ֆայլը.

/etc/systemd/system/libvirtd_exporter.service
[Unit]
Description=Node Exporter

[Service]
User=node_exporter
ExecStart=/usr/sbin/prometheus-libvirt-exporter --web.listen-address=":9101"

[Install]
WantedBy=multi-user.target

Եվ այսպես, մենք ունենք 1 արտահանող, մեզ անհրաժեշտ է երկրորդը, որը վերահսկելու է ինքնին opennebula-ն, ես օգտագործել եմ սա github.com/kvaps/opennebula-exporter/blob/master/opennebula_exporter

Կարելի է ավելացնել նորմալ հանգույց_արտահանող համակարգը վերահսկելու համար հետևյալը.

Node_exporter ֆայլում մենք փոխում ենք սկիզբը այսպես.

ExecStart=/usr/sbin/node_exporter --web.listen-address=":9102" --collector.textfile.directory=/var/lib/opennebula_exporter/textfile_collector

Ստեղծեք գրացուցակ mkdir -p /var/lib/opennebula_exporter

Վերևում ներկայացված bash սկրիպտը, սկզբում աշխատանքը ստուգում ենք վահանակի միջոցով, եթե այն ցույց է տալիս, թե ինչ է մեզ անհրաժեշտ (եթե սխալ է տալիս, ապա տեղադրեք xmlstarlet), պատճենեք այն /usr/local/bin/opennebula_exporter.sh-ում:

Յուրաքանչյուր րոպեի համար ավելացրեք cron առաջադրանք.

*/1 * * * * (/usr/local/bin/opennebula_exporter.sh > /var/lib/opennebula_exporter/textfile_collector/opennebula.prom)

Մետրիկաները սկսեցին հայտնվել, դուք կարող եք դրանք վերցնել պրոմեթևսի պես և գրաֆիկներ կառուցել և ահազանգեր անել: Grafana-ում դուք կարող եք նկարել, օրինակ, նման պարզ վահանակ:

(պարզ է, որ այստեղ ես գերազանցում եմ պրոցեսորը, ram)

Նրանց համար, ովքեր սիրում և օգտագործում են Zabbix-ը, կա github.com/OpenNebula/addon-zabbix

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

Ես իսկապես դեռ չեմ սկսել հատել: Ամենապարզ տարբերակն է՝ ավելացնել td-agent՝ կանոնավոր արտահայտություններով /var/lib/one գրացուցակը վերլուծելու համար։ Օրինակ, sunstone.log ֆայլը համընկնում է nginx regexp-ի և այլ ֆայլերի հետ, որոնք ցույց են տալիս հարթակ մուտքի պատմությունը. ո՞րն է դրա առավելությունը: Դե, օրինակ, մենք կարող ենք հստակորեն հետևել «Սխալ, սխալ» թվին և արագ հետևել, թե որտեղ և ինչ մակարդակում կա անսարքություն:

3. Կրկնօրինակներ

Կան նաև վճարովի ավարտված նախագծեր, օրինակ սեպ wiki.sepsoftware.com/wiki/index.php/4_4_3_Tigon:OpenNebula_Backup. Այստեղ մենք պետք է հասկանանք, որ պարզապես մեքենայի պատկերի կրկնօրինակումն այս դեպքում ամենևին էլ նույնը չէ, քանի որ մեր վիրտուալ մեքենաները պետք է աշխատեն ամբողջական ինտեգրմամբ (նույն համատեքստային ֆայլը, որը նկարագրում է ցանցի կարգավորումները, vm անունը և ձեր հավելվածների հատուկ կարգավորումները) . Հետևաբար, այստեղ մենք որոշում ենք, թե ինչ և ինչպես ենք կրկնօրինակելու: Որոշ դեպքերում ավելի լավ է պատճենել այն, ինչ կա հենց vm-ում: Եվ միգուցե ձեզ հարկավոր է միայն մեկ սկավառակի կրկնօրինակում տվյալ մեքենայից:

Օրինակ, մենք որոշեցինք, որ բոլոր մեքենաները սկսում են մշտական ​​պատկերներով, հետևաբար, կարդալուց հետո docs.opennebula.io/5.12/operation/vm_management/img_guide.html

Սա նշանակում է, որ նախ մենք կարող ենք վերբեռնել պատկերը մեր vm-ից.

onevm disk-saveas 74 3 prom.qcow2
Image ID: 77

Смотрим, под каким именем он сохранился

oneimage show 77
/var/lib/one//datastores/100/f9503161fe180658125a9b32433bf6e8
   
И далее копируем куда нам необходимо. Конечно, так себе способ. Просто хотел показать, что используя инструменты opennebula можно строить подобные решения.

Ինտերնետում էլ գտա հետաքրքիր զեկույց և կա ավելին այսպիսի բաց նախագիծ, բայց կա միայն qcow2-ի պահեստ:

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

4. Օգտագործման հեշտություն

Այս պարբերությունում ես նկարագրելու եմ այն ​​խնդիրները, որոնց հանդիպել եմ: Օրինակ, ըստ պատկերների, ինչպես գիտենք, կա համառ - երբ այս պատկերը տեղադրվում է vm-ի վրա, բոլոր տվյալները գրվում են այս պատկերի վրա: Իսկ եթե ոչ համառ, ապա պատկերը պատճենվում է պահեստում և տվյալները գրվում են սկզբնաղբյուրի պատկերից պատճենվածի վրա՝ այսպես են աշխատում կաղապարների կաղապարները։ Ես մի քանի անգամ ինքս ինձ համար խնդիրներ եմ առաջացրել՝ մոռանալով նշել համառ, և 200 ԳԲ պատկերը պատճենվել է, խնդիրն այն է, որ այս ընթացակարգը, իհարկե, չի կարող չեղարկվել, դուք պետք է գնաք հանգույց և սպանեք ընթացիկ «cp» գործընթացը:

Կարևոր թերություններից մեկն այն է, որ դուք չեք կարող չեղարկել գործողությունները պարզապես օգտագործելով gui-ը: Ավելի ճիշտ՝ կչեղարկես դրանք ու կտեսնես, որ ոչինչ չի լինում ու նորից կսկսես, կչեղարկես ու իրականում արդեն կլինի 2 cp պրոցես, որը պատճենում է պատկերը։

Եվ հետո գալիս է հասկանալու, թե ինչու է opennebula-ն յուրաքանչյուր նոր օրինակ համարակալում նոր id-ով, օրինակ, նույն proxmox-ում ստեղծել է vm id 101-ով, ջնջել այն, այնուհետև նորից ստեղծել և id 101: Opennebula-ում դա տեղի չի ունենա, յուրաքանչյուր նոր օրինակ կստեղծվի նոր id-ով, և դա ունի իր տրամաբանությունը, օրինակ՝ հին տվյալների մաքրում կամ անհաջող տեղադրումներ:

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

5. Առավելագույն պարզություն

Իհարկե, որքան առաջ ես գնում, այնքան քիչ են դառնում քեզ հասկացողները։

Իմ ստենդի պայմաններում՝ 3 հանգույց nfs պահեստով, ամեն ինչ լավ է աշխատում։ Բայց եթե մենք փորձեր անցկացնենք էլեկտրաէներգիայի անջատման հետ կապված, օրինակ՝ նկարը գործարկելիս և հանգույցի հոսանքն անջատելիս, մենք տվյալների բազայում պահում ենք կարգավորումներ, որ պատկեր կա, բայց իրականում չկա (լավ, մենք բոլորս հասկանում ենք, որ մենք ի սկզբանե գրել է տվյալների բազան այս գործողության մասին sql-ով, բայց գործողությունն ինքնին հաջող չի եղել): Առավելությունն այն է, որ snapshot ստեղծելիս առանձին ֆայլ է ձևավորվում և կա «ծնող», հետևաբար խնդիրների դեպքում և նույնիսկ եթե այն չի աշխատում gui-ի միջոցով, մենք կարող ենք վերցնել qcow2 ֆայլը և վերականգնել այն առանձին: docs.opennebula.io/5.8/operation/vm_management/vm_instances.html

Ցանցերում, ցավոք, ամեն ինչ այնքան էլ պարզ չէ: Դե, համենայն դեպս, դա ավելի հեշտ է, քան openstack-ում, ես օգտագործել եմ միայն vlan (802.1Q) - այն բավականին լավ է աշխատում, բայց եթե դուք փոփոխություններ եք կատարում կարգավորումներում կաղապարի ցանցից, ապա այս կարգավորումները չեն կիրառվի արդեն աշխատող մեքենաների վրա, այսինքն. դուք պետք է ջնջեք և ավելացնեք ցանցային քարտ, այնուհետև կկիրառվեն նոր կարգավորումները:

Եթե ​​դուք դեռ ցանկանում եք այն համեմատել openstack-ի հետ, ապա կարող եք սա ասել. opennebula-ում հստակ սահմանում չկա, թե որ տեխնոլոգիաներն օգտագործել տվյալների պահպանման, ցանցի, ռեսուրսների կառավարման համար. յուրաքանչյուր ադմինիստրատոր ինքն է որոշում, թե որն է իրեն ավելի հարմար:

6. Լրացուցիչ պլագիններ և տեղադրումներ

Ի վերջո, ինչպես մենք հասկանում ենք, ամպային հարթակը կարող է կառավարել ոչ միայն kvm, այլ նաև vmware esxi: Ցավոք սրտի, ես Vcenter-ով լողավազան չունեի, եթե որևէ մեկը փորձել է, խնդրում եմ գրեք:

Նշվում է ամպային այլ մատակարարների աջակցությունը docs.opennebula.io/5.12/advanced_components/cloud_bursting/index.html
AWS, AZURE.

Ես նաև փորձեցի միացնել Vmware Cloud-ը Selectel-ից, բայց ոչինչ չստացվեց, - ընդհանուր առմամբ, այն արգելափակվեց, քանի որ կան բազմաթիվ գործոններ, և իմաստ չունի գրել հոսթինգ մատակարարի տեխնիկական աջակցությանը:

Բացի այդ, այժմ նոր տարբերակն ունի firecracker. սա microvm-ի գործարկումն է, մի տեսակ kvm ամրագոտի դոկերի վրա, որը տալիս է էլ ավելի բազմակողմանիություն, անվտանգություն և բարձր արտադրողականություն, քանի որ կարիք չկա ռեսուրսներ վատնել նմանակող սարքավորումների վրա: Միակ առավելությունը, որը ես տեսնում եմ Docker-ի նկատմամբ, այն է, որ այն չի վերցնում լրացուցիչ քանակությամբ գործընթացներ և չկան զբաղեցված վարդակներ այս էմուլյացիայի օգտագործման ժամանակ, այսինքն. Դա միանգամայն հնարավոր է օգտագործել որպես ծանրաբեռնվածության հավասարակշռող (բայց, հավանաբար, արժե գրել առանձին հոդված այս մասին, քանի դեռ ամբողջությամբ չեմ կատարել բոլոր թեստերը):

7. Օգտագործման դրական փորձ և սխալների վերացում

Ցանկանում էի կիսվել աշխատանքի վերաբերյալ իմ դիտարկումներով, մի քանիսը վերը նկարագրեցի, կուզենայի ավելին գրել։ Իրոք, ես երևի միակը չեմ, ով սկզբում կարծում է, որ սա ճիշտ համակարգը չէ, և ընդհանրապես, այստեղ ամեն ինչ հենակ է. ինչպե՞ս են նրանք նույնիսկ աշխատում սրա հետ: Բայց հետո հասկացվում է, որ ամեն ինչ միանգամայն տրամաբանական է։ Իհարկե, դուք չեք կարող բոլորին գոհացնել, և որոշ ասպեկտներ բարելավում են պահանջում:

Օրինակ՝ սկավառակի պատկերը տվյալների պահեստից մյուսը պատճենելու պարզ գործողություն: Իմ դեպքում կա nfs-ով 2 հանգույց, ես ուղարկում եմ պատկերը - պատճենումը տեղի է ունենում frontend opennebula-ի միջոցով, չնայած մենք բոլորս սովոր ենք, որ տվյալները պետք է պատճենվեն անմիջապես հոսթների միջև - նույն vmware-ում, hyper-v մենք ենք: սովոր է սրան, բայց այստեղ՝ ուրիշին։ Կա այլ մոտեցում և այլ գաղափարախոսություն, և 5.12 տարբերակում նրանք հանեցին «գաղթել տվյալների պահեստ» կոճակը. փոխանցվում է միայն մեքենան, բայց ոչ պահեստը, քանի որ նշանակում է կենտրոնացված պահեստավորում:

Հաջորդը հայտնի սխալ է՝ տարբեր պատճառներով. «Վիրտուալ մեքենայի տեղակայման սխալ. Չհաջողվեց ստեղծել տիրույթ /var/lib/one//datastores/103/10/deployment.5»-ից:

• Պատկերի իրավունքները oneadmin օգտվողի համար;
• Oneadmin օգտվողի թույլտվությունները՝ գործարկելու libvirtd;
• Արդյո՞ք տվյալների պահեստը ճիշտ է տեղադրված: Գնացեք և ստուգեք ուղին հենց հանգույցի վրա, միգուցե ինչ-որ բան ընկել է.
• Սխալ կազմաձևված ցանց, ավելի ճիշտ ճակատային մասում ցանցի կարգավորումներում է, որ vlan-ի հիմնական ինտերֆեյսը br0 է, բայց հանգույցի վրա այն գրված է որպես bridge0 - այն պետք է լինի նույնը:

System datastore-ը պահպանում է մետատվյալները ձեր vm-ի համար, եթե դուք գործարկում եք vm-ն մշտական ​​պատկերով, ապա vm-ին պետք է մուտք գործի սկզբնապես ստեղծված կոնֆիգուրացիան այն պահեստում, որտեղ դուք ստեղծել եք vm-ը, սա շատ կարևոր է: Հետևաբար, VM-ն այլ տվյալների շտեմարան տեղափոխելիս պետք է ամեն ինչ կրկնակի ստուգել:

8. Փաստաթղթեր, համայնք. Հետագա զարգացում

Իսկ մնացածը՝ լավ փաստաթղթեր, համայնք, և գլխավորն այն է, որ նախագիծը շարունակի ապրել ապագայում։

Ընդհանրապես, ամեն ինչ բավականին լավ փաստաթղթավորված է, և նույնիսկ պաշտոնական աղբյուրից օգտվելով՝ խնդիր չի լինի տեղադրել և գտնել հարցերի պատասխանները։

Համայնք, ակտիվ. Հրապարակում է բազմաթիվ պատրաստի լուծումներ, որոնք կարող եք օգտագործել ձեր տեղադրումներում:

Այս պահին ընկերությունում որոշ քաղաքականություններ փոխվել են 5.12-ից forum.opennebula.io/t/towards-a-stronger-opennebula-community/8506/14 Հետաքրքիր կլինի տեսնել, թե ինչպես կզարգանա նախագիծը։ Սկզբում ես հատուկ մատնանշեցի որոշ վաճառողներին, ովքեր օգտագործում են իրենց լուծումները և այն, ինչ առաջարկում է արդյունաբերությունը: Իհարկե, հստակ պատասխան չկա, թե ինչ օգտագործել: Բայց ավելի փոքր կազմակերպությունների համար իրենց փոքր մասնավոր ամպի պահպանումը կարող է այնքան էլ թանկ լինել, որքան թվում է: Հիմնական բանը հստակ իմանալն է, թե ինչ է ձեզ անհրաժեշտ:

Արդյունքում, անկախ նրանից, թե ինչ եք ընտրում որպես ամպային համակարգ, չպետք է կանգ առեք մեկ ապրանքի վրա: Եթե ​​ժամանակ ունեք, արժե նայել այլ ավելի բաց լուծումներին:

Լավ զրույց կա t.me/opennebula Նրանք ակտիվորեն օգնում են և չեն ուղարկում Google-ում խնդրի լուծում որոնելու։ Միացեք մեզ.

Source: www.habr.com