WSFC 群集中的 Windows Server 2016 來賓因丟棄心跳路由而被隨機隔離

有 2 個由 Hyper-V Server 2016 託管的來賓 Windows Server 2016 作業系統。來賓作業系統集群非常不可靠，其中一個節點不斷被隔離（每天多次）。

我也有 Windows Server 2012R2 集群。它們由相同的 Hyper-V 主機託管，沒有任何問題。這意味著我在 2012R2 和 2016 之間擁有相同的網路和 hyper-v 基礎架構。

2016 主機的進一步配置：

1. 在網路連接中，未選中所有適配器的 TCP/IPv6。我知道這實際上並沒有禁用集群的 IPv6，因為它使用 NetFT 的隱藏網路適配器，並將 IPv6 封裝在 IPv4 中以用於心跳。我在良好的 2012R2 主機上具有相同的配置。
2. 儘管 2012R2 集群在沒有 Witness 的情況下可以正常工作，但我最初配置 2016 時也是如此。為了解決這些問題，我將文件共享見證添加到 2016 集群 - 沒有變化。
3. 網路驗證報告成功完成

我知道會發生什麼，但不知道為什麼。什麼：_

1. 集群通過埠 3343 上兩個節點之間的多個介面使用心跳 UDP 數據包播放乒乓球。數據包大約發送。每一秒。
2. 突然 1 個節點停止打乒乓球並且沒有響應。一個節點仍然嘗試傳遞心跳。
3. 好吧，我閱讀集群日誌文件發現節點刪除了路由資訊知識：

000026d0.000028b0::2019/06/20-10:58:06.832 ERR   [CHANNEL fe80::7902:e234:93bd:db76%6:~3343~]/recv: Failed to retrieve the results of overlapped I/O: 10060
000026d0.000028b0::2019/06/20-10:58:06.909 ERR   [NODE] Node 1: Connection to Node 2 is broken. Reason (10060)' because of 'channel to remote endpoint fe80::7902:e234:93bd:db76%6:~3343~ has failed with status 10060'
...
000026d0.000028b0::2019/06/20-10:58:06.909 WARN  [NODE] Node 1: Initiating reconnect with n2.
000026d0.000028b0::2019/06/20-10:58:06.909 INFO  [MQ-...SQL2] Pausing
000026d0.000028b0::2019/06/20-10:58:06.910 INFO  [Reconnector-...SQL2] Reconnector from epoch 1 to epoch 2 waited 00.000 so far.
000026d0.00000900::2019/06/20-10:58:08.910 INFO  [Reconnector-...SQL2] Reconnector from epoch 1 to epoch 2 waited 02.000 so far.
000026d0.00002210::2019/06/20-10:58:10.910 INFO  [Reconnector-...SQL2] Reconnector from epoch 1 to epoch 2 waited 04.000 so far.
000026d0.00002fc0::2019/06/20-10:58:12.910 INFO  [Reconnector-...SQL2] Reconnector from epoch 1 to epoch 2 waited 06.000 so far.
...
000026d0.00001c54::2019/06/20-10:59:06.911 INFO  [Reconnector-...SQL2] Reconnector from epoch 1 to epoch 2 waited 1:00.000 so far.
000026d0.00001c54::2019/06/20-10:59:06.911 WARN  [Reconnector-...SQL2] Timed out, issuing failure report.
...
000026d0.00001aa4::2019/06/20-10:59:06.939 INFO  [RouteDb] Cleaning all routes for route (virtual) local fe80::e087:77ce:57b4:e56c:~0~ to remote fe80::7902:e234:93bd:db76:~0~
000026d0.00001aa4::2019/06/20-10:59:06.939 INFO    <realLocal>10.250.2.10:~3343~</realLocal>
000026d0.00001aa4::2019/06/20-10:59:06.939 INFO    <realRemote>10.250.2.11:~3343~</realRemote>
000026d0.00001aa4::2019/06/20-10:59:06.939 INFO    <virtualLocal>fe80::e087:77ce:57b4:e56c:~0~</virtualLocal>
000026d0.00001aa4::2019/06/20-10:59:06.939 INFO    <virtualRemote>fe80::7902:e234:93bd:db76:~0~</virtualRemote>

