Opennebula. Lühikesed märkmed

Tere kõigile. See artikkel on kirjutatud neile, kes on endiselt kahe vahel valikuga virtuaaliseerimisplatvormide vahel ja pärast artiklite lugemist seeriast "Paigaldasime proxmoxi ja kõik on suurepärane, 6 aastat tööaega ilma katkestusteta". Kuid pärast teatud valmislahenduse paigaldamist tekib küsimus, kuidas siin ja seal midagi kohandada, et monitooring oleks arusaadavam ja siin, et varukoopiate kontrollimine oleks tõhus... Ja siis tuleb aeg, mil mõistate, et soovite midagi funktsionaalsemat või et teie süsteemi sees peaks olema kõik arusaadav, mitte mingi must kast, või soovite kasutada midagi enamat kui hüperviisor ja hulk virtuaalmasinaid. Selles artiklis on veidi mõtteid ja praktikat Opennebula platvormi põhjal — valisin selle, kuna see on ressursside osas vähenenud nõudlik ja arhitektuur pole nii keeruline.

Nagu näeme, töötavad paljud pilveteenuse pakkujad KVM-i peal ja loovad väliseid liideseid masinate haldamiseks. On selge, et suured hostimisettevõtted kirjutavad oma liideseid pilv-infrastruktuuri jaoks, näiteks YANDEX. Mõned kasutavad OpenStacki ja loovad liidese selle alusel — SELECTEL, MAIL.RU. Kuid kui teil on oma riistvara ja väike spetsialistide meeskond, valitakse tavaliselt midagi valmis lahendustest — VMWARE, HYPER-V, on olemas tasuta ja tasulised litsentsid, aga sellest me ei räägi. Räägime entusiastidest — need on inimesed, kes ei karda uut proovida, vaatamata sellele, et ettevõte on selgelt öelnud: "Kes seda pärast sind hooldab?" ja "Kas me seda ikka tootmisse viime? See on hirmutav." Kuid alguses saab neid lahendusi katsetada testkeskkonnas ja kui kõik on rahul, saab tõstatada küsimuse edasise arendamise ja tõsisemates keskkondades kasutamise üle.

Siin on ka link ettekandele www.youtube.com/watch?v=47Mht_uoX3A aktiivse osaleja poolt selle platvormi arendamisel.

Võib-olla on selles artiklis midagi liigset, mis on kogenud spetsialistile juba selge, ja mõnes olukorras ei hakka ma kõike kirjeldama, kuna sarnaseid käske ja selgitusi leiab internetist. Siin on ainult minu kogemus selle platvormiga. Loodan, et aktiivsed osalejad täiustavad kommentaarides, mida saaks paremini teha ja milliseid vigu ma tegin. Kõik toimingud viidi läbi kodustes tingimustes, kus oli 3 erinevate omadustega arvutit. Samuti ei hakanud ma eraldi selgitama, kuidas see tarkvara töötab ja kuidas installida. Ei, ainult haldamise kogemus ja probleemid, millega silmitsi seisime. Võib-olla on see kellelegi kasuks valiku tegemisel.

Nii, asume asja kallale. Minu kui süsteemihalduri jaoks on olulised järgmised punktid, ilma milleta ma ei saa seda lahendust tõenäoliselt kasutada.

1. Paigaldus korduvus

On palju juhendeid opennebula installimise kohta, siin ei tohiks probleeme tekkida. Uue versiooniga kaasnevad alati uued funktsioonid, mis ei pruugi alati vanalt versioonilt uuele üleminekul toimida.

2. Jälgimine

Jälgime nodi, kvm ja opennebula. Hea, et see on juba valmis. Linuxi hostide jälgimiseks on palju valikuid, sama Zabbix või Node Exporter — kellele mis rohkem meeldib — hetkel määratlen, et süsteemi mõõdikute jälgimine (temperatuur seal, kus see on mõõdetav, kettamahuti järjepidevus) toimub Zabbixi kaudu, ja rakenduste osas Prometheuse eksportimise kaudu. KVM jälgimiseks võib näiteks võtta projekti github.com/zhangjianweibj/prometheus-libvirt-exporter.git ja käivitamise seadistamine läbi systemd, töötab suurepäraselt ja näitab kvm mõõdikuid, samuti 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

