Résoudre le problème de cluster avec l’ID d’événement 1135

Cet article vous aide à diagnostiquer et à résoudre l’ID d’événement 1135, qui peut être enregistré lors du démarrage du service de cluster dans l’environnement de clustering de basculement.

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016, Azure Stack HCI, versions 21H2 et 20H2

Essayez notre agent virtuel : il peut vous aider à identifier et à résoudre rapidement les problèmes courants de réplication Active Directory.

Page de démarrage

L’ID d’événement 1135 indique qu’un ou plusieurs nœuds de cluster ont été supprimés de l’appartenance active au cluster de basculement. Elle peut être accompagnée des symptômes suivants :

• Basculement de cluster\nodes supprimés de l’appartenance active au cluster de basculement :

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

• ID d’événement 1069 :

  ID d’événement 1069 - Disponibilité des applications ou des services en cluster

• ID d’événement 1177 pour la perte de quorum :

  ID d’événement 1177 - Quorum et connectivité nécessaires pour le quorum

• ID d’événement 1006 pour le service de cluster arrêté :

  ID d’événement 1006 - Démarrage du service de cluster

Une validation et les tests réseau sont recommandés comme l’une des étapes de dépannage initiales pour vous assurer qu’il n’existe aucun problème de configuration pouvant être une cause de problème.

Vérifier si les correctifs à chaud recommandés sont installés

Le service cluster est le composant logiciel essentiel qui contrôle tous les aspects du fonctionnement du cluster de basculement et gère la base de données de configuration du cluster. Si vous voyez l’ID d’événement 1135, nous vous recommandons d’installer les correctifs mentionnés dans les articles suivants et de redémarrer tous les nœuds du cluster, puis de vérifier si le problème se reproduit.

• Correctifs et mises à jour recommandés pour les clusters de basculement Windows Server 2012 R2
• Correctifs et mises à jour recommandés pour les clusters de basculement Windows Server 2012
• Correctifs logiciels et mises à jour recommandés pour les clusters de basculement Windows Server 2008 R2 SP1

Vérifier si le service de cluster s’exécute sur tous les nœuds

Suivez la commande suivante en fonction de votre système d’exploitation Windows pour vérifier que le service de cluster est en cours d’exécution et disponible en continu.

Pour le cluster Windows Server 2008 R2

À une invite de commandes avec privilèges élevés, exécutez cluster.exe node /stat.

Pour Windows Server 2012 et Windows Server 2012 cluster R2

Exécutez l’applet de commande PowerShell suivante : Get-ClusterResource

Le service de cluster est-il en cours d’exécution et disponible sur tous les nœuds ?

Plusieurs scénarios d’ID d’événement 1135

Nous voulons que vous examiniez de plus près les journaux des événements système sur tous les nœuds de votre cluster. Passez en revue l’ID d’événement 1135 que vous voyez sur les nœuds et copiez toutes les instances de cet événement. Cela vous permettra de les examiner et de les examiner.

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.

Il existe trois scénarios classiques :

Scénario A

Vous examinez tous les événements et tous les nœuds du cluster indiquent que le nœud A a perdu la communication.

Il est possible que lorsque vous voyez les journaux système sur le nœud A, il comporte des événements pour tous les nœuds restants du cluster.

Solution

Cela suggère tout à fait qu’au moment du problème, soit en raison d’une congestion du réseau, soit de la communication avec le NŒUD A a été perdue.

Vous devez examiner et valider les problèmes de configuration et de communication réseau. N’oubliez pas de rechercher les problèmes liés au nœud A.

Scénario B

Vous examinez les événements sur les nœuds et laissez-nous dire que votre cluster est dispersé sur deux sites. NODE A, NODE B et NODE C sur le site 1 et NODE D & NODE E au site 2.

Sur les nœuds A, B et C, vous voyez que les événements enregistrés concernent la connectivité aux nœuds D & E. De même, lorsque vous voyez les événements sur les nœuds D & E, les événements suggèrent que nous avons perdu la communication avec A, B et C.

Solution

Si vous voyez une activité similaire, cela indique qu’il y a eu un échec de communication, via le lien qui connecte ces sites. Nous vous recommandons de passer en revue la connexion entre les sites. S’il s’agit d’une connexion WAN, nous vous suggérons de vérifier avec votre isp la connectivité.

