Keepalived 原理篇：VRRP 协议与 VIP 漂移机制深入解析
开篇
很多运维朋友都用过 Keepalived，知道它能做高可用、能漂移 VIP，但对它"为什么能漂移"、VRRP 报文里到底传了什么、主备是怎么选举的，往往一知半解。
本文作为 Keepalived 系列的第二篇，不讲配置、不写安装，专门把 VRRP 协议与 VIP 漂移的底层机制讲透。理解了原理，遇到诡异的高可用问题才能真正定位。
一、Keepalived 的角色定位
先明确一件事：Keepalived 本身不提供业务能力，它是一个"状态协调器"。
它做两件事：
- 用VRRP 协议在多个节点间协商出一个"虚拟路由器"，对外暴露一个虚拟 IP（VIP）。
- 用健康检查脚本 + 优先级动态决定：此刻该由谁持有 VIP。
它就像一个"裁判"，只负责判定"谁上场"，真正的业务（Nginx/MySQL/LVS）由裁判之外的选手完成。
二、VRRP 协议的前世今生
2.1 它解决什么问题
在 VRRP 出现之前，局域网内要做网关冗余，用的是HSRP（思科私有）或VRRP 前身协议，各自封闭、互不兼容。VRRP 由 IETF 标准化，解决了：
- 网关单点故障：一个路由器挂了，全网断网。
- 协议不互通：不同厂商设备无法协同做冗余。
VRRP 让一组路由器对外虚拟成一台路由器，客户端把网关设成这个虚拟 IP 即可，底层谁在服务客户端不关心。
2.2 版本演进
| 版本 | 说明 |
|---|---|
| VRRPv2（RFC 3768） | 仅支持 IPv4，Keepalived 2.x 默认 |
| VRRPv3（RFC 5798） | 支持 IPv4/IPv6，报文结构有变化 |
Keepalived 2.x 同时支持 v2/v3，通过advert报文版本自动协商。IPv6 环境必须用 v3。
2.3 VRRP 的三个角色
| 角色 | 职责 |
|---|---|
| Master | 持有虚拟 IP，正常转发流量，周期性发 Advertisement 报文 |
| Backup | 监听 Master 报文，等待接管；可以有多台 |
| Virtual Router | 逻辑概念，一组 Master+Backup 对外构成的"虚拟路由器" |
三、VRRP 报文结构（拆开看）
VRRP 基于IP 组播通信，协议号为112，目的组播地址为224.0.0.18。报文不经过 TCP/UDP，直接封装在 IP 层。
3.1 报文关键字段
0 1 2 3 |
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|Version| Type | Virtual Rtr ID| Priority | Count IP Addrs| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|(v2) Auth Type | Adver Int | Checksum | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| IP Address (VIP) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Authentication Data (v2 only) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 字段 | 含义 |
|---|---|
| Version/Type | v2 或 v3；Type=1 表示 Advertisement 通告报文 |
| Virtual Rtr ID | 虚拟路由器 ID（0~255），同组必须一致 |
| Priority | 优先级（1~255），选举 Master 的核心依据 |
| Count IP Addrs | 携带的虚拟 IP 个数 |
| Adver Int | 通告间隔（秒），Master 发送报文的周期 |
| IP Address | 虚拟 IP（VIP）地址列表 |
| Authentication Data | 认证数据（v2 的简单认证：PASS/AH） |
核心理解：VRRP 报文就是 Master 每
Adver Int秒广播一次"我还活着，优先级是 XX，虚拟 IP 是我的"这样的声明。Backup 就是听这个声明来判断要不要接管。
3.2 为什么要 multicast（组播）
组播（224.0.0.18）比单播高效——一台 Master 发一次，所有 Backup 同时收到，无需知道各自地址。但组播依赖二层多播能力，云服务器、部分交换机上会被丢弃，这是云上必须改单播的根本原因。
四、Master/Backup 选举机制（核心中的核心）
这是全文最值得记的部分。Keepalived 的选举规则就一条：
priority 值大的当 Master；priority 相同时，真实 IP 大的当 Master。
但要注意顺序和细节：
4.1 初始状态
节点启动后先进入Backup状态，等待Master_Down_Interval（默认约3 × Adver_Int）时间。若这段时间内没收到任何 Master 通告，则立即抢占为 Master。
4.2 抢占（Preempt）
- 默认开启抢占。一台priority 更高的 Backup一旦上线，会立刻剥夺现有 Master 的 VIP。
- 这就是"主节点重启后能抢回 VIP"的机制。
4.3 抢占条件细节
抢占时不是只看 priority，而是比"Master 的 priority + 累计减分"：
选举依据 = Master 通告中的 priority + weight 累计结果这也是为什么健康检查失败（weight=-60）会把一个 150 的 Master 拉低到 90，从而让 100 的 Backup 胜出。
4.4 完整状态机
启动 |
│ |
▼ |
┌─────────┐ Master_Down_Interval 超时 ┌─────────┐ |
┌──────▶ │ BACKUP │ ───────────────────────────▶ │ MASTER │ |
│ └─────────┘ └─────────┘ |
│ ▲ │ |
│ │ 收到更高priority的通告 │ 本机priority被 |
│ │ 或本机priority被压低 │ 健康检查压低 |
│ └────────────────────────────────────────┘ |
| 状态 | 触发条件 | 动作 |
|---|---|---|
| Backup → Master | 超时未收到 Master 通告；或收到更低 priority 通告 | 绑定 VIP、发送免费 ARP |
| Master → Backup | 收到更高 priority 通告（开启抢占） | 释放 VIP、停止通告 |
| Master → Fault | 本机网卡故障、健康检查持续失败 | 释放 VIP，进入 Fault 待机 |
五、VIP 漂移的完整链路（逐字节拆解）
以"主节点 node1 宕机 → 备节点 node2 接管"为例：
时间线： |
T0 node1(MASTER) 持有 VIP=192.168.1.100，每1秒发一次组播通告 |
T1 node1 宕机，停止发通告 |
T2 node2 最后一次收到通告 |
T3 等待 Master_Down_Interval（≈3秒）超时，node2 判定 Master 失联 |
T4 node2 将 VIP 192.168.1.100 绑定到自己的 eth0 |
T5 node2 向全网发送"免费 ARP"(Gratuitous ARP)， |
宣告"192.168.1.100 的 MAC 现在是 node2 的 MAC" |
T6 网关/交换机刷新 ARP 表，发往 VIP 的流量转向 node2 |
T7 node2 进入 MASTER 状态，开始发送自己的 VRRP 通告 |
关键点：VIP 的"漂移"本质是两步——① 把 IP 从 node1 解绑并绑到 node2；② 用免费 ARP通知全网"这条 IP 换了 MAC 地址"。第②步若失败（如 ARP 缓存未刷新），流量仍会发往已宕机的 node1，造成"VIP 已漂移但业务不通"的假象。
免费 ARP（Gratuitous ARP）的作用
它是一类特殊的 ARP 请求：
- 源 IP = 目标 IP = VIP；
- 接收方不是问"谁有这个 IP"，而是"我有这个 IP，请大家更新 ARP 表"。
Keepalived 在 Master 状态切换后，会连续发送多次免费 ARP（默认 5 次，间隔由garp_master_delay控制）确保所有二层设备刷新缓存。
六、主备状态与抢占的边界条件（容易踩坑）
6.1 两台都成了 Master（脑裂）
当心跳链路断了（交换机故障、组播被禁），node2 收不到 node1 通告，会误判 node1 挂了而抢占 VIP，结果两台同时持有 VIP，这就是脑裂（Split Brain）。
Keepalived 自身的脑裂防护手段有限，规避方式：
- 关键业务配合仲裁机制（如 MySQL 配 MHA 或双主防脑裂）；
- 保持优先级严格唯一，避免平票；
- 网络层面保证 VRRP 心跳链路的高可用。
6.2 免费 ARP 失败导致流量不切换
常见于虚拟化/云环境。排障时可用：
bash
# 看 VIP 是否真的绑定了 |
ip addr show eth0 |
# 手动清 ARP 表强制刷新 |
arp -d 192.168.1.100 |
七、单播模式与多播模式（何时用哪个）
| 模式 | 配置 | 适用场景 |
|---|---|---|
| 多播 | 默认，无需额外配置 | 传统局域网、机房物理机 |
| 单播 | 配置unicast_src_ip+unicast_peer | 云服务器、跨网段、多播被禁环境 |
判断标准：能 ping 通彼此、但 VIP 不漂移、日志提示收不到对端通告时，八成是多播被禁，改用单播。
单播配置示例：
conf
vrrp_instance VI_1 { |
unicast_src_ip 10.0.0.11 # 本机真实 IP |
unicast_peer { |
10.0.0.12 # 对端真实 IP |
} |
# 其余配置同多播 |
} |
八、理解这些原理对排障有什么用
| 故障现象 | 原理层面的解释 |
|---|---|
| VIP 起不来 | 没有触发 Backup→Master 的超时判定，或 virtual_router_id 冲突 |
| 双 Master | 心跳链路中断，双方都判定对方失联（脑裂） |
| 主恢复了却切不回去 | 非抢占模式，或 weight 配置让主恢复后 priority 仍低 |
| VIP 漂了但业务不通 | 免费 ARP 未刷新，网关 ARP 表仍是旧 MAC |
| 时好时坏、抖动 | 组播被部分丢弃、Adver_Int 与链路抖动冲突 |
九、总结
把原理浓缩成三句话：
- VRRP 是"选裁判"的协议：通过组播/单播交换 priority，决定谁当 Master、谁持 VIP。
- VIP 漂移是"IP 换绑 + 免费 ARP"：先换绑 IP，再用免费 ARP 通知全网更新 MAC。
- 健康检查是"加减分"：业务挂了就减 priority，让 Backup 名正言顺地赢下选举。
理解了这三层，Keepalived 在你眼里就不再是"玄学"，而是一套逻辑清晰的选举+宣告机制。下一篇我们讲keepalived.conf 全参数详解与常见坑大全，把配置层面的每个参数掰开揉碎。
本文为 Keepalived 高可用系列第 2 篇。系列目录：① Keepalived+Nginx 实战 → ② VRRP 原理篇（本文） → ③ 配置与排障 → ④ Keepalived+MySQL 主从高可用。
