Behandeln von Clusterproblemen mit ereignis-ID 1135

Dieser Artikel hilft Ihnen bei der Diagnose und Auflösung der Ereignis-ID 1135, die beim Starten des Clusterdiensts in der Failoverclusterumgebung protokolliert werden kann.

Gilt für: Windows Server 2022, Windows Server 2019, Windows Server 2016, Azure Stack HCI, Versionen 21H2 und 20H2

Testen Sie unseren virtuellen Agent : Er kann Ihnen helfen, häufige Probleme bei der Active Directory-Replikation schnell zu identifizieren und zu beheben.

Startseite

Die Ereignis-ID 1135 gibt an, dass mindestens ein Clusterknoten aus der aktiven Failoverclustermitgliedschaft entfernt wurde. Es kann von folgenden Symptomen begleitet werden:

• Clusterfailover\naus der aktiven Failoverclustermitgliedschaft entfernt werden:

  Problem mit Knoten, die aus der aktiven Failoverclustermitgliedschaft entfernt werden

• Ereignis-ID 1069:

  Ereignis-ID 1069– Clusterdienst- oder Anwendungsverfügbarkeit

• Ereignis-ID 1177 für Quorumverlust:

  Ereignis-ID 1177: Quorum und Konnektivität für Quorum erforderlich

• Ereignis-ID 1006 für den Clusterdienst angehalten:

  Ereignis-ID 1006 – Clusterdienststart

Eine Überprüfung und die Netzwerktests werden als einer der ersten Schritte zur Problembehandlung empfohlen, um sicherzustellen, dass keine Konfigurationsprobleme vorliegen, die möglicherweise eine Ursache für Probleme sind.

Überprüfen Sie, ob die empfohlenen Hotfixes installiert sind.

Der Clusterdienst ist die wesentliche Softwarekomponente, die alle Aspekte des Failoverclusterbetriebs steuert und die Clusterkonfigurationsdatenbank verwaltet. Wenn die Ereignis-ID 1135 angezeigt wird, empfehlen wir Ihnen, die in den folgenden Artikeln erwähnten Korrekturen zu installieren und alle Knoten des Clusters neu zu starten. Beobachten Sie dann, wenn das Problem erneut auftritt.

• Empfohlene Hotfixes und Updates für Windows Server 2012 R2-basierte Failovercluster
• Empfohlene Hotfixes und Updates für Windows Server 2012-basierte Failovercluster
• Empfohlene Hotfixes und Updates für Windows Server 2008 R2 SP1-Failovercluster

Überprüfen, ob der Clusterdienst auf allen Knoten ausgeführt wird

Führen Sie den folgenden Befehl gemäß Ihrem Windows-Betriebssystem aus, um zu überprüfen, ob der Clusterdienst kontinuierlich ausgeführt und verfügbar ist.

Für Windows Server 2008 R2-Cluster

Führen Sie cluster.exe node /stat über eine Eingabeaufforderung mit erhöhten Rechten aus.

Für Windows Server 2012 und Windows Server 2012 R2-Cluster

Führen Sie das folgende PowerShell-Cmdlet aus: Get-ClusterResource

Wird der Clusterdienst kontinuierlich ausgeführt und ist auf allen Knoten verfügbar?

Mehrere Szenarien der Ereignis-ID 1135

Wir möchten, dass Sie sich die Systemereignisprotokolle auf allen Knoten Ihres Clusters genauer ansehen. Überprüfen Sie die Ereignis-ID 1135, die auf den Knoten angezeigt wird, und kopieren Sie alle Instanzen dieses Ereignisses. Dadurch können Sie sie sich bequem ansehen und überprüfen.

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.

Es gibt drei typische Szenarien:

Szenario A

Sie sehen sich alle Ereignisse an, und alle Knoten im Cluster deuten darauf hin, dass NODE A die Kommunikation verloren hat.

Es kann sein, dass, wenn die Systemprotokolle auf KNOTEN A angezeigt werden, Ereignisse für alle verbleibenden Knoten im Cluster enthalten sind.

Lösung

