Cluster de basculement Windows Server 2019 sans stockage partagé en workgroup – guide complet

Deux serveurs physiques identiques sous Windows Server 2019 peuvent offrir une haute disponibilité sans stockage partagé ni domaine AD : en combinant Storage Replica ou Storage Spaces Direct, un quorum témoin et un cluster « workgroup », on obtient un basculement automatique robuste et économique.

Sommaire

Pourquoi un cluster « shared‑nothing » ?

Les solutions de partage de baie SAN ou NAS restent coûteuses et introduisent un point de défaillance unique. Depuis Windows Server 2016, Microsoft promeut le modèle shared‑nothing, où chaque nœud gère son propre stockage local répliqué de façon synchrone ou asynchrone. Les avantages sont multiples :

  • Élimination des frais d’infrastructure SAN.
  • Meilleure isolation : la panne d’un disque n’impacte qu’un nœud.
  • Évolutivité horizontale – on ajoute un serveur pour accroître la capacité.
  • Simplicité de déploiement en sites distants ou PME.

Architecture cible

Le schéma minimal comprend :

  1. Nœud A : Windows Server 2019 Datacenter ou Standard, groupe de travail.
  2. Nœud B : même configuration matérielle et logicielle.
  3. Témoin (quorum) : partage SMB tiers ou Cloud Witness Azure.
  4. Lien de réplication : 10 GbE recommandé, latence < 5 ms pour du synchrone.

L’application résidera sur un volume répliqué (Storage Replica) ou sur un rôle applicatif géré par le cluster.

Conditions préalables

ÉlémentExigence
Système d’exploitationWindows Server 2019 fully patched
LicenceDatacenter pour Storage Replica synchrone illimité ; Standard limitée à 1 volume ≤ 2 TB
MatérielServeurs identiques : même CPU, RAM, firmware, drivers, HBA
RéseauDeux cartes : 1 LAN client, 1 replication/cluster (idéalement isolée)
Comptes locauxAdministrateur local même nom/mot de passe sur les deux nœuds

Mise en place pas à pas

1. Activer la fonctionnalité de clustering

Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools

2. Vérifier la préparation des nœuds

Test-Cluster -Node SRV1,SRV2 -Include "Storage Spaces Direct","Inventory","Network","System Configuration"

Corrigez toutes les erreurs signalées avant d’aller plus loin.

3. Créer le cluster sans stockage partagé

New-Cluster -Name CL-WORKGRP -Node SRV1,SRV2 -NoStorage -StaticAddress 10.10.10.100

Le paramètre -NoStorage empêche l’assistant de tenter d’agréger des LUN partagées.

4. Configurer le quorum

File Share Witness :

Set-ClusterQuorum -FileShareWitness \\NAS01\Witness

Cloud Witness :

Set-ClusterQuorum -CloudWitness `
   -AccountName monstorageaccount `
   -AccessKey "<CléAzure>"

5. Mettre en place la réplication de stockage

Supposons un volume D: sur chaque nœud :

# Sur SRV1
New-SRPartnership -SourceComputerName SRV1 -SourceRGName RG1 `
                  -DestinationComputerName SRV2 -DestinationRGName RG2 `
                  -LogVolumeName E: -SourceVolumeName D: `
                  -DestinationVolumeName D: -ReplicationMode Sync

La création des groupes de réplication (New-SRGroup) et des volumes journaux (10 – 20 % de la taille du volume) précède ce partenariat.

6. Ajouter le rôle applicatif

Selon la nature du logiciel :

  • Service Windows : Assistant « Rôle générique de service ».
  • Exécutable/Script : Ressource application générique.
  • Base SQL Server : Configuration d’AG Always On + Listener.

Chaque rôle se voit attribuer une adresse IP virtuelle et, au besoin, un nom NetBIOS.

7. Tester les basculements

Invoke-Command -ComputerName SRV1 `
  -ScriptBlock { Stop-Computer -Force }

Surveillez dans le Gestionnaire de cluster que le service passe automatiquement sur SRV2 puis revient selon la politique failback.

Gestion et surveillance

Journaux et alertes

  • Événements StorageReplica 160, 164 : état de la réplication.
  • Événements FailoverClustering 1069, 1135 : ressource ou nœud indisponible.
  • PerfMon : compteurs Storage Replica Replicated Log Write Latency.

Maintenance sans interruption

  1. Mettre le rôle en maintenance (Pause – Drain Roles).
  2. Appliquer les mises à jour Windows et firmware.
  3. Redémarrer le nœud.
  4. Reprendre les rôles (Resume Cluster Node).
  5. Répéter sur l’autre serveur.

Cette méthode rolling upgrade garantit qu’un nœud reste actif en permanence.

Limitations importantes

  • Pas d’authentification Kerberos en workgroup. Les ressources requérant Kerberos (ex. DFS Namespaced, File Server SOFS) ne peuvent pas être hautement disponibles hors domaine.
  • Les stratégies GPO ne s’appliquent pas ; toute configuration doit être locale ou scriptée.
  • Le quorum File Share nécessite que le partage tiers reste accessible ; si le LAN tombe, privilégier Cloud Witness ou un troisième site.
  • En édition Standard, un seul partenariat Storage Replica est autorisé.

Bonnes pratiques de performance

Bonnes pratiquesDétails
Dual NICDédier un VLAN à la réplication pour éviter la saturation du LAN utilisateur.
Jumbo FramesActiver sur le lien de réplication pour réduire l’overhead TCP.
QoSLimiter le trafic SR si d’autres services critiques partagent le réseau.
Disques NVMeRéduisent la latence du journal SR, améliorant le RPO.
Surveillance continueIntégrer OMS/Azure Monitor ou un outil SNMP pour recevoir des alertes.

Alternatives et compléments

  • Hyper‑V Replica pour les charges virtuelles, mais cela nécessite un hyperviseur.
  • Solutions tierces comme Quest Double‑Take ou Veeam CDP pouvant répliquer au niveau bloc vers un site distant.
  • Backup immuable (Azure Backup with Immutable Vault) pour protéger contre la corruption logique.

FAQ

Faut‑il obligatoirement deux réseaux distincts ?
Non, mais un réseau unique constitue un SPOF ; deux VLANs augmentent la résilience.

Puis‑je étendre le cluster à un troisième nœud plus tard ?
Oui. Ajoutez le serveur, activez Failover Clustering, validez (Test-Cluster) puis utilisez Add-ClusterNode. Le quorum passera automatiquement en Node Majority.

Quelle taille pour le volume de journal Storage Replica ?
Microsoft recommande 8 – 12 % du volume répliqué, avec un minimum de 9 GB et un maximum de 100 GB.

Comment mesurer le RTO ?
Utilisez Get-ClusterGroup pour chronométrer le déplacement de rôle entre les nœuds et corréler aux logs d’application.

Conclusion

Grâce aux innovations Storage Replica et au support des clusters « workgroup », Windows Server 2019 permet de bâtir un environnement haute disponibilité sans stockage partagé ni domaine AD. Une planification rigoureuse, un témoin fiable et une surveillance proactive transforment deux serveurs standards en plate‑forme continue pour vos applications critiques.

Sommaire