具有 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 () 。

解決方案

若要解決此問題，請放寬叢集網路組態設定。 請參閱 活動訊號和閾值。

參考資料

如需微調 Windows 叢集網路組態設定的詳細資訊，請參閱 調整故障轉移叢集網路閾值。

如需使用 cluster.exe 微調 Windows 叢集網路組態設定的詳細資訊，請參閱 如何設定故障轉移叢集的叢集網路。