Ahoj všichni. Tento článek je napsán pro ty, kteří stále váhají mezi výběrem virtuizačních platforem a po přečtení článku ze série „Nainstalovali jsme proxmox a všechno funguje skvěle, 6 let uptime bez jediného výpadku“. Po instalaci některého z hotových řešení se však objevuje otázka, jak to tu ještě upravit a tady, aby byl monitoring srozumitelnější a tady, jak kontrolovat zálohy… A pak přijde čas a vy si uvědomíte, že chcete něco funkčnějšího, nebo chcete, aby všechno uvnitř vašeho systému bylo jasné, a ne ten černý box, nebo chcete používat něco víc než hypervisor a hromadu virtuálních strojů. V tomto článku se budou některé úvahy a praxe na základě platformy Opennebula — vybral jsem ji, protože není náročná na zdroje a architektura není tak složitá.
Tak jak vidíme, mnoho cloudových poskytovatelů pracuje na KVM a vytváří vnější rozhraní pro správu strojů. Je jasné, že velcí poskytovatelé hostingu vyvíjejí svá vlastní rozhraní pro cloudovou infrastrukturu, například YANDEX. Někdo používá OpenStack a dělá rozhraní na jeho základě — SELECTEL, MAIL.RU. Ale pokud máte vlastní hardware a malý tým specialistů, obvykle volí něco z hotových řešení — VMWARE, HYPER-V, jsou dostupné bezplatné i placené licence, ale o tom teď nemluvíme. Pojďme si promluvit o nadšencích — to jsou ti, kdo se nebojí nabídnout a vyzkoušet něco nového, i když ve firmě jasně dali najevo „Kdo to pak bude udržovat po tobě?“, „A my to snad nasadíme do produkce? To je děsivé.“ Ale přitom by se tato řešení mohla nejprve použít v testovací prostředí a pokud se to všem zalíbí, můžeme otevřít otázku dalšího vývoje a použití v serióznějších prostředích.
Zde je také odkaz na prezentaci od aktivního účastníka vývoje této platformy.
Možná v tomto článku bude něco nadbytného a pro zkušeného odborníka už jasné, a v některých případech nebudu popisovat vše, protože podobné příkazy a popisy jsou dostupné online. Tady je jen moje zkušenost s touto platformou. Doufám, že aktivní účastníci doplní v komentářích, co by se dalo udělat lépe a jaké chyby jsem udělal. Všechny akce probíhaly v domácím prostředí složeném ze 3 PC s různými specifikacemi. Také jsem záměrně neuvedl, jak tento software funguje a jak se instaluje. Ne, jen zkušenost s administrací a problémy, se kterými jsem se setkal. Možná to někomu pomůže při výběru.
A tak, pojďme na to. Jako systémovému administrátorovi mi záleží na následujících bodech, bez kterých pravděpodobně nebudu toto řešení používat.
1. Opakovanost instalace
Existuje spousta návodů na instalaci opennebula, takže by neměly vzniknout žádné problémy. S každou verzí se objevují nové funkce, které nemusí vždy fungovat při přechodu z verze na verzi.
2. Monitoring
Budeme monitorovat samotnou uzel, kvm a opennebula. Naštěstí už existují hotové řešení. Pro monitoring linuxových hostitelů je mnoho možností, například Zabbix nebo node exporter — co komu více vyhovuje — v současnosti určuji tak, že monitorování systémových metrik (teplota tam, kde lze měřit, konzistence diskového pole) probíhá přes Zabbix, zatímco to, co se týká aplikací, přes exportér v Prometheu. Pro monitoring kvm můžete například použít projekt a spustit ho přes systemd, funguje docela dobře a ukazuje metriky kvm, také existuje hotový dashboard .
Například, tady je 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.targetA tak máme 1 exportér, potřebujeme druhý pro monitoring samotné opennebula, použil jsem tento
Můžete přidat do běžného pro monitoring systému následující.
V souboru pro node_exporter měníme start tímto způsobem:
ExecStart=/usr/sbin/node_exporter --web.listen-address=":9102" --collector.textfile.directory=/var/lib/opennebula_exporter/textfile_collectorVytvoříme adresář mkdir -p /var/lib/opennebula_exporter
bash skript uvedený výše nejprve ověříme v konzoli, pokud ukazuje to, co má (pokud se objeví chyba, nainstalujeme xmlstarlet), zkopírujeme ho do /usr/local/bin/opennebula_exporter.sh
Přidáme úlohu do cronu na každou minutu:
* /1 * * * * (/usr/local/bin/opennebula_exporter.sh > /var/lib/opennebula_exporter/textfile_collector/opennebula.prom)Metriky začaly přicházet, můžete je sbírat pomocí Promethea, vytvářet grafy a nastavovat upozornění. V Grafaně můžete například nakreslit takový jednoduchý dashboard.
(vidíte, že jsem zde udělal overcommit cpu, ram)
Pro ty, kteří mají rádi a používají Zabbix, je k dispozici
Co se týče monitorování, to je vše, hlavní je, že existuje. Samozřejmě je možné používat vestavěné prostředky pro monitorování virtuálních strojů a exportovat data do billing systému, každý má svou vizi, zatím jsem se tomuto zatím podrobněji nevěnoval.
K logování jsem se zatím také nijak zvlášť nedostal. Nejjednodušší možností je přidat td-agent pro parsování adresáře /var/lib/one pomocí regulárních výrazů. Například soubor sunstone.log vyhovuje regexp nginx a dalším souborům, které zobrazují historii kontaktů s platformou — jaký je v tom přínos? Například můžeme jasně sledovat počet 'Error, error' a rychleji zjistit, kde a na jaké úrovni je problém.
3. Zálohy
Existují také placené vylepšené projekty — například sep. :OpenNebula_Backup. Zde musíme pochopit, že prostě zálohovat obraz stroje, v tomto případě vůbec není totéž, neboť naše virtuální stroje musí fungovat s plnou integrací (ten samý kontext, soubor, ve kterém jsou popsána nastavení sítě, jméno vm a vlastní nastavení pro vaše aplikace). Proto definujeme, co a jak budeme zálohovat. V některých případech je lepší dělat kopie toho, co se nachází v samotné vm. A možná bychom měli zálohovat pouze jeden disk od tohoto stroje.
Například jsme se rozhodli, že všechny stroje se spouští s persistentními obrazy, tudíž po přečtení
můžeme nejprve z našeho vm exportovat obraz:
onevm disk-saveas 74 3 prom.qcow2
Image ID: 77
Pod jakým jménem byl uložen
oneimage show 77
/var/lib/one//datastores/100/f9503161fe180658125a9b32433bf6e8
A poté zkopírujeme, kam potřebujeme. Samozřejmě, není to nejlepší způsob. Chtěl jsem to jen ukázat, že pomocí nástrojů opennebula lze vytvářet podobná řešení.Také jsem v prostorách sítě našel a existuje také , ale ten je pouze pro storages qcow2.
Jak všichni víme, dříve nebo později nastane chvíle, kdy si přejeme provádět inkrementální zálohy. Zde to je složitější, a možná vedení uvolní peníze na placené řešení, nebo se vydáme jinou cestou a pochopíme, že zde čerpáme pouze zdroje, zatímco zálohování provádíme na úrovni aplikací, přidáváme počet nových uzlů a virtuálních strojů. Ano, zde mluvím o tom, že bychom měli používat cloud výhradně pro spouštění klastrů aplikací, zatímco databáze spouštíme na jiné platformě nebo používáme hotové řešení od poskytovatele, pokud je to možné.
4. Uživatelský komfort
V této části popíšu problémy, se kterými jsem se setkal. Například, pokud jde o obrazy, jak víme, existují persistentní obrazy – při připojení tohoto obrazu k VM se všechna data zapisují do tohoto obrazu. A pokud je non-persistent, pak se obraz zkopíruje do úložiště a data se zapisují do toho, co bylo zkopírováno z původního obrazu – takto fungují šablony. Často jsem si sám způsobil komplikace tím, že jsem zapomněl označit persistent a 200 GB obraz se zkopíroval. Problém je v tom, že tuto proceduru nelze zrušit, musíte jít na uzel a ukončit aktuální proces „cp“.
Jednou z významných nevýhod je, že akce nelze zrušit jednoduše pomocí GUI. Přesněji, zrušíte je, a uvidíte, že se nic neděje, a znovu je spustíte, zrušíte je a ve skutečnosti už budou dva procesy cp, které kopírují obraz.
A zde přichází pochopení, proč opennebula každou novou instanci číslu novým ID. Například v proxmoxu jsem vytvořil VM s ID 101, smazal ji a poté ji znovu vytvořil s ID 101. V opennebula to tak nebude; každá nová instance bude vytvořena s novým ID, a v tom je určitá logika – například čistění starých dat nebo neúspěšných instalací.
Totéž platí pro úložiště, tato platforma je zejména zaměřena na centralizované úložiště. Existují doplňky pro použití lokálního, ale zde se o to nejedná. Myslím, že v budoucnu někdo napíše článek o tom, jak se povedlo využít lokální úložiště na uzlech a úspěšně jej použít v produkci.
5. Maximální jednoduchost
Samozřejmě, čím dál jdete, tím méně lidí vás bude rozumět.
V podmínkách mého stánku — 3 uzly s NFS úložištěm — všechno funguje v pořádku. Ale pokud provádíme experimenty s odpojením energie, například při spuštění snapshotu a odpojení napájení uzlu, uchováváme nastavení v DB, že existuje snapshot, ale fakticky není (všichni víme, že jsme původně zapsali do SQL databáze o této akci, ale sama operace proběhla neúspěšně). Plusem je, že při vytváření snímku se vytvoří samostatný soubor a existuje "rodič", proto v případě problémů, a i když přes GUI nefunguje, můžeme vzít qcow2 soubor a obnovit se samostatně.
Ohledně sítí, bohužel, to není tak jednoduché. No, alespoň je to jednodušší než v OpenStacku, použil jsem pouze VLAN (802.1Q) — funguje to docela dobře, ale pokud provedete změny v nastavení šablony sítě, tato nastavení se neaplikují na již běžící stroje, tedy je potřeba síťovou kartu odstranit a znovu přidat, pak se nová nastavení aplikují.
Pokud chcete ještě porovnat s OpenStackem, můžeme říct, že v OpenNebule není jasné určení, jaké technologie použít pro ukládání dat, správu sítí a zdrojů — každý administrátor si rozhoduje sám, jak mu to vyhovuje.
6. Další pluginy a instalace
Jelikož chápeme, že cloudová platforma může spravovat nejen KVM, ale i VMware ESXi. Bohužel jsem neměl pool s VCenter, pokud to někdo zkusil, napište mi.
V podpoře dalších cloudových poskytovatelů bylo uvedeno
AWS, AZURE.
Také jsem se pokusil připojit VMware Cloud od Selectelu, ale nic nevyšlo — prostě jsem to vzdal, protože je mnoho faktorů a psát na technickou podporu hostingového poskytovatele nemá smysl.
Také, nyní v nové verzi je zde Firecracker — to je spuštění microVM, něco jako KVM obal nad Dockerem, což přináší ještě více univerzálnosti, bezpečnosti a zvýšení výkonu, protože není potřeba vyčleňovat zdroje na emulaci hardwaru. Vidím pouze výhodu ve srovnání s Dockerem v tom, že nezabírá dodatečné procesy a nezabírá žádné zásuvky při použití této emulace, tudíž to lze použít jako vyvažovač zátěže (ale o tom asi stojí za to napsat samostatný článek, zatím jsem neprovedl všechny testy v plné míře).
7. Pozitivní zkušenost s použitím a debugování chyb
Chtěl jsem se podělit o své postřehy ohledně fungování, část jsem popsal výše, rád bych napsal více. Opravu, pravděpodobně nejsem sám, kdo si nejprve myslí, že tohle není ten správný systém a že je to vůbec všechno horkou jehlou — jak s tím vlastně fungují? Ale pak přichází pochopení a věci dávají smysl. Samozřejmě, že nelze vyhovět všem a některé aspekty vyžadují vylepšení.
Například jednoduchá operace kopírování diskového obrazu z jednoho datastore na druhé. V mém případě jsou 2 uzly s NFS, posílám obraz — kopírování probíhá přes frontend OpenNebula, i když jsme všichni zvyklí, že data by měla být kopírována přímo mezi hostiteli — ve VMware, Hyper-V jsme na to zvyklí, ale zde je to jinak. Je to jiný přístup a jiná ideologie, a ve verzi 5.12 byla odstraněna tlačítko „migrate to datastore“ — přesouvá se pouze samotný stroj, ale ne úložiště, protože se předpokládá centralizované úložiště.
A pak populární chyba s různými příčinami „Error deploying virtual machine: Could not create domain from /var/lib/one//datastores/103/10/deployment.5“ Níže bude seznam, co je třeba zkontrolovat.
- Práva na obraz pro uživatele oneadmin;
- Práva pro uživatele oneadmin pro spuštění libvirtd;
- Je datastore správně připojen? Jdi a zkontroluj cestu na samotném uzlu, možná něco selhalo;
- Nesprávně nakonfigurovaná síť, spíše na frontendu v síťových nastaveních, že jako hlavní rozhraní pro VLAN je br0, zatímco na uzlu je uvedeno — bridge0 — musí být stejné.
system datastore uchovává metadat pro vaši VM, pokud spouštíte VM s persistentním obrazem, musí mít VM přístup k původně vytvořené konfiguraci na tom úložišti, kde jste VM vytvářeli — to je velmi důležité. Proto musíte při přesunu VM na jiné datastore všechno pečlivě zkontrolovat.
8. Dokumentace, komunita. Další vývoj
A k tomu, dobrá dokumentace, komunita a hlavně, aby projekt měl i nadále budoucnost.
Celkově je zde všechno docela dobře zdokumentováno a podle oficiálních zdrojů nebude problém nainstalovat a najít odpovědi na otázky.
Komunita je aktivní. Publikuje mnoho hotových řešení, která můžete použít ve svých instalacích.
V současnosti se s verzí 5.12 změnily některé politiky ve společnosti Bude zajímavé vidět, jak se projekt bude vyvíjet. Na začátku jsem záměrně uvedl některé dodavatele, kteří používají vlastní řešení a to, co nabízí odvětví. Samozřejmě neexistuje jasná odpověď na to, co byste měli použít. Ale pro malé organizace může podpora vlastního malého soukromého cloudu vyjít levněji, než se zdá. Hlavní je přesně vědět, co potřebujete.
Nakonec, bez ohledu na to, co jste si vybrali jako cloudový systém, není dobré zastavit se pouze u jednoho produktu. Pokud máte čas, stojí za to podívat se na jiná otevřenější řešení.
Je zde dobrý chat. aktivně pomáhají a neposílají vás hledat řešení problémů na Googlu. Připojte se.
Zdroj: habr.com