Ja nii on meil 1 eksportija, vaja on teist opennebula jälgimiseks, kasutasin sellist github.com/kvaps/opennebula-exporter/blob/master/opennebula_exporter

Saab lisada tavalisse node_exporter süsteemi jälgimiseks järgmist.

Failis node_exporter muudame käivitamise 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

Esmaltame bash skripti, mis kontrollib esmalt tööd konsoolis. Kui see näitab vajalikku (kui tekib viga, siis paigaldame xmlstarlet), kopeerige see /usr/local/bin/opennebula_exporter.sh.

Lisame croni ülesande iga minuti tagant:

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

Metrika hakkab ilmuma, neid saab Prometheuse kaudu koguda ja graafikuid luua ning häiresid seadistada. Grafanas saab näiteks sellise lihtsa armatuurlaua joonistada.

(näha on, et siin tegin ülekompenseerimise cpu, ram jaoks)

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

Kogu monitooringu kohta on kõik, peamine on see, et see on olemas. Loomulikult võib lisaks kasutada virtuaalmasinate sisseehitatud monitooringuvahendeid ning andmed arveldamiseks välja laadida, siin on kõigil oma nägemus, kuid ma pole veel selle kallal põhjalikumalt töötanud.

Logimise kohta pole veel erilist tähelepanu pööratud. Lihtsaim variant oleks lisada td-agent, et analüüsida kausta /var/lib/one regulaarsete väljenditega. Näiteks sobib fail sunstone.log regexp nginxile ning muud failid, mis näitavad looduse ajalugu platvormiga — milleks see hea on? Näiteks saame selgelt jälgida «Error, error» arvu ja kiiremini leida, kus ja millisel tasemel on tõrge.

3. Varukoopiad

On olemas ka tasulised täiendatud projektid — näiteks sep wiki.sepsoftware.com/wiki/index.php/4_4_3_Tigon:OpenNebula_Backup. Siin peame mõistma, et lihtsalt masina pildi varundamine ei ole selles osas piisav, sest meie virtuaalsed masinad peavad töötama täies integratsioonis (sama konteksti fail, kus kirjeldatakse võrgu konfiguratsiooni, vm nimi ja kohandatud seadistused teie rakenduste jaoks). Seetõttu peame otsustama, mida ja kuidas me varundame. Mõnedes juhtudes on parem teha koopiaid sellest, mis asub masinas endas. Ja võib-olla on vaja varundada ainult üks ketas antud masinast.

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

see siis kõigepealt saame meie vm-ilt 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 siis kopeerime sinna, kuhu vajame. Loomulikult on see natuke nõrk viis. Lihtsalt tahtsin näidata, et kasutades opennebula tööriistu, on võimalik selliseid lahendusi ehitada.

Otsisin samuti võrgust huvitavat ettekannet ja on veel selline avatud projekt, kuid siin on ainult qcow2 salvestus.

Aga nagu me kõik teame, tuleb varem või hiljem hetk, mil soovitakse inkrementaalseid varukoopiaid, sellega on keerulisem ja võib-olla suudab juhtkond raha leida tasulise lahenduse jaoks või minna teist teed, mõistes, et siin me tarbime ainult ressursse, samas varundamine toimub rakenduste tasemel ning uusi node ja virtuaallokid lisades — jah, siin ma räägin, et kasutada pilve alleen rakendusklastrite käitamiseks, samas andmebaas käivitada teisel platvormil või võtta olemasolev teenusepakkujalt, kui see on võimalik.

4. Kasutamise mugavus

