Des nœuds de Cluster se retrouvent hors cluster
Des nœuds de Cluster se retrouvent hors du cluster.
Event ID 1135
Cluster node ‘NODE A’ was removed from the active failover cluster membership. The Cluster service on this node may have stopped. This could also be due to the node having lost communication with other active nodes in the failover cluster. Run the Validate a Configuration wizard to check your network configuration. If the condition persists, check for hardware or software errors related to the network adapters on this node. Also check for failures in any other network components to which the node is connected such as hubs, switches, or bridges.
Cet évènement signale qu’un membre du Cluster actif a été sorti. Ce phénomène survient lorsqu’un ou un groupe de nœud ne parviennent plus à communiquer entre-deux sur le port 3343. Ces communications réseaux sont gérées par le driver réseaux virtuel, NetFT.SYS, lorsque la feature Failover Cluster est installée. Elles sont appelées Communication Intra-Cluster et sont nécessaires pour surveiller l’état et le bon fonctionnement de chacun des nœuds qui forment le Cluster.
Sans rentrer forcement dans le détail, NetFT.SYS communique sur tous les réseaux disponibles dans un Cluster afin de s’assurer que les chemins réseaux (Public et privé à minima) sont opérationnels. Ceci est fait via les signaux heartbeat qui sont envoyés périodiquement par chacun des nœuds à tous les membres.
Lorsqu’un problème survient sur les communications intra-cluster que NetFT a fini de tester la viabilité de toutes les connexions réseaux, cet évènement ID 1135 apparaît et est notifié à tous les nœuds.
Bien souvent, les administrateurs IT ne peuvent que constater ce phénomène et il n’est pas évident de trouver la cause de cette coupure de communication.
Alors que faire ?
1- updates…
Il se peut qu’il ait des disfonctionnements au niveau de l’OS et/ou drivers network. Une bonne pratique basique est de procéder aux mises à jour de quelques composants.
Recommended hotfixes and updates for Windows Server 2012 R2-based failover clusters
Recommended hotfixes and updates for Windows Server 2012-based failover clusters
Recommended hotfixes and updates for Windows Server 2008 R2 SP1 Failover Clusters
2- Backup en cours.
Bien souvent, ces évènements ID 1135 surviennent lors des périodes de backup. En effet, j’ai souvent observé à partir de traces Perfmon ou Xperf, une augmentation significative des DPC, ne laissant plus assez de temps processeurs de traiter les interruptions réseaux.
Il est alors nécessaire de sérialiser les backups ou de revoir la politique mise en place pour les sauvegardes des données du Cluster.
3- Guest Cluster sous VMWare
Un problème connu sous VMware peut entrainer des drops des paquets réseaux et ainsi causer la perte de communications Intra-Cluster.
Ce problème touche les adaptateurs VMXNET3 et est documenté ci-dessous.
4- Tuning des heartbeat
Enfin et si le problème est aléatoire, que vous souhaitez le faire disparaître rapidement, nous pouvons modifier les tolérances de détections de perte de communication intra-Cluster en modifiant ces paramètres du cluster.
Les paramètres sont les suivants :
Propriété |
Défaut |
Maximum |
SameSubnetDelay |
1 seconde |
2 secondes |
SameSubnetThreshold |
5 heartbeats (10 si Hyper-V 2012 R2) |
120 heartbeats |
CrossSubnetDelay |
1 seconde |
4 secondes |
CrossSubnetThreshold |
5 heartbeats (20 si Hyper-V 2012 R2) |
120 heartbeats |
La configuration se fait par Powershell, par exemple :
(get-cluster).SameSubnetDelay = 2 enverra un heartbeat toutes les 2 secondes au lieu de toutes les secondes.
A partir de Windows Server 2012, il y a du logging additionnel pour le Cluster.log pour ce qui est du trafic du Heartbeat droppé. Par défaut, RouteHistoryLength est mis à 10, ce qui est 2x le nombre par défaut des seuils. Si vous modifiez les valeurs de SameSubnetThreshold ou CrossSubnetThrehold, il est recommandé de doubler la valeur de RouteHistoryLength afin de pouvoir troubleshooter plus en détail dans le Cluster.log. Ceci peut être fait avec cette commande PowerShell :
PS C:\Windows\system32> (get-cluster).RouteHistoryLength = 20