IaaS mit SQL Server – Optimieren der Netzwerkschwellenwerte für Failovercluster

In diesem Artikel werden Lösungen zum Anpassen des Schwellenwerts von Failoverclusternetzwerken beschrieben.

Symptom

Beim Ausführen Windows Failoverclusterknoten in IaaS mit einer SQL Server Always On-Verfügbarkeitsgruppe wird empfohlen, die Clustereinstellung in einen gelockerteren Überwachungszustand zu ändern. Die Clustereinstellungen sind bereits restriktiv und können zu nicht mehr häufigen Ausausfällen führen. Die Standardeinstellungen sind für stark optimierten lokalen Netzwerken konzipiert und berücksichtigen nicht die Möglichkeit einer durch eine mehr mandantenübergreifende Umgebung wie Windows Azure (IaaS) verursachten Latenz.

Windows Serverfailoverclustering ü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)

Der Clusterknoten Node1 wurde aus der aktiven Failoverclustermitgliedschaft entfernt. Die Clusterdienst auf diesem Knoten wurde möglicherweise beendet. Dies kann auch daran liegt, dass der Knoten die Kommunikation mit anderen aktiven Knoten im Failovercluster verloren hat. Führen Sie den Konfigurationsüberprüfungs-Assistenten aus, um Ihre Netzwerkkonfiguration zu überprüfen. Wenn die Bedingung weiterhin besteht, überprüfen Sie, ob Hardware- oder Softwarefehler im Zusammenhang mit den Netzwerkadaptern auf diesem Knoten auftreten. Ü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 verwendet werden, um die Konnektivitätszustand des Clusters zu konfigurieren.

Verzögerung : 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 kann es zu unterschiedlichen Verzögerungen zwischen Knoten im gleichen Subnetz und zwischen Knoten kommen, die sich in unterschiedlichen Subnetzen befinden.

Schwellenwert : Definiert die Anzahl der Heartbeats, die verpasst werden, bevor der Cluster Eine Wiederherstellungsaktion ausführen kann. Der Schwellenwert ist eine Reihe von Heartbeats. Innerhalb desselben Clusters kann es unterschiedliche Schwellenwerte zwischen Knoten im gleichen Subnetz und zwischen Knoten geben, die sich in unterschiedlichen Subnetzen befinden.

Standardmäßig wird Windows Server 2016 SameSubnetThreshold auf 10 und SameSubnetDelay auf 1000 ms festgelegt. Wenn beispielsweise die Konnektivitätsüberwachung 10 Sekunden lang fehlschlägt, wird der Failoverschwellenwert erreicht, was dazu führt, dass der Knoten nicht 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. Weitere Informationen finden Sie unter Heartbeat and threshold (Heartbeat und Schwellenwert).

Referenzen

Weitere Informationen zum Optimieren Windows Netzwerkkonfigurationseinstellungen für Cluster finden Sie unter Tuning Failover Cluster Network Thresholds.

Informationen zur Verwendung von cluster.exe zum Optimieren Windows Clusternetzwerkkonfigurationseinstellungen finden Sie unter Konfigurieren von Clusternetzwerken für einen Failovercluster.