通过

从活动故障转移群集成员身份中删除节点时遇到问题

  • 项目

本文介绍如何解决从活跃故障转移群集成员身份中随机删除节点的问题。

现象

出现问题时，会看到系统事件日志中记录的此类事件：

事件 1135 示例的屏幕截图。

此事件记录在群集中的所有节点上，但已删除的节点除外。 发生此事件的原因是群集中的节点之一将该节点标记为已关闭。 然后，它会通知事件的所有其他节点。 当节点收到通知时，它们会停止并断开与已关闭节点的检测信号连接。

导致节点被标记为已关闭的原因

Windows Server 故障转移群集中的所有节点都通过设置为允许此网络上的群集网络通信的网络相互通信。 这些节点将这些网络中的检测信号数据包发送到所有其他节点。 其他节点应会接收这些数据包并发回响应。 群集中的每个节点都有自己的检测信号，它将监视该信号，以确保网络已启动，并且其他节点已启动。 以下示例应有助于阐明此行为：

两个相互通信的节点关系图。

如果未返回其中任何一个数据包，则将特定的检测信号视为失败。 例如，W2K8-R2-NODE2 在发送请求后收到 W2K8-R2-NODE1 对检测信号数据包的响应，因此确定网络和节点已启动。 如果 W2K8-R2-NODE1 向 W2K8-R2-NODE2 发送请求，并且 W2K8-R2-NODE1 未获得响应，则被视为丢失检测信号，W2K8-R2-NODE1 会跟踪它。 未收到响应可能会导致 W2K8-R2-NODE1 将网络显示为已关闭，直到另一个检测信号请求被收到为止。

默认情况下，群集节点有一个 5 秒内 5 次失败的限制，超出该限制就会将连接标记为已关闭。 因此，如果 W2K8-R2-NODE1 在时间段内未收到响应五次，则会认为到 W2K8-R2-NODE2 的特定路由将关闭。 如果其他路由仍被认为是打开的，则可认为 W2K8-R2-NODE2 仍为活跃成员。

如果所有路由都标记为 W2K8-R2-NODE2，则会从活动故障转移群集成员身份中删除该路由，并记录在第一节中看到的事件 1135。 在 W2K8-R2-NODE2 上，群集服务会在终止后重启，以便尝试重新加入群集。

若要详细了解我们如何处理三个或更多个节点出现特定路由关闭的问题，请参阅 Jeff Hughes 撰写的“已分区”群集网络博客。

现在我们知道了检测信号过程的工作原理，那么导致过程失败的一些已知原因是什么呢？

  1. 实际网络硬件故障。 如果数据包在节点之间的某个位置在网络上丢失，则检测信号会失败。 涉及的两个节点发出的网络跟踪将揭示这一点。

  2. 网络连接的配置文件可能会从“域”传输到“公共”，然后再次返回到“域”。 在这些更改的过渡期间，可能会阻止网络 I/O。 可以通过查看网络配置文件操作日志来检查是否属于这种情况。 可以通过打开事件查看器并导航到应用程序和服务日志\Microsoft\Windows\NetworkProfile\Operational 来查找此日志。 在事件 ID 1135 中提到的节点上查看此日志中的事件，并查看配置文件目前是否发生了更改。 如果是这样，请参阅 网络位置配置文件在 Windows 7 或 Windows Server 2008 R2 中从“域”更改为“公共”。

  3. 在服务器上启用了 IPv6，但在 Windows 防火墙中禁用了以下两个入站和出站规则：

    • 核心网络 - 邻居发现播发
    • 核心网络 - 邻居发现请求

  4. 防病毒软件也可能干扰此过程。 如果怀疑这一点，请通过禁用或卸载软件进行测试。 出于自己的风险执行此操作，因为你此时不受病毒保护。

  5. 网络上的延迟也可能导致这种情况发生。 数据包可能不会在节点之间丢失，但在超时期限到期之前，它们可能无法快速到达节点。

  6. IPv6 是可供故障转移群集用于其检测信号的默认协议。 检测信号本身是通过端口 3343 进行通信的 UDP 单播网络数据包。 如果交换机、防火墙或路由器因未正确配置而不允许此流量通过，你可能会遇到此类问题。

  7. IPsec 安全策略刷新也可能导致此问题。 具体问题是，在 IPSec 组策略更新期间，所有 IPsec 安全关联 (SA) 都被具有高级安全性的 Windows 防火墙 (WFAS) 破坏。 发生这种情况时，会阻止所有网络连接。 如果 Active Directory 执行身份验证时出现延迟，则重新协商安全关联时，这些延迟（阻止所有网络通信）也会阻止群集检测信号通过，并导致群集运行状况监视在 5 秒阈值内未响应时检测节点。

  8. 还有旧的或过时的网卡驱动程序和/或固件。 有时，仅仅因为网卡或交换机的配置错误，也可能导致检测信号丢失。

  9. 新式网卡和虚拟网络卡可能会遇到数据包丢失。 可以通过打开性能监视器并添加计数器“已丢弃的网络接口\数据包”来跟踪此问题。此计数器是累积的，仅在服务器重新启动之前增加。 在此处看到大量丢弃的数据包可能是网卡上的接收缓冲区设置太低或服务器正在缓慢执行且无法处理入站流量的标志。 每个网卡制造商都可以选择是否在网卡的属性中公开这些设置，因此，你需要参考制造商的网站来了解如何提高这些值，并应使用建议的值。 如果在 VMware 上运行，以下博客将详细介绍这一点，包括如何判断这是否是问题，并指向有关要更改的设置的 VMware 文章。

    从 VMware ESX 上的故障转移群集成员身份中删除节点

这些是记录这些事件的最常见原因，但也可能存在其他原因。 此博客的目的是让你对这个过程有一些了解，并让你知道自己要的是什么。 某些用户会将以下值提高到最大值来尝试解决此问题。

参数 默认 范围
SameSubnetDelay 1000 毫秒 250-2000 毫秒
CrossSubnetDelay 1000 毫秒 250-4000 毫秒
SameSubnetThreshold 5 3-10
CrossSubnetThreshold 5 3-10

将这些值增加到其最大值可能会使事件和节点删除消失，它只会掩盖问题。 而无法解决问题。 最好的做法是找出检测信号失败的根本原因并修复它。 增加这些值的唯一实际需求是在多站点方案中，节点驻留在不同位置，网络延迟无法克服。