Hej alle. Denne artikel er skrevet til dem, der stadig er splittet mellem at vælge virtualiseringsplatforme og efter at have læst artiklen fra serien "Vi installerede proxmox og generelt er alt fint, 6 års oppetid uden en eneste pause." Men efter at have installeret en eller anden out-of-the-box-løsning, opstår spørgsmålet: hvordan kan jeg rette dette her, så overvågningen er mere forståelig, og her for at kontrollere backups... Og så kommer tiden, og du indser, at du vil have noget mere funktionelt, eller du vil have, at alt inde i dit system bliver klart, og ikke denne sorte boks, eller du vil bruge noget mere end en hypervisor og en masse virtuelle maskiner. Denne artikel vil indeholde nogle tanker og praksis baseret på Opennebula platformen – jeg valgte det pga. det er ikke ressourcekrævende, og arkitekturen er ikke så kompleks.
Og så, som vi ser, arbejder mange cloud-udbydere på kvm og laver eksterne forbindelser for at styre maskiner. Det er tydeligt, at store hostere skriver deres egne rammer for cloud-infrastruktur, det samme YANDEX for eksempel. Nogen bruger openstack og laver en forbindelse på dette grundlag - SELECTEL, MAIL.RU. Men hvis du har din egen hardware og en lille stab af specialister, så vælger du normalt noget færdiglavet - VMWARE, HYPER-V, der er gratis og betalte licenser, men det er ikke det, vi taler om nu. Lad os tale om entusiaster - det er dem, der ikke er bange for at tilbyde og prøve noget nyt, på trods af at virksomheden tydeligt gjorde det klart, "Hvem vil servicere dette efter dig," "Skal vi rulle det ud i produktion senere ? Skræmmende." Men du kan først anvende disse løsninger i en testbænk, og hvis alle kan lide det, så kan du rejse spørgsmålet om videreudvikling og brug i mere seriøse miljøer.
Her er også et link til rapporten fra en aktiv deltager i udviklingen af denne platform.
Måske i denne artikel vil noget være overflødigt og allerede forståeligt for en erfaren specialist, og i nogle tilfælde vil jeg ikke beskrive alt, fordi lignende kommandoer og beskrivelser er tilgængelige på internettet. Dette er blot min erfaring med denne platform. Jeg håber, at aktive deltagere vil tilføje i kommentarerne, hvad der kunne gøres bedre, og hvilke fejl jeg lavede. Alle handlinger foregik i en hjemmestand bestående af 3 pc'er med forskellige karakteristika. Jeg har heller ikke specifikt angivet, hvordan denne software virker, og hvordan den installeres. Nej, kun administrationserfaring og de problemer, jeg stødte på. Måske vil dette være nyttigt for nogen i deres valg.
Så lad os komme i gang. Som systemadministrator er følgende punkter vigtige for mig, uden hvilke jeg næppe vil bruge denne løsning.
1. Installation repeterbarhed
Der er en masse instruktioner til installation af opennebula, der burde ikke være nogen problemer. Fra version til version dukker der nye funktioner op, som ikke altid vil fungere, når man går fra version til version.
2. Overvågning
Vi vil overvåge selve knudepunktet, kvm og opennebula. Heldigvis er den allerede klar. Der er mange muligheder for at overvåge Linux-værter, den samme Zabbix eller node-eksportør - hvem kan lide hvad bedre - i øjeblikket definerer jeg det som overvågningssystemmetrikker (temperatur, hvor det kan måles, diskarrayets konsistens) gennem zabbix , og hvad angår ansøgninger gennem Prometheus-eksportøren. Til kvm-overvågning kan du fx tage projektet og sæt den til at køre via systemd, den fungerer ret godt og viser kvm metrics, der er også et færdiglavet dashboard .
For eksempel, her er 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.targetOg så vi har 1 eksportør, vi har brug for en anden til at overvåge opennebula selv, jeg brugte denne
Kan tilføjes til alm for at overvåge systemet følgende.
I node_exporter-filen ændrer vi starten sådan her:
ExecStart=/usr/sbin/node_exporter --web.listen-address=":9102" --collector.textfile.directory=/var/lib/opennebula_exporter/textfile_collectorOpret en mappe mkdir -p /var/lib/opennebula_exporter
bash script præsenteret ovenfor, først tjekker vi arbejdet gennem konsollen, hvis det viser hvad vi har brug for (hvis det giver en fejl, så installer xmlstarlet), kopier det til /usr/local/bin/opennebula_exporter.sh
Tilføj en cron-opgave for hvert minut:
*/1 * * * * (/usr/local/bin/opennebula_exporter.sh > /var/lib/opennebula_exporter/textfile_collector/opennebula.prom)Målinger begyndte at dukke op, du kan tage dem som en prometheus og bygge grafer og lave advarsler. I Grafana kan du for eksempel tegne sådan et simpelt dashboard.
(det er klart, at her overcommiter jeg cpu, ram)
For dem, der elsker og bruger Zabbix, er der
Hvad angår overvågning, er det vigtigste, at den er der. Selvfølgelig kan du derudover bruge de indbyggede virtuelle maskine overvågningsværktøjer og uploade data til fakturering, her har alle deres egen vision, det er jeg ikke begyndt at arbejde nærmere med endnu.
Jeg er ikke rigtig begyndt at logge endnu. Den enkleste mulighed er at tilføje td-agent for at parse mappen /var/lib/one med regulære udtryk. For eksempel matcher filen sunstone.log nginx regexp og andre filer, der viser historikken for adgang til platformen - hvad er fordelen ved dette? Nå, for eksempel kan vi eksplicit spore antallet af "Fejl, fejl" og hurtigt spore, hvor og på hvilket niveau der er en fejl.
3. Sikkerhedskopier
Der er også betalt gennemførte projekter - fx sep :OpenNebula_Backup. Her skal vi forstå, at blot at sikkerhedskopiere et maskinbillede slet ikke er det samme i dette tilfælde, fordi vores virtuelle maskiner skal arbejde med fuld integration (den samme kontekstfil, der beskriver netværksindstillingerne, vm-navnet og brugerdefinerede indstillinger for dine applikationer) . Derfor beslutter vi her, hvad og hvordan vi vil sikkerhedskopiere. I nogle tilfælde er det bedre at lave kopier af, hvad der er i selve vm. Og måske behøver du kun at tage backup af én disk fra en given maskine.
For eksempel fastslog vi, at alle maskiner starter med vedvarende billeder, derfor efter læsning
Det betyder, at vi først kan uploade billedet fra vores vm:
onevm disk-saveas 74 3 prom.qcow2
Image ID: 77
Смотрим, под каким именем он сохранился
oneimage show 77
/var/lib/one//datastores/100/f9503161fe180658125a9b32433bf6e8
И далее копируем куда нам необходимо. Конечно, так себе способ. Просто хотел показать, что используя инструменты opennebula можно строить подобные решения.Jeg fandt også på internettet og der er mere , men der er kun lagerplads til qcow2.
Men som vi alle ved, kommer der før eller siden et tidspunkt, hvor du vil have inkrementelle sikkerhedskopier, det er sværere her, og måske vil ledelsen allokere penge til en betalt løsning, eller gå den anden vej og forstå, at her skærer vi kun på ressourcer, og lave sikkerhedskopier på applikationsniveau og tilføje en række nye noder og virtuelle maskiner - ja, her siger jeg, at man bruger skyen udelukkende til at starte applikationsklynger og starte databasen på en anden platform eller tage en færdiglavet en fra leverandøren, hvis det er muligt.
4. Brugervenlighed
I dette afsnit vil jeg beskrive de problemer, jeg stødte på. For eksempel, ifølge billeder, som vi ved, er der vedvarende - når dette billede er monteret på en vm, skrives alle data til dette billede. Og hvis ikke-vedvarende, så kopieres billedet til lageret, og dataene skrives til det, der blev kopieret fra kildebilledet - det er sådan skabelonskabeloner fungerer. Jeg har gentagne gange forårsaget problemer for mig selv ved at glemme at angive persistent, og 200 GB-billedet blev kopieret, problemet er, at denne procedure bestemt ikke kan annulleres, du skal gå til noden og dræbe den nuværende "cp"-proces.
En af de vigtige ulemper er, at du ikke kan annullere handlinger blot ved at bruge gui. Eller rettere sagt, du vil annullere dem og se, at der ikke sker noget, og du vil starte dem igen, annullere dem og faktisk vil der allerede være 2 cp-processer, der kopierer billedet.
Og så kommer det til at forstå, hvorfor opennebula nummererer hver ny instans med et nyt id, for eksempel i samme proxmox oprettede en vm med id 101, slettede den, så opretter du den igen og id 101. I opennebula vil dette ikke ske, hver ny instans vil blive oprettet med et nyt id, og dette har sin egen logik - for eksempel sletning af gamle data eller mislykkede installationer.
Det samme gælder for opbevaring; mest af alt er denne platform rettet mod centraliseret opbevaring. Der er tilføjelser til at bruge lokalt, men det er ikke det, vi taler om i dette tilfælde. Jeg tror, at nogen i fremtiden vil skrive en artikel om, hvordan de formåede at bruge lokal lagring på noder og med succes bruge det i produktionen.
5. Maksimal enkelhed
Jo længere du går, jo færre bliver de, der vil forstå dig.
Under betingelserne for min stand - 3 noder med nfs storage - fungerer alt fint. Men hvis vi udfører eksperimenter, der involverer strømafbrydelse, f.eks. når vi kører et øjebliksbillede og slukker for strømmen til noden, gemmer vi indstillinger i databasen om, at der er et øjebliksbillede, men i virkeligheden er der ingen (vel, vi forstår alle, at vi skrev oprindeligt databasen om denne handling i sql , men selve operationen lykkedes ikke). Fordelen er, at når der oprettes et snapshot, dannes der en separat fil, og der er en "forælder", derfor kan vi i tilfælde af problemer, og selvom det ikke virker gennem gui, hente qcow2-filen og gendanne den separat
På netværk er alt desværre ikke så simpelt. Nå, det er i hvert fald nemmere end i openstack, jeg brugte kun vlan (802.1Q) - det fungerer ret godt, men hvis du laver ændringer i indstillingerne fra skabelonnetværket, så vil disse indstillinger ikke blive anvendt på allerede kørende maskiner, dvs. du skal slette og tilføje et netværkskort, så vil de nye indstillinger blive anvendt.
Hvis du stadig vil sammenligne det med openstack, kan du sige dette: i opennebula er der ingen klar definition af, hvilke teknologier der skal bruges til lagring af data, styring af netværket, ressourcer - hver administrator bestemmer selv, hvad der er mere bekvemt for ham.
6. Yderligere plugins og installationer
Når alt kommer til alt, som vi forstår det, kan cloud-platformen ikke kun styre kvm, men også vmware esxi. Jeg havde desværre ikke en pool med Vcenter, hvis nogen har prøvet, så skriv endelig.
Support til andre cloud-udbydere er oplyst
AWS, AZURE.
Jeg forsøgte også at forbinde Vmware Cloud fra Selectel, men intet virkede - generelt blev det blokeret, fordi der er mange faktorer, og det nytter ikke at skrive til den tekniske support fra hostingudbyderen.
Nu har den nye version også et fyrværkeri - dette er lanceringen af microvm, en type kvm-sele over docker, som giver endnu mere alsidighed, sikkerhed og øget produktivitet, fordi der ikke er behov for at spilde ressourcer på at emulere udstyr. Den eneste fordel, jeg ser i forhold til Docker, er, at den ikke optager et yderligere antal processer, og der er ingen besatte sockets, når du bruger denne emulering, dvs. Det er ganske muligt at bruge det som en load balancer (men det er nok værd at skrive en separat artikel om dette, indtil jeg har kørt alle testene fuldt ud).
7. Positiv oplevelse af brug og fejlfinding
Jeg ville gerne dele mine observationer om arbejdet, jeg beskrev noget af det ovenfor, jeg vil gerne skrive mere. Faktisk er jeg nok ikke den eneste, der først tror, at dette ikke er det rigtige system, og generelt er alt her en krykke - hvordan arbejder de overhovedet med dette? Men så kommer forståelsen af, at alt er ret logisk. Selvfølgelig kan du ikke behage alle, og nogle aspekter kræver forbedring.
For eksempel en simpel handling med at kopiere et diskbillede fra et datalager til et andet. I mit tilfælde er der 2 noder med nfs, jeg sender billedet - kopiering sker gennem frontend opennebula, selvom vi alle er vant til, at data skal kopieres direkte mellem værter - i samme vmware, hyper-v er vi vant til dette, men her til en anden. Der er en anden tilgang og en anden ideologi, og i version 5.12 fjernede de knappen "migrer til datalager" - kun selve maskinen overføres, men ikke lageret pga. betyder centraliseret opbevaring.
Dernæst er en populær fejl med forskellige årsager: "Fejl ved implementering af virtuel maskine: Kunne ikke oprette domæne fra /var/lib/one//datastores/103/10/deployment.5" Nedenfor er det vigtigste at se på.
- Billedrettigheder for oneadmin-brugeren;
- Tilladelser for oneadmin-brugeren til at køre libvirtd;
- Er datalageret monteret korrekt? Gå og tjek stien på selve knudepunktet, måske er der faldet noget af;
- Forkert konfigureret netværk, eller rettere på frontenden er det i netværksindstillingerne at hovedgrænsefladen for vlan er br0, men på noden skrives det som bridge0 - det skal være det samme.
systemdatalager gemmer metadata for din vm, hvis du kører vm'en med et persistent image, så skal vm'en have adgang til den oprindeligt oprettede konfiguration på lageret, hvor du oprettede vm'en - dette er meget vigtigt. Når du overfører en vm til et andet datalager, skal du derfor dobbelttjekke alt.
8. Dokumentation, fællesskab. Videre udvikling
Og resten, god dokumentation, fællesskab og hovedsagen er, at projektet fortsætter med at leve i fremtiden.
Generelt er alt ganske veldokumenteret, og selv ved at bruge en officiel kilde vil det ikke være et problem at installere og finde svar på spørgsmål.
Fællesskab, aktiv. Udgiver mange færdige løsninger, som du kan bruge i dine installationer.
I øjeblikket er nogle politikker i virksomheden ændret siden 5.12 Det bliver spændende at se, hvordan projektet udvikler sig. I starten pegede jeg specifikt på nogle af de leverandører, der bruger deres løsninger, og hvad branchen tilbyder. Der er selvfølgelig ikke noget klart svar på, hvad man skal bruge. Men for mindre organisationer er det måske ikke så dyrt at vedligeholde deres lille private sky, som det ser ud til. Det vigtigste er at vide præcis, hvad du har brug for.
Som følge heraf bør du, uanset hvad du vælger som cloud-system, ikke stoppe ved ét produkt. Hvis du har tid, er det værd at tage et kig på andre mere åbne løsninger.
Der er en god snak De hjælper aktivt og sender dig ikke til at søge efter en løsning på problemet på Google. Kom med os.
Kilde: www.habr.com