Opennebula. Lyhyet muistiinpanot

Opennebula. Lyhyet muistiinpanot

Hei kaikki. Tämä artikkeli on kirjoitettu niille, jotka ovat edelleen kipeänä virtualisointialustojen valinnan välillä ja luettuamme artikkelin sarjasta "Asensimme proxmoxin ja yleensä kaikki on kunnossa, 6 vuotta käyttöaikaa ilman yhtäkään taukoa." Mutta yhden tai toisen käyttövalmis ratkaisun asennuksen jälkeen herää kysymys: miten voin korjata tämän, jotta valvonta olisi ymmärrettävämpää, ja tässä varmuuskopioiden hallinta.... Ja sitten tulee aika ja ymmärrät, että haluat jotain toimivampaa tai haluat kaiken järjestelmän sisällä olevan selvä, etkä tätä mustaa laatikkoa, tai haluat käyttää jotain muuta kuin hypervisoria ja joukko virtuaalikoneita. Tämä artikkeli sisältää ajatuksia ja käytäntöjä Opennebula-alustalla - valitsin sen siksi. se ei vaadi resursseja eikä arkkitehtuuri ole niin monimutkainen.

Ja kuten näemme, monet pilvipalveluntarjoajat työskentelevät kvm:llä ja muodostavat ulkoisia yhteyksiä koneiden ohjaamiseksi. On selvää, että suuret isännöitsijät kirjoittavat omat puitteet pilviinfrastruktuurille, esimerkiksi sama YANDEX. Joku käyttää openstackia ja muodostaa yhteyden tällä perusteella - SELECTEL, MAIL.RU. Mutta jos sinulla on oma laitteistosi ja pieni asiantuntijoiden henkilökunta, valitset yleensä jotain valmiita - VMWARE, HYPER-V, on ilmaisia ​​ja maksullisia lisenssejä, mutta siitä emme nyt puhu. Puhutaanpa harrastajista - nämä ovat niitä, jotka eivät pelkää tarjota ja kokeilla jotain uutta huolimatta siitä, että yritys teki selkeästi selväksi: "Kuka tämän jälkeen huoltaa", "Otetaanko tämä myöhemmin tuotantoon" ? Pelottava." Mutta voit ensin soveltaa näitä ratkaisuja testipenkissä, ja jos kaikki pitävät niistä, voit nostaa kysymyksen jatkokehityksestä ja käytöstä vakavammissa ympäristöissä.

Tässä myös linkki raporttiin www.youtube.com/watch?v=47Mht_uoX3A aktiiviselta osallistujalta tämän alustan kehittämiseen.

Ehkä tässä artikkelissa jotain on tarpeetonta ja jo ymmärrettävää kokeneelle asiantuntijalle, ja joissain tapauksissa en kuvaa kaikkea, koska samanlaisia ​​​​komentoja ja kuvauksia on saatavilla Internetissä. Tämä on vain minun kokemukseni tästä alustasta. Toivon, että aktiiviset osallistujat lisäävät kommentteihin, mitä voisi tehdä paremmin ja mitä virheitä tein. Kaikki toiminnot tapahtuivat kotiosastolla, joka koostui kolmesta eri ominaisuuksista omaavasta PC:stä. En myöskään maininnut erityisesti, kuinka tämä ohjelmisto toimii ja kuinka se asennetaan. Ei, vain hallintokokemus ja kohtaamani ongelmat. Ehkä tästä on hyötyä jollekin valinnassaan.

Joten aloitetaan. Järjestelmänvalvojana seuraavat asiat ovat minulle tärkeitä, ilman niitä en todennäköisesti käytä tätä ratkaisua.

1. Asennuksen toistettavuus

Opennebulan asennukseen on paljon ohjeita, ei pitäisi olla ongelmia. Versiosta toiseen ilmestyy uusia ominaisuuksia, jotka eivät aina toimi siirryttäessä versiosta toiseen.

2. Valvonta

Tarkkailemme itse solmua, kvm:ää ja opennebulaa. Onneksi se on jo valmis. Linux-isäntien, saman Zabbixin tai solmuviennin tarkkailuun on monia vaihtoehtoja - kumpi pitää mistä paremmasta - tällä hetkellä määrittelen sen järjestelmän mittareiksi (lämpötila missä se voidaan mitata, levyryhmän johdonmukaisuus) zabbixin kautta. , ja Prometheus-viejän kautta tehtyihin sovelluksiin. Esimerkiksi kvm-valvontaan voit ottaa projektin github.com/zhangjianweibj/prometheus-libvirt-exporter.git ja aseta se toimimaan systemd:n ​​kautta, se toimii melko hyvin ja näyttää kvm-mittaukset, siellä on myös valmis kojelauta grafana.com/grafana/dashboards/12538.

