Marco Russo

Circa un mese fa ho iniziato un'operazione di server consolidation e di aggiornamento e ampliamento dei server di sviluppo che uso per molte delle mie attività.
Una premessa necessaria è che, pur avendo usato prodotti come VMware sin dalle prime versioni, ho sempre ritenuto che la perdita prestazionale fosse un prezzo molto alto da pagare per tutta una serie di casi.
Pur mantenendo una certa riserva rispetto all'uso della virtualizzazione in alcuni scenari (su cui tornerò tra poco) credo che la combinazione dell'avanzamento di hardware e software (inteso come prodotti di virtualizzazione) offra oggi una soluzione valida per innumerevoli scenari.
In questo post cerco di raccontare un po' la mia esperienza, con gli occhi dello sviluppatore che ogni tanto deve fare anche il sistemista (credo sia un'esperienza piuttosto comune).

L'idea è di partire con due server quasi gemelli (dischi, RAM, rete) e differenti solo per le CPU usate (due dual-core 2.8GHz da una parte e due Xeon "normali" ma da 3.8GHz dall'altra).
Il software di virtualizzazione usato è VMware GSX Server: Microsoft Virtual Server, per quanto stia evolvendo velocemente, è ancora distante da prestazioni e flessibilità di VMware.
Senza entrare troppo nei dettagli, su un server sono montate una decina di macchine virtuali che restano "sempre attive" e su cui girano una serie di servizi di supporto (dal Domain Controller a Vault) che devono essere sempre disponibili. Questo primo server (diciamo "di produzione") ha anche delle interfacce in DMZ e degli IP esposti (il lavoro da remoto è essenziale) e nonostante questo la sicurezza ottenuta nella separazione delle reti è uguale se non maggiore (per il controllo che è possibile) della precedente separazione (reti e macchine fisiche).
Il secondo server contiene invece SQL Server sul sistema operativo host insieme a VMware GSX Server, che consente di affiancare la piena potenza di calcolo di tutti i processori (quando si provano dei caricamenti di un Data Warehouse la potenza non basta mai) alla condivisione delle risorse con macchine virtuali "di sviluppo" (che possono essere reinstallate e/o riavviate spesso, per i più disparati motivi).
Perché mai una simile architettura? Eccone i vantaggi:

• backup di tutte le macchine virtuali fatte dal sistema operativo host (in fondo le macchine virtuali sono dei file sul disco)
• disaster recovery relativamente semplice: si ripristinano le macchine virtuali sul server superstite e i sistemi di produzione ritornano operativi con un fermo macchina minimo (compatibile con le esigenze operative interne, insomma)
• gestibilità: creare o spostare una macchina virtuale è estremamente semplice e si può fare tutto da remoto, con vari tool di amministrazione che consentono di variare tutti i parametri fisici delle macchie virtuali
• costi: forse è la cosa più importante, ma dal mio punto di vista la flessibilità e il minor tempo necessario per la manutenzione ha un valore ancora maggiore del risparmio sull’hardware “fisico”. Comunque, giusto per fare qualche conticino, un server da meno di 6.000€ tiene in piedi una decina di macchine virtuali e resta ancora un po’ di spazio (RAM in particolare) per aumentare il carico. È indubbio che un numero pari di macchine con caratteristiche hardware equivalenti a ogni macchina virtuale costerebbe di più (i dischi sono Ultra SCSI 320 da 15.000 rpm in mirror).
• licenze: come ho detto, tutto l’ambiente serve per fare sviluppo e test e quindi per le licenze di VMware GSX Server si può ricorrere alla VMTN Subscription, un contratto analogo a quello di MSDN (Microsoft) con cui è possibile utilizzare i prodotti VMware per scopi di sviluppo (con alcune limitazioni che però nel nostro caso non costituivano un problema).

Qualche considerazione sulle risorse necessarie.

1. RAM: tanta. Un server con meno di 4Gb è quasi inutile per fare operazioni simili. Può avere senso partire con 6Gb, con 8Gb si ha molto spazio per operare.
2. CPU: finora non è mai stato un problema, però la migrazione di tutti i servizi richiederà ancora tempo e quindi, anche se le macchine virtuali sono già tutte definite, non sono ancora tutte attive, quindi il consumo per ora non è significativo. Poi ovviamente dipende tutto dalle applicazioni e dal carico applicato...
3. LAN: avere tante prese di rete è la cosa migliore perché garantisce la possibilità di allestire le configurazioni più strane. Come minimo è bene avere due collegamenti, ma con quattro sicuramente non si sbaglia. Bisogna ricordare che un serve che ospita macchine virtuali è come se fosse una server farm: progettereste il telaio limitando i collegamenti di tutte le macchine a un unico hub?

Come ho detto prima, esistono ancora dei limiti che però saranno presto superati. Il più grande è che l'attuale versione di VMware GSX Server non fornisca a ciascuna macchina virtuale più di un processore. Questo limite, insieme a un certo rallentamento sulle operazioni di I/O, mi fa scegliere di usare una macchina "fisica" per ospitare SQL Server 2005 e Analysis Services. Ma le prossime versioni supereranno almeno il limite dei processori (VMware workstation già lo fa), mentre per la penalizzazione sulle operazioni di I/O dovrò tornare sull'argomento più avanti, l’argomento richiede studi approfonditi.

A questo punto devo fare un doveroso ringraziamento per tutto ciò che ho imparato nonché per il fatto che nell'arco di due giorni ci fosse dal nulla un'infrastruttura funzionante (praticamente un datacenter visto il numero di macchine virtuli)... Il grazie va ad Alessandro Perilli, che oltre a essere un esperto di virtualizzazione e sicurezza mantiene anche un seguitissimo blog [in inglese] sulla virtualizzazione (http://virtualization.info) che è una grande miniera di informazioni, novità e riferimenti su tutti i prodotti relativi alla virtualizzazione.