Hei alle sammen. Denne artikkelen ble skrevet for de som fortsatt er dratt mellom å velge virtualiseringsplattformer og etter å ha lest artikkelen fra serien "Vi installerte proxmox og generelt er alt bra, 6 år med oppetid uten en eneste pause." Men etter å ha installert en eller annen ut-av-boksen-løsning, oppstår spørsmålet: hvordan kan jeg rette dette her, slik at overvåkingen blir mer forståelig, og her for å kontrollere sikkerhetskopier... Og så kommer tiden og du innser at du vil ha noe mer funksjonelt, eller du vil at alt inne i systemet skal bli klart, og ikke denne svarte boksen, eller du vil bruke noe mer enn en hypervisor og en haug med virtuelle maskiner. Denne artikkelen vil inneholde noen tanker og praksis basert på Opennebula-plattformen – jeg valgte den pga. det er ikke ressurskrevende og arkitekturen er ikke så kompleks.
Og så, som vi ser, jobber mange skyleverandører på kvm og lager eksterne forbindelser for å styre maskiner. Det er tydelig at store hostere skriver sine egne rammer for skyinfrastruktur, den samme YANDEX for eksempel. Noen bruker openstack og oppretter en forbindelse på dette grunnlaget - SELECTEL, MAIL.RU. Men hvis du har din egen maskinvare og en liten stab av spesialister, velger du vanligvis noe ferdig - VMWARE, HYPER-V, det er gratis og betalte lisenser, men det er ikke det vi snakker om nå. La oss snakke om entusiaster - dette er de som ikke er redde for å tilby og prøve noe nytt, til tross for at selskapet tydelig gjorde det klart, "Hvem skal betjene dette etter deg," "Skal vi rulle dette ut i produksjon senere ? Skummelt." Men du kan først bruke disse løsningene i en testbenk, og hvis alle liker det, så kan du reise spørsmålet om videreutvikling og bruk i mer seriøse miljøer.
Her er også en lenke til rapporten fra en aktiv deltaker i utviklingen av denne plattformen.
Kanskje i denne artikkelen vil noe være overflødig og allerede forståelig for en erfaren spesialist, og i noen tilfeller vil jeg ikke beskrive alt fordi lignende kommandoer og beskrivelser er tilgjengelige på Internett. Dette er bare min erfaring med denne plattformen. Jeg håper at aktive deltakere vil legge til i kommentarfeltet hva som kan gjøres bedre og hvilke feil jeg gjorde. Alle handlinger fant sted i en hjemmestand bestående av 3 PC-er med ulike egenskaper. Jeg har heller ikke spesifikt angitt hvordan denne programvaren fungerer og hvordan du installerer den. Nei, bare administrasjonserfaring og problemene jeg møtte. Kanskje dette vil være nyttig for noen i deres valg.
Så la oss komme i gang. Som systemadministrator er følgende punkter viktige for meg, uten hvilke jeg neppe kommer til å bruke denne løsningen.
1. Repeterbarhet for installasjon
Det er mange instruksjoner for å installere opennebula, det burde ikke være noen problemer. Fra versjon til versjon dukker det opp nye funksjoner som ikke alltid vil fungere når du går fra versjon til versjon.
2. Overvåking
Vi skal overvåke selve noden, kvm og åpen nebula. Heldigvis er den allerede klar. Det er mange alternativer for å overvåke Linux-verter, den samme Zabbix- eller node-eksportøren - hvem som liker hva bedre - for øyeblikket definerer jeg det som overvåkingssystemmålinger (temperatur der det kan måles, konsistens til diskarrayen), gjennom zabbix , og når det gjelder søknader gjennom Prometheus-eksportøren. For kvm-overvåking kan du for eksempel ta prosjektet og sett den til å kjøre via systemd, den fungerer ganske bra og viser kvm-metrikk, det er også et ferdig dashbord .
For eksempel, her er filen min:
/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 trenger en annen for å overvåke åpen nebula selv, jeg brukte denne
Kan legges til normal for å overvåke systemet følgende.
I node_exporter-filen endrer vi starten slik:
ExecStart=/usr/sbin/node_exporter --web.listen-address=":9102" --collector.textfile.directory=/var/lib/opennebula_exporter/textfile_collectorOpprett en katalog mkdir -p /var/lib/opennebula_exporter
bash script presentert ovenfor, først sjekker vi arbeidet gjennom konsollen, hvis det viser det vi trenger (hvis det gir en feil, installer deretter xmlstarlet), kopier det til /usr/local/bin/opennebula_exporter.sh
Legg til en cron-oppgave for hvert minutt:
*/1 * * * * (/usr/local/bin/opennebula_exporter.sh > /var/lib/opennebula_exporter/textfile_collector/opennebula.prom)Beregninger begynte å dukke opp, du kan ta dem som en prometheus og bygge grafer og lage varsler. I Grafana kan du tegne for eksempel et så enkelt dashbord.
(det er tydelig at her overcommitter jeg cpu, ram)
For de som elsker og bruker Zabbix, finnes det
Når det gjelder overvåking, er hovedsaken at den er der. Selvfølgelig kan du i tillegg bruke de innebygde overvåkingsverktøyene for virtuelle maskiner og laste opp data til fakturering, her har alle sin egen visjon, jeg har ikke begynt å jobbe nærmere med dette ennå.
Jeg har egentlig ikke begynt å logge enda. Det enkleste alternativet er å legge til td-agent for å analysere /var/lib/one-katalogen med regulære uttrykk. Sunstone.log-filen samsvarer for eksempel med nginx regexp og andre filer som viser historikken for tilgang til plattformen - hva er fordelen med dette? Vel, for eksempel kan vi eksplisitt spore antallet "Feil, feil" og raskt spore hvor og på hvilket nivå det er en feil.
3. Sikkerhetskopier
Det er også betalt gjennomførte prosjekter - for eksempel sep :OpenNebula_Backup. Her må vi forstå at bare sikkerhetskopiering av et maskinbilde ikke er det samme i dette tilfellet, fordi våre virtuelle maskiner må fungere med full integrasjon (den samme kontekstfilen som beskriver nettverksinnstillingene, vm-navnet og tilpassede innstillinger for applikasjonene dine) . Derfor bestemmer vi her hva og hvordan vi skal sikkerhetskopiere. I noen tilfeller er det bedre å lage kopier av det som er i selve vm. Og kanskje du bare trenger å sikkerhetskopiere én disk fra en gitt maskin.
For eksempel bestemte vi at alle maskiner starter med vedvarende bilder, derfor etter lesing
Dette betyr at vi først kan laste opp bildet fra vår vm:
onevm disk-saveas 74 3 prom.qcow2
Image ID: 77
Смотрим, под каким именем он сохранился
oneimage show 77
/var/lib/one//datastores/100/f9503161fe180658125a9b32433bf6e8
И далее копируем куда нам необходимо. Конечно, так себе способ. Просто хотел показать, что используя инструменты opennebula можно строить подобные решения.Jeg fant også på Internett og det er mer , men det er bare lagringsplass for qcow2.
Men som vi alle vet, før eller siden kommer det en tid når du vil ha inkrementelle sikkerhetskopier, det er vanskeligere her og kanskje ledelsen vil bevilge penger til en betalt løsning, eller gå den andre veien og forstå at her kutter vi bare ressurser, og lage sikkerhetskopier på applikasjonsnivå og legge til en rekke nye noder og virtuelle maskiner - ja, her, jeg sier at det å bruke skyen utelukkende for å starte applikasjonsklynger, og starte databasen på en annen plattform eller ta en ferdig fra leverandøren, hvis mulig.
4. Brukervennlighet
I dette avsnittet vil jeg beskrive problemene jeg møtte. For eksempel, ifølge bilder, som vi vet, er det vedvarende - når dette bildet er montert til en vm, blir alle data skrevet til dette bildet. Og hvis det ikke er vedvarende, kopieres bildet til lagringen og dataene skrives til det som ble kopiert fra kildebildet - slik fungerer malmaler. Jeg forårsaket gjentatte ganger problemer for meg selv ved å glemme å spesifisere vedvarende og 200 GB-bildet ble kopiert, problemet er at denne prosedyren absolutt ikke kan kanselleres, du må gå til noden og drepe den nåværende "cp" -prosessen.
En av de viktige ulempene er at du ikke kan avbryte handlinger bare ved å bruke gui. Eller rettere sagt, du vil avbryte dem og se at ingenting skjer og du vil starte dem på nytt, avbryte dem og faktisk vil det allerede være 2 cp-prosesser som kopierer bildet.
Og så kommer det til å forstå hvorfor opennebula nummererer hver ny forekomst med en ny id, for eksempel i samme proxmox opprettet en vm med id 101, slettet den, så opprettet den igjen og id 101. I opennebula vil dette ikke skje, hver ny instans vil bli opprettet med en ny id og denne har sin egen logikk - for eksempel sletting av gamle data eller mislykkede installasjoner.
Det samme gjelder lagring; mest av alt er denne plattformen rettet mot sentralisert lagring. Det er tillegg for å bruke lokalt, men det er ikke det vi snakker om i dette tilfellet. Jeg tror at noen i fremtiden vil skrive en artikkel om hvordan de klarte å bruke lokal lagring på noder og vellykket bruke den i produksjon.
5. Maksimal enkelhet
Jo lenger du går, jo færre blir de som vil forstå deg.
Under forholdene til standen min - 3 noder med nfs-lagring - fungerer alt bra. Men hvis vi utfører eksperimenter som involverer strømbrudd, for eksempel når vi kjører et øyeblikksbilde og slår av strømmen til noden, lagrer vi innstillinger i databasen om at det er et øyeblikksbilde, men det er faktisk ingen (vel, vi forstår alle at vi skrev opprinnelig databasen om denne handlingen i sql , men selve operasjonen var ikke vellykket). Fordelen er at når du oppretter et øyeblikksbilde, dannes det en egen fil og det er en "forelder", derfor i tilfelle problemer og selv om det ikke fungerer gjennom gui, kan vi plukke opp qcow2-filen og gjenopprette den separat
På nettverk er dessverre ikke alt så enkelt. Vel, det er i hvert fall enklere enn i openstack, jeg brukte kun vlan (802.1Q) - det fungerer ganske bra, men hvis du gjør endringer i innstillingene fra malnettverket, så vil ikke disse innstillingene bli brukt på allerede kjørende maskiner, dvs. du må slette og legge til et nettverkskort, så vil de nye innstillingene bli brukt.
Hvis du fortsatt vil sammenligne det med openstack, kan du si dette: i opennebula er det ingen klar definisjon av hvilke teknologier som skal brukes til å lagre data, administrere nettverket, ressurser - hver administrator bestemmer selv hva som er mer praktisk for ham.
6. Ytterligere plugins og installasjoner
Tross alt, slik vi forstår det, kan skyplattformen administrere ikke bare kvm, men også vmware esxi. Dessverre hadde jeg ikke basseng med Vcenter, hvis noen har prøvd, vennligst skriv.
Støtte for andre skyleverandører er oppgitt
AWS, AZURE.
Jeg prøvde også å koble til Vmware Cloud fra Selectel, men ingenting fungerte - generelt ble det blokkert fordi det er mange faktorer, og det er ingen vits å skrive til den tekniske støtten til vertsleverandøren.
Nå har også den nye versjonen fyrverkeri - dette er lanseringen av microvm, en type kvm-sele over docker, som gir enda mer allsidighet, sikkerhet og økt produktivitet fordi det ikke er behov for å kaste bort ressurser på å emulere utstyr. Den eneste fordelen jeg ser fremfor Docker er at den ikke tar opp et ekstra antall prosesser og det er ingen okkuperte stikkontakter når du bruker denne emuleringen, dvs. Det er fullt mulig å bruke det som en lastbalanser (men det er nok verdt å skrive en egen artikkel om dette før jeg har fullført alle testene).
7. Positiv opplevelse av bruk og feilsøking
Jeg ønsket å dele mine observasjoner om arbeidet, jeg beskrev noe av det ovenfor, jeg vil gjerne skrive mer. Faktisk er jeg sannsynligvis ikke den eneste som først tror at dette ikke er det riktige systemet, og generelt er alt her en krykke - hvordan jobber de med dette? Men så kommer forståelsen av at alt er ganske logisk. Selvfølgelig kan du ikke glede alle, og noen aspekter krever forbedring.
For eksempel, en enkel operasjon med å kopiere et diskbilde fra ett datalager til et annet. I mitt tilfelle er det 2 noder med nfs, jeg sender bildet - kopiering skjer gjennom frontend opennebula, selv om vi alle er vant til at data skal kopieres direkte mellom verter - i samme vmware, hyper-v vi er vant til dette, men her til en annen. Det er en annen tilnærming og en annen ideologi, og i versjon 5.12 fjernet de knappen "migrer til datalager" - bare selve maskinen overføres, men ikke lagringen fordi betyr sentralisert lagring.
Neste er en populær feil med ulike årsaker: "Feil ved distribusjon av virtuell maskin: Kunne ikke opprette domene fra /var/lib/one//datastores/103/10/deployment.5" Nedenfor er det viktigste å se på.
- Bilderettigheter for oneadmin-brukeren;
- Tillatelser for oneadmin-brukeren til å kjøre libvirtd;
- Er datalageret riktig montert? Gå og sjekk banen på selve noden, kanskje noe har falt av;
- Feilkonfigurert nettverk, eller rettere sagt på frontend det er i nettverksinnstillingene at hovedgrensesnittet for vlan er br0, men på noden skrives det som bridge0 - det må være det samme.
systemdatalageret lagrer metadata for vm-en din, hvis du kjører vm-en med et vedvarende bilde, må vm-en ha tilgang til den opprinnelig opprettede konfigurasjonen på lagringen der du opprettet vm-en - dette er veldig viktig. Derfor, når du overfører en vm til et annet datalager, må du dobbeltsjekke alt.
8. Dokumentasjon, fellesskap. Videre utvikling
Og resten, god dokumentasjon, fellesskap og hovedsaken er at prosjektet fortsetter å leve i fremtiden.
Generelt er alt ganske godt dokumentert, og selv ved å bruke en offisiell kilde vil det ikke være noe problem å installere og finne svar på spørsmål.
Fellesskap, aktiv. Publiserer mange ferdige løsninger som du kan bruke i dine installasjoner.
For øyeblikket har noen retningslinjer i selskapet endret seg siden 5.12 Det blir spennende å se hvordan prosjektet utvikler seg. I begynnelsen pekte jeg spesifikt ut noen av leverandørene som bruker deres løsninger og hva bransjen tilbyr. Selvfølgelig er det ikke noe klart svar på hva du skal bruke. Men for mindre organisasjoner er det kanskje ikke så dyrt å vedlikeholde den lille private skyen som det ser ut til. Det viktigste er å vite nøyaktig hva du trenger.
Som et resultat, uansett hva du velger som skysystem, bør du ikke stoppe ved ett produkt. Hvis du har tid, er det verdt å ta en titt på andre mer åpne løsninger.
Det er en god prat De hjelper aktivt og sender deg ikke for å søke etter en løsning på problemet på Google. Bli med oss.
Kilde: www.habr.com