Opennebula. Lühikesed märkmed

Opennebula. Lühikesed märkmed

Tere kõigile. See artikkel on kirjutatud neile, kes on endiselt virtualiseerimisplatvormide valimise vahel ja pärast artikli lugemist sarjast "Paigaldasime proxmoxi ja üldiselt on kõik korras, 6 aastat tööaega ilma ühegi pausita." Kuid pärast ühe või teise karbist väljas lahenduse installimist tekib küsimus: kuidas seda siin parandada, et jälgimine oleks arusaadavam ja siin varukoopiate kontrollimiseks…. Ja siis saabub aeg ja sa mõistad, et tahad midagi funktsionaalsemat või tahad, et kõik sinu süsteemi sees saaks selgeks, mitte see must kast või tahad kasutada midagi enamat kui hüperviisor ja hunnik virtuaalmasinaid. See artikkel sisaldab Opennebula platvormil põhinevaid mõtteid ja praktikat – valisin selle, sest. see ei nõua ressursse ja arhitektuur pole nii keeruline.

Nagu näeme, töötavad paljud pilveteenuse pakkujad kvm-iga ja loovad masinate juhtimiseks väliseid ühendusi. On selge, et suured hostijad kirjutavad oma raamistikud pilve infrastruktuuri jaoks, näiteks seesama YANDEX. Keegi kasutab openstacki ja loob selle alusel ühenduse - SELECTEL, MAIL.RU. Kuid kui teil on oma riistvara ja vähe spetsialiste, siis valite tavaliselt midagi valmis - VMWARE, HYPER-V, on tasuta ja tasulised litsentsid, kuid see pole see, millest me praegu räägime. Räägime entusiastidest - need on need, kes ei karda midagi uut pakkuda ja proovida, hoolimata asjaolust, et ettevõte tegi selgelt selgeks: "Kes seda pärast teid teenindab", "Kas me kavatseme selle hiljem tootmisse viia" ? Hirmutav." Aga neid lahendusi saab esmalt katsestendis rakendada ja kui see kõigile meeldib, siis võib tõstatada küsimuse edasisest arendusest ja kasutamisest ka tõsisemates keskkondades.

Siin on ka link raportile www.youtube.com/watch?v=47Mht_uoX3A selle platvormi arenduses aktiivselt osalejalt.

Võib-olla on selles artiklis midagi üleliigset ja kogenud spetsialistile juba arusaadav ning mõnel juhul ei kirjelda ma kõike, kuna sarnased käsud ja kirjeldused on Internetis saadaval. See on lihtsalt minu kogemus selle platvormiga. Loodan, et aktiivsed osalejad lisavad kommentaaridesse, mida saaks paremini teha ja milliseid vigu tegin. Kõik toimingud toimusid kodustendil, mis koosnes 3 erineva omadustega arvutist. Samuti ei osutanud ma konkreetselt, kuidas see tarkvara töötab ja kuidas seda installida. Ei, ainult halduskogemus ja probleemid, millega kokku puutusin. Võib-olla on see kellelegi nende valikul kasulik.

Niisiis, alustame. Süsteemiadministraatorina on minu jaoks olulised järgmised punktid, ilma milleta ma seda lahendust tõenäoliselt ei kasuta.

1. Paigaldamise korratavus

Opennebula paigaldamiseks on palju juhiseid, probleeme ei tohiks tekkida. Versioonist versioonini ilmuvad uued funktsioonid, mis versioonilt versioonile liikumisel alati ei tööta.

2. Järelevalve

Jälgime sõlme ennast, kvm-i ja avatud udukogu. Õnneks on see juba valmis. Linuxi hostide jälgimiseks on palju võimalusi, seesama Zabbix või sõlmeeksportija - kellele mis rohkem meeldib - hetkel defineerin seda süsteemimõõdikute jälgimisena (temperatuur, kus seda saab mõõta, kettamassiivi järjepidevus), läbi zabbixi , ja mis puudutab rakendusi Prometheuse eksportija kaudu. Näiteks kvm-seire jaoks võite võtta projekti github.com/zhangjianweibj/prometheus-libvirt-exporter.git ja pane see tööle systemd kaudu, see töötab päris hästi ja näitab kvm mõõdikuid, on ka 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 et meil on 1 eksportija, vajame teist, et jälgida opennebuli ennast, ma kasutasin seda github.com/kvaps/opennebula-exporter/blob/master/opennebula_exporter

