Opennebula. Shënime të shkurtra

Opennebula. Shënime të shkurtra

Pershendetje te gjitheve. Ky artikull u shkrua për ata që janë ende të shqetësuar midis zgjedhjes së platformave të virtualizimit dhe pasi lexuan artikullin nga seria "Ne instaluam proxmox dhe në përgjithësi gjithçka është në rregull, 6 vjet kohë pune pa asnjë ndërprerje të vetme." Por pas instalimit të një ose një tjetër zgjidhjeje jashtë kutisë, lind pyetja: si mund ta korrigjoj këtë këtu, në mënyrë që monitorimi të jetë më i kuptueshëm, dhe këtu, për të kontrolluar kopjet rezervë…. Dhe pastaj vjen koha dhe kupton që dëshiron diçka më funksionale, ose dëshiron që gjithçka brenda sistemit të bëhet e qartë, dhe jo kjo kuti e zezë, ose dëshiron të përdorësh diçka më shumë se një hipervizor dhe një tufë makinash virtuale. Ky artikull do të përmbajë disa mendime dhe praktikë të bazuar në platformën Opennebula - e zgjodha sepse. nuk kërkon burime dhe arkitektura nuk është aq komplekse.

Dhe kështu, siç e shohim, shumë ofrues të cloud punojnë në kvm dhe bëjnë lidhje të jashtme për kontrollin e makinave. Është e qartë se hostet e mëdhenj shkruajnë kornizat e tyre për infrastrukturën cloud, i njëjti YANDEX për shembull. Dikush përdor openstack dhe bën një lidhje mbi këtë bazë - SELECTEL, MAIL.RU. Por nëse keni pajisjen tuaj dhe një staf të vogël specialistësh, atëherë zakonisht zgjidhni diçka të gatshme - VMWARE, HYPER-V, ka licenca falas dhe me pagesë, por kjo nuk është ajo për të cilën po flasim tani. Le të flasim për entuziastët - këta janë ata që nuk kanë frikë të ofrojnë dhe provojnë diçka të re, pavarësisht nga fakti që kompania e bëri të qartë, "Kush do ta shërbejë këtë pas jush", "A do ta hedhim këtë në prodhim më vonë ? E frikshme." Por së pari mund t'i aplikoni këto zgjidhje në një stol testimi dhe nëse të gjithëve u pëlqen, atëherë mund të ngrini çështjen e zhvillimit dhe përdorimit të mëtejshëm në mjedise më serioze.

Këtu është gjithashtu një lidhje me raportin www.youtube.com/watch?v=47Mht_uoX3A nga një pjesëmarrës aktiv në zhvillimin e kësaj platforme.

Ndoshta në këtë artikull diçka do të jetë e tepërt dhe tashmë e kuptueshme për një specialist me përvojë, dhe në disa raste nuk do të përshkruaj gjithçka, sepse komanda dhe përshkrime të ngjashme janë të disponueshme në internet. Kjo është vetëm përvoja ime me këtë platformë. Shpresoj që pjesëmarrësit aktivë të shtojnë në komente se çfarë mund të bëhet më mirë dhe çfarë gabimesh kam bërë. Të gjitha veprimet u zhvilluan në një stendë të përbërë nga 3 PC me karakteristika të ndryshme. Gjithashtu, unë në mënyrë specifike nuk tregova se si funksionon ky softuer dhe si ta instaloni atë. Jo, vetëm përvoja e administratës dhe problemet që kam hasur. Ndoshta kjo do të jetë e dobishme për dikë në zgjedhjen e tyre.

Pra, le të fillojmë. Si administrator i sistemit, pikat e mëposhtme janë të rëndësishme për mua, pa të cilat nuk ka gjasa të përdor këtë zgjidhje.

1. Përsëritshmëria e instalimit

Ka shumë udhëzime për instalimin e opennebula, nuk duhet të ketë asnjë problem. Nga versioni në version, shfaqen veçori të reja që nuk do të funksionojnë gjithmonë kur lëvizni nga versioni në version.

2. Monitorimi

Ne do të monitorojmë vetë nyjen, kvm dhe opennebula. Për fat të mirë, tashmë është gati. Ka shumë opsione në lidhje me monitorimin e hosteve Linux, i njëjti Zabbix ose eksportues i nyjeve - kushdo që i pëlqen më mirë - për momentin unë e përkufizoj atë si metrikë të sistemit të monitorimit (temperatura ku mund të matet, konsistenca e grupit të diskut), përmes zabbix , dhe si për aplikimet përmes eksportuesit Prometheus. Për monitorimin e kvm, për shembull, mund të merrni projektin github.com/zhangjianweibj/prometheus-libvirt-exporter.git dhe e vendose te ekzekutohet nepermjet systemd, funksionon mjaft mire dhe tregon metrika kvm, ka edhe pultin e gatshem grafana.com/grafana/dashboards/12538.

