Partager via


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 consigné lors du démarrage du service de cluster dans un 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 liés à la 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. Il peut s’accompagner des symptômes suivants :

Une validation et des tests du réseau sont recommandés pour commencer la résolution des problèmes afin de s’assurer qu’il n’existe aucun problème de configuration pouvant être à l’origine de problèmes.

Le service de cluster est le composant logiciel principal permettant de contrôler l’ensemble des aspects du fonctionnement du cluster de basculement et de gérer 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 d’observer si le problème se produit.

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

Suivez la commande suivante selon 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

À partir d’une invite de commandes avec élévation de privilèges, exécutez cluster.exe node /stat.

Pour les clusters Windows Server 2012 et Windows Server 2012 R2

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

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

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

Vous devez examiner 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. Vous pouvez ainsi les examiner et les évaluer facilement.

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 NODE A avait perdu la communication.

Diagramme montrant la communication réussie du nœud A, du nœud B et du nœud C.

Diagramme montrant que le nœud A a perdu la communication avec le nœud B et le nœud C.

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

Solution

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

Vous devez passer en revue 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 supposons que votre cluster est dispersé sur deux sites. NODE A, NODE B et NODE C sur le site 1 et NODE D &NODE E sur le site 2.

Diagramme montrant que la communication réussie du site 1 avec le site 2 via une liaison WAN.

Sur les nœuds A, B et C, vous voyez que les événements enregistrés sont destinés à 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.

Diagramme montrant que le site 1 a perdu la connexion de liaison WAN avec le site 2.

Solution

Si vous constatez une activité similaire, cela indique un échec de communication via la liaison 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 conseillons de vérifier la connectivité auprès de votre fournisseur de services Internet.

Scénario C

Vous examinez les événements sur les nœuds et vous voyez que les noms des nœuds n’ont pas de modèle particulier. Imaginons que votre cluster s’étend sur deux sites. NODE A, NODE B et NODE C sur le site 1 et NODE D &NODE E sur le site 2.

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

Diagramme du scénario C montrant que votre cluster est dispersé sur deux sites.

Solution

Ces événements sont possibles en cas de goulots d’étranglement sur les canaux réseau entre les nœuds et quand les messages de communication du cluster n’arrivent pas en temps voulu. Ainsi, 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 en cluster

Nous vous recommandons de passer en revue vos réseaux en cluster en vérifiant les trois options suivantes une par une afin de poursuivre ce guide de résolution des problèmes.

Vérification de 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 les fichiers suivants :

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

  • Répertoires de configuration de la machine virtuelles personnalisés

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

  • Répertoires de disques durs virtuels personnalisés

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

  • Répertoires d’instantanés

  • mms.exe

    Notes

    Il est possible que ce fichier doive être configuré en tant qu’exclusion du processus dans le logiciel antivirus.

  • Vmwp.exe

    Notes

    Il est possible que ce fichier doive être configuré en tant qu’exclusion du processus dans le logiciel antivirus.

En outre, quand 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 avec les services de cluster et les logiciels antivirus sont installés, désinstallez temporairement le logiciel antivirus ou vérifiez auprès du fabricant du logiciel pour déterminer si le logiciel antivirus fonctionne avec les services de cluster. Dans la plupart des cas, il ne suffit pas de désactiver le logiciel antivirus. Même si vous désactivez le logiciel antivirus, le pilote de filtre est toujours chargé quand vous redémarrez l’ordinateur.

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

Le service de cluster contrôle les opérations de cluster de serveurs et gère la base de données du cluster. Un cluster est une collection d’ordinateurs indépendants qui agissent comme un ordinateur unique. Les responsables, les programmeurs et les utilisateurs voient le cluster comme un système unique. Le logiciel distribue les données aux différents nœuds du cluster. En cas d’échec d’un nœud, les autres nœuds fournissent les services et les données qui étaient précédemment fournies par le nœud manquant. Quand un nœud est ajouté ou réparé, le logiciel du cluster migre certaines données vers ce nœud.

Nom du service système : ClusSvc

Application Protocol Ports
Service de cluster UDP 3343
Service de cluster TCP 3343 (ce port est nécessaire lors d’une opération de jointure de nœud.)
RPC TCP 135
Administration du 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 compris entre 1024 et 65535
Numéro de port aléatoire compris entre 49152 et 65535***

Notes

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.

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 rechercher la configuration du port réseau dans le pare-feu. Par exemple, cette commande permet de déterminer le port 3343 disponible\ouvert 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 toute erreur ou avertissement

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

Suivez ces instructions :

  1. Exécutez le rapport de validation du cluster en vue de détecter toute erreur ou tout avertissement. Pour plus d’informations, consultez Présentation des tests de validation des clusters : réseau

    Capture d’écran des résultats après l’exécution du rapport validation du cluster pour les erreurs ou avertissements.

  2. Vérifiez s’il existe des avertissements et des erreurs pour les réseaux. Pour plus d’informations, consultez Présentation des tests de validation des clusters : réseau.

    Capture d’écran des résultats par catégorie.

    Capture d’écran de la validation de la configuration du pare-feu Windows sous Réseau.

