Opennebula. Lühikesed märkmed

Tere kõigile. See artikkel on kirjutatud neile, kes endiselt kaevavad virtualiseerimisplatvormide valiku vahel ning pärast artikli lugemist sarjast „Paigaldasime proxmoxi ja kõik on suurepärane, 6 aastat tööaega ilma katkestusteta“. Kuid pärast selle või tolle karbis lahenduse paigaldamist tekib küsimus, kuidas siit natukene kohandada ja sealt, et jälgimine oleks arusaadavam ja et siin saaks varukoopiaid paremini kontrollida... Ja siis tuleb aeg, mil mõistate, et soovite midagi funktsionaalsemat, või soovite, et teie süsteem oleks selgem, mitte see must karp, või soovite kasutada midagi enamat kui hüperviisor ja hunnik virtuaalmasinaid. Selles artiklis on veidi mõtteid ja praktikat OpenNebula platvormi põhjal - valitud, kuna see ei ole nõudlik ressursside osas ja arhitektuur on suhteliselt lihtne.

Nii et, nagu näeme, töötab paljusid pilveteenuse pakkujaid KVM-il ja teevad väliseid liideseid masinate haldamiseks. Selge on see, et suured hostimisettevõtted kirjutavad oma liideseid pilveinfrastruktuuri jaoks, näiteks YANDEX. Mõned kasutavad OpenStacki ja teevad selle põhjal liidese - SELECTEL, MAIL.RU. Kuid kui teil on oma riistvara ja väike meeskond spetsialiste, siis tavaliselt valitakse midagi valmis lahendustest - VMWARE, HYPER-V, on olemas tasuta ja tasulised litsentsid, aga sellest ei ole nüüd juttu. Räägime entusiastidest - need on need, kes ei karda pakkuda ja proovida uut, hoolimata sellest, et ettevõtte poolt on selgelt antud mõista, et „Kes seda pärast sind hooldab“, „Kas me tõesti peaksime seda tootmisse viima? Hirmutav.“ Kuid alguses saab neid lahendusi katsetada testkeskkonnas ja kui kõigile meeldib, siis saab tõstatada teema edasise arendamise ja tõsisemates keskkondades kasutamise kohta.

Siin on ka link ettekandele www.youtube.com/watch?v=47Mht_uoX3A aktiivse osaleja poolt selles platvormis arendamise juures.

Võib-olla on artiklis midagi liigset ja kogenud spetsialistile arusaadavat, ning mõnes olukorras ma ei kirjelda kõike, kuna sarnaseid käske ja kirjeldusi leidub veebis. Siin on ainult minu kogemus selle platvormiga töötamisel. Loodan, et aktiivsed osalejad lisavad kommentaarides, mida võiks paremini teha ja milliseid vigu olen teinud. Kõik tegevused toimusid kodustes tingimustes, mis koosnesid kolmest arvutist erinevate parameetritega. Samuti ei viidanud ma, kuidas see tarkvara töötab ja kuidas see installida. Ei, ainult haldustööde kogemus ja probleemid, millega silmitsi seisin. Võib-olla on see kellelegi kasulik valiku tegemisel.

Nii, alustame. Mina, kui süsteemiadministraator, pean oluliseks järgmisi punkte, ilma milleta ma seda lahendust tõenäoliselt ei kasuta.

1. Installatsiooni korduvus

Opennebulat on palju installatsioonijuhendeid, seega ei tohiks probleeme tekkida. Uute versioonide ilmumisega tulevad välja uued funktsioonid, mis ei pruugi alati töötada versiooniüleminekute korral.

2. Jälgimine

Jälgime node'i, kvm'i ja opennebula't. Õnneks on juba olemas valmidus. Linuxi hostide jälgimiseks on palju variante, näiteks Zabbix või node exporter - kellele mis rohkem meeldib - hetkel määratlen nii, et süsteemi metrikate jälgimine (temperatuur seal, kus see on mõõdetav, ketta massi järjepidevus) toimub läbi Zabbixi, ja rakenduste jälgimise jaoks läbi eksportija Prometheuses. KVM-i jälgimiseks võib näiteks kasutada projekti. github.com/zhangjianweibj/prometheus-libvirt-exporter.git ja seadistada käivitamine läbi systemd, töötab kenasti ja kuvab KVM metrikad, lisaks on olemas valmis armatuurlaud. grafana.com/grafana/dashboards/12538.

