简介：Keepalived 1.2.13 源码压缩包面向网络运维工程师、系统管理员及对高可用架构感兴趣的中高级开发者，用于研究 VRRP 协议实现与服务故障自动切换机制。包内含 188 个文件，以 62 个头文件和 61 个 C 源文件为骨架，辅以配置模板、init 脚本、SSL 校验与健康检查相关文件，整体仅 334KB，便于快速回溯核心逻辑。已有 366 人学习下载，比较适合作为 Keepalived 二次开发或深度排查的参考样本。通过梳理源码目录中的核心调度、健康检查与 SNMP 扩展代码，并结合配置文件示例，可掌握虚拟 IP 漂移、服务状态探测、LVS 联动等关键特性的落地方式，快速搭建实验环境并理解各配置选项。
1. 收到旧包先别急着解压：先把需求理清楚
说实话，看到keepalived-1.2.13.tar.gz这个文件名，我就知道碰到的是一类很典型的场景——要么是在内网环境里给老系统做高可用，要么是接手了一个跑了好几年的遗留集群，需要补齐或升级组件。版本号停在 1.2.13，说明这套环境不是追新派，稳定和兼容才是第一位的。
Keepalived 是 Linux 服务端高可用方案里绕不开的一个组件，核心就干两件事：用 VRRP 协议做虚拟 IP 飘逸，配合 LVS 做负载均衡健康检查。你把它下载到手，通常是打算给 Nginx、HAProxy 或业务服务做一个主备切换，保证机器挂了、网线断了、服务假死了，虚拟 IP 能自动跑到备用节点上，前端访问不中断。
这篇文章我按实际部署的经验来讲，覆盖从解压、编译、配置主备、健康检查到排障的完整链路。适合第一次接触 Keepalived 的运维新手，也适合那些摸过但总是被脑裂、VIP 漂移不干净、服务起不来恶心过的老手。我用的就是 1.2.13 这个版本，在老系统上编译干净利落，过程和细节会尽量说透。
先把核心信息摆在这：
- 软件名：Keepalived 1.2.13
- 打包格式：tar.gz（源码包，需编译安装）
- 用途：VRRP 虚拟 IP 高可用、LVS 负载均衡健康检查
- 适用系统：CentOS 6/7、Ubuntu 14/16 等主流 Linux 发行版
2. 为什么是 1.2.13：版本选择的门道
2.1 老版本不等于老古董
很多人一看到 1.x 就觉得过时，但在 Keepalived 这个项目里，1.2.13 是一个口碑非常稳的分支版本。它不像 2.x 那样引入了大量新特性，但正因如此，它的行为非常可预期，配置格式稳定，网上能搜到的资料几乎可以一一对上，这对排障来说是巨大的优势。
我选择 1.2.13 还有一个现实原因：它对新老内核的兼容性做得比较好，尤其是在 CentOS 6 这种 kernel 2.6.32 的环境里，2.x 版本反而可能碰到编译或运行时的兼容问题。1.2.13 在这种老环境里表现得很低调，但很可靠，跑个两三年不出幺蛾子才是王道。
2.2 源码包和二进制包的区别
这里多说一句，为什么官方推荐用源码包而不是yum install keepalived。发行版的软件仓库里通常也有 Keepalived，但版本往往偏保守，而且默认编译参数未必贴你的场景。比如你要用track_script做自定义健康检查，仓库版本可能没启用；你想把日志输出到独立的日志文件，也需要编译时指定相关选项。
源码包的好处是编译参数自己说了算，依赖关系清晰，出问题了自己能完全掌控。而且像tar.gz这种格式是 Linux 世界最通用的源码分发格式，只要拿到包，任何发行版都能用同一套流程装起来。
3. tar.gz 解压与编译安装：一步一步来
3.1 解压命令拆解
先看这个最基础的命令：
tar -zxvf keepalived-1.2.13.tar.gz参数拆开解释：
-z：通过 gzip 解压，因为文件后缀是.gz-x：执行解压操作-v：显示解压过程，方便确认哪些文件被释放出来了-f：指定要解压的文件名，注意-f后面必须紧跟文件名
解压完成后，进入目录：
cd keepalived-1.2.13这里有个小习惯我建议你养成：先ls -l看看目录里的文件，确认有configure、Makefile.in、README这些文件，再继续后续操作。有些网上下载的包被改过名或者损坏了，看一眼能少走弯路。
3.2 编译前置条件检查
Keepalived 编译依赖两个库：openssl-devel和popt-devel。前者用于支持一些加密认证相关的功能，后者是一个命令行参数解析库。如果系统里没有，configure 阶段就会报错。
准备好依赖：
yum install -y gcc openssl-devel popt-devel如果是 Ubuntu/Debian 系：
apt-get install -y build-essential libssl-dev libpopt-dev3.3 configure 与编译参数选择
编译安装前先看一下 configure 的帮助，了解可用的选项：
./configure --help我推荐用下面这个组合，把 prefix 单独指定，方便后期管理：
./configure --prefix=/usr/local/keepalived --disable-lvs--disable-lvs是我个人比较常用的参数。如果只是做 VIP 漂移，不需要 LVS 后端健康检查，这个选项可以关掉，减少无用功能和潜在的依赖问题。但如果你确实要用 Keepalived 配合 LVS 做负载均衡，那就不要加这个参数。
configure 成功后会生成 Makefile，显示 summary 信息。检查一下输出里是否包含Use IPVS framework: No之类的提示，确认是否符合预期。
接着编译安装：
make && make install整个编译过程视机器性能而定，一般几十秒到几分钟。结束后 Keepalived 的可执行文件会安装在/usr/local/keepalived/sbin/keepalived。
3.4 安装后配置整理
这一步很容易被忽略，却是后期维护的关键。为了和系统服务框架对接，我习惯用符号链接把二进制和配置文件放到标准路径：
ln -s /usr/local/keepalived/sbin/keepalived /usr/sbin/keepalived ln -s /usr/local/keepalived/etc/keepalived/keepalived.conf /etc/keepalived/keepalived.conf ln -s /usr/local/keepalived/etc/sysconfig/keepalived /etc/sysconfig/keepalived ln -s /usr/local/keepalived/etc/rc.d/init.d/keepalived /etc/init.d/keepalived这样service keepalived start、systemctl start keepalived都能直接管理。如果你用的是 systemd 系统，也可以直接创建一个 service 文件，但符号链接的方式最简单直接。
4. 核心配置解析：主备切换与虚拟 IP 漂移
4.1 配置骨架
一套最简配置分为三块：global_defs、vrrp_instance、virtual_ipaddress。下面是我实际用过的一个主备实例配置，我把它简化到只剩核心参数：
global_defs { notification_email { admin@example.com } notification_email_from keepalived@localhost smtp_server 127.0.0.1 smtp_connect_timeout 30 router_id LVS_01 } 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.1.100/24 dev eth0 label eth0:1 } }对应备机配置基本一样，差别在state改为BACKUP，priority调低（例如 90），virtual_router_id必须保持一致。
4.2 关键参数的作用与原因
virtual_router_id：VRRP 报文的区分标志。主备之间这个值必须一样，否则两边各自为政，无法协商。priority：选举 MASTER 的依据，越大优先级越高。主备用不同的 priority，正常时主节点赢，备节点待命。advert_int：发送 VRRP 通告的时间间隔，单位秒。默认为 1 秒，也就是备节点每秒钟都在等主节点的心跳，超时 3 秒收不到就抢占 VIP。auth_pass：VRRP 认证密码，两边必须一致。注意这个只做基础校验，不提供强加密，同一广播域内都能看到。virtual_ipaddress：要漂移的虚拟 IP。备机平时不绑定这个 IP，一旦主节点失联，备节点会立即把 IP 配置到自己的网卡上并发送免费 ARP，通知交换机刷新 MAC 表。
提示：如果 Keepalived 所在机器还被防火墙管着，记得放行 VRRP 协议。VRRP 使用组播地址 224.0.0.18，协议号 112。iptables 拦了它，主备就互相收不到通告，两个节点同时认为自己是主，造成 VIP 在两台机器上同时出现，这就是著名的脑裂。
4.3 健康检查脚本：让服务假死也能触发切换
机器心跳正常不代表业务正常。假如 Nginx 进程卡死、端口无响应，Keepalived 默认是不管的。这时就需要track_script来自定义业务健康检查。
写一个检查脚本/etc/keepalived/check_nginx.sh：
#!/bin/bash if [ "$(pidof nginx)" ]; then exit 0 else exit 1 fi给脚本执行权限：
chmod +x /etc/keepalived/check_nginx.sh在配置中加入：
vrrp_script chk_nginx { script "/etc/keepalived/check_nginx.sh" interval 2 weight -20 } vrrp_instance VI_1 { ... track_script { chk_nginx } }这里每个参数都有讲究：
interval 2：每 2 秒执行一次脚本。weight -20：脚本失败时，priority 自动减 20。如果主节点 priority 为 100，失败后变成 80，低于备节点的 90，备节点立即切换为主，VIP 随之漂移。- 脚本返回非 0 就认为检查失败，这是 Shell 脚本的标准约定。
注意：健康检查脚本里尽量不要写复杂的逻辑，避免脚本执行过慢导致 Keepalived 主进程阻塞。实测下来，脚本执行时间建议控制在 1 秒以内。最后一定要用
chmod +x给执行权限，而且脚本头部要有#!/bin/bash。
4.4 单播模式
默认情况下，VRRP 走组播。如果网络环境不允许组播（比如某些云平台或者跨 VLAN 场景），可以改用单播模式，把对端 IP 显式写出来：
vrrp_instance VI_1 { ... unicast_src_ip 192.168.1.10 unicast_peer { 192.168.1.11 } }单播模式下，防火墙规则容易写得多一些，只需放行本机 IP 的对端 IP 之间的 UDP 协议，端口默认是 VRRP 使用的 112。
5. 常见问题与排查技巧实录
5.1 问题一：VIP 出现两台机器上（脑裂）
这是高可用场景里最危险的状态，两边同时持有 VIP，流量会乱七八糟。
排查思路：
- 先看两台机器网卡上是否都有 VIP：
ip addr show eth0检查是否出现相同的 VIP。 - 查看 Keepalived 日志，确认是否两边都显示进入 MASTER 状态：
tail -f /var/log/keepalived.log - 检查防火墙是否放行 VRRP。临时关掉防火墙测试：
systemctl stop iptables
如果发现默认的组播协议没被放行，让主备节点走到单播模式，把unicast_peer显式写出来，同时按对端 IP 开放 UDP 端口。
关键点：脑裂不能只靠 Keepalived 自身解决，它是一个监控项，需要你在外部部署脚本定期探测两边状态，发现脑裂立刻报警。
5.2 问题二：VIP 切换后服务不可用
很多时候 VIP 漂移成功了，但流量进来了服务不响应。原因通常是 VIP 绑定到了错误的网卡，或者防火墙规则没有同步。
一个快速定位方法：
ip addr show eth0 curl -I http://192.168.1.100如果 VIP 在 eth0 上，但服务绑定的是 eth1，那流量只会走进来却到达不了对应的监听端口。解决方式是调整interface参数，让 VIP 绑定到服务实际监听的网卡上。
另一个常见原因：切换后后端服务没有及时处理 ARP 缓存，导致交换机还拿着旧 MAC。Keepalived 在切换时会主动发送免费 ARP，但如果网络里启用了严格 ARP 过滤，需要额外配置：
net.ipv4.conf.all.arp_ignore = 1 net.ipv4.conf.all.arp_announce = 2这些参数通常需要配合 LVS 或者复杂网络环境才需要动，普通场景默认值即可。
5.3 问题三：服务状态正常但 Keepalived 一直切换
脚本检查的逻辑有误，或者脚本执行超时，常见于脚本中使用了sleep或者netstat这类命令，在特定环境里执行慢。排查时先手动执行脚本看返回码：
/bin/bash -x /etc/keepalived/check_nginx.sh echo $?返回 0 正常，返回非 0 就按脚本逻辑逐行排查。我踩过一次是因为脚本里用了grep -c，但pidof在系统里根本没装，导致每次都走到 else 分支，Keepalived 误判服务挂了。所以脚本里最好像这样用绝对路径：
/usr/sbin/pidof nginx这样至少不会因为 PATH 环境问题影响判断。
5.4 问题四：配置文件报错导致服务无法启动
Keepalived 对配置文件语法非常敏感。最常见的问题包括：
- 缺少大括号的配对
virtual_ipaddress段写了多余的空格或注释- 使用了不支持的关键字（不同版本支持范围不同，1.2.13 相对保守）
启动前先用命令做一次语法检查非常有帮助：
keepalived -t -f /etc/keepalived/keepalived.conf这个命令会输出配置解析结果，有错会直接打在第几行，节省大量排查时间。
注意：1.2.13 不支持某些 2.x 引入的配置项，比如
mcast_src_ip、nopreempt在不同版本里的行为也有些差异。如果你从别人那拷贝了一份新版本配置，记得对照版本差异检查。
5.5 问题五：keepalived 服务无法管理的困扰
有时候用service keepalived restart会提示找不到服务，那是因为上面的符号链接没做全，systemd 无法识别。如果不想用符号链接，可以写一个简短的 unit 文件放到/usr/lib/systemd/system/keepalived.service：
[Unit] Description=Keepalived Daemon After=network-online.target [Service] Type=forking ExecStart=/usr/local/keepalived/sbin/keepalived -D -f /etc/keepalived/keepalived.conf Restart=on-failure [Install] WantedBy=multi-user.target然后执行daemon-reload和enable --now keepalived即可。
5.6 常见问题速查表
| 现象 | 可能原因 | 排查命令 | 解决方案 |
|---|---|---|---|
| 两边都有 VIP | 防火墙拦了 VRRP | iptables -L | 放行 VRRP 或改单播 |
| 日志里不断 MASTER/BACKUP | 通告被丢弃或 priority 相差太小 | tail -f /var/log/keepalived.log | 检查网卡/组播/时延，拉开 priority 差距 |
| 切换后服务不通 | VIP 绑错网卡 | ip addr show | 改 interface 或服务监听 IP |
| 状态正常却切换 | 脚本检测逻辑错误 | bash -x 脚本; echo $? | 修脚本、使用绝对路径 |
| 服务无法启动 | 配置语法错误 | keepalived -t | 定位错误行修复 |
6. 实际部署中的一点经验
我个人在实际部署中最大的体会是，Keepalived 本身很简单，真正决定高可用效果的是你对业务的理解。判断节点存活不能只看进程在不在，还要看端口、看接口响应、看关键数据能否正常读写。实际做的时候，建议把健康检查脚本当成一个小型业务探活平台来设计，把端口检查、HTTP 状态码检查、日志异常检查都织进去。
再分享一个很实用的思路：不要把 VIP 切换的触发条件做得太灵敏。阻塞 1-2 秒的抖动就切换，会造成无谓的切换，日志里看起来像精神分裂。合理的做法是把检查间隔拉长一点，或者连续失败 N 次才触发，可以用两个 vrrp_script 叠加做联动。
生产环境里我还见过不少人忘了设置nopreempt参数，导致主节点恢复后 VIP 又切回去。默认配置下 Master 恢复后是允许抢占的，如果你的逻辑希望主节点恢复后不自动抢回，就在两边都加上：
vrrp_instance VI_1 { nopreempt ... }这个参数的含义是：即使本节点优先级更高，也不主动抢占，等当前 MASTER 出问题时再接管。在需要保持连接稳定的场景（比如数据库读写分离）非常有用。
最后再提一遍 tar.gz 解压这些基础命令——很多问题的根因其实在最开始的一步就埋下了。下载完源码包先校验一下完整性，看看文件大小、MD5 是否和官方一致，防止网络传输损坏。解压后先跑一遍./configure再看make，遇到错误别硬着头皮继续，先解决错误信息里提示的依赖。这些细节做到位，后面就会顺利很多。
本文还有配套的精品资源，点击获取
