Otevřená mlhovina. Krátké poznámky

Otevřená mlhovina. Krátké poznámky

Ahoj všichni. Tento článek byl napsán pro ty, kteří se stále táhnou mezi výběrem virtualizačních platforem a po přečtení článku ze série „Nainstalovali jsme proxmox a obecně je vše v pořádku, 6 let provozu bez jediné přestávky.“ Ale po instalaci toho či onoho out-of-the-box řešení vyvstává otázka: jak to mohu opravit zde, aby bylo monitorování srozumitelnější, a zde pro kontrolu záloh…. A pak přijde čas a vy si uvědomíte, že chcete něco funkčnějšího, nebo chcete, aby se všechno uvnitř vašeho systému vyjasnilo, a ne tahle černá skříňka, nebo chcete použít něco víc než hypervizor a hromadu virtuálních strojů. Tento článek bude obsahovat některé myšlenky a praktiky založené na platformě Opennebula – vybral jsem si ho proto. není náročný na zdroje a architektura není tak složitá.

A tak, jak vidíme, mnoho poskytovatelů cloudu pracuje na kvm a provádí externí připojení k řídicím strojům. Je jasné, že velcí hostitelé píší své vlastní frameworky pro cloudovou infrastrukturu, stejný YANDEX například. Někdo používá openstack a na tomto základě udělá spojení - SELECTEL, MAIL.RU. Pokud ale máte vlastní hardware a malý tým specialistů, pak si většinou vyberete něco hotového – VMWARE, HYPER-V, existují bezplatné i placené licence, ale o tom se teď nebavíme. Pojďme se bavit o nadšencích – to jsou ti, kteří se nebojí nabídnout a vyzkoušet něco nového, přestože společnost jasně dala najevo: „Kdo to bude po vás obsluhovat“, „Zavedeme to do výroby později ? Děsivé." Tato řešení ale můžete nejprve aplikovat ve zkušební stolici, a pokud se to všem bude líbit, pak můžete nastolit otázku dalšího vývoje a použití ve vážnějších prostředích.

Zde je také odkaz na zprávu www.youtube.com/watch?v=47Mht_uoX3A od aktivního účastníka vývoje této platformy.

Možná v tomto článku bude něco zbytečné a pro zkušeného specialistu již srozumitelné a v některých případech nebudu popisovat vše, protože podobné příkazy a popisy jsou k dispozici na internetu. To je jen moje zkušenost s touto platformou. Doufám, že aktivní účastníci doplní do komentářů, co by se dalo udělat lépe a jaké chyby jsem udělal já. Všechny akce probíhaly v domácím stánku složeném ze 3 PC s různými vlastnostmi. Také jsem konkrétně neuvedl, jak tento software funguje a jak jej nainstalovat. Ne, pouze zkušenosti s administrací a problémy, se kterými jsem se setkal. Možná to bude pro někoho užitečné při jeho výběru.

Takže, pojďme začít. Jako správce systému jsou pro mě důležité následující body, bez kterých toto řešení pravděpodobně nevyužiji.

1. Opakovatelnost instalace

Návodů na instalaci opennebula je spousta, neměly by být žádné problémy. Od verze k verzi se objevují nové funkce, které při přechodu z verze na verzi nebudou vždy fungovat.

2. Sledování

Budeme sledovat samotný uzel, kvm a opennebulu. Naštěstí je již připraven. Existuje spousta možností, jak monitorovat hostitele Linuxu, stejný Zabbix nebo exportér uzlů - kdo má rád co lepší - v tuto chvíli to definuji jako sledování systémových metrik (teplota, kde lze měřit, konzistence diskového pole), přes zabbix , a pokud jde o aplikace prostřednictvím exportéra Prometheus. Například pro sledování kvm můžete vzít projekt github.com/zhangjianweibj/prometheus-libvirt-exporter.git a nastavit, aby to běželo přes systemd, funguje to docela dobře a ukazuje metriky kvm, je tam i hotový dashboard grafana.com/grafana/dashboards/12538.

Zde je například můj soubor:

/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, potřebujeme druhého na sledování samotné opennebuly, použil jsem toto github.com/kvaps/opennebula-exporter/blob/master/opennebula_exporter

Lze přidat k normálu node_exporter pro sledování systému následující.

V souboru node_exporter změníme začátek takto:

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

Vytvořte adresář mkdir -p /var/lib/opennebula_exporter

bash skript uvedený výše, nejprve zkontrolujeme práci přes konzolu, pokud ukazuje, co potřebujeme (pokud dává chybu, pak nainstalujte xmlstarlet), zkopírujte jej do /usr/local/bin/opennebula_exporter.sh

Přidejte úlohu cron pro každou minutu:

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

Začaly se objevovat metriky, můžete je brát jako prometheus a sestavovat grafy a dělat upozornění. V Grafaně si můžete nakreslit třeba takový jednoduchý dashboard.

Otevřená mlhovina. Krátké poznámky

(je jasné, že zde přetěžuji cpu, ram)

Pro ty, kteří milují a používají Zabbix, existuje github.com/OpenNebula/addon-zabbix

