Problème de suppression de nœuds de l’appartenance active au cluster de basculement

Cet article explique comment résoudre les problèmes liés à la suppression aléatoire de nœuds de l’appartenance active au cluster de basculement.

Symptômes

Lorsque le problème se produit, vous voyez des événements comme cet événement enregistrés dans votre 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é. La raison de cet événement est que l’un des nœuds du cluster a marqué ce nœud comme étant arrêté. Il avertit ensuite tous les autres nœuds de l’événement. Lorsque les nœuds sont avertis, ils interrompent et suppriment leurs connexions de pulsation au nœud en panne.

Pourquoi le nœud a-t-il été marqué hors service ?

Tous les nœuds d’un cluster de basculement Windows 2008 ou 2008 R2 communiquent entre eux sur les réseaux définis pour autoriser la communication réseau de cluster sur ce réseau. Les nœuds envoient des paquets de pulsation 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 place et que les autres nœuds sont en place. L’exemple suivant doit vous 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 une réponse de W2K8-R2-NODE1 à un paquet de pulsation afin qu’il détermine le réseau et le nœud est actif. Si W2K8-R2-NODE1 envoie une requête à W2K8-R2-NODE2 et que W2K8-R2-NODE1 n’obtient pas la réponse, elle est considérée comme une perte de pulsation et W2K8-R2-NODE1 en effectue le suivi. Cette réponse manquée peut faire que W2K8-R2-NODE1 affiche le réseau comme étant arrêté jusqu’à ce qu’une autre demande de pulsation soit reçue.

Par défaut, les nœuds de cluster ont une limite de cinq échecs dans 5 secondes avant que la connexion ne soit marquée. Par conséquent, si W2K8-R2-NODE1 ne reçoit pas la réponse cinq fois au cours de la période, il considère que cet itinéraire particulier vers W2K8-R2-NODE2 est arrêté. Si d’autres itinéraires sont toujours considérés comme étant activés, W2K8-R2-NODE2 reste un membre actif.

Si tous les itinéraires sont marqués pour W2K8-R2-NODE2, ils sont supprimés 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é afin qu’il puisse tenter de rejoindre le cluster.

Pour plus d’informations sur la façon dont nous gérons des itinéraires spécifiques qui tombent en panne avec au moins trois nœuds, consultez le blog « Réseaux de cluster partitionnés » écrit par Jeff Hughes.

Maintenant que nous savons comment fonctionne le processus de pulsation, quelles sont les causes connues de l’échec du processus

1. Défaillances matérielles réseau réelles. Si le paquet est perdu sur le câble quelque part entre les nœuds, les pulsations échouent. Une trace réseau des deux nœuds impliqués le révèle.

2. Le profil de vos connexions réseau peut éventuellement rebondir de Domaine à Public et de nouveau au Domaine. Pendant la transition de ces modifications, les E/S réseau peuvent être bloquées. Vous pouvez case activée pour voir si c’est le cas en examinant le journal des opérations du profil réseau. Vous pouvez trouver ce journal en ouvrant le observateur d'événements et en accédant à Journaux des applications et des 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 était en train de changer à ce stade. Si c’est le cas, consultez Le profil d’emplacement réseau passe de « Domaine » à « Public » dans Windows 7 ou windows Server 2008 R2.

3. IPv6 est activé sur les serveurs, mais les deux règles suivantes sont désactivées pour le trafic entrant et sortant dans le Pare-feu Windows :

   • Mise en réseau principale - Annonce de découverte du voisin
   • Mise en réseau principale - Sollicitation de découverte de voisin

4. Les logiciels antivirus peuvent également interférer avec ce processus. Si vous le soupçonnez, testez en désactivant ou en désinstallant le logiciel. Faites-le à vos propres risques, car vous n’êtes pas protégé contre les virus à ce stade.

5. La latence sur votre réseau peut également provoquer ce problème. Les paquets peuvent ne pas être perdus entre les nœuds, mais ils peuvent ne pas atteindre les nœuds assez rapidement avant l’expiration du délai d’expiration.

6. IPv6 est le protocole par défaut que le clustering de basculement utilisera pour ses pulsations. La pulsation proprement dite est un paquet réseau monocast UDP qui communique sur le port 3343. S’il existe des commutateurs, des pare-feu ou des routeurs non configurés correctement pour autoriser ce trafic, vous pouvez rencontrer des problèmes comme celui-ci.

7. Les actualisations de stratégie de sécurité IPsec peuvent également provoquer ce problème. Le problème spécifique est que, lors d’une mise à jour de stratégie de groupe IPSec, toutes les associations de sécurité IPsec sont détruites par le Pare-feu Windows avec sécurité avancée (WFAS). Pendant que cela se produit, toute la connectivité réseau est bloquée. Lors de la renégociation des associations de sécurité en cas de retards dans l’exécution de l’authentification avec Active Directory, ces retards (où toute la communication réseau est bloquée) empêchent également les pulsations de cluster de passer et entraînent la détection des nœuds comme étant en panne s’ils ne répondent pas dans le seuil de 5 secondes.

8. Pilotes et/ou microprogrammes de carte réseau anciens ou obsolètes. Parfois, une simple mauvaise configuration du carte réseau ou du commutateur peut également entraîner une perte de pulsations.

9. 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 le réseau carte sont définies trop bas ou que le serveur fonctionne lentement et ne peut pas gérer le trafic entrant. Chaque réseau carte fabricant choisit d’exposer ces paramètres dans les propriétés du réseau carte. Par conséquent, vous devez vous reporter au site web du fabricant pour savoir comment augmenter ces valeurs et les valeurs recommandées doivent être utilisées. Si vous exécutez sur VMware, le blog suivant en parle un peu plus en détail, y compris comment déterminer 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 enregistrés, mais il peut y avoir d’autres raisons également. Le but de ce blog était de vous donner un aperçu du processus et aussi donner des idées de ce qu’il faut rechercher. Certains élèvent les valeurs suivantes à leurs valeurs maximales pour essayer d’arrêter ce problème.

Parameter	Par défaut	Plage
SameSubnetDelay	1000 millisecondes	250-2000 millisecondes
CrossSubnetDelay	1000 millisecondes	250-4 000 millisecondes
SameSubnetThreshold	5	3-10
CrossSubnetThreshold	5	3-10

L’augmentation de ces valeurs à leur maximum peut faire disparaître l’événement et la suppression du nœud, ce qui masque simplement le problème. Ça ne résout rien. La meilleure chose à faire est de déterminer la cause racine des échecs de pulsation et de la corriger. Le seul besoin réel d’augmenter ces valeurs est dans un scénario multisite où les nœuds résident à différents emplacements et où la latence réseau ne peut pas être surmontée.