Scénario C

Vous examinez les événements sur les nœuds et vous voyez que les noms des nœuds ne correspondent pas à un modèle particulier. Supposons que votre cluster soit dispersé sur deux sites. NODE A, NODE B et NODE C au site 1 et NODE D & NODE E au site 2.

• Sur le nœud A : vous voyez des événements pour les nœuds B, D, E.
• Sur le nœud B : vous voyez des événements pour les nœuds C, D, E.
• Sur le nœud C : vous voyez des événements pour les nœuds A, B, E.
• Sur le nœud D : vous voyez des événements pour les nœuds A, C, E.
• Sur le nœud E : vous voyez des événements pour les nœuds B, C, D.
• Ou toute autre combinaison.

Solution

De tels événements sont possibles lorsque les canaux réseau entre les nœuds sont étouffés et que les messages de communication du cluster n’atteignent pas en temps voulu, ce qui fait que le cluster a l’impression que la communication entre les nœuds est perdue, ce qui entraîne la suppression des nœuds de l’appartenance au cluster.

Passer en revue les réseaux de cluster

Nous vous recommandons de passer en revue vos réseaux de cluster en consultant les trois options suivantes une par une pour continuer ce guide de résolution des problèmes.

Rechercher l’exclusion de l’antivirus

Excluez les emplacements de système de fichiers suivants de l’analyse antivirus sur un serveur qui exécute les services de cluster :

• Chemin d’accès du témoin FileShare
• Dossier %Systemroot%\Cluster

Configurez le composant d’analyse en temps réel dans votre logiciel antivirus pour exclure les répertoires et fichiers suivants :

• Répertoire de configuration de la machine virtuelle par défaut (C :\ProgramData\Microsoft\Windows\Hyper-V)

• Répertoires de configuration de machine virtuelle personnalisés

• Répertoire de lecteur de disque dur virtuel par défaut (C :\Users\Public\Documents\Hyper-V\Virtual Hard Disks)

• Répertoires de lecteur de disque dur virtuel personnalisés

• Répertoires de données de réplication personnalisés, si vous utilisez un réplica Hyper-V

• Répertoires d’instantanés

• mms.exe

  Remarque

  Ce fichier peut être configuré en tant qu’exclusion de processus dans le logiciel antivirus.

• Vmwp.exe

  Remarque

  Ce fichier peut être configuré en tant qu’exclusion de processus dans le logiciel antivirus.

En outre, lorsque vous utilisez la migration dynamique avec des volumes partagés de cluster, excluez le chemin CSV C :\Clusterstorage et tous ses sous-répertoires. Si vous résolvez des problèmes de basculement ou des problèmes généraux liés aux services de cluster et qu’un logiciel antivirus est installé, désinstallez temporairement le logiciel antivirus ou case activée avec le fabricant du logiciel pour déterminer si le logiciel antivirus fonctionne avec les services de cluster. La simple désactivation du logiciel antivirus est insuffisante dans la plupart des cas. Même si vous désactivez le logiciel antivirus, le pilote de filtre est toujours chargé lorsque vous redémarrez l’ordinateur.

Vérifier la configuration du port réseau dans le pare-feu

Le Service de clusters contrôle les opérations de cluster du serveur et gère la base de données du cluster. Un cluster est un ensemble d’ordinateurs indépendants qui agissent en tant qu’ordinateur unique. Les gestionnaires, les programmeurs et les utilisateurs voient le cluster comme un système unique. Le logiciel distribue les données aux nœuds du cluster. En cas de défaillance d’un nœud, les autres nœuds fournissent les services et données correspondants à sa place. Lorsque qu’un nœud est ajouté ou réparé, le logiciel de cluster migre certaines données vers ce nœud.

Nom du service système : ClusSvc

Application	Protocole	Ports
Service de clusters	UDP	3343
Service de clusters	TCP	3343 (Ce port est obligatoire pendant les opérations de jonction de nœuds.)
RPC	TCP	135
Administration de cluster	UDP	137
Kerberos	UDP/TCP	464*
SMB	TCP	445
Ports UDP élevés alloués de manière aléatoire**	UDP	Numéro de port aléatoire entre 1024 et 65535 Numéro de port aléatoire compris entre 49152 et 65535***

Remarque

