Pozdravljeni vsi. Ta članek je napisan za tiste, ki se še vedno odločajo med izbiro virtualizacijskih platform, pa po branju članka iz serije 'Namestili smo proxmox in vse je super, 6 let brez prekinitev'. Toda po namestitvi katerega koli od teh rešitev, se pojavi vprašanje, kako prilagoditi sistem, da bo spremljanje bolj jasno in kako nadzorovati varnostne kopije... Nato pa pride čas in spoznaš, da želiš nekaj bolj funkcionalnega, ali pa želiš, da je v tvojem sistemu vse pregledno, namesto da imaš črno škatlo, ali želiš uporabiti nekaj več kot samo hipervizor in kup virtualnih strojev. V tem članku bomo podali nekaj razmišljanj in praktičnih nasvetov na osnovi platforme OpenNebula – izbrana je bila, ker ni zahtevna glede virov in je arhitektura dovolj preprosta.
Torej, kot vidimo, mnogi oblačni ponudniki delujejo na KVM in ustvarjajo zunanje vmesnike za upravljanje strojev. Jasno je, da veliki gostitelji razvijajo svoje vmesnike za oblačno infrastrukturo, kot je YANDEX. Nekateri uporabljajo OpenStack in ustvarjajo vmesnike na tej osnovi – SELECTEL, MAIL.RU. Ampak, če imate svojo strojno opremo in majhno ekipo strokovnjakov, običajno izberejo nekaj pripravljenega – VMWARE, HYPER-V, na voljo so brezplačne in plačljive licence, vendar o tem zdaj ne bomo razpravljali. Povedali bomo o entuzijastih – to so tisti, ki se ne bojijo predlagati in preizkušati nove stvari, kljub temu da je v podjetju očitno bilo povedano 'Kdo bo to potem vzdrževal?' 'Ali bomo to sploh uvedli v produkcijo? Strašno.' Ampak vendar lahko ti rešitve najprej preizkusite v testnem okolju in če se vsem dopade, lahko postavite vprašanje o nadaljnjem razvoju in uporabi v resnejših okoljih.
Tukaj je tudi povezava do poročila od aktivnega udeleženca pri razvoju te platforme.
V tejto článku môžu byť niektoré informácie nadbytočné a už zrozumiteľné pre skúseného odborníka, a v niektorých prípadoch nebudem opisovať všetko, pretože podobné príkazy a opisy sú dostupné na internete. Tu je len moja skúsenosť s touto platformou. Dúfam, že aktívni účastníci doplnia v komentároch, čo by sa dalo zlepšiť a aké chyby som urobil. Všetky akcie prebiehali v podmienkach domáceho nastavenia tvoreného z 3 PC s rôznymi charakteristikami. Takisto som sa úmyselne nerozhodol uvádzať, ako tento softvér funguje a ako ho nainštalovať. Nie, iba skúsenosti z administrácie a problémy, s ktorými som sa stretol. Možno to niekomu pomôže pri rozhodovaní.
A tak, poďme na to. Pre mňa ako systémového administrátora sú dôležité nasledujúce body, bez ktorých sa ťažko rozhodnem pre toto riešenie.
1. Opakovateľnosť inštalácie
Existuje množstvo návodov na inštaláciu opennebula, tu by nemali vzniknúť problémy. Z verzie na verziu sa objavujú nové funkcie, ktoré nemusia vždy fungovať pri prechode z verzie na verziu.
2. Monitoring
Budeme monitorovať samotný uzol, kvm a opennebula. Našťastie už existujú pripravené nástroje. O monitorovaní linuxových hostiteľov je množstvo možností, ako napríklad Zabbix alebo Node Exporter — kto čo preferuje — momentálne určuje, že monitorovanie systémových metrík (teplota tam, kde je možné to merať, konzistencia diskového poľa), cez Zabbix, a čo sa týka aplikácií, cez exportér do Promethea. Pre monitorovanie kvm napríklad môžeme použiť projekt a nastaviť spustenie cez systemd, celkom dobre funguje a ukazuje metriky kvm, rovnako je k dispozícii pripravený dashboard .
Napríklad, tu je môj súbor:
/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.targetA tak máme 1 exportér, potrebujeme druhý na monitorovanie samotného opennebula, použil som takýto
Môžeme pridať do bežného na monitorovanie systému nasledujúce.
V súbore node_exporter zmeníme štart nasledovne:
ExecStart=/usr/sbin/node_exporter --web.listen-address=":9102" --collector.textfile.directory=/var/lib/opennebula_exporter/textfile_collectorVytvorte adresár mkdir -p /var/lib/opennebula_exporter
bash skript uvedený vyššie najprv skontrolujeme fungovanie cez terminál, ak zobrazuje to, čo má (ak vyhodí chybu, tak nainštalujeme xmlstarlet), skopírujeme ho do /usr/local/bin/opennebula_exporter.sh
Pridáme do Cron úlohu na každú minútu:
* /1 * * * * (/usr/local/bin/opennebula_exporter.sh > /var/lib/opennebula_exporter/textfile_collector/opennebula.prom)Metrične funkcionalnosti so postale na voljo, lahko jih pridobimo preko Prometeusa, izrišemo grafi in nastavimo alarm. V Grafani lahko na primer pripravimo tako enostaven nadzorni plošči.
(vidno je, da sem tukaj naredil overcommit cpu, ram)
Za tiste, ki uporabljajo in imajo radi Zabbix, je na voljo
To je vse glede monitoringa, najpomembnejše je, da obstaja. Seveda se lahko dodatno uporabi vgrajene funkcije za spremljanje virtualnih strojev in podatke izvozi v billing, tukaj ima vsak svoje poglede, zaenkrat se s tem še nisem ukvarjal.
Glede logiranja, se še nisem posebej lotil. Najenostavnejša možnost je dodati td-agent za parsing direktorija /var/lib/one s pomočjo regularnih izrazov. Na primer, datoteka sunstone.log ustreza regexp nginx ter druge datoteke, ki prikazujejo zgodovino interakcij s platformo — kakšna je korist? No, na primer lahko jasno sledimo številu "Error, error" in hitreje ugotovimo, kje in na katerem nivoju je napaka.
3. Varnostne kopije
Na voljo so tudi plačljivi obsežnejši projekti — na primer sep :OpenNebula_Backup. Tukaj moramo razumeti, da samo backup slike stroja v tem primeru ni dovolj, saj morajo naši virtualni stroji delovati z popolno integracijo (prav tisti kontekst datoteke, v kateri so opisane nastavitve omrežja, ime vm in prilagojene nastavitve za aplikacije). Zato se dogovorimo, kaj in kako bomo varnostno kopirali. V nekaterih primerih je bolje kopirati tisto, kar se nahaja v sami vm. Morda je potrebno varnostno kopirati samo en disk tega stroja.
Na primer, odločili smo se, da se vsi stroji zaženejo s trajnimi slikami, s čimer smo prebrali
to pomeni, da lahko najprej iz naše vm izvozimo sliko:
onevm disk-saveas 74 3 prom.qcow2
ID slike: 77
Oglejmo si, pod katerim imenom se je shranila
oneimage show 77
/var/lib/one//datastores/100/f9503161fe180658125a9b32433bf6e8
In nato jo kopiramo kamor potrebujemo. Seveda, to ni najboljši način. Le želel sem pokazati, da je mogoče z orodji OpenNebula graditi podobne rešitve.Prav tako sem na spletu našel in obstaja še , vendar je tu le za qcow2 shranjevanje.
Kot sva vsi vemo, prej ali slej pride trenutek, ko si želimo inkrementalnih varnostnih kopij; tukaj je situacija bolj zapletena, morda bo vodstvo dodelilo sredstva za plačljivo rešitev, ali pa se odpraviti po drugi poti z zavedanjem, da tukaj le porabljamo vire, rezervacije pa bi izvajali na ravni aplikacij in dodajali število novih vozlišč in virtualk — ja, tukaj govorim, da uporabim oblak izključno za zagon aplikacijskih grozdov, baze podatkov pa zagnati na drugi platformi ali vzeti pripravljene rešitve od dobavitelja, kjer je to mogoče.
4. Uporabniška prijaznost
V tem odstavku opisujem težave, s katerimi sem se srečal. Na primer, kar se tiče slik, kot vemo, obstaja persistent — pri montaži te slike na VM se vsi podatki zapisujejo v to sliko. Če pa je non-persistent, se slika kopira na shranjevanje in podatki se pišejo v to, kar je bilo skopirano iz izvorne slike — tako delujejo predloge. Večkrat sem povzročil težave sebi, ker sem pozabil označiti persistent, in 200 GB slika se je kopirala; težava je v tem, da te operacije ni mogoče preklicati, moraš iti na vozlišče in ustaviti trenutni postopek „cp“.
Ena od pomembnih slabosti je, da dejanj ne moreš preprosto preklicati z uporabo GUI. Natančneje, preklical jih boš, a videl boš, da se nič ne dogaja, in ponovno boš zagnal proces; preklical boš, in dejansko bo že potekalo 2 procesa cp, ki kopirata sliko.
In tukaj pride razumevanje, zakaj opennebula vsako novo instanco označuje z novim ID-jem; na primer, v proxmoxu ustvariš VM z ID-jem 101, jo izbrišeš, potem jo ponovno ustvariš, in ID je spet 101. V opennebuli tega ne bo; vsaka nova instanca bo ustvarjena z novim ID-jem, in v tem je svojo logiko — na primer, čiščenje starih podatkov ali neuspešnih namestitev.
Enako velja za shranjevanje; ta platforma je najbolj usmerjena v centralizirano shranjevanje. Obstajajo dodatki za uporabo lokalnega shranjevanja, a v tem primeru to ni cilj. Mislim, da bo v prihodnosti nekdo napisal članek o tem, kako je mogoče uspešno uporabljati lokalno shranjevanje na vozliščih v produkciji.
5. Maksimalna enostavnost
Seveda, bolj ko napreduješ, manj je tistih, ki te bodo razumeli.
V mojem okolju — 3 vozlišča z nfs shrambo — vse deluje brez težav. Toda, če izvedemo eksperimente z izklopom napajanja, se ob zagonu posnetka in izklopu napajanja vozlišča shranijo nastavitve v BDP, kar pomeni, da obstaja posnetek, dejansko pa ga ni (vsi razumemo, da je prvotno zapisano v sql bazo o tej akciji, vendar je bila operacija neuspešna). Prednost je, da se ob ustvarjanju posnetka ustvari poseben datotek in obstaja „starš“, zato v primeru težav in celo če preko gui ne deluje, lahko vzamemo qcow2 datotek in ga obnovimo posamično.
O omrežjih žal ni tako preprosto. No, vsaj lažje kot v openstacku, uporabljal sem samo vlan (802.1Q) — deluje povsem dobro, toda če v preglednici omrežja naredite spremembe v nastavitvah, se te nastavitve ne bodo uporabile na že delujočih strojih, torej je potrebno odstraniti in dodati omrežno kartico, potem se nove nastavitve uporabijo.
Če želite primerjati z openstackom, bi lahko rekli, da v opennebuli ni jasne definicije, katere tehnologije uporabiti za shranjevanje podatkov, upravljanje omrežja, virov — vsak skrbnik se odloči sam, kako mu bolj ustreza.
6. Dodatni vtičniki in namestitve
Kot razumemo, lahko oblačna platforma upravlja ne samo kvm, temveč tudi vmware esxi. Žal nimam bazena z Vcenter, če je kdo poskusil, naj piše.
V podpori drugih oblačnih ponudnikov je navedeno
AWS, AZURE.
Poskusil sem tudi povezati Vmware Cloud od Selectela, a ni uspelo — na splošno sem obupal, ker je preveč dejavnikov, pisanje v tehnično podporo ponudnika gostovanja nima smisla.
Prav tako, sedaj v novi različici obstaja firecracker — to je zagon microvm, nekakšna kvm obloga nad dockerjem, kar omogoča še večjo univerzalnost, varnost in povečanje zmogljivosti, saj ni potrebno trošiti virov na emulacijo strojne opreme. Vidim le prednost v primerjavi z dockerjem, da ne zaposluje dodatnih procesov in ni zasedenih socketov pri uporabi te emulacije, torej ga je mogoče uporabljati kot uravnavalnik obremenitve (o tem pa bi verjetno morali napisati posebej, dokler nisem izpeljal vseh testov v celoti).
7. Pozitivne izkušnje in odpravljanje napak
Želel sem deliti svoje opazovanje o delovanju, deloma sem ga opisal zgoraj, želim napisati več. Res je, verjetno nisem edini, ki najprej misli, da to ni tisti sistem in da je vse skupaj precej začasno — kako se s tem sploh dela? A nato pride razumevanje, da je vse povsem logično. Seveda ni mogoče ustreči vsem in nekateri vidiki zahtevajo izboljšave.
Na primer, preprosta operacija kopiranja slike diska z enega podatkovnega skladišča na drugo. V mojem primeru sta tu 2 vozlišča z nfs, pošiljam sliko — kopiranje poteka preko frontend opennebule, čeprav smo vsi navajeni, da se podatki kopirajo neposredno med gosti — pri VMware, Hyper-V smo navajeni prav tega, toda tukaj je drugače. Tu je drugačen pristop in druga ideologija, v različici 5.12 pa so odstranili gumb »migrate to datastore« — premika se le sam stroj, ne pa shranjevanje, ker se predpostavlja centralizirano shranjevanje.
Nato pogosta napaka z različnimi razlogi »Error deploying virtual machine: Could not create domain from /var/lib/one//datastores/103/10/deployment.5«. Spodaj bo seznam, na kaj je treba paziti.
- Dostop do slike za uporabnika oneadmin;
- Dostop za uporabnika oneadmin za zagon libvirtd;
- Ali je podatkovno skladišče pravilno montirano? Pojdi in preveri pot na samem vozlišču, morda je nekaj odpovedalo;
- Napačno konfigurirana mreža, natančneje na frontend je v nastavitvah omrežja navedeno, da je br0 glavni vmesnik za VLAN, na vozlišču pa je zapisano — bridge0 — mora biti enako.
System datastore shranjuje metapodatke za vašo VM, če zagnate VM s persistent image, mora imeti VM dostop do prvotne konfiguracije na tistem shranjevanju, kjer ste ustvarili VM — to je zelo pomembno. Zato je pri prenosu VM na drugo podatkovno skladišče potrebno vse preveriti.
8. Dokumentacija, skupnost. Nadaljnji razvoj
In še to, dobra dokumentacija, skupnost in predvsem, da projekt v prihodnje še naprej živí.
Tu je na splošno vse precej dobro dokumentirano in tudi po uradnem viru ne bi smeli imeti težav pri namestitvi in iskanju odgovorov na vprašanja.
Skupnost, aktivna. Objavlja veliko pripravljenih rešitev, ki jih lahko uporabite v svojih namestitvah.
Trenutno so se s 5.12 spremenile nekatere politike v podjetju. Bilo bi zanimljivo saznati kako će se projekt razvijati. Na početku sam namjerno naveo nekoliko dobavljača koji koriste svoja rješenja i ono što industrija nudi. Naravno, ne postoji definitivan odgovor što koristiti. No, za manje organizacije podrška vlastitom malom privatnom oblaku može biti jeftinija nego što se čini. Najvažnije je točno znati što vam treba.
Kao zaključak, bez obzira na to što odaberete kao oblačni sustav, ne trebate se zadržavati na jednom proizvodu. Ako imate vremena, vrijedi razmotriti i druga otvorenija rješenja.
Postoji dobar chat aktivno pomažu i ne šalju vas da tražite rješenje problema na Googleu. Pridružite se.
Izvor: habr.com