Për shembull, këtu është skedari im:

/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

Dhe kështu ne kemi 1 eksportues, ne kemi nevojë për një të dytë për të monitoruar vetë opennebula, unë e përdora këtë github.com/kvaps/opennebula-exporter/blob/master/opennebula_exporter

Mund të shtohet në normale nyja_eksportues për të monitoruar sistemin si më poshtë.

Në skedarin node_exporter ne ndryshojmë fillimin si kjo:

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

Krijo një direktori mkdir -p /var/lib/opennebula_exporter

skripti bash i paraqitur me lart, fillimisht kontrollojme punen nepermjet tastieres, nese tregon cfare na duhet (nese jep gabim, atehere instalo xmlstarlet), kopjoje ne /usr/local/bin/opennebula_exporter.sh

Shto një detyrë cron për çdo minutë:

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

Metrikat filluan të shfaqen, mund t'i marrësh si një promete dhe të ndërtosh grafikë dhe të bësh alarme. Në Grafana mund të vizatoni, për shembull, një pult kaq të thjeshtë.

Opennebula. Shënime të shkurtra

(është e qartë se këtu unë e tejkaloj CPU, ram)

Për ata që e duan dhe përdorin Zabbix, ekziston github.com/OpenNebula/addon-zabbix

Për sa i përket monitorimit, kryesorja është se ai është aty. Natyrisht, përveç kësaj, mund të përdorni mjetet e integruara të monitorimit të makinës virtuale dhe të ngarkoni të dhëna në faturim, këtu të gjithë kanë vizionin e tyre, unë nuk kam filluar të punoj për këtë akoma më nga afër.

Unë ende nuk kam filluar të regjistrohem. Opsioni më i thjeshtë është të shtoni td-agent për të analizuar drejtorinë /var/lib/one me shprehje të rregullta. Për shembull, skedari sunstone.log përputhet me nginx regexp dhe skedarë të tjerë që tregojnë historinë e aksesit në platformë - cili është avantazhi i kësaj? Epo, për shembull, ne mund të gjurmojmë në mënyrë eksplicite numrin e "Gabim, gabim" dhe të gjurmojmë shpejt se ku dhe në çfarë niveli ka një mosfunksionim.

3. Rezervimet

Ka edhe projekte të përfunduara me pagesë - për shembull shtator wiki.sepsoftware.com/wiki/index.php/4_4_3_Tigon:OpenNebula_Backup. Këtu duhet të kuptojmë se thjesht kopjimi i një imazhi të makinës nuk është aspak i njëjtë në këtë rast, sepse makinat tona virtuale duhet të punojnë me integrim të plotë (i njëjti skedar konteksti që përshkruan cilësimet e rrjetit, emrin e vm dhe cilësimet e personalizuara për aplikacionet tuaja) . Prandaj, këtu vendosim se çfarë dhe si do të bëjmë kopje rezervë. Në disa raste është më mirë të bëni kopje të asaj që është në vetë vm. Dhe ndoshta ju duhet vetëm të kopjoni një disk nga një makinë e caktuar.

Për shembull, ne përcaktuam që të gjitha makinat fillojnë me imazhe të qëndrueshme, prandaj, pas leximit docs.opennebula.io/5.12/operation/vm_management/img_guide.html

Kjo do të thotë që së pari ne mund të ngarkojmë imazhin nga vm-ja jonë:

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

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

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

Kam gjetur edhe në internet raport interesant dhe ka më shumë një projekt kaq i hapur, por ka vetëm ruajtje për qcow2.

Por siç e dimë të gjithë, herët a vonë vjen një moment kur dëshironi rezerva shtesë, është më e vështirë këtu dhe ndoshta menaxhmenti do të ndajë para për një zgjidhje të paguar, ose do të shkojë në anën tjetër dhe do të kuptojë se këtu ne vetëm po shkurtojmë burimet, dhe duke bërë kopje rezervë në nivelin e aplikacionit dhe duke shtuar një numër nyjesh të reja dhe makina virtuale - po, këtu, po them se përdorimi i cloud thjesht për të nisur grupimet e aplikacioneve dhe nisja e bazës së të dhënave në një platformë tjetër ose marrja e një të gatshme nga furnizuesi, nëse është e mundur.

4. Lehtësia e përdorimit

