This post is also available in: Inglese

Come probabilmente avrete notato, la funzionalità di VMware chiamata vSphere Fault Tolerance non è poi cambiata molto da quando era stata introdotta (in vSphere 4.x)… Almeno fino ad ora.

Con vSphere 6.0, annunciato di recente, vi sarà una nuova versione di FT Multi-Processore (SMP-FT) che sostituirà in toto la versione precedente e permetterà nuovi scenari di HA anche per VM fino a 4 vCPU!

Ad essere onesti non è una grande novità nel mondo della virtualizzazione: vari anni fa Marathon aveva annunciato everRun MX che già permetteva un FT multiprocessore, ma solo in ambiente Citrix XenServer. I piani dell’azienda erano di fare un porting anche per Linux e vSphere, ma successivamente fu acquisita da Stratus Technologies e everRun MX è oggi un prodotto Windows.

Ma torniamo alla nuova versione di VMware vSphere 6.0 Fault Tolerance. Sicuramente il supporto multiprocessore è la prima nuova funzonalità che salta all’occhio, ma non è l’unica; troviamo anche:

• Enhanced virtual disk format support (non solo supporta i dischi eager thick, ma tutti i tipi di VMDK)
• Possibilità di configurare a caldo FT (in realtà, con certi limiti, si poteva anche prima)
• Miglioramente nei requisiti riguardo la host compatibility
• Supporto alle snapshot, senza disattivare FT
• Supporto alle vStorage APIs for Data Protection (VADP), ossia compatibilità con i programmi di backup nativi

Notare che in realtà vi è una differenza tra le diverse edizioni di vSphere: secondo la tabella comparativa, solo l’edizione Enterprise Plus (o la Branch Office Advanced) supporterà i 4 processori virtuali! Per le edizioni Standard ed Enterprise vi è un limite di 2 vCPU.

Un prodotto sostanzialmente nuovo

FT “6.0” è sostanzialmente differente rispetto ad FT “1.0”: differente implementazione, differente archittettura, differenti requisiti e, naturalmente, differenti funzionalità.

L’aspetto interessante è che benché sia differente, l’interfaccia grafica non è cambiata e tutto è, apparentemente, come prima, facilitando ma migrazione (un po’ come era avvenuto con il nuovo vSphere HA nella versione 5.x).

Nella precedente versione FT utilizzava una tecnologia chiamata VMware vLockstep (con requisiti anche hardware) per tenere sincronizzata la VM secondaria, facendole eseguire le medesime istruzione della primara (a parte le scritture sul disco). Ora si utilizza una nuova tecnologia chiamata Fast Checkpointing che è molto più veloce e permette una copia continua dei checkpoint della VM primaria.

Molto diversa anche la parte storage: al fine di implementare alcune funzioni, come il supporto alle snapshot, è stata stravolta ed ora anche lo storage è fault tolerant.

Invece che avere come requisito obbligatorio un datastore condiviso (e i VMDK preparati ad hoc, in formato eager thick), ora è possibile utilizzare anche due datastore distinti. In particolare ogni VM avrà i suoi file:

• VMX config file: come già avveniva prima
• VMDK file: ora privati e distinti tra primaria e secondaria

Ci sono le snapshot?

Questo punto forse è il meno chiaro (sulla carta): le VM protette con FT ora si possono sottoporre a backup usando programmi nativi per VMware (prima si potevano comunque sottoporre a backup usando programmi tradizionali ad agenti e considerando queste VM come se fossero “macchine fisiche”).

I programmi di backup nativi usano delle API specifiche (VADP) che lavorano utilizzando le snapshot di VMware.

Questo però funziona solo per i backup, l’utente non potrà (almeno non dalla GUI e probaibilmente neppure dalla CLI) eseguire una snapshot manualmente. Le snapshot funzioneranno solo tramite VADP.

Ma è tutto rose e fiori?

Sicuramente siamo di fronte ad un gran passo avanti rispetto alle versioni precedenti (o meglio, dovremmo dire alla versione precedente, dato che nulla era cambiato su questo fronte)… ma non sarà tutto così bello come sembra.

Prima di tutto (ma è facilmente intuibile) il nuovo FT sarà più ingordo di risorse: più CPU ovviamente corrispondo a più risorse. E avrà comunque un impatto non solo sulle risorse, ma anche sulle prestazioni della VM (ma questo accadeva anche nella versione precedente): circa un 10-­30% di overhead a seconda del tipo di workload.

La replica dello storage comporta poi anche un utilizzo molto maggiore di banda sul canale dedicato ai log di FT (la parte di rete e di vmkernel rimane concettualmente simile) dato che ora dovranno passare più informazioni. Ed infatti si ha come requisito l’uso di schede 10 Gbps dedicate ad FT (al momento la beta supportava anche schede a 1 Gbps, ma con un evidente warning sulla compatibility non rispettata).

A causa della nuova architettura NON è possibile escludere la duplicazione dei VMDK, il che vuol dire che nei casi di datastore condiviso si avrà il doppio di spazio usato (e di I/O eseguiti). Sarebbe stato bello scegliere se avere o non avere la storage FT, ma purtroppo non è un’opzione ma fa parte dell’architettura stessa.

Vi sono poi, ovviamente, i limiti di FT che non lo rendono la soluzione per tutte le VM (e comunque non ve ne sarebbe il senso): per ogni host is possono avere un massimo di 4 VM protette da FT oppure di un massimo di 8 vCPU protette da FT. Contando sia le macchine (e vCPU) primarie che quelle secondarie.

Ricordiamoci inoltre che, anche se cambiato, vSphere FT rimane una soluzione di HA in grado di proteggere dal fallimento dell’host, ma non dal fallimento dell’applicazione o del sistema operativo guest (per questo vi sono i cluster applicativi che continuano ad avere la loro funzione).

Riepilogo

* Only for Enterprise Plus (or Branch Office Advanced) edition (for others the limit is 2)

Una nota finale: visto che ora supporta fino a 4 vCPU, ci si potrebbe chiede se VMware raccomanda FT come soluzione di HA per vCenter Servers, o almeno lo supporta… Inizialmente la risposta, purtroppo, è stata no, ma non per ragioni tecniche, più che altro per la difficoltà ad avere molti casi reali di utilizzo (un costo è testarlo in un lab, un conto è su un sistema in produzione). Pare invece che SMP-FT sarà supportato per vCenter in alcuni particoli scenari. Maggiori informazioni non appena il prodotto sarà scaricabile.

Per maggiori informazioni vedere anche (in inglese):

• vSphere 6.0 blog – Fault Tolerance
• vSphere 6: Multi-Processor Fault Tolerance (SMP-FT)
• vSphere 6 Fault Tolerance highlights and improvements
• Multiple vCPU Fault Tolerance on vSphere 6.0

Andrea Mauro

Virtualization, Cloud and Storage Architect. Tech Field delegate. VMUG IT Co-Founder and board member. VMware VMTN Moderator and vExpert 2010-24. Dell TechCenter Rockstar 2014-15. Microsoft MVP 2014-16. Veeam Vanguard 2015-23. Nutanix NTC 2014-20. Several certifications including: VCDX-DCV, VCP-DCV/DT/Cloud, VCAP-DCA/DCD/CIA/CID/DTA/DTD, MCSA, MCSE, MCITP, CCA, NPP.