具有 SQL Server 的 IaaS - 微調故障轉移叢集網路閾值

本文介紹調整故障轉移叢集網路閾值的解決方案。

徵兆

當您使用 SQL Server Always On 可用性群組在 IaaS 中執行 Windows 故障轉移叢集節點時，建議將叢集設定變更為較寬鬆的監視狀態。 現用的叢集設定具有限制性，而且可能會導致不必要的中斷。 默認設定是針對高度微調的內部部署網路所設計，且不會考慮多租用戶環境（例如 azure Microsoft#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 會將 SameSubnetThreshold 設為 10， 並將 SameSubnetDelay 設定為 1000 毫秒。 例如，如果連線監視失敗 10 秒，就會達到故障轉移閾值，導致無法連線到該節點從叢集成員資格中移除。 這會導致資源移至叢集上的另一個可用節點。 將回報叢集錯誤，包括回報叢集錯誤 1135 （以上） 。

解決方法

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

參考資料

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

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