Keepalived 心跳检测失败怎样触发故障切换

Keepalived故障切换核心依赖VRRP协议：Master每秒发VRRP心跳，Backup连续3个间隔未收到即判定失效，进入FAULT状态并依据priority竞争成为新Master，绑定VIP、发免费ARP完成接管；超时时间由advert_int与fall参数共同决定。

Keepalived 心跳检测失败触发故障切换，核心依赖 VRRP 协议的机制设计，不是“一两次收不到心跳就切”，而是通过连续失败判定 + 优先级比较 + 状态跃迁完成的。关键在于理解它如何把网络通信异常转化为角色变更。

心跳检测失败后怎么触发切换

• Keepalived 主节点（Master）会周期性地以多播方式发送 VRRP 广告报文（即“心跳”），默认每秒 1 次（advert_int 1），携带自身优先级、状态等信息
• 备节点（Backup）持续监听该多播报文；一旦在 3 个连续广告间隔内（即默认 3 秒）未收到主节点心跳，就判定 Master 不可达
• 此时 Backup 节点立即进入 FAULT 状态，随后根据本地配置的 priority 值，与其他 Backup 节点竞争（若有多备），最终选出新 Master
• 新 Master 启动 VIP 绑定、ARP 刷新（arping）、服务接管（如启动 Nginx、MySQL 等），完成故障切换

注意：这个“3 秒”不是固定值，由 advert_int 和 fail 参数共同决定。例如 advert_int 2; fall 2 表示：心跳间隔 2 秒，连续 2 次收不到即触发切换 → 实际超时为 4 秒。

常见导致心跳失败却未切换的原因

• 防火墙拦截 VRRP 多播报文：VRRP 使用协议号 112（非端口），需放行 proto 112 或 udp port 0（实际不走 UDP 端口）
• 网卡或路由问题：心跳走指定网卡（interface eth0），但该网卡 down、IP 冲突、或未启用 multicast
• 优先级配置错误：两节点 priority 相同，且都设为 nopreempt，可能长期僵持不切换
• 日志被忽略：/var/log/messages 或 journalctl -u keepalived 中出现 VRRP_Instance(VI_1) Sending/Receiving VRRP packet failed 才是真实线索

如何验证心跳是否真正失效

• 在 Backup 节点执行 tcpdump -i eth0 vrrp -nn，观察是否收到主节点 VRRP 报文
• 查看 Keepalived 进程状态：systemctl status keepalived，确认运行中且无 ERROR
• 检查 /etc/keepalived/keepalived.conf 中 vrrp_instance 段是否正确指定了 interface、virtual_router_id（必须主备一致）、priority（Master > Backup）

切换本身不依赖脚本或外部命令，是 Keepalived 内置 VRRP 状态机自动完成的。只要心跳链路断开满足判定条件，且配置无逻辑冲突，切换就会发生。