Windows故障转移群集的虚拟IP无法访问

Question

windows故障转移群集winserver2016

物理节点node1：ip1， mac1

物理节点node2：ip2，mac2

此时启用一个windows群集服务Serv3，虚拟ip3，在该群集上新增一个虚拟文件服务器FileServ4，虚拟ip4

接入一台win系统的PC-A机，设置ip5

ip1-ip5在同一个网段NetA中。

无论FileServ4运行在node1还是node2上，ip5访问虚拟ip4均正常，可以正常通过SMB访问FileServ4的文件共享，在PC5上arp显示的mac地址均正常（为ip4所在的node节点的mac地址）

在另一个网段NetB中的win系统的PC-B机，通过三层交换机访问NetA网络

情况1，当FileServ4运行在node1上时：

PC-B机ping ip1、ip2、ip4均正常

情况2，将FileServ4切换到node2上时：

PC-B机ping ip1、ip2正常，但ping ip4不通，通过SMB访问FileServ4的文件共享不通无法访问；三层交换上显示ip4的mac地址正常为mac2

测试了多次，问题必现，都出现了这种“群集服务运行在特定节点时，访问物理IP通，但windows故障转移群集的虚拟ip不通”的情况

基本上排除了网络问题，因为所有物理IP都是通的

网上查过相关资料，有人说是windows2016的故障转移群集功能的缺陷导致的

补充一下：最开始部署完群集后，两个节点都是正常的，无论服务运行在哪个节点都能够正常访问。但不知从什么时候开始，它就不行了，问题出现的过程中也没发现两个节点之间有什么差异变量

Answer 1

你好我理解这个故障转移群集问题真的很让人头疼 — 在一个节点上运行正常，但切换到另一个节点就出问题，这种“有时候能用”的情况最难排查。 根据你的描述，物理 IP 一直都能访问，所以基础网络没有问题。 问题通常出在 Windows Server 2016 故障转移群集在节点切换时对虚拟 IP 的处理。 有时候上游三层交换机的 ARP 表不会及时刷新，即使 MAC 地址看起来是正确的。

你可以尝试在资源切换时强制发送 gratuitous ARP 广播，让外部客户端更快更新映射。 另外，检查一下两个群集网络是否都设置为“允许客户端通过此网络连接”，如果某个节点配置不对，就会出现你描述的情况。 还有一个步骤是确认群集角色的依赖关系是否正确（网络名称和 IP 资源绑定）。

这并不是 Windows Server 2016 的根本缺陷，但确实存在一些已知的 ARP 缓存刷新和故障转移时序上的小问题，具体表现也和交换机有关。 安装最新的群集累积更新通常能改善情况。 如果问题依旧，可以考虑测试不同交换机固件，或者在三层设备上缩短 ARP 缓存的生命周期