Similitudini, differenze e integrazione con OpenStack: tutto quello che c'è da sapere passando da VMware ad oVirt
Molti di voi avranno scoperto oVirt cercando una valida alternativa a vSphere (e al suo hypervisor ESXi). È bene ricordare che oVirt non è l'unico virtualization manager open source ma sicuramente è quello che più si ispira al prodotto commerciale di VMware. Inoltre, oVirt è la soluzione ideale per realizzare il cloud ibrido in azienda, affiancando ad un sistema di cloud puro (come OpenStack) un sistema di virtualizzazione consolidato ma moderno (vedi il paragrafo dedicato al cloud ibrido). Proveremo ora ad analizzare similitudine e differenza tra i due prodotti. In questo articolo segneremo in rosso le componenti relative a vSphere e in verde quelle relative ad oVirt.Indice del documento:
- Virtualizzazione
- Storage
- Networking
- Cloud ibrido e integrazione con OpenStack
- Importare le macchine virtuali VMware in oVirt
- Tabella comparativa delle funzionalità
- Supporto e costi
- Perché oVirt può essere meglio di VMware
Virtualizzazione
Sebbene la virtualizzazione sia oggi percepita come una commodity, gli hypervisor moderni sono in grado di fornire funzionalità sempre maggiori, sopratutto nell'ottimizzazione dell'utilizzo dell'hardware. A differenza di VMware, che usa il suo hypervisor proprietario denominato ESXi, i nodi di oVirt utilizzano un modulo del kernel Linux chiamato KVM.Che cos'è KVM?
KVM non è l'hypervisor ma bensì un modulo che trasforma il kernel Linux in un eccellente hypervisor, beneficiando quindi delle continue migliorie che vengono apportare a Linux stesso. Per l'emulazione dell'I/O, KVM si affida a QEMU, un software in grado di emulare tutte le periferiche (dischi, rete, VGA, PCI, USB, porte seriali e parallele) al fine di ottenere un hardware virtuale completo. Cosa fa quindi KVM? Permette a QEMU di sfruttare l'accelerazione hardware delle moderne cpu Intel e AMD (VT-x e AMD-V rispettivamente) per far girare i processi delle VM direttamente sull'hardware anziché su delle cpu emulate, che sarebbero quindi molto poco prestanti.Driver paravirtualizzati
Come ESXi, anche KVM dispone di driver paravirtualizzati per le VM chiamati VirtIO. Questi driver sono in grado di migliorare le performance dei sistemi operativi guest, rendendole in tutto e per tutto paragonabili ad un sistema bare-metal. I driver VirtIO sono disponibili per la virtualizzazione delle schede di rete, degli hard disk, della scheda video e per l'ottimizzazione dell'uso della memoria. Quando utilizziamo questi driver, il sistema operativo guest diventa quindi consapevole di essere virtualizzato su un hypervisor e utilizza VirtIO come front-end per le periferiche virtualizzate da QEMU. Dove questi driver non dovessero essere utilizzabili, si dovrà ripiegare su periferiche emulate, con prestazioni ovviamente inferiori.Sono disponibili per i seguenti sistemi operativi guest:
- Windows (7, 8, 8.1, 10)
- Windows Server (2008, 2008 R2, 2012, 2012 R2)
- Red Hat Enterprise Linux (3, 4, 5, 6, 7)
- SUSE Linux Enterprise Server (10 e superiori)
- Ubuntu (12.04 e superiori)
Storage
Tema centrale nel datacenter tanto quanto nel cloud è lo storage. In questo senso sia vSphere che oVirt sono in grado di utilizzare diversi tipi di storage per salvare i dati delle macchine virtuali. Per fare ciò utilizzano un contenitore, chiamato rispettivamente Datastore o Storage Domain, che funge da livello di astrazione della tecnologia di storage vera e propria, presentando alle macchine virtuali un metodo uniforme di accesso ai dati.Vediamo brevemente quali sono i backend a disposizione nei due ambienti:
| tipo di Storage | VMware | oVirt | descrizione |
|---|---|---|---|
| Local storage | ✓ | ✓ | Lo storage locale può essere fatto con i dischi interni oppure con un JBOD direttamente collegato al nodo ESXi/KVM. Non richiede una rete dedicata ma, pur essendo molto semplice da implementare, introduce una serie di limitazioni tra cui l'impossibilità di migrare le VM tramite vMotion/Live Migration ed implementare l'High Availability. |
| Fibre Channel (FC) | ✓ | ✓ | Permette di usare una FC storage area network come backend per le macchine virtuali. Sarà necessario equipaggiare i nodi con adattatori HBA e creare una rete dedicata con uno switch FC. |
| Internet SCSI (iSCSI) | ✓ | ✓ | Permette di usare una storage area network remota tramite il protocollo iSCSI, in grado di incapsulare il traffico SCSI in una normale rete TCP/IP. I nodi (gli hypervisor) fungeranno da initiator della connessione iSCSI verso un target dove risiederà lo storage vero e proprio. |
| Network-attached Storage (NFS) | ✓ | ✓ | Permette di usare un file server remoto attraverso una rete standard TCP/IP. È probabilmente la soluzione meno prestante ma allo stesso tempo molto facile da realizzare. Utilizza il protocollo NFS disponibile in qualsiasi soluzione NAS. |
| VMware Virtual SAN (VSAN) | ✓ (*) | È la soluzione software-defined-storage nativamente supportata da vSphere, (*) disponibile solo attraverso una sottoscrizione a parte (vedi paragrafo dedicato all'hyperconvergence). | |
| GlusterFS | ✓ | Possiamo scegliere un namespace GlusterFS come backend per uno Storage Domain. Inoltre, GlusterFS è la soluzione software-defined-storage integrata nativamente in oVirt (vedi paragrafo dedicato all'hyperconvergence). | |
| OpenStack Cinder / Ceph | ✓ | oVirt supporta nativamente il block storage di OpenStack (Cinder) come backend dei propri Storage Domain, traendo vantaggio dei suoi numerosi driver tra cui quello per il filesystem distribuito Ceph. VMware non ha questa possibilità per i suoi Datastore (da non confondere con la possibilità di aggiungere un Datastore come backend di Cinder, che invece è l'operazione contraria). |
Block storage e le LUN: le diverse implementazioni di VMware e oVirt
Quando andiamo ad utilizzare uno storage che usa le LUN come dispositivo a blocchi, è bene comprendere la differente implementazione tra VMware ed oVirt. In particolare, vSphere crea un ulteriore filesystem sopra la LUN chiamato VMFS, mentre oVirt crea un partizionamento logico che presenta direttamente alle macchine virtuali.
Qui VMware: una volta connessi alla SAN, la LUN viene formattata con un filesystem proprietario chiamato VMFS, sul quale verranno depositati tanti file quanti sono i dischi virtuali contenuti nel Datastore (vedi immagine a sinistra). Questo approccio aggiunge un livello ulteriore tra lo storage fisico e la macchina virtuale, che a sua volta dovrà formattare il disco virtuale con il proprio filesystem (una VM Windows, ad esempio, dovrà effettuare una formattazione NTFS). Si perde qualcosa in prestazioni in cambio della disponibilità dei dischi virtuali sotto forma di file.Qui oVirt: avendo sotto il cofano un sistema operativo minimale derivato da RHEL, i nodi hypervisor hanno a disposizione tutte le moderne tecnologie dell'universo Linux. La scelta è ricaduta su LVM, che non è altro che un sistema di suddivisione del disco fisico (la LUN in questo caso) in partizioni logiche. Non viene aggiunto alcun filesystem e l'hypervisor presenta alla VM un logical volume LVM come un dispositivo a blocchi, per essere poi formattato dalla macchina virtuale con il filesystem desiderato. Questo approccio risulta molto più prestante rispetto a quello che troviamo in vSphere. Volendo essere precisi va detto che, in caso di interventi sullo storage a livello più basso (come recupero dati, copie manuali di virtual disk, ecc...) sarà necessario avere un minimo di dimestichezza con LVM.
In entrambe le piattaforme è comunque possibile mappare direttamente una LUN come disco virtuale di una VM (RDM/Direct LUN) a patto di rinunciare ad alcune funzionalità; la LUN non farà parte ne di uno snapshot ne di un export della VM e non sarà possibile effettuare la migrazione live dei dati. Da prendere in considerazione quando lo storage è basato su SAN di livello enterprise (EMC, NetApp, IBM, HP, ...) in grado di gestire autonomamente la disponibilità la migrazione dei dati delle VM.
Tra le altre carattiristiche in ambito storage supportate da entrambe le piattaforme troviamo:
- il Multipathing
- il Thick e il Thin Provisioning dei dischi
- gli Snapshot a caldo e a freddo delle VM
Software Defined Storage (SDS)
Anziché adottare costose soluzioni storage come le SAN, da qualche tempo stanno prendendo piede le soluzioni software-defined-storage che, come suggerisce il nome, rendono superflua la necessità di soluzioni hardware dedicate e gestiscono la ridondanza e la disponibilità dei dati attraverso routine software che comunicano tra loro sulla rete. Sarà sufficiente acquistare hardware general-purpose carrozzato di tanta cpu, memoria e dischi rigidi standard (meglio se con qualche SSD). Sia VMware che oVirt hanno adottato una propria soluzione a questo scopo; rispettivamente VSAN e GlusterFS.VMware Virtual SAN (VSAN): è la soluzione HC di VMware alternativa alla classica SAN. Attivabile con un'apposita licenza, la VSAN permette di utilizzare lo storage locale degli host e aggregarlo in un unico storage pool. Così facendo vengono mantenute tutte le funzionalità di VMware (come HA, vMotion e DRS) eliminando la necessità di uno storage esterno.
GlusterFS: è un filesystem distribuito di tipo network-attached-storage, fortemente scalabile, i cui nodi sono connessi tra di loro tramite normale rete TCP/IP (Gigabit o superiore). GlusterFS è fortemente integrato in oVirt al punto che non solo possiamo scegliere un namespace GlusterFS come backend per i nostri Storage Domain, ma possiamo amministrarne i volumi direttamente dall'Administration Portal, trasformando oVirt stesso in una piattaforma di storage. Possiamo creare un cluster di nodi dedicati, oppure scegliere la via iperconvergente (HC) e far girare GlusterFS sugli stessi nodi dedicati alla virtualizzazione. Parleremo di Gluster e HC più avanti, in un altro articolo, sempre qui su oVirt Italia.
Hyperconvergence
L'iperconvergenza (che abbrevieremo con HC) è una soluzione software dove i servizi di virtualizzazione, storage e networking sono erogati da tutti i nodi del cluster. Non c'è quindi distinzione tra nodi dedicati alla virtualizzazione e nodi dedicati alla SAN, con enormi vantaggi in termini di costi, dal momento che andiamo ad utilizzare hardware general purpose anziché costose soluzioni proprietarie di storage. Abbiamo quindi la possibilità di usare lo storage locale di ogni nodo ma, affinché la singola macchina non diventi un single-point-of-failure, è necessario utilizzare una soluzione software-defined-storage (SDS) che crei un cluster tra i dischi dei nodi e presenti un unico namespace. Su vSphere dovremo quindi utilizzare la VSAN come backend del Datastore, mentre su oVirt dovremo utilizzare GlusterFS come backend dello Storage Domain.Networking
Sia VMware che oVirt forniscono di base la gestione
del networking a livello 2; è il networking più semplice in assoluto, in
grado di fornire connettività tra gli host e le virtual machine. Sia i vSphere Standard Switches così come le oVirt Logical Networks
creano fondamentalmente un bridge tra le VM che risiedono (cioè hanno
una vNIC connessa) sulla medesima VLAN; questi bridge includono a loro volta la NIC fisica degli hypervisor, sulla quale transitano tutte le VLAN verso lo switch fisico esterno. In entrambe le piattaforme
possiamo
raggruppare più NIC fisiche per ottenere banda aggregata e ridondanza. Possiamo assegnare ad ogni
bridge una funzione specifica (management / migrazione delle VM /
storage / virtual desktop) e modificare alcuni parametri come l'MTU. La gestione del livello 3 (il routing) è invece delegata ad un router fisico esterno o ad un provider SDN configurabile con un driver. Non ci sono differenze sostanziali tra le due piattaforme.Software Defined Networking (SDN)
Ci sono situazioni in cui il networking classico va molto stretto. In ambienti molto dinamici, dove le VM migrano spesso e con architetture di rete complesse, risulta molto utile avere una gestione del networking distribuita su ogni singolo nodo, ma orchestrata e monitorata centralmente. Così facendo si evita di dover configurare e gestire la rete su router, switch e nodi hypervisor in modo distaccato e ripetitivo, separando il data plane (che risiede sull'host) dal management plane (sul vCenter/Engine). Ci sono innumerevoli vantaggi nell'utilizzare una SDN:- networking gestito direttamente da vSphere/oVirt;
- facilità di deployment delle nuove reti (scalabilità);
- consistenza della topologia di rete tra i nodi;
- funzioni avanzate di tagging e tunnelling (GRE, VxLAN, IPsec);
- funzioni di monitoring avanzato (NetFlow, IPFIX, sFlow);
Qui oVirt: il supporto alle SDN è stato recentemente ottenuto con l'Open Virtual Network (OVN), un'estensione di Open vSwitch (OVS) che aggiunge alle funzionalità consolidate di switching L2, le funzionalità di astrazione delle reti. Consiste fondamentalmente di due componenti:
- un driver, in grado di dialogare con le NIC in caso di topology change e configurare di conseguenza le vNIC sulla rete logica appropriata;
- un provider, responsabile di dialogare con un'istanza Open vSwitch (OVS).
Network Function Virtualization (NFV)
Con il termine Network Function Virtualization si fa riferimento ad una particolare architettura di rete dove tutte le funzionalità sono svolte da apparati virtuali anziché fisici (i servizi di router, switch, firewall, load balancer sono ottenuti attraverso routine software ospitate su macchine virtuali). Questo tipo di approccio è sempre più richiesto dagli operatori che necessitano di una rete flessibile ma allo stesso tempo affidabile. Con la NFV è possibile effettuare rapidi deployment di segmenti di rete, migrare le Virtual Function (VF) da un server ad un altro e ridurre sensibilmente i costi di gestione e approvvigionamento.Qui VMware: è possibile aggiungere le funzionalità NFV acquistando il modulo VMware NSX.
Qui oVirt: come per le SDN, anche le funzionalità NFV sono fornite dall'estensione OVN.
Cloud ibrido e integrazione con OpenStack
L'errore più comune che vedo commettere dalle aziende è pensare di sostituire VMware con OpenStack, per ottenere in un colpo solo un potentissimo private cloud e (sopratutto) una riduzione dei costi di licenza. Solitamente, a seguito di un breve periodo di prova, si decide di rinunciare e rimanere con l'attuale piattaforma di virtualizzazione rimandando il "progetto cloud". Questo accade fondamentalmente per due ragioni:- una piattaforma cloud richiede competenze diverse (maggiori) rispetto ad una classica piattaforma di virtualizzazione; se quest'ultima si occupa principalmente di astrarre l'hardware delle VM, nel cloud tutto è un servizio come vuole l'acronimo XaaS (anything as a service). Storage, rete e perfino i database sono considerati delle commodity; sono quindi richieste competenze trasversali, sopratutto in ambito NFV (Network functions virtualization).
- l'inserimento di un [public|private] cloud non può essere approcciato come una normale migrazione ma piuttosto come un affiancamento; per questo tra i temi più dibattuti ci sono proprio l'hybrid cloud (la distribuzione delle risorse tra l'infrastruttura interna e quella pubblica offerta da un provider) e il bimodal IT (ovvero un'architettura che prevede l'infrastruttura classica, legacy, affiancata ad una più moderna come potrebbe essere OpenStack).
La soluzione? oVirt.
Come detto all'inizio dell'articolo, oVirt è la soluzione ideale per realizzare il cloud ibrido in azienda. Per due motivi:- è la piattaforma giusta su cui migrare da VMware:
- vengono abbattuti i costi di licenza e di supporto;
- le competenze acquisite su piattaforma vSphere sono completamente spendibili su oVirt con il minimo sforzo di adattamento;
- è la piattaforma perfetta per essere affiancata ad OpenStack perché in grado di dialogare con la maggior parte delle sue componenti:
- virtualizzazione (gestione delle VM di oVirt direttamente da Horizon);
- dischi virtuali (utilizzo diretto dei volumi del Cinder, senza alcuna importazione);
- immagini (importazione delle immagini e degli snapshot di Glance);
- networking (integrazione di Neutron come network provider).
Importare le macchine virtuali VMware in oVirt
È veramente facile migrare le macchine virtuali da VMware a oVirt. Ci sono due possibilità alternative:- La prima prevede l'utilizzo del plugin nativo per VMware. Sarà sufficiente aggiungere un istanza VMware vCenter all'interno della sezione External Providers sull'oVirt Engine, quindi avviare l'importazione tramite la funzione Import all'interno della sezione Virtual Machines.
- In alternativa, è sempre possibile esportare le macchine virtuali da VMware in formato OVF e importarle in oVirt con la generica funzione virt-v2v.
Tabella comparativa delle funzionalità
Spesso mi viene chiesto: «quella tal funzione di vSphere la trovo anche su oVirt?» Provo qui a riepilogare le funzionalità così come sono denominate nelle due piattaforme. Sono ovviamente ben accetti suggerimenti e correzioni.| VMware | oVirt | descrizione |
|---|---|---|
| vSphere | oVirt | È il nome della soluzione di virtualizzazione nel suo insieme e comprende i nodi (hypervisor) e la piattaforma di gestione. |
| ESXi | oVirt Node | È il nodo fisico dove viene eseguito l'hypervisor, ovvero il software in grado di astrarre il processore, la memoria, lo storage e presentare queste risorse alle macchine virtuali. È dotato di un sistema operativo a footprint ridotto ad alte prestazioni e bassa predisposizione alle vulnerabilità di sicurezza; quello di VMware è chiamato VMkernel mentre oVirt usa una versione minimale di Linux con modulo KVM (vedi paragrafo sulla virtualizzazione). |
| vCenter Server | oVirt Engine | La piattaforma per la gestione centralizzata del datacenter. Da qui vengono comandate tutte le operazioni che i nodi (gli hypervisor) devono effettuare sulle macchine virtuali |
| vCenter Server Appliance | oVirt Self Hosted Engine | Con questa funzionalità potete installare il vCenter Server/oVirt Engine direttamente su di una macchina virtuale e quindi godere della funzionalità di HA come una normale VM. Questa scelta si contrappone all'installazione dell'Engine su di una macchina fisica che, di fatto, rappresenta un single point of failure. |
| vSphere Web Client | oVirt Administration Portal | L'interfaccia web dalla quale creare le macchine virtuali, monitorare le risorse e svolgere tutti i task relativi al ciclo di vita della VM. |
| Datastore | Storage Domain | Sono contenitori logici che astraggono le specifiche fisiche dello storage sottostante e forniscono un metodo uniforme per il salvataggio dei dati delle macchine virtuali. |
| vMotion | Live Migration | Effettua la migrazione di una o più VM in esecuzione da un nodo fisico ad un altro, senza alcun disservizio, preservando le operazioni in esecuzione. |
| Storage vMotion | Storage Live Migration | Effettua la migrazione di uno o più dischi virtuali di una VM, da un Datastore/Storage Domain ad un altro, senza alcun disservizio, preservando l'integrità dei dati. |
| High Availability (HA) | Host HA / Virtual Machine HA | Garantisce l'alta disponibilità delle macchine virtuali, facendole ripartire su un nodo fisico diverso da quello che subisce un guasto. oVirt differenzia l'HA per host (guasto fisico) e per macchina virtuale (errore della VM), da configurare in contesti diversi. |
| Distributed Resource Scheduler (DRS) | Cluster Policies | Permette di impostare le policy di load balancing, power saving e failover. |
In questa seconda tabella, invece, ho elencato tutti quegli addon di VMware che non fanno parte di vSphere ma lo integrano. Per quanto riguarda la controparte oVirt, la soluzione può essere fornita direttamente dalla piattaforma base o tramite un software esterno; quest'ultimo, pur trattandosi di un altro progetto, è in ogni caso un sotware ufficialmente supportato e direttamente integrato in oVirt.
| categoria | VMware | oVirt | descrizione |
|---|---|---|---|
| SDS | VSAN | GlusterFS | Sia VMware che oVirt mettono a disposizione la propria soluzione Software Defined Storage (SDS) in grado di raggruppare lo storage locale e alternativa alla SAN (vedi il paragrafo corrispondente). |
| NFV | NSX | OVN | Ne VMware ne oVirt sono in grado di creare nativamente reti completamente astratte. Entrambe mettono a disposizione un addon per la gestione della Network Function Virtualization (NFV). |
| Cloud Management | vRealize Automation | ManageIQ | Sono tool in grado di raggruppare le risorse dal public e dal private cloud di vendor differenti, automatizzandone la gestione attraverso un semplice layer di astrazione. |
| Life Cycle Management | vRealize Operations | The Foreman | Sono tool in grado di gestire il completo ciclo di vita dei sistemi (sia fisici che virtuali), il monitoring e il reporting. |
| VDI | Horizon | (direttamente integrato in oVirt) | Se in VMware la creazione e la gestione dell'infrastruttura per il Virtual Desktop (VDI) è demandata ad un addon esterno, in oVirt tutte le risorse necessarie sono già presenti nella piattaforma base (SPICE/Teamplate/Pools). |
Supporto e costi
È impossibile paragonare i costi di due software provenienti da contesti così diversi. VMware è un prodotto commerciale, utilizzabile a seguito del pagamento di una licenza, al quale si può aggiungere una sottoscrizione per il supporto. oVirt invece è un progetto opensource, fornito senza alcun costo di licenza o di manutenzione, il cui supporto viene fornito dalla community. Se il know-how del reparto IT della vostra azienda è sufficiente a gestire un prodotto opensource, oVirt è sicuramente la soluzione che state cercando.In alternativa, una volta valutato il software, potete optare per una delle soluzioni commerciali basate su oVirt (che ho elencato qui).
Perché oVirt può essere meglio di VMware
oVirt è una piattaforma solida, stabile e completa. Supporta tutte le feature che siete abituati ad usare su vSphere (alta affidabilità, vMotion, snapshot, backup a caldo, backup a freddo, import ed export delle VM, ecc...) e le mette a disposizione senza alcun costo di licenza o subscription.
Inoltre, presenta diversi vantaggi rispetto a VMware. Sebbene vSphere possa sembrare molto facile di primo acchito, sul lungo periodo oVirt risulta molto più semplice da gestire in termini di:
- facilità di aggiornamento (su oVirt è semplice tanto quanto lanciare il comando yum update ovirt-engine-setup);
- meno vincoli architetturali (ad esempio, l'obbligo del dominio vsphere.local e delle sorgenti di autenticazione);
- ottime performance e stabilità;
- integrazione forte (e sopratutto nativa) con OpenStack;
- impiego esclusivo di software opensource e protocolli standard, evitando alla vostra azienda il pericolo del vendor lock-in.
Non mi resta che invitarvi a provarlo. Lavoro con oVirt da quasi quattro anni e ne sono fortemente entusiasta. Vorrei lo foste anche voi.
Bibliografia
- Red Hat Documentation - https://access.redhat.com/documentation
- oVirt Documentation - http://www.ovirt.org/documentation
- VMware vSphere 6.0 Documentation Center
- AA. VV., Mastering KVM Virtualization, Packt Publishing, 2016
Nessun commento:
Posta un commento