Keepalived高可用实战：VRRP协议原理、VIP漂移与Nginx故障切换

1. Keepalived到底解决什么问题：高可用基础场景

1.1 从一次真实故障说起

先讲个我亲身经历的事。前几年给一家电商公司做运维支持，他们的线上商城入口是两台Nginx做负载均衡，前面挂着一台物理机充当网关入口。有一天晚上十一点多，那台入口机器突然宕机了，结果整个商城直接无法访问，后台告警电话被打爆。事后复盘，大家发现了一个很扎心的事实：明明有两台Nginx，但它们只是“各自为战”，并没有形成一个整体。入口机器一挂，上面配置的虚拟IP也跟着消失了，流量没有其他路径可以走，整个系统瞬间瘫痪。

这正是Keepalived登场的地方。它的核心作用就是把多台机器组织成一个“高可用小组”，对外只暴露一个虚拟IP（VIP）。哪台机器挂了，VIP就自动漂移到另一台活着的机器上，客户端完全无感知。换句话说，Keepalived解决的是单点故障问题，而不是负载均衡问题。很多人一开始会把这两个概念搞混，后面我会专门展开说。

1.2 VIP漂移与VRRP协议的核心逻辑

Keepalived能实现故障切换，底层依赖的是VRRP协议（Virtual Router Redundancy Protocol，虚拟路由冗余协议）。这个协议的设计思路很有意思，它把一组路由器（或者服务器）当作一个“虚拟路由器”，对外用一个虚拟IP来提供服务。组内会通过优先级机制选出一个Master节点来承载流量，其余节点都是Backup，时刻监听Master的心跳。

心跳报文通过组播地址224.0.0.18发送，默认每隔1秒发一次。Backup节点只要连续收到Master的报文，就默认一切正常；一旦超过一定时间收不到，就会认定Master挂了，然后按照优先级重新选举，抢占VIP继续对外服务。这种机制和现实中的“备胎上位”很像——平时备胎不发声，但一旦主位出问题，立刻顶上，而且整个过程对客户端是透明的。

Keepalived项目最早就是基于VRRP协议实现的一套高可用方案，但它比纯VRRP多做了一件事：健康检查。它不仅可以检测节点本身是否存活，还能通过脚本检测Nginx、MySQL、业务接口等服务的运行状态。比如你配置一个脚本去检测Nginx进程是否存在，如果Nginx挂了，Keepalived会先尝试重启它；重启失败则主动降低自身优先级，把VIP让给其他健康的节点。这种“服务级”的故障感知能力，是它被广泛使用的重要原因。

1.3 Keepalived和HAProxy到底有什么区别

这个几乎是面试必问题，也是很多新手最迷糊的地方。简单说，两者根本不在一层：Keepalived负责“高可用”，HAProxy负责“负载均衡”。它们经常一起配合使用，但职责完全不同。

如果做个类比，Keepalived像是小区的门禁系统——它决定哪个门岗开放，哪个门岗待命，让业主永远有一个能进出的门；HAProxy则像是楼栋里的电梯调度——它把不同楼层的人分派到不同电梯里，均衡分配压力。一个管“活着的入口”，一个管“入口内的流量分发”。

在实际架构中，最常见的组合是：两台HAProxy节点，前面用Keepalived挂一个VIP；两台Nginx或应用服务器，由HAProxy做七层负载均衡。Keepalived保证HAProxy不单点，HAProxy保证后端服务不单点。如果你只有两台Nginx，也没有Keepalived，那和文章开头那个案例一样，机器再多也可能因为某个环节的故障导致整体不可用。

当然，两者也有一个“功能重叠”的区域：Keepalived本身可以通过配置实现简单的负载均衡，但它只支持LVS（Linux Virtual Server）的模式，而且配置复杂、管理成本高，远不如HAProxy灵活。所以生产环境里，Keepalived通常是作为“VIP漂移引擎”来用的，负载均衡的活儿还是交给专业选手。

2. 环境部署前的准备与设计思路

2.1 部署架构怎么选：主备还是双主

