Otvorená hmlovina. Krátke poznámky

Otvorená hmlovina. Krátke poznámky

Ahojte všetci. Tento článok bol napísaný pre tých, ktorí sú stále zmietaní medzi výberom virtualizačných platforiem a po prečítaní článku zo série „Nainštalovali sme proxmox a vo všeobecnosti je všetko v poriadku, 6 rokov prevádzky bez jedinej prestávky.“ Po inštalácii jedného alebo druhého hotového riešenia však vyvstáva otázka: ako to môžem opraviť tu, aby bolo monitorovanie zrozumiteľnejšie, a tu kontrolovať zálohy…. A potom príde čas a vy si uvedomíte, že chcete niečo funkčnejšie, alebo chcete, aby sa všetko vo vašom systéme vyjasnilo, a nie táto čierna skrinka, alebo chcete použiť niečo viac ako hypervízor a kopu virtuálnych strojov. Tento článok bude obsahovať niekoľko myšlienok a postupov založených na platforme Opennebula – vybral som si ho preto. nie je náročná na zdroje a architektúra nie je taká zložitá.

A tak, ako vidíme, mnohí poskytovatelia cloudu pracujú na kvm a vytvárajú externé pripojenia k riadiacim strojom. Je zrejmé, že veľkí hostitelia píšu svoje vlastné rámce pre cloudovú infraštruktúru, napríklad rovnaký YANDEX. Niekto používa openstack a robí spojenie na tomto základe - SELECTEL, MAIL.RU. Ak však máte vlastný hardvér a malý tím špecialistov, zvyčajne si vyberiete niečo hotové - VMWARE, HYPER-V, existujú bezplatné a platené licencie, ale o tom teraz nehovoríme. Hovorme o nadšencoch - to sú tí, ktorí sa neboja ponúknuť a vyskúšať niečo nové, napriek tomu, že spoločnosť jasne povedala: „Kto to bude po vás obsluhovať“, „Zavedieme to do výroby neskôr ? Strašidelné." Tieto riešenia však môžete najskôr aplikovať v testovacej stolici a ak sa to všetkým páči, môžete nastoliť otázku ďalšieho vývoja a použitia vo vážnejších prostrediach.

Tu je tiež odkaz na správu www.youtube.com/watch?v=47Mht_uoX3A od aktívneho účastníka vývoja tejto platformy.

Možno v tomto článku bude niečo zbytočné a pre skúseného odborníka už pochopiteľné a v niektorých prípadoch nebudem popisovať všetko, pretože podobné príkazy a popisy sú k dispozícii na internete. Toto je len moja skúsenosť s touto platformou. Dúfam, že aktívni účastníci pridajú do komentárov, čo by sa dalo urobiť lepšie a aké chyby som urobil ja. Všetky akcie prebiehali v domácom stánku pozostávajúcom z 3 PC s rôznymi vlastnosťami. Tiež som konkrétne neuviedol, ako tento softvér funguje a ako ho nainštalovať. Nie, iba skúsenosti s administratívou a problémy, s ktorými som sa stretol. Možno to bude pre niekoho užitočné pri výbere.

Takže, začnime. Ako správca systému sú pre mňa dôležité nasledujúce body, bez ktorých je nepravdepodobné, že by som toto riešenie použil.

1. Opakovateľnosť inštalácie

Návodov na inštaláciu opennebuly je veľa, nemali by byť žiadne problémy. Z verzie na verziu sa objavia nové funkcie, ktoré pri prechode z verzie na verziu nebudú vždy fungovať.

2. Monitorovanie

Budeme monitorovať samotný uzol, kvm a opennebulu. Našťastie je to už pripravené. Možností monitorovania linuxových hostiteľov je veľa, rovnaký Zabbix alebo exportér uzlov - kto má rád čo lepšie - momentálne to definujem ako monitorovanie systémových metrík (teplota, kde sa dá merať, konzistencia diskového poľa), cez zabbix , a čo sa týka žiadostí cez exportéra Prometheus. Napríklad na monitorovanie kvm si môžete vziať projekt github.com/zhangjianweibj/prometheus-libvirt-exporter.git a nastav to aby sa to spustilo cez systemd, ide to celkom dobre a ukazuje kvm metriky, je tam aj hotovy dashboard grafana.com/grafana/dashboards/12538.

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.target

