Chi amministra un cluster VCF 9.0 su vSAN decide continuamente due cose che sembrano separate e non lo sono: quante rotture il dato deve sopravvivere, e quanto spazio è disposto a pagare per sopravvivere. Si esprimono entrambe nello stesso posto — una VM storage policy — e l’obiettivo 2.3 le mette volutamente sullo stesso tavolo.

Oggetti, componenti e stati di guasto

vSAN non ragiona per LUN ma per oggetti: «vSAN stores and manages data in the form of flexible data containers called objects», ciascuno con dati e metadati distribuiti sul cluster. Ogni oggetto è fatto di componenti, e quali componenti esistano lo decide la policy applicata. Fra questi c’è il witness, «a component that contains only metadata and does not contain any actual application data», che serve da arbitro quando bisogna stabilire chi sopravvive a una partizione.

Quando qualcosa si rompe, un componente finisce in uno di due stati, e la distinzione è la prima cosa che l’esame verifica. Degraded è lo stato in cui vSAN «detects a permanent component failure and assumes that the component is not going to recover»: guasto di un dispositivo di cache flash, di un dispositivo di capacità, di uno storage controller. Absent è invece il guasto potenzialmente temporaneo: perdita di connettività di rete, scheda di rete fisica guasta, host ESX caduto, dispositivo scollegato. Il comportamento operativo cambia di conseguenza: sui degraded vSAN ricostruisce subito, se ci sono risorse adeguate nel cluster; sugli absent aspetta, perché il componente potrebbe tornare, e «by default, vSAN starts rebuilding absent components after 60 minutes». È esattamente il motivo per cui un reboot di manutenzione non innesca una risincronizzazione dell’intero cluster.

Le opzioni di resilienza: FTT, metodo e fault domain

La policy si crea da Policies and Profiles > VM Storage Policies; la pagina vSAN ha le tab Availability, Storage Rules, Advanced Policy Rules e Tags. In Availability vivono le due regole che contano: Site disaster tolerance e Failures to tolerate.

FTT ammette 0 (nessuna ridondanza), 1 (RAID-1 o RAID-5), 2 (RAID-1 o RAID-6) e 3 (solo RAID-1). La regola di conteggio è che «for n failures tolerated, each piece of data written is stored in n+1 places, including parity copies if using RAID-5 or RAID-6». Da qui la prima domanda di scenario: RAID 5 richiede quattro o più fault domain all-flash, RAID 6 sei o più, e l’erasure coding «does not support a Failures to tolerate value of 3». Su ESA il RAID-5 è adattivo: schema 2+1 sotto i sei host, 4+1 da sei in su, con riassestamento del formato dopo 24 ore.

I fault domain sono il livello a cui il conto va fatto davvero: proteggono da guasti di rack o chassis, servono almeno tre («for best results, configure four or more»), la formula è 2n+1 per FTT=n — quindi cinque per FTT=2 — e attenzione al dettaglio che l’esame ama: «a host not included in any fault domain is considered to reside in its own single-host fault domain». Domini di dimensione disuguale sbilanciano il posizionamento.

Topologie: due host, stretched cluster, cluster disaggregati

Un cluster standard vuole «a minimum of three ESX hosts that contribute capacity». Il cluster a due host è composto da due data host più un witness esterno, tipicamente un’appliance virtuale in un altro sito; un witness condiviso «can support up to 64 two-node vSAN clusters», in funzione della memoria dell’host, e si assegna con tasto destro sul cluster > vSAN > Assign Shared Witness.

Lo stretched cluster distribuisce gli host su due siti, uno designato preferred e l’altro secondary, con un witness al terzo sito che tiene solo metadati «such as the size and UUID of vSAN object and components» e che deve avere un VMkernel adapter con traffico vSAN verso tutti gli host; la latenza ammessa è al massimo 5 ms RTT. Qui Site disaster tolerance va su «Site mirroring - stretched cluster» e Failures to tolerate diventa la protezione locale dentro ciascun sito. Se cade il witness «all corresponding objects become noncompliant but are fully accessible»: non è un outage, è una non conformità.

