我遇到了一个奇怪的 Windows 2008R2 集群相关问题，这个问题让我很困扰。我觉得我已经接近问题所在了，但仍然不完全明白发生了什么。
我有一个在两台 2008R2 服务器上运行的双节点 Exchange 2007 集群。Exchange 集群应用程序在“主”集群节点上运行时工作正常。当将集群资源故障转移到辅助节点时，就会出现问题。
当将集群故障转移到“辅助”节点（例如，与“主”节点位于同一子网）时，故障转移最初可以正常工作，集群资源在新节点上继续工作几分钟。这意味着接收节点确实会发送免费的 arp 回复数据包，以更新网络上的 arp 表。但是经过 x 段时间（通常在 5 分钟内），某些东西会再次更新 arp 表，因为集群服务突然不响应 ping。
因此，基本上，当 Exchange 群集地址在“主节点”上运行时，我会开始 ping 该地址。效果非常好。我将群集资源组故障转移到“辅助节点”，并且只丢失了一个 ping，这是可以接受的。群集资源在故障转移后仍会响应一段时间，然后突然 ping 开始超时。
这告诉我，arp 表最初是由辅助节点更新的，但后来某些东西（我还没有发现）错误地再次更新了它，可能是使用了主节点的 MAC。
为什么会发生这种情况 - 有人遇到过同样的问题吗？
群集未运行 NLB，并且在故障转移回没有问题的主节点后问题立即停止。
每个节点都使用 NIC 组合 (intel) 和 ALB。就我而言，每个节点都位于同一子网中，并且网关等均输入正确。
编辑：
我想知道这是否与网络绑定顺序有关？因为我注意到，我能看到的唯一节点间差异是在显示本地 arp 表时。在“主”节点上，arp 表是在群集地址上生成的，作为源。而在“辅助”节点上，它从节点自己的网卡生成。
对此有什么意见吗？
编辑：
好的，这是连接布局。
集群地址：AB6.208/25 交易所申请地址：AB6.212/25
节点 A：3 个物理网卡。两个使用英特尔网卡的网卡组成一个组，地址为 AB6.210/25，称为公共网卡；最后一个用于集群流量的网卡称为私有网卡，地址为 10.0.0.138/24
节点 B：3 个物理网卡。两个使用英特尔网卡的网卡组成一个组，地址为 AB6.211/25，称为公共网卡；最后一个用于集群流量的网卡称为私有网卡，地址为 10.0.0.139/24
每个节点位于连接在一起的独立数据中心。终端交换机在 DC1 中为思科，在 DC2 中为 NEXUS 5000/2000。
编辑：
我做了更多测试。我现在在同一个集群上创建了一个空应用程序，并给它提供了与交换应用程序位于同一子网上的另一个 IP 地址。在故障转移此空应用程序后，我看到完全相同的问题发生了。一两分钟后，其他子网上的客户端无法 ping 应用程序的虚拟 IP。但是，虽然其他子网上的客户端无法 ping 通，但同一子网上另一个集群的另一台服务器可以 ping 通。但如果我再次故障转移到原始状态，情况就会相反。所以现在同一子网上的客户端无法 ping 通，而其他子网上的客户端可以。我们在同一子网上以相同的方式设置了另一个集群，使用相同的英特尔网卡、相同的驱动程序和相同的组合设置。在这里我们没有看到这一点。所以这有点令人困惑。
编辑：
好的，做了一些研究。删除了辅助节点的 NIC 组合，因为它无论如何都不起作用。在经历了一些标准问题之后，我终于设法在单个物理网卡上使用旧的 NIC 组合设置重新启动并运行它。现在我无法重现上面描述的问题。所以它在某种程度上与组合有关 - 也许是某种错误？
编辑：
进行了更多故障转移，但无法使其失败。因此，删除 NIC 组似乎是一种解决方法。现在我尝试重新建立英特尔 NIC 与 ALB 的组队（就像以前一样），但我仍然无法使其失败。这很烦人，因为现在我实际上无法确定问题的根源。现在它似乎只是某种 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. 回滚驱动程序 - 此操作现在正在等待中 - 但到目前为止系统运行正常。
然而，我再次发现很难解决这个周期性问题，因为我现在不知道上述哪个步骤解决了这个问题。最有可能是在安装新驱动程序后 - 但我现在不知道事实。
我希望你们中遇到同样问题的人可以添加一些注释/想法/观察，以便我们能够找到问题的根源。
答案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 上托管的虚拟机
英特尔 NIC 团队使用其中一个物理 NIC 的 MAC 地址创建一个虚拟适配器。
我怀疑英特尔 NIC 组合软件是罪魁祸首，但如果有任何其他故障排除想法或解决方案，我将不胜感激。
我可能会用 Server 2012 重建集群主机并在那里使用内置 NIC 组合（因为我在该平台的测试中没有看到该问题）。
答案2
您是否已应用最新的集群修补程序？存在一些相当严重的已知缺陷。
暂时性通信故障导致 Windows Server 2008 R2 故障转移群集停止工作
https://support.microsoft.com/kb/2550886
如果集群和应用程序服务器之间没有路由器，故障转移操作会很慢
https://support.microsoft.com/kb/2582281
“出现此问题的原因是应用程序服务器的 TCP/IP 堆栈错误地忽略了不必要的地址解析协议 (ARP) 请求。”
答案3
这纯粹是推测，但我的猜测是，启用 RLB 可能会产生一些不良交互（默认情况下会打开，Lazerpld、Steven 和 Stack Exchange 都遇到了这个错误）。从英特尔团队白皮书：
接收负载平衡 (RLB) 是 ALB 的一个子集。它允许流量在组中的所有适配器上同时在 Tx 和 Rx 中流动。在 Windows 中创建 RLB 组时，此功能默认启用。可以使用组的高级设置通过英特尔® PROSet GUI 禁用它。
在 RLB 模式下，当客户端尝试通过发送 ARP 请求消息连接到团队时，英特尔 ANS 将控制来自 TCP 堆栈的服务器 ARP 回复消息。然后，英特尔 ANS 根据 RLB 算法将所选团队中为特定终端客户端提供服务的端口之一的 MAC 地址复制到 ARP 回复中。当客户端收到此回复消息时，它会将团队 IP 与给定 MAC 地址之间的匹配项包含在其本地 ARP 表中。随后，所选端口将接收来自此终端客户端的所有数据包。在此模式下，当客户端请求连接到服务器时，英特尔 ANS 会以循环方式分配团队成员来为终端客户端连接提供服务。为了在团队中所有启用的成员之间实现最终客户端的公平分配，RLB 客户端表会以均匀的间隔刷新（默认为五分钟）。这是接收平衡间隔，是注册表中的预配置设置。刷新涉及根据需要为每个客户端选择新的团队成员。英特尔 ANS 使用要连接的新 MAC 地址向受影响的客户端发起 ARP 回复，当所有客户端的 ARP 表都由英特尔 ANS 更新后，接收流量的重新分配就完成了。
操作系统可以随时发出 ARP 请求，这些请求不受英特尔 ANS 驱动程序的控制。这些是通过主端口发出的广播数据包。由于请求数据包使用组的 MAC 地址（组中主端口的 MAC 地址）传输，因此连接到该组的所有最终客户端都将通过将组的 IP 地址与主端口的 MAC 地址相关联来更新其 ARP 表。发生这种情况时，这些客户端的接收负载将集中在主端口上。
为了重新启动 Rx 负载平衡，英特尔 ANS 会向接收哈希表中所有向非主端口传输数据的客户端发送免费 ARP，其中包含相应团队成员的 MAC 地址。此外，操作系统发送的 ARP 请求会保存在 RLB 哈希表中，当从最终客户端收到 ARP 回复时，客户端的 MAC 地址会在哈希表中更新。这与服务器发起连接时启用 RLB 的机制相同。
所以我的理论是，也许当 Windows 集群发布虚拟 IP 时，英特尔驱动程序看不到 IP 已发布，并继续宣布它。话虽如此，现在这只是一个理论。
答案4
我遇到了类似的问题，与你们不同的是，同一子网上的服务器（随机）在任何时候都会停止 ping 我的 SQL 集群，而无需切换/移动集群上的活动节点，即：节点 A 是活动的，节点 B 是备用的，突然我的应用程序服务器与 SQL Server（节点 A - 活动）失去连接。当我检查它们的 ARP 表时，我发现集群 IP 的条目填充了来自（节点 B - 备用）的 MAC 地址。不知何故（我仍然找不到原因）应用程序服务器更新了它的 ARP 表。我已经用 wireshark 嗅探过，没有得到任何包含该更改的 ARP 回复。
问候，
胜利者