具有SQL Server的 IaaS - 优化故障转移群集网络阈值

本文介绍用于调整故障转移群集网络的阈值的解决方案。

症状

使用SQL Server Always On可用性组在 IaaS 中运行 Windows 故障转移群集节点时，建议将群集设置更改为更宽松的监视状态。 现用的群集设置是限制性的，可能会导致不必要的中断。 默认设置专为高度优化的本地网络而设计，不会考虑多租户环境（如 Microsoft Azure (IaaS) ）引起的诱发延迟的可能性。

Windows Server 故障转移群集不断监视 Windows 群集中节点的网络连接和运行状况。 如果无法通过网络访问某个节点，则执行恢复操作以恢复群集中的另一个节点上的应用程序和服务并使其联机。 群集节点之间的通信延迟可能会导致以下错误：

错误 1135 (系统事件日志)

群集节点节点 1 已从活动故障转移群集成员身份中删除。 此节点上的群集服务可能已停止。 这也可能是由于节点与故障转移群集中的其他活动节点失去了通信。 运行“验证配置”向导以检查网络配置。 如果条件仍然存在，检查与此节点上的网络适配器相关的硬件或软件错误。 此外，检查节点所连接到的任何其他网络组件（例如中心、交换机或网桥）中的故障。

Cluster.log 示例：

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)

原因

有两个设置用于配置群集的连接运行状况。

延迟 - 定义在节点之间发送群集检测信号的频率。 延迟是发送下一个检测信号之前的秒数。 在同一群集中，同一子网上的节点之间和不同子网上的节点之间可能存在不同的延迟。

阈值 - 定义在群集执行恢复操作之前错过的检测信号数。 阈值是一些检测信号。 在同一群集中，同一子网上的节点之间和位于不同子网上的节点之间的阈值可能不同。

默认情况下，Windows Server 2016将 SameSubnetThreshold 设置为 10，将 SameSubnetDelay 设置为 1000 毫秒。 例如，如果连接监视在 10 秒内失败，则达到故障转移阈值，导致无法从群集成员身份中删除该节点。 这会导致资源移动到群集上的另一个可用节点。 将报告群集错误，包括报告群集错误 1135 (高于) 。

解决方案

若要解决此问题，请放宽群集网络配置设置。 请参阅 检测信号和阈值。

References

有关优化 Windows 群集网络配置设置的详细信息，请参阅 优化故障转移群集网络阈值。

有关使用 cluster.exe 优化 Windows 群集网络配置设置的信息，请参阅 如何为故障转移群集配置群集网络。