Keepalived 基于 VRRP 的高可用设计与故障排查
一、Keepalived 工作原理深度解析
1. 状态转换：VRRP 协议的核心逻辑
1.1 状态机驱动的节点角色切换
Keepalived 通过 VRRP 状态机 实现节点状态的动态管理，核心状态包括：
-
MASTER：
-
职责：负责转发 VIP 流量，定期发送 VRRP 通告（默认间隔 1 秒），维护 ARP 缓存和路由表。
-
特征：优先级最高（默认 100），响应 ARP 请求时返回自身物理接口的 MAC 地址。
-
-
BACKUP：
-
职责：监听 MASTER 通告，计算超时时间（默认 3 秒），准备接管 VIP。
-
特征：优先级低于 MASTER，接收到通告后重置超时计时器。
-
-
INITIALIZE：
- 触发场景：节点启动或配置变更时进入此状态，完成初始化后根据优先级进入 MASTER 或 BACKUP。
1.2 优先级与选举规则
- 优先级调整因素：
vrrp_instance VI_1 {state MASTERinterface eth0priority 100track_interface {eth0 weight -10 # 若eth0故障，优先级降低10}
}
-
手动配置：通过
priority参数设置（范围 1-254，数值越大优先级越高）。 -
接口权重：结合
track_interface动态调整优先级（如链路故障时降低优先级）。
- 选举流程：
-
节点启动后广播 VRRP 通告，声明自身优先级。
-
备份节点比较接收到的优先级，最高者成为 MASTER。
-
优先级相同则比较接口 IP 地址，IP 更大者胜出（避免 MAC 地址随机性影响）。
1.3 状态转换触发条件
| 触发事件 | 源状态 | 目标状态 | 说明 |
|---|---|---|---|
| 首次启动，优先级最高 | INIT | MASTER | 节点成为主节点，开始发送通告 |
| 首次启动，优先级较低 | INIT | BACKUP | 节点进入备份状态，监听主节点通告 |
| 主节点超时未发送通告 | BACKUP | MASTER | 备份节点检测到主节点故障，触发选举并接管 VIP |
| 主节点恢复并重新通告 | BACKUP | BACKUP | 若配置抢占模式，主节点恢复后重新成为 MASTER；否则维持当前主节点 |
2. ARP 通告：VIP 漂移的网络层适配
2.1 免费 ARP（Gratuitous ARP）机制
-
作用：当 VIP 发生漂移时，新的 MASTER 节点通过发送免费 ARP 报文，强制更新局域网内设备的 ARP 缓存，确保流量路由到新节点。
-
报文特点：
-
目标 IP 为 VIP，目标 MAC 为新 MASTER 节点的物理接口 MAC。
-
无需请求直接响应，属于非请求式 ARP（Unsolicited ARP）。
-
-
配置示例：
vrrp_instance VI_1 {# 启用免费 ARP，每 2 秒发送一次gratuitous_arp 2
}
2.2 ARP 缓存更新流程
-
主节点故障：备份节点升级为 MASTER，绑定 VIP。
-
发送 ARP 通告：新 MASTER 向广播地址（FF:FF:FF:FF:FF:FF）发送 ARP 报文，包含 VIP 和自身 MAC。
-
客户端更新：交换机、服务器等设备接收到 ARP 后，更新本地缓存：
# 客户端查看 ARP 缓存变化
arp -n | grep 192.168.1.254 # 故障前指向主节点 MAC，故障后指向备份节点 MAC
- 流量切换：后续数据包根据新 ARP 条目，将目的为 VIP 的流量发送至新 MASTER 节点。
2.3 优化策略
- 抑制不必要的 ARP 广播：通过
no_gratuitous_arp禁止非必要通告（如测试环境）：
vrrp_instance VI_1 {no_gratuitous_arp # 仅在 VIP 状态变更时发送 ARP
}
- 定向 ARP 通告：向特定设备发送 ARP（如核心交换机），减少广播风暴：
vrrp_instance VI_1 {unicast_src_ip 192.168.1.100 # 源 IP（可选）unicast_dest_ip 192.168.1.1 # 目标 IP（如交换机管理 IP）
}
3. 故障恢复：抢占模式与非抢占模式
3.1 抢占模式（Preemptive Mode）
-
默认行为：原 MASTER 节点恢复后，立即重新夺回 VIP 控制权，确保高优先级节点优先服务。
-
适用场景：对主节点角色有严格权限控制的场景（如数据库主库必须由指定节点担任）。
-
配置方式：
vrrp_instance VI_1 {preempt # 开启抢占模式（默认开启）preempt_delay 30 # 恢复后等待 30 秒再抢占（避免频繁切换）
}
3.2 非抢占模式（Non-Preemptive Mode）
-
行为特点：原 MASTER 恢复后，仅作为备份节点，不主动接管 VIP，需手动切换或通过脚本触发。
-
适用场景：读写分离架构（如主库故障转移后，原主库恢复后作为从库）。
-
配置方式：
vrrp_instance VI_1 {nopreempt # 关闭抢占模式
}
3.3 故障恢复流程对比
| 模式 | 原 MASTER 恢复后的操作 | 流量切换方式 |
|---|---|---|
| 抢占模式 | 1. 发送 VRRP 通告声明高优先级；2. 备份节点检测到通告后释放 VIP；3. 原 MASTER 重新绑定 VIP | 自动切换（秒级） |
| 非抢占模式 | 1. 作为备份节点加入集群；2. 需人工执行 repmgr cluster failover 等命令切换 | 手动或脚本触发 |
3.4 状态持久化与脑裂预防
-
状态持久化：Keepalived 通过
/var/lib/keepalived存储节点状态，确保重启后恢复配置。 -
脑裂预防：
-
配置
unicast_src_ip和unicast_dest_ip实现单播通告，避免广播风暴导致的误判。 -
结合存储层锁机制（如 Redis 分布式锁），确保同一时间只有一个节点持有 VIP。
-
二、典型故障场景与排查
场景 1：VIP 未按预期漂移
- 可能原因：
-
优先级配置错误：备份节点优先级高于主节点，导致初始选举失败。
-
通告间隔过长：
advert_int设置过大（如 10 秒），故障检测延迟增加。 -
防火墙阻断：UDP 112 端口（VRRP 协议端口）被防火墙拦截。
- 排查命令：
# 查看 VRRP 状态
sudo keepalived -S info # 或查看 /var/log/keepalived.log
# 检查端口连通性
nc -uzv <节点 IP> 112 # 确保 UDP 112 端口可达
场景 2：ARP 缓存未更新
- 可能原因：
-
免费 ARP 未启用：
gratuitous_arp参数未配置，新 MASTER 未发送通告。 -
交换机开启 ARP 防护：禁止非请求 ARP 报文，需在交换机配置信任 MASTER 节点 MAC。
- 解决方法：
# 手动发送 ARP 通告
arp -s 192.168.1.254 00:0c:29:ef:gh:02 # 强制更新客户端 ARP 缓存
场景 3：抢占模式导致服务抖动
-
可能原因：主节点恢复后立即抢占 VIP，此时服务尚未完全就绪（如数据库未完成同步）。
-
优化方案：
vrrp_instance VI_1 {preempt_delay 60 # 延迟 60 秒抢占，确保服务就绪track_script {check_service # 抢占前执行脚本检测服务健康状态}
}
三、总结：从原理到实践的高可用设计
Keepalived 的工作原理围绕 VRRP 状态机、ARP 动态适配和灵活的故障恢复策略展开，核心目标是在保障服务连续性的同时，尽可能减少对业务的影响。实际应用中需注意：
-
优先级规划：根据节点性能、数据中心等级等因素合理分配优先级，避免选举混乱。
-
健康检查深度：结合 TCP 检测和自定义脚本，实现从网络层到应用层的多级防护。
-
云原生适配：在 Kubernetes 等容器环境中，通过
keepalived-vip等插件实现 VIP 与 Pod 的动态绑定。
通过深入理解这些机制，可构建出健壮的高可用系统，满足金融、电商等对服务稳定性要求极高的场景需求。