主页 / server / 问题 / 976162
Accepted
Janis Veinbergs
Asked: 2019-07-23 01:31:53 +0800 CST

WSFC 群集中的 Windows Server 2016 来宾因丢弃心跳路由而被随机隔离

  • 772

有 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。

线鲨 2

大约 35 秒后重新添加路由，但这无济于事 - 节点已被隔离 3 小时。

我在这里想念什么？

windows-server-2016

1 个回答

  1. Best Answer

    我刚刚在 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 禁用者！

    • 3

相关问题