Hi almal. Hierdie artikel is geskryf vir diegene wat nog verskeur is tussen die keuse van virtualisasieplatforms en na die lees van 'n artikel uit die reeks "Ons het proxmox geïnstalleer en alles is reg, 6 jaar se uptyd is nie 'n enkele gaping nie." Maar na die installering van een of ander boksoplossing, ontstaan die vraag, hoe om dit hier reg te stel, sodat monitering meer verstaanbaar is en hier om rugsteun te beheer .... En dan kom die tyd en jy verstaan dat jy iets meer funksioneel wil hê, wel, of jy wil hê alles moet duidelik in jou stelsel word, en nie hierdie swart boks nie, of jy wil iets meer as 'n hiperviser en 'n klomp virtuele masjiene gebruik . In hierdie artikel sal daar 'n paar refleksies en oefening wees gebaseer op die Opennebula platform - ek het dit gekies omdat. is nie veeleisend op hulpbronne nie en die argitektuur is nie so ingewikkeld nie.
En so, soos ons sien, werk baie wolkverskaffers op kvm en maak 'n eksterne harnas om masjiene te beheer. Dit is duidelik dat groot gashere hul eie bindings vir wolkinfrastruktuur skryf, dieselfde YANDEX byvoorbeeld. Iemand gebruik openstack en maak 'n binding op hierdie basis - SELECTEL, MAIL.RU. Maar as jy jou eie hardeware en 'n klein personeel van spesialiste het, dan kies hulle gewoonlik iets uit klaargemaakte - VMWARE, HYPER-V, daar is gratis lisensies en betaalde lisensies, maar nou gaan dit nie daaroor nie. Kom ons praat oor entoesiaste - dit is diegene wat nie bang is om iets nuuts aan te bied en te probeer nie, ten spyte van die feit dat die maatskappy dit duidelik gestel het "Wie sal dit na jou bedien", "Sal ons dit dan uitrol vir verkoop? Skrikwekkend." Maar jy kan immers eers hierdie oplossings in 'n toetsbank toepas, en as almal daarvan hou, dan kan jy die kwessie van verdere ontwikkeling en gebruik in meer ernstige omgewings opper.
Hier is ook 'n skakel na die berig. van 'n aktiewe deelnemer aan die ontwikkeling van hierdie platform.
Miskien sal iets in hierdie artikel oorbodig wees en is reeds duidelik vir 'n ervare spesialis, en in sommige gevalle sal ek nie alles beskryf nie, want soortgelyke opdragte en beskrywings is op die netwerk. Dit is net my ervaring met hierdie platform. Ek hoop die aktiewe deelnemers sal in die kommentaar byvoeg wat beter gedoen kan word en watter foute ek gemaak het. Alle aksies was in die toestande van 'n tuisstaander wat bestaan uit 3 PC's met verskillende eienskappe. Ek het ook nie spesifiek begin om aan te dui hoe hierdie sagteware werk en hoe om dit te installeer nie. Nee, slegs ervaring van administrasie en probleme wat in die gesig gestaar is. Miskien sal iemand dit nuttig vind om te kies.
En so, kom ons begin. As 'n stelseladministrateur is die volgende punte vir my belangrik, waarsonder dit onwaarskynlik is dat ek hierdie oplossing sal gebruik.
1. Installasie herhaalbaarheid
Daar is tonne instruksies vir die installering van oopnebula, jy behoort geen probleme daarmee te hê nie. Van weergawe tot weergawe verskyn nuwe kenmerke wat nie altyd verdien kan word wanneer van weergawe na weergawe beweeg word nie.
2. Monitering
Ons sal die nodus self, kvm en oopnebula monitor. Gelukkig is dit reeds gereed. Daar is baie opsies oor die monitering van linux-gashere, dieselfde zabbix- of nodus-uitvoerder - wie ook al daarvan hou - op die oomblik definieer ek dit sodat die monitering van stelselstatistieke (temperatuur waar dit gemeet kan word, skyfskikking konsekwentheid), deur zabbix, maar wat aansoeke deur die uitvoerder in prometheus betref. Vir kvm-monitering, byvoorbeeld, kan jy 'n projek neem en sit die bekendstelling deur systemd, dit werk redelik goed en wys kvm-statistieke, daar is ook 'n klaargemaakte dashboard .
Byvoorbeeld, hier is my lêer:
/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.targetEn so ons het 1 uitvoerder, ons het 'n tweede een nodig om die oopnevel self te monitor, ek het dit gebruik
Kan by gewone gevoeg word om die stelsel soos volg te monitor.
In die node_exporter-lêer verander ons die begin op hierdie manier:
ExecStart=/usr/sbin/node_exporter --web.listen-address=":9102" --collector.textfile.directory=/var/lib/opennebula_exporter/textfile_collectorSkep gids mkdir -p /var/lib/opennebula_exporter
bash script hierbo aangebied, kyk eers na die werk deur die konsole, as dit wys wat ons nodig het (as dit 'n fout gee, plaas ons xmlstarlet), kopieer dit na /usr/local/bin/opennebula_exporter.sh
Voeg 'n cron-taak by vir elke minuut:
*/1 * * * * (/usr/local/bin/opennebula_exporter.sh > /var/lib/opennebula_exporter/textfile_collector/opennebula.prom)Metrieke het begin verskyn, jy kan dit saam met Prometheus neem en grafieke bou en waarskuwings maak. In grafana, byvoorbeeld, kan jy so 'n eenvoudige dashboard teken.
(Jy kan sien dat ek hier wel cpu, ram oorgeplaas het)
Vir diegene wat van Zabbix hou en gebruik, is daar
Op die monitering van alles, die belangrikste ding is. Natuurlik, met behulp van die ingeboude virtuele masjien-moniteringsinstrumente en die oplaai van data na faktuur, het almal ook hul eie visie, totdat hulle dit nader begin doen het.
Om aan te meld, terwyl veral nie begin nie. Die maklikste opsie is om td-agent by te voeg om die /var/lib/one-gids met gereelde uitdrukkings te ontleed. Byvoorbeeld, die sunstone.log-lêer pas by die nginx regexp en ander lêers wat die geskiedenis van toegang tot die platform wys - wat is die pluspunt? Wel, byvoorbeeld, ons kan die nommer van "Fout, fout" uitdruklik opspoor en vinnig opspoor waar en op watter vlak daar 'n wanfunksie is.
3. Rugsteun
Daar is ook betaalde voltooide projekte - byvoorbeeld sep :OpenNebula_Backup. Hier moet ons verstaan dat die rugsteun van die beeld van die masjien, in hierdie geval, glad nie is nie, want ons virtuele masjiene moet met volle integrasie werk (dieselfde lêerkonteks wat die netwerkinstellings, die vm-naam en pasgemaakte instellings vir beskryf jou toepassings). Daarom bepaal ons hier wat en hoe ons sal rugsteun. In sommige gevalle is dit beter om afskrifte te maak van wat in die vm self is. En miskien moet jy net een skyf van hierdie masjien rugsteun.
Ons het byvoorbeeld vasgestel dat alle masjiene met aanhoudende beelde begin, dus na lees
so ons kan eers die prent vanaf ons vm oplaai:
onevm disk-saveas 74 3 prom.qcow2
Image ID: 77
Смотрим, под каким именем он сохранился
oneimage show 77
/var/lib/one//datastores/100/f9503161fe180658125a9b32433bf6e8
И далее копируем куда нам необходимо. Конечно, так себе способ. Просто хотел показать, что используя инструменты opennebula можно строить подобные решения.Ook op die net gevind en daar is meer , maar hier slegs onder qcow2-berging.
Maar soos ons almal weet, kom daar vroeër of later 'n oomblik wanneer jy inkrementele rugsteun wil hê, dit is moeiliker en miskien sal die bestuur geld toewys vir 'n betaalde oplossing, of anderpad gaan en verstaan dat ons hier net hulpbronne sny, en maak besprekings op toepassingsvlak en die byvoeging van die aantal nuwe nodusse en virtuele masjiene - ja, hier, ek sê dat die gebruik van die wolk suiwer is vir die bekendstelling van toepassingsgroepe, en om die databasis op 'n ander platform te laat loop of dit gereed te neem vanaf die verskaffer, indien moontlik .
4. Gebruiksgemak
In hierdie paragraaf sal ek die probleme beskryf wat ek teëgekom het. Byvoorbeeld, volgens beelde, soos ons weet, is daar aanhoudend - wanneer hierdie beeld op 'n vm gemonteer word, word alle data na hierdie beeld geskryf. En as dit nie aanhoudend is nie, word die prent na die berging gekopieer en die data word geskryf na wat van die oorspronklike prent gekopieer is - dit is hoe sjabloon spasies werk. Hy het herhaaldelik probleme vir homself veroorsaak deur te vergeet om aanhoudend te spesifiseer en die 200 GB beeld is gekopieer, die probleem is dat hierdie prosedure nie vir seker gekanselleer kan word nie, jy moet na die node gaan en die huidige "cp" proses doodmaak.
Een van die belangrike nadele is dat jy nie aksies kan ongedaan maak met bloot die gui nie. Of eerder, jy sal hulle kanselleer en sien dat niks gebeur nie en weer begin, kanselleer en eintlik sal daar reeds 2 cp prosesse wees wat die beeld kopieer.
En dan kom dit by die begrip waarom oopnebula elke nuwe instansie met 'n nuwe id nommer, byvoorbeeld, in dieselfde proxmox het 'n vm met id 101 geskep, dit uitgevee, en dan id 101 herskep. Dit sal nie in oopnebula gebeur nie, elke nuwe instansie sal geskep word met 'n nuwe ID en dit het sy eie logika - byvoorbeeld die skoonmaak van ou data of onsuksesvolle installasies.
Dieselfde geld vir berging, die meeste van alles is hierdie platform gemik op gesentraliseerde berging. Daar is byvoegings vir die gebruik van plaaslike, maar in hierdie geval gaan dit nie daaroor nie. Ek dink dat iemand in die toekoms 'n artikel sal skryf oor hoe hulle dit reggekry het om plaaslike berging op nodusse te gebruik en dit suksesvol in produksie te gebruik.
5. Maksimum eenvoud
Natuurlik, hoe verder jy gaan, hoe minder word diegene wat jou sal verstaan.
In die toestande van my staanplek - 3 nodusse met nfs-berging - werk alles goed. Maar as ons eksperimente uitvoer om die krag af te skakel, dan byvoorbeeld, wanneer ons 'n momentopname laat loop en die krag van die nodus afskakel, stoor ons die instellings in die databasis, dat daar 'n momentopname is, maar dit is eintlik nie (wel, ons verstaan almal dat ons aanvanklik die databasis oor hierdie aksie in sql geskryf het, maar die operasie self was nie suksesvol nie). Die voordeel is dat wanneer 'n momentopname geskep word, 'n aparte lêer gevorm word en daar is 'n "ouer", dus, in geval van probleme en selfs al werk dit nie deur die gui nie, kan ons die qcow2-lêer optel en afsonderlik herstel
Op netwerke is alles ongelukkig nie so eenvoudig nie. Wel, dit is ten minste makliker as in openstack, ek het net vlan (802.1Q) gebruik - dit werk goed, maar as jy veranderinge aan die instellings maak vanaf die sjabloonnetwerk, dan sal hierdie instellings nie toegepas word op reeds werkende masjiene nie, dit wil sê jy moet 'n netwerkkaart uitvee en byvoeg, dan sal die nuwe instellings toegepas word.
As jy nog met openstack wil vergelyk, kan jy dit sê, in opennebula is daar geen duidelike definisie van watter tegnologieë om te gebruik vir databerging, netwerkbestuur, hulpbronne nie - elke administrateur besluit self wat vir hom geriefliker is.
6. Bykomende plugins en installasies
Na alles, soos ons verstaan, kan die wolkplatform nie net kvm bestuur nie, maar ook vmware esxi. Ongelukkig het ek nie 'n swembad met Vcenter gehad nie, as iemand probeer skryf het.
Ter ondersteuning van ander wolkverskaffers, word gesê
AWS, AZURE.
Ek het ook probeer om Vmware Cloud van selectel te bind, maar niks het gebeur nie - oor die algemeen het ek 'n telling behaal omdat daar baie faktore is, en dit maak geen sin om aan die tegniese ondersteuning van die gasheerverskaffer te skryf nie.
Ook, nou in die nuwe weergawe is daar 'n vuurkraker - dit is die bekendstelling van mikrovm, soos kvm-binding oor docker, wat selfs meer veelsydigheid, sekuriteit en werkverrigtingverbeterings gee, aangesien dit nie nodig is om hulpbronne op hardeware-emulasie te mors nie. Ek sien net 'n voordeel met betrekking tot die koppelaar dat dit nie 'n addisionele aantal prosesse opneem nie en daar is geen besette voetstukke wanneer hierdie emulasie gebruik word nie, d.w.s. dit is heel moontlik om dit as 'n lasbalanseerder te gebruik (maar dit is waarskynlik die moeite werd om 'n aparte artikel hieroor te skryf totdat jy al die toetse volledig voltooi het).
7. Positiewe gebruikerservaring en foutontfouting
Ek wou my waarnemings oor die werk deel, ek het 'n deel daarvan hierbo beskryf, ek wil meer skryf. Inderdaad, ek is seker nie die enigste een wat eers dink dat dit nie die regte stelsel is nie en oor die algemeen is alles 'n kruk - hoe werk hulle daarmee? Maar dan kom die begrip en dat alles redelik logies is. Natuurlik kan jy nie almal tevrede stel nie, en sommige dinge moet verbeter word.
Byvoorbeeld, 'n eenvoudige bewerking om 'n skyfbeeld van een datawinkel na 'n ander te kopieer. In my geval is daar 2 nodusse met nfs, ek stuur die beeld - kopiëring gaan deur die voorkant oopnebula, alhoewel ons almal gewoond is aan die feit dat data direk tussen gashere gekopieer moet word - in dieselfde vmware, hyper-v, ons is gewoond hieraan, maar hier aan 'n ander. Daar is 'n ander benadering en 'n ander ideologie, en in weergawe 5.12 is die "migreer na datastoor"-knoppie verwyder - net die masjien self word oorgedra, maar nie die berging nie. beteken gesentraliseerde berging.
Verder, 'n gewilde fout met verskeie redes "Fout met die implementering van virtuele masjien: Kon nie domein skep vanaf /var/lib/one//datastores/103/10/deployment.5" Hieronder is die belangrikste ding om na te kyk.
- Regte op die prent vir die oneadmin-gebruiker;
- Toestemmings vir die oneadmin-gebruiker om libvirtd uit te voer;
- Is die datastoor korrek gemonteer? Gaan kyk die pad op die node self, iets het dalk afgeval;
- 'n Verkeerd gekonfigureerde netwerk, of eerder op die frontend, is in die netwerkinstellings dat br0 die hoofkoppelvlak vir vlan is, en bridge0 is op die nodus geskryf - dit moet dieselfde wees.
Die stelseldatastoor stoor metadata vir jou vm, as jy 'n vm met 'n aanhoudende beeld bestuur, dan moet die vm toegang hê tot die aanvanklik geskepte konfigurasie op die berging waar jy die vm geskep het - dit is baie belangrik. Daarom, wanneer u vm na 'n ander datawinkel oordra, moet u alles dubbel kontroleer.
8. Dokumentasie, gemeenskap. Verdere ontwikkeling
En die res, goeie dokumentasie, gemeenskap, en die belangrikste, dat die projek in die toekoms bly leef.
Hier is alles oor die algemeen redelik goed gedokumenteer, en selfs volgens 'n amptelike bron sal dit nie 'n probleem wees om vrae vas te stel en antwoorde te vind nie.
Gemeenskap aktief. Dit publiseer baie klaargemaakte oplossings wat jy in jou installasies kan gebruik.
Op die oomblik het sommige beleide in die maatskappy verander sedert 5.12 Dit sal interessant wees om te sien hoe die projek ontwikkel. Aan die begin het ek spesifiek gewys op sommige van die verkopers wat hul oplossings gebruik en wat die bedryf bied. Natuurlik is daar geen duidelike antwoord wat om vir jou te gebruik nie. Maar vir kleiner organisasies is die instandhouding van hul eie klein private wolk dalk nie so duur soos dit lyk nie. Die belangrikste ding is om presies te weet wat jy nodig het.
As gevolg hiervan, maak nie saak wat u as 'n wolkstelsel kies nie, u moet nie by een produk stop nie. As jy tyd het, moet jy na ander meer oop oplossings kyk.
Daar word lekker gesels aktief help en nie stuur om 'n oplossing vir die probleem in Google te soek nie. Sluit aan.
Bron: will.com