In VCF 9.0 lo storage non è una casella che si spunta a valle: la decisione più pesante si prende quando si crea il dominio, e da lì in avanti si può solo aggiungere, non riscrivere la scelta di fondo.

Principal e supplemental: la distinzione che viene prima di tutte

La documentazione separa il principal storage — quello dichiarato durante la creazione di un workload domain o di un cluster vSphere, e su cui i carichi girano davvero — dal supplemental storage, aggiunto in un secondo momento, che può ospitare workload oppure fare da data at rest storage per template, dati di backup e immagini ISO. I due elenchi non coincidono e non coincidono nemmeno fra domini. Per il cluster di default del management domain il principal può essere vSAN ESA, vSAN OSA, Fibre Channel o NFS. Un VI workload domain aggiunge lo Storage Cluster fra i principal e ammette come supplemental iSCSI, NVMe/TCP, NVMe/FC e NVMe/RDMA.

Il percorso reale per esercitare la scelta parte da VCF Operations → Inventory → Detailed View: si espande VCF Instances, si individua l’istanza e si fa Add Workload Domain → Create New. Superati i passi su nome, vCenter, cluster, NSX Manager e connettività di rete, il wizard presenta la schermata dello storage con quattro opzioni: vSAN (OSA o ESA), NFS, VMFS on FC e vVol, quest’ultima dichiarata deprecata e destinata alla rimozione in una release futura. Con OSA il wizard chiede Failures to Tolerate ed eventualmente deduplication and compression; con ESA chiede se il cluster è vSAN HCI o vSAN Storage e la storage policy la genera il sistema. Nel passo successivo si selezionano gli host ESX: devono essere stati commissionati con il tipo di storage corrispondente, altrimenti nell’elenco non compaiono.

Datastore tradizionali: gli stessi tre clic, due mondi diversi

VMFS e NFS si creano dallo stesso punto del vSphere Client: si seleziona un host, un cluster o un data center e dal menu contestuale Storage → New Datastore. Da lì le strade divergono.

Per VMFS il presupposto è che gli adapter (Fibre Channel, iSCSI, NVMe) siano già configurati e che sia stato fatto un rescan: se il dispositivo non è stato riscansionato, semplicemente non è nella lista. Il nome ha un limite di 80 caratteri. VMFS6 è il formato predefinito e non è accessibile da host ESX 6.0 e precedenti; VMFS5 resta per compatibilità con host fino a ESX 6.7. Sulla partizione si sceglie fra Use all available partitions, che dedica l’intero disco a un solo datastore VMFS, e Use free space. La dimensione minima per VMFS6 è 2 GB. Attenzione alla colonna Snapshot Volume nella selezione del dispositivo: un valore lì significa che state guardando una copia di un datastore esistente.

Per NFS si sceglie fra NFS 3 e NFS 4.1, e la regola che si dimentica sempre è che host diversi che montano lo stesso datastore devono usare lo stesso protocollo. Servono nome (80 caratteri), folder di mount e server, in formato IPv4 o IPv6; NFS 4.1 permette di indicare più indirizzi per il trunking e supporta nConnect per più connessioni TCP. L’Access Mode va messo in sola lettura se il server esporta così. L’autenticazione Kerberos ha tre livelli: krb5 (sola verifica dell’identità), krb5i (aggiunge integrità dei dati), krb5p (cifratura end-to-end del traffico NFS); in assenza si usa AUTH_SYS. Se si lancia il wizard a livello di cluster o data center, si scelgono nel percorso gli host che monteranno il datastore.

Le policy: dove si decide davvero la resilienza

Il piano di controllo dello storage è SPBM. Le VM Storage Policies coprono regole per datastore VMFS, servizi dati host-based, Virtual Volumes e regole basate su tag assegnati ai datastore; le policy si modificano oppure si clonano e si personalizzano.

Su vSAN ogni VM deve avere almeno una policy: in mancanza si applica la vSAN Default Storage Policy, che non si può eliminare e di cui non si possono cambiare nome, descrizione e provider — tutto il resto sì. In OSA i valori di partenza sono FTT 1, uno stripe per oggetto, nessuna riserva di cache, thin provisioning, nessun force provisioning. In ESA il cluster può attivare l’auto-policy management (vSAN → Services → Storage → Edit), che genera una policy ottimale in base al tipo di cluster e al numero di host ESX, chiamata NomeCluster - Optimal Default Datastore Policy.

Fra le regole avanzate contano Number of Disk Stripes per Object (default 1, massimo 12), IOPS Limit for Object, Object Space Reservation (da thin provisioning fino a thick), Flash Read Cache Reservation, Disable Object Checksum e Force Provisioning. Sul provisioning dei dischi virtuali vale la solita terna: thick provision lazy zeroed (default, azzera al primo write), thick provision eager zeroed (richiesto dalle funzioni di clustering come Fault Tolerance, più lento in creazione), thin provision. Con il thin si va in over-subscription: la contromisura documentata è un allarme sulla soglia di spazio provisionato.