Në këtë paragraf do të përshkruaj problemet që kam hasur. Për shembull, sipas imazheve, siç e dimë, ka të vazhdueshme - kur ky imazh është montuar në një vm, të gjitha të dhënat shkruhen në këtë imazh. Dhe nëse nuk është e vazhdueshme, atëherë imazhi kopjohet në ruajtje dhe të dhënat shkruhen në atë që është kopjuar nga imazhi burimor - kështu funksionojnë shabllonet e shablloneve. Unë vazhdimisht i shkaktova probleme vetes duke harruar të specifikoj këmbënguljen dhe imazhi 200 GB u kopjua, problemi është se kjo procedurë sigurisht që nuk mund të anulohet, duhet të shkoni te nyja dhe të vrisni procesin aktual "cp".

Një nga disavantazhet e rëndësishme është se nuk mund të anuloni veprime thjesht duke përdorur gui. Ose më mirë do t'i anuloni dhe do të shihni që asgjë nuk ndodh dhe do t'i rinisni, do t'i anuloni dhe në fakt do të ketë tashmë 2 procese cp që kopjojnë imazhin.

Dhe pastaj bëhet fjalë për të kuptuar pse opennebula numëron çdo instancë të re me një id të ri, për shembull, në të njëjtin proxmox krijoi një vm me id 101, e fshiu atë, pastaj e krijoni përsëri dhe id 101. Në opennebula kjo nuk do të ndodhë. çdo shembull i ri do të krijohet me një ID të re dhe kjo ka logjikën e vet - për shembull, pastrimi i të dhënave të vjetra ose instalimet e pasuksesshme.

E njëjta gjë vlen edhe për ruajtjen; ​​mbi të gjitha, kjo platformë synon ruajtjen e centralizuar. Ka shtesa për përdorimin lokal, por kjo nuk është ajo për të cilën po flasim në këtë rast. Unë mendoj se në të ardhmen dikush do të shkruajë një artikull se si ata arritën të përdorin ruajtjen lokale në nyje dhe ta përdorin me sukses atë në prodhim.

5. Thjeshtësia maksimale

Natyrisht, sa më shumë të shkoni, aq më pak bëhen ata që do t'ju kuptojnë.

Në kushtet e stendës sime - 3 nyje me ruajtje nfs - gjithçka funksionon mirë. Por nëse kryejmë eksperimente që përfshijnë një ndërprerje të energjisë, për shembull, kur ekzekutojmë një fotografi dhe fikim energjinë e nyjes, ruajmë cilësimet në bazën e të dhënave që ka një fotografi, por në fakt nuk ka asnjë (mirë, të gjithë e kuptojmë se ne fillimisht shkroi bazën e të dhënave për këtë veprim në sql, por vetë operacioni nuk ishte i suksesshëm). Avantazhi është se kur krijoni një fotografi, krijohet një skedar i veçantë dhe ekziston një "prind", prandaj në rast problemesh dhe edhe nëse nuk funksionon përmes gui, ne mund të marrim skedarin qcow2 dhe ta rivendosim atë veçmas. docs.opennebula.io/5.8/operation/vm_management/vm_instances.html

Në rrjete, për fat të keq, jo gjithçka është aq e thjeshtë. Epo, të paktën është më e lehtë se sa në openstack, unë përdora vetëm vlan (802.1Q) - funksionon mjaft mirë, por nëse bëni ndryshime në cilësimet nga rrjeti i shabllonit, atëherë këto cilësime nuk do të aplikohen në makinat tashmë që funksionojnë, d.m.th. duhet të fshini dhe shtoni një kartë rrjeti, më pas do të aplikohen cilësimet e reja.

Nëse ende dëshironi ta krahasoni atë me openstack, atëherë mund ta thoni këtë: në opennebula nuk ka një përcaktim të qartë se cilat teknologji të përdoren për ruajtjen e të dhënave, menaxhimin e rrjetit, burimet - secili administrator vendos vetë se çfarë është më e përshtatshme për të.

6. Shtojca dhe instalime shtesë

Në fund të fundit, siç e kuptojmë ne, platforma cloud mund të menaxhojë jo vetëm kvm, por edhe vmware esxi. Fatkeqësisht, nuk kam pasur një pishinë me Vcenter, nëse dikush e ka provuar, ju lutemi shkruani.

Është deklaruar mbështetja për ofruesit e tjerë të cloud docs.opennebula.io/5.12/advanced_components/cloud_bursting/index.html
AWS, AZURE.

Unë gjithashtu u përpoqa të lidh Vmware Cloud nga Selectel, por asgjë nuk funksionoi - në përgjithësi, ai u bllokua sepse ka shumë faktorë dhe nuk ka kuptim të shkruash për mbështetjen teknike të ofruesit të pritjes.

