Introduzione
Progetto open source — una piattaforma di virtualizzazione gratuita a livello aziendale. Dopo aver sfogliato habr, l'ho scoperto non è trattato qui così ampiamente come meriterebbe.
oVirt è in realtà un upstream del sistema commerciale Red Hat Virtualization (RHV, precedentemente RHEV), che cresce sotto l'ala protettrice di Red Hat. Per evitare confusione, questo no come CentOS vs RHEL, modello più vicino a Fedora vs RHEL.
Sotto il cappuccio - , per la gestione viene utilizzata un'interfaccia web. Basato sul sistema operativo RHEL/CentOS 7.
oVirt può essere utilizzato sia per la virtualizzazione server “tradizionale” che per la virtualizzazione desktop (VDI), a differenza della soluzione VMware, entrambi i sistemi possono coesistere in un unico complesso.
Il progetto è buono , ha da tempo raggiunto la maturità per l'uso produttivo ed è pronto per carichi elevati.
Questo articolo è il primo di una serie su come creare un cluster di failover funzionante. Dopo averli esaminati, in breve tempo (circa 2 ore) otterremo un sistema completamente funzionante, anche se ovviamente non verranno svelate alcune problematiche; cercherò di trattarle nei prossimi articoli.
Lo utilizziamo da diversi anni, a partire dalla versione 4.1. Il nostro sistema industriale attualmente funziona su computer HPE Synergy 480 e ProLiant BL460c di decima generazione con CPU Xeon Gold.
Al momento in cui scrivo, la versione attuale è la 4.3.
Articoli
- Introduzione (Noi siamo qui)
Funzionalità
Ci sono 2 entità principali in oVirt: ovirt-engine e ovirt-host(s). Per coloro che hanno familiarità con i prodotti VMware, oVirt nel suo insieme come piattaforma è vSphere, ovirt-engine - il livello di controllo - esegue le stesse funzioni di vCenter e ovirt-host è un hypervisor, come ESX (i). Perché vSphere è una soluzione molto popolare, a volte la confronterò con essa.
Riso. 1 — oPannello di controllo Virt.
La maggior parte delle distribuzioni Linux e delle versioni di Windows sono supportate come macchine guest. Per le macchine guest sono disponibili agenti, dispositivi virtuali ottimizzati e driver virtio, principalmente il controller del disco e l'interfaccia di rete.
Per implementare una soluzione tollerante agli errori e tutte le funzionalità interessanti, avrai bisogno di uno spazio di archiviazione condiviso. Sono supportati entrambi gli archivi di file FC a blocchi, FCoE, iSCSI e NFS, ecc.. Per implementare una soluzione tollerante agli errori, anche il sistema di archiviazione deve essere tollerante agli errori (almeno 2 controller, multipassing).
È possibile utilizzare l'archiviazione locale, ma per impostazione predefinita solo gli archivi condivisi sono adatti per un cluster reale. L'archiviazione locale rende il sistema un insieme disparato di hypervisor e, anche con l'archiviazione condivisa, non è possibile assemblare un cluster. Il modo più corretto sono macchine diskless con avvio da SAN o dischi di dimensioni minime. Probabilmente, tramite l'hook vdsm, è possibile l'opzione di assemblare Software Defined Storage da dischi locali (ad esempio Ceph) e presentarlo ad una VM, ma non l'ho presa seriamente in considerazione.
Architettura
Riso. 2 - Architettura oVirt.
Maggiori dettagli sull'architettura possono essere trovati in sviluppatore.
Riso. 3 — Oggetti oVirt.
L'elemento più alto nella gerarchia è - Banca dati. Determina se viene utilizzata l'archiviazione condivisa o locale, nonché il set di funzionalità utilizzato (compatibilità, da 4.1 a 4.3). Potrebbero essercene uno o più. Per molte opzioni, è adatto l'utilizzo del Data Center predefinito - Default.
Il Data Center è costituito da uno o più Cluster. Il cluster determina il tipo di processore, le politiche di migrazione, ecc. Per piccole installazioni, puoi anche limitarti al cluster predefinito.
Il cluster, a sua volta, è composto da ospiteSono quelli che svolgono il lavoro principale: trasportano macchine virtuali, lo spazio di archiviazione è collegato ad esse. Un cluster presuppone 2 o più host. Sebbene sia tecnicamente possibile creare un cluster con 1 host, non ha alcuna utilità pratica.
oVirt supporta molte funzioni, incl. migrazione live di macchine virtuali tra hypervisor (live migrazione) e migrazione storage (storage migrazione), virtualizzazione desktop (infrastruttura desktop virtuale) con pool di macchine virtuali, macchine virtuali statefull e stateless, supporto per NVidia Grid vGPU, importazione da vSphere, KVM, è disponibile una potente e altro ancora. Tutte queste funzionalità sono disponibili senza royalty e, se necessario, è possibile acquistarlo da Red Hat tramite i partner regionali.
Informazioni sui prezzi RHV
Il costo non è elevato rispetto a VMware, viene acquistato solo il supporto, senza l'obbligo di acquistare la licenza stessa. Il supporto si acquista solo per gli hypervisor; ovirt-engine, a differenza di vCenter Server, non prevede alcuna spesa.
Esempio di calcolo per il 1° anno di proprietà
Consideriamo un cluster di 4 macchine a 2 prese e prezzi al dettaglio (senza sconti di progetto).
Abbonamento RHV standard per socket/anno (premium 365/24/7 — $ 1499), totale 4*2*$ 999=$7992.
:
- VMware vCenter Server Standard $ 10,837.13 per istanza, più abbonamento Basic $ 2,625.41 (Produzione - $ 3,125.39);
- VMware vSphere Standard $ 1,164.15 + Abbonamento Basic $ 552.61 (Produzione $ 653.82);
- VMware vSphere Enterprise Plus $ 6,309.23 + Abbonamento Basic $ 1,261.09 (produzione $ 1,499.94).
Totale: 10 + 837,13 + 2 * 625,41 * (4 + 2) = $ 27 196,62 per l'opzione più giovane. La differenza è di circa 3,5 volte!
In oVirt tutte le funzioni sono disponibili senza restrizioni.
Caratteristiche brevi e massimi
Requisiti di sistema
L'hypervisor richiede una CPU con virtualizzazione hardware abilitata, la quantità minima di RAM per l'avvio è 2 GiB, la quantità di spazio di archiviazione consigliata per il sistema operativo è 55 GiB (principalmente per i registri, ecc., il sistema operativo stesso occupa poco).
Più dettagli - .
per requisiti minimi 2 core/4 GiB RAM/25 GiB storage. Consigliato: da 4 core/16 GiB di RAM/50 GiB di spazio di archiviazione.
Come con qualsiasi sistema, esistono limitazioni su volumi e quantità, la maggior parte delle quali supera le capacità dei server commerciali di massa disponibili. Sì, coppia può indirizzare 2 TiB di RAM e fornisce 40 core (80 thread), che è inferiore anche ai limiti di una singola VM.
Massimi della macchina virtuale:
- Numero massimo di macchine virtuali in esecuzione contemporaneamente: Illimitato;
- Numero massimo di CPU virtuali per macchina virtuale: 384;
- Memoria massima per macchina virtuale: 4 TiB;
- Dimensione massima del singolo disco per macchina virtuale: 8 TiB.
Massimi host:
- Core o thread logici della CPU: 768;
- RAM: 12 TiB;
- Numero di macchine virtuali ospitate: 250;
- Migrazioni live simultanee: 2 in entrata, 2 in uscita;
- Larghezza di banda della migrazione in tempo reale: impostazione predefinita su 52 MiB (~436 Mb) per migrazione quando si utilizza la policy di migrazione legacy. Altre policy utilizzano valori di throughput adattivi basati sulla velocità del dispositivo fisico. Le policy QoS possono limitare la larghezza di banda di migrazione.
Massimi entità logiche del manager:
Nella 4.3 ci sono .
- Banca dati
- Numero massimo di data center: 400;
- Numero massimo di host: 400 supportati, 500 testati;
- Conteggio massimo di VM: 4000 supportate, 5000 testate;
- Cluster
- Conteggio massimo dei cluster: 400;
- Numero massimo di host: 400 supportati, 500 testati;
- Conteggio massimo di VM: 4000 supportate, 5000 testate;
- Network NetPoulSafe
- Reti logiche/cluster: 300;
- Reti SDN/esterne: 2600 testate, nessun limite imposto;
- Archiviazione
- Domini massimi: 50 supportati, 70 testati;
- Host per dominio: nessun limite;
- Volumi logici per dominio blocco (più): 1500;
- Numero massimo di LUN (più): 300;
- Dimensione massima del disco: 500 TiB (limitato a 8 TiB per impostazione predefinita).
Opzioni di implementazione
Come già accennato, oVirt è costituito da 2 elementi base: ovirt-engine (controllo) e ovirt-host (hypervisor).
Il motore può essere posizionato all'esterno della piattaforma stessa (gestore autonomo: può trattarsi di una VM in esecuzione su un'altra piattaforma o di un hypervisor separato o anche di una macchina fisica) o sulla piattaforma stessa (motore self-hosted, simile all'approccio VCSA) da VMware).
L'hypervisor può essere installato su entrambi (EL Host) e così via (oVirt-Node, basato su el7).
I requisiti hardware per tutte le opzioni sono più o meno gli stessi.
Riso. 4 - architettura standard.
Riso. 5 - Architettura del motore self-hosted.
Per quanto mi riguarda ho scelto l'opzione Manager autonomo ed EL Host:
- il Manager autonomo è un po' più semplice quando si tratta di problemi di avvio, non c'è il dilemma dell'uovo e della gallina (come con VCSA - non puoi avviare finché almeno un host non è completamente attivo), ma c'è una dipendenza da un altro sistema*;
- EL Host fornisce tutta la potenza del sistema operativo, utile per il monitoraggio esterno, il debug, la risoluzione dei problemi, ecc.
*Tuttavia durante l'intero periodo di funzionamento ciò non è stato necessario, anche dopo una grave interruzione di corrente.
Ma veniamo al dunque!
Per la sperimentazione, è possibile rilasciare una coppia di blade ProLiant BL460c G7 con una CPU Xeon®. Li useremo per riprodurre il processo di installazione.
Diamo ai nodi i nomi ovirt.lab.example.com, kvm01.lab.example.com e kvm02.lab.example.com.
Andiamo direttamente a .
Fonte: habr.com