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.
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 :
- Nœud A : Windows Server 2019 Datacenter ou Standard, groupe de travail.
- Nœud B : même configuration matérielle et logicielle.
- Témoin (quorum) : partage SMB tiers ou Cloud Witness Azure.
- 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ément | Exigence |
---|---|
Système d’exploitation | Windows Server 2019 fully patched |
Licence | Datacenter pour Storage Replica synchrone illimité ; Standard limitée à 1 volume ≤ 2 TB |
Matériel | Serveurs identiques : même CPU, RAM, firmware, drivers, HBA |
Réseau | Deux cartes : 1 LAN client, 1 replication/cluster (idéalement isolée) |
Comptes locaux | Administrateur 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
- Mettre le rôle en maintenance (Pause – Drain Roles).
- Appliquer les mises à jour Windows et firmware.
- Redémarrer le nœud.
- Reprendre les rôles (Resume Cluster Node).
- 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 pratiques | Détails |
---|---|
Dual NIC | Dédier un VLAN à la réplication pour éviter la saturation du LAN utilisateur. |
Jumbo Frames | Activer sur le lien de réplication pour réduire l’overhead TCP. |
QoS | Limiter le trafic SR si d’autres services critiques partagent le réseau. |
Disques NVMe | Réduisent la latence du journal SR, améliorant le RPO. |
Surveillance continue | Inté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.