Windows Server 2025 / Comment planifier un cluster de basculement

Le clustering de basculement de Windows Server répartit les rôles compatibles entre plusieurs nœuds et peut les redémarrer ou les déplacer après une panne. Deux serveurs ne suffisent pas à eux seuls : la compatibilité des applications, le stockage, le réseau, le quorum, la validation et les objectifs de reprise doivent être cohérents.

Définissez la panne que vous devez pouvoir supporter

Un nœud est un serveur participant. Un rôle en cluster regroupe des ressources de service ou de machine virtuelle gérées ensemble. La détection et la transition peuvent interrompre les connexions, il faut donc tester la reconnexion des clients et la reprise des applications.

La haute disponibilité ne remplace pas la sauvegarde ou la reprise après sinistre. Deux machines virtuelles partageant l'alimentation, un hôte physique ou du stockage peuvent tomber en panne simultanément. Activer le clustering sur des serveurs IIS ordinaires ne rend pas automatiquement leurs sites hautement disponibles.

Définissez d’abord le rôle protégé, l'objectif de temps de récupération (RTO) et l'objectif de point de récupération (RPO). Le RTO concerne le temps de récupération acceptable ; le RPO concerne la perte de données acceptable mesurée par rapport à un point de récupération.

Examinez les exigences de nœuds, de réseau et de capacité

Vérifiez les exigences matérielles et de stockage du cluster par rapport à la version de Windows Server, au matériel pris en charge, aux pilotes et au microprogramme. Une nouvelle conception peut commencer avec des nœuds Windows Server 2025 de configuration comparable. Ne mélangez pas les conditions d’un déploiement dans un domaine avec les conditions propres aux clusters en groupe de travail.

• Cartographiez les réseaux et la bande passante réservés à la gestion, au cluster, au stockage et à la migration des machines virtuelles.
• Identifiez les points de défaillance uniques dans les cartes réseau, les commutateurs, l'alimentation et les chemins de stockage.
• Prévoyez suffisamment de capacité restante en CPU, mémoire et stockage après la défaillance d'un nœud.
• Pour un déploiement de domaine, vérifiez le DNS interne, l'heure, l'identité du cluster et les autorisations d'enregistrement de nom.

Gardez les adresses, noms, VLANs et exigences du pare-feu dans un plan réseau partagé. Les adaptateurs multiples ne fournissent pas de chemins indépendants s’ils dépendent du même commutateur et du même itinéraire de câblage.

Choisissez le stockage pris en charge par le rôle

Les disques partagés, le stockage SMB et Storage Spaces Direct ont des conditions de rôle, de matériel, d’édition et de support. Des noms de dossiers locaux identiques sur deux nœuds ne fournissent pas de données partagées. Les espaces de noms DFS (Distributed File System) ne fournissent pas non plus automatiquement la réplication ou le stockage en cluster.

Utilisez un environnement de test séparé avant de présenter les disques de production aux tests de validation de la configuration ou du stockage. Protégez les données et comprenez la propriété et le contrôle des disques, les réservations, les chemins et les conditions de licence de l'architecture sélectionnée.

Planifiez les domaines de défaillance du quorum et du témoin

Le quorum détermine si le cluster peut continuer à fonctionner, même lorsque la communication est partitionnée. Il aide à éviter la prise de contrôle concurrente des ressources. Un témoin contribue aux décisions de quorum ; il n’est pas une sauvegarde des données du service ni un nœud supplémentaire qui exécute la charge de travail.

Comparez les options de disque, de partage de fichiers et de cloud dans les directives de déploiement du témoin de quorum. Prenez en compte la localisation, les autorisations, les partitions réseau et la connectivité externe ainsi que le nombre de nœuds. Le quorum dynamique ne tolère pas toutes les combinaisons de défaillances arbitraires.

Un témoin dans le même domaine de défaillance peut disparaître avec les deux nœuds. Un témoin distant exige toujours des chemins réseau fonctionnels et les autorisations nécessaires. Énumérez les défaillances spécifiques à supporter avant de choisir son type et son emplacement.

Intégrez la validation dans la décision de déploiement

1. Documentez les nœuds, les réseaux, le stockage, les comptes, les noms et les rôles protégés.
2. Alignez les fonctionnalités, les mises à jour, les pilotes et les exigences de support.
3. Planifiez la validation de la configuration avant de créer le cluster, puis résolvez ou expliquez chaque avertissement et échec.
4. Testez les déplacements planifiés séparément des échecs inattendus.
5. Mesurez la reconnexion des clients, la cohérence des données, le temps de récupération et la livraison des alertes.
6. Validez la restauration des sauvegardes et la perte complète d’un domaine de défaillance séparément.

Suivez les directives de création et de validation de cluster pour l’architecture choisie. Les tests de stockage peuvent affecter le service, évitez donc de les lancer sans discernement en production. Conservez le rapport et documentez pour chaque constat sa cause, son impact et l’action prévue.

Cet exercice de planification ne convertit pas les serveurs de cours existants en un cluster. Il doit produire une architecture compatible avec le rôle protégé, une estimation des ressources nécessaires, une carte des domaines de défaillance, des objectifs de reprise et un plan de validation confié à des responsables identifiés.