Co se monitoringu týče, tak hlavní je, že tam je. Samozřejmě můžete navíc využít vestavěné nástroje pro monitorování virtuálních strojů a nahrávat data do fakturace, zde má každý svou vizi, blíže jsem se tomu zatím věnovat nezačal.

S logováním jsem ještě pořádně nezačal. Nejjednodušší možností je přidat td-agent pro analýzu adresáře /var/lib/one s regulárními výrazy. Například soubor sunstone.log odpovídá regulárnímu výrazu nginx a dalším souborům, které ukazují historii přístupu k platformě – jaká je to výhoda? No, můžeme například explicitně sledovat počet „Chyba, chyba“ a rychle sledovat, kde a na jaké úrovni je porucha.

3. Zálohy

Existují i ​​placené dokončené projekty - např. sep wiki.sepsoftware.com/wiki/index.php/4_4_3_Tigon:OpenNebula_Backup. Zde musíme pochopit, že pouhé zálohování obrazu stroje není v tomto případě vůbec totéž, protože naše virtuální stroje musí pracovat s plnou integrací (stejný kontextový soubor, který popisuje nastavení sítě, název vm a vlastní nastavení pro vaše aplikace) . Proto zde rozhodujeme, co a jak budeme zálohovat. V některých případech je lepší vytvořit kopie toho, co je v samotném vm. A třeba stačí zálohovat jeden disk z daného stroje.

Zjistili jsme například, že všechny počítače po přečtení začínají s trvalými obrazy docs.opennebula.io/5.12/operation/vm_management/img_guide.html

To znamená, že nejprve můžeme nahrát obrázek z našeho vm:

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

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

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

Našla jsem i na internetu zajímavá reportáž a je toho víc takový otevřený projekt, ale existuje pouze úložiště pro qcow2.

Ale jak všichni víme, dříve nebo později přijde čas, kdy chcete inkrementální zálohy, tady je to složitější a možná vedení vyčlení peníze na placené řešení, nebo půjde opačně a pochopí, že zde pouze omezujeme zdroje, a vytváření záloh na úrovni aplikace a přidávání řady nových uzlů a virtuálních strojů - ano, tady říkám, že použití cloudu čistě pro spouštění clusterů aplikací a spuštění databáze na jiné platformě nebo převzetí hotové pokud možno od dodavatele.

4. Snadné použití

V tomto odstavci popíšu problémy, se kterými jsem se setkal. Například podle obrázků, jak víme, existuje perzistentní - když je tento obraz připojen k vm, všechna data se zapisují do tohoto obrazu. A pokud neperzistentní, pak se obrázek zkopíruje do úložiště a data se zapíší do toho, co bylo zkopírováno ze zdrojového obrázku – takto fungují šablony šablon. Opakovaně jsem si způsobil problémy tím, že jsem zapomněl zadat persistent a 200 GB image se zkopíroval, problém je v tom, že tento postup určitě nelze zrušit, musíte jít do uzlu a zabít aktuální proces „cp“.

Jednou z důležitých nevýhod je, že nemůžete zrušit akce jednoduše pomocí gui. Nebo spíš je zrušíš a uvidíš, že se nic neděje a spustíš je znovu, zrušíš a vlastně už budou 2 cp procesy, které kopírují obrázek.

A pak dojde k pochopení, proč opennebula čísluje každou novou instanci novým id, například ve stejném proxmoxu vytvořil vm s id 101, smazal ho, pak ho vytvořil znovu a id 101. V opennebule se to nestane, každá nová instance bude vytvořena s novým id a to má svou logiku - například vymazání starých dat nebo neúspěšné instalace.

Totéž platí pro úložiště především, tato platforma je zaměřena na centralizované úložiště. Existují doplňky pro použití local, ale o tom v tomto případě nemluvíme. Myslím, že v budoucnu někdo napíše článek o tom, jak se jim podařilo využít lokální úložiště na uzlech a úspěšně ho využít v produkci.

5. Maximální jednoduchost

Samozřejmě, čím dále půjdete, tím méně bude těch, kteří vám budou rozumět.

Za podmínek mého stojanu - 3 uzly s úložištěm nfs - vše funguje dobře. Ale pokud provádíme experimenty zahrnující výpadek napájení, například při spuštění snímku a vypnutí napájení uzlu, uložíme do databáze nastavení, že snímek existuje, ale ve skutečnosti tam žádný není (no, všichni chápeme, že zpočátku zapsal databázi o této akci v sql , ale samotná operace nebyla úspěšná). Výhodou je, že při vytváření snapshotu se vytvoří samostatný soubor a je tam „rodič“, takže v případě problémů a i když to nefunguje přes gui, můžeme soubor qcow2 vyzvednout a obnovit samostatně docs.opennebula.io/5.8/operation/vm_management/vm_instances.html

Na sítích bohužel není vše tak jednoduché. No aspoň je to jednodušší než v openstacku, použil jsem pouze vlan (802.1Q) - funguje to celkem dobře, ale pokud provedete změny v nastavení ze sítě šablon, tak se tato nastavení nepoužijí na již běžící stroje, tzn. musíte odstranit a přidat síťovou kartu, pak se použijí nové nastavení.