En outre, pour une validation réussie sur les clusters de basculement Windows sur Windows Server 2008 et versions ultérieures, autorisez le trafic entrant et sortant pour ICMP4, ICMP6.

• Pour plus d’informations, consultez La création d’un cluster de basculement Windows Server 2012 échoue avec 0xc000005e d’erreur.
• Pour plus d’informations sur la personnalisation de ces ports, consultez la section « Références » dans Vue d’ensemble du service et configuration requise des ports réseau pour Windows.

Il s’agit de la plage dans Windows Server 2012, Windows 8, Windows Server 2008 R2, Windows 7, Windows Server 2008 et Windows Vista.

En outre, exécutez la commande suivante pour case activée pour la configuration du port réseau dans le pare-feu. Par exemple : cette commande permet de déterminer le port 3343 available\open utilisé pour le cluster de basculement :

netsh advfirewall firewall show rule name="Failover Clusters (UDP-In)" verbose

Exécuter le rapport de validation du cluster pour toutes les erreurs ou avertissements

L’outil de validation de cluster exécute une suite de tests pour vérifier que votre matériel et vos paramètres sont compatibles avec les clustering de basculement.

Suivez ces instructions :

1. Exécutez le rapport de validation du cluster pour toutes les erreurs ou avertissements. Pour plus d’informations, consultez Présentation des tests de validation de cluster : réseau

   

2. Vérifiez la recherche d’avertissements et d’erreurs pour les réseaux. Pour plus d’informations, consultez Présentation des tests de validation de cluster : réseau.

   

   

Vérifier l’ordre de liaison réseau de liste

Ce test répertorie l’ordre dans lequel les réseaux sont liés aux cartes sur chaque nœud.

L’onglet Cartes et liaisons répertorie les connexions dans l’ordre dans lequel les services réseau accèdent aux connexions. L’ordre de ces connexions reflète l’ordre dans lequel les appels/paquets TCP/IP génériques sont envoyés sur le câble.

Suivez les étapes ci-dessous pour modifier l’ordre de liaison des cartes réseau :

1. Sélectionnez Démarrer, Exécuter, tapez ncpa.cpl, puis sélectionnez OK. Vous pouvez voir les connexions disponibles dans la section Réseau local et High-Speed Internet de la fenêtre Connections réseau.
2. Dans le menu Avancé , sélectionnez Paramètres avancés, puis sélectionnez l’onglet Adaptateurs et liaisons .
3. Dans la zone Connections, sélectionnez la connexion que vous souhaitez déplacer plus haut dans la liste. Utilisez les boutons de direction pour déplacer la connexion. En règle générale, le carte qui communique avec le réseau (connectivité de domaine, routage vers d’autres réseaux, etc.) doit être la première liaison (en haut de la liste) carte).

Les nœuds de cluster sont des systèmes multi-hébergés. La priorité réseau affecte le client DNS pour la connectivité réseau sortante. Les cartes réseau utilisées pour la communication client doivent être en haut de l’ordre de liaison. Les réseaux non routés peuvent être placés en priorité inférieure. Dans Windows Server 2012 et Windows Server 2012 R2, l’adaptateur Cluster Network Driver (NETFT.SYS) est automatiquement placé en bas de la liste des ordres de liaison.

Vérifier la validation de la communication réseau

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 suffisamment rapidement avant l’expiration du délai d’expiration.

Ce test vérifie que les serveurs testés peuvent communiquer avec une latence acceptable sur tous les réseaux.

Par exemple : Sous Valider la communication réseau, vous pouvez voir les messages suivants pour les problèmes de latence réseau :

Succeeded in pinging network interface node003.contoso.com IP Address 192.168.0.2 from network interface node004.contoso.com IP Address 192.168.0.3 with maximum delay 500 after 1 attempt(s).
Either address 10.0.0.96 is not reachable from 192.168.0.2 or **the ping latency is greater than the maximum allowed 2000 ms** 
This may be expected, since network interfaces node003.contoso.com - Heartbeat Network and node004.contoso.com - Production Network are on different cluster networks
Either address 192.168.0.2 is not reachable from 10.0.0.96 or **the ping latency is greater than the maximum allowed 2000 ms** 
This may be expected, since network interfaces node004.contoso.com - Production Network and node003.contoso.com - Heartbeat Network for MSCS are on different cluster networks