In VCF lo stretch non si fa a mano: passa dall’API di SDDC Manager, le due availability zone devono avere lo stesso numero di host, il cluster di default del management domain va steso prima di qualunque workload domain, e l’operazione è preclusa se la policy vSAN è condivisa con altri cluster, se gli host sono DPU-backed o se stanno su subnet diverse.

Space efficiency: quattro leve e il loro prezzo

La prima leva è il thin provisioning, esposto come Object space reservation (default Thin provisioning; il Thick annulla i benefici di deduplica e compressione). La seconda è l’erasure coding: «a virtual machine protected by a Failures to tolerate value of 1 with RAID 1 requires twice the virtual disk size, but with RAID 5 it requires 1.33 times the virtual disk size» — e su ESA con cinque fault domain lo schema 4+1 scende ancora. Richiede all-flash, on-disk format 3.0 o successivo e una licenza valida.

La terza leva sta nella tab Storage Rules, regola Space Efficiency, con valori Deduplication and compression, Compression only, No space efficiency, No preference. Qui ESA e OSA divergono: in OSA la deduplica «are enabled as a cluster-wide setting, but they are applied on a disk group basis»; in ESA la deduplica non c’è, la compressione è a livello di oggetto ed è attiva di default via policy, e vale «only for new writes. Old blocks are left uncompressed». Il prezzo operativo di OSA è alto: abilitare o disabilitare comporta «a rolling reformat of every disk group or storage pool on every host», non si rimuove un singolo disco da un disk group, un solo disco guasto fa cadere l’intero disk group, e su VM cifrate il risparmio è quasi nullo.

La quarta leva è il recupero dello spazio già scritto: SCSI unmap. «Unmap capability is not enabled by default»: si attiva con Guest Trim/Unmap nella tab Advanced options dei vSAN Services, richiede virtual hardware 13 o superiore e impone di spegnere e riaccendere tutte le VM. Dal guest si sfrutta con fstrim(8) o mount -o discard su Linux, mentre NTFS fa unmap inline di default.

Infine, ricordare che un cambio di policy non è istantaneo: «vSAN batches the policy change requests and performs them asynchronously», genera capacità transitoria, e certe transizioni vengono respinte subito — come passare da RAID-5 a RAID-6 su un cluster di cinque host. Il posizionamento effettivo si verifica in Monitor > vSAN > Virtual Objects > [VM] > View Placement Details.

Trappole tipiche d’esame

  • Absent contro degraded. I 60 minuti di attesa valgono solo per gli absent. Uno scenario che descrive un controller o un disco guasto (degraded) e chiede «quanto aspetta vSAN» sta cercando la risposta «ricostruisce subito, se ci sono risorse».
  • FTT=3 con erasure coding. RAID 5/6 non supporta FTT 3: se lo scenario chiede tre guasti tollerati, l’unica risposta è RAID-1, con il costo di capacità che ne consegue.
  • Host contro fault domain. La regola 2n+1 si applica ai fault domain, non agli host, e un host lasciato fuori da ogni fault domain conta come dominio a sé — cosa che silenziosamente rende conforme (o non conforme) un cluster che a occhio sembrava a posto.
  • Deduplica su ESA. Non esiste: ESA ha solo compressione, per oggetto e attiva di default via policy, mentre la deduplica è un tratto OSA a scope di disk group. Allo stesso modo, in ESA il checksum «is always on and cannot be deactivated», quindi Disable object checksum è una leva OSA.
  • Site disaster tolerance contro Failures to tolerate in stretched cluster. La prima protegge fra i siti, la seconda protegge dentro un sito. Uno scenario che chiede di sopravvivere alla perdita di un sito e a un guasto locale richiede entrambe le regole, non una sola alzata di FTT.