Tässä on esimerkiksi tiedostoni:

/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

Ja niin meillä on yksi viejä, tarvitsemme toisen valvomaan itse opennebulaa, käytin tätä github.com/kvaps/opennebula-exporter/blob/master/opennebula_exporter

Voidaan lisätä normaaliin node_exporter seurataksesi järjestelmää seuraavasti.

Node_exporter-tiedostossa muutamme alkua seuraavasti:

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

Luo hakemisto mkdir -p /var/lib/opennebula_exporter

yllä esitetty bash-skripti, tarkistamme ensin työn konsolin kautta, jos se näyttää tarvitsemamme (jos se antaa virheen, asenna xmlstarlet), kopioi se hakemistoon /usr/local/bin/opennebula_exporter.sh

Lisää cron-tehtävä joka minuutille:

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

Mittarit alkoivat ilmestyä, voit ottaa niitä kuin prometheusta ja rakentaa kaavioita ja tehdä hälytyksiä. Grafanassa voit piirtää esimerkiksi tällaisen yksinkertaisen kojelaudan.

Opennebula. Lyhyet muistiinpanot

(on selvää, että tässä ylisitoudun prosessoriin, ramiin)

Niille, jotka rakastavat ja käyttävät Zabbixia, on github.com/OpenNebula/addon-zabbix

Mitä tulee seurantaan, pääasia, että se on olemassa. Tietysti voit lisäksi käyttää sisäänrakennettuja virtuaalikoneen seurantatyökaluja ja ladata dataa laskutukseen, täällä jokaisella on oma näkemyksensä, en ole vielä alkanut perehtyä asiaan tarkemmin.

En ole vielä aloittanut kirjaamista. Yksinkertaisin vaihtoehto on lisätä td-agent jäsentämään /var/lib/one-hakemisto säännöllisillä lausekkeilla. Esimerkiksi sunstone.log-tiedosto vastaa nginx regexp-tiedostoa ja muita tiedostoja, jotka näyttävät alustan käyttöhistorian - mitä hyötyä tästä on? No, esimerkiksi voimme nimenomaisesti seurata "Virhe, virhe" määrää ja seurata nopeasti, missä ja millä tasolla vika on.

3. Varmuuskopiot

Myös maksettuja valmiita projekteja - esim. syys wiki.sepsoftware.com/wiki/index.php/4_4_3_Tigon:OpenNebula_Varmuuskopio. Tässä meidän on ymmärrettävä, että pelkkä konekuvan varmuuskopiointi ei ole ollenkaan sama asia tässä tapauksessa, koska virtuaalikoneiden on toimittava täydellä integraatiolla (sama kontekstitiedosto, joka kuvaa verkkoasetukset, virtuaalikoneen nimen ja mukautetut asetukset sovelluksille) . Siksi tässä päätämme, mitä ja miten varmuuskopioimme. Joissakin tapauksissa on parempi tehdä kopioita siitä, mikä on itse vm:ssä. Ja ehkä sinun tarvitsee vain varmuuskopioida yksi levy tietystä koneesta.

Esimerkiksi päätimme, että kaikki koneet alkavat pysyvillä kuvilla, siis lukemisen jälkeen docs.opennebula.io/5.12/operation/vm_management/img_guide.html

Tämä tarkoittaa, että voimme ensin ladata kuvan vm:stämme:

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

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

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

Löysin myös Internetistä mielenkiintoinen raportti ja on enemmänkin niin avoin projekti, mutta tallennustilaa on vain qcow2:lle.

Mutta kuten me kaikki tiedämme, ennemmin tai myöhemmin tulee aika, jolloin halutaan lisävarmuuskopioita, täällä on vaikeampaa ja ehkä johto jakaa rahaa maksulliseen ratkaisuun tai menee toisin ja ymmärtää, että täällä vain leikataan resursseja, ja varmuuskopioiden tekeminen sovellustasolla ja joukko uusien solmujen ja virtuaalikoneiden lisääminen - kyllä, tässä sanon, että pilven käyttäminen pelkästään sovellusklustereiden käynnistämiseen ja tietokannan käynnistäminen toisella alustalla tai valmiin ottaminen toimittajalta, jos mahdollista.

4. Helppokäyttöisyys