Pour le cluster multisite, vous pouvez augmenter les valeurs de délai d’attente. Pour plus d’informations, consultez Configurer les paramètres de pulsation et DNS dans un cluster de basculement multisite.

Vérifiez auprès du faip tout problème de connectivité WAN.

Vérifiez si vous rencontrez l’un des problèmes suivants.

Paquets réseau perdus entre les nœuds

1. Vérifier la perte de paquets à l’aide des performances

   Si le paquet est perdu sur le câble quelque part entre les nœuds, les pulsations échouent. Nous pouvons facilement déterminer s’il s’agit d’un problème en utilisant Analyseur de performances pour examiner le compteur « Interface réseau\Paquets reçus ignorés ». Une fois que vous avez ajouté ce compteur, examinez les nombres Moyens, Minimum et Maximum et si leur valeur est supérieure à zéro, la mémoire tampon de réception doit être ajustée pour l’adaptateur.

   

   Si vous rencontrez une perte de paquets réseau sur la plateforme de virtualisation VMware, consultez la section « Cluster installé dans la plateforme de virtualisation VMware ».

2. Mettre à niveau les pilotes de carte réseau

   Ce problème peut se produire en raison de pilotes de cartes réseau obsolètes\composants d’intégration (IC)\VmTools ou d’adaptateurs de carte réseau défectueux. Si des paquets réseau sont perdus entre les nœuds sur des ordinateurs physiques, veuillez mettre à jour le pilote de votre carte réseau. 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.

Cluster installé dans la plateforme de virtualisation VMware

Vérifiez les problèmes d’adaptateur VMware dans le cas d’un environnement VMware.

Ce problème peut se produire si les paquets sont supprimés pendant des pics de trafic élevés. Vérifiez qu’aucun filtrage du trafic ne se produit (par exemple, avec un filtre de messagerie). Après avoir éliminé cette possibilité, augmentez progressivement le nombre de mémoires tampons dans le système d’exploitation invité et vérifiez.

Pour réduire les chutes de trafic en rafale, procédez comme suit :

1. Sélectionnez Démarrer, Exécuter, tapez devmgmt.msc et appuyez sur Entrée.
2. Développez Cartes réseau, cliquez avec le bouton droit sur vmxnet3 et sélectionnez Propriétés.
3. Sélectionnez l’onglet Avancé.
4. Sélectionnez Mémoires tampons rx de petite taille et augmentez la valeur. La valeur par défaut est 512 et la valeur maximale est 8192.
5. Sélectionnez Rx Ring #1 Taille et augmentez la valeur. La valeur par défaut est 1024 et la valeur maximale est 4096.

Consultez les articles suivants pour vérifier les problèmes d’adaptateur VMware dans le cas d’un environnement VMware :

• Nœuds supprimés de l’appartenance au cluster de basculement sur VMware ESX ?.
• Perte de paquets importante au niveau du système d’exploitation invité sur la carte réseau virtuelle VMXNET3 dans ESXi

Notez toute congestion réseau

La congestion du réseau peut également entraîner des problèmes de connectivité réseau.

Vérifiez que votre réseau est configuré conformément aux recommandations de MS et du fournisseur, consultez Configuration des réseaux de cluster de basculement Windows.

Vérifier la configuration réseau

Si cela ne fonctionne toujours pas, veuillez case activée si vous avez vu un réseau partitionné dans l’interface graphique graphique du cluster ou si l’association de cartes réseau est activée sur la carte réseau de pulsation.

Si vous voyez un réseau partitionné dans l’interface graphique graphique du cluster, consultez Réseaux de cluster « partitionnés » pour résoudre le problème.

Si l’association de cartes réseau est activée sur la carte réseau de pulsation, case activée fonctionnalité logicielle d’association conformément à la recommandation du fournisseur d’association.

Mettre à niveau les pilotes de carte réseau

Ce problème peut se produire en raison de pilotes de cartes réseau obsolètes ou de cartes réseau défectueuses.

Si des paquets réseau sont perdus entre les nœuds sur des ordinateurs physiques, faites mettre à jour le pilote de votre carte réseau. 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.

Vérifier la configuration réseau

Si cela ne fonctionne toujours pas, case activée si vous avez vu le réseau partitionné dans l’interface graphique graphique du cluster ou si l’association de cartes réseau est activée sur la carte réseau de pulsation.