在动手安装之前，先想清楚要部署成哪种模式。Keepalived最常见的两种拓扑是主备模式（Master/Backup）和双主模式（Active/Active）。

主备模式最简单：一台Master，一台Backup，VIP只漂移在这两台之间。正常工作时流量全走Master，Backup闲置。优点是配置简单、逻辑清晰，适合对一致性要求极高的场景，比如数据库主从切换、Nginx入口等；缺点是Backup机器平时不出力，有点浪费。

双主模式更高级：两台机器各自有一个VIP，互为主备。比如机器A持有VIP1，机器B持有VIP2，正常情况下VIP1走A、VIP2走B，负载各分担一半；一旦A挂了，VIP1会漂移到B上，由B同时扛两个VIP。这种模式能充分用上两台机器，适合Web前端这类无状态服务。缺点是配置上需要两个vrrp_instance，而且业务逻辑必须支持跨节点接管，否则容易出问题。

对于第一次部署Keepalived的新手，我建议先从主备模式起步。等把日志、告警、切换机制都摸熟了，再考虑双主。别一开始就上复杂拓扑，否则出了问题很难定位到底是谁在抢VIP。

2.2 服务器基础环境要求

Keepalived对硬件的要求很低，普通虚拟机都能跑，但它对网络环境有一个硬性要求：所有参与高可用的节点必须处于同一个二层网络中。因为VRRP报文是通过组播发送的，跨网段是收不到的。所以，做Keepalived集群的几台机器，必须挂在同一个交换机下，处于同一个网段。

系统方面，CentOS 7/8、Ubuntu 18.04/20.04/22.04、Debian等主流Linux发行版都支持。内存和CPU没有硬性指标，512MB内存的轻量服务器也能跑得很稳，因为Keepalived本身非常轻量，通常只占几十MB内存。真正影响资源占用的是你写的健康检查脚本，如果脚本写得低效，或者检测频率太高，还是会有压力的。

一个容易踩的坑是：两台机器的时间如果不一致，虽然不影响VRRP主备选举，但会导致日志时间错乱，排查问题的时候非常痛苦。建议部署前先统一配置NTP时间同步。

2.3 安装Keepalived的两种方式

Keepalived的安装方式有两种主流选择：系统包管理器安装和源码编译安装。

方式一：系统包管理器安装

这种方式最省心，CentOS用yum，Ubuntu用apt就能搞定。

bash复制# CentOS / RHEL
yum install -y keepalived

# Ubuntu / Debian
apt update && apt install -y keepalived

装完后配置文件会自动放在/etc/keepalived/keepalived.conf，systemd服务也会自动注册好，直接就能用systemctl start keepalived启动。

方式二：源码编译安装

如果系统源里的版本太旧，或者你希望定制编译参数，就需要自己编译。整个流程也不复杂：

bash复制# 下载源码，以2.2.7版本为例
wget https://www.keepalived.org/software/keepalived-2.2.7.tar.gz
tar -zxvf keepalived-2.2.7.tar.gz
cd keepalived-2.2.7

# 安装依赖
yum install -y gcc openssl-devel libnl3-devel

# 编译安装
./configure --prefix=/usr/local/keepalived
make && make install

这里有个细节：源码编译安装后，配置文件默认在/usr/local/keepalived/etc/keepalived/keepalived.conf，而且systemd服务可能没有自动注册，需要手动创建服务文件。如果没有特殊定制需求，我建议直接用系统包管理器安装，省时省力，后续升级也方便。

3. 配置文件详解与实操配置

3.1 看懂keepalived.conf的基本结构

安装完成后，核心工作就是编写配置文件。Keepalived的配置语法虽然不复杂，但第一次看的人可能会被一堆大括号吓到。其实整份配置分为两大块：全局配置（global_defs）和VRRP实例配置（vrrp_instance），如果用到健康检查，还会有一个脚本配置（vrrp_script）。

我先给出一份最基础的主备模式配置，然后逐段拆解说明：

bash复制# 全局配置
global_defs {
    router_id LVS_DEVEL
    enable_script_security
}

# 健康检查脚本，检测Nginx进程是否存活
vrrp_script chk_nginx {
    script "/etc/keepalived/check_nginx.sh"
    interval 2
    weight -20
    fall 2
    rise 1
}