Tässä kappaleessa kuvailen kohtaamiani ongelmia. Esimerkiksi kuvien mukaan, kuten tiedämme, on pysyvä - kun tämä kuva liitetään virtuaalikoneeseen, kaikki tiedot kirjoitetaan tähän kuvaan. Ja jos ei-pysyvä, kuva kopioidaan tallennustilaan ja tiedot kirjoitetaan siihen, mikä kopioitiin lähdekuvasta - näin mallipohjat toimivat. Olen toistuvasti aiheuttanut itselleni ongelmia unohtamalla määrittää pysyvän ja 200 Gt:n kuva kopioitiin, ongelmana on, että tätä toimenpidettä ei todellakaan voi peruuttaa, sinun on mentävä solmuun ja lopetettava nykyinen "cp"-prosessi.

Yksi tärkeimmistä haitoista on, että et voi peruuttaa toimintoja yksinkertaisesti käyttämällä gui. Tai pikemminkin peruutat ne ja huomaat, että mitään ei tapahdu, ja käynnistät ne uudelleen, peruutat ne ja itse asiassa on jo 2 cp-prosessia, jotka kopioivat kuvan.

Ja sitten tulee ymmärtämään, miksi opennebula numeroi jokaisen uuden ilmentymän uudella tunnuksella, esimerkiksi samassa proxmoxissa loi vm:n tunnuksella 101, poisti sen, sitten luot sen uudelleen ja tunnuksella 101. Opennebulassa näin ei tapahdu, jokainen uusi ilmentymä luodaan uudella tunnuksella ja tällä on oma logiikkansa - esimerkiksi vanhojen tietojen tyhjennys tai epäonnistuneet asennukset.

Sama koskee tallennustilaa; ennen kaikkea tämä alusta on tarkoitettu keskitettyyn tallennustilaan. Paikallisen käytön käyttöön on lisäosia, mutta siitä emme puhu tässä tapauksessa. Luulen, että tulevaisuudessa joku kirjoittaa artikkelin siitä, kuinka he onnistuivat käyttämään paikallista tallennustilaa solmuissa ja käyttämään sitä menestyksekkäästi tuotannossa.

5. Maksimaalinen yksinkertaisuus

Tietysti mitä pidemmälle menet, sitä harvemmaksi tulee niitä, jotka ymmärtävät sinua.

Osaston olosuhteissa - 3 solmua nfs-tallennustilalla - kaikki toimii hyvin. Mutta jos teemme kokeita, joihin liittyy sähkökatkos, esimerkiksi kun suoritamme tilannekuvan ja sammutamme solmun virran, tallennamme tietokantaan asetukset, että tilannekuva on olemassa, mutta todellisuudessa sitä ei ole (no, me kaikki ymmärrämme, että alun perin kirjoitti tietokantaan tästä toiminnosta sql -muodossa, mutta itse toiminto ei onnistunut). Etuna on, että tilannekuvaa luotaessa muodostuu erillinen tiedosto ja siellä on "emo", joten ongelmatilanteissa ja vaikka se ei toimisi gui:n kautta, voimme poimia qcow2-tiedoston ja palauttaa sen erikseen docs.opennebula.io/5.8/operation/vm_management/vm_instances.html

Valitettavasti verkoissa kaikki ei ole niin yksinkertaista. No, se on ainakin helpompaa kuin openstackissä, käytin vain vlan:ia (802.1Q) - se toimii melko hyvin, mutta jos teet muutoksia asetuksiin malliverkosta, niin nämä asetukset eivät koske jo käynnissä oleviin koneisiin, ts. sinun on poistettava ja lisättävä verkkokortti, niin uudet asetukset otetaan käyttöön.

Jos haluat myös verrata sitä openstackiin, niin voit sanoa näin: opennebulassa ei ole selkeää määritelmää sille, mitä teknologioita käytetään tietojen tallentamiseen, verkon, resurssien hallintaan - jokainen ylläpitäjä päättää itse, mikä on hänelle kätevämpää.

6. Lisälaajennukset ja -asennukset

Loppujen lopuksi, kuten ymmärrämme, pilvialusta voi hallita paitsi kvm:ää myös vmware esxiä. Valitettavasti minulla ei ollut uima-allasta Vcenterin kanssa, jos joku on kokeillut, kirjoita.

Muiden pilvipalveluntarjoajien tuki on ilmoitettu docs.opennebula.io/5.12/advanced_components/cloud_bursting/index.html
AWS, AZURE.

Yritin myös yhdistää Vmware Cloudiin Selectelistä, mutta mikään ei toiminut - yleensä se estettiin, koska on monia tekijöitä, eikä ole mitään järkeä kirjoittaa isännöintipalveluntarjoajan tekniselle tuelle.

