Përshëndetje të gjithëve. Ky artikull është shkruar për ata që janë ende të dyzuar midis zgjedhjes së një platforme virtualizimi pasi kanë lexuar artikuj si "Ne instaluam Proxmox dhe gjithçka është shkëlqyeshëm, 6 vjet kohëzgjatje funksionimi pa asnjë vonesë". Por pasi instaloni një zgjidhje të paketuar, pyesni veten se si t'i ndryshoni gjërat këtu e atje për ta bërë monitorimin më intuitiv dhe për të kontrolluar kopjet rezervë... Pastaj vjen koha dhe e kuptoni se dëshironi diçka më funksionale, ose dëshironi ta bëni gjithçka brenda sistemit tuaj më të kuptueshme, jo një kuti të zezë, ose dëshironi të përdorni diçka më shumë sesa një hipervizor dhe një mori makinash virtuale. Ky artikull do të ofrojë disa reflektime dhe shembuj praktikë bazuar në platformën Opennebula - e zgjodha sepse nuk kërkon shumë burime dhe arkitektura e saj nuk është aq komplekse.
Pra, siç e shohim, shumë ofrues të shërbimeve cloud punojnë me KVM dhe krijojnë korniza të jashtme për menaxhimin e makinerive. Është e qartë se ofruesit e mëdhenj të shërbimeve hosting shkruajnë kornizat e tyre për infrastrukturën cloud, si për shembull YANDEX. Disa përdorin OpenStack dhe krijojnë korniza bazuar në të - SELECTEL, MAIL.RU. Por nëse keni harduerin 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ë çështja tani. Le të flasim për entuziastët - ata që nuk kanë frikë të propozojnë dhe të provojnë diçka të re, pavarësisht mesazheve të qarta të kompanisë si: "Kush do ta mirëmbajë këtë pasi të largoheni?" ose "A do ta lançojmë vërtet këtë në prodhim? E frikshme." Por fillimisht mund t'i përdorni këto zgjidhje në një platformë testimi, dhe nëse të gjithëve u pëlqejnë, mund të merrni në konsideratë zhvillimin dhe përdorimin e mëtejshëm në mjedise më serioze.
Ja edhe linku i raportit nga një pjesëmarrës aktiv në zhvillimin e kësaj platforme.
Ky artikull mund të përmbajë disa informacione të panevojshme që janë tashmë të qarta për profesionistët me përvojë. Në disa raste, nuk do të trajtoj gjithçka, pasi komanda dhe përshkrime të ngjashme janë të disponueshme në internet. Kjo është vetëm përvoja ime me këtë platformë. Shpresoj që përdoruesit aktivë do të japin mendimin e tyre në komente rreth asaj që mund të ishte përmirësuar dhe çdo gabim që kam bërë. E gjithë kjo është bërë në një sistem shtëpiak që përbëhet nga tre PC me specifikime të ndryshme. Gjithashtu, qëllimisht shmanga shpjegimin se si funksionon softueri ose si ta instaloj atë. Në vend të kësaj, do të ndaj përvojën time të administrimit dhe problemet që hasa. Ndoshta kjo do të jetë e dobishme për dikë që po bën zgjedhjen e tij.
Pra, le të fillojmë. Si administrator sistemi, pikat e mëposhtme janë të rëndësishme për mua; pa to, nuk ka gjasa ta përdor këtë zgjidhje.
1. Përsëritshmëria e instalimit
Ka shumë udhëzime për instalimin e OpenNebula, kështu që nuk duhet të keni probleme. Karakteristika të reja shtohen nga versioni në version dhe ato mund të mos funksionojnë gjithmonë ndërsa kaloni nga një version në tjetrin.
2. Monitorimi
Do të monitorojmë vetë nyjen, KVM-në dhe OpenNebula-n. Për fat të mirë, ne tashmë kemi një zgjidhje të gatshme. Ka shumë mundësi për monitorimin e hosteve Linux, si Zabbix ose Node Exporter - varet nga ju. Aktualisht, unë po përdor Zabbix për monitorimin e metrikave të sistemit (temperatura aty ku është e matshme, qëndrueshmëria e vargut të diskut) dhe Prometheus për monitorimin e aplikacioneve. Për shembull, mund të përdorim një projekt për monitorimin e KVM-së. dhe e caktoni të funksionojë përmes systemd, funksionon mjaft mirë dhe tregon metrika kvm, ekziston edhe një panel kontrolli i gatshëm .
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.targetPra, kemi 1 eksportues, na duhet një i dytë për të monitoruar vetë opennebula-n, unë e përdora këtë.
Mund të shtohet në të rregulltën për të monitoruar sistemin si më poshtë.
Në skedarin node_exporter, ndryshoni fillimin si më poshtë:
ExecStart=/usr/sbin/node_exporter --web.listen-address=":9102" --collector.textfile.directory=/var/lib/opennebula_exporter/textfile_collectorKrijo një direktori mkdir -p /var/lib/opennebula_exporter
Së pari, kontrolloni skriptin bash të paraqitur më sipër nëpërmjet konzolës; nëse tregon atë që ju nevojitet (nëse jep një gabim, instaloni xmlstarlet), kopjojeni atë në /usr/local/bin/opennebula_exporter.sh
Shtoni një detyrë në cron për çdo minutë:
*/1 * * * * (/usr/local/bin/opennebula_exporter.sh > /var/lib/opennebula_exporter/textfile_collector/opennebula.prom)Metrikat kanë filluar të shfaqen dhe ju mund të përdorni Prometheus për t'i kapur ato dhe për të krijuar grafikë dhe alarme. Për shembull, mund të krijoni një panel të thjeshtë si ky në Grafana.
(Mund ta shihni që e mbingarkoj CPU-në dhe RAM-in këtu)
Për ata që e duan dhe përdorin Zabbix, ekziston
Kjo është e gjitha që ka të bëjë me monitorimin, gjëja kryesore është se është aty. Sigurisht, ju gjithashtu mund të përdorni mjetet e integruara të monitorimit të makinës virtuale dhe të ngarkoni të dhëna në faturim, por secili ka mendimin e vet për këtë, dhe unë ende nuk jam thelluar në të.
Nuk kam filluar ende të regjistrohem. Mundësia më e thjeshtë është të shtoj td-agent për të analizuar direktorinë /var/lib/one duke përdorur shprehje të rregullta. Për shembull, skedari sunstone.log përputhet me regexp-in e nginx dhe skedarë të tjerë që tregojnë historikun e aksesit në platformë - cili është përfitimi i kësaj? Për shembull, ne mund të gjurmojmë qartë numrin e mesazheve "Gabim, gabim" dhe të përcaktojmë më shpejt se ku dhe në çfarë niveli është problemi.
3. Kopje rezervë
Ekzistojnë gjithashtu projekte të paguara dhe të përmirësuara, të tilla si sep. :OpenNebula_Backup. Këtu duhet të kuptojmë se thjesht kopja rezervë e një imazhi makine nuk është zgjidhja në këtë rast, pasi makinat tona virtuale duhet të funksionojnë me integrim të plotë (duke përfshirë skedarin e kontekstit që përshkruan cilësimet e rrjetit, emrin e VM-së dhe cilësimet e personalizuara për aplikacionet tuaja). Prandaj, këtu përcaktojmë se çfarë dhe si të kopjojmë rezervë. Në disa raste, është më mirë të bëni kopje rezervë të asaj që është në vetë VM-në. Dhe ndoshta ju duhet të krijoni kopje rezervë vetëm të një disku nga një makinë e caktuar.
Për shembull, ne përcaktuam që të gjitha makinat fillojnë me imazhe të vazhdueshme, prandaj, pas leximit
Pra, së pari mund ta shkarkojmë imazhin nga makina jonë virtuale:
onevm disk-saveas 74 3 prom.qcow2
Image ID: 77
Смотрим, под каким именем он сохранился
oneimage show 77
/var/lib/one//datastores/100/f9503161fe180658125a9b32433bf6e8
И далее копируем куда нам необходимо. Конечно, так себе способ. Просто хотел показать, что используя инструменты opennebula можно строить подобные решения.Edhe këtë e gjeta në internet dhe ka më shumë , por ka vetëm hapësirë ruajtjeje për qcow2.
Por, siç e dimë të gjithë, herët a vonë vjen një kohë kur do të dëshironi kopje rezervë graduale. Kjo është më e ndërlikuar dhe ndoshta menaxhmenti do të ndajë fonde për një zgjidhje me pagesë. Ose, me kuptimin që po shkurtojmë vetëm burimet këtu dhe kopjet rezervë duhet të bëhen në nivelin e aplikacionit dhe duke shtuar nyje dhe makina virtuale të reja - mirë, këtu po them që përdorimi i cloud-it thjesht për ekzekutimin e grupeve të aplikacioneve dhe ekzekutimi i bazës së të dhënave në një platformë tjetër ose përdorimi i një të gatshme nga një shitës, nëse është e mundur.
4. Lehtësia e përdorimit
Në këtë seksion, do të përshkruaj problemet që hasa. Për shembull, me imazhet, siç e dimë, ekziston një opsion i përhershëm - kur montohet imazhi në një VM, të gjitha të dhënat shkruhen në atë imazh. Por nëse nuk është i përhershëm, imazhi kopjohet në memorie dhe të dhënat shkruhen në atë që është kopjuar nga imazhi origjinal - kështu funksionojnë shabllonet. I kam shkaktuar vetes probleme më shumë se një herë duke harruar të specifikoj "persistent", dhe një imazh 200 GB është kopjuar. Problemi është se kjo procedurë nuk mund të anulohet; duhet të shkoni te nyja dhe të mbyllni procesin aktual "cp".
Një pengesë e madhe është se nuk mund t’i anuloni veprimet thjesht duke përdorur GUI-në. Ose më saktë, do t’i anuloni dhe do të shihni që nuk ndodh asgjë. Pastaj, do ta ekzekutoni përsëri, do t’i anuloni dhe në fakt, do të ketë dy procese cp që do ta kopjojnë imazhin.
Dhe pastaj e kuptoj pse OpenNebula i cakton një ID të ri çdo instance të re. Për shembull, në Proxmox, ju krijoni një VM me ID 101, e fshini atë dhe pastaj e rikrijoni atë me ID 101. Kjo nuk do të ndodhë në OpenNebula; çdo instancë e re do të krijohet me një ID të re dhe ka një logjikë për këtë - për shembull, pastrimi i të dhënave të vjetra ose instalimeve të dështuara.
E njëjta gjë vlen edhe për ruajtjen: kjo platformë është përqendruar kryesisht në ruajtjen e centralizuar. Ka shtesa për përdorimin e ruajtjes lokale, por ky nuk është rasti këtu. Mendoj se dikush do të shkruajë një artikull në të ardhmen se si arriti të përdorë ruajtjen lokale në nyje dhe ta përdorë atë me sukses në prodhim.
5. Thjeshtësi maksimale
Sigurisht, sa më larg të shkosh, aq më pak do të ketë nga ata që do të të kuptojnë.
Në konfigurimin tim—tre nyje me ruajtje NFS—gjithçka funksionon mirë. Por nëse kryejmë eksperimente me fikjen e energjisë, për shembull, kur ekzekutojmë një pamje të çastit dhe e fikim një nyje, do t'i ruajmë cilësimet në bazën e të dhënave duke treguar se ekziston një pamje e çastit, por në fakt, nuk ka një të tillë (epo, të gjithë e dimë që fillimisht shkrova për këtë veprim në bazën e të dhënave SQL, por vetë operacioni nuk pati sukses). Avantazhi është se kur krijohet një pamje e çastit, krijohet një skedar i veçantë dhe ekziston një "prind", kështu që në rast problemesh, ose edhe nëse GUI nuk funksionon, mund ta rikuperojmë skedarin qcow2 dhe ta rivendosim atë veçmas.
Fatkeqësisht, gjërat nuk janë aq të thjeshta me rrjetet. Epo, të paktën është më e thjeshtë se në OpenStack. Unë përdora vetëm VLAN (802.1Q)—funksionon mirë, por nëse bëni ndryshime në cilësimet nga rrjeti shabllon, ato cilësime nuk do të zbatohen për makinat ekzistuese. Do t'ju duhet të hiqni dhe shtoni kartën e rrjetit që të zbatohen cilësimet e reja.
Nëse doni ta krahasoni me OpenStack, mund të thoni këtë: OpenNebula nuk përcakton qartë se cilat teknologji duhen përdorur për ruajtjen e të dhënave, menaxhimin e rrjetit dhe menaxhimin e burimeve - çdo administrator vendos vetë se çfarë është më e përshtatshme.
6. Plugin-e dhe instalime shtesë
Siç e kuptojmë, platforma cloud mund të menaxhojë jo vetëm KVM, por edhe VMware ESXI. Fatkeqësisht, unë nuk kisha një grup të dhënash me VCenter, por nëse dikush e ka provuar, ju lutem më njoftoni.
Është deklaruar mbështetja për ofruesit e tjerë të cloud-it
AWS, AZURE.
Gjithashtu provova të instaloj VMware Cloud nga Selectel, por nuk funksionoi. Hoqa dorë sepse kishte shumë faktorë të përfshirë dhe kontaktimi i mbështetjes teknike të ofruesit të hostingut ishte i kotë.
Gjithashtu, versioni i ri tani përfshin Firecracker—një lëshues microVM, si një mbështjellës KVM mbi Docker—i cili ofron edhe më shumë shkathtësi, siguri dhe performancë, pasi eliminon nevojën për të shpenzuar burime në emulimin e harduerit. Avantazhi i vetëm që shoh ndaj Docker është se nuk merr procese shtesë dhe nuk konsumon socket-e kur përdoret ky emulim. Kjo do të thotë se mund të përdoret lehtësisht si një balancues ngarkese (megjithëse ndoshta duhet të shkruaj një artikull të veçantë për këtë derisa ta kem testuar plotësisht).
7. Përvojë pozitive e përdoruesit dhe gabime debugging
Doja të ndaja vëzhgimet e mia rreth punës; i kam përshkruar disa prej tyre më sipër, por do të doja të shkruaja më shumë. Në të vërtetë, ndoshta nuk jam i vetmi që fillimisht mendon se ky është sistemi i gabuar dhe se gjithçka është një mashtrim - si funksionon dikush me këtë? Por pastaj arrij të kuptoj 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 disku nga një depo të dhënash në një tjetër. Në rastin tim, kam dy nyje që ekzekutojnë NFS, dhe kur e dërgoj imazhin, kopjimi ndodh përmes frontend-it të OpenNebula. Ndërsa të gjithë jemi mësuar që të dhënat të kopjohen direkt midis hosteve - si në VMware dhe Hyper-V - kjo është pikërisht ajo me të cilën jemi mësuar, kjo është e ndryshme. Është një qasje dhe një filozofi e ndryshme, dhe në versionin 5.12, butoni "migro në depo të dhënash" u hoq. Vetëm vetë makina migron, jo depoja e të dhënave, pasi ruajtja themelore është e centralizuar.
Më poshtë është një gabim i zakonshëm me shkaqe të ndryshme: “Gabim gjatë vendosjes së makinës virtuale: Nuk mund të krijohet domen nga /var/lib/one//datastores/103/10/deployment.5.” Më poshtë është lista kryesore e gjërave që duhen parë.
- Të drejtat e imazhit për përdoruesin oneadmin;
- Lejet për përdoruesin oneadmin për të ekzekutuar libvirtd;
- A është montuar siç duhet datastore? Kontrolloni shtegun në vetë nyjen; diçka mund të jetë e prishur.
- Rrjeti është konfiguruar gabimisht, ose më saktë, cilësimet e rrjetit në frontend thonë se br0 është vendosur si ndërfaqja kryesore për VLAN, ndërsa në nyje thotë bridge0 - kjo duhet të jetë e njëjta gjë.
Depozita e të dhënave të sistemit ruan meta të dhënat për VM-në tuaj. Nëse nisni një VM nga një imazh i përhershëm, VM-ja ka nevojë për qasje në konfigurimin fillestar në memorien ku e keni krijuar VM-në - kjo është thelbësore. Prandaj, kur migroni një VM në një depo të ndryshme të dhënash, duhet të kontrolloni dy herë gjithçka.
8. Dokumentacioni, komuniteti dhe zhvillimi i ardhshëm
Dhe pjesa tjetër, dokumentacion i mirë, komunitet dhe, më e rëndësishmja, që projekti të vazhdojë të jetojë në të ardhmen.
Këtu, në përgjithësi, gjithçka është mjaft mirë e dokumentuar, dhe madje edhe nga burimi zyrtar nuk do të jetë problem të instaloni dhe të gjeni përgjigje për pyetjet.
Komuniteti është aktiv dhe publikon shumë zgjidhje të gatshme që mund t'i përdorni në instalimet tuaja.
Që nga 5.12 dhjetori, disa politika të kompanisë kanë ndryshuar. Do të jetë interesante të shohim se si do të zhvillohet projekti. Në fillim, përmenda konkretisht disa shitës që përdorin zgjidhjet e tyre dhe atë që ofron industria. Sigurisht, nuk ka një përgjigje të qartë se çfarë duhet të përdorni. Por për organizatat e vogla, mirëmbajtja e cloud-it të tyre të vogël privat mund të mos jetë aq e kushtueshme sa duket. Gjëja kryesore është të dini saktësisht se çfarë ju nevojitet.
Në fund të fundit, pavarësisht se cilin sistem cloud zgjidhni, mos u mjaftoni vetëm me një produkt. Nëse keni kohë, merrni në konsideratë zgjidhje të tjera, më me burim të hapur.
Ka një bisedë të mirë Ata ndihmojnë në mënyrë aktive dhe nuk të dërgojnë te Google për të gjetur një zgjidhje. Bashkohuni me ne.
Burimi: www.habr.com
