Introduzione
Progetto open source è una piattaforma di virtualizzazione di livello enterprise gratuita. Scorrendo su Habr, ho scoperto che non è così ampiamente trattato come meriterebbe.
oVirt è infatti l'upstream per il sistema commerciale Red Hat Virtualization (RHV, precedentemente RHEV), in crescita sotto l'ala di Red Hat. Per evitare confusione, è non lo stesso paragone tra CentOS e RHEL, il modello è più simile a Fedora rispetto a RHEL.
Sotto il cofano — , per la gestione si utilizza un'interfaccia web. Si basa su 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 nello stesso ambiente.
Il progetto è ben , ha raggiunto da tempo la maturità per un'applicazione produttiva ed è pronto per carichi elevati.
Questo articolo è il primo di una serie su come costruire un cluster altamente disponibile. Seguendo queste indicazioni, in breve tempo (circa 2 ore) otterremo un sistema completamente funzionante, anche se alcuni temi, ovviamente, non potranno essere esplorati in dettaglio; cercherò di trattarli nei prossimi articoli.
Lo utilizziamo da diversi anni, partendo dalla versione 4.1. Attualmente il nostro sistema industriale è ospitato su HPE Synergy 480 e ProLiant BL460c di decima generazione con CPU Xeon Gold.
Al momento della scrittura, la versione attuale è la 4.3.
Articoli
- Introduzione (Siamo qui)
Caratteristiche funzionali
In oVirt ci sono 2 entità principali: ovirt-engine e ovirt-host(s). Per chi è ben familiarizzato con i prodotti VMware, oVirt, nel suo complesso, è come vSphere, l'ovirt-engine — il layer di gestione — svolge funzioni simili a vCenter, mentre l'ovirt-host funge da hypervisor, come ESX(i). Poiché vSphere è una soluzione molto popolare, a volte farò un confronto con essa.
Fig. 1 — pannello di controllo oVirt.
La maggior parte delle distribuzioni Linux e delle versioni di Windows è supportata come macchine guest. Per le macchine guest ci sono agenti e dispositivi virtuali e driver virtio ottimizzati, in particolare il controller di disco e l'interfaccia di rete.
Per implementare una soluzione ad alta disponibilità e tutte le funzionalità interessanti sarà necessario uno storage condiviso. Sono supportati storage sia a blocchi FC, FCoE, iSCSI, sia storage file NFS e altri. Per implementare una soluzione ad alta disponibilità, il sistema di storage deve essere anch'esso ad alta disponibilità (almeno 2 controller, multipathing).
L'uso di storage locali è possibile, ma per un reale cluster sono adatte solo le soluzioni di storage condiviso. Gli storage locali rendono la sistemi un insieme disomogeneo di hypervisor e anche se è presente uno storage condiviso, non sarà possibile assemblare un cluster. Il percorso più corretto è l'uso di macchine senza disco con boot from SAN, oppure dischi di volume minimo. È probabile che tramite un vdsm hook sia possibile assemblare storage definiti dal software (ad es. Ceph) usando dischi locali e presentarli a VM, ma non l'ho esaminato seriamente.
Architettura
Fig. 2 — architettura oVirt.
Per ulteriori dettagli sull'architettura, puoi consultare il sviluppatore.
Fig. 3 — oggetti oVirt.
L'elemento superiore nella gerarchia — Centro dati. Determina se vengono utilizzati archivi condivisi (shared) o locali, oltre al set di funzionalità utilizzato (compatibilità, da 4.1 a 4.3). Può esserci uno o più archivi. Per molte opzioni, può essere utilizzato il Data Center predefinito — Default.
Il Data Center consiste in uno o più Cluster. Un cluster definisce il tipo di processore, le politiche di migrazione e altro. Per installazioni di piccole dimensioni, si può anche limitare a un cluster predefinito.
Un cluster, a sua volta, è composto da Hostche svolgono il lavoro principale — ospitano macchine virtuali e sono collegate agli archivi. In un cluster è previsto un numero di 2 o più host. Anche se tecnicamente è possibile avere un cluster con un solo host, non ha un’utilità pratica.
In oVirt sono supportate molte funzionalità, tra cui la migrazione in tempo reale delle macchine virtuali tra hypervisor (live migration) e archivi (storage migration), virtualizzazione desktop (virtual desktop infrastructure) con pool di VM, VM statefull e stateless, supporto per NVidia Grid vGPU, importazione da vSphere, KVM, e offre potenti e molto altro. Tutte queste funzionalità sono disponibili senza costi di licenza, mentre il supporto può essere acquistato da Red Hat tramite partner regionali.
Informazioni sui prezzi di RHV
Il costo non è elevato rispetto a VMware, si acquista solo il supporto — senza obbligo di acquistare la licenza stessa. Il supporto è disponibile solo per gli hypervisor e ovirt-engine, a differenza di vCenter Server che non comporta spese.
Esempio di calcolo per il primo anno di utilizzo
Consideriamo un cluster di 4 macchine a 2 socket e i prezzi al dettaglio (senza sconti di progetto).
Abbonamento standard RHV 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 * (1,164.15 + 552.61) = $27 196,62 per la variante più economica. La differenza è di circa 3,5 volte!
In oVirt, tutte le funzionalità sono disponibili senza limitazioni.
Caratteristiche e massimi
Requisiti di sistema
Per l'hypervisor è richiesto un CPU con virtualizzazione hardware abilitata, la memoria RAM minima per l'avvio è di 2 GiB, la capacità di archiviazione raccomandata per il sistema operativo è di 55 GiB (per lo più per registri e simili, il sistema operativo occupa poco spazio).
Maggiori informazioni — .
Per requisiti minimi 2 core/4 GiB RAM/25 GiB di spazio di archiviazione. Raccomandati: almeno 4 core/16 GiB di RAM/50 GiB di archiviazione.
Come in qualsiasi sistema, ci sono restrizioni sui volumi e sulle quantità, la maggior parte delle quali supera le capacità dei server commerciali di massa disponibili. Ad esempio, una coppia può indirizzare 2 TiB di RAM e offre 40 core (80 thread), che è persino inferiore ai limiti di una VM.
Massimi delle macchine virtuali:
- 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 disco singolo per macchina virtuale: 8 TiB.
Massimi degli host:
- Nuclei o thread della CPU logici: 768;
- RAM: 12 TiB;
- Numero di macchine virtuali ospitate: 250;
- Migrazioni live simultanee: 2 in entrata, 2 in uscita;
- Larghezza di banda della migrazione live: Predefinita a 52 MiB (~436 Mb) per migrazione utilizzando la politica di migrazione legacy. Altre politiche utilizzano valori di throughput adattivi basati sulla velocità del dispositivo fisico. Le politiche QoS possono limitare la larghezza di banda di migrazione.
Massimi delle entità logiche del manager:
In 4.3 ci sono .
- Centro dati
- Numero massimo di centri dati: 400;
- Numero massimo di host: 400 supportati, 500 testati;
- Numero massimo di VM: 4000 supportate, 5000 testate;
- Cluster
- Numero massimo di cluster: 400;
- Numero massimo di host: 400 supportati, 500 testati;
- Numero massimo di VM: 4000 supportate, 5000 testate;
- Network log /dev/log local0 log /dev/log local1 notice chroot /var/lib/haproxy stats timeout 30s user haproxy group haproxy daemondefaults log global mode http option httplog option dontlognull timeout connect 5000 timeout client 50000 timeout server 50000frontend http_front bind *:80 stats uri /haproxy?stats default_backend http_backbackend http_back balance roundrobin server server_name1 private_ip1:80 check server server_name2 private_ip2:80 check
- Reti logiche/cluster: 300;
- Reti SDN/esterne: 2600 testate, nessun limite previsto;
- Storage
- Massimo domini: 50 supportati, 70 testati;
- Host per dominio: Nessun limite;
- Volume logici per dominio a blocchi (di più): 1500;
- Numero massimo di LUN (di più): 300;
- Dimensione massima del disco: 500 TiB (limitata a 8 TiB per impostazione predefinita).
Opzioni di implementazione
Come già detto, oVirt si basa su due componenti fondamentali: ovirt-engine (gestione) e ovirt-host (hypervisor).
L'Engine può essere ospitato sia al di fuori della piattaforma stessa (standalone Manager — può essere una VM eseguita su un'altra piattaforma, su un hypervisor separato o anche su una macchina fisica) sia sulla piattaforma stessa (self-hosted engine, simile all'approccio VCSA di VMware).
L'hypervisor può essere installato su (EL Host), o su (oVirt-Node, basato su el7).
I requisiti hardware per tutte le opzioni sono sostanzialmente gli stessi.
Fig. 4 — architettura standard.
Fig. 5 — architettura del Self-hosted Engine.
Ho scelto la soluzione standalone Manager e EL Hosts:
- lo standalone Manager è leggermente più semplice in caso di problemi di avvio, non c'è il dilemma dell'uovo e della gallina (come per VCSA — non si avvia finché non è completamente avviato almeno un host), ma si crea una dipendenza da un altro sistema*;
- EL Host offre tutta la potenza del sistema operativo, utile per il monitoraggio esterno, il debug, la ricerca di guasti, ecc.
* Tuttavia, in tutto il tempo di utilizzo, ciò non si è mai rivelato necessario, nemmeno dopo un grave guasto di alimentazione.
Ma veniamo al dunque!
Per l'esperimento, abbiamo la possibilità di liberare un paio di lame ProLiant BL460c G7 con CPU Xeon®. Su di esse procederemo con il processo di installazione.
Assegneremo i nomi ovirt.lab.example.com, kvm01.lab.example.com e kvm02.lab.example.com ai nodi.
Passiamo direttamente a .
Fonte: habr.com
