Freigeben über

Optimieren von Netzwerkschwellenwerten für Failovercluster

  • Artikel

In diesem Artikel werden Lösungen vorgestellt, um die Schwellenwerte der Failoverclusternetzwerkeinstellungen anzupassen. Das Erhöhen der Werte dieser Einstellungen kann dazu beitragen, die Vertraulichkeit des Clusters auf vorübergehende Netzwerkprobleme zu reduzieren.

Symptom

Wenn Sie Windows-Failoverclusterknoten ausführen, wird empfohlen, die Clustereinstellung in einen entspannteren Überwachungszustand zu ändern. Clustereinstellungen, die nicht einsatzbereit sind, sind restriktiv und können zu nicht benötigten Ausfällen führen. Die Standardeinstellungen sind für stark abgestimmte lokale Netzwerke ausgelegt und berücksichtigen nicht die Möglichkeit der induzierten Latenz, die durch eine mehrinstanzenfähige Umgebung wie Microsoft Azure (IaaS) verursacht wird.

Windows Server Failover Clustering überwacht ständig die Netzwerkverbindungen und die Integrität der Knoten in einem Windows-Cluster. Wenn ein Knoten über das Netzwerk nicht erreichbar ist, wird eine Wiederherstellungsaktion ausgeführt, um die Anwendungen und Dienste auf einem anderen Knoten im Cluster wieder online zu schalten. Latenz bei der Kommunikation zwischen Clusterknoten kann zu folgendem Fehler führen:

Fehler 1135 (Systemereignisprotokoll)

ClusterknotenKnoten 1 wurde aus der aktiven Failoverclustermitgliedschaft entfernt. Möglicherweise wurde der Clusterdienst auf diesem Knoten beendet. Dies kann auch daran liegen, dass der Knoten die Kommunikation mit anderen aktiven Knoten im Failovercluster verloren hat. Führen Sie den Assistenten zum Überprüfen einer Konfiguration aus, um Ihre Netzwerkkonfiguration zu überprüfen. Wenn der Zustand weiterhin besteht, suchen Sie nach Hardware- oder Softwarefehlern im Zusammenhang mit den Netzwerkadaptern auf diesem Knoten. Überprüfen Sie auch auf Fehler in allen anderen Netzwerkkomponenten, mit denen der Knoten verbunden ist, z. B. Hubs, Switches oder Brücken.

Cluster.log Beispiel:

0000ab34.00004e64::2014/06/10-07:54:34.099 DBG   [NETFTAPI] Signaled NetftRemoteUnreachable event, local address 10.xx.x.xxx:3343 remote address 10.x.xx.xx:3343
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO  [IM] got event: Remote endpoint 10.xx.xx.xxx:~3343~ unreachable from 10.xx.x.xx:~3343~
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO  [IM] Marking Route from 10.xxx.xxx.xxxx:~3343~ to 10.xxx.xx.xxxx:~3343~ as down
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO  [NDP] Checking to see if all routes for route (virtual) local fexx::xxx:5dxx:xxxx:3xxx:~0~ to remote xxx::cxxx:xxxd:xxx:dxxx:~0~ are down
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO  [NDP] All routes for route (virtual) local fxxx::xxxx:5xxx:xxxx:3xxx:~0~ to remote fexx::xxxx:xxxx:xxxx:xxxx:~0~ are down
0000ab34.00007328::2014/06/10-07:54:34.099 INFO  [CORE] Node 8: executing node 12 failed handlers on a dedicated thread
0000ab34.00007328::2014/06/10-07:54:34.099 INFO  [NODE] Node 8: Cleaning up connections for n12.
0000ab34.00007328::2014/06/10-07:54:34.099 INFO  [Nodename] Clearing 0 unsent and 15 unacknowledged messages.
0000ab34.00007328::2014/06/10-07:54:34.099 INFO  [NODE] Node 8: n12 node object is closing its connections
0000ab34.00008b68::2014/06/10-07:54:34.099 INFO  [DCM] HandleNetftRemoteRouteChange
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO  [IM] Route history 1: Old: 05.936, Message: Response, Route sequence: 150415, Received sequence: 150415, Heartbeats counter/threshold: 5/5, Error: Success, NtStatus: 0 Timestamp: 2014/06/10-07:54:28.000, Ticks since last sending: 4
0000ab34.00007328::2014/06/10-07:54:34.099 INFO  [NODE] Node 8: closing n12 node object channels
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO  [IM] Route history 2: Old: 06.434, Message: Request, Route sequence: 150414, Received sequence: 150402, Heartbeats counter/threshold: 5/5, Error: Success, NtStatus: 0 Timestamp: 2014/06/10-07:54:27.665, Ticks since last sending: 36
0000ab34.0000a8ac::2014/06/10-07:54:34.099 INFO  [DCM] HandleRequest: dcm/netftRouteChange
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO  [IM] Route history 3: Old: 06.934, Message: Response, Route sequence: 150414, Received sequence: 150414, Heartbeats counter/threshold: 5/5, Error: Success, NtStatus: 0 Timestamp: 2014/06/10-07:54:27.165, Ticks since last sending: 4
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO  [IM] Route history 4: Old: 07.434, Message: Request, Route sequence: 150413, Received sequence: 150401, Heartbeats counter/threshold: 5/5, Error: Success, NtStatus: 0 Timestamp: 2014/06/10-07:54:26.664, Ticks since last sending: 36

