集群故障转移和奇怪的免费 arp 行为

Question

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

我有一个运行在两台 2008R2 服务器上的两节点交换 2007 集群。在“主要”集群节点上运行时，交换集群应用程序工作正常。将群集资源故障转移到辅助节点时会出现此问题。

当将集群故障转移到“辅助”节点时，例如与“主要”节点在同一子网上，故障转移最初工作正常，集群资源继续在新节点上工作几分钟。这意味着接收节点确实会发送一个更新网络上的 arp 表的免费 arp 回复数据包。但是在 x 时间（通常在 5 分钟内）之后，某些东西会再次更新 a​​rp 表，因为集群服务突然不响应 ping。

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

这告诉我 arp 表最初是由辅助节点更新的，但随后（我还没有发现）错误地再次更新它，可能是主节点的 MAC。

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

群集未运行 NLB，故障转移回没有问题的主节点后，问题会立即停止。

每个节点都将 NIC 组合 (intel) 与 ALB 结合使用。就我而言，每个节点都在同一个子网上，并且具有网关等输入正确。

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

对此有任何意见吗？

编辑：
好的，这里是连接布局。

集群地址：AB6.208/25 交易所申请地址：AB6.212/25

节点 A：3 个物理网卡。两个使用 intels 组合，地址为 AB6.210/25，称为 public 最后一个用于集群流量，称为 private，地址为 10.0.0.138/24

节点 B：3 个物理网卡。两个使用 intels 绑定，地址为 AB6.211/25，称为 public 最后一个用于集群流量，称为 private，地址为 10.0.0.139/24

每个节点位于连接在一起的独立数据中心。DC1 中的终端交换机为 cisco，DC2 中为 NEXUS 5000/2000。

编辑：
我一直在测试更多。我现在在同一个集群上创建了一个空的应用程序，并在与交换应用程序相同的子网上给它另一个 IP 地址。在这个空的应用程序失败后，我看到了完全相同的问题发生。一两分钟后，其他子网上的客户端无法 ping 应用程序的虚拟 IP。但是，虽然其他子网上的客户端不能，但来自同一子网上另一个集群的另一台服务器 ping 没有问题。但是，如果我再次故障转移到原始状态，则情况相反。所以现在同一子网上的客户端不能，而在其他子网上可以。我们有另一个集群以相同的方式设置在相同的子网上，使用相同的英特尔网卡、相同的驱动程序和相同的分组设置。在这里我们没有看到这一点。所以它有点令人困惑。

编辑：
好的，做了更多的研究。删除了辅助节点的 NIC 组合，因为它无论如何都不起作用。在经历了一些标准问题之后，我终于设法在一张物理网卡上使用旧的 NIC 组合设置重新启动并运行它。现在我无法重现上述问题。所以它在某种程度上与团队有关 - 也许是某种错误？

编辑：进行
了更多的故障转移而无法使其失败。因此，移除 NIC 团队似乎是一种解决方法。现在我尝试重新建立与 ALB 合作的英特尔 NIC（就像以前一样），但我仍然无法使其失败。这很烦人，因为现在我实际上无法查明问题的根源。现在它似乎只是某种 MS/intel 故障 - 这很难接受，因为如果问题在 14 天内再次出现怎么办？然而，发生了一件奇怪的事情。在重新创建 NIC 团队后，我无法将团队重命名为旧团队所称的“PUBLIC”。因此，Windows 中的某些内容尚未清理 - 尽管服务器已重新启动！

编辑：
好的，在重新建立 ALB 组合后，错误又回来了。所以我现在要进行一些彻底的测试，然后我会得到我的观察结果。有一件事是肯定的。它与 Intel 82575EB NICS、ALB 和 Gratuitous Arp 有关。

---

听到这个消息我感到很高兴 :) 我现在将通过进行密集测试来找出导致这种情况的原因。希望能得到一些结果。我还没有在 Broadcom 上看到这些问题。

@Kyle Brandt：您看到这种情况发生的系统上有哪些驱动程序版本？请同时提供 NIC 驱动程序版本和 Teaming 驱动程序版本。

我正在运行 11.7.32.0 和 9.8.17。

我知道一个事实，这些驱动程序确实很旧 - 但由于这个问题只是定期发生，如果更新驱动程序可以解决问题，则很难进行故障排除。截至目前，我已尝试使用此行动计划： 1. 删除 ALB 绑定 - 无法引发错误发生 2. 重新建立 ALB 绑定 - 问题再次出现 3. 尝试 AFT（适配器容错） - 问题再次消失 4 . 安装最新的驱动程序并再次运行 ALB 组（尝试使用 11.17.27.0） - 问题消失 5. 回滚驱动程序 - 此操作现在待定 - 但直到现在系统工作正常。

我再次发现很难解决这个周期性问题，因为我现在不知道上述哪个步骤解决了这个问题。最有可能是在安装新驱动程序之后 - 但我现在不知道事实。

我希望你们中的一些遇到同样问题的人可以添加一些注释/想法/观察，以便我们能够找到问题的根源。

Answer 1

我开始看到机器为故障转移群集中的多个 SQL Server 实例获取不正确的 ARP 表条目。

客户端服务器交替使用来自正确 NIC 组的 MAC 地址和来自不同群集节点上的物理 NIC 之一（不一定是该服务器上相应的 NIC 组 MAC）的 MAC 地址来填充其 ARP 表。

这会导致与 SQL 群集位于同一 LAN 上的客户端间歇性连接失败。

VM 客户端和物理设备均已注意到此行为。

这种情况发生在故障转移后并持续数天。

为了缓解这种情况，我不得不在更麻烦的客户端上设置静态 arp 条目。

环境：

• 故障转移群集中的 Windows 2008 R2 SP1 服务器
• SQL Server 2008 R2 实例
• 联合英特尔千兆位网卡
• HP 28XX 交换机
• 托管在 Windows Server 2008 R2 SP1 Hyper-V 上的虚拟机

英特尔网卡团队使用其中一个物理网卡的 MAC 地址创建虚拟适配器。

我怀疑英特尔网卡组合软件是罪魁祸首，但任何其他故障排除想法或解决方案将不胜感激。

我可能会使用 Server 2012 重建集群主机，并使用内置的 NIC 组合（因为我在该平台的测试中尚未发现该问题）。