In un’infrastruttura VMware vSAN, il parametro Failures to Tolerate (FTT) definisce quanti guasti contemporanei il cluster può sopportare senza perdita di dati o interruzioni di servizio. Capire e modificare correttamente questo valore è fondamentale per garantire la disponibilità e la resilienza del tuo ambiente virtuale.
Cosa significa FTT
- FTT=1: il sistema può tollerare un guasto (es. un host o un disco).
- FTT=2: il sistema può tollerare due guasti simultanei, aumentando l’affidabilità ma anche il consumo di spazio.
Ogni incremento di FTT comporta una replica aggiuntiva o una maggiore parità dei dati, quindi è importante pianificare con attenzione le risorse del cluster.
In questo articolo vediamo i passaggi per passare da un settaggio FTT=1 ad un settaggio FTT=2
Prerequisiti
- Controlla lo stato di salute del cluster vSAN in vCenter → Cluster → Monitor → vSAN → Health.
- Verifica di avere almeno 3 nodi per FTT=1 e 6 nodi per FTT=2.
- Assicurati che ci sia spazio libero sufficiente per ospitare le copie aggiuntive.
| FTT | Tipo di Protezione | Guasti tollerati | Requisiti minimi di nodi | Overhead di spazio |
| 0 | Nessuna replica | 0 | 1 | 1x |
| 1 | Mirroring (RAID-1) o Parity (RAID-5) | 1 | 3 (RAID-1) / 4 (RAID-5) | 2x (RAID-1) / 1.33x (RAID-5) |
| 2 | Mirroring (RAID-1) o Parity (RAID-6) | 2 | 5 (RAID-1) / 6 (RAID-6) | 3x (RAID-1) / 1.5x (RAID-6) |
| 3 | Solo RAID-1 | 3 | 7 | 4x |
Nota per vSAN 8.0 ESA
Con l’introduzione di vSAN 8 e dell’Express Storage Architecture (ESA), alcuni comportamenti legati al parametro Failures To Tolerate (FTT) sono stati ottimizzati.
In ESA, i profili RAID-5 e RAID-6 si basano su erasure coding più efficiente, e l’overhead prestazionale rispetto al mirroring è minimo. Tuttavia, i requisiti minimi di host restano fondamentali:
- FTT=1 con RAID-5: minimo 4 host (configurazione 3+1)
- FTT=2 con RAID-6: minimo 6 host (configurazione 4+2)
VMware consiglia di avere un host aggiuntivo rispetto al minimo per garantire piena tolleranza anche durante la manutenzione o i rebuild.
Per chi utilizza ancora l’architettura OSA (Original Storage Architecture), i requisiti e i comportamenti restano invariati rispetto alle versioni precedenti (FTT=1 → 3 host, FTT=2 → 6 host).
Suggerimento: Auto-Policy Management
Dalla versione vSAN 8.0 Update 1, è disponibile la funzione Auto-Policy Management, che consente al cluster di proporre automaticamente la policy di storage più efficiente in base al numero di host e alla configurazione ESA.
Questa opzione non modifica automaticamente le VM esistenti, ma offre una guida utile per creare nuove policy ottimizzate senza rischi di configurazione errata.
… in parole semplici
FTT definisce quante copie o parità dei dati vSAN deve creare per garantire la resilienza contro i guasti.
- FTT = 0 → nessuna tolleranza, se un nodo o disco si guasta, i dati vanno persi.
- FTT = 1 → i dati vengono replicati o codificati in modo da sopravvivere a 1 guasto.
- FTT = 2 → i dati resistono a 2 guasti simultanei, e così via.
vSAN può applicare FTT in due modi principali:
| Tipo | Descrizione | Minimo nodi | Overhead |
| RAID-1 (Mirroring) | Ogni dato è copiato su più nodi | 3 per FTT=1 | 2× spazio |
| RAID-5/6 (Erasure Coding) | Dati + parità distribuiti | 4 (RAID-5) o 6 (RAID-6) | 1.33× o 1.5× spazio |
Esempio pratico:
- Una VM con FTT=1 in RAID-1 → due copie dei dati (una primaria e una replica).
- Con FTT=2 → tre copie (primaria + 2 repliche).
Impatti pratici
| FTT | Guasti tollerabili | Copie dati | Overhead | Nodi minimi |
| 0 | Nessuno | 1 | 1× | 1 |
| 1 | 1 | 2 | 2× (RAID-1) / 1.33× (RAID-5) | 3 / 4 |
| 2 | 2 | 3 | 3× (RAID-1) / 1.5× (RAID-6) | 5 / 6 |
| 3 | 3 | 4 | 4× | 7 |
Cosa controllare prima di applicare la modifica
di seguito una checklist che ti suggerisco di verificare prima di procedere, per mitigare rischi:
- Numero di host
Assicurati che il cluster abbia almeno 6 nodi se intendi adottare una policy con FTT=2. Se hai meno di 6 nodi, potrai solo usare FTT=1 (mirroring o RAID-5, secondo configurazione). - Capacità residua / overhead disponibile
Calcola lo spazio occupato attualmente e lo spazio richiesto per la nuova policy (considerando l’overhead del mirroring/erasure coding). Verifica che ci sia margine sufficiente per far transitare gli oggetti “out of compliance” durante la transizione. - Finestra operativa / carico
Pianifica la modifica in un orario di minima attività (se possibile). Durante la ricostruzione ci può essere un impatto I/O che può degradare le performance delle VM. - Monitoraggio / Health / Compliance
Tieni d’occhio il pannello vSAN Health “resyncing objects” e “compliance”. Assicurati che tutti gli oggetti tornino conformi. - Test in ambiente non produzione (se possibile)
Se hai un cluster di test o staging simile, prova la modifica prima in quell’ambiente per valutare il comportamento. - Backup / piano di rollback / rischi accettabili
Anche se la modifica di policy non distrugge dati, devi avere un piano per intervenire se la risincronizzazione si blocca o se il cluster entra in stato degradato. Identifica come tornare all’impostazione precedente con la policy originaria e verifica che i dati rimangano accessibili anche se in stato degradato. - Verifica compatibilità delle VM critiche / workload IOPS intensivi
Alcuni workload (database, storage intensivo) potrebbero risentire di fasi transitorie. Valuta quali VM possono essere migrate temporaneamente, spostate su politiche meno rischiose, ecc. - Valutare l’Auto-Policy Management
Se il cluster è aggiornato almeno a vSAN 8 U1, considera di attivare “Auto-Policy Management” per avere suggerimenti su policy default ottimali. Questo non farà cambiamenti automatici alle VM, ma ti dà un orientamento.
Impatti di spazio (valori chiave)
- RAID-1 (FTT=1, mirroring) → 50% utilizzabile (ovvero 2× spazio richiesto).
- RAID-5 / EC for FTT=1 (es. 3+1) → 75% utilizzabile (fattore ~1.33× spazio).
- RAID-6 / EC for FTT=2 (es. 4+2) → 66.67% utilizzabile (fattore 1.5× spazio).
Procedura passo-passo:
- Dal menù (hamburger) del vCenter Server selezionare: Menu -> Policies and profiles:
- Selezionare la Policy utilizzata e cliccare su Clone:
Nota: in questa procedura andremo a clonare la Storage policy di default, invece che crearne una nuova (consigliato).
- Inserire un nome per la nuova policy (clonata):
- Lasciare invariati i settaggi e proseguire:
- Modificare il parametro “Failures to tolerate” in “2 failures – RAID-6”:
- Lasciare i parametri invariati e proseguire:
- Lasciare i parametri invariati e proseguire
Nota: nelle VMs che hanno un database è consigliato cambiare “Object space reservation” da “thin” a “thick”.
Cambio della Storage Policy a livello di Virtual Machine (test):
- Selezionare la virtual machiine a cui applicare la nuova storage policy:
- Cliccare sul menù “Configure”:
- Dal menù “Settings” selezionare “Policies”:
- Aprire il menù a tendina della sezione “VM storage policy”:
- Selezionare la storage policy clonata a cui è stato cambiato il settaggio in “2 failures – RAID-6”:
Note: selezionando la “VM -> Configure -> Policies” si può visualizzare se la storage policy è stata applicata correttamente:
Sostituzione della “Default Storage Policy” vSAN Datastore
- Selezionare l’icona “Storage”:
- Selezionare il Datastore vSAN:
- Cliccare su “Configure”:
- Nella sezione “Default Storage policy” cliccare su “Edit”:
- Cambiare la Storage policy e premere il tasto “ok”:
Cosa monitorare
Durante la ricostruzione, tieni d’occhio:
- Lo stato di Compliance nella scheda Monitor → vSAN → Virtual Objects.
- L’attività di Resyncing Components, che mostra l’avanzamento della sincronizzazione.
- Le prestazioni del cluster, poiché l’operazione può influire temporaneamente su I/O e latenza.
Conclusione
In conclusione, configurare la vSAN con FTT=2 garantisce un livello elevato di resilienza e disponibilità dei dati, permettendo al cluster di resistere a guasti multipli.
Pur richiedendo più risorse, questa scelta offre una base solida per la business continuity e una crescita infrastrutturale sicura e affidabile.
By: Alessandro Romeo – Enjoy 👍