A tak máme 1 exportéra, potrebujeme druhého na monitorovanie samotnej opennebuly, použil som toto github.com/kvaps/opennebula-exporter/blob/master/opennebula_exporter

Dá sa pridať k normálu node_exporter na sledovanie systému nasledovné.

V súbore node_exporter zmeníme začiatok takto:

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

Vytvorte adresár mkdir -p /var/lib/opennebula_exporter

bash skript uvedený vyššie, najprv skontrolujeme prácu cez konzolu, ak ukazuje, čo potrebujeme (ak dáva chybu, potom nainštalujte xmlstarlet), skopírujte ho do /usr/local/bin/opennebula_exporter.sh

Pridajte úlohu cron pre každú minútu:

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

Začali sa objavovať metriky, môžete ich brať ako prometheus a vytvárať grafy a robiť upozornenia. V Grafane si môžete nakresliť napríklad taký jednoduchý dashboard.

Otvorená hmlovina. Krátke poznámky

(je jasné, že tu prebíjam cpu, ram)

Pre tých, ktorí milujú a používajú Zabbix, existuje github.com/OpenNebula/addon-zabbix

Čo sa týka monitoringu, hlavné je, že tam je. Samozrejme, môžete navyše využiť vstavané nástroje na monitorovanie virtuálnych strojov a nahrať dáta do fakturácie, tu má každý svoju víziu, bližšie som sa tomu zatiaľ venovať nezačal.

S logovaním som ešte poriadne nezačal. Najjednoduchšou možnosťou je pridať td-agent na analýzu adresára /var/lib/one s regulárnymi výrazmi. Napríklad súbor sunstone.log sa zhoduje s nginx regexp a ďalšími súbormi, ktoré zobrazujú históriu prístupu k platforme – aká je to výhoda? Môžeme napríklad explicitne sledovať počet „Chyba, chyba“ a rýchlo sledovať, kde a na akej úrovni došlo k poruche.

3. Zálohy

Sú aj zaplatené ukončené projekty - napr wiki.sepsoftware.com/wiki/index.php/4_4_3_Tigon:OpenNebula_Backup. Tu musíme pochopiť, že jednoduché zálohovanie obrazu stroja nie je v tomto prípade vôbec to isté, pretože naše virtuálne stroje musia fungovať s plnou integráciou (rovnaký kontextový súbor, ktorý popisuje nastavenia siete, názov vm a vlastné nastavenia pre vaše aplikácie) . Preto sa tu rozhodujeme, čo a ako budeme zálohovať. V niektorých prípadoch je lepšie urobiť kópie toho, čo je v samotnom vm. A možno potrebujete zálohovať iba jeden disk z daného počítača.

Napríklad sme určili, že všetky stroje začínajú s trvalými obrázkami, teda po prečítaní docs.opennebula.io/5.12/operation/vm_management/img_guide.html

To znamená, že najskôr môžeme nahrať obrázok z nášho vm:

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

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

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

Našiel som aj na internete zaujímavá správa a je toho viac taký otvorený projekt, ale existuje iba úložisko pre qcow2.

Ale ako všetci vieme, skôr či neskôr príde čas, keď budete chcieť prírastkové zálohy, tu je to ťažšie a možno vám manažment vyčlení peniaze na platené riešenie, alebo pôjde inou cestou a pochopí, že tu iba škrtíme zdroje, a zálohovanie na úrovni aplikácie a pridávanie množstva nových uzlov a virtuálnych strojov – áno, tu hovorím, že používanie cloudu len na spustenie klastrov aplikácií a spustenie databázy na inej platforme alebo prevzatie už hotovej od dodávateľa, ak je to možné.

4. Jednoduché použitie

