Dans un cluster Windows Server, faut‑il choisir des volumes locaux répliqués ou un stockage partagé (SAN/CSV/S2D) ? Ce guide, inspiré d’un environnement bancaire réel, expose les critères décisionnels, les architectures possibles et un plan d’implémentation prêt à l’emploi.
Contexte synthétique
Vous disposez de deux nœuds Windows Server en cluster de basculement (actif/passif), de quatre contrôleurs de domaine répartis sur le territoire pour desservir les agences, et d’un contrôleur de domaine de secours hébergé dans Microsoft Azure. La question centrale : sur quoi reposent les volumes des ressources clusterisées ? Sur des disques locaux à chaque nœud ou sur un stockage partagé ?
Décision rapide
Recommandation générale : stockage partagé pour les charges de travail nécessitant une seule source de vérité (fichiers, bases de données, volumes Hyper‑V, applications stateful), via Cluster Shared Volumes (CSV) sur SAN/iSCSI ou Storage Spaces Direct (S2D) pour un modèle hyper‑convergé. Active Directory ne se clusterise pas : conservez des contrôleurs de domaine autonomes et répliqués, avec stockage local.
Pour la résilience du cluster : quorum avec témoin (idéalement Cloud Witness dans Azure puisque l’abonnement existe déjà).
Pourquoi le stockage partagé reste la voie royale
Un cluster de basculement Windows Server (Windows Server Failover Clustering, WSFC) est conçu pour que plusieurs nœuds exposent la même donnée à un moment donné, sans divergence. Lors d’un basculement, le service reprend sur un autre nœud qui voit exactement le même volume ; aucune resynchronisation lourde n’est requise, et le temps de reprise se limite à la remise en ligne de la ressource.
CSV et cohérence transactionnelle
Avec les Cluster Shared Volumes, tous les nœuds montent simultanément le volume (NTFS/ReFS) ; un nœud « coordinateur » arbitre les métadonnées et la cohérence. C’est transparent pour la majorité des charges (Hyper‑V, SOFS, SQL sur disques partagés, serveurs de fichiers). Le CSV réduit le nombre de LUN, simplifie l’administration, et permet des opérations comme la maintenance sans interruption des workloads.
Panorama des options de stockage partagé
| Option | Principe | Cas d’usage typiques | Forces | Points d’attention |
|---|---|---|---|---|
| SAN Fibre Channel / iSCSI | Baie centralisée exposant des LUN aux nœuds | Banques, ERP, bases de données, fichiers, Hyper‑V | Performance prévisible, MPIO mature, fonctions avancées (snapshots, clones) | Coût et dépendance constructeur, nécessite un design multipaths strict |
| Storage Spaces Direct (S2D) | Disques locaux agrégés en pool distribué, présentés en CSV | Hyper‑convergé, Hyper‑V + SOFS, clusters 2–16 nœuds | Évite la baie SAN, scale‑out simple, performance élevée (NVMe/SSD) | Exige interconnexion faible latence, conception réseau soignée (RDMA, QoS) |
| SOFS sur SMB 3.0 | Rôle Scale‑Out File Server exposant des partages continus | Stockage de VM Hyper‑V, partages applicatifs hautement disponibles | Scale‑out, SMB Multichannel/RDMA, continuité d’accès client | Nécessite back‑end partagé (SAN/S2D), droits et sécurité SMB à cadrer |
Quand préférer des volumes locaux répliqués
Des volumes locaux sur chaque nœud peuvent être légitimes lorsque la charge gère elle‑même la réplication ou n’a pas besoin d’un volume partagé :
- SQL Server Always On Availability Groups : réplication des bases au niveau transactionnel, pas de LUN partagée ; utile pour multi‑sites.
- Applications conçues pour le multi‑maître (Kafka, certaines NoSQL) : réplication native, tolérance aux partitions.
- DFS‑R pour réplications de dossiers en lecture majoritaire : utile pour contenu largement distribué, à éviter comme back‑end de bases.
- Storage Replica : réplication bloc‑à‑bloc synchrone (RPO≈0) ou asynchrone (RPO>0) entre serveurs/clusters, pour PRA et stretched clusters.
Quel modèle pour quelle charge ?
| Charge de travail | Modèle recommandé | Commentaire |
|---|---|---|
| Serveur de fichiers d’entreprise | SOFS + CSV sur SAN ou S2D | SMB 3.0, transparence de basculement, ACL centralisées |
| Hyper‑V (stockage des VHDX) | CSV + SOFS, ou S2D | Performances stables, Live Migration, VM Storage Resiliency |
| SQL Server instance traditionnelle | Disque partagé en cluster WSFC | Une seule copie des fichiers MDF/LDF, basculement rapide |
| SQL Server Always On AG | Volumes locaux + réplication AG | Pas de LUN partagée ; adapté aux sites distants |
| Contrôleurs de domaine AD DS | Pas de cluster, stockage local | Réplication multi‑maître native, VM‑GenID compatible |
Quorum et haute disponibilité pragmatique
Dans un cluster deux nœuds, un témoin évite le « split brain ». Trois options : Disk Witness (LUN partagée), File Share Witness (partage SMB tiers) ou Cloud Witness (Azure Storage). Dans votre contexte, le Cloud Witness Azure est simple et robuste.
| Type de quorum | Avantages | Limites | Contexte cible |
|---|---|---|---|
| Node Majority + Disk Witness | Local, faible latence | Nécessite stockage partagé supplémentaire | Datacenter unique avec SAN |
| Node Majority + File Share Witness | Pas de LUN dédiée | Le partage doit être hautement disponible | Troisième site on‑premises |
| Node Majority + Cloud Witness | Simplicité, tiers géographiquement séparé | Dépendance Internet/Azure | Organisation déjà intégrée à Azure |
Exemples PowerShell utiles
# Validation préalable (à exécuter avant toute mise en prod)
Test-Cluster -Node "SRV-CL1","SRV-CL2" -Include "Inventory","Network","Storage","System Configuration"
# Création du cluster sans stockage (vous ajouterez les CSV ensuite)
New-Cluster -Name "CL-FICHIERS" -Node "SRV-CL1","SRV-CL2" -StaticAddress "10.10.10.50" -NoStorage
# Configuration du quorum avec témoin Azure
Set-ClusterQuorum -CloudWitness -AccountName "mystorageacct" -AccessKey "xxxxxxxxxxxxxxxxxxxxxxxx"
# Ajout d’un disque partagé existant comme CSV
Get-ClusterAvailableDisk | Add-ClusterDisk
Get-ClusterResource | Where-Object {$_.ResourceType -eq "Physical Disk"}
Add-ClusterSharedVolume -Name "Cluster Disk 1"
# Pour S2D (si modèle hyper‑convergé)
Enable-ClusterS2D -Confirm:$false
Get-StoragePool S2D* | New-Volume -FileSystem ReFS -FriendlyName "DataCSV" -Size 4TB -ResiliencySettingName Mirror -AllocationUnitSize 64KB
# Activation de la journalisation cluster
Get-ClusterLog -UseLocalTime -Destination "C:\Temp\ClusterLogs" Architecture réseau et stockage à l’épreuve des pannes
- Redondance bout‑en‑bout : deux contrôleurs SAN, deux fabrics FC, deux cartes iSCSI/roce par nœud, deux commutateurs par fabric, MPIO activé et testé.
- Séparation des flux : réseaux dédiés pour le trafic client, le CSV, la gestion, et la Live Migration ; SMB Multichannel/RDMA pour SOFS/S2D.
- Latence : si vous étendez le cluster, visez une latence RTT < 5 ms pour la réplication synchrone (Storage Replica/S2D stretch).
- QoS et goulots d’étranglement : contrôlez la bande passante de Live Migration et CSV, surveillez la file d’attente disque et la saturation CPU.
- ReFS + CSV Cache pour Hyper‑V/SOFS : accélère les métadonnées et les VHDX dynamiques.
Spécificités Active Directory dans ce contexte
Ne clusterisez pas AD DS. Les contrôleurs de domaine sont multi‑maîtres, répliqués de façon native. Conservez du stockage local et multipliez les DC dans des sites AD cohérents avec la topologie réseau. Sauvegardez l’état du système, placez les rôles FSMO à des emplacements stables, et évitez les snapshots non coordonnés (risque de rollback d’USN ; heureusement, VM‑Generation ID réduit ce risque sur hyperviseurs modernes).
Bonnes pratiques AD DS
- Au minimum deux DC par site critique ; conservez un DC en Azure pour PRA.
- DNS et DHCP redondants ; surveillance de la réplication (repadmin, DCDiag).
- GPO pour durcir SMB, NTLM et canaux sécurisés ; chiffrement SMB requis côté serveurs de fichiers sensibles.
Stratégies PRA : répliquer, pas seulement basculer
Le basculement intra‑site (cluster) est différent de la reprise après sinistre inter‑site. Combinez :
- Storage Replica pour dupliquer des volumes de production vers un second site/cluster ; mode synchrone (RPO≈0) ou asynchrone (RPO > 0) selon la latence.
- Azure Site Recovery (ASR) pour orchestrer la bascule de VM vers Azure, tester vos playbooks de PRA sans impact de production et réduire le temps d’indisponibilité.
- DFS‑R pour distribuer des contenus de type lecture majoritaire (logiciels, référentiels), non transactionnels.
Plan d’implémentation opérationnel
- Qualification des workloads : listez les services à haute disponibilité ; marquez ceux qui nécessitent une copie unique de données (fichiers, SQL instance, VM) → candidats au stockage partagé.
- Choix de l’architecture :
- SAN + CSV si vous avez déjà une baie et des compétences MPIO.
- S2D si vous voulez supprimer la baie et basculer en hyper‑convergé.
- AG SQL / réplication applicative si le workload le permet.
- Conception du quorum : two‑node + Cloud Witness (compte de stockage Azure existant).
- Réseau : définir VLANs/VRFs, MTU, RDMA (RoCE/iWARP), QoS, chemins physiques indépendants.
- Sécurité : SMB Signing/Encryption pour SOFS, baselines OS, comptes gMSA pour services, segmentation et listes d’accès.
- Déploiement :
- Installer la feature Failover Clustering, Multipath I/O si SAN, agents HBA/DSM.
- Exécuter
Test-Cluster, corriger 100 % des erreurs, documenter les avertissements acceptés. - Créer le cluster, configurer le quorum, ajouter les disques ou activer S2D, formater en ReFS/NTFS.
- Activer CSV, créer les rôles (SOFS, File Server, SQL, Hyper‑V) et tester les basculements planifiés et non planifiés.
- Exploitation : activer Cluster‑Aware Updating, alerter sur événements critiques, sauvegarder via VSS (et tests de restauration réguliers).
Coûts, performances et capacité
- CapEx : SAN = baie + fabric ; S2D = serveurs avec beaucoup de disques NVMe/SSD + réseau 25/40/100 Gbps.
- OpEx : S2D réduit la dépendance constructeur mais exige une instrumentation réseau et stockage rigoureuse.
- Performance : file system ReFS recommandé pour Hyper‑V/S2D (allocation rapide, intégrité), NTFS pour compatibilité large.
- Capacité : planifiez 30 % de marge, définissez une politique de thin/thick provisioning, surveillez la consommation réelle vs engagée.
Checklist de validation avant mise en service
| Élément | Vérification | État |
|---|---|---|
Validation Test-Cluster | 0 erreur, avertissements documentés | ✔︎/✖︎ |
| Quorum | Cloud Witness opérationnel, perte d’un nœud testée | ✔︎/✖︎ |
| Stockage | MPIO actif, chemins redondants, CSV en ligne | ✔︎/✖︎ |
| Réseau | Redondance, VLANs, QoS, RDMA validés | ✔︎/✖︎ |
| Sauvegarde | VSS/agent testés, restauration validée | ✔︎/✖︎ |
| Basculement | Planifié/non planifié, RTO/RPO atteints | ✔︎/✖︎ |
| Supervision | Collecte PerfMon, journaux cluster, alertes | ✔︎/✖︎ |
Pièges à éviter
- Confondre HA et PRA : le cluster protège contre la panne locale ; répliquez pour couvrir la perte de site.
- Utiliser DFS‑R pour du transactionnel : risque de divergences et de conflits, inadéquat pour bases ou VHDX actifs.
- Négliger le quorum : sans témoin, un cluster à 2 nœuds est fragile lors d’un incident réseau.
- Oublier la sauvegarde : HA ≠ sauvegarde. Testez la restauration, pas seulement la sauvegarde.
- Mélanger disques hétérogènes sans politique : cohérence des performances mise à mal (S2D exige des classes homogènes).
- Laisser le CNO sans droits : le Cluster Name Object doit pouvoir créer/mettre à jour les objets AD nécessaires.
FAQ courte
Peut‑on faire un cluster sans stockage partagé ?
Oui : certaines charges répliquent nativement (SQL AG). Pour un serveur de fichiers ou des VM partagées, le stockage partagé via CSV reste la solution la plus simple et rapide en reprise.
Quel système de fichiers choisir ?
ReFS pour Hyper‑V/S2D (création VHDX, intégrité), NTFS pour compatibilité générale et outils historiques.
Cloud Witness consomme‑t‑il beaucoup ?
Non : seules des écritures légères d’objets témoin sont effectuées. L’impact coût/bande passante est marginal et le bénéfice de quorum est majeur.
Et si l’on veut étirer le cluster sur deux sites ?
Choisissez un stretched cluster avec Storage Replica synchrone < 5 ms RTT, ou asynchrone si la latence est plus élevée. Placez le témoin sur un troisième site (Azure recommandé).
Conclusion
Dans votre contexte bancaire, le stockage partagé — via CSV sur SAN/iSCSI ou via S2D — est la réponse la plus sûre pour les charges à état unique : cohérence de données, basculements rapides, exploitation maîtrisée. Conservez AD DS en réplication multi‑maître avec stockage local, et sécurisez le quorum avec un Cloud Witness. En complément, préparez la PRA avec Storage Replica et/ou Azure Site Recovery, et outillez la supervision/sauvegarde pour fermer la boucle de résilience. En suivant le plan d’implémentation, vous obtiendrez une plateforme à la fois robuste et opérationnellement sobre, prête pour les exigences réglementaires et la continuité d’activité du secteur financier.