Dies deutet darauf hin, dass zum Zeitpunkt des Problems entweder aufgrund einer Netzwerküberlastung oder anderweitig die Kommunikation mit knoten A verloren gegangen ist.

Sie sollten die Netzwerkkonfigurations- und Kommunikationsprobleme überprüfen und überprüfen. Denken Sie daran, nach Problemen im Zusammenhang mit Knoten A zu suchen.

Szenario B

Sie betrachten die Ereignisse auf den Knoten und lassen Sie uns sagen, dass Ihr Cluster auf zwei Standorte verteilt ist. KNOTEN A, KNOTEN B und KNOTEN C am Standort 1 und NODE D & KNOTEN E an Standort 2.

Auf den Knoten A, B und C sehen Sie, dass die protokollierten Ereignisse für die Konnektivität mit Knoten D & E dienen. Wenn Sie die Ereignisse auf knoten D & E sehen, deuten die Ereignisse darauf hin, dass die Kommunikation mit A, B und C verloren gegangen ist.

Lösung

Wenn Sie eine ähnliche Aktivität sehen, ist dies ein Hinweis darauf, dass über den Link, der diese Websites verbindet, ein Kommunikationsfehler aufgetreten ist. Es wird empfohlen, die Verbindung standortübergreifend zu überprüfen. Wenn dies über eine WAN-Verbindung erfolgt, empfehlen wir Ihnen, die Konnektivität mit Ihrem ISP zu überprüfen.

Szenario C

Sie sehen sich die Ereignisse auf den Knoten an und stellen fest, dass die Namen der Knoten keinem bestimmten Muster entsprechen. Lassen Sie uns sagen, dass Ihr Cluster auf zwei Standorte verteilt ist. KNOTEN A, KNOTEN B und KNOTEN C am Standort 1 und NODE D & KNOTEN E an Standort 2.

• Auf Knoten A: Ereignisse für die Knoten B, D, E werden angezeigt.
• Auf Knoten B: Es werden Ereignisse für die Knoten C, D, E angezeigt.
• Auf Knoten C: Es werden Ereignisse für die Knoten A, B, E angezeigt.
• Auf Knoten D: Es werden Ereignisse für die Knoten A, C, E angezeigt.
• Auf Knoten E: Ereignisse für die Knoten B, C, D werden angezeigt.
• Oder andere Kombinationen.

Lösung

Solche Ereignisse sind möglich, wenn die Netzwerkkanäle zwischen den Knoten erstickt sind und die Clusterkommunikationsnachrichten nicht rechtzeitig erreicht werden, sodass der Cluster das Gefühl hat, dass die Kommunikation zwischen den Knoten verloren geht, was dazu führt, dass Knoten aus der Clustermitgliedschaft entfernt werden.

Überprüfen von Clusternetzwerken

Wir empfehlen Ihnen, Ihre Clusternetzwerke zu überprüfen, indem Sie die folgenden drei Optionen einzeln überprüfen, um diesen Leitfaden zur Problembehandlung fortzusetzen.

Auf Antivirusausschluss überprüfen

Schließen Sie die folgenden Dateisystemspeicherorte von der Virenüberprüfung auf einem Server aus, auf dem Clusterdienste ausgeführt werden:

• Der Pfad des FileShare-Zeugen
• Der Ordner %Systemroot%\Cluster

Konfigurieren Sie die Echtzeitüberprüfungskomponente in Ihrer Antivirensoftware, um die folgenden Verzeichnisse und Dateien auszuschließen:

• Standardkonfigurationsverzeichnis für virtuelle Computer (C:\ProgramData\Microsoft\Windows\Hyper-V)

• Konfigurationsverzeichnisse für benutzerdefinierte virtuelle Computer

• Standardverzeichnis für virtuelle Festplattenlaufwerke (C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks)

• Verzeichnisse für benutzerdefinierte virtuelle Festplattenlaufwerke

• Benutzerdefinierte Replikationsdatenverzeichnisse bei Verwendung des Hyper-V-Replikats

• Momentaufnahmeverzeichnisse

• mms.exe

  Hinweis

  Diese Datei muss möglicherweise als Prozessausschluss innerhalb der Antivirensoftware konfiguriert werden.

