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 e qui i precedenti) è 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.

Uno degli aspetti importanti della infrastruttura virtuale, e scusate il gioco di parole, è l’infrastruttura fisica:

la connettività

il primo aspetto da tenere sempre bene a mente è che i server virtuali sono all’interno di diversi, a volte molti, server fisici e che, a loro volta, sono collegati ad uno storage ed a un network: Il tutto a formare un cluster. Questa affermazione è meno banale di quanto si possa pensare: la connettività va dimensionata correttamente ed è necessario prevedere ed analizzare molti particolari come le latenze per l’accesso allo storage e alla comunicazione fra i nodi, il throughput necessario, l’eventuale scalabilità del network, la ridondanza, un adeguato backend e un frontend all’altezza della aspettative. Se è vero che molto di quanto detto si può sottovalutare in progetti di minore importanza diventa fondamentale quando i numeri si fanno anche solo mediamente importanti, per non creare colli di bottiglia tali da compromettere seriamente le prestazioni e l’operatività dell’intero cluster.

In passato si consideravano infatti le richieste di connettività di un singolo sistema operativo / applicazione, e nella grande maggioranza dei casi la dotazione HW standard della macchina (le classiche 2 interfacce Gbit + 2 porte FC) erano più che sufficienti, oggi con le densità raggiunte dalle piattaforme di virtualizzazione (nei casi di deployment VDI si parla anche di 6/8 VM per core!) la connettività è uno dei punti focali, questo ha portato pero’ a degli spiacevoli side effects come:

  • proliferazione di NIC/HBA e cavi (es.: separazione fisica delle reti e ridondanza)
  • complessità di gestione (trunking, network management, troubleshooting  difficoltoso)
  • limitazioni dei nodi (pochi slot PCI, poche porte ethernet a disposizione, ecc.)

Per ovviare a tutto quanto detto in precedenza l’industria si è attrezzata cercando di unificare il più possibile la parte di networking tradizionale e, nelle ultime incarnazioni, di inglobare anche la parte di connessione verso lo storage. L’adozione di una rete ethernet a 10Gbit/sec può ridurre drasticamente il numero di connessioni necessarie fino a 2 (più per motivi di ridondanza che altro) e, attraverso strumenti e protocolli moderni (VLAN, Virtual Switches, etc), è possibile comunque separare in maniera semplice e relativamente sicura tutto il traffico. Fatto salvo che il media oggi più usato è (e probabilmente rimarrà) ethernet non si può invece dire la stessa cosa per i protocolli deputati alla comunicazione lato storage: FC, FCoE, iSCSI, NFS sono tutti protocolli validi e supportati. La scelta su come e quando usarli dipende dalla dimensione dell’infrastruttura, dal tipo di storage, dall’architettura che si sceglie di adottare e, molto, anche dai costi. L’unica nota che mi sento di aggiungere a quanto detto su quello che viene normalmente chiamato “converged networking” riguarda Infiniband. Infiniband è una tecnologia di connessione molto efficiente e performante (attualmente la sua versione QDR arriva fino a 40Gb/sec) con una bassissima latenza che si trova principalmente in ambienti HPC (High Performance Computing), questa è, sotto molti punti di vista, decisamente meglio di Ethernet, ma è supportata da pochissimi nomi dell’industria (a parte uno tutti nomi di secondaria importanza), le installazioni sono poche e i prodotti decisamente costosi.

i server

Uno dei grandi vantaggi che ha portato la virtualizzazione, in termini di costi e funzionalità hardware, è la reciproca rincorsa che (gli unici due) produttori di CPU per server X86 hanno fatto negli ultimi anni. Io sono un forte sostenitore dell’hardware standard e ormai, fortunatamente, tutta l’industria sta andando in quella direzione. Non ha più senso per nessuno, se non per AMD e intel, sviluppare chipset, RAM o altre componenti particolari per i server. Tutti i produttori montano le stesse CPU, la stessa RAM, gli stessi chipset, le stesse schede PCI, gli stessi controller RAID, stesse porte ethernet in server delle medesime dimensioni, con gli stessi consumi e via dicendo! Insomma, I server sono tutti uguali. Dell, HP, IBM Fujitsu hanno caratteristiche decisamente confrontabili e non portano nessun valore aggiunto sensibile. La differenza nella scelta di un vendor piuttosto che un altro la possono fare: il livello del servizio di assistenza, il prezzo o la simpatia per il rivenditore e poco più. Certo, è sempre preferibile sposare un unico vendor alla volta per avere una certa omogeneità nell’hardware da gestire e un solo numero da chiamare per l’assistenza ma è vero anche che non è necessario legarsi per la vita ad un unico fornitore… anzi!, mentre da un punto di vista puramente tecnico possiamo invece fare un discorso abbastanza semplice: molta RAM. La cosa più importante nella scelta dell’hardware non la velocità della CPU (a parte casi particolari) ma è la quantità di RAM, è sempre più probabile trovare nodi a corto di RAM piuttosto che con poche risorse di CPU ed è per questo che, quando si valuta l’hardware, è necessario prendere in considerazione i server più espandibili in questo senso. Il discorso server si complica un pochino se l’infrastruttura è complessa. In questo caso, spesso, si preferiscono soluzioni più “dense” basate su piattaforme blade. I blade sono particolari server montati su degli chassis (non standard) che hanno diversi vantaggi in termini di compattezza fisica, interconnessione fra le blade integrata e un unico punto di management del sistema. il server blade, in passato, aveva dei seri problemi di espandibilità del singolo nodo, ma le ultime generazioni (di tutti i server vendor) hanno un po sfatato questo mito. In questo caso, a fronte di un notevole risparmio in termini di corrente elettrica, una migliore gestione complessiva e meno cavi c’è lo scotto da pagare di doversi legare in maniera più importante al vendor. Nel campo delle blade esistono anche delle soluzioni di particolare eccellenza che integrano una parte di virtualizzazione dell’hardware molto utile se usata correttamente ma che purtroppo non sono alla portata di tutti.

