Öppen nebulosa. Korta anteckningar

Öppen nebulosa. Korta anteckningar

Hej alla. Den här artikeln skrevs för dem som fortfarande slits mellan att välja virtualiseringsplattformar och efter att ha läst artikeln från serien "Vi installerade proxmox och i allmänhet är allt bra, 6 års drifttid utan en enda paus." Men efter att ha installerat en eller annan out-of-the-box-lösning uppstår frågan: hur kan jag korrigera detta här, så att övervakningen är mer förståelig, och här, för att kontrollera säkerhetskopior... Och så kommer tiden och du inser att du vill ha något mer funktionellt, eller så vill du att allt i ditt system ska bli klart, och inte den här svarta lådan, eller så vill du använda något mer än en hypervisor och ett gäng virtuella maskiner. Den här artikeln kommer att innehålla lite tankar och övningar baserade på Opennebula-plattformen - jag valde den för. det är inte resurskrävande och arkitekturen är inte så komplex.

Och så, som vi ser, arbetar många molnleverantörer på kvm och gör externa anslutningar för att styra maskiner. Det är tydligt att stora värdar skriver sina egna ramverk för molninfrastruktur, samma YANDEX till exempel. Någon använder openstack och gör en anslutning på grundval av detta - SELECTEL, MAIL.RU. Men om du har din egen hårdvara och en liten personal med specialister, väljer du vanligtvis något färdigt - VMWARE, HYPER-V, det finns gratis och betalda licenser, men det är inte vad vi pratar om nu. Låt oss prata om entusiaster - det här är de som inte är rädda för att erbjuda och prova något nytt, trots att företaget tydligt gjorde det klart, "Vem kommer att serva det här efter dig," "Ska vi rulla ut det här i produktion senare ? Skrämmande." Men du kan först applicera dessa lösningar i en testbänk, och om alla gillar det, då kan du ta upp frågan om vidareutveckling och användning i mer seriösa miljöer.

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

Kanske i den här artikeln kommer något att vara överflödigt och redan förståeligt för en erfaren specialist, och i vissa fall kommer jag inte att beskriva allt eftersom liknande kommandon och beskrivningar finns tillgängliga på Internet. Detta är bara min erfarenhet av den här plattformen. Jag hoppas att aktiva deltagare lägger till i kommentarerna vad som kan göras bättre och vilka misstag jag gjort. Alla åtgärder ägde rum i en hemmamonter bestående av 3 PC:er med olika egenskaper. Dessutom angav jag inte specifikt hur denna programvara fungerar och hur man installerar den. Nej, bara administrativ erfarenhet och de problem jag stött på. Kanske kommer detta att vara användbart för någon i deras val.

Så, låt oss börja. Som systemadministratör är följande punkter viktiga för mig, utan vilka jag sannolikt inte kommer att använda den här lösningen.

1. Repeterbarhet vid installation

Det finns många instruktioner för att installera opennebula, det borde inte vara några problem. Från version till version dyker det upp nya funktioner som inte alltid fungerar när man flyttar från version till version.

2. Övervakning

Vi kommer att övervaka själva noden, kvm och opennebula. Som tur är är den redan klar. Det finns många alternativ för att övervaka Linux-värdar, samma Zabbix- eller nodexportör - vem som gillar vad bättre - för tillfället definierar jag det som övervakningssystemmetrik (temperatur där den kan mätas, diskarrayens konsistens), genom zabbix , och när det gäller ansökningar genom Prometheus-exportören. För kvm-övervakning kan du till exempel ta projektet github.com/zhangjianweibj/prometheus-libvirt-exporter.git och ställ in den att köras via systemd, den fungerar ganska bra och visar kvm-mått, det finns även en färdig instrumentpanel 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å vi har en exportör, vi behöver en andra för att övervaka den öppna nebulosan själv, jag använde den här github.com/kvaps/opennebula-exporter/blob/master/opennebula_exporter

Kan läggas till normal node_exporter för att övervaka systemet följande.

I node_exporter-filen ändrar vi starten så här:

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

Skapa en katalog mkdir -p /var/lib/opennebula_exporter

bash script presenterat ovan, först kontrollerar vi arbetet genom konsolen, om det visar vad vi behöver (om det ger ett fel, installera sedan xmlstarlet), kopiera det till /usr/local/bin/opennebula_exporter.sh

Lägg till en cron-uppgift för varje minut:

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

Mätvärden började dyka upp, du kan ta dem som en prometheus och bygga grafer och göra varningar. I Grafana kan du rita till exempel en sådan enkel instrumentpanel.

Öppen nebulosa. Korta anteckningar

(det är tydligt att här överbryggar jag cpu, ram)

För dem som älskar och använder Zabbix finns det github.com/OpenNebula/addon-zabbix

