IaaS mit SQL Server: Optimieren von Netzwerkschwellenwerten für Failovercluster

In diesem Artikel werden Lösungen zum Anpassen des Schwellenwerts für Failoverclusternetzwerke vorgestellt.

Problembeschreibung

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

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

Fehler 1135 (Systemereignisprotokoll)

Clusterknoten Knoten 1 wurde aus der aktiven Failoverclustermitgliedschaft entfernt. Der Clusterdienst auf diesem Knoten wurde möglicherweise beendet. Dies kann auch daran liegen, dass der Knoten die Kommunikation mit anderen aktiven Knoten im Failovercluster unterbrochen hat. Führen Sie den Konfigurationsüberprüfungs-Assistenten aus, um Ihre Netzwerkkonfiguration zu überprüfen. Wenn die Bedingung 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 : Definiert die Häufigkeit, mit der Clustertakte zwischen Knoten gesendet werden. Die Verzögerung ist die Anzahl von Sekunden, bevor der nächste Heartbeat gesendet wird. Innerhalb desselben Clusters kann es unterschiedliche Verzögerungen zwischen Knoten im selben Subnetz und zwischen Knoten geben, die sich in verschiedenen Subnetzen befinden.

Schwellenwert : Definiert die Anzahl der Heartbeats, die verpasst werden, bevor der Cluster eine Wiederherstellungsaktion 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 2016 SameSubnetThreshold auf 10 und SameSubnetDelay auf 1000 ms fest. Wenn z. B. die Konnektivitätsüberwachung zehn Sekunden lang fehlschlägt, wird der Failoverschwellenwert erreicht, was dazu führt, dass der knoten aus der Clustermitgliedschaft entfernt wird, der nicht erreichbar ist. Dies führt dazu, dass die Ressourcen auf einen anderen verfügbaren Knoten im Cluster verschoben werden. Clusterfehler werden gemeldet, einschließlich clusterfehler 1135 (oben) wird gemeldet.

Lösung

Um dieses Problem zu beheben, lockern Sie die Einstellungen für die Clusternetzwerkkonfiguration. Weitere Informationen finden Sie unter Takt und Schwellenwert.

References

Weitere Informationen zum Optimieren der Netzwerkkonfigurationseinstellungen für Windows-Cluster finden Sie unter Optimieren von Netzwerkschwellenwerten für Failovercluster.

Informationen zur Verwendung voncluster.exe zum Optimieren der Netzwerkkonfigurationseinstellungen von Windows-Clustern finden Sie unter Konfigurieren von Clusternetzwerken für einen Failovercluster.