Oracle RAC如何处理节点驱逐（Eviction）？优化心跳超时阈值

Oracle RAC 节点驱逐的真正触发条件是什么？

在 Oracle RAC 集群环境中，许多管理员存在一个普遍误解，认为“网络心跳丢包”会直接引发节点驱逐。实际上，Oracle RAC 的驱逐机制远比这复杂和严谨。驱逐的核心决策者是 cssd（集群同步服务守护进程），它如同一个高度可靠的裁判，会综合分析来自网络心跳、磁盘心跳以及本地进程心跳的多路信号。

节点被驱逐的根本条件是：任何一条关键心跳路径在预设的超时窗口内持续处于不可达状态。请注意，是“任何一条”而非“所有路径”。这意味着，只要网络、磁盘或本地心跳中有一条关键路径彻底失效并超过容忍时间，cssd 就会启动驱逐流程，而不会等待所有路径都中断。

节点驱逐的真正触发条件是任一关键心跳路径（网络、磁盘或本地）在超时窗口内持续不可达，而不仅仅是网络心跳丢包；cssd 综合判断后触发驱逐，且驱逐决策需获得多数派节点的共识。

这里有一个至关重要的诊断细节：在 cssd 日志中看到 “missed heartbeat from node X” 的警告信息，并不代表节点已被驱逐。这只是一个预警信号。真正的驱逐行动开始前，日志中会出现明确的 “node eviction initiated” 标记。此时，该节点虽然尚未重启，但已经停止参与集群的资源协调，进入了“准驱逐”状态。

• 网络心跳：默认每秒1次。连续3次未响应（即3秒）会触发告警，但最终是否驱逐，取决于 misscount 这个核心参数的设定。
• 磁盘心跳：通过表决磁盘（Voting Disk）进行，可靠性更高，但延迟也相对较高。如果网络中断而磁盘心跳依然通畅，节点通常不会被驱逐。
• 本地心跳：指 cssd 进程自身的健康状态。如果它因 CPU 占满、内存溢出（OOM）等问题而卡死，导致本地心跳失效，那么即使网络和磁盘心跳都正常，该节点也会被其他健康的节点投票驱逐。

如何安全调整 misscount 和 disktimeout 参数？

理解了驱逐逻辑后，调整相关参数就有了明确方向。misscount 是决定网络心跳容忍度的核心参数，单位是秒。其实际含义是“允许连续多少秒收不到任何有效心跳”。自 Oracle RAC 11gR2 起，其默认值通常为30秒。这意味着，一个节点需要连续30秒失去所有心跳联系，才会被判定为失效。盲目调大此值可能掩盖真实的硬件或系统故障，而调小则容易引发误驱逐，导致不必要的服务中断。

另一个关键参数是 disktimeout，它控制磁盘心跳的超时时间，默认值为200秒。这里有一条必须严格遵守的黄金法则：disktimeout 的值必须大于 misscount。否则，磁盘心跳可能永远来不及响应就被判定为超时，从而极大增加误驱逐的概率。

• 调优第一步——确认当前配置：执行 crsctl get css misscount 和 crsctl get css disktimeout 命令，获取当前集群的配置值。
• 何时需要调整：如果环境存在频繁的网络抖动（例如在虚拟化环境或跨机架链路中），可以考虑将 misscount 适度提高到45至60秒。但切记，必须同步将 disktimeout 设置为至少 misscount + 30 秒。
• 如何使修改生效：修改后，需要重启 cssd 服务（使用 crsctl stop crs && crsctl start crs）。并且，所有节点上的设置必须保持完全一致，否则集群可能无法正常启动。
• 修改后的观察期：切勿在生产系统业务高峰期进行修改。调整后，应至少观察48小时，重点检查 $GRID_HOME/log//cssd/ocssd.log 日志中是否出现 “evicting node” 或反复的 “rebooting node” 记录。

为什么调整了阈值节点仍被驱逐？排查这三类底层问题

必须清醒地认识到：调整 misscount 仅仅是延长了故障容忍的窗口时间，并不能修复导致心跳中断的根本原因。大量的运维案例表明，超过90%的非预期驱逐事件，根源在于以下三类未被及时发现的底层异常：

• cssd 进程因 I/O 延迟卡住：表决磁盘（Voting Disk）所在的 ASM 磁盘组如果 I/O 负载过高，会导致磁盘心跳响应超时。通过 iostat -x 1 命令查看，如果 %util 持续高于95%或 await 时间超过50毫秒，就需要警惕。此时单纯调大 disktimeout 可能只是延缓问题，而无法避免最终的驱逐。
• 私网配置不当：RAC 私网未使用专用物理网卡，或者未禁用网卡的高级卸载功能（如通过 ethtool -K eth1 gro off lro off 关闭 GRO/LRO）。这可能导致心跳包被延迟或合并处理，表现为偶发性的 “missed heartbeat”。
• 系统级资源争用与限制：SELinux 运行在强制模式可能会干扰 cssd 对共享设备的访问；另外，操作系统内核信号量参数（kernel.sem）设置过低（建议值至少为 250 32000 100 128）可能导致进程间通信（IPC）信号丢失，从而影响心跳。

如何验证驱逐逻辑是否按预期工作？

如何验证你的参数调整和系统配置是有效的？一个常见的误区是直接模拟网络断开（例如使用 iptables 规则阻断节点间流量）。这种方法不够精确，因为它可能只阻断了部分心跳路径，结果难以复现且无法全面验证逻辑。

更可靠的验证需要分步骤、有控制地进行隔离测试：

• 测试网络心跳失效的响应：在单个节点上，停止 cssd 服务（crsctl stop res ora.cssd -init）。然后观察其他节点的日志，是否在 misscount 秒后准确记录了 “evicting node” 信息。
• 测试磁盘心跳失效的响应：临时卸载表决磁盘（Voting Disk）所在的 ASM 磁盘（umount /dev/asm-diskX）。确认驱逐动作是在 disktimeout 秒之后才被触发，而不是立即发生。
• 关键日志监控：始终紧盯核心日志指标：grep -i “evict\|missed\|reboot” $GRID_HOME/log//cssd/ocssd.log | tail -50。仔细核对日志中的时间戳，看其间隔是否与配置的阈值参数吻合。

这里还有一个复杂点：驱逐决策是集群中“多数派”节点通过共识机制共同做出的。因此，单个节点的日志通常只记录它“被驱逐”的结果，而不会显示是“谁发起了驱逐”。要定位问题的源头，需要横向比对所有节点的 ocssd.log 日志时间线，找出第一个发出 “evicting node” 记录的节点，并追溯该节点在做出决策前的心跳失败记录。这才是完整的故障诊断链条。