När det gäller övervakningen är huvudsaken att den finns där. Naturligtvis kan du dessutom använda de inbyggda verktygen för övervakning av virtuella maskiner och ladda upp data till fakturering, här har alla sin egen vision, jag har inte börjat arbeta närmare med detta än.

Jag har inte riktigt börjat logga än. Det enklaste alternativet är att lägga till td-agent för att analysera katalogen /var/lib/one med reguljära uttryck. Till exempel, filen sunstone.log matchar nginx regexp och andra filer som visar historiken för åtkomst till plattformen - vad är fördelen med detta? Tja, till exempel kan vi explicit spåra antalet "Fel, fel" och snabbt spåra var och på vilken nivå det finns ett fel.

3. Säkerhetskopieringar

Det finns även betalda genomförda projekt - till exempel sep wiki.sepsoftware.com/wiki/index.php/4_4_3_Tigon:OpenNebula_Backup. Här måste vi förstå att helt enkelt säkerhetskopiera en maskinavbildning inte alls är detsamma i det här fallet, eftersom våra virtuella maskiner måste fungera med full integration (samma kontextfil som beskriver nätverksinställningarna, vm-namnet och anpassade inställningar för dina applikationer) . Därför bestämmer vi här vad och hur vi ska säkerhetskopiera. I vissa fall är det bättre att göra kopior av det som finns i själva vm. Och kanske behöver du bara säkerhetskopiera en disk från en given maskin.

Till exempel bestämde vi att alla maskiner börjar med beständiga bilder, därför efter läsning docs.opennebula.io/5.12/operation/vm_management/img_guide.html

Det betyder att vi först kan ladda upp bilden från vår vm:

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

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

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

Jag hittade också på Internet intressant rapport och det finns mer ett så öppet projekt, men det finns bara lagring för qcow2.

Men som vi alla vet kommer det förr eller senare en tid då man vill ha inkrementella säkerhetskopieringar, det är svårare här och kanske kommer ledningen att allokera pengar till en betald lösning, eller gå åt andra hållet och förstå att här skär vi bara resurser, och att göra säkerhetskopior på applikationsnivå och lägga till ett antal nya noder och virtuella maskiner - ja, här säger jag att man använder molnet enbart för att starta applikationskluster och starta databasen på en annan plattform eller ta en färdig. från leverantören, om möjligt.

4. Användarvänlighet

I det här stycket kommer jag att beskriva de problem som jag stötte på. Till exempel, enligt bilder, som vi vet, finns det ihållande - när denna bild är monterad på en vm skrivs all data till denna bild. Och om den inte är ihållande, kopieras bilden till lagringen och data skrivs till det som kopierades från källbilden - så här fungerar mallmallar. Jag orsakade upprepade gånger problem för mig själv genom att glömma att ange persistent och 200 GB-bilden kopierades, problemet är att denna procedur verkligen inte kan avbrytas, du måste gå till noden och döda den nuvarande "cp" -processen.

En av de viktiga nackdelarna är att du inte kan avbryta åtgärder bara med hjälp av gui. Eller rättare sagt, du kommer att avbryta dem och se att inget händer och du kommer att starta dem igen, avbryta dem och i själva verket kommer det redan att finnas 2 cp-processer som kopierar bilden.

Och sedan kommer det att förstå varför opennebula numrerar varje ny instans med ett nytt id, till exempel i samma proxmox skapade en vm med id 101, tog bort den, sedan skapar du den igen och id 101. I opennebula kommer detta inte att hända, varje ny instans kommer att skapas med ett nytt id och detta har sin egen logik - till exempel rensning av gammal data eller misslyckade installationer.

Detsamma gäller lagring, framför allt är den här plattformen inriktad på centraliserad lagring. Det finns tillägg för att använda lokalt, men det är inte vad vi pratar om i det här fallet. Jag tror att någon i framtiden kommer att skriva en artikel om hur de lyckades använda lokal lagring på noder och framgångsrikt använda den i produktionen.

5. Maximal enkelhet

Naturligtvis, ju längre du kommer, desto färre blir de som kommer att förstå dig.

Under förhållandena i min monter - 3 noder med nfs-lagring - fungerar allt bra. Men om vi utför experiment som involverar ett strömavbrott, till exempel när vi kör en ögonblicksbild och stänger av nodens ström, sparar vi inställningar i databasen att det finns en ögonblicksbild, men det finns faktiskt ingen (ja, vi förstår alla att vi skrev först databasen om denna åtgärd i sql , men själva operationen lyckades inte). Fördelen är att när du skapar en ögonblicksbild, bildas en separat fil och det finns en "förälder", därför vid problem och även om det inte fungerar via gui, kan vi hämta qcow2-filen och återställa den separat docs.opennebula.io/5.8/operation/vm_management/vm_instances.html