Lisäksi nyt uudessa versiossa on sähinkäisy - tämä on microvm, eräänlainen kvm-valjaat telakan päällä, lanseeraus, joka antaa entistä enemmän monipuolisuutta, turvallisuutta ja lisää tuottavuutta, koska resursseja ei tarvitse tuhlata emulointilaitteisiin. Ainoa etu, jonka näen Dockeriin nähden, on se, että se ei vie ylimääräistä määrää prosesseja ja ei ole varattuja pistorasioita käytettäessä tätä emulointia, ts. On täysin mahdollista käyttää sitä kuormituksen tasapainottajana (mutta tästä on luultavasti syytä kirjoittaa erillinen artikkeli, kunnes olen suorittanut kaikki testit kokonaan).

7. Positiivinen käyttökokemus ja virheenkorjaus

Halusin jakaa havaintojani työstä, kuvailin niistä joitain yllä, haluaisin kirjoittaa lisää. Todellakin, en ole luultavasti ainoa, joka aluksi ajattelee, että tämä ei ole oikea järjestelmä ja yleensä kaikki täällä on kainalosauva - kuinka he edes toimivat tämän kanssa? Mutta sitten tulee ymmärrys, että kaikki on varsin loogista. Kaikkia ei tietenkään voi miellyttää, ja jotkut näkökohdat vaativat parantamista.

Esimerkiksi yksinkertainen toimenpide, jolla kopioidaan levykuva tietovarastosta toiseen. Minun tapauksessani on 2 solmua, joissa on nfs, lähetän kuvan - kopiointi tapahtuu etupään avoimen nebulan kautta, vaikka olemme kaikki tottuneet siihen, että tiedot pitäisi kopioida suoraan isäntien välillä - samassa vmwaressa, hyper-v tähän tottunut, mutta täällä toiseen. On erilainen lähestymistapa ja erilainen ideologia, ja versiossa 5.12 poistettiin "migrate to datastore" -painike - vain kone itse siirretään, mutta ei tallennustilaa, koska tarkoittaa keskitettyä varastointia.

Seuraava on suosittu virhe useista syistä: "Virhe otettaessa käyttöön virtuaalikoneen: Ei voitu luoda verkkotunnusta osoitteesta /var/lib/one//datastores/103/10/deployment.5" Alla on tärkein asia, jota kannattaa tarkastella.

  • Kuvaoikeudet oneadmin-käyttäjälle;
  • Oneadmin-käyttäjän oikeudet suorittaa libvirtd;
  • Onko tietovarasto asennettu oikein? Mene ja tarkista itse solmun polku, ehkä jotain on pudonnut;
  • Väärin määritetty verkko, tai pikemminkin käyttöliittymässä verkkoasetuksissa vlanin pääliitäntä on br0, mutta solmussa se on kirjoitettu silta0 - sen on oltava sama.

System Datastore tallentaa virtuaalikoneen metatiedot. Jos käytät virtuaalikonetta pysyvällä näköistiedostolla, virtuaalikoneella on oltava pääsy alun perin luotuihin määrityksiin siinä tallennustilassa, jossa loit virtuaalikoneen - tämä on erittäin tärkeää. Siksi, kun siirrät vm:n toiseen tietosäilöön, sinun on tarkistettava kaikki.

8. Dokumentaatio, yhteisö. Edelleen kehittäminen

Ja loput, hyvä dokumentaatio, yhteisöllisyys ja pääasia, että projekti elää myös tulevaisuudessa.

Yleisesti ottaen kaikki on melko hyvin dokumentoitua, ja edes virallista lähdettä käytettäessä ei ole ongelma asentaa ja löytää vastauksia kysymyksiin.

Yhteisöllinen, aktiivinen. Julkaisee monia valmiita ratkaisuja, joita voit käyttää asennuksissasi.

Tällä hetkellä yhtiössä osa politiikoista on muuttunut 5.12 forum.opennebula.io/t/towards-a-stronger-opennebula-community/8506/14 Mielenkiintoista nähdä miten hanke kehittyy. Alussa korostin erityisesti joitain toimittajia, jotka käyttävät heidän ratkaisujaan ja mitä toimiala tarjoaa. Tietenkään ei ole selvää vastausta siihen, mitä käyttää. Mutta pienemmille organisaatioille pienen yksityisen pilven ylläpito ei välttämättä ole niin kallista kuin miltä näyttää. Tärkeintä on tietää tarkalleen mitä tarvitset.

Tämän seurauksena, riippumatta siitä, minkä valitset pilvijärjestelmäksi, sinun ei pitäisi pysähtyä yhteen tuotteeseen. Jos sinulla on aikaa, kannattaa katsoa muita avoimempia ratkaisuja.

Siellä on hyvä keskustelu t.me/opennebula He auttavat aktiivisesti eivätkä lähetä sinua etsimään ratkaisua ongelmaan Googlesta. Liity meihin.

Lähde: will.com

Lisää kommentti