Keepalived高可用集群实战：VRRP协议原理、配置与排错指南

Keepalived 高可用集群，这四个字背后，是我两年前一次凌晨三点被监控电话吵醒的血泪教训。当时一套跑了快一年的业务系统，Nginx入口节点静悄悄地宕了，整个前端入口中断了一个多小时才被值班同事发现。那次之后我彻底想明白了一件事：单点再怎么加固，都扛不住硬件老化、机房断电、内核panic这种不讲理的事故，高可用集群不是“大厂才需要”的东西，而是一个正经业务系统的基本盘。而Keepalived，就是我在对比了多套方案之后最终选定的那个“把VIP安稳地漂来漂去”的组件。

这篇文章不打算写成一页页的官方文档翻译，而是把Keepalived高可用集群从原理、选型、配置、验证、排错这几条线完整串一遍，重点讲清楚那些文档里不会明说的设计动机和坑。如果你正在为内网网关、数据库前置、负载均衡入口、DNS服务这类场景搭建双机热备，这篇文章可以直接当作业指导书来用。

1. 为什么我最终选了Keepalived：高可用方案的选型逻辑

先别急着敲安装命令，我们先说清楚一件事：Keepalived在整套高可用架构里到底扮演什么角色。它最核心的能力只有三个——通过VRRP协议把一组机器组织成一个虚拟路由器、对外提供一个可漂移的虚拟IP（VIP）、用自定义脚本探测业务健康状态并据此调整角色。换句话说，它解决的是“一台机器挂了，IP能不能自动换到另一台机器上继续干活”这个最基础也最关键的问题。

当年我面临的选择其实不少，这里把常见方案放在一起对比过，结论会更立体：

重点说下为什么没有选Pacemaker这类重方案。如果只是双机主备、资源就一个VIP加两个服务，用Pacemaker属于典型的“杀鸡用牛刀”。它的资源约束语法、fencing机制、DC选举逻辑，光是理解成本就够喝一壶，而且配置文件的维护压力并不小。Keepalived的哲学是“一个主配置文件搞定一切”，vrrp_instance里既能定义VIP，又能挂脚本做健康检查，还能在角色切换时触发notify脚本，心智负担小得多，出问题也好排查。

另一个促使我选Keepalived的关键因素，是它对网络拓扑的侵入性极低。你不需要在交换机上做任何改动（除非要手动绑MAC），只靠VRRP多播包就能完成节点间的协商。对很多没有网络设备权限、只能在服务器层面想办法的团队来说，这是非常大的自由度。

当然，Keepalived也不是万能的。比如它无法帮你自动拉起一台新的应用服务器，也无法解决两台机器之间的网络彻底隔离下的状态决策问题（这就是脑裂，后面专门说），更不负责分布式锁之类的强一致事务。认清边界比盲目崇拜重要。

2. VRRP协议与VIP漂移：Keepalived高可用的底层逻辑

Keepalived的底层灵魂是VRRP（Virtual Router Redundancy Protocol，虚拟路由冗余协议）。这个协议的目的很简单：把多台路由器（在咱们的场景里就是多台Linux服务器）虚拟成一台“虚拟路由器”，对外只暴露一个虚拟IP，由其中一台MASTER实际持有并响应ARP请求，其他机器作为BACKUP待命。MASTER挂了，BACKUP顶上，整个过程对客户端来说是无感的。

VRRP本质上是个基于多播的选举协议，默认组播地址是224.0.0.18，协议号112。节点之间通过周期性发送VRRP报文来宣告自己的存活状态和优先级。这里有几个关键点值得展开：

• 优先级（priority）决定角色：范围是1到254，数值越大越优先成为MASTER。两台机器优先级不同，就能实现“A为主、B为备”的固定主备模式；如果优先级相同，则比较IP地址大小来决定谁是MASTER。
• 抢占（nopreempt）机制：默认情况下，一个BACKUP如果发现自己的优先级比当前MASTER高，会立刻抢占成为MASTER。这在计划内切换、RMA维护场景中很有用；但如果不希望频繁抢占（比如希望“先到先得”，谁活着谁继续干），可以打开nopreempt。
• 发送间隔与master_down：MASTER默认每秒发送一次VRRP通告（advert_int 1s），BACKUP如果在3个通告间隔内没收到MASTER的报文，就判死对方并进入MASTER状态。这个3倍规则不是随便定的，是为了兼容网络抖动和报文丢失，但又不能等太久。

VIP漂移的本质，是MASTER变更后在局域网内重新广播 gratuitous ARP（免费ARP），告诉所有交换机、客户端“这个虚拟IP的MAC地址变了，请刷新ARP缓存”。这一步如果出现问题，客户端的TCP连接就会一直往旧MAC上发，表现为服务“假死”。后面