# VRRP实例
vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.1.100/24 dev eth0 label eth0:1
    }
    track_script {
        chk_nginx
    }
}

配置看起来不长，但每一行都有讲究。下面我逐个参数说清楚。

3.2 全局配置与VRRP实例参数逐个拆解

先看global_defs块，最重要的就是router_id。它是Keepalived节点的标识符，在同一个VRRP组里可以不相同，主要用来在日志中识别是哪个节点发出的消息。enable_script_security是用来限制脚本执行权限的，建议加上，安全性更好。

接下来是vrrp_instance，这是配置的核心。state定义初始状态，Master和Backup的写法要配合优先级一起看，下面会讲。interface指定VRRP报文从哪个物理网卡发出，务必和机器实际网卡名一致，用ip addr命令确认，填错会导致组播发不出去。

virtual_router_id是一个关键参数，取值范围0到255。同一个高可用组里的所有节点，这个ID必须完全一致，它决定了多个实例之间的隔离。如果你在同一套环境里跑了多组Keepalived，记得为每组分配不同的ID，否则会发生串扰，两个不相关的组会互相抢VIP。

priority参与优先级选举。数值越大，成为Master的概率越高。在主备模式下，Master节点通常配置100，Backup节点配置90。要注意，这个数字不是单纯按大小排的，而是会受健康检查脚本的weight参数影响，后面我会专门演示一个真实场景。

advert_int是VRRP广播间隔，单位秒，默认1秒。如果业务对切换时间敏感，可以调到0.5秒，但会增加网络开销。authentication块里的auth_type和auth_pass是认证配置，同一个组内的认证方式和密码必须一致，否则报文会被丢弃。密码最长8位，别写太复杂，它就是一道基础防线。

virtual_ipaddress就是最终要对外提供的VIP。写法上，IP后面可以带子网掩码，也可以加dev指定网卡和label指定别名。比如192.168.1.100/24 dev eth0 label eth0:1，意思是VIP绑定到eth0上，并且别名为eth0:1。加label的好处是排查问题的时候，一眼就能通过ip addr看到这个VIP是哪来的。

3.3 健康检查脚本：检测Nginx进程是否存活

现在重点讲vrrp_script，这是Keepalived的灵魂组件。没有它，Keepalived只能检测“机器是否存活”；有了它，才能检测“服务是否正常”。

bash复制vrrp_script chk_nginx {
    script "/etc/keepalived/check_nginx.sh"
    interval 2
    weight -20
    fall 2
    rise 1
}

这段的含义是：每隔2秒执行一次check_nginx.sh脚本，如果脚本返回0，表示服务正常；返回非0，表示服务异常。fall 2表示连续失败2次才最终判定服务故障，这个参数能避免偶发抖动导致误切换。rise 1表示只要恢复1次，就立即认定服务正常。

weight参数的逻辑要理清楚：当脚本检测失败时，当前节点的优先级会降低20。假设Master的初始优先级是100，检测失败后变成80，低于Backup的90，于是VIP会漂移到Backup上。如果服务恢复正常，Master的优先级恢复到100，又会抢回VIP。这套机制非常实用，因为它真正做到了“以服务状态为第一优先”。

但如果脚本一开始就返回非0，weight -20生效后，Master优先级跌破Backup，VIP漂移，整个Nginx集群对外依然可用——这才是高可用该有的样子。

check_nginx.sh脚本我一般这样写：

bash复制#!/bin/bash
if [ "$(ps -C nginx --no-header | wc -l)" -eq 0 ]; then
    exit 1
fi
exit 0

注意，脚本必须要有可执行权限，否则Keepalived执行会失败：

bash复制chmod +x /etc/keepalived/check_nginx.sh

3.4 双节点完整配置示例：主备模式

将上面的片段整合成两份完整配置，方便直接抄作业。

Master节点（192.168.1.11）：

bash复制global_defs {
    router_id LB_MASTER
    enable_script_security
}

