Keepalived 实现 VIP 漂移的本质，是让虚拟 IP 不再固定在某台服务器的网卡上，而是根据主备节点的健康状态动态归属。主节点正常时持有 VIP 并响应请求，一旦主节点宕机或服务异常，VIP 会在秒级内转移到备用节点，客户端几乎无感知。这个过程依赖 VRRP 协议完成状态协商，而部署的关键在于正确区分主备配置、理解优先级变化以及配合健康检查脚本。
一、VIP漂移的核心机制与状态切换
VIP 漂移并不是 Keepalived 独有概念，它的底层支撑是 VRRP，也就是虚拟路由冗余协议。VRRP 把多台物理设备抽象成一个虚拟路由器，对外暴露一个虚拟 IP 和虚拟 MAC。集群中的节点只会有两种角色：主节点和备节点。主节点负责响应发往 VIP 的流量，并持续向局域网发送 VRRP 通告报文，告诉其他节点自己仍然存活。备节点则保持监听，不会主动抢占 VIP。
优先级是决定角色归属的核心参数。每个 VRRP 实例都有一个优先级，取值范围通常是 0 到 255，数值越大越优先。默认情况下，主节点配置 state MASTER 且优先级为 100，备节点配置 state BACKUP 且优先级为 90。当备节点连续多个通告周期没有收到主节点的通告，就会认为主节点已经失联，随即进入选举流程。如果自身优先级高于当前失效节点，备节点会立刻切换为主节点，并在本机网卡上添加 VIP。这个切换周期由 advert_int 控制，默认是 1 秒，因此故障感知通常可以做到秒级完成。
VIP 的添加和移除直接发生在操作系统网卡上。当节点成为主节点时，Keepalived 会调用内核接口将 VIP 附加到指定网卡；当节点降级为备节点时，又会把 VIP 从网卡上摘除。正是因为 VIP 是动态绑定而不是静态写入网卡配置文件，所以同一时刻集群中只有一台设备持有该地址。如果出现两台设备同时绑定 VIP，通常说明 VRRP 通告被防火墙阻断，或者两台节点配置了不同的 virtual_router_id，形成了两个互不通信的虚拟路由器。
二、部署环境与Keepalived配置
部署前需要准备两台操作系统版本一致的 Linux 服务器，并确保它们位于同一个二层网络，因为 VRRP 通告报文依赖组播地址 224.0.0.18，不能跨路由传播。本例假设两台节点 IP 分别为 192.168.10.11 和 192.168.10.12，VIP 设置为 192.168.10.100。两台节点都需要安装 Keepalived，可以使用包管理器直接安装，也可以从源码编译，生产环境建议使用系统仓库提供的稳定版本。
安装完成后，主节点的配置文件通常位于 /etc/keepalived/keepalived.conf。下面是一个典型的主节点配置，启用了一个健康检查脚本，当 Nginx 进程不存在时自动降低优先级，从而触发 VIP 漂移。
global_defs {
router_id KEEPALIVED_MAIN
}
vrrp_script chk_nginx {
script "/etc/keepalived/check_nginx.sh"
interval 2
weight -20
}
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1234
}
virtual_ipaddress {
192.168.10.100/24
}
track_script {
chk_nginx
}
}
这段配置中 vrrp_script 定义了一个外部检查脚本，每 2 秒执行一次。脚本返回非 0 时，Keepalived 会把当前节点的优先级减去 20，主节点优先级从 100 降到 80，低于备节点的 90，于是备节点立即抢占 VIP。这样设计的目的是让 Keepalived 不仅监控服务器是否存活，还能监控具体服务进程是否正常。
备节点配置与主节点基本一致，但需要修改两处：state 改为 BACKUP，priority 改为 90。其余参数如 virtual_router_id、认证密码和 VIP 地址必须完全相同，否则两台节点会各自为政，无法形成有效的主备关系。备节点可以省略健康检查脚本，也可以保留同一脚本，但通常建议保留，以保证接管后继续监控服务状态。
配置完成后，在防火墙中放行 VRRP 协议。由于 VRRP 使用 IP 协议号 112，不是 TCP 或 UDP，因此普通端口放行没有作用。如果使用 firewalld，可以执行 firewall-cmd --add-protocol=vrrp --permanent 后重新加载。随后启动 Keepalived 并设置开机自启，在主节点执行 ip addr show eth0 应该能看到 VIP 已绑定在网卡上。
三、故障切换验证与日志分析
完成基础部署后，切换测试是验证高可用能力的关键步骤。最简单的测试方法是直接停止主节点的 Keepalived 服务，或者直接重启主节点操作系统。停掉主节点后，在备节点上观察 VIP 是否自动出现。正常情况下，备节点会在 1 到 3 秒内完成切换，期间客户端请求可能出现一次连接超时，但不会长时间中断。
更细致的测试可以开启 Keepalived 的详细日志。配置文件中加入 debug 级别日志后，可以通过 journalctl -u keepalived -f 实时查看状态变化。当主节点停止通告后，备节点日志中会出现类似进入 MASTER 状态的记录，同时出现 VIP 添加事件。主节点恢复后，如果配置的是默认抢占模式，VIP 会自动回到主节点；如果配置了 nopreempt，则 VIP 会留在当前持有节点，直到下一次故障发生。
测试时还需要验证 VIP 上的服务是否真正可用。VIP 漂移成功不等于服务已经正常，例如备节点的 Nginx 如果没有配置相同的站点文件，或者后端应用没有启动，即使 VIP 已经接管，用户访问仍然会失败。因此健康检查脚本需要覆盖服务进程、端口监听、甚至具体的 HTTP 响应状态，只做进程级检查有时并不能反映真实可用性。
四、常见问题与优化实践
脑裂是 Keepalived 高可用集群中最棘手的故障之一。脑裂一旦发生，两台节点都会认为自己持有 VIP，导致 IP 地址冲突、请求被随机路由到两台服务器，数据一致性也无法保证。脑裂的常见诱因包括防火墙阻断了 VRRP 通告、交换机端口隔离、virtual_router_id 不一致，以及网络抖动导致备节点超时。排查时可以先抓取组播包确认通告是否到达对端，再核对两边的配置文件和优先级设置。
为了减少脑裂带来的影响，可以在健康检查脚本中加入更严格的判断，比如当备节点检测到网络中已经存在 VIP 时，主动停止本机 Keepalived 或移除 VIP。还可以在路由器或交换机层面配置端口隔离策略，但这对多数业务场景来说成本偏高。更实用的做法是监控告警，当两台节点同时出现 MASTER 状态时立即通知运维人员介入，避免双主状态长时间存在。
Keepalived 不仅可以用在 Nginx 场景，也常用于 LVS、MySQL、Redis 等服务的故障转移。对于数据库这类有持久化需求的场景，VIP 漂移只是第一步，还需要配合数据同步、双主检测和自动恢复机制。此外，在多实例部署中，可以创建多个 vrrp_instance，让不同服务使用不同 VIP 并分布在两台节点上，实现负载分担和互相备份，而不是简单的一主一备闲置一台服务器。
优化层面还可以调整通告间隔和优先级步长。默认 1 秒的通告间隔在链路质量较差的网络中可能出现频繁切换，可以适当增大到 2 秒，同时把健康检查的 interval 和 weight 组合调整得更平滑。对于需要避免回切造成连接中断的场景，可以启用非抢占模式，让 VIP 稳定停留在当前节点，减少不必要的地址迁移。
KeepalivedVIP漂移高可用集群修改时间：2026-10-05 16:21:27