Su vSphere Foundation la resilienza dello storage non si compra con un controller RAID: si dichiara in una policy. vSAN aggrega i dispositivi locali degli host ESX in un unico datastore, dove ogni VMDK, namespace, swap e delta di snapshot è un oggetto distribuito nel cluster e spezzato in componenti: repliche, stripe di dati e witness, soli metadati che fanno da arbitro nel quorum. Quante copie e dove lo decide lo Storage Policy Based Management.

Le opzioni di resilienza vivono in «Failures to tolerate»

La regola che conta è Failures to tolerate (FTT): quanti guasti di host o di dispositivo un oggetto sopporta restando accessibile. Le policy si creano in Policies and Profiles > VM Storage Policies e si assegnano alla VM o al singolo disco. Le scelte hanno nomi precisi: No data redundancy, 1 failure - RAID-1 (Mirroring), 1 failure - RAID-5 (Erasure Coding), 2 failures - RAID-1, 2 failures - RAID-6 (Erasure Coding), 3 failures - RAID-1.

La differenza è di spazio, ed è qui che resilienza e space efficiency si toccano. Il mirroring moltiplica: FTT=1 occupa il doppio dei dati (100 GB diventano 200), FTT=2 il triplo, FTT=3 il quadruplo. L’erasure coding no: su OSA il RAID 5 chiede quattro fault domain e porta 100 GB a circa 133, il RAID 6 ne chiede sei e si ferma sui 150. Su ESA il RAID 5 è adattivo — 2+1 sotto i sei host, 4+1 da sei in su, con riassetto dopo 24 ore se il cluster cambia dimensione. E l’erasure coding non supporta FTT=3.

Fault domain, stretched cluster, cluster a due host

Di default l’unità di guasto è l’host. Con i fault domain si dichiarano rack o chassis: gli host dello stesso rack stanno nello stesso dominio e vSAN non vi colloca mai due repliche. La formula è numero di fault domain = 2 * FTT + 1, con almeno tre domini e preferibilmente quattro, lo stesso numero di host ciascuno e capacità libera pari a un dominio per ricostruire. Un host lasciato fuori vale come fault domain a sé.

Se i guasti sono di sito si passa allo stretched cluster: due siti dati più un host witness in un terzo sito, che tiene solo metadati — dimensione e UUID degli oggetti. Un sito è preferred: se cade il collegamento fra i due attivi, il cluster prosegue lì. Site disaster tolerance va posta su Site mirroring - stretched cluster, mentre FTT governa la protezione locale dentro il sito. Il caso limite è il cluster a due host, col witness su un’appliance virtuale altrove: uno condiviso ne serve fino a 64.

Assente o degradato: come vSAN reagisce

Di fronte a un guasto vSAN usa due stati, e la differenza è operativa. Degraded è il guasto presunto permanente — dispositivo di capacità o di cache rotto, controller storage rotto: vSAN ricostruisce subito, se ha risorse. Absent è il guasto che potrebbe rientrare — host caduto, rete persa, NIC guasta, disco sfilato: vSAN attende e per default ricostruisce dopo 60 minuti. È l’orologio che evita una ricostruzione a ogni riavvio. Risincronizzano anche il cambio di una policy, l’evacuazione in Full data migration e la capacità oltre l’80 percento; il cambio di policy è accodato e asincrono, lo spazio transitorio si osserva in Cluster > Monitor > vSAN > Capacity, e una richiesta incompatibile col cluster è rifiutata subito.

In Maintenance Mode si sceglie fra Ensure accessibility, che sposta il minimo perché tutto resti accessibile ma può lasciare le VM non conformi, Full data migration, che evacua tutto mantenendo la conformità, e No data migration; su tre host l’unica praticabile è la prima. vSphere HA, infine, va attivato dopo vSAN, usa la rete vSAN al posto di quella di management (das.isolationaddress0 per l’isolamento) e vuole un admission control allineato a FTT.

Space efficiency: dove si risparmia e cosa si paga

Le funzioni sono cinque: SCSI unmap/TRIM, deduplica e compressione, compression-only, RAID 5 e RAID 6. Le ultime due sono resilienza che costa meno spazio, cumulabile con la deduplica.

Deduplica e compressione richiedono all-flash e, su OSA, sono un’impostazione di cluster applicata per disk group: non si accendono per singola VM via policy, e i duplicati spariscono solo dentro lo stesso disk group. Attivarle o disattivarle comporta una riformattazione a rotazione di ogni disk group o storage pool, costano circa il cinque percento della capacità grezza e vogliono Object space reservation a 0 o a 100 percento — il 100 viene rispettato, ma rende la deduplica molto meno efficace. Su ESA la compressione è attiva per default sul cluster ma agisce per oggetto, così una policy può escluderne certi workload, e comprime solo le scritture nuove.

Lo unmap chiude il cerchio lato guest: non è attivo per default, si abilita come Guest Trim/Unmap fra le opzioni avanzate dei servizi vSAN e richiede virtual hardware 13 o superiore più un ciclo di spegnimento delle VM. Poi tocca al sistema operativo: fstrim o mount -o discard su Linux, NTFS inline su Windows.

Trappole tipiche d’esame

  • Absent contro degraded. Degraded significa ricostruzione immediata, absent attesa di 60 minuti per default: lo scenario dell’host riavviato verifica esattamente questa coppia.
  • FTT non è il numero di host. Il RAID 5 su OSA vuole quattro fault domain, il RAID 6 ne vuole sei — su cinque host una policy RAID-6 è rifiutata — e l’erasure coding non arriva a FTT=3, che resta del RAID-1 a quattro copie.
  • Site disaster tolerance e FTT sono regole distinte. Nello stretched cluster la prima protegge fra i siti, la seconda dentro il sito: citarne una sola è l’errore atteso.
  • «Ensure accessibility» non vuol dire «conforme». È il default e l’unica scelta su tre host, ma lascia le VM esposte: per una rimozione definitiva la risposta è Full data migration.
  • Siamo su VVF, non su VCF. vSAN c’è, NSX no: la rete vSAN vive su VMkernel e distributed switch di vSphere, e non esistono workload domain da citare.