lo storage

Tutti gli storage (certificati) funzionano. Il problema, poi, non è più il fatto che uno storage funzioni o meno ma tutto si riconduce all’efficienza! Efficienza significa principalmente: automazione, integrazione, facilità d’uso, funzionalità avanzate. Non esiste una soluzione uguale per tutti e i produttori variano da chi fornisce una “banale” scatola di dischi con controller RAID senza funzionalità a sistemi complessi che implementano in hardware molte funzionalità altrimenti delegate agli strati superiori, ovviamente anche i prezzi sono molto diversi e tutto dipende da come l’azienda valuta il rapporto tra TCA e TCO (costo di acquisto contro costo totale nel tempo – compresa la gestione). Quando si effettua la scelta per la soluzione di storage più indicata al proprio progetto di virtualizzazione, è bene tenere a mente, avrò a che fare con problematiche diverse da quelle cui si era abituati a vedere in precedenza: prima, ogni server ospitava un S.O. e una applicazione con il suo set di dati su un disco/volume specifico ora, molto probabilmente, ogni server fisico ospiterà decine di VM con relativi S.O., Applicatizioni e dati: i workload e le necessità di throughput si complicheranno notevolmente. Più l’infrastruttura è complessa e critica e più avrò bisogno di strumenti che mi permettano di isolare e monitorare ogni parametro dello storage. Un’altro fattore fondamentale dello storage è la scalabilità, acquistare un sistema troppo ritagliato per le esigenze attuali e poco espandibile può facilmente generare spiacevoli sorprese (anche nel breve periodo). I produttori di hypervisor mettono a disposizione dei vendor alcune API per integrare al meglio lo storage con gli strati superiori, il primo passo verso l’integrazione passa proprio da qui: se l’HW e lo storage sanno vicendevolmente con chi hanno a che fare è molto probabile che alcune funzionalità verranno delegate all’hardware sottostante limitando inutili sprechi di risorse di calcolo e memoria e velocizzando di molto le operazioni. Molti storage vendor hanno poi realizzato dei plug-in per le console di management in modo da rendere più semplice (in alcuni casi quasi trasparente) l’amministrazione, il (self-)provisioning e il monitoring dello storage da parte degli amministratori, rendendo così la console dell’hypervisor il punto centrale di amministrazione di tutta l’infrastruttura. Ultimo, ma dovrebbe essere sempre il primo, più ancora delle funzionalità, è il supporto tecnico. E’ indispensabile che il sistema di storage che adottiamo per la nostra infrastruttura sia proattivo e avvisi prontamente chi di dovere (in molti casi anche il vendor stesso) di un possibile guasto o di una deriva particolare sul fronte prestazioni o uso di spazio.

gli stack

Molti produttori spingono per l’adozione di stack tecnologici preconfigurati o, perlomeno, pre-certificati. Lo fanno principalmente per due motivi:

  1. Commercialmente è molto meglio (per il vendor) perchè possono vendere un pacchetto di hardware (in alcuni casi hardware + software + servizi) molto più importante e quindi guadagnarci di più.
  2. E’ molto più facile nascondere le pecche di una singola componente dell’infrastruttura in una offerta globale dove il cliente compra la “soluzione” e non indaga particolarmente a fondo su cosa c’è dentro
  3. Si riesce ad incatenare molto meglio il cliente con una soluzione chiusa che poi non avrà via di scampo per i futuri aggiornamenti.

Questo approccio ha comunque degli aspetti positivi dovuti alla semplificazione: un unico numero da chiamare, un unico referente commerciale, una teorica omogeneità nella documentazione, nella qualità del servizio e nei tempi di risposta del supporto.
Affidarsi ad uno stack tecnologico da un unico fornitore può essere una ottima soluzione quando l’aspetto tecnico del progetto è meno importante di quello organizzativo e magari l’azienda non ha risorse umane adeguate per gestire infrastrutture tecnologiche complesse o una cultura aziendale sufficiente a prendere decisioni di questo tipo. E’ bene comunque fare molta attenzione sulla differenza che passa fra uno stack tecnologico integrato e una offerta completa ma di tutte componenti separate e disaggregate. L’esempio classico è quello dell’assistenza: posso telefonare ad un unico numero che vede il mio stack come una unità? oppure devo specificare già alla prima chiamata su quale (degli N) strati dello stack penso di avere il problema? e se poi ho sbagliato? succede come con il gioco dell’oca: riparti dal via!

Per oggi ho finito. La prossima volta affronterò: la migrazione da fisico a virtuale, i rischi della virtualizzazione selvaggia, virtualizzare e consolidare.