• Vmwp.exe

  Hinweis

  Diese Datei muss möglicherweise als Prozessausschluss innerhalb der Antivirensoftware konfiguriert werden.

Wenn Sie die Livemigration zusammen mit freigegebenen Clustervolumes verwenden, schließen Sie außerdem den CSV-Pfad C:\Clusterstorage und alle zugehörigen Unterverzeichnisse aus. Wenn Sie Failoverprobleme oder allgemeine Probleme mit Clusterdiensten behandeln und Antivirensoftware installiert ist, deinstallieren Sie die Antivirensoftware vorübergehend, oder wenden Sie sich an den Hersteller der Software, um zu ermitteln, ob die Antivirensoftware mit Clusterdiensten funktioniert. Das Deaktivieren der Antivirensoftware reicht in den meisten Fällen nicht aus. Auch wenn Sie die Antivirensoftware deaktivieren, wird der Filtertreiber weiterhin geladen, wenn Sie den Computer neu starten.

Überprüfen der Netzwerkportkonfiguration in der Firewall

Der Clusterdienst steuert Serverclusterfunktionen und verwaltet die Clusterdatenbank. Ein Cluster ist eine Gruppe unabhängiger Computer, die wie ein einzelner Computer agieren. Manager, Programmierer und Benutzer sehen den Cluster als ein einzelnes System. Die Software verteilt Daten zwischen den Knoten des Clusters. Wenn ein Knoten ausfällt, liefern andere Knoten die Dienste und Daten, die zuvor von dem ausgefallenen Knoten bereitgestellt wurden. Wenn ein Knoten hinzugefügt oder repariert wurde, migriert die Clustersoftware einige Daten auf diesen Knoten.

Name des Systemdiensts: ClusSvc

Anwendung	Protokoll	Ports
Clusterdienst	UDP	3343
Clusterdienst	TCP	3343 (dieser Port ist während eines Knotenverknüpfungsvorgangs erforderlich.)
RPC	TCP	135
Cluster Admin	UDP	137
Kerberos	UDP/TCP	464*
SMB	TCP	445
Zufällig zugeordnete hohe UDP-Ports**	UDP	beliebige Portnummer zwischen 1024 und 65535 Zufällige Portnummer zwischen 49152 und 65535***

Hinweis

Für eine erfolgreiche Überprüfung auf Windows-Failoverclustern unter Windows Server 2008 und höher können Sie außerdem eingehenden und ausgehenden Datenverkehr für ICMP4 und ICMP6 zulassen.

• Weitere Informationen finden Sie unter Erstellen eines Windows Server 2012 Failoverclusters schlägt mit Fehler 0xc000005e fehl.
• Weitere Informationen zum Anpassen dieser Ports finden Sie im Abschnitt "Verweise" unter Dienstübersicht und Netzwerkportanforderungen für Windows.

Dies ist der Bereich in Windows Server 2012, Windows 8, Windows Server 2008 R2, Windows 7, Windows Server 2008 und Windows Vista.

Führen Sie außerdem den folgenden Befehl aus, um die Konfiguration des Netzwerkports in der Firewall zu überprüfen. Beispiel: Mit diesem Befehl können Sie den für den Failovercluster verwendeten Port 3343 available\open ermitteln:

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

Ausführen des Clustersvalidierungsberichts für Fehler oder Warnungen

Das Clustervalidierungstool führt eine Reihe von Tests aus, um zu überprüfen, ob Ihre Hardware und Einstellungen mit dem Failoverclustering kompatibel sind.

Befolgen Sie diese Anweisungen:

1. Führen Sie den Clustervalidierungsbericht für Fehler oder Warnungen aus. Weitere Informationen finden Sie unter Grundlegendes zu Clustervalidierungstests: Netzwerk

   

2. Überprüfen Sie, ob Warnungen und Fehler für Netzwerke vorliegen. Weitere Informationen finden Sie unter Grundlegendes zu Clustervalidierungstests: Netzwerk.

   

   

Überprüfen der Listen-Netzwerkbindungsreihenfolge