Selles punktis kirjeldan probleeme, millega olen silmitsi seisnud. Näiteks piltide puhul, nagu me teame, on olemas persistent — kui see pilt on tüübi külge kinnitatud, salvestatakse kõik andmed sellesse pilti. Kui taas mittesinev, siis kopeeritakse pilt salvestusse ja andmed kirjutatakse sinna, mis on kopeeritud algsest pildist — need on mallide valmistamise viis. Olen korduvalt ise endale probleeme valmistanud, unustades määrata persistent, ja 200 GB pilt kopeeriti, probleem on selles, et tõenäoliselt ei saa seda protseduuri tühistada, tuleb minna node'i ja lõpetada jooksva "cp" protsess.

Üks olulisemaid miinuseid on see, et toimingut ei saa lihtsalt GUI kaudu tühistada. Tõepoolest, sa tühistad need ja näed, et midagi ei toimu, ja käivitad selle jälle, tühistad ja tegelikult on juba 2 cp protsessi, mis kopeerivad pilti.

Ja siis tuleb arusaam, miks opennebula igat uut instantsi numbreerib uue ID-ga. Näiteks proxmox'is lõid vm ID-ga 101, kustutasid selle, siis lood taas ja ID on 101. Opennebula's seda ei juhtu, iga uus instants luuakse uue ID-ga ja selles on oma loogika — näiteks vanade andmete või ebaõnnestunud installatsioonide puhastamine.

Sama asi salvestuse osas, see platvorm on suunatud peamiselt tsentraliseeritud salvestusele. Kohaliku kasutamiseks on saadaval lisandid, kuid see pole meie teema. Arvan, et tulevikus keegi kirjutab artikli selle kohta, kuidas õnnestus kasutada kohalikku salvestust sõlmedes ja edukalt tootmises kasutusele võtta.

5. Maksimaalne lihtsus

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

Minu seadistustes — 3 sõlme nfs salvestusega — kõik töötab korralikult. Kuid kui eksperimenteerida voolu väljalülitamisega, siis näiteks snapshot'i käivitamise ja sõlme toitest välja lülitamise korral salvestatakse meie andmebaasi seaded, et snapshot on olemas, kuid tegelikult seda ei ole (me kõik mõistame, et algselt kirjutati SQL andmebaasi selle tegevuse kohta, kuid operatsioon ei õnnestunud). Pluss on see, et snapshot'i loomisel luuakse eraldi fail ja on olemas „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

Kahjuks ei ole võrkudes kõik nii lihtsalt. No vähemalt on see lihtsam kui OpenStackis, ma kasutasin ainult VLAN-i (802.1Q) — see töötab üsna hästi, kuid kui teete mingeid muudatusi sisemise võrgu seadetesse, ei rakendata neid seadeid juba töötavatele masinatele, st peate võrkaartme eemaldama ja uuesti lisama, et uued seaded kehtima hakkaksid.

Kui soovite veel OpenStackiga võrrelda, siis võib öelda nii, et OpenNebulas ei ole selget määratlemist, milliseid tehnoloogiaid andmete salvestamiseks, võrgu haldamiseks ja ressursside jaoks kasutada — iga administreerija otsustab ise, mis talle mugavam on.

6. Täiendavad pistikprogrammid ja seadistused

Kuna me mõistame, et pilveplatvorm suudab hallata mitte ainult KVM-i, vaid ka VMware ESXi. Kahjuks ei olnud mul VCenter'i klooni, kui keegi on proovinud, kirjutage mulle.

Teiste pilveteenuste pakkujate toega on teatatud docs.opennebula.io/5.12/advanced_components/cloud_bursting/index.html
AWS, AZURE.

Olen ka proovinud integreerida VMware Cloud'i Selecteli kaudu, kuid ei õnnestunud — ühesõnaga loobusin, kuna on liiga palju tegureid ja kirjutada hostingu teenusepakkuja tehnilisse tugi ei ole mõtet.

Samuti, uues versioonis on nüüd firecracker — microvm-i käivitamine, mis on kvm-i mähis dockerite kohal, mis pakub veelgi rohkem mitmekesisust, turvalisust ja tootlikkuse suurenemist, kuna ei pea ressursse kulutama seadmete emuleerimisele. Näen ainult eeliseid dockerite suhtes, kuna see ei võta lisaprotsesse ja ei kasuta sockets mitte ühegi emulatsiooni puhul, mistõttu võib seda kasutada ka koormuse tasakaalustajana (aga sellest võiks võib-olla kirjutada eraldi artikli, kuna ei ole veel läbi viinud kõiki testimisi täielikult).