現在是 WHY 部分……為什麼要這樣做？我不知道。請注意，它會提前一分鐘抱怨：Failed to retrieve the results of overlapped I/O. 但我仍然可以看到正在發送/接收的 UDP 數據包

直到路線在 10:59:06 被刪除並且只有 1 個節點 ping，但沒有 pong。正如在wireshark 中看到的，源列中沒有IP 10.0.0.19 和10.250.2.10。

大約 35 秒後重新添加路由，但這無濟於事 - 節點已被隔離 3 小時。

我在這裡想念什麼？

我剛剛在 Windows Server 2019 故障轉移群集（適用於 Hyper-V 2019）上遇到了同樣的問題。我通常也會在我的伺服器上禁用 IPv6，這會導致問題。集群拋出了很多嚴重錯誤，有時還會進行硬故障轉移，即使文件共享見證也已就位並且正在工作（？！）。

我在事件日誌中觀察到的錯誤和警告是：

FailoverClustering 事件 ID：

• 1135（群集節點“….”已從活動故障轉移群集成員中刪除）
• 1146（集群資源託管子系統（RHS）程序已終止，將重新啟動）
• 1673（集群節點“….”已進入隔離狀態。）
• 1681（節點“….”上的虛擬機已進入不受監控狀態。）

服務控制管理器事件 ID：

• 7024（集群節點的法定人數不存在以形成集群。）
• 7031（群集服務服務意外終止。）

FailoverClustering-客戶端

• 81（擴展 RPC 錯誤資訊）

感謝您的研究，我得到了一個重要線索：隱藏的適配器仍然使用 IPv6。由於您連結到的文章說不建議或主流禁用隱藏適配器上的 IPv6，但支持和測試在所有其他適配器上禁用它，我想知道是什麼阻止了他工作。

使用以下命令，我提取了集群日誌（也感謝您的提示！我不知道這個有用的命令）：

# -Destination (Folder) in my case changed to be not on the "C:\" SATADOM (this thing is slow and has few write cycles)
# -TimeSpan (in minutes) limited to one of the Failovers because these logs get HUGE otherwise.
Get-ClusterLog -Destination "E:\" -TimeSpan 5

不幸的是，我已經發布了相同的日誌條目。

我在所有適配器上重新啟用了 IPv6，並通過以下方式恢復了與隧道相關的適配器/配置：

Set-Net6to4Configuration -State Default
Set-NetTeredoConfiguration -Type Default
Set-NetIsatapConfiguration -State Default

那沒有成功…進一步看，我注意到我也總是禁用“那些不需要的”與 IPv6 相關的防火牆規則…這似乎是真正重要的變化！這些規則似乎也影響了隱形適配器。

事情似乎是：IPv6 不使用 ARP 來查找其通信夥伴的 MAC 地址。它使用鄰居發現協議。如果您禁用相關的防火牆規則，此協議將不起作用。雖然您可以使用以下命令檢查 IPv4 ARP 條目：

arp -a

這不會顯示 IPv6 地址的 MAC 地址。對於那些你可以使用：

netsh interface ipv6 show neighbors level=verbose

如果需要，可以將輸出過濾到 IPv6 適配器地址，如下所示：

netsh interface ipv6 show neighbors level=verbose | sls ".*fe80::1337:1337:1234:4321.*" -Context 4 |%{$_.Line,$_.Context.PostContext,""}

這樣做我發現，這些條目似乎很短暫。群集夥伴的 Microsoft“故障轉移群集虛擬適配器”連結本地地址的條目狀態始終在“可訪問”和“探測”之間切換。雖然我沒有得到它“無法訪問”的那一刻，但是在重新啟用 IPv6 規則後，問題就消失了：

Get-NetFirewallRule -ID "CoreNet-ICMP6-*" | Enable-NetFirewallRule

不知何故，這個 MAC 地址似乎在集群夥伴之間以另一種方式交換（可能是因為它是“虛擬遠端”地址而不是真實地址？）。所以它不斷重新出現，導致那些瘋狂的故障轉移/隔離/隔離狀態。

可能在不可見的適配器上禁用 IPv6 也會有所幫助，但由於不建議這樣做，我現在決定完全停止禁用 IPv6 相關的東西。無論如何，這就是未來:-)

希望這可以幫助另一個 IPv6 禁用者！

引用自：https://serverfault.com/questions/976162