L’obiettivo 2.3 chiede due cose che in laboratorio si fanno nello stesso pomeriggio, ma che l’esame tiene ben separate: configurare lo storage di vSphere in uno scenario dato, e saper motivare quando serve vSAN ESA e quando vSAN OSA. Su VMware vSphere Foundation entrambe le risposte vivono dentro vSphere e vSAN: il piatto è vCenter Standard, ESX, vSAN, VCF Operations e VCF Operations for Logs. Niente NSX, niente VCF Automation, niente workload domain. Anche il networking dello storage è quello di sempre — standard switch, distributed switch, port group, VMkernel, teaming, VLAN.

Il datastore è l’astrazione, non il disco

La documentazione definisce i datastore come «logical containers, analogous to file systems, that hide specifics of each storage device». Ne esistono quattro tipi — VMFS, NFS, vSAN e vVol — e la 9.0 segna quest’ultimo come deprecato. La tabella delle caratteristiche è già una fonte di domande: il multipathing è una proprietà di VMFS e vVol, non di NFS né di vSAN; Storage I/O Control vale per VMFS e NFS; extent e drive type esistono solo su VMFS.

Per crearne uno VMFS il percorso è: nel navigatore oggetti del vSphere Client, tasto destro su un host, un cluster o un data center → Storage → New Datastore. Il formato predefinito è VMFS6 (minimo 2 GB); VMFS5 resta disponibile solo perché «supports access by the ESX hosts of version 6.7 or earlier». Su VMFS6 il wizard chiede anche block size e i parametri di space reclamation.

Trasporti e adattatori: quale strada prende l’I/O

ESX distingue lo storage locale (dischi interni, o array esterni collegati direttamente in SAS o SATA) dal networked storage. In rete i trasporti sono: Fibre Channel, che porta «SCSI or NVMe traffic» su HBA; iSCSI, che incapsula lo SCSI in TCP/IP e si usa con un adattatore hardware dedicato oppure con l’adattatore software iSCSI e una scheda di rete standard; NAS via NFS versione 3 e 4.1; il SAS condiviso; e NVMe over Fabrics, nelle varianti NVMe over RDMA (RoCE v2), NVMe over Fibre Channel e NVMe over TCP/IP. Tutto tranne NFS finisce su datastore VMFS.

La sequenza dell’iSCSI software è d’obbligo saperla in ordine: attivare l’adattatore, modificare le proprietà generali (nome o alias iSCSI), configurare il port binding, impostare la discovery dinamica o statica, poi CHAP e, se serve, i jumbo frame. Il port binding vale per l’adattatore software iSCSI, per quello hardware dipendente e per iSER; su iSER però non c’è NIC teaming, e va usato un solo vmnic RDMA e un solo vmk per vSwitch. La raccomandazione ufficiale resta «designate a separate network adapter for iSCSI».

Fra NFS 3 e NFS 4.1 le differenze che l’esame ama sono quattro: il locking (proprietario contro quello nativo del protocollo), il multipathing (previsto dal protocollo su 4.1, «not applicable» su NFS 3), la sicurezza (AUTH_SYS su entrambi, Kerberos solo su 4.1) e il fatto che i dischi virtuali su NFS nascono thin, salvo hardware acceleration che supporti l’operazione Reserve Space.

Sul blocco, la scelta del path la fa il PSP: Most Recently Used prende il primo path funzionante trovato al boot e non torna indietro quando l’originale ricompare (default sulla maggior parte degli array active-passive); Fixed usa un preferred path e ci ritorna appena è di nuovo disponibile (default sugli active-active); Round Robin ruota fra i path configurati con un meccanismo adattivo che pesa banda e latenza.

Provisioning e politiche

Tre formati di disco: thick provision lazy zeroed (spazio allocato alla creazione, azzeramento al primo write), thick provision eager zeroed (spazio allocato e azzerato subito) e thin, che «starts small» e cresce. Il thin abilita l’over-subscription — spazio provisionato superiore alla capacità reale — e lì l’allocazione diventa first-come first-served: la contromisura ufficiale è un allarme sulla soglia di spazio provisionato.

Una pool sola, due architetture

