Problème lié à la suppression des nœuds de l’appartenance au cluster de basculement actif
Cet article explique comment résoudre les problèmes liés à la suppression aléatoire de nœuds de l’appartenance active à un cluster de basculement.
Symptômes
Lorsque le problème se produit, vous voyez des événements comme cet événement enregistré dans le journal des événements système :
Cet événement est enregistré sur tous les nœuds du cluster, à l’exception du nœud qui a été supprimé. Cet événement se produit parce que l’un des nœuds du cluster a marqué ce nœud comme inactif. Il informe ensuite tous les autres nœuds de l’événement. Quand les nœuds sont informés, ils arrêtent et désactivent leurs connexions de pulsation avec le nœud inactif.
Pourquoi le nœud a-t-il été marqué comme inactif ?
Tous les nœuds d’un cluster de basculement Windows Server communiquent entre eux sur les réseaux qui sont définis pour autoriser la communication réseau de cluster sur ce réseau. Les nœuds envoient des paquets de pulsations sur ces réseaux à tous les autres nœuds. Ces paquets sont censés être reçus par les autres nœuds, puis une réponse est renvoyée. Chaque nœud du cluster a ses propres pulsations qu’il va surveiller pour s’assurer que le réseau est en cours et que les autres nœuds sont en cours. L’exemple suivant doit aider à clarifier ce comportement :
Si l’un de ces paquets n’est pas retourné, la pulsation spécifique est considérée comme ayant échoué. Par exemple, W2K8-R2-NODE2 envoie une requête et reçoit de W2K8-R2-NODE1 une réponse à un paquet de pulsations. Il détermine ainsi que le réseau et le nœud sont actifs. Si W2K8-R2-NODE1 envoie une requête à W2K8-R2-NODE2 et W2K8-R2-NODE1 n’obtient pas la réponse, elle est considérée comme une pulsation perdue et W2K8-R2-NODE1 effectue le suivi. De par cette non-réponse, W2K8-R2-NODE1 peut indiquer le réseau comme inactif jusqu’à ce qu’une autre requête de pulsation soit reçue.
Par défaut, les nœuds de cluster ont une limite de cinq échecs en 5 secondes avant que la connexion ne soit marquée comme inactive. Par conséquent, si W2K8-R2-NODE1 ne reçoit pas la réponse cinq fois dans la période, il considère que l’itinéraire particulier vers W2K8-R2-NODE2 doit être arrêté. Si d’autres routes sont toujours considérées comme actives, W2K8-R2-NODE2 reste un membre actif.
Si tous les itinéraires sont marqués vers le bas pour W2K8-R2-NODE2, il est supprimé de l’appartenance active au cluster de basculement et l’événement 1135 que vous voyez dans la première section est journalisé. Sur W2K8-R2-NODE2, le service de cluster est arrêté, puis redémarré pour qu’il puisse essayer de rejoindre le cluster.
Pour plus d’informations sur la façon dont nous gérons les routes spécifiques devenant inactives avec trois nœuds ou plus, consultez le blog « Partitioned » Cluster Networks (Réseaux en cluster « partitionnés ») écrit par Jeff Hughes.
Nous savons maintenant comment fonctionne le processus de pulsation. Examinons à présent certaines causes connues de l’échec du processus.
Réelles défaillances matérielles du réseau. Si le paquet est perdu sur le câble quelque part entre les nœuds, les pulsations échouent. Ceci peut être déterminé avec une trace réseau à partir des deux nœuds impliqués.
Il se peut que le profil de vos connexions réseau passe de Domaine à Public, puis, de nouveau à Domaine. Pendant que ces phases de transition, les E/S réseau peuvent être bloquées. Vous pouvez vérifier si c’est le cas en examinant le journal des opérations de profil réseau. Vous trouverez ce journal en ouvrant l’Observateur d’événements et en accédant aux journaux des applications et services\Microsoft\Windows\NetworkProfile\Operational. Examinez les événements de ce journal sur le nœud mentionné dans l’ID d’événement 1135 et vérifiez si le profil a changé pour l’instant. Si c’est le cas, consultez le profil d’emplacement réseau qui passe de « Domaine » à « Public » dans Windows 7 ou dans Windows Server 2008 R2.
IPv6 est activé sur les serveurs, mais les deux règles suivantes sont désactivées pour le trafic entrant et le trafic sortant dans le Pare-feu Windows :
- Réseau de base - Publication de découverte de voisin
- Réseau de base - Sollicitation de découverte de voisin
Il se peut également qu’un logiciel antivirus interfère avec ce processus. Si cela fait partie de vos hypothèses, faites un test en désactivant ou en désinstallant le logiciel. Faites cela à votre propre risque, car vous n’êtes pas protégé contre les virus à ce stade.
La latence sur votre réseau peut également être à l’origine de ce problème. Les paquets peuvent ne pas être perdus entre les nœuds, mais ils risquent de ne pas accéder aux nœuds suffisamment rapidement avant l’expiration de la période d’expiration.
IPv6 est le protocole utilisé par le clustering de basculement pour ses pulsations par défaut. La pulsation elle-même est un paquet réseau de monodiffusion UDP qui communique sur le port 3343. En présence de commutateurs, pare-feux ou routeurs qui ne sont pas configurés correctement pour autoriser ce trafic, vous pouvez rencontrer ce type de problème.
Les actualisations de stratégie de sécurité IPsec peuvent également provoquer ce problème. Le problème spécifique est que durant une mise à jour de stratégie de groupe IPSec, toutes les associations de sécurité IPsec sont désactivées par le Pare-feu Windows avec fonctions avancées de sécurité (WFAS). Pendant ce temps, toute la connectivité réseau est bloquée. Lorsque vous renégociez les associations de sécurité s’il y a des retards dans l’exécution de l’authentification avec Active Directory, ces retards (où toutes les communications réseau sont bloquées) empêchent également l’exécution des pulsations de cluster et provoquent l’analyse de l’intégrité du cluster pour détecter les nœuds comme s’ils ne répondent pas au seuil de 5 secondes.
Pilotes de carte réseau et/ou microprogrammes anciens ou obsolètes. Parfois, une simple configuration incorrecte du commutateur ou de la carte réseau peut également entraîner la perte de pulsations.
Les cartes réseau modernes et les cartes réseau virtuelles peuvent rencontrer une perte de paquets. Cela peut être suivi en ouvrant Analyseur de performances et en ajoutant le compteur « Interface réseau\Paquets reçus ignorés ». Ce compteur est cumulatif et augmente uniquement jusqu’à ce que le serveur soit redémarré. Voir un grand nombre de paquets supprimés ici peut être un signe que les mémoires tampons de réception sur la carte réseau sont définies trop bas ou que le serveur s’exécute lentement et ne peut pas gérer le trafic entrant. Chaque fabricant de carte réseau choisit d’exposer ou non ces paramètres dans les propriétés de la carte réseau. Vous devez donc vous reporter au site web du fabricant pour savoir comment augmenter ces valeurs et comment utiliser les valeurs recommandées. Si vous exécutez sur VMware, le blog suivant parle de cela en un peu plus de détails, notamment comment savoir si c’est le problème et vous pointe vers l’article VMware sur les paramètres à modifier.
Nœuds supprimés de l’appartenance au cluster de basculement sur VMware ESX
Il s’agit des raisons les plus courantes pour lesquelles ces événements sont journalisés. Il peut cependant y avoir d’autres raisons. Le but de ce blog est de vous permettre de mieux comprendre le processus et de vous orienter sur ce qu’il faut rechercher. Certains utilisateurs augmentent les valeurs suivantes au maximum pour essayer d’éliminer ce problème.
| Paramètre | Default | Plage |
|---|---|---|
| SameSubnetDelay | 1 000 millisecondes | 250-2 000 millisecondes |
| CrossSubnetDelay | 1 000 millisecondes | 250-4 000 millisecondes |
| SameSubnetThreshold | 5 | 3-10 |
| CrossSubnetThreshold | 5 | 3-10 |
L’augmentation de ces valeurs à leur maximum peut rendre l’événement et la suppression du nœud disparaître, il masque simplement le problème. Cela ne corrige rien. La meilleure chose à faire consiste à déterminer la cause racine des échecs de pulsation et à le corriger. La seule nécessité réelle d’augmenter ces valeurs se trouve dans un scénario multi-site où les nœuds résident dans différents emplacements et la latence réseau ne peuvent pas être surmontés.