7. Positiivne kasutuskogemus ja vigade tõrje

Soovisin jagada oma tähelepanekuid töö kohta, osa neist on eelnevalt mainitud, soovin kirjutada rohkem. Tõepoolest, tõenäoliselt ei ole ma ainus, kes esmalt arvab, et see ei ole see süsteem ja üldiselt on siin kõik konksud — kuidas sellega üldse töötada? Kuid hiljem tuleb arusaamine, et kõik on täiesti loogiline. Loomulikult ei saa kõigile meeldida ja mõned aspektid vajavad täiustamist.

Näiteks lihtne ketta kuva kopeerimine ühe andmesalvestusest teise. Minu puhul on kaks sõlme nfs-iga, saatmine toimub kuva kaudu - kopeerimine käib opennebula esiplaanilt, kuigi me oleme harjunud, et andmeid kopeeritakse otse hostide vahel - samamoodi nagu vmware'is ja hyper-v's on meil sellekohased kogemused, kuid siin on see erinev. Siin on teine lähenemine ja teine ideoloogia, ning versioonis 5.12 eemaldati nupp „migrate to datastore“ - edasi kantakse ainult masin, mitte salvestus, kuna eeldatakse tsentraliseeritud salvestust.

Järgmine levinud viga erinevatel põhjustel: „Virtual machine'i juurutamine ebaõnnestus: ei saanud domeeni luua failist /var/lib/one//datastores/103/10/deployment.5” Allpool on loetelu, mida tuleks kontrollida.

• Õigused pildi jaoks kasutajale oneadmin;
• Õigused kasutajale oneadmin libvirtd'i käivitamiseks;
• Kas andmesalvestus on õigesti mountitud? Mine ja kontrolli teed salvestuse siseselt, võib-olla on midagi katkenud;
• Vale võrgu konfigureerimine, täpsemalt frontendis on võrgu seadetes, et peamise liidesena vlan jaoks on br0, samas sõlmes on aga kirjutatud - bridge0 - peaks olema sama.

süsteemi andmehoidla salvestab teie vm-i metaandmed. Kui käivitate vm-i püsiva pildiga, peab vm-l olema juurdepääs algselt loodud konfiguratsioonile sellele salvestusse, kus loodi vm — see on väga oluline. Seetõttu tuleb vm-i teisaldamisel teise andmehoidla kõik uuesti üle kontrollida.

8. Dokumentatsioon, kogukond. Edasiareng

Ja muud, hea dokumentatsioon, kogukond ja mis kõige tähtsam, et projekt jätkaks edaspidi elu.

Siin on üldiselt kõik üsna hästi dokumenteeritud ja isegi ametlikest allikatest ei valmista probleeme paigaldamine ja küsimustele vastuste leidmine.

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

Praeguseks on 5.12-ga mõned poliitikad ettevõttes muutunud. forum.opennebula.io/t/towards-a-stronger-opennebula-community/8506/14 On huvitav teada, kuidas projekt edasi areneb. Alguses mainisin teadlikult mõningaid tarnijaid, kes kasutavad oma lahendusi ja seda, mida tööstus pakub. Kindlat vastust, mida kasutada, muidugi ei ole. Kuid väikestele organisatsioonidele võib oma väikese private cloud'i hoidmine osutuda odavamaks, kui see esialgu tundub. Peamine on täpselt teada, kas see on teie vajadus.

Kokkuvõtteks, olenemata sellest, mida te pilvesüsteemina valisite, ei tasu jääda ainult ühe toote juurde. Kui teil on aega, tasub vaadata ka teisi avatud lahendusi.

On hea väike vestlusruum t.me/opennebula aitavad aktiivselt ja ei suuna teid probleemi lahendust Google'ist otsima. Liituge.

Allikas: habr.com