vrrp_script chk_nginx {
    script "/etc/keepalived/check_nginx.sh"
    interval 2
    weight -20
    fall 2
    rise 1
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.1.100/24 dev eth0 label eth0:1
    }
    track_script {
        chk_nginx
    }
}

Backup节点（192.168.1.12）：

bash复制global_defs {
    router_id LB_BACKUP
    enable_script_security
}

vrrp_script chk_nginx {
    script "/etc/keepalived/check_nginx.sh"
    interval 2
    weight -20
    fall 2
    rise 1
}

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 90
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.1.100/24 dev eth0 label eth0:1
    }
    track_script {
        chk_nginx
    }
}

两份配置唯一的区别就是router_id、state和priority，其他必须完全一致。有个容易被忽略的点：state MASTER并不代表它一定是Master，它只表示“我倾向于当Master”，最终谁能持有VIP，还是靠priority比大小。所以即使两台都误写成MASTER，priority高的一方才会真正持有VIP，另一方会以Backup身份运行。

3.5 Nginx + Keepalived组合场景配置技巧

在实际生产环境里，Nginx + Keepalived的组合非常常见。Nginx作为反向代理或负载均衡器，Keepalived为Nginx提供一个高可用的VIP入口。

这种架构下有一个经典的配置技巧：不要让Keepalived只检测Nginx进程存在，还要检测它是否真的能提供服务。比如你可以检测Nginx的监听端口是否开放：

bash复制#!/bin/bash
if ! nc -z 127.0.0.1 80; then
    exit 1
fi
exit 0

甚至更严格一点，直接请求一个健康检查URL，看返回状态码：

