Introduzione
Progetto open source — una piattaforma di virtualizzazione di livello enterprise. Scorrendo Habr, ho scoperto che non è trattato qui così ampiamente come meriterebbe.
oVirt è in effetti l'upstream per il sistema commerciale Red Hat Virtualization (RHV, precedentemente RHEV), che cresce sotto l'ala di Red Hat. Per evitare confusione, questo non è lo stesso di CentOS vs RHEL, il modello è simile a Fedora vs RHEL.
Sotto il cofano — , la gestione avviene tramite un'interfaccia web. Basato su RHEL/CentOS 7.
oVirt può essere utilizzato sia per la virtualizzazione server "tradizionale" che desktop (VDI), a differenza della soluzione VMware, i due sistemi possono coesistere nello stesso ambiente.
Il progetto è ben , ha raggiunto da tempo la maturità per usi produttivi ed è pronto per carichi elevati.
Questo articolo è il primo di un ciclo su come costruire un cluster resiliente. Seguendoli, in breve tempo (circa 2 ore) otterremo un sistema completamente funzionante, anche se non riusciremo a trattare una serie di questioni, cercherò di affrontarle nei prossimi articoli.
Lo utilizziamo da qualche anno, partendo dalla versione 4.1. Il nostro sistema industriale è attualmente in esecuzione su calcolatori HPE Synergy 480 e ProLiant BL460c di decima generazione con CPU Xeon Gold.
Al momento della scrittura, la versione attiva è 4.3.
Articoli
- Introduzione (Siamo qui)
Caratteristiche funzionali
In oVirt ci sono 2 entità principali: ovirt-engine e ovirt-host(s). Per coloro che conoscono bene i prodotti VMware, oVirt come piattaforma è fondamentalmente vSphere, ovirt-engine — il layer di gestione — svolge le stesse funzioni di vCenter, mentre ovirt-host — l'iper-vizor, come ESX(i). Poiché vSphere è una soluzione molto popolare, a volte farò confronti con essa.
Fig. 1 — pannello di controllo di oVirt.
Come macchine guest sono supportati la maggior parte delle distribuzioni Linux e versioni di Windows. Per le macchine guest ci sono agenti e dispositivi virtuali e driver virtio ottimizzati, in primo luogo il controller del disco e l'interfaccia di rete.
Per implementare una soluzione resiliente e tutte le funzioni interessanti è necessario uno storage condiviso. Sono supportati storage block come FC, FCoE, iSCSI e anche storage file come NFS, ecc. Per implementare una soluzione resiliente, anche il sistema di storage deve essere resiliente (minimo 2 controller, multi-pathing).
L'uso di storage locali è possibile, ma per impostazione predefinita solo gli storage condivisi (shared storages) sono adatti per un vero cluster. Gli storage locali rendono il sistema un insieme disgiunto di hypervisor e anche in presenza di uno storage condiviso, non è possibile assemblare un cluster. La strada più corretta è l'utilizzo di macchine senza disco con boot da SAN, o dischi di capacità minima. Probabilmente, tramite un vdsm hook, è possibile assemblare soluzioni Software Defined Storage da dischi locali (ad es., Ceph) e presentarli a VM, ma non l'ho esaminato seriamente.
Architettura
Fig. 2 - architettura di oVirt.
Puoi trovare maggiori dettagli sull'architettura in sviluppatore.
Fig. 3 - oggetti di oVirt.
L'elemento superiore nella gerarchia è Centro Dati. Esso determina se si usano storage condivisi (shared) o locali, oltre all'insieme di funzionalità (compatibilità, da 4.1 a 4.3). Possono esserci uno o più elementi. Per molte opzioni, è possibile utilizzare il Data Center predefinito - Default.
Il Data Center è composto da uno o più Clusters. Un cluster definisce il tipo di processore, le politiche di migrazione e altro. Per piccole installazioni, può essere sufficiente limitarsi al cluster Default.
Un cluster, a sua volta, è composto da Host's che svolgono il lavoro principale: portano le macchine virtuali e sono collegati a storage. In un cluster sono previsti 2 o più host. Anche se tecnicamente è possibile creare un cluster con 1 host, non ha alcun vantaggio pratico.
In oVirt è supportato un ampio ventaglio di funzionalità, tra cui migrazione live delle macchine virtuali tra hypervisor (live migration) e storage (storage migration), virtualizzazione desktop con pool di VM, VM stateful e stateless, supporto per NVidia Grid vGPU, importazione da vSphere, KVM, sono inoltre disponibili potenti e molto altro. Tutte queste funzionalità sono disponibili senza pagamenti per licenze, e se è necessario supporto, può essere acquistato da Red Hat tramite partner regionali.
I prezzi per RHV
I costi non sono elevati rispetto a VMware, si acquista solo il supporto - senza obbligo di acquistare la licenza stessa. Il supporto è disponibile solo per gli hypervisor, ovirt-engine, a differenza di vCenter Server, senza necessità di ulteriori spese.
Esempio di calcolo per il primo anno di possesso
Consideriamo un cluster composto da 4 macchine a 2 socket e i prezzi al dettaglio (senza sconti di progetto).
L'abbonamento standard a RHV per socket/anno (premium 365/24/7 - $1499), quindi 4*2*$999=$7992.
:
- VMware vCenter Server Standard $10,837.13 per esemplare, 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ù base. La differenza è di circa 3,5 volte!
In oVirt tutte le funzioni sono disponibili senza limitazioni.
Caratteristiche e massimi
Requisiti di sistema
Per l'hypervisor è richiesto un CPU con virtualizzazione hardware attivata, il minimo di RAM per l'avvio è di 2 GiB, l'ammontare di storage raccomandato per il sistema operativo è di 55 GiB (per lo più per registri, ecc., il sistema operativo occupa poco).
Per ulteriori dettagli — .
Per requisiti minimi 2 core/4 GiB di RAM/25 GiB di storage. Raccomandati — da 4 core/16 GiB di RAM/50 GiB di storage.
Come in qualsiasi sistema, ci sono limitazioni su dimensioni e quantità, la maggior parte delle quali supera le capacità dei server commerciali di massa disponibili. Così, una coppia può indirizzare 2 TiB di RAM e offre 40 core (80 thread), che è inferiore anche ai limiti di una VM.
Massimi delle macchine virtuali:
- Massimo numero di macchine virtuali in esecuzione contemporaneamente: Illimitato;
- Massimo di CPU virtuali per macchina virtuale: 384;
- Massima memoria per macchina virtuale: 4 TiB;
- Massima dimensione di un singolo disco per macchina virtuale: 8 TiB.
Massimi dell'host:
- Core logici o thread della CPU: 768;
- RAM: 12 TiB;
- Numero di macchine virtuali ospitate: 250;
- Migrazioni live simultanee: 2 in ingresso, 2 in uscita;
- Ampiezza di larghezza di banda per migrazione live: Default a 52 MiB (~436 Mb) per migrazione usando la politica di migrazione legacy. Altre politiche usano valori di throughput adattivo basati sulla velocità del dispositivo fisico. Le politiche QoS possono limitare la larghezza di banda per la migrazione.
Massimi delle entità logiche del Manager:
In 4.3 esistono .
- 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 global 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 imposto;
- Storage
- Numero massimo di domini: 50 supportati, 70 testati;
- Host per dominio: Nessun limite;
- Volumi logici per dominio di blocco (di più): 1500;
- Numero massimo di LUN (di più): 300;
- Dimensione massima del disco: 500 TiB (limitata a 8 TiB per default).
Opzioni di implementazione
Come già detto, oVirt è composto da 2 elementi di base — ovirt-engine (gestione) e ovirt-host (hypervisor).
L'engine può essere collocato sia al di fuori della piattaforma stessa (standalone Manager — può essere una VM eseguita su un'altra piattaforma o hypervisor separato e persino una macchina fisica), sia sulla piattaforma stessa (self-hosted engine, similmente all'approccio di VCSA di VMware).
L'hypervisor può essere installato sia su (EL Host), sia su (oVirt-Node, basato su el7).
I requisiti hardware per tutte le opzioni sono più o meno gli stessi.
Fig. 4 — architettura standard.
Fig. 5 — Architettura di Engine self-hosted.
Per me ho scelto la variante standalone Manager e EL Hosts:
- Il standalone Manager è un po' più semplice in caso di problemi di avvio, non c'è il dilemma dell'uovo e della gallina (come per il VCSA — non si avvia finché non è completamente avviato almeno un host), ma si crea dipendenza da un altro sistema*;
- EL Host fornisce tutta la potenza del sistema operativo, utile per il monitoraggio esterno, il debug, la ricerca dei guasti, ecc.
* Tuttavia, per tutta la durata dell'esercizio, ciò non è stato necessario, nemmeno dopo un grave incidente con l'alimentazione.
Ma già passiamo al sodo!
Per l'esperimento c'è la possibilità di liberare un paio di lame ProLiant BL460c G7 con CPU Xeon®. Su di esse riprodurremo il processo di installazione.
Daremo i nomi ovirt.lab.example.com, kvm01.lab.example.com e kvm02.lab.example.com agli host.
Passiamo direttamente a .
Fonte: habr.com
