Sziasztok. Ez a cikk azoknak íródott, akik még mindig tépelődnek a virtualizációs platformok választása között, és miután elolvasták a „Proxmoxot telepítettük és általában minden rendben van, 6 év üzemidő egyetlen megszakítás nélkül” sorozat cikkét. Ám az egyik-másik gyári megoldás telepítése után felvetődik a kérdés: hogyan tudnám ezt itt kijavítani, hogy érthetőbb legyen a felügyelet, itt pedig a mentések ellenőrzése…. Aztán eljön az idő, és rájössz, hogy valami funkcionálisabbat akarsz, vagy azt akarod, hogy a rendszeredben minden világos legyen, és ne ez a fekete doboz, vagy valami többet akarsz használni, mint egy hipervizort és egy csomó virtuális gépet. Ez a cikk az Opennebula platformon alapuló gondolatokat és gyakorlatokat tartalmaz – azért választottam. nem igényel erőforrásokat, és az architektúra sem olyan bonyolult.
És így, mint látjuk, sok felhőszolgáltató dolgozik a kvm-en, és külső kapcsolatokat hoz létre a gépek vezérléséhez. Nyilvánvaló, hogy a nagy szolgáltatók saját keretrendszert írnak a felhő infrastruktúrához, például ugyanazt a YANDEX-et. Valaki openstacket használ, és ezen az alapon hoz létre kapcsolatot - SELECTEL, MAIL.RU. De ha van saját hardvere és egy kis szakembergárdája, akkor általában valami kész terméket választ - VMWARE, HYPER-V, vannak ingyenes és fizetős licencek, de most nem erről beszélünk. Beszéljünk a rajongókról – ők azok, akik nem félnek valami újat kínálni és kipróbálni, annak ellenére, hogy a cég egyértelműen leszögezte: „Ki fogja ezt utánad kiszolgálni”, „Később bevezetjük a gyártásba” ? Ijedős." De ezeket a megoldásokat először próbapadon lehet alkalmazni, és ha mindenkinek tetszik, akkor felvetheti a továbbfejlesztés és a komolyabb környezetekben való felhasználás kérdése.
Itt van egy link is a jelentéshez a platform fejlesztésének aktív résztvevőjétől.
Talán ebben a cikkben valami felesleges és már érthető lesz egy tapasztalt szakember számára, és bizonyos esetekben nem írok le mindent, mert hasonló parancsok és leírások érhetők el az interneten. Ez csak az én tapasztalatom ezzel a platformmal. Remélem, hogy az aktív résztvevők kommentben megírják, mit lehetne jobban csinálni, és milyen hibákat követtem el. Minden művelet egy otthoni standon zajlott, amely 3 különböző jellemzőkkel rendelkező PC-ből állt. Ezenkívül konkrétan nem jeleztem, hogyan működik ez a szoftver és hogyan kell telepíteni. Nem, csak az adminisztrációs tapasztalat és az általam tapasztalt problémák. Talán ez hasznos lesz valakinek a választás során.
Tehát kezdjük. Rendszergazdaként számomra fontosak az alábbi pontok, amelyek nélkül nem valószínű, hogy ezt a megoldást használnám.
1. A telepítés megismételhetősége
Az opennebula telepítéséhez rengeteg instrukció van, nem lehet gond. Verzióról verzióra új funkciók jelennek meg, amelyek nem mindig működnek, amikor verzióról verzióra váltunk.
2. Monitoring
Figyelni fogjuk magát a csomópontot, a kvm-t és a nyílt ködöt. Szerencsére már készen van. Rengeteg lehetőség van Linux hosztok, ugyanaz a Zabbix vagy csomópont exportőr figyelésére - kinek mi tetszik jobban - jelenleg a rendszer metrikáját figyelem (hőmérséklet ahol mérhető, a lemeztömb konzisztenciája), zabbixon keresztül , valamint a Prometheus exportőrön keresztüli alkalmazásokhoz. A kvm-felügyelethez például átveheti a projektet és beállítom, hogy a systemd-n keresztül fusson, elég jól működik és kvm mérőszámokat mutat, van kész műszerfal is .
Például itt van a fájlom:
/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És így van 1 exportőrünk, kell egy másik, hogy magát az opennebulát figyeljük, én ezt használtam
Hozzáadható a normálhoz a rendszer figyeléséhez a következőket.
A node_exporter fájlban a kezdést így módosítjuk:
ExecStart=/usr/sbin/node_exporter --web.listen-address=":9102" --collector.textfile.directory=/var/lib/opennebula_exporter/textfile_collectorHozzon létre egy mkdir -p /var/lib/opennebula_exporter könyvtárat
A fent bemutatott bash script, először a konzolon keresztül ellenőrizzük a munkát, ha azt mutatja, amire szükségünk van (ha hibát ad, akkor telepítse az xmlstarlet-et), másolja be a /usr/local/bin/opennebula_exporter.sh mappába
Adjon hozzá egy cron feladatot minden perchez:
*/1 * * * * (/usr/local/bin/opennebula_exporter.sh > /var/lib/opennebula_exporter/textfile_collector/opennebula.prom)Elkezdtek megjelenni a mérőszámok, úgy veheted őket, mint egy prométheuszt, grafikonokat készíthetsz, és figyelmeztethetsz. A Grafanában például egy ilyen egyszerű műszerfalat rajzolhat.
(egyértelmű, hogy itt túlvállalom a cpu-t, ramot)
Azok számára, akik szeretik és használják a Zabbixot, van
Ami a monitoringot illeti, az a lényeg, hogy ott van. Természetesen ezen kívül használhatod a beépített virtuális gép felügyeleti eszközöket és adatokat tölthetsz fel a számlázásba, itt mindenkinek megvan a maga elképzelése, ezzel még nem kezdtem el közelebbről foglalkozni.
Még nem igazán kezdtem el a naplózást. A legegyszerűbb lehetőség a td-agent hozzáadása a /var/lib/one könyvtár reguláris kifejezésekkel történő elemzéséhez. Például a sunstone.log fájl megegyezik az nginx regexp és más fájlokkal, amelyek a platformhoz való hozzáférés előzményeit mutatják – mi ennek az előnye? Nos, például kifejezetten nyomon tudjuk követni a „Hiba, hiba” számát, és gyorsan nyomon követhetjük, hol és milyen szinten van hiba.
3. Biztonsági mentések
Vannak fizetett befejezett projektek is - például szept :OpenNebula_Backup. Itt meg kell értenünk, hogy a gépkép egyszerű biztonsági mentése ebben az esetben egyáltalán nem ugyanaz, mert a virtuális gépeinknek teljes integrációval kell működniük (ugyanaz a kontextusfájl, amely leírja a hálózati beállításokat, a virtuális gép nevét és az alkalmazások egyéni beállításait) . Ezért itt mi döntjük el, hogy mit és hogyan fogunk biztonsági másolatot készíteni. Bizonyos esetekben jobb másolatot készíteni arról, ami magában a VM-ben van. És talán csak egy lemezre kell biztonsági másolatot készítenie egy adott gépről.
Például megállapítottuk, hogy minden gép állandó képekkel indul, tehát az olvasás után
Ez azt jelenti, hogy először feltölthetjük a képet a virtuális gépünkről:
onevm disk-saveas 74 3 prom.qcow2
Image ID: 77
Смотрим, под каким именем он сохранился
oneimage show 77
/var/lib/one//datastores/100/f9503161fe180658125a9b32433bf6e8
И далее копируем куда нам необходимо. Конечно, так себе способ. Просто хотел показать, что используя инструменты opennebula можно строить подобные решения.Az interneten is találtam és van még , de csak a qcow2 számára van tárhely.
De mint azt mindannyian tudjuk, előbb-utóbb eljön az idő, amikor növekményes biztonsági mentéseket akarsz, itt nehezebb, és talán a menedzsment pénzt szán egy fizetős megoldásra, vagy más irányba megy, és megérti, hogy itt csak az erőforrásokat csökkentjük. és biztonsági mentések készítése az alkalmazás szintjén, valamint számos új csomópont és virtuális gép hozzáadása – igen, itt azt mondom, hogy a felhőt pusztán alkalmazásfürtök indítására használjuk, és az adatbázist egy másik platformon indítjuk el, vagy egy készet. lehetőség szerint a szállítótól.
4. Könnyű használat
Ebben a bekezdésben leírom azokat a problémákat, amelyekkel találkoztam. Például a képek szerint, mint tudjuk, van perzisztens – ha ez a kép egy virtuális gépre van csatolva, akkor minden adat ebbe a képfájlba kerül. Ha pedig nem perzisztens, akkor a kép a tárolóra másolódik, az adatok pedig a forrásképből másoltakba íródnak - így működnek a sablonsablonok. Többször okoztam magamnak problémát azzal, hogy elfelejtettem megadni a persistent-et, és a 200 GB-os kép másolásra került, a probléma az, hogy ezt az eljárást biztosan nem lehet törölni, el kell menni a csomóponthoz és meg kell állítani az aktuális „cp” folyamatot.
Az egyik fontos hátrány, hogy a műveleteket nem lehet egyszerűen a gui használatával törölni. Illetve törli őket és látja, hogy nem történik semmi és újraindítja őket, törli őket és tulajdonképpen már lesz 2 cp process, ami másolja a képet.
És akkor meg kell érteni, hogy az opennebula miért számoz minden új példányt új azonosítóval, például ugyanabban a proxmoxban létrehozott egy virtuális gépet 101-es azonosítóval, törölte, majd újra létrehozza és 101-es azonosítóval. Opennebulában ez nem fog megtörténni, minden új példány új azonosítóval jön létre, és ennek megvan a maga logikája – például a régi adatok törlése vagy a sikertelen telepítések.
Ugyanez vonatkozik a tárolásra is; ez a platform elsősorban a központosított tárolásra irányul. Vannak kiegészítők a helyi használatához, de ebben az esetben nem erről beszélünk. Azt hiszem, a jövőben valaki ír majd egy cikket arról, hogyan sikerült a helyi tárhelyet a csomópontokon használni, és sikeresen használni a termelésben.
5. Maximális egyszerűség
Természetesen minél tovább mész, annál kevesebb lesz az, aki megért téged.
A standom körülményei között - 3 csomópont nfs tárolóval - minden jól működik. De ha áramszünettel járó kísérleteket végzünk, például pillanatfelvétel futtatásakor és a csomópont áramellátásának kikapcsolásakor, akkor az adatbázisba mentjük a beállításokat, hogy van pillanatkép, de valójában nincs (jó, mindannyian megértjük, hogy Erről a műveletről először sql-ben írta az adatbázist, de maga a művelet nem volt sikeres). Előnye, hogy a pillanatkép készítésekor külön fájl jön létre és van egy „szülő”, ezért probléma esetén, és ha nem is működik gui-n keresztül, felvehetjük a qcow2 fájlt és külön visszaállíthatjuk.
A hálózatokon sajnos nem minden olyan egyszerű. Na, legalább egyszerűbb, mint openstackben, én csak vlan-t (802.1Q) használtam - elég jól működik, de ha a sablonhálózatból változtatsz a beállításokon, akkor ezek a beállítások nem vonatkoznak a már futó gépekre, pl. törölnie kell és hozzá kell adnia egy hálózati kártyát, akkor az új beállítások érvényesülnek.
Ha mégis össze akarja hasonlítani az openstackkel, akkor ezt mondhatja: az opennebulában nincs egyértelmű meghatározás, hogy mely technológiákat kell használni az adatok tárolására, a hálózat, az erőforrások kezelésére - minden rendszergazda maga dönti el, mi a kényelmesebb számára.
6. További bővítmények és telepítések
Hiszen a felhőplatform, ahogy megértjük, nem csak a kvm-t, hanem a vmware esxi-t is képes kezelni. Sajnos a Vcenterrel nem volt medencém, ha valaki próbálta, kérem írjon.
Más felhőszolgáltatók támogatása szerepel
AWS, AZURE.
Megpróbáltam a Vmware Cloud-ot a Selectelről is csatlakoztatni, de semmi sem működött - általában le van tiltva, mert sok tényező van, és nincs értelme a tárhelyszolgáltató technikai támogatásának írni.
Ezenkívül most az új verzióban petárda is található – ez a microvm bevezetése, egyfajta kvm kábelköteg a docker felett, amely még több sokoldalúságot, biztonságot és nagyobb termelékenységet biztosít, mivel nem kell erőforrásokat pazarolni emuláló berendezésekre. Az egyetlen előnyt, amit a Dockerrel szemben látok, az az, hogy nem vesz fel több folyamatot, és nincsenek foglalt socketek ennek az emulációnak a használatakor, pl. Teljesen lehetséges terheléselosztóként használni (de valószínűleg érdemes erről külön cikket írni, amíg az összes tesztet teljesen le nem futtatom).
7. Pozitív tapasztalatok a használatról és a hibakeresésről
A munkával kapcsolatos észrevételeimet szerettem volna megosztani, néhányat fentebb leírtam, szeretnék még írni. Valószínűleg nem én vagyok az egyetlen, aki először azt gondolja, hogy ez nem a megfelelő rendszer, és általában itt minden egy mankó - hogyan működnek ezzel? De aztán jön a megértés, hogy minden egészen logikus. Természetesen nem lehet mindenkinek a kedvében járni, és bizonyos szempontok javításra szorulnak.
Például egy egyszerű művelet egy lemezkép másolása egyik adattárból a másikba. Az én esetemben 2 csomópont van nfs-el, küldöm a képet - a másolás a frontend opennebulán keresztül történik, bár mindannyian megszoktuk, hogy az adatokat közvetlenül kell másolni a gépek között - ugyanabban a vmware-ben, hyper-v-ben vagyunk ehhez szokott, de itt máshoz. Más a megközelítés és más az ideológia, és az 5.12-es verzióban eltávolították a „migrate to datastore” gombot - csak maga a gép kerül átvitelre, de a tárhely nem, mert központosított tárolást jelent.
A következő egy népszerű hiba, amelynek többféle oka lehet: „Hiba a virtuális gép üzembe helyezésekor: Nem sikerült létrehozni a tartományt a /var/lib/one//datastores/103/10/deployment.5 fájlból.
- Képjogok a oneadmin felhasználó számára;
- Engedélyek a oneadmin felhasználó számára a libvirtd futtatásához;
- Az adattár megfelelően van felszerelve? Menjen, és ellenőrizze az útvonalat magán a csomóponton, talán valami leesett;
- Rosszul konfigurált hálózat, vagy inkább a frontenden a hálózati beállításokban a vlan fő interfésze a br0, de a csomóponton bridge0-nek van írva - ennek ugyanannak kell lennie.
A rendszeradattár a virtuális géped metaadatait tárolja, ha a virtuális gépet állandó lemezképpel futtatod, akkor a virtuális gépnek hozzá kell férnie az eredetileg létrehozott konfigurációhoz azon a tárolón, ahol a virtuális gépet létrehozta - ez nagyon fontos. Ezért, amikor egy virtuális gépet egy másik adattárba visz át, mindent újra kell ellenőriznie.
8. Dokumentáció, közösség. További fejlődés
És a többi, jó dokumentáció, közösség és a lényeg, hogy a projekt a jövőben is éljen.
Általánosságban elmondható, hogy minden meglehetősen jól dokumentált, és még hivatalos forrás felhasználásával sem lesz probléma a telepítés és a kérdések megválaszolása.
Közösségi, aktív. Számos kész megoldást tesz közzé, amelyeket a telepítései során használhat.
Jelenleg a vállalat egyes irányelvei megváltoztak 5.12 óta Érdekes lesz látni, hogyan alakul a projekt. Az elején külön felhívtam a figyelmet a megoldásaikat használó szállítókra és arra, hogy mit kínál az iparág. Természetesen nincs egyértelmű válasz arra, hogy mit kell használni. De a kisebb szervezetek számára a kis privát felhő fenntartása nem feltétlenül olyan drága, mint amilyennek látszik. A lényeg az, hogy pontosan tudja, mire van szüksége.
Ennek eredményeként, függetlenül attól, hogy melyiket választja felhőrendszerként, nem szabad egy terméknél megállnia. Ha van időd, érdemes egy pillantást vetni más nyitottabb megoldásokra is.
Van egy jó csevegés Aktívan segítenek, és nem küldik el, hogy a Google-on keressen megoldást a problémára. Csatlakozz hozzánk.
Forrás: will.com