bash复制#!/bin/bash
HTTP_CODE=$(curl -o /dev/null -s -w "%{http_code}" http://127.0.0.1/health)
if [ "$HTTP_CODE" -ne 200 ]; then
    exit 1
fi
exit 0

这种做法的价值在于：有时候Nginx进程还活着，但配置出了问题，导致请求全部404或502。如果只检测进程，Keepalived会判定“正常”，VIP就不会漂移，用户访问的依然是坏掉的服务。所以，健康检查脚本的内容越接近真实用户访问路径，高可用的意义越大。

4. 启动验证与故障切换实测

4.1 启动Keepalived并确认VIP状态

配置文件写好之后，先做一次语法检查：

bash复制keepalived -t -f /etc/keepalived/keepalived.conf

如果输出没有报错，就可以启动服务了：

bash复制systemctl start keepalived
systemctl enable keepalived

启动之后，用ip addr查看VIP是否已经绑定到Master节点的网卡上。正常情况下，应该在Master上看到类似这样的输出：

code复制eth0:1: <BROADCAST, MULTICAST, UP, LOWER_UP> mtu 1500
    inet 192.168.1.100/24 scope global eth0:1

同时，用ps -ef | grep keepalived能看到Keepalived主进程在运行。此时可以验证一下从外部是否能ping通VIP，以及通过VIP访问Nginx是否正常：

bash复制ping -c 3 192.168.1.100
curl -I http://192.168.1.100

这一步是整个部署的关键验证点，VIP通了、服务通了，你才算真正完成了一半的部署。

4.2 故障切换实测：停掉Master节点

接下来进行故障切换演练，这是高可用集群部署后最不该省的一步。我的习惯是分三个层级模拟故障：

第一层，停掉Nginx服务。此时Keepalived的健康检查脚本应该检测到Nginx进程不存在，触发优先级降低，VIP从Master漂移到Backup：

bash复制# 在Master上执行
systemctl stop nginx
# 等待几秒后，在Backup上查看
ip addr | grep 192.168.1.100

第二层，直接停掉Keepalived服务：

bash复制systemctl stop keepalived

第三层，模拟整机宕机：

bash复制poweroff

每次演练后都去Backup节点上确认VIP是否出现，再通过VIP去访问Nginx，看是否依然能响应。

我见过很多团队部署完Keepalived就不管了，从来不做切换演练，结果真出故障的时候发现VIP压根没漂移，或者漂移了但业务访问不了。这种“假高可用”比没有高可用更害人。所以每次部署，我都会强制要求做一次完整的故障切换演练，并且把过程记录下来。

4.3 抓包确认VRRP报文交互

如果你想深入验证VRRP协议的工作机制，最直观的方式是在节点上抓包。用tcpdump抓取组播地址224.0.0.18上的报文：

bash复制tcpdump -i eth0 vrrp -n

正常情况下，你应该能看到Master节点持续发送VRRP广播报文，内容大致是：

code复制22:14:33.123456 IP 192.168.1.11 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 1s, length 20

当Master故障时，这个报文会消失，然后Backup节点开始发送自己的广播报文，优先级变为100，VIP随之漂移。通过抓包，你可以清晰地看到整个切换过程，这对排查“为什么VIP不飘”的问题非常有帮助。

抓包是排查网络问题最好的手段，比看日志直观多了。如果两边的VRRP报文互相收不到，优先检查防火墙是否放行了组播流量、网卡是否配置正确。

4.4 配置开机自启与系统服务托管

Keepalived作为基础设施组件，必须保证开机自启。如果是yum安装的，systemd服务会自动注册，直接执行：

bash复制systemctl enable keepalived

如果是源码编译安装的，需要手动创建服务文件。在/usr/lib/systemd/system/keepalived.service中写入：

ini复制[Unit]
Description=Keepalived
After=network-online.target
Wants=network-online.target

[Service]
Type=forking
PIDFile=/var/run/keepalived.pid
ExecStart=/usr/local/keepalived/sbin/keepalived -D
ExecReload=/usr/bin/kill -HUP $MAINPID
ExecStop=/usr/bin/kill -TERM $MAINPID

[Install]
WantedBy=multi-user.target

然后执行systemctl daemon-reload和systemctl enable --now keepalived。需要注意，源码安装的PID文件路径可能不同，根据实际情况修改PIDFile指向即可。

另外，还有一个细节值得提醒：Keepalived在配置变更后，重新加载配置不要用systemctl restart，建议用systemctl reload keepalived，或者执行kill -HUP $(cat /var/run/keepalived.pid)。这样不会中断VIP，切换过程对业务无感知，只在内存中重新加载配置，能最大程度减少对在线服务的影响。

5. 常见问题与排查技巧实录

5.1 两个节点同时持有VIP：脑裂问题

这是Keepalived部署里最危险的情况——Master和Backup同时认为自己是Master，同时持有VIP，导致流量同时打到两台机器上，引起严重的数据不一致或服务异常。

产生脑裂的根本原因是：两个节点互相收不到VRRP心跳报文，于是各自开始“夺权”。常见诱因包括：

• 防火墙屏蔽了组播地址224.0.0.18的流量
• 交换机开启了端口隔离，二层不通
• 网卡故障或链路中断
• 两台机器的virtual_router_id不一致

排查方法很简单，分别在两台机器上执行：

bash复制tcpdump -i eth0 vrrp -n

如果其中一台抓不到另一台的VRRP报文，说明网络路径有问题。还有一种快速验证方法：在两台机器上互相ping对方的物理IP，如果ping不通，链路肯定有问题。

处理脑裂的通用做法是：在健康检查脚本中增加一个“仲裁”操作，当节点发现自己不再是唯一的VIP持有者时，主动释放VIP。不过更推荐的做法是从根源排查网络问题，毕竟Keepalived本身不提供防脑裂的完整机制。

5.2 配置没问题但VIP一直不出现

一个经典场景是：Backup节点配置完全正确，priority也正常，但VIP就是起不来。这种情况多半是Backup节点上已经有一个IP和VIP冲突了，或者网卡没有正确绑定VIP。

用ip addr show dev eth0查看网卡当前的所有IP地址。如果发现VIP已经被某个进程占用，可能是之前故障切换后没有正常释放。此时在Backup上执行：

bash复制ip addr del 192.168.1.100/24 dev eth0

如果VIP本身没被占用，那就检查防火墙。Keepalived默认使用VRRP组播，CentOS 7默认防火墙firewalld是会拦截组播报文的。所以要在两个节点上都放行：

bash复制firewall-cmd --permanent --add-rich-rule='rule protocol value="vrrp" accept'
firewall-cmd --reload

Ubuntu的ufw则执行：

bash复制ufw allow proto vrrp from any to any
ufw reload

这一步非常关键，很多新手部署失败，十有八九都是因为防火墙拦了VRRP报文。

5.3 服务恢复后Master抢不回VIP

有些场景下，Master故障恢复后，VIP并不会自动回到Master上，而是继续留在Backup上。这其实是正常现象，取决于你的配置策略。

Keepalived默认是支持“抢占”的，即当Master恢复且priority更高时，它会主动把VIP抢回来。但如果你的配置里加了nopreempt参数，就变成了非抢占模式，Master恢复后不会自动抢回VIP，需要等待Backup主动释放或者手动干预。

bash复制vrrp_instance VI_1 {
    state BACKUP
    nopreempt
    ...
}

非抢占模式在某些场景下是有意义的，比如数据库主从切换，你不想让VIP频繁来回漂移，避免引起连接闪断。但对大部分Web入口场景，建议保持默认的抢占模式，让高优先级节点尽快恢复接管。

如果你确认配置是抢占模式但VIP抢不回来，那就检查Master节点上的Keepalived日志，看是否有脚本检测失败导致优先级一直被压低：

bash复制tail -f /var/log/messages

5.4 Keepalived日志刷屏或看不到日志

日志是排查一切问题的基础。Keepalived的日志输出位置根据系统不同有所差异，CentOS 7通常输出到/var/log/messages，Ubuntu则可能输出到/var/log/syslog。

启动后如果发现日志刷屏，大量出现类似下面的内容：

code复制Keepalived_vrrp: VRRP_Instance(VI_1) Dropping received VRRP packet...

这种情况几乎可以断定是两个节点的auth_pass或者virtual_router_id不一致。VRRP报文校验失败就会丢弃，Backup收不到有效报文就会认为Master挂了，然后反复尝试抢占，形成刷屏。

如果完全看不到日志，先确认配置文件里加没加-D参数。如果是手动启动的，命令应该是：

bash复制keepalived -D -f /etc/keepalived/keepalived.conf

-D表示以详细日志模式运行，日志会打印更丰富的信息，排查问题的时候强烈建议开启。

5.5 常见问题速查表

我把这些年遇到的典型问题整理成一张速查表，方便你遇到问题时对号入座：

5.6 几个来自实操的避坑心得

最后聊几个很难从官方文档里学到的经验教训，都是我自己踩过坑之后总结的。

第一，虚拟IP不要和物理IP规划在同一个段但又不做区分。生产环境里，建议把VIP单独规划一个网段，比如物理IP是192.168.1.11/12，VIP用192.168.1.100。这样通过IP就能一眼分辨出哪个是服务入口，哪个是节点物理地址。如果所有IP混在一起，后期维护和排查会非常痛苦。

第二，健康检查脚本尽量保持简单。脚本越复杂，出bug的概率越高。我见过有人在脚本里连着做三次curl请求、又解析JSON、又写日志，结果脚本本身频繁超时，导致Keepalived误判服务故障。健康检查的本质是快速判断“活没活”，不是做全面的业务监控。复杂的监控应该交给Prometheus这类专业工具，Keepalived只需要做最基础的存活判断即可。

第三，切换演练一定要做，而且要定期做。Keepalived部署完不是终点，它需要持续验证。我建议每个季度至少做一次故障切换演练，记录下切换耗时、业务影响面、告警是否及时触发。不用等真出故障才交学费，演练成本低得多。

第四，配置变更要走流程，别随手改。Keepalived的配置变更直接关系到整个入口的可用性，一定要经过评审。我习惯在配置文件里加上注释说明变更人、变更时间、变更原因，方便后续查阅。配置文件和脚本还要纳入版本管理，万一出了问题能快速回滚。

总体来说，Keepalived是一款成熟稳定、部署简单的高可用工具，但它也是一把双刃剑——配置得当，它能帮你扛住单点故障；配置疏忽，它也可能在故障时“静默失职”。把VRRP的原理吃透，把健康检查脚本写好，把切换演练做扎实，这套东西才能真正成为你系统里可靠的一环。