Questo post è disponibile anche in: Inglese

Reading Time: 6 minutes

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).

vSphere6-FT

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

vSphere6-FT-Storage

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

Feature FT (vSphere 5.5) FT (vSphere 6.0)
vCPUs 1 4*
Virtual Disks EZT Any
Hot Configure FT No Yes
H/W Virtualization No Yes
Backup (Snapshot) No Yes
Paravirtual Devices No Yes
Storage Redundancy No Yes
VSAN/VVols No No
HA Yes Yes
DRS Partial Partial
DPM Yes Yes
SRM Yes Yes
VDS Yes Yes
Storage DRS No No
VCD No No
vSphere Replication No No

* 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):

Andrea MauroAbout Andrea Mauro (2908 Posts)

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


Related Post:

Share