简介：Keepalived 1.2.13 源码包面向运维工程师、系统架构师及高可用方案学习者，用于搭建基于 VRRP 协议的服务故障自动切换环境。包内共 188 个文件，以 62 个 .h 头文件与 61 个 .c 源文件为核心，完整呈现 VRRP、健康检查、LVS 管理等模块的实现逻辑；另含 configure 构建脚本、keepalived.conf 示例配置、man 手册及 init 启动脚本等辅助文件，压缩包约 334KB，结构紧凑便于通读源码。已有 367 人学习下载。借助该版本可深入理解 VRRP 状态机、TCP/HTTP/ICMP 健康检查机制与虚拟服务器组配置方式，并结合示例配置快速完成主备切换实验，是研究 Keepalived 内部原理与部署实践的实用参考。
1. keepalived-1.2.13.tar.gz 到底解决什么问题：从源码包到高可用入口
手里拿到一个keepalived-1.2.13.tar.gz，很多人第一反应是「这不就是个老版本的压缩包吗」。但真正在生产里滚过一圈的人知道，这个 tar.gz 背后是一整套 Linux 高可用入口方案：用 VRRP 协议在多台机器之间漂移一个虚拟 IP，再配合 LVS 做四层负载均衡的健康检查。它解决的核心问题很朴素——当你的 Nginx、HAProxy 或者自研网关挂掉时，用户不该感知到，流量要自动切到备用节点。这个包适合两类人：一是要在内网自建高可用入口、又不想引入 Keepalived 之外重型组件的中小团队运维；二是需要理解 VRRP 心跳、抢占、脑裂这些底层机制，方便排查「VIP 漂移了但业务没起来」这类玄学问题的后端工程师。1.2.13 是个偏老的稳定分支，源码编译能让你精确控制编译选项和运行路径，代价是要自己处理依赖和 systemd 集成。
2. 编译前先想清楚：VRRP 状态机与 LVS 健康检查怎么配合
在动手./configure之前，得先明白这个包里的两个核心模块各自干什么，否则编译选项会选错，后面排错也没有方向感。
2.1 VRRP 实例的状态机：MASTER、BACKUP 与抢占
Keepalived 的高可用靠 VRRP 实现。每台机器上跑一个 VRRP 实例，实例有一个虚拟路由器 ID（virtual_router_id），同一个 VRID 的一组机器通过组播（默认224.0.0.18）互相发通告。状态机只有三个状态：MASTER、BACKUP、FAULT。初始时优先级（priority）最高的成为 MASTER，持有 VIP；其余是 BACKUP，持续监听通告。如果 BACKUP 在advert_int秒内收不到 MASTER 的通告，就认为对方挂了，自己升为 MASTER 并接管 VIP。
抢占（nopreempt）是个容易踩的点。默认是抢占模式：原来优先级高的机器恢复后，会把 VIP 抢回来。如果你的业务对连接中断敏感，频繁抢占会导致 TCP 连接反复断开，这时候就要考虑nopreempt，让恢复的节点保持 BACKUP，直到当前 MASTER 主动让出。但nopreempt只在state BACKUP下生效，写在 MASTER 上是不起作用的，这个细节后面避坑章节还会提。
2.2 LVS 健康检查：real_server 与 MISC_CHECK 的分工
Keepalived 不只是漂 VIP，它还能直接管理 IPVS 虚拟服务。配置里virtual_server段定义 VIP 和端口，下面挂多个real_server，每个 real_server 可以配TCP_CHECK、HTTP_GET、SSL_GET或MISC_CHECK。TCP_CHECK 只探端口通不通，HTTP_GET 能校验返回码和摘要，MISC_CHECK 则允许你挂一个自定义脚本，用退出码判断健康。
这里的关键是：VIP 漂移和 real_server 摘除是两套独立逻辑。VIP 漂移由 VRRP 决定，real_server 摘除由健康检查决定。常见误解是「VIP 切过去业务就好了」，但如果后端 real_server 本身没恢复，新 MASTER 上的 IPVS 表里可能还是带着坏节点，流量照样打过去。所以健康检查的delay_loop、connect_timeout、retry这几个参数要和业务启动时间对齐。
2.3 编译选项：哪些开关必须开，哪些可以关
1.2.13 的configure脚本支持不少开关，生产环境我一般会显式指定，避免依赖探测出意外结果。
# 解压并进入源码目录 tar -zxvf keepalived-1.2.13.tar.gz cd keepalived-1.2.13 # 配置编译选项 ./configure \ --prefix=/usr/local/keepalived \ --with-kernel-dir=/usr/src/kernels/$(uname -r) \ --disable-fwmark \ --disable-lvs-syncd--prefix决定安装路径，建议独立目录，方便回滚。--with-kernel-dir指向内核头文件，LVS 相关的 IPVS 头文件要从这里找，如果系统没装kernel-devel会直接报错。--disable-fwmark关掉防火墙标记支持，除非你用 iptables 给 LVS 打标记做持久化，否则不需要。--disable-lvs-syncd关掉连接同步守护，单播或小规模场景用不上，开了反而多一个进程要维护。
配置完成后make && make install。如果make阶段报openssl相关错误，说明系统缺openssl-devel，装上再重新configure。这一步没有后悔药，依赖没装全就反复configure是常态。
3. 从源码到 systemd：keepalived-1.2.13 的落地配置
编译安装只是把二进制放到了/usr/local/keepalived/sbin/keepalived，真正让它跑起来并接管 VIP，还需要配置文件、启动脚本和内核参数配合。
3.1 最小可用的 keepalived.conf 模板
下面这份配置是双机主备的最小骨架，MASTER 和 BACKUP 各一份，差异只在state、priority和nopreempt。
# /etc/keepalived/keepalived.conf (MASTER 节点) global_defs { router_id LVS_NODE_01 # 节点标识，双机不要重复 enable_traps # 开启 SNMP trap，可选 } vrrp_instance VI_1 { state MASTER # 本机初始状态 interface eth0 # 绑定物理网卡，必须真实存在 virtual_router_id 51 # VRID，同组必须一致 priority 100 # 优先级，MASTER 高于 BACKUP advert_int 1 # 通告间隔，单位秒 authentication { auth_type PASS auth_pass 123456 # 同组密码必须一致 } virtual_ipaddress { 192.168.1.100/24 dev eth0 # VIP 及绑定网卡 } } virtual_server 192.168.1.100 80 { delay_loop 6 # 健康检查间隔 lb_algo wrr # 加权轮询 lb_kind DR # 直接路由模式 persistence_timeout 50 # 会话保持时间 protocol TCP real_server 192.168.1.11 80 { weight 1 TCP_CHECK { connect_timeout 3 nb_get_retry 3 delay_before_retry 3 } } }router_id是日志里区分节点的关键，双机配成一样会让排错变成黑匣子。interface必须写实际承载 VIP 的网卡名，写错会导致 VIP 加不上。virtual_router_id范围 1 到 255，同网段内不同组不能冲突。priority差距建议大于 50，避免网络抖动时误切换。auth_pass只用于 VRRP 通告认证，不是业务密码，但同组必须一致。
virtual_server段的lb_kind常用 DR 和 NAT。DR 模式性能好，但要求 real_server 上配置 VIP 到 lo 接口并抑制 ARP 响应，否则会 ARP 冲突。NAT 模式配置简单，但 MASTER 会成为瓶颈。persistence_timeout对需要会话保持的业务很关键，设太短会导致用户请求被分到不同后端。
3.2 启动脚本与 systemd 单元
1.2.13 源码包里带了keepalived/etc/init.d/keepalived和keepalived/etc/sysconfig/keepalived，但现代系统用 systemd 更稳。我一般直接写一个 unit 文件。
# /etc/systemd/system/keepalived.service [Unit] Description=Keepalived High Availability After=network.target [Service] Type=forking ExecStart=/usr/local/keepalived/sbin/keepalived -D -f /etc/keepalived/keepalived.conf ExecReload=/bin/kill -HUP $MAINPID PIDFile=/var/run/keepalived.pid KillMode=process Restart=on-failure [Install] WantedBy=multi-user.target-D是详细日志，排错阶段必开，稳定后可以去掉。-f指定配置文件路径，不写会去默认路径找。KillMode=process保证重启服务时不会误杀子进程。Restart=on-failure让 keepalived 异常退出后自动拉起，但如果是配置错误导致反复重启，日志会刷得很快，需要先systemctl stop再改配置。
启动前先确认内核允许绑定非本地 IP：sysctl -w net.ipv4.ip_nonlocal_bind=1，并写入/etc/sysctl.conf。否则 keepalived 在 BACKUP 状态尝试绑定 VIP 时会失败。
3.3 验证 VIP 漂移和健康检查是否生效
配置完成后，验证分三步。第一步看 VRRP 状态：ip addr show eth0在 MASTER 上应该能看到 VIP，BACKUP 上看不到。第二步模拟故障：在 MASTER 上systemctl stop keepalived，观察 BACKUP 是否在advert_int秒内接管 VIP。第三步验证 real_server 摘除：停掉一个后端服务，看ipvsadm -Ln里对应条目是否被移除。
# 查看 IPVS 虚拟服务和真实服务器状态 ipvsadm -Ln # 查看 keepalived 日志中的 VRRP 状态迁移 journalctl -u keepalived -f | grep -i "state"ipvsadm -Ln输出里，ActiveConn和InActConn能反映流量分布。如果某个 real_server 一直显示weight 0，说明健康检查判定它不健康，但没被完全摘除，这时候要去看TCP_CHECK的超时和重试参数是不是太宽松。日志里Entering BACKUP STATE和Entering MASTER STATE是状态迁移的关键标记，配合时间戳能算出切换耗时。
4. 避坑与排查：keepalived-1.2.13 最常见的 5 个翻车现场
这一章全是血泪经验，每条都按「现象 → 原因 → 解决」写，遇到问题直接对号入座。
4.1 VIP 漂移了但业务不通
现象：MASTER 挂掉后 BACKUP 接管了 VIP，ip addr能看到地址，但客户端访问超时。
原因：BACKUP 上的 IPVS 表没有正确同步，或者 real_server 健康检查还没跑完第一轮，流量被转发到未就绪的后端。另一种可能是 BACKUP 所在机器的防火墙没放行 VIP 的流量。
解决：先ipvsadm -Ln确认虚拟服务和 real_server 条目存在且权重正常。再检查delay_loop是否设得太长，导致切换后健康检查还没执行。最后确认 iptables 或 firewalld 没有拦截 VIP 端口。如果是 DR 模式，还要检查 real_server 上的 lo 接口有没有配 VIP 以及 ARP 抑制。
4.2 双机同时持有 VIP（脑裂）
现象：两台机器ip addr都能看到 VIP，客户端请求时通时断。
原因：VRRP 组播被网络设备拦截，或者advert_int设得太短导致通告丢失，双方都认为对方挂了。也可能是auth_pass不一致，认证失败后各自为政。
解决：先抓包确认组播是否可达：tcpdump -i eth0 vrrp。如果组播不通，改用单播 VRRP（1.2.13 支持unicast_peer配置）。检查双机auth_type和auth_pass是否完全一致。适当调大advert_int，但不要超过 3 秒，否则故障发现太慢。生产环境建议加一个独立的仲裁链路或使用notify脚本做二次确认。
4.3 nopreempt 不生效
现象：配置了nopreempt，但原 MASTER 恢复后还是把 VIP 抢回去了。
原因：nopreempt只在state BACKUP的节点上生效。如果原 MASTER 配置的是state MASTER，它启动后会直接进入 MASTER 状态，根本不走抢占逻辑。
解决：把双机的state都设为BACKUP，靠priority决定谁先成为 MASTER。这样恢复的节点会保持 BACKUP，直到当前 MASTER 失效。注意nopreempt和state MASTER同时出现是无效组合，日志里不会有明显报错，只能靠行为判断。
4.4 健康检查脚本超时导致误摘
现象：后端服务明明正常，但 real_server 频繁被摘除又加回，流量抖动。
原因：MISC_CHECK脚本执行时间超过了connect_timeout，或者脚本内部有阻塞操作。TCP_CHECK的nb_get_retry和delay_before_retry乘积决定了总容忍时间，设太小会误判。
解决：把connect_timeout调到脚本最大执行时间的 2 倍以上。MISC_CHECK加warmup参数，给脚本一个预热时间。如果是 HTTP 检查，确认url路径返回的是 200 而不是 302 重定向，HTTP_GET默认不跟随重定向。
4.5 编译时报 kernel header 找不到
现象：./configure报Linux kernel headers not found或IPVS headers not found。
原因：系统没装kernel-devel或kernel-headers，或者--with-kernel-dir指向的路径不对。
解决：先uname -r确认内核版本，然后安装对应版本的kernel-devel。路径通常是/usr/src/kernels/$(uname -r)，如果该目录不存在，说明包没装对。CentOS 系用yum install kernel-devel，Ubuntu 系用apt install linux-headers-$(uname -r)。装完后重新configure，不要跳过make clean。
5. 进阶技巧：用 notify 脚本把切换动作变成可控流程
前面讲的都是 Keepalived 自己怎么切，但真实业务里，VIP 漂移只是第一步。数据库连接池要重建、缓存要预热、监控要打标，这些动作如果全靠人工，切换就变成了半自动。1.2.13 支持notify_master、notify_backup、notify_fault和notify_stop四个钩子，分别在状态进入 MASTER、BACKUP、FAULT 和停止时触发。用好这几个钩子，能把切换从「听天由命」变成「按剧本走」。
5.1 notify 脚本的触发时机与参数
notify_master在节点成为 MASTER 并添加 VIP 后执行，适合做「上线动作」：启动业务进程、挂载共享存储、注册到服务发现。notify_backup在节点降为 BACKUP 并移除 VIP 后执行，适合做「下线动作」：停止业务进程、释放资源、上报监控。notify_fault在健康检查失败导致进入 FAULT 时触发，适合做告警。notify_stop在 keepalived 进程停止时触发，适合做清理。
脚本接收三个参数：$1是组名（VI_1），$2是状态名，$3是优先级。脚本必须有可执行权限，且执行时间不能太长，否则会阻塞 VRRP 状态机。
5.2 一个可复用的 notify 脚本模板
#!/bin/bash # /etc/keepalived/notify.sh # 用法：在 vrrp_instance 中配置 notify_master "/etc/keepalived/notify.sh master" TYPE=$1 NAME=$2 STATE=$3 case $STATE in "MASTER") # 成为 MASTER：启动业务、挂载存储、注册服务 echo "$(date) - $NAME entering MASTER" >> /var/log/keepalived_notify.log systemctl start nginx # 如果有共享存储，在这里挂载 # mount /dev/vg0/data /data ;; "BACKUP") # 降为 BACKUP：停止业务、释放资源 echo "$(date) - $NAME entering BACKUP" >> /var/log/keepalived_notify.log systemctl stop nginx # umount /data ;; "FAULT") # 进入 FAULT：告警 echo "$(date) - $NAME entering FAULT" >> /var/log/keepalived_notify.log # 发送告警到监控系统 ;; *) echo "$(date) - $NAME unknown state: $STATE" >> /var/log/keepalived_notify.log exit 1 ;; esac exit 0脚本里systemctl start nginx和stop nginx是最简单的业务动作，实际场景可能更复杂。关键点是：MASTER 动作要幂等，重复执行不报错；BACKUP 动作要能容忍资源已经被释放的情况。日志一定要写，否则切换出问题时没有后悔药可查。
5.3 验证 notify 脚本是否按预期执行
配置好 notify 后，不要直接在生产上试。先在测试环境模拟：手动systemctl stop keepalived，观察 BACKUP 节点日志里notify_master是否触发，业务进程是否启动。再手动启动原 MASTER，观察notify_backup是否触发，业务进程是否停止。
# 实时查看 notify 日志 tail -f /var/log/keepalived_notify.log # 查看 keepalived 主日志中 notify 脚本的执行记录 journalctl -u keepalived | grep -i notify如果 notify 脚本没有执行，先检查脚本路径是否绝对路径、是否有可执行权限、SELinux 是否拦截。1.2.13 在 SELinux 开启的系统上，notify 脚本可能因为上下文不对被拒绝执行，临时setenforce 0可以验证，但生产环境应该用semanage添加策略而不是直接关闭。
5.4 参数速查表
| 参数 | 作用 | 建议值 | 备注 |
|---|---|---|---|
advert_int | VRRP 通告间隔 | 1 秒 | 太大故障发现慢，太小网络抖动敏感 |
priority | 节点优先级 | MASTER 100，BACKUP 90 | 差距大于 50 避免误切 |
virtual_router_id | VRID | 1-255 内唯一 | 同网段不同组不能冲突 |
delay_loop | 健康检查间隔 | 6 秒 | 根据业务启动时间调整 |
connect_timeout | 检查超时 | 3 秒 | 至少是脚本执行时间的 2 倍 |
nb_get_retry | 重试次数 | 3 次 | 配合 delay_before_retry 使用 |
persistence_timeout | 会话保持 | 50 秒 | 无状态服务可设 0 |
这张表是我每次配 Keepalived 都会翻出来对一遍的，参数之间有关联，不能孤立地调。比如advert_int和priority要一起看，delay_loop和connect_timeout要一起看。调完参数后，至少做一次完整的故障演练：停 MASTER、验证切换、恢复 MASTER、验证回切。演练通过再上生产，这是我这些年唯一没翻过车的习惯。希望帮到你。
本文还有配套的精品资源，点击获取
