Opennebula. Korta anteckningar

Hej alla. Denna artikel är skriven för de som fortfarande tvekar mellan olika virtualiseringsplattformar, och efter att ha läst artikeln i serien "Vi installerade proxmox och allt fungerar utmärkt, 6 års driftsäkerhet utan avbrott". Men efter installationen av något av de färdiga lösningarna uppstår frågan om hur man kan justera och förbättra så att övervakningen blir tydligare, och här för att kontrollera backupen…. Och sen kommer tiden när man inser att man vill ha något mer funktionellt, eller att man vill att allt ska vara tydligt i sitt system, istället för den här svarta lådan, eller man vill använda något mer än en hypervisor och en massa virtuella maskiner. I denna artikel kommer det att finnas en del tankar och praktiska exempel baserade på plattformen Opennebula – jag valde den eftersom den inte är så resurskrävande och arkitekturen är inte så komplicerad.

Så som vi ser arbetar många molnleverantörer på kvm och skapar externa gränssnitt för att hantera maskiner. Det är uppenbart att stora hostingleverantörer skriver sina egna lösningar för molninfrastrukturen, samma YANDEX till exempel. Vissa använder OpenStack och bygger ett gränssnitt baserat på det – SELECTEL, MAIL.RU. Men om du har din egen hårdvara och en liten grupp specialister, väljer man oftast något färdigt – VMWARE, HYPER-V, det finns gratis och betalda licenser, men det är inte ämnet för idag. Låt oss prata om entusiaster – de är de som inte är rädda för att föreslå och prova något nytt, trots att företaget tydligt har signalerat "Vem ska underhålla detta efter dig?", "Ska vi verkligen lansera detta i produktion? Skrämmande." Men man kan ju börja med att använda dessa lösningar i ett teststånd, och om alla är nöjda, kan man lyfta frågan om vidare utveckling och användning i mer seriösa miljöer.

Här är också en länk till föredraget www.youtube.com/watch?v=47Mht_uoX3A från en aktiv deltagare i utvecklingen av denna plattform.

Det kan hända att det finns något överflödigt i denna artikel som redan är klart för en erfaren specialist, och i vissa fall kommer jag inte att beskriva allt, eftersom liknande kommandon och beskrivningar finns på nätet. Här är bara min erfarenhet av att arbeta med denna plattform. Jag hoppas att aktiva deltagare kompletterar i kommentarerna om vad som kan göras bättre och vilka misstag jag har gjort. Alla åtgärder har genomförts i en hemmastånd med tre datorer med olika specifikationer. Dessutom har jag avsiktligt valt att inte ange hur denna programvara fungerar och hur man installerar den. Nej, endast administrations erfarenheter och problem som jag har stött på. Kanske kan detta vara till nytta för någon vid valet.

Så, låt oss börja. För mig som systemadministratör är följande punkter viktiga, utan vilka jag knappast skulle använda denna lösning.

1. Installationsåterkomlighet

Det finns massor av instruktioner för att installera opennebula, så det borde inte uppstå några problem. Från version till version dyker nya funktioner upp som kanske inte alltid fungerar vid övergång mellan versioner.

2. Övervakning

Vi kommer att övervaka själva noden, kvm och opennebula. Lyckligtvis finns det redan något klart. Det finns många alternativ för övervakning av linux-servrar, antingen Zabbix eller node exporter — vad som passar bäst — för tillfället definierar jag det så här: övervakning av systemmetrik (temperatur där den kan mätas, konsistens i diskarrayer), via zabbix, medan det som gäller applikationer via exporter till Prometheus. När det gäller att övervaka kvm kan vi till exempel använda projektet github.com/zhangjianweibj/prometheus-libvirt-exporter.git och ställa in det för att starta via systemd, det fungerar bra och visar kvm-metrik, det finns också en färdig dashboard grafana.com/grafana/dashboards/12538.

Till exempel, här är min fil:

/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

Och så har vi 1 exporter, vi behöver en till för att övervaka själva opennebula, jag använde denna github.com/kvaps/opennebula-exporter/blob/master/opennebula_exporter

Kan läggas till i vanlig node_exporter för att övervaka systemet enligt följande.

I filen för node_exporter ändrar vi startkommandot på följande sätt:

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

Skapa katalogen mkdir -p /var/lib/opennebula_exporter

Bash-skriptet som presenteras ovan kontrollerar först arbetet via konsolen, om det visar vad som behövs (om det ger ett fel, installera xmlstarlet), kopiera det till /usr/local/bin/opennebula_exporter.sh

Lägg till ett cron-jobb för varje minut:

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

Metrics have started to appear, you can retrieve them with Prometheus and create graphs and alerts. In Grafana, you can draw a simple dashboard like this.