Dieser Test listet die Reihenfolge auf, in der Netzwerke an die Adapter auf jedem Knoten gebunden sind.

Auf der Registerkarte Adapter und Bindungen werden die Verbindungen in der Reihenfolge aufgelistet, in der von Netzwerkdiensten auf die Verbindungen zugegriffen wird. Die Reihenfolge dieser Verbindungen gibt die Reihenfolge an, in der generische TCP/IP-Aufrufe/Pakete an die Leitung gesendet werden.

Führen Sie die folgenden Schritte aus, um die Bindungsreihenfolge von Netzwerkadaptern zu ändern:

1. Wählen Sie Start aus, wählen Sie Ausführen aus, geben Siencpa.cplein, und wählen Sie dann OK aus. Die verfügbaren Verbindungen werden im Abschnitt LAN und High-Speed Internet des Fensters Netzwerk Connections angezeigt.
2. Wählen Sie im Menü Erweitert die Option Erweiterte Einstellungen und dann die Registerkarte Adapter und Bindungen aus.
3. Wählen Sie im Bereich Connections die Verbindung aus, die Sie in der Liste nach oben verschieben möchten. Verwenden Sie die Pfeilschaltflächen, um die Verbindung zu verschieben. In der Regel sollte der Karte, der mit dem Netzwerk kommuniziert (Domänenkonnektivität, Routing zu anderen Netzwerken usw.), der erste gebundene (oben in der Liste) Karte).

Clusterknoten sind Multi-Homed-Systeme. Die Netzwerkpriorität wirkt sich auf den DNS-Client für ausgehende Netzwerkkonnektivität aus. Netzwerkadapter, die für die Clientkommunikation verwendet werden, sollten sich ganz oben in der Bindungsreihenfolge befinden. Nicht geroutete Netzwerke können mit niedrigerer Priorität platziert werden. In Windows Server 2012 und Windows Server 2012 R2 wird der Adapter cluster network driver (NETFT.SYS) automatisch am Ende der Bindungsreihenfolgeliste platziert.

Überprüfen sie die Überprüfung der Netzwerkkommunikation.

Dies kann auch durch die Latenz in Ihrem Netzwerk verursacht werden. Die Pakete gehen möglicherweise nicht zwischen den Knoten verloren, aber sie gelangen möglicherweise nicht schnell genug zu den Knoten, bevor der Timeoutzeitraum abläuft.

Dieser Test überprüft, ob getestete Server in allen Netzwerken mit akzeptabler Latenz kommunizieren können.

Beispiel: Unter Netzwerkkommunikation überprüfen werden möglicherweise die folgenden Meldungen für Probleme mit der Netzwerklatenz angezeigt:

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

Bei Clustern mit mehreren Standorten können Sie die Timeoutwerte erhöhen. Weitere Informationen finden Sie unter Konfigurieren von Heartbeat- und DNS-Einstellungen in einem Multi-Site-Failovercluster.

Wenden Sie sich an den ISP auf WAN-Konnektivitätsprobleme.

Überprüfen Sie, ob eines der folgenden Probleme auftritt.

Netzwerkpakete, die zwischen Knoten verloren gegangen sind

1. Überprüfen des Paketverlusts mithilfe der Leistung

   Wenn das Paket auf der Verbindung zwischen den Knoten verloren geht, schlagen die Heartbeats fehl. Wir können leicht herausfinden, ob dies ein Problem ist, indem wir Leistungsmonitor verwenden, um den Zähler "Netzwerkschnittstelle\Empfangene Pakete verworfen" zu betrachten. Nachdem Sie diesen Zähler hinzugefügt haben, sehen Sie sich die Zahlen Average, Minimum und Maximum an. Wenn es sich um einen Wert über 0 (null) handelt, muss der Empfangspuffer für den Adapter angepasst werden.

   

   Wenn auf der VMware-Virtualisierungsplattform Netzwerkpakete verloren gehen, lesen Sie den Abschnitt "Cluster auf der VMware-Virtualisierungsplattform installiert".