V tomto odseku popíšem problémy, s ktorými som sa stretol. Napríklad podľa obrázkov, ako vieme, existuje perzistentný - keď je tento obrázok pripojený k vm, všetky údaje sa zapíšu do tohto obrázka. A ak nie je trvalý, potom sa obrázok skopíruje do úložiska a údaje sa zapíšu do toho, čo bolo skopírované zo zdrojového obrázka – takto fungujú šablóny šablón. Opakovane som si spôsobil problémy tým, že som zabudol špecifikovať persistent a 200 GB obraz bol skopírovaný, problém je v tom, že tento postup určite nemožno zrušiť, musíte ísť do uzla a zabiť aktuálny proces „cp“.

Jednou z dôležitých nevýhod je, že nemôžete zrušiť akcie jednoducho pomocou gui. Alebo ich radšej zrušíš a uvidíš, že sa nič nedeje a znova ich spustíš, zrušíš a vlastne už budú 2 cp procesy, ktoré kopírujú obrázok.

A potom príde k pochopeniu, prečo opennebula čísluje každú novú inštanciu novým id, napríklad v tom istom proxmoxe vytvoril vm s id 101, vymazal ho, potom ho vytvoril znova a id 101. V opennebule sa to nestane, každá nová inštancia sa vytvorí s novým id a to má svoju logiku - napríklad vymazanie starých dát alebo neúspešné inštalácie.

To isté platí pre úložisko, táto platforma je predovšetkým zameraná na centralizované úložisko. Existujú doplnky na používanie miestnych, ale o tom v tomto prípade nehovoríme. Myslím, že v budúcnosti niekto napíše článok o tom, ako sa im podarilo využiť lokálne úložisko na uzloch a úspešne ho použiť vo výrobe.

5. Maximálna jednoduchosť

Samozrejme, čím ďalej, tým menej bude tých, ktorí vám budú rozumieť.

V podmienkach môjho stojana - 3 uzly s úložiskom nfs - všetko funguje dobre. Ak však vykonávame experimenty zahŕňajúce výpadok napájania, napríklad pri spustení snímky a vypnutí napájania uzla, uložíme do databázy nastavenia, že snímka existuje, ale v skutočnosti tam žiadna neexistuje (dobre, všetci chápeme, že pôvodne zapísal databázu o tejto akcii v sql, ale samotná operácia nebola úspešná). Výhodou je, že pri vytváraní snímky sa vytvorí samostatný súbor a je tam „rodič“, takže v prípade problémov a aj keď to nefunguje cez gui, môžeme súbor qcow2 vyzdvihnúť a obnoviť samostatne docs.opennebula.io/5.8/operation/vm_management/vm_instances.html

V sieťach, bohužiaľ, nie je všetko také jednoduché. No aspon je to jednoduchsie ako v openstacku, pouzival som len vlan (802.1Q) - ide to celkom dobre, ale ak spravis zmeny v nastaveniach zo site šablón, tak sa tieto nastavenia nepoužijú na už spustené stroje, t.j. musíte odstrániť a pridať sieťovú kartu, potom sa použijú nové nastavenia.

Ak to stále chcete porovnať s openstackom, môžete povedať toto: v opennebule nie je jasná definícia, ktoré technológie použiť na ukladanie údajov, správu siete, zdrojov - každý správca sa sám rozhodne, čo je pre neho výhodnejšie.

6. Ďalšie pluginy a inštalácie

Koniec koncov, ako to chápeme, cloudová platforma dokáže spravovať nielen kvm, ale aj vmware esxi. Bohužiaľ som nemal bazén s Vcenter, ak to niekto skúšal, napíšte.

Uvádza sa podpora pre iných poskytovateľov cloudu docs.opennebula.io/5.12/advanced_components/cloud_bursting/index.html
AWS, AZURE.

Skúšal som pripojiť aj Vmware Cloud od Selectel, ale nič nefungovalo - vo všeobecnosti to bolo zablokované, pretože existuje veľa faktorov a nemá zmysel písať technickej podpore poskytovateľa hostingu.

Teraz má nová verzia aj petardu – toto je spustenie microvm, typu kvm postroja cez docker, ktorý poskytuje ešte väčšiu všestrannosť, bezpečnosť a zvýšenú produktivitu, pretože nie je potrebné plytvať zdrojmi na emuláciu zariadenia. Jedinú výhodu oproti Dockeru vidím v tom, že nezaberá ďalšie množstvo procesov a pri použití tejto emulácie nie sú obsadené sockety, t.j. Je celkom možné ho použiť ako vyrovnávač zaťaženia (ale pravdepodobne stojí za to napísať o tom samostatný článok, kým úplne nespustím všetky testy).