(it's clear that I've done overcommit for CPU and RAM here)

For those who love and use Zabbix, there is github.com\/OpenNebula\/addon-zabbix

That's all for monitoring; the main thing is that it's there. Of course, you can additionally use built-in tools for monitoring virtual machines and export data to billing; everyone has their own vision on this, and I haven't delved into it more deeply yet.

As for logging, I haven't really started yet. The simplest option is to add td-agent for parsing the directory \/var\/lib\/one using regular expressions. For example, the file sunstone.log fits the regexp for nginx and other files that show the history of interactions with the platform — what's the advantage of this? Well, for instance, we can clearly track the number of "Error, error" messages and quickly identify where and at what level the issue is occurring.

3. Backups

There are also paid enhanced projects — for example sep wiki.sepsoftware.com\/wiki\/index.php\/4_4_3_Tigon:OpenNebula_Backup. Here we need to understand that simply backing up a machine image is not enough; our virtual machines need to operate with full integration (the same context file that describes network settings, the VM name, and custom settings for your applications). Therefore, we determine what and how we will backup. In some cases, it is better to create copies of what is stored directly in the VM. And perhaps we should only backup one disk from this machine.

For example, we've determined that all machines boot with persistent images, so after reading docs.opennebula.io\/5.12\/operation\/vm_management\/img_guide.html

we can first export the image from our VM:

onevm disk-saveas 74 3 prom.qcow2\nImage ID: 77\n\nLet's see under what name it was saved\n\noneimage show 77\n\/var\/lib\/one\/\/datastores\/100\/f9503161fe180658125a9b32433bf6e8\n   \nAnd then we copy it wherever we need. Of course, it's not the best method. I just wanted to show that using OpenNebula tools, similar solutions can be built.

I also found an interesting report and there's another open project like this, but this one is only for qcow2 storage.

Men som vi alla vet, kommer det förr eller senare en tid då man vill ha inkrementella säkerhetskopior; här är det svårare och det är möjligt att ledningen kommer att avsätta pengar för en betald lösning, eller gå en annan väg och inse att vi bara förbrukar resurser här, medan säkerhetskopiering görs på applikationsnivå och genom att öka antalet nya noder och virtuella maskiner — ja, här säger jag att man ska använda molnet enbart för att starta applikationskluster, medan databaser ska drivas på en annan plattform eller använda en färdig lösning från en leverantör, om det är möjligt.

4. Användarvänlighet

I denna punkt kommer jag att beskriva de problem jag har stött på. Till exempel, vad gäller bilder, som vi vet, finns det persistent — när denna bild monteras på en VM, skrivs all data till denna bild. Om den är non-persistent kopieras bilden till lagringen och data skrivs där det kopierades från den ursprungliga bilden — så fungerar mallarna. Jag har upprepade gånger ställt till problem för mig själv genom att glömma att ange persistent och 200 GB bilden kopierades; problemet är att denna procedur förmodligen inte kan annulleras, man måste gå till noden och döda den pågående 'cp'-processen.

En av de viktiga nackdelarna är att man inte kan ångra åtgärder enbart genom att använda GUI. Man ångrar dem, ser att ingenting händer och startar om, ångrar igen och i praktiken kommer det redan att finnas 2 'cp'-processer som kopierar bilden.

Och här kommer insikten om varför opennebula numrerar varje ny instans med ett nytt id; till exempel i proxmox skapade jag en VM med id 101, tog bort den, och skapade sedan en ny och fick id 101. I OpenNebula kommer det inte att bli så; varje ny instans kommer att skapas med ett nytt id och det finns en logik bakom detta — till exempel för att rensa gamla data eller misslyckade installationer.

Samma sak gäller lagring; denna plattform fokuserar mest på centraliserad lagring. Det finns tillägg för att använda lokal lagring, men det handlar inte om det i detta fall. Jag tror att någon i framtiden kommer att skriva en artikel om hur man lyckades använda lokal lagring på noder och framgångsrikt använda det i produktion.

5. Maximal enkelhet

Självklart, ju längre man går, desto färre blir de som verkligen förstår en.

Under the conditions of my setup — 3 nodes with NFS storage — everything works fine. However, if we perform experiments with power outages, for example, when starting a snapshot and cutting off the power to the nodes, we retain the settings in the database indicating that there is a snapshot, but in reality, it does not exist (we all understand that it initially recorded the action in the SQL database, but the operation itself was unsuccessful). The plus side is that when creating a snapshot, a separate file is formed and there is a 'parent,' so in case of issues, even if it doesn't work through the GUI, we can take the qcow2 file and restore it separately. docs.opennebula.io/5.8/operation/vm_management/vm_instances.html

