De plus en plus d’entreprises abandonnent les baies RAID classiques ou les SAN dédiés au profit de Storage Spaces Direct (S2D), la technologie de stockage logiciel intégrée à Windows Server depuis la version 2016. Le principe séduit : agréger le stockage local de plusieurs serveurs standards en un seul pool virtuel, sans matériel de stockage propriétaire. Mais cette simplicité côté exploitation a une contrepartie rarement mise en avant : en cas de défaillance grave, la récupération de données sur un cluster S2D est nettement plus complexe qu’une récupération RAID classique.
Storage Spaces et Storage Spaces Direct : deux choses différentes
Storage Spaces, tout court, existe depuis Windows Server 2012 : c’est une couche logicielle qui virtualise des disques attachés à une seule machine, un peu comme un RAID logiciel intégré à l’OS. Storage Spaces Direct (S2D), lui, va plus loin : il combine le stockage local de plusieurs serveurs (de 2 à 16 nœuds) en un seul pool partagé, via le réseau, sans passer par une baie de stockage externe ou du câblage SAS partagé. Chaque nœud voit les disques de tous les autres comme s’ils lui étaient directement attachés.
Comment fonctionne concrètement un cluster S2D
L’architecture empile plusieurs couches logicielles bien distinctes. D’abord le Software Storage Bus, qui relie les disques physiques de tous les nœuds sur le réseau et remplace le câblage Fibre Channel ou SAS partagé d’une baie traditionnelle. Vient ensuite le pool de stockage, qui regroupe automatiquement tous les disques éligibles. Au-dessus, Storage Spaces crée des disques virtuels avec une tolérance de panne (mirroring ou parité, selon la configuration). Puis le système de fichiers ReFS (ou NTFS) et la couche Cluster Shared Volumes (CSV) font apparaître ces volumes comme montés localement sur chaque serveur, en s’appuyant sur le protocole réseau SMB 3.0. Cinq couches logicielles séparent donc le disque physique du fichier final, contre une seule (le contrôleur RAID) sur une baie classique.
Le cache joue un rôle central dans cette architecture : les disques les plus rapides d’un nœud (SSD ou NVMe) mettent automatiquement en cache les lectures/écritures des disques de capacité (SSD plus lents ou disques mécaniques), pour accélérer les performances. Microsoft recommande de prévoir au moins 4 Go de mémoire vive par To de capacité de cache pour gérer les métadonnées associées, et impose que les disques de cache fassent au moins 32 Go.
Des capacités qui dépendent fortement de la version de Windows Server
Point souvent source de confusion : les capacités maximales de S2D ont fortement augmenté entre les versions. Sur Windows Server 2016, la limite était de 100 To de capacité brute par serveur et 1 Po (1 000 To) par pool. Depuis Windows Server 2019, ces plafonds sont passés à 400 To par serveur et 4 Po (4 000 To) par pool, sur un cluster pouvant toujours aller jusqu’à 16 serveurs. Un cluster S2D ancien, jamais mis à jour depuis son déploiement initial, peut donc fonctionner avec des contraintes très différentes d’un cluster récent — un point à connaître avant tout diagnostic, y compris en cas de panne.
| Version | Capacité brute max. par serveur | Capacité max. du pool |
|---|---|---|
| Windows Server 2016 | 100 To | 1 Po (1 000 To) |
| Windows Server 2019 et ultérieur | 400 To | 4 Po (4 000 To) |
La résilience intégrée n’élimine pas le risque de perte de données
S2D protège les données par mirroring (deux ou trois copies réparties sur des serveurs différents) ou par parité, selon un principe proche du RAID 1 ou RAID 5/6, mais appliqué au niveau du cluster plutôt qu’au niveau d’une seule baie. Un cluster correctement configuré tolère généralement deux pannes simultanées de disque ou de serveur (typiquement avec un mirroring à trois copies). Cette résilience protège contre la panne matérielle isolée, pas contre tout le reste : un nombre de pannes simultanées supérieur à ce qui a été configuré, une erreur de manipulation lors d’un remplacement de disque, une corruption logique propagée avant qu’elle ne soit détectée, ou un défaut de configuration initial (mirroring insuffisant sur un pool entièrement en disques rapides, par exemple) restent des scénarios de perte de données bien réels, malgré la résilience native.
Pourquoi une récupération sur S2D est plus complexe qu’un RAID classique
Sur une baie RAID traditionnelle, un ingénieur reconstruit un volume en travaillant sur une seule couche : l’agencement des données sur les disques physiques selon l’algorithme RAID utilisé. Sur un cluster S2D, il faut reconstituer successivement le pool de stockage réparti sur plusieurs serveurs, puis les disques virtuels avec leur schéma de résilience propre, puis le système de fichiers CSV/ReFS, avant même d’atteindre les fichiers ou les disques virtuels des machines virtuelles hébergées dessus. Chaque couche logicielle supplémentaire est un point où le lien entre une donnée et son emplacement physique réel peut se rompre, en particulier si une tentative de réparation automatique a déjà été lancée par le cluster avant l’intervention.
Sur des clusters hyperconvergés hébergeant des machines virtuelles (Hyper-V) via cette même infrastructure, la complexité s’ajoute encore une couche : au-delà du stockage virtualisé lui-même, il faut aussi restaurer la cohérence des disques virtuels des VM. Une base de données hébergée sur une VM dont le stockage S2D sous-jacent a été corrompu illustre bien ce cumul de couches — un cas de figure proche, en termes de complexité, de ce que nous décrivons dans notre article sur une base de données disparue après corruption d’une VM.
Ce qu’il ne faut pas faire face à une alerte sur un cluster S2D
- Ne pas relancer une reconstruction automatique du pool sans avoir d’abord identifié précisément quels disques et quels nœuds sont réellement en cause : sur une architecture répartie sur plusieurs serveurs, une reconstruction lancée sur de mauvaises bases peut aggraver une situation encore récupérable.
- Ne pas retirer ou remplacer plusieurs disques sur plusieurs nœuds en même temps sans avis préalable, même si l’interface de gestion (Windows Admin Center, PowerShell) le permet techniquement.
- Ne pas négliger l’état du réseau : comme les nœuds communiquent en continu via SMB 3.0 sur des liaisons 10 GbE ou RDMA dédiées, un problème réseau peut se manifester comme une panne de stockage alors que les disques eux-mêmes sont intacts — un diagnostic qui mérite d’être vérifié avant toute manipulation physique.
Quand faire appel à un laboratoire spécialisé
Dès qu’un cluster S2D devient inaccessible, qu’une tentative de réparation automatique a échoué, ou que le nombre de disques/nœuds défaillants dépasse la tolérance configurée, chaque manipulation supplémentaire réduit les chances de récupération. Un laboratoire habitué aux architectures de stockage RAID et virtualisé peut travailler couche par couche — Software Storage Bus, pool, disques virtuels, système de fichiers — plutôt que de dépendre du service de réparation automatique intégré au cluster, qui n’est pas conçu pour un scénario où la résilience native a déjà été dépassée.
Storage Spaces Direct reste une technologie robuste, conçue pour tolérer des pannes matérielles courantes sans interruption de service. Mais sa flexibilité a un coût en cas de défaillance dépassant ce qui a été prévu : plus de couches logicielles signifie plus de façons pour le lien entre une donnée et son support physique de se rompre, et une reconstruction improvisée peut transformer une panne récupérable en perte totale.