Keepalived中notify_master脚本延迟执行问题深度解析

问题现象

在Keepalived v2.1.5版本的实际生产环境中，发现配置的notify_master脚本存在明显的延迟执行现象。典型表现为：

1. VRRP实例在08:54:36进入MASTER状态，但关联脚本直到08:54:51才被执行（延迟15秒）
2. 另一次状态切换中，MASTER状态在11:38:54触发，脚本到11:38:57才执行（延迟3秒）

技术背景

Keepalived的VRRP模块通过状态机管理实例状态转换。当实例进入MASTER状态时，会立即执行以下操作序列：

1. 记录"Entering MASTER STATE"日志
2. 同步调用notify_master脚本
3. 开始发送VRRP通告报文

核心代码位于vrrp_state_master_tx()函数中（keepalived/vrrp/vrrp.c），从日志输出到脚本执行是连续操作，理论上不应存在显著延迟。

根因分析

经过深入排查，发现延迟可能由以下因素导致：

1. 系统调度延迟
   Linux内核可能因系统负载过高暂时挂起keepalived进程，特别是当：

   • 系统存在大量中断处理
   • 其他高优先级进程占用CPU
   • 虚拟机环境存在CPU资源争用

2. 脚本执行链阻塞
   虽然refresh-and-enable-arp脚本本身简单，但若系统存在以下情况可能导致延迟：

   • 文件系统挂载点响应缓慢
   • 大量进程竞争执行资源
   • 内核资源（如进程表）暂时耗尽

3. 时间戳记录差异
   脚本中的时间戳记录位置（如refresh-arp开头）与Keepalived日志时间可能存在测量基准差异，但通常不会产生秒级偏差。

解决方案建议

短期缓解措施

1. 提升进程优先级
   在keepalived.conf的global_defs中添加：

   vrrp_rt_priority 50
   

   这将使VRRP进程以SCHED_RR策略运行（优先级50），但注意：

   • 子进程不会继承该优先级（因设置了SCHED_RESET_ON_FORK）
   • 需确保系统未过度分配实时优先级

2. 脚本优化

   • 在脚本开头添加时间戳记录
   • 实现执行超时机制
   • 避免脚本中可能存在的阻塞操作

根本解决建议

1. 解决VRRP报文丢失问题
   日志显示频繁出现：

   Master received advert with higher priority
   

   表明存在网络问题，建议：

   • 检查网络设备（交换机端口、网卡配置）
   • 验证组播/广播通信是否正常
   • 考虑使用VRRP over TCP（如最新版本支持）

2. 系统级优化

   • 为VM分配专用CPU资源
   • 调整内核调度参数（如sched_min_granularity_ns）
   • 监控系统实时负载（通过ftrace或perf）

经验总结

在生产环境中使用Keepalived时需注意：

1. 状态切换脚本应设计为幂等且快速执行
2. 虚拟机环境需特别关注CPU调度和时钟同步
3. 网络稳定性是VRRP可靠运行的基础前提
4. 建议升级到较新版本（v2.2+）以获得更好的稳定性改进

通过系统化的分析和优化，可以显著提高Keepalived在高可用集群中的响应可靠性。