2. Aktualisieren der NIC-Treiber

   Dieses Problem kann aufgrund veralteter NIC-Treiber\Integrationskomponenten (IC)\VmTools oder fehlerhafter NIC-Adapter auftreten. Wenn Netzwerkpakete zwischen Knoten auf physischen Computern verloren gehen, lassen Sie den Netzwerkadaptertreiber aktualisieren. Alte oder veraltete Netzwerk-Karte Treiber und/oder Firmware. Manchmal kann auch eine einfache Fehlkonfiguration des Netzwerk-Karte oder Switchs zu Einem Verlust von Takten führen.

Auf der VMware-Virtualisierungsplattform installierte Cluster

Überprüfen Sie VMware-Adapterprobleme im Fall einer VMware-Umgebung.

Dieses Problem kann auftreten, wenn die Pakete während hoher Datenverkehrsspitzen verworfen werden. Stellen Sie sicher, dass keine Datenverkehrsfilterung erfolgt (z. B. mit einem E-Mail-Filter). Nachdem Sie diese Möglichkeit beseitigt haben, erhöhen Sie schrittweise die Anzahl der Puffer im Gastbetriebssystem, und überprüfen Sie.

Führen Sie die folgenden Schritte aus, um die Anzahl von Burstdatenverkehr zu reduzieren:

1. Wählen Sie Start aus, wählen Sie Ausführen aus, geben Sie ein devmgmt.msc , und drücken Sie die EINGABETASTE.
2. Erweitern Sie Netzwerkadapter, klicken Sie mit der rechten Maustaste auf vmxnet3 , und wählen Sie Eigenschaften aus.
3. Wählen Sie die Registerkarte Erweitert aus.
4. Wählen Sie Kleine Rx-Puffer aus , und erhöhen Sie den Wert. Der Standardwert ist 512 und der Höchstwert 8192.
5. Wählen Sie Rx Ring #1 Größe aus, und erhöhen Sie den Wert. Der Standardwert ist 1024 und der Höchstwert 4096.

Lesen Sie die folgenden Artikel, um probleme mit dem VMware-Adapter im Fall einer VMware-Umgebung zu überprüfen:

• Knoten, die aus der Failoverclustermitgliedschaft in VMware ESX entfernt werden?
• Großer Paketverlust auf Der Ebene des Gastbetriebssystems auf der VMXNET3 vNIC in ESXi

Beachten Sie eine Netzwerküberlastung

Eine Netzwerküberlastung kann auch zu Netzwerkkonnektivitätsproblemen führen.

Überprüfen Sie, ob Ihr Netzwerk gemäß den Empfehlungen von MS und Anbietern konfiguriert ist. Weitere Informationen finden Sie unter Konfigurieren von Windows-Failoverclusternetzwerken.

Überprüfen der Netzwerkkonfiguration

Wenn dies immer noch nicht funktioniert, überprüfen Sie, ob sie ein partitioniertes Netzwerk in der Cluster-GUI gesehen haben oder ob das NIC-Teaming für die Heartbeat-NIC aktiviert ist.

Wenn partitioniertes Netzwerk in der Cluster-GUI angezeigt wird, lesen Sie "Partitionierte" Clusternetzwerke , um das Problem zu beheben.

Wenn Sie NIC-Teaming für die Heartbeat-NIC aktiviert haben, überprüfen Sie die Teaming-Softwarefunktionalität gemäß der Empfehlung des Teaminganbieters.

Aktualisieren der NIC-Treiber

Dieses Problem kann aufgrund veralteter NIC-Treiber oder fehlerhafter NIC-Adapter auftreten.

Wenn Netzwerkpakete zwischen Knoten auf physischen Computern verloren gehen, lassen Sie den Netzwerkadaptertreiber aktualisieren. Alte oder veraltete Netzwerk-Karte Treiber und/oder Firmware.

Manchmal kann auch eine einfache Fehlkonfiguration des Netzwerk-Karte oder Switchs zu Einem Verlust von Takten führen.

Überprüfen der Netzwerkkonfiguration

Wenn dies immer noch nicht funktioniert, überprüfen Sie, ob sie ein partitioniertes Netzwerk in der Cluster-GUI gesehen haben oder ob das NIC-Teaming für die Heartbeat-NIC aktiviert ist.