Saluton al ĉiuj. Ĉi tiu artikolo estis skribita por tiuj, kiuj ankoraŭ estas disŝiritaj inter elektado de platformoj de virtualigo kaj post legi la artikolon de la serio "Ni instalis proxmox kaj ĝenerale ĉio estas en ordo, 6 jarojn da funkciado sen ununura paŭzo." Sed post instalo de unu aŭ alia eltrovebla solvo, stariĝas la demando: kiel mi povas korekti ĉi tion ĉi tie, por ke la monitorado estu pli komprenebla, kaj ĉi tie, por kontroli sekurkopiojn.... Kaj tiam venas la tempo kaj vi rimarkas, ke vi volas ion pli funkcian, aŭ vi volas, ke ĉio ene de via sistemo fariĝu klara, kaj ne ĉi tiun nigran skatolon, aŭ vi volas uzi ion pli ol hiperviziilon kaj amason da virtualaj maŝinoj. Ĉi tiu artikolo enhavos kelkajn pensojn kaj praktikojn bazitajn sur la platformo Opennebula - mi elektis ĝin ĉar. ĝi ne estas postulema je rimedoj kaj la arkitekturo ne estas tiel kompleksa.
Kaj tiel, kiel ni vidas, multaj nubaj provizantoj laboras pri kvm kaj faras eksterajn konektojn por kontroli maŝinojn. Estas klare, ke grandaj gastigantoj skribas siajn proprajn kadrojn por nuba infrastrukturo, la sama YANDEX ekzemple. Iu uzas openstack kaj faras konekton sur ĉi tiu bazo - SELECTEL, MAIL.RU. Sed se vi havas vian propran aparataron kaj malgrandan kunlaborantaron de specialistoj, tiam vi kutime elektas ion pretan - VMWARE, HYPER-V, ekzistas senpagaj kaj pagitaj permesiloj, sed pri tio ni ne parolas nun. Ni parolu pri entuziasmuloj - ĉi tiuj estas tiuj, kiuj ne timas oferti kaj provi ion novan, malgraŭ tio, ke la kompanio klare klarigis, "Kiu servos ĉi tion post vi," "Ĉu ni poste realigos ĉi tion en produktadon. ? Timiga." Sed vi povas unue apliki ĉi tiujn solvojn en prova benko, kaj se ĉiuj ŝatas ĝin, tiam vi povas levi la demandon pri plua disvolviĝo kaj uzo en pli seriozaj medioj.
Ankaŭ ĉi tie estas ligilo al la raporto de aktiva partoprenanto en la evoluo de ĉi tiu platformo.
Eble en ĉi tiu artikolo io estos superflua kaj jam komprenebla por sperta specialisto, kaj en iuj kazoj mi ne priskribos ĉion ĉar similaj komandoj kaj priskriboj estas haveblaj en la Interreto. Ĉi tio estas nur mia sperto kun ĉi tiu platformo. Mi esperas, ke aktivaj partoprenantoj aldonos en la komentoj, kion oni povus pli bone fari kaj kiajn erarojn mi faris. Ĉiuj agoj okazis en hejma stando konsistanta el 3 komputiloj kun malsamaj karakterizaĵoj. Ankaŭ, mi specife ne indikis kiel ĉi tiu programaro funkcias kaj kiel instali ĝin. Ne, nur administra sperto kaj la problemoj kiujn mi renkontis. Eble ĉi tio estos utila al iu en ilia elekto.
Do, ni komencu. Kiel sistemadministranto, la sekvaj punktoj estas gravaj por mi, sen kiuj mi verŝajne ne uzos ĉi tiun solvon.
1. Ripeteblo de instalado
Estas multaj instrukcioj por instali opennebula, ne devus esti problemoj. De versio al versio aperas novaj funkcioj, kiuj ne ĉiam funkcios kiam oni moviĝas de versio al versio.
2. Monitorado
Ni kontrolos la nodon mem, kvm kaj opennebula. Feliĉe, ĝi jam estas preta. Estas multaj ebloj pri monitorado de Linuksaj gastigantoj, la sama Zabbix aŭ nodo-eksportanto - al kiu plaĉas kio pli bone - nuntempe mi difinas ĝin kiel monitoradsisteman metrikon (temperaturo kie ĝi povas esti mezurita, konsistenco de la disko-tabelo), per zabbix. , kaj koncerne aplikojn per la eksportisto Prometheus. Por kvm-monitorado, ekzemple, vi povas preni la projekton kaj agordu ĝin funkcii per systemd, ĝi funkcias sufiĉe bone kaj montras kvm-metrikojn, ekzistas ankaŭ preta instrumentpanelo. .
Ekzemple, jen mia dosiero:
/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.targetKaj do ni havas 1 eksportilon, ni bezonas duan por monitori opennebula mem, mi uzis ĉi tion
Povas esti aldonita al normalo por kontroli la sistemon jene.
En la dosiero node_exporter ni ŝanĝas la komencon jene:
ExecStart=/usr/sbin/node_exporter --web.listen-address=":9102" --collector.textfile.directory=/var/lib/opennebula_exporter/textfile_collectorKreu dosierujon mkdir -p /var/lib/opennebula_exporter
bash-skripto prezentita supre, unue ni kontrolas la laboron per la konzolo, se ĝi montras kion ni bezonas (se ĝi donas eraron, tiam instalu xmlstarlet), kopiu ĝin al /usr/local/bin/opennebula_exporter.sh
Aldonu kron-taskon por ĉiu minuto:
*/1 * * * * (/usr/local/bin/opennebula_exporter.sh > /var/lib/opennebula_exporter/textfile_collector/opennebula.prom)Metrikoj komencis aperi, vi povas preni ilin kiel prometeo kaj konstrui grafikaĵojn kaj fari atentigojn. En Grafana oni povas desegni, ekzemple, tian simplan instrumentpanelon.
(estas klare, ke ĉi tie mi superas cpu, ram)
Por tiuj, kiuj amas kaj uzas Zabbix, ekzistas
Koncerne monitoradon, la ĉefa afero estas, ke ĝi estas tie. Kompreneble, vi povas, krome, uzi la enkonstruitajn virtualajn maŝinajn monitorajn ilojn kaj alŝuti datumojn al fakturado, ĉi tie ĉiu havas sian propran vizion, mi ankoraŭ ne komencis labori pri tio pli proksime.
Mi ankoraŭ ne vere komencis registri. La plej simpla opcio estas aldoni td-agent por analizi la dosierujon /var/lib/one kun regulaj esprimoj. Ekzemple, la sunstone.log dosiero kongruas kun la regexp nginx kaj aliaj dosieroj, kiuj montras la historion de aliro al la platformo - kio estas la avantaĝo de ĉi tio? Nu, ekzemple, ni povas eksplicite spuri la nombron de "Eraro, eraro" kaj rapide spuri kie kaj je kiu nivelo estas misfunkcio.
3. Rezervoj
Estas ankaŭ pagitaj finitaj projektoj - ekzemple sep :OpenNebula_Backup. Ĉi tie ni devas kompreni, ke simple sekurkopii maŝinan bildon tute ne estas la sama en ĉi tiu kazo, ĉar niaj virtualaj maŝinoj devas funkcii kun plena integriĝo (la sama kunteksta dosiero, kiu priskribas la retajn agordojn, vm-nomon kaj kutimajn agordojn por viaj aplikoj) . Tial ĉi tie ni decidas kion kaj kiel ni sekurkopios. En kelkaj kazoj estas pli bone fari kopiojn de kio estas en la VM mem. Kaj eble vi nur bezonas sekurkopii unu diskon de donita maŝino.
Ekzemple, ni determinis, ke ĉiuj maŝinoj komenciĝas per konstantaj bildoj, do post legado
Ĉi tio signifas, ke unue ni povas alŝuti la bildon de nia VM:
onevm disk-saveas 74 3 prom.qcow2
Image ID: 77
Смотрим, под каким именем он сохранился
oneimage show 77
/var/lib/one//datastores/100/f9503161fe180658125a9b32433bf6e8
И далее копируем куда нам необходимо. Конечно, так себе способ. Просто хотел показать, что используя инструменты opennebula можно строить подобные решения.Mi trovis ankaŭ en la interreto kaj estas pli , sed ekzistas nur stokado por qcow2.
Sed kiel ni ĉiuj scias, baldaŭ aŭ malfrue venas tempo, kiam vi volas pliigajn sekurkopiojn, ĉi tie estas pli malfacile kaj eble la administrado asignos monon por pagita solvo, aŭ iros aliman vojon kaj komprenos, ke ĉi tie ni nur tranĉas rimedojn, kaj fari sekurkopiojn ĉe la aplikaĵnivelo kaj aldoni kelkajn novajn nodojn kaj virtualajn maŝinojn - jes, ĉi tie, mi diras, ke uzi la nubon nur por lanĉi aplikaĵgrupojn, kaj lanĉi la datumbazon sur alia platformo aŭ preni pretan. de la provizanto, se eble.
4. Facileco de uzo
En ĉi tiu paragrafo mi priskribos la problemojn, kiujn mi renkontis. Ekzemple, laŭ bildoj, kiel ni scias, estas persista - kiam ĉi tiu bildo estas muntita al vm, ĉiuj datumoj estas skribitaj al ĉi tiu bildo. Kaj se ne persistas, tiam la bildo estas kopiita al la stokado kaj la datumoj estas skribitaj al tio, kio estis kopiita de la fonta bildo - jen kiel ŝablonoj de ŝablonoj funkcias. Mi plurfoje kaŭzis problemojn al mi mem forgesante specifi persistan kaj la bildo de 200 GB estis kopiita, la problemo estas, ke ĉi tiu proceduro certe ne povas esti nuligita, vi devas iri al la nodo kaj mortigi la nunan "cp" procezon.
Unu el la gravaj malavantaĝoj estas, ke vi ne povas nuligi agojn simple uzante la gui. Aŭ pli ĝuste, vi nuligos ilin kaj vidos, ke nenio okazas kaj vi rekomencos ilin, nuligos ilin kaj fakte jam estos 2 cp-procezoj, kiuj kopias la bildon.
Kaj tiam temas pri kompreni kial opennebula nombras ĉiun novan okazon per nova id, ekzemple, en la sama proxmox kreis vm kun id 101, forigis ĝin, tiam vi kreas ĝin denove kaj id 101. En opennebula tio ne okazos, ĉiu nova kazo estos kreita kun nova identigilo kaj ĉi tio havas sian propran logikon - ekzemple, malplenigo de malnovaj datumoj aŭ malsukcesaj instalaĵoj.
La sama validas por stokado; ĉefe, ĉi tiu platformo celas centralizitan stokadon. Estas aldonaĵoj por uzi lokan, sed pri tio ni ne parolas en ĉi tiu kazo. Mi pensas, ke estonte iu skribos artikolon pri kiel ili sukcesis uzi lokan stokadon sur nodoj kaj sukcese uzi ĝin en produktado.
5. Maksimuma simpleco
Kompreneble, ju pli vi iras, des malpli fariĝos tiuj, kiuj komprenos vin.
Sub la kondiĉoj de mia stando - 3 nodoj kun nfs-stokado - ĉio funkcias bone. Sed se ni faras eksperimentojn engaĝantajn elektropaneon, ekzemple, kiam oni rulas momentfoton kaj malŝaltas la potencon de la nodo, ni konservas agordojn en la datumbazo, ke ekzistas momentfoto, sed fakte ne ekzistas (nu, ni ĉiuj komprenas, ke ni komence skribis la datumbazon pri ĉi tiu ago en sql , sed la operacio mem ne sukcesis). La avantaĝo estas, ke dum kreado de momentfoto, aparta dosiero estas formita kaj estas "gepatro", do en kazo de problemoj kaj eĉ se ĝi ne funkcias per gui, ni povas preni la qcow2-dosieron kaj restarigi ĝin aparte.
En retoj, bedaŭrinde, ne ĉio estas tiel simpla. Nu, almenaŭ ĝi estas pli facila ol en openstack, mi uzis nur vlan (802.1Q) - ĝi funkcias sufiĉe bone, sed se vi faras ŝanĝojn al la agordoj el la ŝablono reto, tiam ĉi tiuj agordoj ne estos aplikataj al jam rulantaj maŝinoj, t.e. vi devas forigi kaj aldoni retan karton, tiam la novaj agordoj estos aplikataj.
Se vi ankoraŭ volas kompari ĝin kun openstack, tiam vi povas diri ĉi tion: en opennebula ne estas klara difino pri kiuj teknologioj uzi por stoki datumojn, administri la reton, rimedojn - ĉiu administranto decidas mem, kio estas pli oportuna por li.
6. Pliaj kromaĵoj kaj instalaĵoj
Post ĉio, kiel ni komprenas ĝin, la nuba platformo povas administri ne nur kvm, sed ankaŭ vmware esxi. Bedaŭrinde, mi ne havis naĝejon kun Vcenter, se iu provis, bonvolu skribi.
Subteno por aliaj nubaj provizantoj estas deklarita
AWS, LAZURO.
Mi ankaŭ provis konekti Vmware Cloud de Selectel, sed nenio funkciis - ĝenerale, ĝi estis blokita ĉar ekzistas multaj faktoroj, kaj ne utilas skribi al la teknika subteno de la gastiga provizanto.
Ankaŭ nun la nova versio havas petardon - ĉi tio estas la lanĉo de microvm, speco de kvm-jungilaro super docker, kiu donas eĉ pli da versatileco, sekureco kaj pliigita produktiveco ĉar ne necesas malŝpari rimedojn por emulado de ekipaĵo. La sola avantaĝo, kiun mi vidas super Docker, estas, ke ĝi ne okupas plian nombron da procezoj kaj ne estas okupataj ingoj kiam oni uzas ĉi tiun emuladon, t.e. Estas tute eble uzi ĝin kiel ŝargilon (sed verŝajne indas verki apartan artikolon pri tio ĝis mi plene plenumos ĉiujn testojn).
7. Pozitiva sperto pri uzo kaj erarpurigado
Mi volis kunhavigi miajn observojn pri la verko, mi priskribis kelkajn el ĝi supre, mi ŝatus skribi pli. Efektive, mi verŝajne ne estas la sola, kiu unue opinias, ke ĉi tio ne estas la ĝusta sistemo kaj ĝenerale ĉio ĉi tie estas lambastono - kiel ili eĉ funkcias kun ĉi tio? Sed tiam venas la kompreno, ke ĉio estas sufiĉe logika. Kompreneble, vi ne povas plaĉi al ĉiuj kaj iuj aspektoj postulas plibonigon.
Ekzemple, simpla operacio kopii diskobildon de unu datumvendejo al alia. En mia kazo, estas 2 nodoj kun nfs, mi sendas la bildon - kopiado okazas tra la fasado opennebula, kvankam ni ĉiuj kutimas al tio, ke datumoj estu kopiitaj rekte inter gastigantoj - en la sama vmware, hiper-v ni estas; alkutimiĝinta al ĉi tio, sed ĉi tie al alia. Estas malsama aliro kaj malsama ideologio, kaj en versio 5.12 ili forigis la butonon "migri al datumvendejo" - nur la maŝino mem estas translokigita, sed ne la stokado ĉar signifas centralizita stokado.
Sekva estas populara eraro kun diversaj kialoj: "Eraro dum virtuala maŝino: Ne eblis krei domajnon de /var/lib/one//datastores/103/10/deployment.5" Malsupre estas la ĉefa afero por rigardi.
- Bildrajtoj por la unuadministra uzanto;
- Permesoj por la unuadministra uzanto ruli libvirtd;
- Ĉu la datumvendejo estas muntita ĝuste? Iru kaj kontrolu la vojon sur la nodo mem, eble io defalis;
- Malĝuste agordita reto, aŭ pli ĝuste sur la fasado estas en la retaj agordoj, ke la ĉefa interfaco por vlan estas br0, sed sur la nodo ĝi estas skribita kiel bridge0 - ĝi devas esti la sama.
sistema datumvendejo stokas metadatenojn por via VM, se vi rulas la VM kun konstanta bildo, tiam la VM devas havi aliron al la komence kreita agordo sur la stokado kie vi kreis la VM - tio estas tre grava. Tial, kiam vi transdonas VM al alia datumvendejo, vi devas duoble kontroli ĉion.
8. Dokumentado, komunumo. Pluevoluigo
Kaj la resto, bona dokumentado, komunumo kaj la ĉefa afero estas, ke la projekto daŭre vivas en la estonteco.
Ĝenerale ĉio estas sufiĉe bone dokumentita kaj eĉ uzante oficialan fonton ne estos problemo instali kaj trovi respondojn al demandoj.
Community, aktiva. Eldonas multajn pretajn solvojn, kiujn vi povas uzi en viaj instalaĵoj.
Nuntempe iuj politikoj en la kompanio ŝanĝiĝis ekde 5.12 Estos interese vidi kiel evoluas la projekto. Komence, mi specife atentigis kelkajn el la vendistoj, kiuj uzas siajn solvojn kaj kion la industrio ofertas. Kompreneble, ne estas klara respondo pri tio, kion uzi. Sed por pli malgrandaj organizoj, konservi sian malgrandan privatan nubon eble ne estas tiel multekosta kiel ĝi ŝajnas. La ĉefa afero estas scii ĝuste kion vi bezonas.
Kiel rezulto, sendepende de tio, kion vi elektas kiel nuba sistemo, vi ne devus halti ĉe unu produkto. Se vi havas tempon, indas rigardi aliajn pli malfermajn solvojn.
Estas bona babilado Ili aktive helpas kaj ne sendas vin serĉi solvon al la problemo en Guglo. Aliĝu al ni.
fonto: www.habr.com