Virtualizzazione ed HA, la prova dei fatti

Sto seguendo con un certo interesse la discussione avviata da Giorgio Malusardi in un suo post, riprendendo la discussione avviata da Mike DiPetrillo di Vmware.

Altri interventi illustri sono di Massimo Re Ferré di IBM (con cui ho avuto il piacere di collaborare nel primo progetto di Infrastruttura di produzione internet della mia azienda) che riprende ed amplia il discorso parlando di una nascente  IT 2.0.

Oggi Giorgio riprende la discussione segnalando un post nel Virtualization Team Blog di Microsoft.

Già ieri stavo valutando un mio intervento nella discussione per apportare quella che, nel mondo della erogazione di servizi su Internet, credo sia una esperienza valida.

Nell 2004/5 abbiamo iniziato ad introdurre la tecnologia di virtualizzazione (dopo averla a lungo usata sui desktop per test e sviluppo) anche in produzione per erogare servizi su Internet.

Principalmente la soluzione di VMware è stata primariamente utilizzata per virtualizzare, con il P2V vecchi server che comunque avevano ancora applicazioni valide da erogare per abbassare i costi di manutenzione di hardware vecchio.

Nel corso del 2006, alla disponibilità di VI3 con HA e DRS, abbiamo usato la soluzione di virtualizzazione anche per la progettazione di una nuova infrastruttura su 2 siti geografici.

Ad oggi, dopo 2 anni di go-live, possiamo già trarre alcuni insegnamenti che mi piacerebbe introdurre nella un pò troppo accademica discussione sulle tecnologie (non comparabili, in realtà) di QuickMigration e vMotion.

La QuickMigration altro non è che il failover cluster di Windows Server 2008 applicato ai servizi di virtualizzazione di Hyper-V. Il vMotion con HA e DRS è la possibilità di spostare una macchina, senza alcuna interruzione nell’erogazione dei servizi, in caso di manutenzione programmata o di ribalanciamento del carico  sugli host.

La precisazione appena fatta è importante per capire la reale portata e contesto di utilizzo di queste tecnologie. In caso di crash dell’hardware (host), del crash della macchina virtuale (guest) HA non fa altro che far ripartire rebootando il server virtuale su un nuovo host esattamente come QuickMigration.

Questo provoca comunque un disservizio la cui durata è proporzionale alla configurazione (leggasi software al suo interno e configurazione dei dischi).

Nel caso degli SQL Server o di Oracle (lo so sto bestemmiando…) la cosa si complica ulteriormente dovendo effettuare del recovery sul DB.

Dalla mia esperienza dunque nessuna delle soluzioni, in caso di malfunzionamento, assicura la continuità del servizio ed anzi i tempi di ripristino possono anche essere enormemente più lunghi di quelli di una coppia di server fisici in cluster di failover in considerazione dell’enorme carico che si finisce per mettere sugli host.

Dunque il nuovo paradigma per l’IT al momento è ancora largamento incompleto ed inefficiente nella parte più complessa e che, paradossalmente, meno dovrebbe accorgersi della virtualizzazione: il management e lo sviluppo.

Nella mia personale esperienza la gestione delle macchine virtualizzate aumenta in maniera considerevole la complessità della farm nel suo insieme dovendo tenere conto di nuove e, a volte, poco evidenti variabili legate alle nuove funzionalità della piattaforma di virtualizzazione.

Per quanto riguarda il software diventa ancora più critica diventa la fase di progettazione e implementazione delle policy di recovery delle applicazioni che non può dare per scontata la disponibilità di servizi e il loro recovery da failure in tempi ristretti.

Aggiungiamo che diventa ancora più critica la policy di recovery visto che, come fa giustamente notare il blog del Virtualization Team di Microsoft, la perdita di un host virtuale è un vero disastro.

Infine esiste un fenomeno degenerativo che accelera le problematiche appena esposte: fare macchine virtuali è troppo facile, troppo più facile che fare applicazioni performanti e quindi, ironia delle sorte rispetto alla consolidation, si moltiplicano in maniera esponenziale i server.

Dunque la virtualizzazione va “corretta” con un approccio pragmatico su alcuni ruoli che, a mio giudizio, vanno tenuti fisici (grossi database cluster in primis), con l’aumento di utilizzo convinto di sistemi di gestione vm-aware, l’adozione coscenziosa e costante di metodologie di progettazione e realizzazione di software assolutamente collaudate (ITIL, ad esempio)

Nessuna delle tecnologie di migrazione potrà mai risolvere il problema alla base del successo (o del fallimento) delle infrastrutture tecnologiche.