Consulter la liste de l’ordre de liaison réseau

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

L’onglet Adaptateurs et liaisons répertorie les connexions dans l’ordre dans lequel les connexions sont accessibles par les services réseau. L’ordre de ces connexions reflète l’ordre dans lequel les appels/paquets TCP/IP génériques sont envoyés sur le réseau.

Pour modifier l’ordre de liaison des cartes réseau, procédez comme suit :

  1. Sélectionnez Démarrer, sélectionnez Exécuter, tapez ncpa.cpl, puis sélectionnez OK. Les connexions disponibles sont affichées dans la section Réseau local et Internet haut débit de la fenêtre Connexions 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 Connexions, sélectionnez la connexion que vous souhaitez faire monter dans la liste. Utilisez les flèches pour déplacer la connexion. En règle générale, la carte qui communique avec le réseau (connectivité de domaine, routage vers d’autres réseaux, etc. doit être la première carte liée (en haut de la liste).

Les nœuds de cluster sont des systèmes multirésidents. 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 se trouver en haut sur la liste de l’ordre de liaison. Les réseaux non routés peuvent être placés à un niveau de priorité inférieur. Dans Windows Server 2012 et Windows Server 2012 R2, l’adaptateur de pilote réseau de cluster (NETFT.SYS) est automatiquement placé en bas dans la liste des commandes de liaison.

Vérifier Valider la communication réseau

La latence sur votre réseau peut également être à l’origine de ce problème. Il est possible que les paquets ne soient pas perdus entre les nœuds, mais qu’ils n’atteignent pas assez rapidement les nœuds avant l’expiration du délai.

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, les messages suivants peuvent s’afficher concernant des 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’expiration. Pour plus d’informations, consultez Configurer les paramètres de pulsation et DNS dans un cluster de basculement multisite.

Vérifiez auprès du fournisseur de services Internet s’il existe des problèmes de connectivité WAN.

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

Perte de paquets réseau entre les nœuds
  1. Vérifier si des paquets sont perdus à l’aide des performances

    Si le paquet est perdu sur le réseau entre des nœuds, les pulsations échouent. Nous pouvons facilement déterminer s’il s’agit du problème à l’aide de l’Analyseur de performances en examinant le compteur « Interface réseau\Paquets reçus ignorés ». Une fois que vous avez ajouté ce compteur, examinez les nombres Moyen, Minimum et Maximum. Si l’une des valeurs est supérieure à zéro, la mémoire tampon de réception doit être ajustée à la hausse pour l’adaptateur.

    Capture d’écran de la fenêtre Ajouter des compteurs.

    Si vous rencontrez des paquets réseau perdus 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 être dû à des pilotes de carte réseau\Composants d’intégration (IC)\VmTools obsolètes ou à des cartes réseau défectueuses. Si des paquets réseau sont perdus entre les nœuds sur des machines physiques, effectuez des mises à jour de votre pilote de carte réseau. 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.

Cluster installé sur la plateforme de virtualisation VMware

Vérifiez les problèmes de carte VMware s’il s’agit d’un environnement VMware.

Ce problème peut survenir si les paquets sont supprimés lors de pics de trafic élevés en rafale. Assurez-vous que le trafic n’est pas filtré (par exemple via 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 effectuez une vérification.

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

  1. Sélectionnez Démarrer, sélectionnez Exécuter, tapez devmgmt.msc et appuyez sur Entrée.
  2. Développez les 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 Petites mémoires tampons Rx et augmentez la valeur. La valeur par défaut est 512 et la valeur maximum est 8192.
  5. Sélectionnez Rx Ring #1 Taille et augmentez la valeur. La valeur par défaut est 1024 et la valeur maximum est 4096.

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

Notez toute congestion du 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 Microsoft et du fournisseur. Consultez Configuration des réseaux en cluster de basculement Windows.

Vérifier la configuration réseau

S’il ne fonctionne toujours pas, vérifiez si vous avez vu le réseau partitionné dans l’interface graphique utilisateur du cluster ou si l’association de cartes réseau est activée sur la carte réseau de pulsations.

Si un réseau partitionné est visible dans l’interface 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, vérifiez la fonctionnalité logicielle d’association conformément à la recommandation du fournisseur d’association.

Mettre à niveau les pilotes de carte réseau

Ce problème peut être dû à des pilotes de carte réseau obsolètes ou à des cartes réseau défectueuses.

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

Vérifier la configuration réseau

S’il ne fonctionne toujours pas, vérifiez si vous avez vu le réseau partitionné dans l’interface graphique utilisateur du cluster ou si l’association de cartes réseau est activée sur la carte réseau de pulsations.