På nätverk är tyvärr inte allt så enkelt. Tja, det är i alla fall enklare än i openstack, jag använde bara vlan (802.1Q) - det fungerar ganska bra, men om du gör ändringar i inställningarna från mallnätverket så kommer dessa inställningar inte att tillämpas på redan körande maskiner, d.v.s. du måste ta bort och lägga till ett nätverkskort, då kommer de nya inställningarna att tillämpas.

Om du fortfarande vill jämföra det med openstack kan du säga så här: i opennebula finns det ingen tydlig definition av vilka tekniker som ska användas för att lagra data, hantera nätverket, resurser - varje administratör bestämmer själv vad som är bekvämare för honom.

6. Ytterligare plugins och installationer

När allt kommer omkring, som vi förstår det, kan molnplattformen hantera inte bara kvm, utan även vmware esxi. Tyvärr hade jag ingen pool med Vcenter, om någon har provat, skriv gärna.

Stöd för andra molnleverantörer anges docs.opennebula.io/5.12/advanced_components/cloud_bursting/index.html
AWS, AZURE.

Jag försökte också ansluta Vmware Cloud från Selectel, men ingenting fungerade - i allmänhet blockerades det eftersom det finns många faktorer, och det är ingen idé att skriva till värdleverantörens tekniska support.

Dessutom har den nya versionen smällare - det här är lanseringen av microvm, en typ av kvm-sele över docker, som ger ännu mer mångsidighet, säkerhet och ökad produktivitet eftersom det inte finns något behov av att slösa resurser på att emulera utrustning. Den enda fördelen jag ser gentemot Docker är att den inte tar upp ytterligare ett antal processer och det finns inga upptagna sockets när man använder denna emulering, d.v.s. Det är fullt möjligt att använda det som en lastbalanserare (men det är förmodligen värt att skriva en separat artikel om detta tills jag har kört alla tester helt).

7. Positiv erfarenhet av användning och felsökning

Jag ville dela med mig av mina iakttagelser om arbetet, jag beskrev en del av det ovan, jag skulle vilja skriva mer. Jag är faktiskt inte den enda som först tror att detta inte är rätt system och i allmänhet är allt här en krycka - hur jobbar de ens med detta? Men så kommer förståelsen att allt är ganska logiskt. Naturligtvis kan du inte tillfredsställa alla och vissa aspekter kräver förbättring.

Till exempel en enkel operation att kopiera en skivavbild från en datalagring till en annan. I mitt fall finns det 2 noder med nfs, jag skickar bilden - kopiering sker genom frontend opennebula, även om vi alla är vana vid att data ska kopieras direkt mellan värdar - i samma vmware, hyper-v är vi van vid detta, men här vid en annan. Det finns ett annat tillvägagångssätt och en annan ideologi, och i version 5.12 tog de bort knappen "migrera till datalagring" - bara själva maskinen överförs, men inte lagringen eftersom betyder centraliserad lagring.

Nästa är ett populärt fel med olika anledningar: "Fel vid installation av virtuell maskin: Det gick inte att skapa domän från /var/lib/one//datastores/103/10/deployment.5" Nedan är det bästa att titta på.

  • Bildrättigheter för oneadmin-användaren;
  • Behörigheter för oneadmin-användaren att köra libvirtd;
  • Är datalagringen korrekt monterad? Gå och kolla banan på själva noden, kanske något har ramlat av;
  • Felkonfigurerat nätverk, eller snarare på frontend det är i nätverksinställningarna som huvudgränssnittet för vlan är br0, men på noden skrivs det som bridge0 - det måste vara detsamma.

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 initialt skapade konfigurationen på lagringen där du skapade vm - detta är mycket viktigt. Därför måste du dubbelkolla allt när du överför en vm till en annan databutik.

8. Dokumentation, gemenskap. Ytterligare utveckling

Och resten, bra dokumentation, gemenskap och huvudsaken är att projektet fortsätter leva i framtiden.

I allmänhet är allt ganska väldokumenterat och även med en officiell källa kommer det inte att vara ett problem att installera och hitta svar på frågor.

Gemenskap, aktiv. Publicerar många färdiga lösningar som du kan använda i dina installationer.

För tillfället har vissa policyer i företaget ändrats sedan 5.12 forum.opennebula.io/t/towards-a-stronger-opennebula-community/8506/14 Det ska bli intressant att se hur projektet utvecklas. I början pekade jag specifikt ut några av de leverantörer som använder deras lösningar och vad branschen erbjuder. Det finns naturligtvis inget klart svar på vad man ska använda. Men för mindre organisationer är det kanske inte så dyrt att underhålla sitt lilla privata moln som det verkar. Det viktigaste är att veta exakt vad du behöver.

Som ett resultat bör du, oavsett vad du väljer som molnsystem, inte stanna vid en produkt. Om du har tid är det värt att ta en titt på andra mer öppna lösningar.

Det är en bra pratstund t.me/opennebula De hjälper aktivt till och skickar dig inte för att söka efter en lösning på problemet på Google. Följ med oss.

Källa: will.com

Lägg en kommentar