Näiteks, siin on minu fail:

/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

Nii, meil on üks eksportija, jaoks opennebula jälgimist on vajalik teine, kasutasin järgmist: github.com/kvaps/opennebula-exporter/blob/master/opennebula_exporter

Võib lisada tavaliselt node_exporter süsteemi jälgimiseks järgmise.

Node_exporteri failis muudame käivituse järgmiselt:

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

Loome katalooge mkdir -p /var/lib/opennebula_exporter

Bash skripti, nagu eelnevalt esitatud, kontrollime kõigepealt töötlust konsoolis, kui see näitab, mida peab (kui see annab vea, siis paigaldame xmlstarlet'i), kopeerime selle /usr/local/bin/opennebula_exporter.sh

Lisame cron'i ülesande iga minuti tagant:

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

Mõõdikud on hakanud ilmuma, neid saab Prometheusega koguda, graafikuid koostada ja häireid seada. Grafanas saab näiteks joonistada sellise lihtsa dünaamilise juhtpaneeli.

(näha, et siin tegin CPU ja RAM-i ülekompenseerimise)

Neile, kes armastavad ja kasutavad Zabbixit, on olemas github.com\/OpenNebula\/addon-zabbix

Monitooringust on kõik, peamine on, et see olemas on. Loomulikult saab täiendavalt kasutada virtuaalmasinate sisseehitatud monitooringuvahendeid ja andmeid arveldamiseks väljastada, siin on kõigil oma vaated, ma pole sellele veel eriti lähenenud.

Logimise osas pole ma veel eriti alustanud. Kõige lihtsam variant on lisada td-agent katalooge saadetavate failide jaoks, näiteks kataloogis \/var\/lib\/one, kasutades regulaaravaldisi. Näiteks sobib fail sunstone.log regexp-nginx ja muud failid, mis näitavad meie platvormiga seotud päringute ajalugu — milline on selle eelis? Näiteks saame otseselt jälgida 'Error, error' arvu ja kiiremini leida, kus ja mis tasemel on tõrge.

3. Varukoopiad

On ka tasulisi täiustatud projekte — näiteks sep wiki.sepsoftware.com\/wiki\/index.php\/4_4_3_Tigon:OpenNebula_Backup. Siin peame aru saama, et lihtsalt masina pildi varundamine ei tähenda veel seda, et meie virtuaalmasinad peavad töötama täieliku integreeritusega (sama konteksti fail, mis kirjeldab võrgu seadeid, vm nime ja kohandatud seadeid teie rakenduste jaoks). Seetõttu määrame, mida ja kuidas me varundame. Mõnel juhul on parem teha koopiaid sellest, mis asub masinas endas. Ja võib-olla peaksime varundama ainult ühe ketta antud masinast.

Näiteks oleme otsustanud, et kõik masinad käivitatakse püsivate piltidega, seega lugedes docs.opennebula.io\/5.12\/operation\/vm_management\/img_guide.html

saame kõigepealt meie VM-ist pildi välja laadida:

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

Vaata, millise nime all see salvestati

oneimage show 77
\/var\/lib\/one\/datastores\/100\/f9503161fe180658125a9b32433bf6e8
   
Ja seejärel kopeerime kuhugi, kus me seda vajame. Loomulikult pole see parim viis. Lihtsalt tahtsin näidata, et kasutades OpenNebula tööriistu, saab selliseid lahendusi luua.

Samas, netis leidsin huvitava ettekande ja on veel selline avatud projekt, kuid see on ainult qcow2 ladustamise jaoks.

Kuid nagu me kõik teame, tuleb varem või hiljem hetk, mil soovitakse inkrementaalseid varukoopiaid. Siin on see keerulisem ja võib-olla eraldab juhtkond raha tasulise lahenduse jaoks või tuleb minna teist teed, mõistes, et siin kulutame ainult ressursse, samal ajal kui varundamine toimub rakenduste tasemel ja uute sõlmede ja virtuaalmasinate lisamine — jah, ma räägin, et kasutage pilve ainult rakenduste klastrite käivitamiseks, samas kui andmebaasid tuleks käivitada teisel platvormil või võtta tarnijalt valmis lahendus, kui see on võimalik.

4. Kasutamise mugavus

Selles punktis kirjeldan probleeme, millega olen kokku puutunud. Näiteks piltide osas, nagu me teame on olemas persistent — kui see pilt montaažitakse virtuaalmasinale, salvestatakse kõik andmed sellesse pilti. Kui aga non-persistent, siis kopeeritakse pilt salvestusse ja andmed kirjutatakse sinna, kuhu see kopeeriti algsest pildist — just nii toimivad mallide ettevalmistused. Olen korduvalt endale probleeme tekitanud, unustades määrata persistent ja 200 GB pilt kopeeriti, probleemiks on see, et tõenäoliselt seda protseduuri tühistada ei saa, tuleb minna sõlme ja oma ajaloo „cp“ praegust protsessi katkestama.

Üks olulisi miinuseid — tegevusi ei saa lihtsalt GUI-d kasutades tühistada. Täpsemalt öeldes, tühistad nad ja näed, et midagi ei toimu ja käivitad uuesti; tühistad ja sisuliselt on juba 2 „cp“ protsessi, mis kopeerivad pilti.

Ja siia tulebki arusaamine, miks opennebula igale uuele instantsile uue ID numbri paneb. Näiteks proxmoxis lõid VM ID-ga 101, kustutasid selle, siis loodi see uuesti ja ID jääb 101-ks. Opennebula puhul ei juhtu seda, iga uus instants luuakse uue ID-ga ja selles on oma loogika — näiteks vanade andmete või ebaõnnestunud installatsioonide puhastamine.

Sama on ka salvestusega; see platvorm on suunatud peamiselt tsentraliseeritud salvestusele. Kohalike lahenduste kasutamiseks on olemas lisandmooduleid, kuid antud juhul ei ole see teemaks. Arvan, et tulevikus keegi kirjutab artikli selle kohta, kuidas on õnnestunud kasutada kohalikke salvestusi sõlmedes ja edukalt kasutada neid tootmises.

5. Maksimaalne lihtsus

Muidugi, mida kaugemale sa lähed, seda vähem on neid, kes sind mõistavad.

Minu selle seadmestiku tingimustes — 3 nodi NFS salvestusega — kõik töötab piisavalt hästi. Kuid kui katsetada voolu katkestamist, näiteks snapshoti käivitamisel ja nodi toite katkestamisel, siis jäävad meil andmed andmebaasis, et snapshot on olemas, kuigi tegelikult seda ei ole (noh, me mõistame kõik, et algselt salvestasime SQL andmebaasi selle toimingu kohta, kuid operatsioon ei õnnestunud). Eeliseks on, et snapshoti loomisel genereeritakse eraldi fail ja on "vanem", seega probleemide korral, isegi kui GUI ei tööta, saame qcow2 faili võtta ja taastuda eraldi. docs.opennebula.io/5.8/operation/vm_management/vm_instances.html

Võrkude osas, kahjuks ei ole kõik nii lihtne. Noh, vähemalt lihtsam kui OpenStackis, ma kasutasin ainult VLAN-i (802.1Q) — see töötab kenasti, kuid kui teete muutusi mallvõrgu seadetes, ei rakendata neid juba töötavatele masinatele, st tuleb võrgukaart eemaldada ja uuesti lisada, siis rakenduvad uued seaded.

Kui soovite võrrelda OpenStackiga, võib öelda nii: OpenNebulas ei ole selget määratlemist, milliseid tehnoloogiaid andmete salvestamiseks, võrgu juhtimiseks, ressursside haldamiseks kasutada — iga administraator otsustab ise, kuidas tal on mugavam.

6. Täiendavad pluginad ja installatsioonid

Kuna me mõistame, et pilveplatvorm saab hallata mitte ainult KVM-i, vaid ka VMware ESXi-d. Kahjuks ei olnud mul juurdepääsu Vcenter’i, kui keegi on proovinud, kirjutage.

Teiste pilveteenuse pakkujate toetuses on kuulutatud docs.opennebula.io/5.12/advanced_components/cloud_bursting/index.html
AWS, AZURE.

Ma proovisin ka VMware Cloudi Selectelilt, kuid ei saanud millestki aru — üldiselt loobusin, kuna on palju tegureid, ja pole mõtet kirjutada hostingu teenusepakkuja tehnilise toe poole.

Lisaks on uues versioonis Firecracker — see on mikrovms-i käivitamine, tüü pilveserveri KVM-i üle Docker’i, mis pakub veelgi rohkem universaalsust, turvalisust ja jõudlust, kuna ei pea kulutama ressursse riistvara emulatsioonile. Näen ainult eeliseid võrreldes Docker’iga, kuna see ei võta lisaprotsesse ja ei kasuta sokette selle emulatsiooni kasutamisel, seega saab seda kenasti kasutada koormuse tasakaalustajana (aga sellest peaks vist eraldi artikli kirjutama, kuna ei ole oma teste täiel määral läbi viinud).

7. Positiivne kogemus kasutamisest ja vigade tõrke.

Soovin jagada oma tähelepanekuid töö kohta, osa neist on juba eespool kirjeldatud, tahan kirjutada rohkem. Tõeliselt, tõenäoliselt ei ole ma ainus, kes alguses arvas, et see ei ole see süsteem ja et siin on kõik kohmakas — kuidas sellega üldse töötada? Kuid siis tuleb arusaamine, et kõik on täiesti loogiline. Loomulikult ei saa kõiki rahuldada ja mõned teemad vajavad täiustamist.

Näiteks lihtne toiming, kus kopeeritakse ketaspilti ühest andmemagasi kohast teise. Minu juhul on 2 node’i nfs-iga, ma saadan pildi — kopeerimine toimub opennebula frontend'i kaudu, kuigi me oleme harjunud, et andmed peavad kopeeruma otse hostide vahel — nagu vmware’is, hyper-v-s oleme harjunud just sellega, kuid siin on teisiti. Siin on teine lähenemine ja teine ideoloogia, ning versioonis 5.12 eemaldati nupp „migrate to datastore“ — liigub ainult masin, mitte salvestus, kuna eeldatakse tsentraliseeritud salvestust.

Edasi populaarne viga erinevate põhjustega „Error deploying virtual machine: Could not create domain from /var/lib/one//datastores/103/10/deployment.5“ Allpool on top, mida tasub vaadata.

• Õigused pildile kasutajale oneadmin;
• Õigused kasutajale oneadmin libvirtd käivitamiseks;
• Kas andmemagasi on õigesti monteeritud? Mine ja kontrolli rada ise node'is, võib-olla on midagi katkenud;
• Vääralt konfigureeritud võrk, täpsemalt on frontend'i võrgue seadetes, et br0 on peamine liides vlan’i jaoks, kuid node'is on kirjas — bridge0 — see peab olema ühtlane.

system datastore salvestab teie vm-i metaandmed, kui käivitate vm-i persistent image'iga, peab vm olema juurdepääs algselt loodud konfiguratsioonile seal, kus te vm-i lõite — see on väga oluline. Seetõttu tuleb vm-i teisaldamisel teise andmemagasi kõik uuesti üle kontrollida.

8. Dokumentatsioon, kogukond. Edasine areng

Ja ülejäänud, hea dokumentatsioon, kogukond ja kõige tähtsam, et projekt jätkaks tulevikus elu.

Siin on üldiselt kõik üsna hästi dokumenteeritud ning isegi ametlikust allikast ei ole probleeme installida ja leida vastuseid küsimustele.

Kogukond on aktiivne. Avaldab palju valmis lahendusi, mida saate oma seadistustes kasutada.

Hetkel on versioonis 5.12 muutunud mõned poliitikad ettevõttes forum.opennebula.io/t/towards-a-stronger-opennebula-community/8506/14 Huvitav oleks teada, kuidas projekt areneb. Alguses mainisin teadlikult mõningaid teenusepakkujaid, kes kasutavad oma lahendusi ja seda, mida tööstus pakub. Kindlat vastust selle kohta, mida kasutada, pole kindlasti olemas. Kuid väikestele organisatsioonidele võib oma väikese erakliendi toetamine osutuda odavamaks, kui see esialgu tunduda võib. Peamine on täpselt teada, et see on teile vajalik.

Kokkuvõttes, sõltumata sellest, mida olete valinud oma pilvesüsteemiks, ei tasu jääda ühe toote juurde. Kui teil on aega, tasuks tutvuda teiste avatumate lahendustega.

On hea vestlusring. t.me/opennebula aitavad aktiivselt ning ei saada teid probleemi lahendust otsima Googlest. Liituge.

Allikas: habr.com