Gjithashtu, tani versioni i ri ka fishekzjarre - ky është lëshimi i microvm, një lloj parzmore kvm mbi doker, i cili jep edhe më shumë shkathtësi, siguri dhe produktivitet më të madh, sepse nuk ka nevojë të harxhoni burime për pajisjet imituese. Avantazhi i vetëm që shoh ndaj Docker është se ai nuk merr një numër shtesë procesesh dhe nuk ka priza të zëna kur përdoret ky emulim, d.m.th. Është mjaft e mundur ta përdorësh atë si një balancues të ngarkesës (por ndoshta ia vlen të shkruaj një artikull të veçantë për këtë derisa t'i kryej plotësisht të gjitha testet).

7. Përvoja pozitive e përdorimit dhe korrigjimi i gabimeve

Doja të ndaja vëzhgimet e mia për veprën, disa prej saj i përshkrova më lart, do të doja të shkruaja më shumë. Në të vërtetë, unë ndoshta nuk jam i vetmi që në fillim mendoj se ky nuk është sistemi i duhur dhe në përgjithësi gjithçka këtu është një paterica - si funksionojnë ata madje me këtë? Por më pas vjen mirëkuptimi se gjithçka është mjaft logjike. Sigurisht, nuk mund t'i kënaqësh të gjithë dhe disa aspekte kërkojnë përmirësim.

Për shembull, një operacion i thjeshtë i kopjimit të një imazhi të diskut nga një dyqan të dhënash në tjetrin. Në rastin tim, ka 2 nyje me nfs, unë dërgoj imazhin - kopjimi ndodh përmes opennebula frontend, megjithëse të gjithë jemi mësuar me faktin që të dhënat duhet të kopjohen drejtpërdrejt midis hosteve - në të njëjtin vmware, hyper-v ne jemi i mësuar me këtë, por këtu me një tjetër. Ekziston një qasje e ndryshme dhe një ideologji tjetër, dhe në versionin 5.12 ata hoqën butonin "migrimi në dyqanin e të dhënave" - ​​transferohet vetëm vetë makina, por jo ruajtja sepse nënkupton ruajtjen e centralizuar.

Më pas është një gabim popullor me arsye të ndryshme: "Gabim në vendosjen e makinës virtuale: Nuk mund të krijohej domeni nga /var/lib/one//datastores/103/10/deployment.5". Më poshtë është gjëja kryesore për t'u parë.

  • Të drejtat e imazhit për përdoruesin e oneadmin;
  • Lejet për përdoruesin e oneadmin për të ekzekutuar libvirtd;
  • A është montuar saktë dyqani i të dhënave? Shkoni dhe kontrolloni shtegun në vetë nyjen, mbase diçka ka rënë;
  • Rrjeti i konfiguruar gabimisht, ose më saktë në frontend është në cilësimet e rrjetit që ndërfaqja kryesore për vlan është br0, por në nyjen shkruhet si bridge0 - duhet të jetë e njëjtë.

sistemi i datastore ruan meta të dhënat për vm-në tuaj, nëse e përdorni vm-në me një imazh të vazhdueshëm, atëherë vm duhet të ketë akses në konfigurimin e krijuar fillimisht në hapësirën ruajtëse ku keni krijuar vm - kjo është shumë e rëndësishme. Prandaj, kur transferoni një vm në një dyqan tjetër të dhënash, duhet të kontrolloni dy herë gjithçka.

8. Dokumentacioni, komuniteti. Zhvillimi i mëtejshëm

Dhe pjesa tjetër, dokumentacion i mirë, komunitet dhe kryesorja është që projekti të vazhdojë të jetojë edhe në të ardhmen.

Në përgjithësi, gjithçka është mjaft e dokumentuar dhe madje duke përdorur një burim zyrtar nuk do të jetë problem të instaloni dhe të gjeni përgjigje për pyetjet.

Komunitet, aktiv. Publikon shumë zgjidhje të gatshme që mund t'i përdorni në instalimet tuaja.

Për momentin, disa politika në kompani kanë ndryshuar që nga data 5.12 forum.opennebula.io/t/towards-a-stronger-opennebula-community/8506/14 Do të jetë interesante të shihet se si do të zhvillohet projekti. Në fillim, unë theksova në mënyrë specifike disa nga shitësit që përdorin zgjidhjet e tyre dhe çfarë ofron industria. Sigurisht, nuk ka një përgjigje të qartë se çfarë të përdorni. Por për organizatat më të vogla, mbajtja e resë së tyre të vogël private mund të mos jetë aq e shtrenjtë sa duket. Gjëja kryesore është të dini saktësisht se çfarë ju nevojitet.

Si rezultat, pavarësisht se çfarë zgjidhni si sistem cloud, nuk duhet të ndaleni në një produkt. Nëse keni kohë, ia vlen t'i hidhni një sy zgjidhjeve të tjera më të hapura.

Ka një bisedë të mirë t.me/opennebula Ata ndihmojnë në mënyrë aktive dhe nuk ju dërgojnë të kërkoni një zgjidhje për problemin në Google. Bashkohu me ne.

Burimi: www.habr.com

Shto një koment