0000ab34.00007328::2014/06/10-07:54:34.100 INFO    <realLocal>10.xxx.xx.xxx:~3343~</realLocal>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO    <realRemote>10.xxx.xx.xxx:~3343~</realRemote>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO    <virtualLocal>fexx::xxxx:xxxx:xxxx:xxxx:~0~</virtualLocal>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO    <virtualRemote>fexx::xxxx:xxxx:xxxx:xxxx:~0~</virtualRemote>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO    <Delay>1000</Delay>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO    <Threshold>5</Threshold>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO    <Priority>140481</Priority>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO    <Attributes>2147483649</Attributes>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO  </struct mscs::FaultTolerantRoute>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO   removed

0000ab34.0000a7c0::2014/06/10-07:54:38.433 ERR   [QUORUM] Node 8: Lost quorum (3 4 5 6 7 8)
0000ab34.0000a7c0::2014/06/10-07:54:38.433 ERR   [QUORUM] Node 8: goingAway: 0, core.IsServiceShutdown: 0
0000ab34.0000a7c0::2014/06/10-07:54:38.433 ERR   lost quorum (status = 5925)

Ursache

Es gibt zwei Einstellungen, die zum Konfigurieren der Konnektivitätsintegrität des Clusters verwendet werden.

Verzögerung – Dies definiert die Häufigkeit, mit der Clustertakte zwischen Knoten gesendet werden. Die Verzögerung ist die Anzahl der Sekunden vor Senden des nächsten Takts. Innerhalb desselben Clusters können unterschiedliche Verzögerungen zwischen Knoten im selben Subnetz und zwischen Knoten in unterschiedlichen Subnetzen auftreten.

Schwellenwert – Dies definiert die Anzahl der Takte, die verpasst werden, bevor der Cluster Wiederherstellungsaktionen ausführt. Der Schwellenwert ist eine Anzahl von Takten. Innerhalb desselben Clusters können unterschiedliche Schwellenwerte zwischen Knoten im selben Subnetz und zwischen Knoten in unterschiedlichen Subnetzen vorhanden sein.

Standardmäßig legt Windows Server den SameSubnetThreshold auf 10 und SameSubnetDelay auf 1000 ms fest. Wenn die Konnektivitätsüberwachung beispielsweise 10 Sekunden lang fehlschlägt, wird der Failover-Schwellenwert erreicht, was dazu führt, dass der nicht erreichbare Knoten aus der Clustermitgliedschaft entfernt wird. Dies führt dazu, dass die Ressourcen auf einen anderen verfügbaren Knoten im Cluster verschoben werden. Clusterfehler werden gemeldet, einschließlich des Clusterfehlers 1135 (oben).

Lösung

Um dieses Problem zu beheben, lockern Sie die Einstellungen für die Clusternetzwerkkonfiguration. Siehe Takt und Schwellenwert.

References

Weitere Informationen zum Optimieren der Einstellungen für die Windows-Clusternetzwerkkonfiguration finden Sie unter Optimieren von Netzwerkschwellenwerten für Failovercluster.

Informationen zur Verwendung von cluster.exe zum Optimieren der Konfigurationseinstellungen für das Windows Cluster-Netzwerk finden Sie unter Konfigurieren von Clusternetzwerken für einen Failovercluster.