vSAN «aggregates local or direct-attached capacity devices of all ESX hosts in a cluster» in un unico pool condiviso. Le due architetture differiscono nel costrutto logico sottostante.

OSA organizza i dispositivi in disk group: un solo dispositivo di cache, da 1 a 7 dispositivi di capacità, massimo cinque disk group per host e fino a 35 dispositivi di capacità per host. Serve un HBA SAS/SATA o un controller RAID in passthrough o RAID 0. Il cluster può essere ibrido (cache flash + capacità magnetica SAS o NL-SAS) o all-flash. Rete: 1 GbE dedicata in ibrido, 10 GbE dedicata o condivisa in all-flash.

ESA «replaces disk groups with a new logical construct called a storage pool», che organizza i dispositivi NVMe idonei in un’unica pool che fa cache e capacità insieme. Richiede almeno un dispositivo NVMe TLC per storage pool e almeno 128 GB di memoria per host; in rete 10 GbE minimo, 25 GbE o superiore raccomandato. In entrambe le architetture ogni host del cluster deve avere una VMkernel adapter per il traffico vSAN, «regardless of whether it contributes capacity».

Si reclamano i dischi da Cluster → Configure → vSAN → Disk Management → Claim Unused Disks. In OSA si sceglie per tier: Claim for cache tier e Claim for capacity tier. In ESA si selezionano i dispositivi e si preme Create, oppure si usa Change Disk Claim Mode per il claim gestito da vSAN; il default è una storage pool per host.

Quando ESA e quando OSA

ESA abilita la compressione per impostazione predefinita tramite la storage policy, e la si può disattivare per singolo workload; la deduplica «is not available in the vSAN ESA cluster», il checksum è sempre attivo e non disattivabile, e la cifratura avviene negli strati alti dopo la compressione, riducendo l’overhead. Soprattutto, ESA supporta RAID 5 con tre fault domain (schema 2+1 sotto i sei host, 4+1 da sei in su, con riadattamento dopo 24 ore al variare del cluster): l’erasure coding smette di essere un compromesso e diventa la scelta normale.

OSA resta la strada quando l’hardware non è NVMe TLC, quando serve una configurazione ibrida con capacità magnetica, o quando si vuole la deduplica e compressione: si abilita come impostazione di cluster ma si applica per disk group, solo su all-flash, e con un prezzo esplicito — «a single disk failure causes the entire disk group to fail». La Flash Read Cache Reservation è un attributo di policy che vive solo in OSA.

Per entrambe: RAID 5 su cluster all-flash con quattro o più fault domain, RAID 6 con sei o più, e l’erasure coding non supporta FTT 3. I deployment sono cluster standard da minimo tre host, cluster a due host con un witness remoto condivisibile, stretched cluster su due siti con witness in un terzo sito, e storage cluster da minimo quattro host. La vSAN Default Storage Policy parte con FTT 1, uno stripe, object space reservation thin e force provisioning a No.

Trappole tipiche d’esame

  • VVF non è VCF. Non c’è NSX, quindi non c’è il networking stack che i vSphere Pod richiedono: su vSphere Foundation i container girano nei cluster VKS. Il blueprint nomina i vSphere Pod, la documentazione ne pone il limite — sapere entrambe le cose è la risposta giusta.
  • Deduplica su ESA non esiste. ESA fa compressione (default, via policy); dedup + compressione è OSA, all-flash, a livello di cluster ma applicata per disk group. Ogni opzione che «attiva la deduplica su un cluster ESA» è distrattore.
  • Disk group contro storage pool. Il raggio d’esplosione cambia: in OSA con dedup attiva un singolo disco perso porta giù l’intero disk group; in ESA il disk group non esiste proprio.
  • Il conteggio dell’erasure coding. RAID 5 vuole quattro o più fault domain — tranne in ESA, che scende a tre. RAID 6 sei o più. FTT 3 solo in mirroring, mai in erasure coding.
  • Il multipathing non è di tutti. PSP e path selection policy sono roba a blocchi: NFS 3 non ha multipathing, NFS 4.1 ce l’ha per protocollo, e vSAN non compare in quella colonna. E attenzione al failback: Fixed torna al preferred path, MRU no.