windows-server-2008-r2 – 集群故障转移和奇怪的无偿arp行为

我遇到了一个奇怪的 Windows 2008R2群集相关问题困扰着我.我觉得我已经接近问题是什么,但仍然不完全了解正在发生的事情.

我在两台2008R2服务器上运行了一个双节点Exchange 2007集群.在“主”群集节点上运行时,Exchange群集应用程序正常工作.
将群集资源故障转移到辅助节点时会发生此问题.

当将群集故障转移到“辅助”节点(例如与“主”位于同一子网上)时,故障转移最初工作正常,并且群集资源在新节点上继续工作几分钟.这意味着接收节点确实发送了一个免费的arp回复数据包,它更新了网络上的arp表.但是经过x个时间(通常在5分钟之内)之后,某些东西会再次更新arp-tables,因为群集服务突然无法响应ping.

所以基本上,当它在“主节点”上运行时,我开始ping交换集群地址.它工作得很好.我将群集资源组故障转移到“辅助节点”,我只丢失了一个可接受的ping.在故障转移之后,群集资源仍然会回答一段时间,突然间ping开始超时.

这告诉我,arp表最初是由辅助节点更新的,但是后来某些东??西(我还没有发现)错误地再次更新它,可能是主节点的MAC.

为什么会发生这种情况 – 有没有人遇到过同样的问题？

群集没有运行NLB,并且在故障转移回没有问题的主节点后,问题会立即停止.

每个节点都使用带有ALB的NIC组合(英特尔).就我而言,每个节点都在同一个子网上,并且有网关等正确输入.

编辑：
我想知道它是否可能与网络绑定顺序有关？因为我注意到从节点到节点的唯一区别是显示本地arp表.在“主”节点上,在群集地址上生成arp表作为源.而在“二级”它从节点自己的网卡生成.

有什么输入吗？

编辑：
好的是连接布局.

集群地址：A.B.6.208 / 25
交换申请地址：A.B.6.212 / 25

节点A：
3个物理网络.
两个使用intels合作,地址为A.B.6.210 / 25,名为public
用于集群流量的最后一个称为私有10.0.0.138/24

节点B：
3个物理网络.
两个使用intels合作,地址为A.B.6.211 / 25,名为public
用于群集流量的最后一个称为私有10.0.0.139/24

每个节点都位于连接在一起的单独数据中心.终端交换机是DC1中的cisco和DC2中的NEXUS 5000/2000.

编辑：
我一直在测试一下.
我现在在同一个集群上创建了一个空应用程序,并在与交换应用程序相同的子网上为其提供了另一个IP地址.在这个空的应用程序失败后,我看到完全相同的问题发生.一到两分钟后,其他子网上的客户端无法ping通应用程序的虚拟IP.但是,虽然其他子网上的客户端不能,但同一子网上另一个群集中的另一台服务器也没有问题.但如果我再将故障转移到原始状态,则情况正好相反.所以现在同一个子网上的客户端不能,而另一些则可以.
我们在同一个子网上设置了另一个集群,具有相同的intel网卡,相同的驱动程序和相同的组合设置.在这里,我们没有看到这一点.所以它有点令人困惑.

编辑：
好的做了一些研究.删除了辅助节点的NIC组合,因为它无论如何都没有工作.经过一些标准问题之后,我终于设法在一个物理网卡上使用旧网卡绑定设置重新启动并再次运行.现在我无法重现上述问题.所以它在某种程度上与团队有关 – 也许是某种错误？

编辑：
如果不能让它失败,还会有一些失败.因此删除NIC团队看起来像是一种解决方法.现在我尝试重新建立与ALB合作的intel NIC(就像之前一样),但我仍然无法让它失败.这很烦人,因为现在我实际上无法确定问题的根源.现在它似乎只是某种MS / intel hick-up – 这很难接受,因为如果问题在14天内再次发生怎么办？虽然发生了一件奇怪的事情.重新创建NIC团队后,我无法将团队重命名为“PUBLIC”,旧团队被称为“PUBLIC”.因此,在Windows中没有清理过某些东西 – 尽管服务器已重新启动！

编辑：
好的,在重新建立ALB团队后,错误又回来了.所以我现在要做一些彻底的测试,我会回过头来看看.有一件事是肯定的.它与Intel 82575EB NICS,ALB和Gratuitous Arp有关.

我很高兴听到这个:)我现在要通过密集测试找出导致这种情况的原因.希望能够取得一些成果.我没有看到Broadcom的这些问题.

@Kyle Brandt：你看到这种情况发生在系统上的驱动程序版本是什么？请提供NIC驱动程序版本和Teaming驱动程序版本.

我正在运行11.7.32.0和9.8.17.

我知道这些驱动程序确实非常古老 – 但由于这个问题只是定期发生,因此如果更新驱动程序正在解决问题,则很难进行故障排除.截至目前我有fx尝试使用此行动计划：1.删除ALB团队 – 无法引发错误发生2.重新建立ALB团队 – 问题再次出现3.尝试AFT(适配器容错) – 问题再次出现4安装最新的驱动程序并再次运行ALB组合(尝试使用11.17.27.0) – 问题已经消失5.回滚驱动程序 – 此操作现在正在等待 – 但直到现在系统正常工作.

我再次发现解决这个周期性问题令人沮丧,因为我现在不知道上述哪个步骤解决了这个问题.最可能的是它是在安装新驱动程序之后 – 但我现在不知道一个事实.

我希望你们中的一些人遇到同样的问题可以添加一些注意事项/想法/观察,以便我们能够找到它的根源.