Ciao a tutti. Questo articolo è scritto per coloro che sono ancora indecisi nella scelta della piattaforma di virtualizzazione, dopo aver letto articoli come «Abbiamo installato Proxmox e va tutto alla grande, 6 anni di uptime senza alcun problema». Ma dopo aver installato una soluzione preconfezionata, ci si rende conto che ci sono delle modifiche da apportare per avere un monitoraggio più comprensibile e per controllare i backup... E poi arriva il momento in cui si capisce che si desidera qualcosa di più funzionale, o si vuole che all'interno del proprio sistema tutto sia chiaro, e non un black box, oppure si desidera utilizzare qualcosa di più di un hypervisor e una miriade di macchine virtuali. In questo articolo ci saranno alcune riflessioni e una pratica basata sulla piattaforma OpenNebula, scelta perché non è particolarmente esigente in termini di risorse e la sua architettura non è così complessa.
Dunque, come vediamo, molti fornitori di cloud operano su KVM e creano un'interfaccia esterna per gestire le macchine. È chiaro che i grandi hoster scrivono le proprie interfacce per l'infrastruttura cloud, come ad esempio YANDEX. Qualcuno utilizza OpenStack e crea un'interfaccia su questa base — SELECTEL, MAIL.RU. Ma se hai il tuo hardware e un piccolo gruppo di specialisti, di solito si sceglie qualcosa di pronto — VMware, Hyper-V, ci sono licenze gratuite e a pagamento, ma non è questo il punto. Parliamo degli entusiasti — quelli che non hanno paura di proporre e provare cose nuove, nonostante in azienda venga chiaramente fatto capire «Chi si occuperà di questo dopo di te?», «Lo deployeremo in produzione? È spaventoso.» Ma si possono testare queste soluzioni in un ambiente di test e, se piacciono a tutti, si può sollevare la questione di ulteriori sviluppi e utilizzi in ambienti più seri.
Ecco un link a una presentazione di un attivo partecipante allo sviluppo di questa piattaforma.
È possibile che in questo articolo ci sia qualche dettaglio superfluo già chiaro agli specialisti esperti, e per alcuni casi non descriverò tutto poiché simili comandi e descrizioni sono disponibili in rete. Qui condividerò solo la mia esperienza con questa piattaforma. Spero che i partecipanti attivi integreranno nei commenti ciò che si potrebbe fare meglio e quali errori ho commesso. Tutte le operazioni sono state svolte in un ambiente domestico composto da 3 PC con caratteristiche diverse. Inoltre, ho scelto di non specificare come funziona il software e come installarlo. No, parlerò solo di esperienza di amministrazione e dei problemi con cui ho dovuto confrontarmi. Forse a qualcuno questo sarà utile nella scelta.
Quindi, iniziamo. Come amministratore di sistema, sono importanti i seguenti punti, senza i quali difficilmente utilizzerò questa soluzione.
1. Ripetibilità dell'installazione
Ci sono molte istruzioni per l'installazione di OpenNebula, quindi non dovrebbero esserci problemi. Da versione a versione compaiono nuove funzionalità, che a volte non funzionano sempre al passaggio da una versione all'altra.
2. Monitoraggio
Moniteremo il nodo stesso, KVM e OpenNebula. Fortunatamente, ci sono già soluzioni pronte. Per il monitoraggio degli host Linux ci sono molte opzioni, come Zabbix o Node Exporter — ognuno può scegliere quello che preferisce — per ora definisco che il monitoraggio delle metriche di sistema (temperatura dove può essere misurata, coerenza dell'array disco), avviene tramite Zabbix, mentre per quanto riguarda le applicazioni, tramite l'esportatore in Prometheus. Ad esempio, per il monitoraggio di KVM, possiamo utilizzare il progetto e configurarlo per l'avvio tramite systemd, funziona abbastanza bene e mostra le metriche di KVM. C'è anche un dashboard 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.targetDunque, abbiamo un esportatore, ne serve un secondo per monitorare OpenNebula stessa, ho utilizzato questo
Può essere aggiunto normalmente al monitoraggio di sistema come segue.
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 inizialmente testato tramite console; se mostra ciò che è necessario (se restituisce un errore, installiamo xmlstarlet), lo copiamo in /usr/local/bin/opennebula_exporter.sh
Aggiungiamo un compito a cron ogni minuto:
*/1 * * * * (/usr/local/bin/opennebula_exporter.sh > /var/lib/opennebula_exporter/textfile_collector/opennebula.prom)Le metriche sono iniziate ad apparire, possiamo prelevarle con Prometheus e costruire grafici e creare allerta. In Grafana, possiamo creare un semplice dashboard come questo.
(si nota che qui ho fatto l'overcommit di CPU e RAM)
Per chi ama e utilizza Zabbix, c'è
Per il monitoraggio è tutto, l'importante è che esso esista. Certamente si possono anche utilizzare strumenti di monitoraggio integrati nelle macchine virtuali e scaricare i dati in un sistema di billing; qui ognuno ha la propria visione, al momento non ho ancora approfondito questa parte.
Per quanto riguarda il logging, non mi sono ancora dedicato molto a questo. Come soluzione più semplice, si potrebbe aggiungere td-agent per il parsing della directory /var/lib/one con espressioni regolari. Ad esempio, il file sunstone.log si adatta al regexp nginx e ad altri file che mostrano la cronologia delle interazioni con la piattaforma — qual è il vantaggio? Possiamo chiaramente monitorare il numero di “Error, error” e identificare più rapidamente dove e a che livello si verifica un malfunzionamento.
3. Backup
Esistono anche progetti a pagamento con funzionalità avanzate — ad esempio sep :OpenNebula_Backup. Qui dobbiamo capire che semplicemente fare il backup dell'immagine della macchina, in questo caso non è sufficiente, poiché le nostre macchine virtuali devono operare con piena integrazione (lo stesso contesto del file in cui sono descritte le impostazioni di rete, il nome della vm e le configurazioni personalizzate per le vostre applicazioni). Pertanto, dobbiamo decidere cosa e come faremo il backup. In alcuni casi, è meglio effettuare copie di ciò che si trova direttamente nella vm. E potrebbe essere necessario eseguire il backup solo di un disco di quella macchina.
Ad esempio, ci siamo accordati sul fatto che tutte le macchine vengono avviate con 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 necessario. Certo, non è proprio il metodo ideale. Volevo semplicemente mostrare che utilizzando gli strumenti di OpenNebula si possono costruire soluzioni del genere.Ho anche trovato e c'è anche , ma qui solo per il deposito qcow2.
Ma come sappiamo, prima o poi arriva il momento in cui desideriamo dei backup incrementali, qui è più complicato e probabilmente la direzione finanzierà una soluzione a pagamento, oppure si può optare per un’altra strada, consapevoli che stiamo solo gestendo le risorse, e il backup deve essere fatto a livello di applicazioni, mentre cresciamo il numero di nodi e macchine virtuali — in questo caso, dico che utilizzare il cloud solo per l'avvio di cluster di applicazioni, mentre i database vengono eseguiti su un'altra piattaforma o si utilizza un'offerta preconfezionata dal fornitore, se disponibile.
4. Facilità d'uso
In questo punto descriverò i problemi con cui mi sono trovato. Ad esempio, riguardo le immagini, come sappiamo ci sono immagini persistenti — al momento del montaggio di questa immagine sulla vm, tutti i dati vengono scritti in quell'immagine. Ma se è non persistente, l'immagine viene copiata nel deposito e i dati vengono scritti in ciò che è stato copiato dall’immagine originale — così funzionano i modelli. Spesso ho creato problemi a me stesso perché ho dimenticato di specificare persistente e 200 GB di immagine sono stati copiati, il problema è che non è possibile annullare questa procedura, è necessario andare sul nodo e arrestare attualmente il processo “cp”.
Uno degli aspetti negativi principali è che non puoi annullare l'azione semplicemente utilizzando l'interfaccia grafica. In effetti, annullerai l'azione e vedrai che non succede nulla e quindi riavvierai, annullerai, e di fatto ci saranno già 2 processi cp che stanno copiando l'immagine.
E qui si comprende perché OpenNebula assegna un nuovo ID a ogni nuova istanza, ad esempio in Proxmox ho creato una vm con ID 101, l'ho eliminata, poi la ricreo e ottengo di nuovo ID 101. In OpenNebula non si verifica questo, ogni nuova istanza verrà creata con un nuovo ID e c'è una logica in questo — ad esempio, la pulizia dei vecchi dati o delle installazioni fallite.
Lo stesso vale per lo storage; questa piattaforma è fortemente orientata verso lo storage centralizzato. Ci sono addon per usare storage locale, ma in questo caso non è il tema. Penso che in futuro qualcuno scriverà un articolo su come è riuscito a utilizzare lo storage locale sui nodi e a utilizzarlo con successo in produzione.
5. Massima semplicità
Certo, più si avanza, meno persone capiscono quello che dici.
Nel contesto del mio stand — 3 nodi con storage NFS — tutto funziona bene. Ma se esegui esperimenti di blackout, ad esempio, durante l'avvio di uno snapshot e il blackout di una nodo, le impostazioni vengono salvate nel DB, che esiste uno snapshot, ma in realtà non c'è (sappiamo tutti che inizialmente si è registrato in un database SQL tale azione, ma l'operazione stessa non è andata a buon fine). Un vantaggio è che quando viene creato uno snapshot, viene generato un file separato e c'è un 'genitore', quindi in caso di problemi, anche se tramite l'GUI non funziona, possiamo prendere il file qcow2 e ripristinare separatamente.
Purtroppo, le cose non sono così semplici nelle reti. Ma almeno è più facile rispetto a openstack, ho utilizzato solo vlan (802.1Q) — funziona perfettamente, ma se apporti modifiche nelle impostazioni della rete template, queste non verranno applicate alle macchine già attive, ovvero è necessario rimuovere e aggiungere la scheda di rete, così le nuove impostazioni verranno applicate.
Se vuoi paragonarlo ancora a openstack, si può dire che in opennebula non c'è una chiara definizione delle tecnologie da utilizzare per la memorizzazione dei dati, gestione della rete, risorse — ogni amministratore decide autonomamente come preferisce.
6. Plugin e installazioni aggiuntive
Perché come sappiamo, la piattaforma cloud può gestire non solo KVM, ma anche VMware ESXi. Purtroppo non avevo un pool con Vcenter, se qualcuno ha provato, scrivetemi.
Nella documentazione di altri fornitori di servizi cloud è dichiarato
AWS, AZURE.
Ho anche provato a integrare VMware Cloud di Selectel, ma non ci sono riuscito — in generale ho smesso di provare perché ci sono molti fattori, e non ha senso contattare il supporto tecnico del provider di hosting.
Inoltre, ora nella nuova versione c'è Firecracker — è l'avvio di microvm, una sorta di KVM avvolto sopra Docker, che offre ancora maggiore versatilità, sicurezza e aumento delle prestazioni poiché non è necessario sprecare 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, ossia può essere utilizzato come bilanciatore di carico (ma su questo sarebbe opportuno scrivere un articolo separato, visto che non ho svolto ancora tutti i test completamente).
7. Esperienza positiva e debug degli errori
Volevo condividere le mie osservazioni sul funzionamento, parte l'ho descritta sopra, vorrei scrivere di più. In effetti, probabilmente non sono l'unico a pensare inizialmente che questo non sia il sistema giusto e che sia tutto tutto un po' forzato — come si può lavorare con questo? Ma poi arriva la comprensione e tutto ha una logica. Naturalmente non si può accontentare tutti e alcuni aspetti richiedono 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 di Opennebula, mentre noi siamo abituati a pensare che i dati debbano essere copiati direttamente tra gli host — nella stessa VMware, Hyper-V ci siamo abituati a questo, ma qui è diverso. Qui c'è un approccio e un'ideologia diversi, e nella versione 5.12 è stato rimosso il pulsante "migrate to datastore" — viene spostata solo la macchina, ma non il datastore poiché si presume uno storage centralizzato.
Poi, un errore comune con varie cause "Error deploying virtual machine: Could not create domain from /var/lib/one//datastores/103/10/deployment.5". Qui di seguito ci sarà un elenco di cosa controllare.
- Permessi sull'immagine per l'utente oneadmin;
- Permessi per l'utente oneadmin per avviare libvirtd;
- È montato correttamente il datastore? Vai a controllare il percorso sul nodo stesso, potrebbe essere che qualcosa si sia scollegato;
- Rete configurata in modo errato, in altre parole, nel frontend nelle impostazioni di rete, come interfaccia principale per il vlan è impostato br0, mentre sul nodo è configurato — bridge0 — deve essere uguale.
Il datastore di sistema memorizza i metadati per la tua VM; se avvii una VM con un'immagine persistente, la VM deve avere accesso alla configurazione originariamente creata nello storage in cui hai creato la VM — questo è molto importante. Quindi, quando trasferisci la VM su un altro datastore, tutto deve essere verificato.
8. Documentazione, comunità. Ulteriore sviluppo
E altro ancora, una buona documentazione, una comunità attiva e soprattutto affinché il progetto continui a vivere.
Qui in generale, tutto è ben documentato e persino tramite la fonte ufficiale, sarà facile installare e trovare risposte alle domande.
La comunità è attiva. Pubblica molte soluzioni pronte che puoi utilizzare nelle tue installazioni.
Attualmente, con la versione 5.12 sono cambiate alcune politiche aziendali sarebbe interessante sapere come si svilupperà il progetto. All'inizio ho specificato alcuni fornitori che utilizzano le proprie soluzioni e ciò che offre l'industria. Non c'è una risposta chiara su cosa utilizzare, ovviamente. Ma per piccole organizzazioni mantenere il proprio piccolo cloud privato può non essere così costoso come sembra. L'importante è sapere esattamente che è ciò di cui hai bisogno.
In conclusione, indipendentemente da ciò che hai scelto come sistema cloud, non dovresti fermarti a un solo prodotto. Se hai tempo, vale la pena dare un'occhiata ad altre soluzioni più aperte.
C'è una buona chat aiutano attivamente e non ti mandano a cercare la soluzione su Google. Unisciti a noi.
Fonte: habr.com