vSAN: due architetture, non due versioni

vSAN aggrega i dispositivi locali o direct-attached di tutti gli host ESX del cluster in un unico pool condiviso. Le due architetture differiscono nella struttura fisica, non nell’anzianità.

OSA è a due tier: la costruzione logica è il disk group, che lega un dispositivo di cache ai dispositivi di capacità — al massimo cinque disk group per host, fino a sette capacity device ciascuno. Ammette SATA, SAS e NVMe, in configurazione ibrida o all-flash, con un HBA SAS/SATA o un controller RAID in passthrough o RAID 0. La memoria indicata è almeno 32 GB per sostenere cinque disk group con sette dispositivi.

ESA è single-tier: i dispositivi confluiscono in uno storage pool che gestisce insieme caching e capacità, e richiede NVMe TLC, almeno un dispositivo per pool. I requisiti host sono più alti: almeno 128 GB di memoria e almeno 16 core per host. Sulla rete, OSA chiede 1 GbE dedicato in ibrido e 10 GbE dedicato o condiviso in all-flash; ESA parte da 10 GbE con 25 GbE o più consigliati. Le latenze: 1 ms RTT fra host in cluster single-site, 5 ms fra i siti principali di uno stretched cluster, fino a 200 ms verso il witness.

Le differenze sui servizi dati sono quelle che l’esame ama. In OSA deduplication and compression è un’impostazione di cluster, disponibile solo su all-flash, applicata nel destage dalla cache alla capacità e con dominio di deduplica limitato al singolo disk group; attivarla o disattivarla comporta una riformattazione rolling di ogni disk group su ogni host, quindi non è un interruttore da premere a cuor leggero. In ESA la deduplica non esiste: c’è la compressione, attiva per default via storage policy e governabile per oggetto, e vale solo per le nuove scritture — i blocchi già esistenti restano non compressi. Il checksum in ESA è sempre attivo e non si disabilita; Flash Read Cache Reservation ha senso solo in configurazione ibrida.

Sull’erasure coding: in OSA RAID 5 vuole almeno quattro fault domain e RAID 6 almeno sei. In ESA il layout è adattivo — con sei o più fault domain RAID 5 usa cinque componenti, con cinque o meno ne usa tre. Un disco da 100 GB con FTT 1 costa 200 GB in RAID 1, circa 133 GB in RAID 5 su OSA, 125 GB in ESA con cinque fault domain. FTT 3 con erasure coding non è supportato. Sui fault domain la regola è 2n+1 per tollerare n guasti: minimo tre per FTT 1, meglio quattro o più, perché con soli tre non si ha reprotect e non si può usare Full data migration mode.

Quando ESA e quando OSA

ESA è la scelta quando l’hardware è NVMe certificato e si vuole erasure coding senza pagarlo in prestazioni, con compressione sempre accesa e policy generata dal cluster; è anche l’architettura raccomandata per i vSAN storage cluster disaggregati, che chiedono almeno quattro host. OSA resta quando il parco è SAS/SATA o ibrido, quando il controller non è NVMe, o quando serve la deduplica, che in ESA non c’è. Sui modelli di deployment: HCI standard con almeno tre host ESX che contribuiscono capacità, two-node con host witness per ROBO, stretched cluster con host divisi equamente fra due siti e witness in un terzo, compute cluster che consuma storage da un cluster vSAN separato.

Trappole tipiche d’esame

  • VCF contro vSphere Foundation. Il wizard di deployment è lo stesso installer, ma VVF non è VCF: la domanda che mette in scena SDDC Manager, i workload domain e i modelli di principal storage completi sta parlando di VCF, non di una VVF.
  • ESA non è “OSA aggiornato”. Storage pool contro disk group, NVMe TLC obbligatorio contro SAS/SATA/NVMe, 128 GB di memoria contro 32. E soprattutto: in ESA la deduplica non esiste, c’è solo la compressione — e la compressione ESA lavora solo sulle nuove scritture.
  • Principal contro supplemental. iSCSI, NVMe/TCP, NVMe/FC e NVMe/RDMA compaiono come supplemental in un VI workload domain: non sono opzioni di principal storage, quindi non si può creare un dominio partendo da lì.
  • I numeri dei fault domain per l’erasure coding. RAID 5 su OSA parte da quattro fault domain; in ESA il layout si adatta e sotto i sei fault domain usa tre componenti. Se la domanda dà cinque host e chiede se RAID 5 è possibile, la risposta dipende dall’architettura.
  • vVol è deprecato in 9.0. Compare ancora nel wizard di creazione del workload domain, con VASA provider, storage container e utente VASA, ma è marcato come deprecato e da rimuovere: una risposta che lo propone come scelta di design per un ambiente nuovo è quasi sempre la trappola.