7. Pozitívne skúsenosti s používaním a ladením chýb

Chcel som sa podeliť o svoje postrehy k práci, niektoré som opísal vyššie, rád by som napísal viac. Naozaj, asi nie som jediný, kto si najprv myslí, že toto nie je správny systém a vo všeobecnosti je tu všetko barličkou – ako s tým vôbec pracujú? Ale potom príde pochopenie, že všetko je celkom logické. Samozrejme, nemôžete vyhovieť všetkým a niektoré aspekty si vyžadujú zlepšenie.

Napríklad jednoduchá operácia skopírovania obrazu disku z jedného dátového úložiska do druhého. V mojom prípade sú 2 uzly s nfs, posielam obrázok - kopírovanie prebieha cez frontend opennebula, aj keď sme všetci zvyknutí, že údaje by sa mali kopírovať priamo medzi hostiteľmi - v rovnakom vmware, hyper-v sme zvyknutý na toto, ale tu na iné. Existuje iný prístup a iná ideológia a vo verzii 5.12 odstránili tlačidlo „migrovať do úložiska údajov“ - prenáša sa iba samotný stroj, ale nie úložisko, pretože znamená centralizované úložisko.

Ďalej je populárna chyba s rôznymi dôvodmi: „Chyba pri nasadzovaní virtuálneho počítača: Nepodarilo sa vytvoriť doménu z /var/lib/one//datastores/103/10/deployment.5“ Nižšie je najdôležitejšia vec, na ktorú sa treba pozrieť.

  • Práva na obrázky pre používateľa oneadmin;
  • Povolenia pre používateľa oneadmin spustiť libvirtd;
  • Je dátové úložisko správne namontované? Choďte a skontrolujte cestu na samotnom uzle, možno niečo spadlo;
  • Nesprávne nakonfigurovaná sieť, respektíve na frontende je v nastaveniach siete, že hlavné rozhranie pre vlan je br0, ale na uzle je napísané ako bridge0 - musí to byť rovnaké.

systémový dátový sklad ukladá metaúdaje pre váš vm, ak spustíte vm s trvalým obrazom, potom vm musí mať prístup k pôvodne vytvorenej konfigurácii v úložisku, kde ste vytvorili vm – to je veľmi dôležité. Preto pri prenose vm do iného úložiska údajov musíte všetko skontrolovať.

8. Dokumentácia, komunita. Ďalší vývoj

A zvyšok, dobrá dokumentácia, komunita a hlavná vec je, že projekt žije aj v budúcnosti.

Vo všeobecnosti je všetko celkom dobre zdokumentované a aj s použitím oficiálneho zdroja nebude problém nainštalovať a nájsť odpovede na otázky.

Spoločenstvo, aktívne. Zverejňuje mnoho hotových riešení, ktoré môžete použiť vo svojich inštaláciách.

Momentálne sa v spoločnosti zmenili niektoré politiky od 5.12 forum.opennebula.io/t/towards-a-stronger-opennebula-community/8506/14 Bude zaujímavé sledovať, ako sa projekt vyvinie. Na začiatku som konkrétne poukázal na niektorých predajcov, ktorí využívajú ich riešenia a čo dané odvetvie ponúka. Samozrejme, neexistuje jednoznačná odpoveď na to, čo použiť. Pre menšie organizácie však údržba ich malého súkromného cloudu nemusí byť taká drahá, ako sa zdá. Hlavná vec je presne vedieť, čo potrebujete.

Výsledkom je, že bez ohľadu na to, čo si vyberiete ako cloudový systém, nemali by ste sa zastaviť pri jednom produkte. Ak máte čas, oplatí sa pozrieť aj na iné otvorenejšie riešenia.

Je tu dobrý chat t.me/opennebula Aktívne pomáhajú a neposielajú vás hľadať riešenie problému na Google. Pripoj sa k nám.

Zdroj: hab.com

Pridať komentár