Pokud to stále chcete srovnávat s openstackem, můžete říci toto: v opennebula není jasná definice, jaké technologie použít pro ukládání dat, správu sítě, zdrojů - každý správce se sám rozhodne, co je pro něj výhodnější.

6. Další pluginy a instalace

Ostatně, jak tomu rozumíme, cloudová platforma umí spravovat nejen kvm, ale i vmware esxi. Bohužel jsem neměl bazén s Vcenterem, pokud někdo zkusil, napište.

Je uvedena podpora pro další poskytovatele cloudu docs.opennebula.io/5.12/advanced_components/cloud_bursting/index.html
AWS, AZUROVÁ.

Zkoušel jsem také připojit Vmware Cloud od Selectel, ale nic nefungovalo - obecně to bylo zablokováno, protože existuje mnoho faktorů a nemá smysl psát technické podpoře poskytovatele hostingu.

Nová verze má nyní také petardu – to je spuštění microvm, typu kvm harness over docker, který poskytuje ještě větší všestrannost, bezpečnost a zvýšenou produktivitu, protože není potřeba plýtvat prostředky na emulaci zařízení. Jedinou výhodu oproti Dockeru vidím v tom, že nezabírá další množství procesů a nejsou obsazené sockety při použití této emulace, tzn. Je docela možné jej použít jako load balancer (ale pravděpodobně stojí za to napsat o tom samostatný článek, dokud plně neprovedu všechny testy).

7. Pozitivní zkušenosti s používáním a laděním chyb

Chtěl jsem se podělit o své postřehy k práci, některé jsem popsal výše, rád bych napsal více. Pravděpodobně nejsem sám, kdo si zprvu myslí, že to není správný systém a obecně je tady všechno berlička – jak s tím vůbec pracují? Ale pak přijde pochopení, že vše je docela logické. Samozřejmě se nemůžete zavděčit všem a některé aspekty vyžadují zlepšení.

Například jednoduchá operace zkopírování obrazu disku z jednoho datového úložiště do druhého. V mém případě jsou 2 uzly s nfs, posílám obrázek - kopírování probíhá přes frontend opennebula, i když jsme všichni zvyklí na to, že data by se měla kopírovat přímo mezi hostiteli - ve stejném vmware, hyper-v jsme zvyklí na tohle, ale tady na jiné. Existuje jiný přístup a jiná ideologie a ve verzi 5.12 odstranili tlačítko „migrovat do úložiště dat“ - přenese se pouze samotný stroj, ale ne úložiště, protože znamená centralizované úložiště.

Další je oblíbená chyba s různými důvody: „Chyba při nasazování virtuálního počítače: Nelze vytvořit doménu z /var/lib/one//datastores/103/10/deployment.5“ Níže je hlavní věc, na kterou je třeba se podívat.

  • Práva k obrázku pro uživatele oneadmin;
  • Oprávnění pro uživatele oneadmin ke spuštění libvirtd;
  • Je datové úložiště správně připojeno? Jděte a zkontrolujte cestu na samotném uzlu, možná něco spadlo;
  • Špatně nakonfigurovaná síť, respektive na frontendu je v nastavení sítě hlavní rozhraní pro vlan br0, ale na nodu je to napsané jako bridge0 - musí to být stejné.

systémové datové úložiště ukládá metadata pro váš virtuální stroj, pokud spustíte virtuální stroj s trvalým obrazem, pak musí mít virtuální stroj přístup k původně vytvořené konfiguraci na úložišti, kde jste vytvořili virtuální stroj – to je velmi důležité. Proto při přenosu vm do jiného datového úložiště musíte vše znovu zkontrolovat.

8. Dokumentace, komunita. Další vývoj

A zbytek, dobrá dokumentace, komunita a hlavní věc je, že projekt žije i v budoucnu.

Obecně je vše celkem dobře zdokumentováno a ani s použitím oficiálního zdroje nebude problém nainstalovat a najít odpovědi na otázky.

Komunita, aktivní. Publikuje mnoho hotových řešení, která můžete použít ve svých instalacích.

V současné době se od 5.12. ve společnosti změnily některé zásady forum.opennebula.io/t/towards-a-stronger-opennebula-community/8506/14 Bude zajímavé sledovat, jak se projekt vyvine. Na začátku jsem konkrétně poukázal na některé dodavatele, kteří jejich řešení využívají a co obor nabízí. Jasná odpověď na to, co použít, samozřejmě neexistuje. Pro menší organizace však údržba jejich malého privátního cloudu nemusí být tak nákladná, jak se zdá. Hlavní věc je přesně vědět, co potřebujete.

Výsledkem je, že bez ohledu na to, co si zvolíte jako cloudový systém, byste se neměli zastavit u jednoho produktu. Pokud máte čas, stojí za to podívat se na další otevřenější řešení.

Je tam dobrý chat t.me/opennebula Aktivně pomáhají a neposílají vás hledat řešení problému na Google. Připoj se k nám.

Zdroj: www.habr.com