Cos’è Storage Spaces Direct e perché richiede un failover cluster

Storage Spaces Direct (S2D) è la tecnologia di software-defined storage di Windows Server che aggrega i dischi locali (NVMe, SSD, HDD) di più nodi in un unico storage pool condiviso, senza SAN né controller RAID hardware. Il fondamento è il failover cluster: S2D si abilita su un cluster già validato (Enable-ClusterS2D) e usa il Software Storage Bus per far “vedere” a ogni nodo i dischi degli altri via rete. Sopra il pool si creano volumi (virtual disk) esposti come Cluster Shared Volumes (CSV) formattati in ReFS, accessibili simultaneamente da tutti i nodi. Serve un quorum witness per mantenere il cluster operativo in caso di partizione: poiché non esiste disco condiviso, il disk witness classico non è utilizzabile, quindi si ricorre a cloud witness (Azure) o file share witness.

Requisiti chiave da ricordare: edizione Windows Server Datacenter, da 2 a 16 nodi, dischi collegati in pass-through (HBA, niente RAID hardware) e rete ad alte prestazioni, idealmente RDMA (RoCE o iWARP) con SMB Direct e SMB Multichannel a 10 GbE o superiore.

Architettura hyper-converged vs disaggregated

S2D si distribuisce in due modelli. Nel modello hyper-converged (HCI) compute e storage vivono sugli stessi nodi: Hyper-V esegue le VM direttamente sui volumi CSV del cluster. È il modello più semplice e diffuso, scala compute e storage insieme, ideale per infrastrutture medio-piccole.

Nel modello disaggregated (converged) lo storage cluster S2D è separato dal cluster di compute: i volumi vengono esposti tramite Scale-Out File Server (SOFS) e consumati via SMB3 da server applicativi o host Hyper-V remoti. Permette di scalare storage e compute in modo indipendente, adatto a datacenter grandi con più cluster di calcolo che condividono la stessa capacità.

Resilienza e alta disponibilità dello storage

L’alta disponibilità dipende dal resiliency type scelto alla creazione del volume:

  • Two-way mirror: due copie, tollera 1 guasto (disco/nodo), efficienza circa 50%, minimo 2 nodi.
  • Three-way mirror: tre copie, tollera 2 guasti simultanei, efficienza circa 33%, minimo 3 nodi.
  • Dual parity (erasure coding): tollera 2 guasti con efficienza di spazio superiore, ma più costoso in CPU e in scrittura, minimo 4 nodi.
  • Mirror-accelerated parity: mirror per i dati “caldi” più parity per i “freddi”, compromesso fra capacità e prestazioni.

Per i cluster a 2 soli nodi esiste la nested resiliency (nested two-way mirror o nested mirror-accelerated parity), che protegge dalla perdita simultanea di un nodo e di un disco, cosa che il semplice two-way mirror non garantisce. I fault domain (disco, nodo, chassis, rack) determinano come le copie vengono distribuite; la ricostruzione (repair) è automatica usando la capacità libera riservata. Un cache tier su NVMe/SSD accelera gli IO verso i dischi di capacità.

Quando S2D è la scelta giusta

S2D conviene quando serve storage altamente disponibile su hardware commodity senza acquistare una SAN, tipicamente per virtualizzazione Hyper-V. Il 2-node con nested resiliency è pensato per branch office ed edge; i cluster più grandi per il datacenter. Se il carico non richiede HA o si dispone già di uno storage array condiviso affidabile, S2D aggiunge complessità inutile. Nota: Azure Stack HCI è l’evoluzione as-a-service di questo stack, ma è un sistema operativo distinto.

Trappole tipiche d’esame

  • Cluster a 2 nodi che deve sopravvivere a nodo giù + disco guasto → nested resiliency: il two-way mirror standard non basta; solo nested two-way mirror o nested mirror-accelerated parity coprono il doppio guasto.
  • Quorum su cluster S2D → cloud witness o file share witness: senza shared disk il disk witness non è disponibile; l’esame lo propone spesso come distrattore.
  • Edizione richiesta → Windows Server Datacenter: l’edizione Standard non abilita S2D; attenzione agli scenari che citano Standard.
  • Massima efficienza di spazio con 4+ nodi → dual parity: il mirror è più veloce ma spreca capacità; la parity conviene per dati a freddo.
  • Scalare storage e compute separatamente → modello disaggregated con SOFS: l’hyper-converged li lega insieme e non permette scaling indipendente.
  • Dischi dietro controller RAID hardware → non supportato: S2D richiede pass-through/HBA; il RAID hardware va disabilitato prima di abilitare il cluster.