Un cluster vSAN in VCF 9.0 nasce da host preparati, da una rete pensata prima e da una scelta — ESA o OSA — che dopo costa cara rimettere in discussione. L’esame la chiede «given a scenario».

Cosa deve essere vero prima di abilitare vSAN

Servono almeno tre host ESX, quattro o più raccomandati, e almeno tre devono contribuire capacità. La memoria minima è 32 GB per host, ma vSAN ESA parte da 128 GB. I controller vanno certificati nella Broadcom Compatibility Guide e messi in passthrough o RAID 0, e i dispositivi vSAN non possono condividere partizioni VFFS, VMFS o di boot di ESX: per questo il commissioning in VCF pretende HDD e SSD senza partizioni. Ogni host vuole poi un adattatore VMkernel per il traffico vSAN su una rete di livello 2 o 3: 1 GbE dedicato in hybrid, 10 GbE in all-flash, con ESA che raccomanda 25 GbE o superiore. La latenza è al massimo 1 ms RTT su un cluster single-site e 5 ms fra i due siti di uno stretched cluster.

Le due strade per creare il cluster

Dentro VCF si passa dal workload domain. Prima si crea un network pool per gli IP statici delle porte VMkernel di vMotion e vSAN; poi si fa il commissioning degli host da vSphere Client, in Global Inventory Lists > Hosts > Unassigned Hosts > Commission Hosts, scegliendo lì il tipo di storage principale. Il dominio si crea da VCF Operations, in Inventory > Detailed View > VCF Instances, con Add Workload Domain > Create New: il wizard chiede vCenter, cluster, immagine vSphere Lifecycle Manager, NSX Manager e infine lo storage, dove vSAN convive con NFS, VMFS on FC e vVol. La casella Enable vSAN ESA decide l’architettura, e il default è OSA: con OSA il wizard chiede Failures to Tolerate e la spunta di deduplica e compressione, con ESA chiede il tipo di cluster — vSAN HCI o vSAN Storage — e la policy resta auto-gestita.

Fuori da VCF si crea un cluster vSphere e si abilita vSAN sopra, oppure si usa Quickstart, che consolida il flusso con i default raccomandati e lo valida con il vSAN health service: vuole ESX 9.0 o successivo, host omogenei e nessuna configurazione di rete o vSAN preesistente, e avverte che toccare la rete fuori dal suo flusso compromette l’aggiunta di altri host. In entrambi i casi lo storage provider vSAN si registra da solo su vCenter e il datastore vSAN viene creato.

ESA, OSA e le topologie

In OSA i dispositivi si organizzano in disk group: uno di cache e da uno a sette di capacità, fino a cinque disk group per host. In ESA i dispositivi NVMe eleggibili confluiscono in un unico storage pool che serve cache e capacità insieme, senza tier separati. Le topologie riconosciute sono il cluster HCI single-site, il two-node con witness remoto, lo stretched cluster su due siti con witness in un terzo, il compute cluster senza storage locale, e lo storage cluster, minimo quattro host, «formerly known as vSAN Max».

Le storage policy: dove si scrivono e cosa dicono

Le policy vivono in Policies and Profiles > VM Storage Policies. Si sceglie il vCenter, si spunta «Enable rules for vSAN storage» e si compilano le schede Availability, Storage Rules, Advanced Policy Rules e Tags; poi Storage Compatibility elenca i datastore compatibili prima del Review and Finish.

In Availability, Site disaster tolerance distingue None per il cluster standard, Host mirroring per il two-node, Site mirroring per lo stretched e le varianti None - Keep Data on Preferred e on Secondary. Failures to tolerate va da No data redundancy a 1 failure RAID-1 o RAID-5, 2 failures RAID-1 o RAID-6 e 3 failures RAID-1: l’erasure coding non arriva a FTT 3. Storage Rules copre cifratura, space efficiency e storage tier; Advanced Policy Rules raccoglie Number of disk stripes per object (default 1, massimo 12), IOPS limit for object (normalizzato su blocchi da 32 KB, 0 disattiva il limite), Object space reservation, Flash read cache reservation, Disable object checksum e Force provisioning.

La vSAN Default Storage Policy — modificabile nei parametri, non nel nome, e non eliminabile — nasce con FTT 1, uno stripe, nessuna riserva e Force provisioning a No, tranne per gli oggetti di swap e memoria, dove è a Yes. Su ESA esistono due policy predefinite, RAID-5 con FTT 1 e RAID-6 con FTT 2, e l’auto-policy management può generarne una chiamata «ClusterName - Optimal Default Datastore Policy».

Cambiare policy non è istantaneo: vSAN raggruppa le richieste e le esegue in modo asincrono per contenere lo spazio transitorio, che si legge in Cluster > Monitor > vSAN > Capacity, sotto Usage breakdown > System usage. Se la richiesta è incompatibile con l’hardware sottostante — RAID-6 su cinque host — viene respinta subito.

Trappole tipiche d’esame

  • ESA non è «OSA veloce». In ESA il checksum è sempre attivo e non si disattiva, la compressione è per oggetto e attiva di default, e Flash read cache reservation vale solo in hybrid.
  • FTT si conta in fault domain, non in host. Un host non assegnato ad alcun fault domain fa fault domain da solo; il minimo è 2n+1, tre per FTT 1 e cinque per FTT 2. RAID-5 in all-flash ne chiede quattro, RAID-6 sei.
  • vSAN storage cluster e compute cluster non sono ovunque. Non valgono come storage principale sul cluster di default del management domain: lì restano vSAN ESA, vSAN OSA, Fibre Channel e NFS.
  • Una sola default per datastore. E su ESA le predefinite sono RAID-5 e RAID-6, non la RAID-1 di FTT 1.
  • Stretching non è una spunta. Passa dall’API di SDDC Manager, esclude i cluster che condividono una vSAN Storage Policy con altri, quelli con host DPU-backed e quelli su subnet diverse, e vuole il management domain di default già stirato.