Sempre più aziende abbandonano i tradizionali array RAID o le SAN dedicate a favore di Storage Spaces Direct (S2D), la tecnologia di storage software integrata in Windows Server a partire dalla versione 2016. Il principio è semplice: unire lo storage locale di più server standard in un unico pool virtuale, senza hardware di storage proprietario. Ma questa semplicità operativa ha una contropartita raramente menzionata: in caso di guasto grave, il recupero dati su un cluster S2D è molto più complesso di un recupero RAID classico.
Storage Spaces e Storage Spaces Direct: due cose diverse
Storage Spaces, da solo, esiste sin da Windows Server 2012: è un livello software che virtualizza i dischi collegati a una singola macchina, un po’ come un RAID software integrato nel sistema operativo. Storage Spaces Direct (S2D) va oltre: combina lo storage locale di più server (da 2 a 16 nodi) in un unico pool condiviso via rete, senza passare per un array di storage esterno o un cablaggio SAS condiviso. Ogni nodo vede i dischi di tutti gli altri come se fossero collegati direttamente a lui.
Come funziona concretamente un cluster S2D
L’architettura sovrappone diversi livelli software distinti. Innanzitutto il Software Storage Bus, che collega i dischi fisici di tutti i nodi via rete e sostituisce il cablaggio Fibre Channel o SAS condiviso di un array tradizionale. Segue il pool di storage, che raggruppa automaticamente tutti i dischi idonei. Sopra di esso, Storage Spaces crea dischi virtuali con una tolleranza di guasto scelta (mirroring o parità). Infine, il file system ReFS (o NTFS) e il livello Cluster Shared Volumes (CSV) fanno apparire questi volumi come montati localmente su ogni server, basandosi sul protocollo di rete SMB 3.0. Cinque livelli software separano quindi il disco fisico dal file finale, contro un solo livello (il controller RAID) su un array classico.
La cache ha un ruolo centrale in questa architettura: i dischi più rapidi di un nodo (SSD o NVMe) memorizzano automaticamente in cache le letture/scritture dei dischi di capacità (SSD più lenti o dischi meccanici), migliorando le prestazioni. Microsoft raccomanda almeno 4 GB di RAM per TB di capacità di cache per gestire i metadati associati, e richiede che i dischi di cache siano almeno da 32 GB.
Capacità che dipendono fortemente dalla versione di Windows Server
Un punto spesso fonte di confusione: le capacità massime di S2D sono aumentate notevolmente tra le versioni. Su Windows Server 2016, il limite era di 100 TB di capacità grezza per server e 1 PB (1.000 TB) per pool. A partire da Windows Server 2019, questi limiti sono passati a 400 TB per server e 4 PB (4.000 TB) per pool, su un cluster che può comunque arrivare fino a 16 server. Un vecchio cluster S2D, mai aggiornato dal suo primo utilizzo, può quindi funzionare con vincoli molto diversi da un cluster recente — un aspetto da conoscere prima di qualsiasi diagnosi, anche in caso di guasto.
| Versione | Capacità grezza max. per server | Capacità max. del pool |
|---|---|---|
| Windows Server 2016 | 100 TB | 1 PB (1.000 TB) |
| Windows Server 2019 e successivi | 400 TB | 4 PB (4.000 TB) |
La resilienza integrata non elimina il rischio di perdita dati
S2D protegge i dati tramite mirroring (due o tre copie distribuite su server diversi) o parità, secondo un principio simile a RAID 1 o RAID 5/6, ma applicato a livello di cluster piuttosto che all’interno di un singolo array. Un cluster configurato correttamente tolera generalmente due guasti simultanei di disco o server (in genere con un mirroring a tre copie). Questa resilienza protegge dal guasto hardware isolato, non da tutto il resto: un numero di guasti simultanei superiore a quello configurato, un errore di manipolazione durante la sostituzione di un disco, una corruzione logica propagata prima di essere rilevata, oppure un difetto di configurazione iniziale (mirroring insufficiente su un pool interamente flash, ad esempio) restano scenari di perdita dati molto reali, nonostante la resilienza nativa.
Perché un recupero su S2D è più complesso di un RAID classico
Su un array RAID tradizionale, un tecnico ricostruisce un volume lavorando su un unico livello: la disposizione dei dati sui dischi fisici secondo l’algoritmo RAID utilizzato. Su un cluster S2D, occorre ricostruire in sequenza il pool di storage distribuito su più server, poi i dischi virtuali con il proprio schema di resilienza, poi il file system CSV/ReFS, prima ancora di raggiungere i file o i dischi virtuali delle macchine virtuali ospitate sopra. Ogni livello software aggiuntivo è un punto in cui il legame tra un dato e la sua posizione fisica reale può rompersi, in particolare se un tentativo di riparazione automatica è già stato avviato dal cluster prima dell’intervento.
Sui cluster iperconvergenti che ospitano macchine virtuali (Hyper-V) su questa stessa infrastruttura, la complessità aumenta di un ulteriore livello: oltre allo storage virtualizzato in sé, occorre ripristinare anche la coerenza dei dischi virtuali delle VM. Un database ospitato su una VM il cui storage S2D sottostante è stato corrotto illustra bene questa sovrapposizione di livelli — un caso per certi versi simile, in termini di complessità, a quanto descriviamo nel nostro articolo su un database scomparso dopo la corruzione di una VM.
Cosa non fare in caso di allarme su un cluster S2D
- Non avviare una ricostruzione automatica del pool prima di aver identificato con precisione quali dischi e quali nodi sono realmente coinvolti: su un’architettura distribuita su più server, una ricostruzione avviata su basi errate può aggravare una situazione ancora recuperabile.
- Non rimuovere o sostituire più dischi su più nodi contemporaneamente senza un parere preventivo, anche se l’interfaccia di gestione (Windows Admin Center, PowerShell) lo consente tecnicamente.
- Non sottovalutare lo stato della rete: poiché i nodi comunicano in continuazione via SMB 3.0 su collegamenti 10 GbE o RDMA dedicati, un problema di rete può manifestarsi come un guasto dello storage anche quando i dischi stessi sono intatti — un aspetto da verificare prima di qualsiasi intervento fisico.
Quando rivolgersi a un laboratorio specializzato
Non appena un cluster S2D diventa inaccessibile, un tentativo di riparazione automatica è fallito, oppure il numero di dischi/nodi guasti supera la tolleranza configurata, ogni ulteriore manipolazione riduce le possibilità di recupero. Un laboratorio abituato alle architetture di storage RAID e virtualizzato può lavorare livello per livello — Software Storage Bus, pool, dischi virtuali, file system — invece di dipendere dalla riparazione automatica integrata nel cluster, che non è pensata per uno scenario in cui la resilienza nativa è già stata superata.
Storage Spaces Direct resta una tecnologia solida, pensata per tollerare guasti hardware comuni senza interruzione del servizio. Ma la sua flessibilità ha un costo quando un guasto supera quanto previsto: più livelli software significano più modi in cui il legame tra un dato e il suo supporto fisico può rompersi, e una ricostruzione improvvisata può trasformare un guasto recuperabile in una perdita totale.