Saab lisada normaalsele sõlme_eksportija süsteemi jälgimiseks järgmist.

Failis node_exporter muudame algust järgmiselt:

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

Looge kataloog mkdir -p /var/lib/opennebula_exporter

ülaltoodud bash-skripti, kontrollime esmalt tööd konsooli kaudu, kui see näitab, mida vajame (kui see annab vea, installige xmlstarlet), kopeerige see kausta /usr/local/bin/opennebula_exporter.sh

Lisage iga minuti jaoks cron-ülesanne:

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

Mõõdikud hakkasid ilmuma, võite neid võtta nagu prometheust ja koostada graafikuid ja teha hoiatusi. Grafanas saab joonistada näiteks sellise lihtsa armatuurlaua.

Opennebula. Lühikesed märkmed

(selge on see, et siin ma panen üle CPU, ram)

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

Mis puudutab monitooringut, siis peaasi, et see olemas on. Loomulikult saab lisaks kasutada sisseehitatud virtuaalmasina jälgimise tööriistu ja andmeid arveldusse üles laadida, siin on igaühel oma nägemus, ma pole sellega veel lähemalt tegelema hakanud.

Ma pole veel õieti metsaraiet alustanud. Lihtsaim võimalus on lisada td-agent, et analüüsida kataloogi /var/lib/one regulaaravaldistega. Näiteks fail sunstone.log ühtib nginx regexpi ja muude failidega, mis näitavad platvormile juurdepääsu ajalugu – mis on selle eelis? Näiteks saame selgesõnaliselt jälgida "Error, error" arvu ja kiiresti jälgida, kus ja millisel tasemel on rike.

3. Varukoopiad

On ka tasulisi lõpetatud projekte - näiteks sept wiki.sepsoftware.com/wiki/index.php/4_4_3_Tigon:OpenNebula_Backup. Siin peame mõistma, et lihtsalt masinapildi varundamine pole antud juhul sama, sest meie virtuaalmasinad peavad töötama täieliku integratsiooniga (sama kontekstifail, mis kirjeldab võrgusätteid, virtuaalseadme nime ja teie rakenduste kohandatud sätteid) . Seetõttu otsustame siin, mida ja kuidas varundame. Mõnel juhul on parem teha koopiaid sellest, mis on vm-is endas. Ja võib-olla peate varundama ainult ühe ketta antud masinast.

Näiteks tegime kindlaks, et kõik masinad algavad pärast lugemist püsivate kujutistega docs.opennebula.io/5.12/operation/vm_management/img_guide.html

See tähendab, et esmalt saame pildi üles laadida oma VM-st:

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

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

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

Internetist leidsin ka huvitav aruanne ja on veel selline avatud projekt, kuid salvestusruumi on ainult qcow2 jaoks.

Aga nagu me kõik teame, tuleb varem või hiljem hetk, kus tahad juurdekasvu varukoopiaid, siin on keerulisem ja ehk eraldab juhtkond raha tasulise lahenduse jaoks või läheb teist teed ja saab aru, et siin me ainult kärpime ressursse, ja varukoopiate tegemine rakenduste tasemel ja mitmete uute sõlmede ja virtuaalmasinate lisamine – jah, siin ma ütlen, et pilve kasutamine puhtalt rakendusklastrite käivitamiseks ja andmebaasi käivitamine mõnel teisel platvormil või valmis platvormi võtmine. võimaluse korral tarnijalt.

4. Kasutuslihtsus

Selles lõigus kirjeldan probleeme, millega kokku puutusin. Näiteks piltide järgi, nagu me teame, on püsiv - kui see pilt on ühendatud VM-iga, kirjutatakse kõik andmed sellele pildile. Ja kui mittepüsiv, siis kopeeritakse pilt salvestusruumi ja andmed kirjutatakse lähtepildilt kopeeritule – nii töötavad mallimallid. Tekitasin endale korduvalt probleeme sellega, et unustasin määrata püsiv ja 200 GB pilt kopeeriti, probleem on selles, et seda protseduuri ei saa kindlasti tühistada, tuleb minna sõlme ja tappa praegune "cp" protsess.

