Ciao a tutti. Questo articolo è scritto per coloro che sono ancora indecisi nella scelta delle piattaforme di virtualizzazione, dopo aver letto articoli come "Abbiamo installato proxmox e va tutto alla grande, 6 anni di uptime senza una sola interruzione." Ma dopo aver installato una soluzione commerciale, sorge la domanda su come aggiornare alcune cose per avere un monitoraggio più chiaro e, qui, per controllare i backup... E poi arriva il momento in cui capite che volete qualcosa di più funzionale, o desiderate che all'interno del vostro sistema tutto sia chiaro, non un misterioso scatolone nero, oppure volete usare qualcosa di più di un hypervisor e una miriade di macchine virtuali. In questo articolo ci saranno alcune riflessioni e pratiche basate sulla piattaforma Opennebula — l'ho scelta perché non è esigente in termini di risorse e l'architettura non è così complessa.
Quindi, come possiamo vedere, molti provider cloud lavorano su KVM e creano integrazioni esterne per gestire le macchine. È chiaro che i grandi provider scrivono le proprie integrazioni per l'infrastruttura cloud, lo stesso YANDEX, ad esempio. Alcuni usano OpenStack e creano integrazioni su questa base — SELECTEL, MAIL.RU. Ma se avete il vostro hardware e un piccolo team di specialisti, di solito si opta per qualcosa di già pronto — VMWARE, HYPER-V, ci sono licenze gratuite e a pagamento, ma non stiamo parlando di questo ora. Parliamo degli appassionati — sono coloro che non hanno paura di proporre e provare nuove soluzioni, nonostante in azienda sia stato chiaramente espresso "Chi si occuperà di questo dopo di te?", "E noi lo lanceremo in produzione? È spaventoso." Ma è possibile iniziare ad applicare queste soluzioni in un ambiente di test e se a tutti piace, si può sollevare la questione di uno sviluppo e utilizzo più serio.
Ecco il link alla presentazione di un partecipante attivo allo sviluppo di questa piattaforma.
È possibile che in questo articolo ci sia qualcosa di superfluo e già chiaro per un professionista esperto, e in alcuni casi non descriverò tutto poiché comandi e descrizioni simili sono disponibili in rete. Qui condivido solo la mia esperienza con questa piattaforma. Spero che i partecipanti attivi integreranno nei commenti cosa si può fare meglio e quali errori ho commesso. Tutte le operazioni sono state effettuate in un ambiente domestico costituito da 3 PC con caratteristiche diverse. Inoltre, ho scelto di non indicare come funziona questo software e come si installa. No, solo esperienza di amministrazione e problemi che ho affrontato. Potrebbe essere utile a qualcuno nella scelta.
Bene, iniziamo. Per me, come amministratore di sistema, i seguenti punti sono importanti, senza i quali probabilmente non utilizzerò questa soluzione.
1. Ripetibilità dell'installazione
Ci sono molte istruzioni per l'installazione di opennebula, non dovrebbero sorgere problemi. Da una versione all'altra compaiono nuove funzionalità, che potrebbero non funzionare sempre durante il passaggio da una versione all'altra.
2. Monitoraggio
Monitoreremo il nodo stesso, kvm e opennebula. Fortunatamente, ci sono già soluzioni pronte. Ci sono molte opzioni per il monitoraggio degli host linux, quali zabbix o node exporter — a seconda delle preferenze attuali, definisco attualmente il monitoraggio delle metriche di sistema (temperatura dove può essere misurata, consistenza dell'array disco), tramite zabbix, e per quanto riguarda le applicazioni tramite esportatore in prometheus. Per il monitoraggio di kvm, ad esempio, si può utilizzare il progetto e configurarlo per l'avvio tramite systemd, funziona molto bene e mostra le metriche kvm, inoltre c'è un dashboard già pronto .
Ad esempio, ecco il mio file:
/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.targetQuindi abbiamo 1 esportatore, ne serve un altro per monitorare opennebula stessa, ho usato questo
Si può aggiungere al normale per monitorare il sistema il seguente.
Nel file di node_exporter cambiamo l'avvio in questo modo:
ExecStart=/usr/sbin/node_exporter --web.listen-address=":9102" --collector.textfile.directory=/var/lib/opennebula_exporter/textfile_collectorCreiamo la directory mkdir -p /var/lib/opennebula_exporter
Lo script bash presentato sopra viene prima verificato tramite console, se mostra ciò che deve (se dà errore, installiamo xmlstarlet), lo copiamo in /usr/local/bin/opennebula_exporter.sh
Aggiungiamo un compito cron per ogni minuto:
*\/1 * * * * (\/usr\/local\/bin\/opennebula_exporter.sh > \/var\/lib\/opennebula_exporter\/textfile_collector\/opennebula.prom)Le metriche hanno iniziato a comparire, si possono prelevare con Prometheus e costruire grafici e allerta. In Grafana si può ad esempio disegnare un semplice dashboard.
(si vede che qui ho fatto overcommit di cpu e ram)
Per chi ama e utilizza Zabbix, c'è
Per il monitoraggio è tutto, l'importante è che esista. Ovviamente si possono utilizzare gli strumenti di monitoraggio delle macchine virtuali e esportare i dati in fatturazione; ognuno ha la propria visione, per ora non ci ho dedicato molto tempo.
Per quanto riguarda il logging, non ci ho ancora lavorato molto. Come opzione più semplice, è possibile aggiungere td-agent per il parsing della directory \/var\/lib\/one con espressioni regolari. Ad esempio, il file sunstone.log si adatta a regexp nginx e ad altri file che mostrano la cronologia delle interazioni con la piattaforma: qual è il vantaggio? Possiamo seguire chiaramente il numero di "Error, error" e individuare più rapidamente dove e a quale livello si trova il problema.
3. Backup
Ci sono anche progetti a pagamento migliorati, come sep :OpenNebula_Backup. Qui dobbiamo capire che fare semplicemente il backup dell'immagine della macchina non è sufficiente, poiché le nostre macchine virtuali devono funzionare con un'integrazione completa (lo stesso file di contesto, in cui sono descritte le impostazioni di rete, il nome della vm e le impostazioni personalizzate per le vostre applicazioni). Quindi qui definiamo cosa e come faremo il backup. In alcuni casi è meglio fare copie di ciò che si trova nella vm stessa. E potrebbe essere necessario eseguire il backup solo di un disco di quella macchina.
Ad esempio, abbiamo stabilito che tutte le macchine partono da immagini persistenti, quindi leggendo
significa che prima possiamo esportare l'immagine dalla nostra vm:
onevm disk-saveas 74 3 prom.qcow2
Image ID: 77
Controlliamo con quale nome è stata salvata
oneimage show 77
\/var\/lib\/one\/datastores\/100\/f9503161fe180658125a9b32433bf6e8
E poi copiamo dove ci serve. Certo, è un metodo non ideale. Volevo solo mostrare che utilizzando gli strumenti di OpenNebula si possono costruire soluzioni simili.Ho anche trovato nel vasto mondo della rete e c'è anche , ma qui solo per lo storage qcow2.
Ma come sappiamo tutti, prima o poi arriva il momento in cui si desidera avere backup incrementali. Qui la situazione si complica e potrebbe essere che la direzione decida di stanziare fondi per una soluzione a pagamento, oppure si può optare per un altro approccio, comprendendo che qui stiamo solo sprecando risorse e che il backup dovrebbe essere gestito a livello di applicazioni, incrementando il numero di nodi e macchine virtuali. Dico che si dovrebbe utilizzare il cloud puramente per avviare cluster di applicazioni, mentre i database andrebbero avviati su un'altra piattaforma o utilizzati quelli forniti dal fornitore, se disponibile.
4. Facilità d'uso
In questo punto descriverò i problemi con cui mi sono trovato. Ad esempio, per le immagini, come sappiamo ci sono le persistent: quando si monta quest'immagine su una VM, tutti i dati vengono scritti in quest'immagine. Se invece è non-persistent, l'immagine viene copiata nello storage e i dati vengono scritti in ciò che è stato copiato dall'immagine originale — così funzionano i modelli di template. Spesso ho creato problemi a me stesso dimenticando di specificare persistent, e 200 GB venivano copiati; il problema è che sicuramente questa procedura non può essere annullata, bisogna accedere al nodo e terminare il processo «cp» corrente.
Uno dei grandi svantaggi è che non puoi annullare le azioni semplicemente utilizzando la GUI. O meglio, le annullerai e vedrai che non succede nulla, poi riavvierai, annullerai di nuovo e di fatto avrai già 2 processi cp che copiano l'immagine.
E qui arriva la comprensione del perché opennebula numera ogni nuova istanza con un nuovo ID; ad esempio, in proxmox ho creato una VM con ID 101, l'ho eliminata, poi la ricreo e ho di nuovo l'ID 101. In opennebula questo non accade; ogni nuova istanza verrà creata con un nuovo ID e questo ha la sua logica: ad esempio, per pulire i dati vecchi o le installazioni non riuscite.
Lo stesso vale per lo storage; questa piattaforma è più orientata verso lo storage centralizzato. Ci sono addon per utilizzare l'archiviazione locale, ma in questo caso non è di questo che stiamo parlando. Penso che in futuro qualcuno scriverà un articolo su come sia riuscito a utilizzare lo storage locale sui nodi e ad utilizzarlo con successo in produzione.
5. Massima semplicità
Certo, più ci si allontana, meno persone riusciranno a capire ciò che dici.
Nelle condizioni della mia configurazione — 3 nodi con storage NFS — tutto funziona correttamente. Ma se si effettuano esperimenti di interruzione dell'energia, ad esempio durante l'avvio di uno snapshot e l'interruzione dell'alimentazione del nodo, manteniamo le impostazioni nel database, ovvero c'è uno snapshot, ma di fatto non esiste (beh, capiamo tutti che inizialmente abbiamo registrato in un database SQL questa azione, ma l'operazione stessa è andata a buon fine). Inoltre, quando viene creato uno snapshot, viene generato un file separato e c'è un "genitore", quindi in caso di problemi e anche se non funziona tramite GUI, possiamo recuperare il file qcow2 e ripristinarlo separatamente.
Per quanto riguarda le reti, purtroppo non è tutto così semplice. Beh, per lo meno è più semplice rispetto a OpenStack; ho utilizzato solo VLAN (802.1Q) — funziona perfettamente, ma se apporti modifiche alle impostazioni nel template network, queste impostazioni non verranno applicate alle macchine già in funzione, ovvero devi rimuovere e aggiungere la scheda di rete, solo allora le nuove impostazioni verranno applicate.
Se vogliamo confrontare con OpenStack, possiamo dire così: in OpenNebula non c'è una chiara definizione di quali tecnologie utilizzare per la memorizzazione dei dati, la gestione della rete, delle risorse — ogni amministratore decide da solo come gli è più comodo.
6. Plugin e installazioni aggiuntive
Infatti, come sappiamo, la piattaforma cloud può gestire non solo KVM, ma anche VMware ESXi. Purtroppo non avevo un cluster con Vcenter, se qualcuno l'ha provato, scriva.
Nella supporto di altri fornitori di cloud è stato dichiarato
AWS, AZURE.
Ho anche provato a connettere VMware Cloud di Selectel, ma non ha funzionato — in generale ho lasciato perdere, poiché ci sono molti fattori, e scrivere al supporto tecnico del provider di hosting non ha senso.
Inoltre, ora nella nuova versione c'è Firecracker — questo avvio di microvm, tipo KVM, un'interfaccia sopra Docker, che offre ancora maggiore versatilità, sicurezza e miglioramento delle prestazioni perché non è necessario spendere risorse per l'emulazione dell'hardware. Vedo solo vantaggi rispetto a Docker in quanto non occupa un numero aggiuntivo di processi e non ci sono socket occupati durante l'uso di questa emulazione, ovvero può essere utilizzata tranquillamente come bilanciatore di carico (ma di questo probabilmente vale la pena scrivere un articolo separato, poiché non ho ancora condotto tutti i test in modo completo).
7. Esperienza positiva nell'uso e debug degli errori
Volevo condividere le mie osservazioni sul lavoro, ne ho già descritto parte sopra, ma vorrei scriverne di più. Effettivamente, probabilmente non sono l'unico a pensare inizialmente che questo non sia il sistema giusto e che tutto sia un po' traballante — come si lavora qui? Ma poi arriva la comprensione e ci si rende conto che tutto è abbastanza logico. Certo, non si può accontentare tutti e alcuni aspetti richiedono dei miglioramenti.
Ad esempio, una semplice operazione di copia di un'immagine del disco da un datastore a un altro. Nel mio caso ci sono 2 nodi con nfs, invio l'immagine — la copia avviene tramite il frontend opennebula, anche se siamo abituati al fatto che i dati debbano essere copiati direttamente tra gli host — come in vmware o hyper-v, ma qui funziona in modo diverso. Qui c'è un altro approccio e un'altra ideologia, e nella versione 5.12 è stato rimosso il bottone «migrate to datastore» — viene spostata solo la macchina stessa, ma non lo storage poiché si presuppone uno storage centralizzato.
Poi c'è un errore comune con diverse cause «Error deploying virtual machine: Could not create domain from /var/lib/one//datastores/103/10/deployment.5» Di seguito ci sarà un elenco di ciò che bisogna controllare.
- Autorizzazioni sull'immagine per l'utente oneadmin;
- Autorizzazioni per l'utente oneadmin per avviare libvirtd;
- È montato correttamente il datastore? Vai e controlla il percorso sul nodo stesso, forse qualcosa è andato perso;
- Rete configurata in modo errato, o meglio, nel frontend, nelle impostazioni di rete, è impostato che per il vlan il principale sia br0, mentre sul nodo è scritto — bridge0 — deve essere uguale.
Il datastore di sistema memorizza i metadati per la tua vm, se stai avviando la vm con un'immagine persistente, la vm deve avere accesso alla configurazione origine su quel datastore dove hai creato la vm — questo è molto importante. Pertanto, durante il trasferimento della vm su un altro datastore, devi controllare tutto.
8. Documentazione, comunità. Ulteriore sviluppo
E altro ancora, una buona documentazione, una comunità e soprattutto affinché il progetto continui a vivere.
Qui in generale, tutto è abbastanza ben documentato e anche dalle fonti ufficiali non sarà un problema installare e trovare risposte alle domande.
Comunità attiva. Pubblica molte soluzioni pronte che puoi utilizzare nelle tue installazioni.
Al momento, con la versione 5.12 sono cambiate alcune politiche in azienda Sarà interessante sapere come si svilupperà il progetto. All'inizio ho specificamente menzionato alcuni fornitori che utilizzano le proprie soluzioni e ciò che offre l'industria. Non c'è ovviamente una risposta chiara su cosa usare. Ma per piccole organizzazioni, supportare il proprio piccolo cloud privato potrebbe non costare tanto quanto sembra. L'importante è sapere esattamente che è ciò di cui hai bisogno.
In conclusione, indipendentemente da quale sistema cloud hai scelto, non fermarti a un solo prodotto. Se hai tempo, vale la pena dare un'occhiata ad altre soluzioni più aperte.
C'è un buon chat. aiutano attivamente e non ti rimandano a cercare soluzioni a problemi su Google. Unisciti a noi.
Fonte: habr.com