When it comes to networks, unfortunately, it's not that simple. At least it's easier than in OpenStack; I've only used VLAN (802.1Q) — it works quite well, but if you make changes in the settings from the template network, those settings will not apply to already running machines, i.e., you need to delete and re-add the network card for the new settings to take effect.

If you want to compare with OpenStack, you could say that in OpenNebula, there's no clear definition of which technologies to use for data storage, network management, or resources — each administrator decides for themselves what is more convenient.

6. Additional plugins and installations

As we understand, the cloud platform can manage not only KVM but also VMware ESXi. Unfortunately, I didn't have a pool with vCenter; if anyone has tried, please let me know.

In the support of other cloud providers, it has been stated docs.opennebula.io/5.12/advanced_components/cloud_bursting/index.html
AWS, AZURE.

I also tried to integrate VMware Cloud from Selectel, but nothing worked out — overall, I gave up since there were many factors, and writing to the hosting provider's tech support seemed pointless.

Additionally, in the new version, there is Firecracker — this launches microVMs, a kind of KVM wrapper over Docker, which provides even more versatility, security, and enhanced performance since it doesn't waste resources on hardware emulation. I see only advantages over Docker in that it doesn’t occupy additional processes or sockets when using this emulation, meaning it can easily be used as a load balancer (but perhaps I should write a separate article about this, as I have yet to conduct all tests fully).

7. Positive experience of use and error debugging

Jag ville dela med mig av mina observationer angående systemets funktion, en del har jag beskrivit ovan och jag vill skriva mer. Verkligen, det är troligtvis inte bara jag som först tänker att det här inte är rätt system och att allt här är hackigt — hur fungerar man egentligen med detta? Men sen kommer insikten om att allt är ganska logiskt. Självklart kan man inte tillfredsställa alla och vissa aspekter kräver förbättringar.

Till exempel, en enkel operation att kopiera en diskavbild från en datastore till en annan. I mitt fall finns det 2 noder med NFS, jag skickar bilden — kopieringen sker genom frontend OpenNebula, även om vi alla är vana vid att data ska kopieras direkt mellan värdarna — i VMware och Hyper-V är vi just vana vid detta, men här fungerar det annorlunda. Här är det en annan metod och annan ideologi, och i version 5.12 togs knappen 'migrate to datastore' bort — endast själva maskinen flyttas, inte lagringen, eftersom det förutsätter en centraliserad lagring.

Sedan finns det ett vanligt fel med olika orsaker 'Error deploying virtual machine: Could not create domain from /var/lib/one//datastores/103/10/deployment.5'. Nedan är en lista över vad du bör se över.

• Rättigheter för bilden för användaren oneadmin;
• Rättigheter för användaren oneadmin för att köra libvirtd;
• Är datastoren korrekt monterad? Gå och kontrollera sökvägen på själva noden, kanske har något försvunnit;
• Felaktigt konfigurerat nätverk, egentligen står det i frontend-inställningarna att br0 är det primära gränssnittet för VLAN, medan noden har angivit — bridge0 — det måste vara samma på båda.

Systemdatastore lagrar metadata för din VM, om du kör VM med en beständig bild måste VM ha tillgång till den ursprungligen skapade konfigurationen på den lagring där du skapade VM:n — detta är mycket viktigt. Så vid flytt av VM till en annan datastore måste allt dubbelkollas.

8. Dokumentation, gemenskap. Vidare utveckling

Och mer, bra dokumentation, en aktiv gemenskap och viktigast av allt, att projektet fortsätter att leva i framtiden.

Här är det överlag ganska väl dokumenterat och det bör inte vara några problem att installera eller hitta svar på frågor, även från officiella källor.

Gemenskapen är aktiv. De publicerar många färdiga lösningar som du kan använda i dina installationer.

För närvarande har vissa policys förändrats i företaget med version 5.12. forum.opennebula.io/t/towards-a-stronger-opennebula-community/8506/14 Det blir intressant att se hur projektet utvecklas. I början angav jag medvetet några leverantörer som använder sina egna lösningar och det som erbjuds inom branschen. Det finns inget klart svar på vad du ska använda, förstås. Men för små organisationer kan stödet för sitt eget lilla privata moln kosta betydligt mindre än vad det verkar. Det viktiga är att veta exakt vad du behöver.

Som en slutsats, oavsett vad du valt som molnsystem, bör du inte stanna kvar vid en enda produkt. Om du har tid, titta på andra mer öppna lösningar.

Det finns en bra chatt t.me/opennebula som aktivt hjälper och inte bara skickar dig för att söka lösningar på problemet på Google. Gå med.

Källa: habr.com