Üks olulisi puudusi on see, et te ei saa toiminguid lihtsalt juhendit kasutades tühistada. Õigemini, tühistad need ja vaatad, et midagi ei juhtu ja käivitad uuesti, tühistad ja tegelikult on juba 2 cp protsessi, mis pilti kopeerivad.

Ja siis tuleb arusaamine, miks opennebula nummerdab iga uue eksemplari uue id-ga, näiteks samas proxmoxis lõi vm ID-ga 101, kustutas selle, siis loo uuesti ja id 101. Opennebulas seda ei juhtu, iga uus eksemplar luuakse uue ID-ga ja sellel on oma loogika - näiteks vanade andmete kustutamine või ebaõnnestunud installid.

Sama kehtib ka salvestamise kohta; ennekõike on see platvorm suunatud tsentraliseeritud salvestusele. Kohaliku kasutamiseks on lisandmooduleid, kuid see pole see, millest me antud juhul räägime. Ma arvan, et tulevikus kirjutab keegi artikli sellest, kuidas neil õnnestus sõlmedes kohalikku salvestusruumi kasutada ja seda edukalt tootmises kasutada.

5. Maksimaalne lihtsus

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

Minu stendi tingimustes - 3 sõlme koos nfs-salvestusega - töötab kõik hästi. Aga kui teeme katseid, mis hõlmavad voolukatkestust, näiteks hetktõmmise tegemisel ja sõlme toite väljalülitamisel, salvestame andmebaasi sätted, et hetktõmmis on olemas, kuid tegelikult seda pole (noh, me kõik mõistame, et algselt kirjutas selle toimingu andmebaasi sql-is, kuid toiming ise ei õnnestunud). Eeliseks on see, et hetktõmmise loomisel moodustatakse eraldi fail ja seal on "vanem", seetõttu saame probleemide korral ja isegi kui see läbi gui ei tööta, saame qcow2 faili üles võtta ja selle eraldi taastada docs.opennebula.io/5.8/operation/vm_management/vm_instances.html

Võrkudes pole kahjuks kõik nii lihtne. Noh, vähemalt on see lihtsam kui openstackis, kasutasin ainult vlan-i (802.1Q) - töötab päris hästi, aga kui teha mallivõrgust seadistustesse muudatusi, siis juba töötavatele masinatele neid sätteid ei rakendata, s.t. peate võrgukaardi kustutama ja lisama, siis rakenduvad uued sätted.

Kui tahad seda ka openstackiga võrrelda, siis võib öelda nii: opennebulas pole selget definitsiooni, milliseid tehnoloogiaid andmete salvestamiseks, võrgu, ressursside haldamiseks kasutada – iga administraator otsustab ise, mis talle mugavam on.

6. Täiendavad pistikprogrammid ja installid

Lõppude lõpuks, nagu me aru saame, saab pilveplatvorm hallata mitte ainult kvm-i, vaid ka vmware esxi. Kahjuks ei olnud mul Vcenteriga basseini, kui keegi on proovinud, palun kirjutage.

Teatatakse toetust teistele pilveteenuse pakkujatele docs.opennebula.io/5.12/advanced_components/cloud_bursting/index.html
AWS, ASUUR.

Proovisin ka Vmware Cloudi Selectelist ühendada, kuid miski ei toiminud - üldiselt blokeeriti see, kuna tegureid on palju ja pole mõtet hostiteenuse pakkuja tehnilisele toele kirjutada.

