In vSphere Foundation vSAN è lo storage di serie, ed è dove la confusione con VMware Cloud Foundation costa cara: in VVF non c’è NSX e non ci sono workload domain, quindi il cluster vSAN lo costruisci col networking di vSphere — VMkernel adapter, port group, distributed switch.

I prerequisiti che bloccano davvero

Un cluster standard vuole almeno tre host ESX che contribuiscono capacità; l’alternativa è il cluster a due host con witness esterno. Un host vSAN non può partecipare ad altri cluster.

Sull’hardware le architetture divergono. ESA vuole almeno un dispositivo NVMe TLC per storage pool e 128 GB di memoria per host. OSA vuole, per ogni disk group, un solo dispositivo cache (SSD SAS/SATA o flash PCIe, almeno il 10% della capacità prevista) e uno o più capacity, dietro un HBA SAS/SATA o un RAID controller in passthrough o RAID 0.

La rete è il prerequisito più sottovalutato: ogni host deve avere un VMkernel adapter per il traffico vSAN anche se non contribuisce capacità. OSA chiede 1 GbE dedicata in hybrid e 10 GbE in all-flash; ESA parte da 10 GbE, con 25 GbE o più raccomandati. La latenza massima è 1 ms RTT in single-site, 5 ms fra i siti di uno stretched, 200 ms verso il witness.

Infine, vSphere HA non deve essere attivo quando abiliti vSAN: lo disattivi, abiliti vSAN, lo riabiliti. Da lì il suo traffico interagente viaggia sulla rete vSAN, non sulla management.

Il wizard, e il claim dei dischi

Il percorso è Cluster > Configure > vSAN > Services, poi Configure. Prima il tipo — vSAN HCI, Compute Cluster (solo calcolo, monta datastore remoti) o vSAN Storage Cluster (solo storage) — poi il modello: Single site, Two node o stretched. Segue ESA o OSA, più vSAN managed disk claim (rivendica da sé i dischi compatibili, anche sugli host futuri) e Auto-Policy management (tiene la default coerente col cluster). Nei servizi accendi deduplica e compressione, data-at-rest e data-in-transit encryption, RDMA; poi claim dei dischi, fault domain opzionali e Finish. A valle verifichi datastore, Skyline Health e storage provider.

Il claim si rifà in Configure > vSAN > Disk Management, Claim Unused Disks. In ESA i dispositivi finiscono in uno storage pool per host, senza cache e capacity. In OSA costruisci disk group: il flash con Claim for cache tier, i dischi di capacità con Claim for capacity tier. Un disk group ha un solo dispositivo cache.

Sui fault domain vale un’aritmetica: per tollerare n guasti servono almeno 2n+1 fault domain, quindi 3 per FTT=1 (4 raccomandati) e 5 per FTT=2. Un host non assegnato conta come fault domain a sé. Quickstart è l’alternativa guidata, ma pretende host a ESX 9.0 o superiore, allineati come patch e senza configurazioni di rete o vSAN preesistenti; e se lo salti non lo recuperi.

Le regole di una storage policy

Nella scheda Availability, Site disaster tolerance sceglie fra None (standard, default), Host mirroring per i due nodi e Site mirroring per lo stretched. Failures to tolerate dice quanti guasti l’oggetto sopporta: per n guasti il dato sta in n+1 posti, parità compresa. Si va da No data redundancy a 1 failure RAID-1 o RAID-5, 2 failures RAID-1 o RAID-6, 3 failures RAID-1. In ESA il formato lo sceglie vSAN: RAID-5 2+1 sotto i sei host, 4+1 da sei in su; RAID-6 consuma 150 GB ogni 100 GB di oggetto.

Storage rules copre encryption services, space efficiency e storage tier, di default su “No preference”. In Advanced Policy Rules stanno Number of disk stripes per object (default 1, massimo 12), IOPS limit for object (0 = nessun limite), Object space reservation (Thin di default), Flash read cache reservation (0%, solo in hybrid), Disable object checksum e Force provisioning, entrambi No.

Creare, assegnare, verificare

Una policy si crea da Policies and Profiles > VM Storage Policies > Create: nome e istanza vCenter, Enable rules for vSAN storage, le schede di regole, poi Storage compatibility, dove il datastore vSAN deve comparire fra i compatibili.

La vSAN Default Storage Policy applica FTT=1, uno stripe, flash read cache reservation a 0 e disco thin. Ne modifichi le regole, non il nome, e non puoi eliminarla: la via pulita è clonarla. La default di un datastore si cambia dal datastore, non da VM Storage Policies: Configure > General > Default Storage Policy > Edit. La conformità si legge da VM > Configure > Policies > Check VM Storage Policy Compliance, con gli stati Compliant, Noncompliant, Out of Date (modificata e non riapplicata) e Not Applicable.

Un cambio di policy non è istantaneo: vSAN accorpa le richieste e le esegue in modo asincrono per contenere lo spazio transitorio, che monitori in Cluster > Monitor > vSAN > Capacity. Alcune conversioni sono rifiutate subito perché il cluster non le regge: da RAID-5 a RAID-6 su cinque host, per dire.

Trappole tipiche d’esame

  • Fault domain, non host. Per FTT=2 lo scenario offre “5 host” contro “5 fault domain”: la regola è 2n+1 fault domain, e un host non assegnato ne vale uno.
  • ESA non è OSA in salsa nuova. Niente cache tier, niente disk group: storage pool e NVMe TLC. In ESA il checksum è sempre attivo e Disable object checksum non lo spegne; Flash read cache reservation esiste solo in hybrid.
  • “Ensure accessibility” non significa conforme. In maintenance mode evacua il minimo perché gli oggetti restino accessibili, e le VM possono uscire dalla compliance; su tre host è l’unica opzione. Solo Full data migration la preserva.
  • La default policy non si cancella. Si clona, e la si elegge default dalle proprietà del datastore. Swap e oggetti di memoria la ricevono con Force provisioning a Yes.
  • vSAN e HA in sequenza. HA va disattivato prima di abilitare vSAN, e da acceso il suo traffico interagente lascia la management per la rete vSAN.