Keepalived 是 Linux 环境下实现系统高可用与负载均衡的关键组件，其核心高可用能力建立在 VRRP 协议之上。理解 VRRP 的选举与通告机制，是正确部署 Keepalived 的前提。很多线上故障并非网络中断，而是对协议交互细节理解偏差导致角色震荡或脑裂。
VRRP 协议底层原理与角色选举
VRRP 全称 Virtual Router Redundancy Protocol，本质是将多台物理路由器（或主机）虚拟成一个逻辑路由器，对外提供同一个虚拟 IP（VIP）。协议中定义了 Master 与 Backup 两种角色，Master 负责周期性发送 VRRP 通告报文，Backup 监听这些报文来判断 Master 是否存活。通告报文默认目的地址为组播 224.0.0.18，协议号 112，包含优先级、虚拟路由器 ID 与校验信息等字段。
选举过程遵循优先级最高者胜出原则。优先级取值范围为 1 到 254，配置为 255 表示拥有该 IP 地址的接口本身（如真实网关），通常不参与动态选举。若优先级相同，则比较接口 IP 大小，大者当选。Master 失效后，Backup 在退避时间（通常三倍通告间隔）内未收到报文，便触发新一轮选举，选出新 Master 并接管 VIP，整个过程对客户端透明。这种机制避免了静态网关的单点问题。
需要厘清的是，VRRP 本身只解决“谁持有 VIP”的问题，并不感知后端业务健康。Keepalived 在此基础上引入 vrrp_script 模块，通过自定义检测脚本结果动态调整节点优先级，从而实现业务级高可用。例如当 Nginx 进程退出，脚本返回非 0，节点优先级降低，触发角色切换。这是单纯 VRRP 路由器不具备的能力。
Keepalived 实战部署与配置详解
在 CentOS 或 Ubuntu 上，通过系统包管理器安装 keepalived 后，主配置文件通常为 /etc/keepalived/keepalived.conf。一个最小化的双节点热备配置包含 global_defs、vrrp_instance 与可选的 vrrp_script。以下示例展示主节点配置，备节点仅需修改 priority 与 state。
global_defs {
router_id LVS_DEVEL_01
}
vrrp_script chk_nginx {
script "/usr/bin/pgrep nginx"
interval 2
weight -30
}
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 150
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.0.100
}
track_script {
chk_nginx
}
}
上述配置中，virtual_router_id 两端必须一致，否则被视为不同虚拟组。priority 主节点设 150，备节点可设 120；当 chk_nginx 检测失败时 weight -30 使主节点优先级降至 120，低于备节点从而完成切换。authentication 段防止非法节点加入组播组，生产环境务必设置复杂密码。
网络环境若禁止组播，可将通告改为单播。在 vrrp_instance 中添加 unicast_src_ip 与 unicast_peer 列表即可。单播模式规避了交换机组播限制，但要求明确写出对端 IP。另外，抢占模式（preempt）默认开启，主节点恢复后会夺回 VIP；若业务会话不友好，可设置 nopreempt 让备节点持续服务直至其自身故障。
脑裂成因分析与规避策略
脑裂指主备同时认为自己是 Master 并绑定 VIP，造成 IP 冲突与流量无序。最常见诱因是心跳链路中断但业务链路正常，例如防火墙误拦 VRRP 报文或网卡丢包。此时两端都收不到对方通告，各自升主。解决思路从网络与设计两层入手。
网络层应确保 VRRP 报文专用链路或至少不被安全策略阻断。可借助 tcpdump 观察 224.0.0.18 的协议 112 包：tcpdump -i eth0 vrrp。若备节点完全看不到报文，需检查 iptables 或云安全组。设计层可引入第三方仲裁，如通过 vrrp_script 周期性 ping 网关，失败则主动降权；或采用双心跳网卡绑定。下表对比常见规避手段：
| 方案 | 实现方式 | 适用场景 |
|---|---|---|
| 单播+独立心跳网 | unicast_peer 指向对端管理网 | 云环境禁组播 |
| 脚本仲裁 | 检测上游连通性动态调整 weight | 链路抖动频繁 |
| nopreempt | 关闭抢占避免震荡 | 长连接业务 |
此外，监控不可忽视。通过 SNMP 或 Keepalived 的 notify 钩子，在状态变更时触发告警脚本，第一时间感知切换。结合日志中的 VRRP_Instance 状态行，可快速定位是优先级变化还是报文丢失。完备的部署不仅是写对配置，更要有可观测与可恢复闭环。
与负载均衡层的整合建议
Keepalived 常与 LVS 或 Nginx 组合构成前端高可用接入层。当采用 Nginx 做七层代理时，VIP 漂移后客户端无需更改指向，DNS 记录固定为 VIP 即可。若后端服务要求源 IP 透传，需注意 Master 切换瞬间连接断开，应用层应实现重试。
对于 LVS-DR 模式，Keepalived 可直接管理 ipvs 规则，在 vrrp_instance 之外定义 virtual_server 段，实现故障节点自动剔除。此时 VRRP 保证 Director 高可用，LVS 保证 Real Server 负载均衡，两层职责清晰。生产扩容时，新增 Real Server 只需在配置中追加 real_server 块，无需停业务。
最后强调，任何高可用方案都无法替代备份与容量规划。Keepalived 解决的是节点级失效，而非数据一致或性能瓶颈。上线前应在测试环境模拟断电、拔网线、杀进程三种场景，验证切换时间与业务影响，才能放心投入生产。
KeepalivedVRRP高可用集群修改时间：2026-08-15 22:26:32