Samuti on nüüd uues versioonis pauguti – see on microvm, teatud tüüpi kvm-rakmete tüüp dockeriga, mis annab veelgi rohkem mitmekülgsust, turvalisust ja suurendab tootlikkust, kuna pole vaja ressursse raisata emuleerimisseadmetele. Ainus eelis, mida ma Dockeri ees näen, on see, et see ei võta täiendavat arvu protsesse ja selle emulatsiooni kasutamisel pole hõivatud pesasid, st. Seda on täiesti võimalik kasutada koormuse tasakaalustajana (kuid tõenäoliselt tasub selle kohta eraldi artikkel kirjutada, kuni olen kõik testid täielikult läbi teinud).

7. Positiivne kasutuskogemus ja vigade silumine

Tahtsin jagada oma tähelepanekuid töö kohta, osa sellest kirjeldasin ülalpool, kirjutan veel. Tõepoolest, ma pole ilmselt ainus, kes alguses arvab, et see pole õige süsteem ja üldiselt on siin kõik kark - kuidas nad sellega üldse töötavad? Siis aga tuleb arusaam, et kõik on üsna loogiline. Muidugi ei saa te kõigile meeldida ja mõned aspektid vajavad parandamist.

Näiteks lihtne toiming kettapildi kopeerimiseks ühest andmesalvest teise. Minu puhul on nfs-iga 2 sõlme, saadan pildi - kopeerimine toimub läbi frontend opennebula, kuigi me kõik oleme harjunud sellega, et andmeid tuleks kopeerida otse hostide vahel - samas vmware, hyper-v oleme sellega harjunud, aga siin teisega. Seal on erinev lähenemine ja erinev ideoloogia ning versioonis 5.12 eemaldati nupp "migreeri andmesalve" - ​​edastatakse ainult masin ise, kuid mitte salvestusruum, kuna tähendab tsentraliseeritud ladustamist.

Järgmine on mitmel põhjusel levinud tõrge: "Viga virtuaalmasina juurutamisel: domeenist /var/lib/one//datastores/103/10/deployment.5 ei saa luua" Allpool on kõige olulisem asi, mida vaadata.

  • Oneadmini kasutaja pildiõigused;
  • Oneadmin kasutaja õigused libvirtd käitamiseks;
  • Kas andmesalv on õigesti paigaldatud? Minge ja kontrollige sõlme enda teed, võib-olla on midagi maha kukkunud;
  • Valesti seadistatud võrk või õigemini esiküljel on võrguseadetes vlani põhiliides br0, kuid sõlmes on see kirjutatud sild0 - see peab olema sama.

süsteemi andmesalve salvestab teie VM-i metaandmeid, kui käivitate VM-i püsiva pildiga, siis peab VM-l olema juurdepääs algselt loodud konfiguratsioonile sellel salvestusruumil, kus te VM-i lõite - see on väga oluline. Seetõttu peate VM-i teise andmesalve ülekandmisel kõik üle kontrollima.

8. Dokumentatsioon, kogukond. Edasine areng

Ja ülejäänu, hea dokumentatsioon, kogukond ja peaasi, et projekt elaks ka tulevikus.

Üldiselt on kõik üsna hästi dokumenteeritud ja isegi ametlikku allikat kasutades pole probleemi installimine ja küsimustele vastuste leidmine.

Kogukond, aktiivne. Avaldab palju valmislahendusi, mida saate oma installatsioonides kasutada.

Hetkel on ettevõttes osa poliitikaid muutunud alates 5.12 forum.opennebula.io/t/towards-a-stronger-opennebula-community/8506/14 Huvitav on näha, kuidas projekt areneb. Alguses tõin konkreetselt välja mõned müüjad, kes nende lahendusi kasutavad ja mida tööstus pakub. Muidugi pole selget vastust selle kohta, mida kasutada. Kuid väiksemate organisatsioonide jaoks ei pruugi väikese privaatpilve ülalpidamine olla nii kulukas, kui tundub. Peaasi on täpselt teada, mida vajate.

Selle tulemusel ei tohiks te sõltumata sellest, mille pilvesüsteemiks valite, peatuda ühe toote juures. Kui aega on, tasub pilk peale visata ka teistele avatumatele lahendustele.

Toimub hea vestlus t.me/openbula Nad aitavad aktiivselt ega saada teid Google’ist probleemile lahendust otsima. Liitu meiega.

Allikas: www.habr.com

Lisa kommentaar