La virtualizzazione dei server è uno degli argomenti più caldi di questi anni. Molte aziende stanno già affrontando la loro seconda ondata di virtualizzazione che spesso si traduce in una rivisitazione radicale di quello che è stato fatto negli anni passati per correggere errori e, magari, aggiornare l’infrastruttura con gli ultimi trend tecnologici. L’obiettivo di questa breve serie di articoli (qui il precedente) è quello di sottolineare alcuni aspetti di base per chi si avvicina per la prima volta alla virtualizzazione ma anche di ricordare, a chi ha già intrapreso questo percorso, alcuni punti focali per migliorare il più possibile la propria infrastruttura.

non tutto è virtualizzabile

Quando si esegue l’analisi di una infrastruttura fisica con l’obiettivo di virtualizzarla non si riuscirà quasi mai ad ottenere un risultato pieno al 100%. Alcuni server fisici, per diversi motivi, non saranno virtualizzabili ma dovranno rimanere tali. Nella categoria dei server non virtualizzabili troviamo sicuramente:

  • server non x86 (per ovvi motivi);
  • server che hanno particolari caratteristiche hardware: come ad esempio schede PCI particolari (un esempio può essere il fax server);
  • server con sistemi operativi non supportati dall’hypervisor;
  • particolari tipi di cluster;

Questi sono i più diffusi e per alcuni di questi esiste anche una soluzione (almeno parziale). Ovviamente sarà necessario capire bene cosa fanno questi server, che applicazioni e servizi di base stanno facendo ed anche la loro criticità. Con tutte le informazioni e le precauzione del caso, sarà possibile migrare tutti (o parte) dei servizi/applicativi contenuti ed anche ipotizzare nuovi meccanismi di alta affidabilità per i cluster (spesso già insiti -e forse migliori- nell’ hypervisor). Nel caso specifico di server con componenti hardware particolari, ad esempio, potrebbe essere ipotizzabile l’eliminazione di tutte le parti virtualizzabili lasciando sul fisico il minimo indispensabile.

la scelta dell’hypervisor

La scelta dell’hypervisor, secondo il mio personale punto di vista, è abbastanza a senso unico. Esistono comunque alcune eccezioni alla regola da verificare con attenzione prima di procedere con una scelta che potrebbe limitare lo sviluppo dell’infrastruttura e aumentare i costi in modo sensibile.

Il mio primo consiglio è quello di fare una scelta oculata perchè mettersi in casa più di un hypervisor (ad esempio: uno per i server e uno diverso per i desktop) è una follia dal punto di vista di management, gestione delle risorse e probabilmente costi (consulenze, minor potere d’acquisto, storage più complesso da gestire, ecc.).
Un’altro aspetto da considerare, ancora prima di concentrarsi sulle singole funzionalità dell’hypervisor, è il supporto tecnico che si può ottenere. Supporto tecnico non significa solo numero verde da chiamare (con dietro qualcuno che risponda in modo decente e, magari, in italiano) ma anche una comunità attiva (una ricerca su google può salvarti la giornata, 😉 ), knowledge base da consultare, facilità di reperire patch e aggiornamenti di sicurezza.

In questo articolo non scenderò nei dettagli tecnici sugli hypervisor (virtualizzazione, para-virtualizzazione, ecc.): non è l’obiettivo di questo articolo e vorrei semplificare al massimo la lettura, quindi mi permetto di azzardare una macro suddivisione degli hypervisor per 3 macro aree:

  • senza compromessi
  • open source based
  • Microsoft

Nella prima categoria, senza compromessi, l’unico che trova posto è VMware. E’ il primo ad essere nato, è il primo in termini di quote di mercato, è quello che ha la maggior sofisticazione tecnologica, è il più supportato, è il più scalabile… e potrei continuare. L’unico difetto di questo hypervisor è il costo di acquisto (al momento in cui scrivo per socket – max 12 core per socket). Come in tutte le cose però c’è da dire che paghi per quello che ottieni: alcune funzionalità esistono solo qui e soprattutto per i progetti più sofisticati (es. con problematiche, anche complesse, di Disaster Recovery o alta affidabilità, fino alla fault tolerance) è l’unica via per ottenere un risultato sicuro e un TCO basso e predicibile nelle installazioni importanti. Devo aggiungere, a onor di cronaca, che ultimamente VMware ha anche messo a listino diverse licenze “limitate” nelle funzionalità e con prezzi aggressivi: in questo caso il vantaggio è che si può partire con una implementazione ritagliata (più simile anche come funzionalità a quelle dei concorrenti) per poi, eventualmente, crescere se sarà necessario.

