Nello scorso numero di dicembre 2015 abbiamo recensito in modo approfondito la versione 4.0 della piattaforma open source per la virtualizzazione sviluppata dalla società austriaca Proxmox Server Solutions. Analizziamo insieme le novità che Proxmox mette a disposizione per competere con i blasonati concorrenti Microsoft e VMware.
Proxmox VE vs. vSphere
Il confronto con l’hypervisor leader di mercato può sembrare impari, ma una analisi accurata delle funzionalità di Proxmox può farlo rivalutare come alternativa, in particolare nel caso di situazioni in cui il rapporto tra budget e prestazioni sia il principale parametro di scelta.
Proxmox VE (da qui in avanti semplicemente Proxmox) è basato sul sistema operativo Debian e porta con sé vantaggi e svantaggi di questa nota distribuzione Linux: un sistema operativo stabile, sicuro, diffuso e ben collaudato, con un’ampia scelta di pacchetti software – sebbene a volte non aggiornati all’ultima release ma in grado di garantire una perfetta stabilità – e il “Contratto Sociale” che assicura i vantaggi del Software Libero (https://www.debian.org/social_contract). Tra i vantaggi bisogna sicuramente citare anche la presenza di una community ben radicata e attiva nella gestione del codice e della documentazione, che risulta sempre essere ricca e dettagliata. In quanto progetto open-source, il repository del codice sorgente è a disposizione di chiunque voglia implementare nuove funzioni, o adattare quelle esistenti in base alle proprie esigenze. Inoltre la licenza GPL consente l’uso anche commerciale in modo del tutto gratuito.
Come noto a chi già conosce la piattaforma VMware, la maggior parte delle funzionalità avanzate dell’hypervisor (Clustering, High Availability, live migration di VM e storage etc.) non sono disponibili nella versione gratuita di ESXi. Per potervi accedere è necessario acquistare le varie licenze (Essentials Plus, Standard, Enterprise Plus...) con i relativi costi e requisiti. Al contrario, con Proxmox si possono utilizzare gratuitamente e nativamente gran parte delle funzionalità sopra citate, e anche alcune aggiuntive, tra cui: backup e restore delle VM con vzdump, clonazione delle VM, creazione di template, simulazione di High Availability e storage di rete distribuito. In aggiunta, sempre per proporre una alternativa all’ecosistema vSphere, con ogni installazione di Proxmox (quindi su ogni host) è disponibile una interfaccia Web per il controllo centralizzato di eventuali cluster. Interessante sottolineare che in questo modo non c’è dipendenza dal singolo vCenter perché ogni host può ricoprire questo ruolo indipendentemente dagli altri.
Parlando delle funzionalità del tutto assenti nel prodotto VMware, Container con LXC e file system ZFS sono quelli con un valore aggiunto più consistente. vSphere, a sua volta, è un prodotto maturo, assurto come standard de-facto nel mondo della virtualizzazione: viene usato in ambienti mission-critical, il supporto da parte di VMware e di tutti i produttori di hardware è eccellente e le gamma di funzioni offerte è molto vasta. Tuttavia la possibilità di effettuare vMotion, storage vMotion, High Availability, Fault Tolerance, vSwitch, integrazione con gli altri prodotti VMware è una prerogativa delle versioni a pagamento che, tra costi di licenza e complessità dell’infrastruttura richiesta, possono arrivare a costare svariate decine di migliaia di euro.
Posto come discriminante il solo prezzo di acquisto, Proxmox riesce a essere più vantaggioso anche della versione gratuita di ESXi, in virtù del rapporto prezzo/funzionalità decisamente a suo favore. La presenza di molte feature aggiuntive a costo zero consente inoltre di poter sperimentare scenari e situazioni d’uso più o meno complessi senza limiti di tempo (la versione gratuita di ESXi permette di provare l’hypervisor in modalità full-feature, ma solo per 60 giorni).
In quest’ottica, PMI e i liberi professionisti possono valutare Proxmox come soluzione per il consolidamento dei loro server o la creazione della propria infrastruttura con un budget contenuto sfruttando eventualmente acquistando - se necessario - il supporto commerciale offerto dalla società austriaca sui suoi prodotti.
Non solo punti a favore, ma anche qualche svantaggio
Nel processo decisionale occorre valutare con attenzione il fatto che Proxmox richieda di "sporcarsi le mani". Questo hypervisor è essenzialmente una distribuzione Debian, quindi occorre una buona conoscenza del sistema operativo Linux e una confidenza naturale con la linea di comando.
Proxmox è un progetto gestito da team di sviluppo che – per quanto attivo, professionale e circondato da una affermata community – non è paragonabile per dimensioni e risorse a disposizione, a quello di VMware (o di Microsoft se vogliamo paragonarlo ad Hyper-V).
Nonostante Proxmox sia production-ready e diverse realtà lo utilizzino per la gestione dell’infrastruttura virtualizzata, bisogna tenere in considerazione la possibilità di trovare bug e piccoli problemi che, in generale, non ci si aspetta dai prodotti concorrenti.
Anche il supporto potrebbe rivelarsi critico: VMware offre una copertura ampia e collaudata, oltre a MSP, rivenditori e tecnici specializzati che compongono una rete di professionisti su scala globale: nemmeno paragonabile a un prodotto di nicchia e ancora poco diffuso come quello austriaco.
Il supporto di Proxmox Server Solutions, come nel caso di vSphere, viene offerto a pagamento con un modello di licensing più semplice rispetto a quello di VMware. I 4 tipi di Subscription disponibili sono su base annuale per socket e includono, anche l’accesso ai repository Enterprise.
Proxmox VE 4.1: la nuova release
Una delle peculiarietà di Proxmox è senz’altro la presenza dei Container LXC. I Container (CT) sono un sistema di virtualizzazione che permette di creare varie istanze virtualizzate, condividendo le risorse del sistema operativo sottostante: permettono quindi di creare macchine virtuali Linux a partire dello stesso sistema operativo dell’hypervisor. LXC è infatti l’acronimo di Linux Containers.
I vantaggi dei CT rispetto alle VM tradizionali sono un minor impatto in termini di risorse computazionali richieste e in un tempo di deployment molto basso. Dopo aver finito la procedura guidata di Proxmox, sono infatti necessari solo pochi secondi per avere il Container operativo e funzionante. Il tempo di boot è anche minore, in quanto il kernel è già stato caricato in memoria dall’hypervisor, rendendo la creazione, l’uso e la distruzione dei CT un processo molto veloce e facilmente replicabile.
Tra gli svantaggi c’è un minor isolamento rispetto al sistema operativo sottostante: una VM ha un kernel a parte che può essere completamente diverso da quello dell’host (una VM con Windows Server su Proxmox – Linux ad esempio), mentre un CT condivide il kernel con l’host rimanendone parzialmente dipendente.
Un approccio di questo tipo pone importanti interrogativi sulla sicurezza di questa soluzione: è possibile che un utente riesca ad “evadere” da un CT e trovarsi direttamente nell’host? La risposta è sì e nel caso limite in cui si trovasse come root nell’host avrebbe anche il controllo totale dell’hypervisor. Questo scenario si può realizzare quando lo UID (l’user ID, un numero che contraddistingue univocamente l’utente e determina i permessi) viene mappato a 0 (zero), cioè root e ci si trova nella situazione dei cosiddetti CT Privileged. Questo tipo di Container sono stati i primi ad essere implementati, e proprio a proposito di questo comportamento, tutt’oggi persistono dubbi sull’effettiva sicurezza di questo tipo di virtualizzazione.
Con i CT Unprivileged invece è possibile concedere i permessi amministrativi all’utente all’interno dei Container, privandolo degli stessi al di fuori (e quindi sull’host) aumentando il livello di sicurezza in caso di evasione.
In Proxmox 4.1 sono stati introdotti i Container Unprivileged – sebbene in forma sperimentale – ma non è possibile crearli utilizzando l’interfaccia grafica. Occorre specificare l’apposito parametro --unprivileged da linea di comando durante la creazione (ad esempio pct create 130 local:vztmpl/centos-7-default_20150829_amd64.tar.xz --unprivileged).
Altra procedura che non può essere fatta nativamente è la conversione di un Container da un tipo all’altro: utilizzando l’interfaccia a linea di comando bisogna fare un backup e poi ripristinare il CT con l’apposita opzione indicata in precedenza (ad esempio pct restore 127 local:backup/vzdump-lxc-111-2016_04_07-13_18_30.tar.gz --unprivileged). Dalla prossima versione di Proxmox, il supporto ai Container Unprivileged dovrebbe diventare completo.
Tra le altre novità bisogna sicuramente nominare il supporto a ZFS migliorato, che ora prevede fino a 8 dischi nelle configurazioni RAIDZ. Il servizio NTP (Network Time Protocol) che serve per mantenere sincronizzati VM, CT e host dei cluster, è abilitato di default e il sistema di accensione/spegnimento è stato migliorato tramite systemd – l’analogo di init che gestisce l’avvio dei processi dopo la fase di boot – ed è inoltre possibile spegnere le macchine da GUI senza ricevere errori. Sempre in tema di system behaviour è stata aggiunta alla GUI l’opzione per attivare QEMU Agent (per VM KVM), la cui implementazione rimane comunque migliorabile: l’installazione è macchinosa e richiede un driver VirtIO che di default non viene installato.
Oltre ai CT Unprivileged, LXC vede aggiungersi il supporto per i nuovi sistemi operativi Fedora 22 ed Ubuntu 15.10, oltre alla ossibilità di ridimensionare i CT con rootfs da GUI.
Infine, la tecnologia di Thin Provisioning per i dischi partizionati con LVM è stata introdotta come technology preview: l’implementazione verrà migliorata nelle future release e al momento risulta ancora troppo acerba per essere usata in produzione (ad esempio i CT non possono migrare su supporti LVM-thin).
La roadmap delle prossime release contempla ulteriori miglioramenti: Proxmox 4.2 sarà basato su kernel Linux 4.4 e sono previste diverse novità interessanti, tra cui la migrazione live dei Container e il partizionamento LVM-thin provisioned (che al momento soffre ancora di bug e problemi di implementazione).
Per quando riguarda la sicurezza verrà introdotto il supporto a Let’s Encrypt (LE è il progetto open-source dell’Internet Security Research Group che offre gratuitamente certificati SSL tramite una procedura automatizzata di richiesta, attivazione e rinnovo. https://letsencrypt.org/about/), mentre in ambito High Availability verrà introdotto il supporto a dispositivi esterni di fencing per una gestione più ampia dell’HA e miglioramenti per DRBD9 (replica a blocchi dello storage).
In programma c’è anche l’aggiornamento sia del framework della documentazione sia dell’interfaccia Web con l’accattivante Sencha Ext JS.
Proxmox e Turnkey per un deploy rapido di VM e Container
Turnkey Linux (tutte le informazioni su https://www.turnkeylinux.org) è un progetto molto interessante che mette a disposizione diverse Virtual Appliance (sia sotto forma di VM che di Container) con vari servizi preconfigurati: stack LAMP/LEMP, vari CMS, BugZilla, Ansible, MySQL, sistemi di wiki, ownCloud, openLDAP, OpenVPN etc.
L’integrazione con Proxmox è presente sin dalla versione 2.0, con i precedenti Containter basati su OpenVZ. Con Proxmox 4.0 – la release che ha segnato il passaggio da OpenVZ a LXC – erano state rimosse le appliance basate sul vecchio sistema di Container, e lasciate solo le immagini dei sistemi operativi. Dall’uscita di Proxmox 4.1 TurnKey è tornato ad offre entrambe le tipologie di risorsa.
Il deployment è molto facile: è sufficiente accedere alla Storage View, selezionare l’host e lo storage di riferimento, quindi nel tab Content selezionare la voce Templates.
Al momento sono disponibili ben 97 virtual appliance, oltre a template di sistemi operativi sopra nominati.
Il comando pvereport, introdotto in questa release, fornisce un’utile e dettagliatissima panoramica dell’installazione in corso, analizzando informazioni generali di sistema, macchine virtuali, container, storage bios, cluster, firewall, interfacce e schema di rete.
L’output è piuttosto corposo, suggeriamo di concatenarlo ad un file di testo (pvereport > report.txt) per una rapida consultazione, ad esempio, in caso di troubleshooting.
In chiusura, una nota sul lifecycle
L’intervallo di rilascio tra una versione e la successiva di Proxmox è di circa sei mesi. Essendo un progetto in pieno sviluppo e relativamente giovane (è partito nel 2008), ogni release introduce corpose novità e numerosi bugfix: il consiglio è quindi quello di aggiornare costantemente l’infrastruttura, previa verifica della compatibilità tra le varie versioni.
Alla fine di questo mese (più precisamente il 30 aprile 2016) termina il supporto generale a Proxmox 3.4, la più importante release prima di Proxmox 4.x. Verranno d’ora in poi distribuiti gli aggiornamenti di sicurezza, ma nessuna nuova funzionalità: Debian 7 “Wheezy” – il sistema operativo su cui si basava Proxmox 3.4 – entrerà nella fase Long Term Support il 26 aprile 2016 ed estenderà la durata degli aggiornamenti di sicurezza, gestiti da un gruppo di volontari e non dagli sviluppatori, fino al 31 maggio 2018.