Nella categoria dell'”open source based” trovano posto principalmente Xen e i suoi derivati oltre anche a KVM (spinto da RedHat). Xen ora è di Citrix che però, sia per motivi commerciali che tecnici, non sembra molto interessata a spendere troppo in R&D, mentre KVM ha come unico sostenitore RedHat e non mi è ancora capitato di vedere nulla in giro, se non qualche schermata durante gli eventi di presentazione. Il vantaggio di Xen è che costa poco, è performante e “open”. I difetti primari sono sicuramente l’immaturità, la ruvidità con cui molte funzionalità sono state implementate (la CLI la fa da padrone), il supporto da parte dei vendor esterni un po carente. I principali utilizzatori di Xen sono quelli che ne preferiscono l’aspetto open a tutti gli altri, il che comprende: smanettoni, service e cloud provider, ambienti accademici e in generale tutti quelli che hanno pochi soldi e molto tempo a disposizione. Gli utenti Xen devono avere una cultura e un tempo da spendere per il supporto superiore alla media e molta buona volontà. Xen è comunque alla base delle piattaforme Cloud e VPS più importanti in circolazione (es.: Amazon, rackspace).

Infine c’è la categoria che ho definito “Microsoft”. L’hypervisor di casa Microsoft si chiama Hyper-V. Microsoft è partita in enorme ritardo (fallendo un paio di colpi in precedenza) ma l’ultima incarnazione del suo Hypervisor inizia ad essere interessante ed è sicuramente uno dei player per un progetto di virtualizzazione in azienda (almeno per l’SMB). Il prodotto Microsoft è limitato se comparato a VMware ma sta crescendo molto bene, la base installata cresce velocemente, il supporto dai vendor non manca. Se un utente ha una infrastruttura basata principalmente su prodotti Microsoft non troppo grande, Hyper-V potrebbe essere una scelta valida. Il costo, anche nella sua versione più completa, non è elevato e garantisce già un set di funzionalità di tutto rispetto. Rimarco il fatto che i migliori risultati con Hyper-V si ottengono su ambienti Microsoft anche perchè il supporto per altri sistemi operativi è decisamente limitato e questo potrebbe compromettere il processo di virtualizzazione di una infrastruttura multi vendor.

il management di base

Parlare di management di base nel 2010 è quasi ridicolo, infatti per management di base intendo una console di amministrazione unica che permetta di gestire più server fisici e molti server virtuali. Mi spiego meglio: ogni hypervisor (installato sul server fisico) può essere acceduto direttamente per essere amministrato, il problema è che, in realtà, anche il più piccolo dei progetti di virtualizzazione prevede un minimo di due server fisici per una questione di alta affidabilità. Dal secondo server in poi devo avere a disposizione una console di management (ogni produttore la chiama in modo diverso: vCenter per VMware, SCVMM per Microsoft, ecc.) che, in alcuni casi è una ulteriore macchina virtuale. La console di management serve per fare praticamente tutto: interagire con l’HW, creare, modificare e amministrare le VM, schedulare ogni tipo di attività, gestire gli aggiornamenti dell’infrastruttura, gestire l’alta affidabilità, reporting, insomma tutto. La console di management, a parte casi particolari (es.: quella di Citrix può gestire anche Hyper-V) è strettamente legata al suo hypervisor, è l’interfaccia grafica dell’infrastruttura da virtualizzare ed è bene valutarla bene insieme ad ogni altra caratteristiche dell’ambiente che si sta progettando.

Nel prossimo articolo parleremo un po di hardware della infrastruttura di virtualizzazione: il networking, i server fisici, lo storage.