Keepalived 完全指南

想象一个门童,他站在门口专门负责把客人带到正确的房间。Keepalived 就是这个"智能门童"------专门负责 LVS 集群中 VIP 的高可用,确保 Director 出问题时,备用 Director 能立即接手工作!


📑 目录

  1. [什么是 Keepalived?](#什么是 Keepalived?)
  2. 名词解释(命令与术语)
  3. [Keepalived 架构](#Keepalived 架构)
  4. [Keepalived 配置详解](#Keepalived 配置详解)
  5. [Keepalived 部署实战](#Keepalived 部署实战)
  6. [VRRP 状态转换](#VRRP 状态转换)
  7. 健康检查
  8. 常见问题与故障排查
  9. 最佳实践
  10. [同行软件对比与 Keepalived 配合应用](#同行软件对比与 Keepalived 配合应用)
  11. 总结
  12. 官方文档与参考

🎯 什么是 Keepalived?

核心概念

Keepalived 是一个基于 VRRP 协议的高可用解决方案,专门用于实现 LVS(Linux Virtual Server)集群中负载均衡器的高可用。

官方定义简述 (来源:keepalived.org):Keepalived 是用 C 编写的路由与高可用软件 ,通过 VRRP(Virtual Router Redundancy Protocol) 实现高可用,并可配合 LVS 做负载均衡与健康检查。高可用由 VRRP 状态机驱动;可与 BFD 集成以加快状态切换。权威配置参考为 keepalived.conf(5) 手册
故障切换
正常状态
处理请求
待命
无法服务
处理请求
Director 主

192.168.1.100

MASTER
客户端
Director 备

192.168.1.101

BACKUP
Director 主

❌ 故障
Director 备

✅ 接管 VIP

生活类比

  • VIP = 餐厅的总机电话号码
  • Keepalived = 智能转接系统
  • MASTER = 当前值班的前台
  • BACKUP = 备用前台,随时准备接电话
  • VRRP = 前台之间的通讯协议

Keepalived vs 其他 HA 方案

特性 Keepalived Heartbeat Corosync+Pacemaker
专注领域 LVS/VIP 高可用 通用 HA 完整集群解决方案
配置复杂度 ⭐ 简单 ⭐⭐ 中等 ⭐⭐⭐⭐ 复杂
资源管理 VIP/IPVS 多种资源 任意资源
适用场景 LVS Director HA 通用 HA 复杂集群
生活类比 专门管 VIP 的门童 多功能管家 整个公司管理层
同行软件对比一览(VIP/网关高可用与负载)
软件/方案 定位 与 Keepalived 的异同 典型组合
Keepalived VIP 高可用 + 可选 LVS 健康检查 本文主角;轻量、配置简单、VRRP 标准协议 LVS、Nginx、HAProxy、MySQL 等
Heartbeat 通用 HA(心跳 + 资源脚本/CRM) 不只管 VIP,可管服务、文件系统等;配置较复杂;多与 Pacemaker 搭配 双机热备、Pacemaker
Corosync + Pacemaker 完整集群资源管理 可管任意资源(VIP、服务、存储),支持多节点、约束、STONITH;学习曲线陡 数据库 HA、复杂集群
HAProxy(自身无 VIP 漂移) 负载均衡 只做流量分发,不做多机 VIP 协商;高可用需配合 Keepalived 等做 VIP Keepalived + HAProxy
Nginx(开源版) 反向代理/负载均衡 同单机多进程,无内置多机 HA;主备需靠 Keepalived 漂 VIP Keepalived + Nginx
商用负载均衡(F5、A10 等) 硬件/商用 LB 自带主备与健康检查,无需自建 Keepalived;成本高 独立部署

📖 名词解释(命令与术语)

以下对文档中出现的命令、配置项、概念做简要解释,并配上生活例子与「为什么」,便于记忆与理解。

常用命令

命令/名称 含义 说明 生活例子 为什么?
keepalived -t 测试配置文件 检查 keepalived.conf 语法,不启动服务 像「交卷前检查有没有错别字」 为什么先 -t?改完配置直接 start 若语法错误会启动失败,-t 可快速发现错误
keepalived -C 显示解析后的配置 输出当前生效的配置(含默认值) 像「看最终版排班表」 为什么有用?确认实际生效的 virtual_router_id、priority 等是否与预期一致
keepalived --dont-fork 前台运行 不 fork 到后台,便于看日志排障 像「不关前台灯,边看边调试」 为什么排障时用?日志直接打在当前终端,方便观察 VRRP 广播与切换
ip addr show eth0 查看网卡地址 看本机 IP 及是否绑有 VIP 像「看门口牌子上写的是谁的名字」 为什么看 VIP?MASTER 上应有 VIP,BACKUP 上不应有;切换后要确认 VIP 是否漂到对端
tcpdump -i eth0 vrrp 抓 VRRP 包 看本机是否收发 VRRP 广播 像「监听对讲机里有没有人在喊话」 为什么排障用?确认心跳是否发出、对端是否收到、优先级是否正确

配置项与概念

名词 含义 生活例子 为什么?
VRRP Virtual Router Redundancy Protocol,虚拟路由冗余协议 像「多个人共用一个工号,谁在岗谁接电话」 为什么用 VRRP?标准协议,多台设备可协商「谁当前持有 VIP」,无需自造轮子
virtual_router_id (VRID) 虚拟路由 ID,0--255,同一组必须相同 像「班组编号」:51 号班组的人只和 51 号班组的人抢主 为什么必须一致?不同 VRID 属于不同「虚拟路由器」,不会互相协商;两边不一致就成两个组,VIP 会乱
priority 优先级,1--255,大者为主 像「工号大小」:100 比 90 大,100 当 MASTER 为什么默认 100?中间值,便于一侧调高(主)一侧调低(备);差距建议 ≥20 避免同分
advert_int VRRP 广播间隔(秒) 像「每隔几秒喊一声:我还在当班」 为什么常用 1?间隔小则故障发现快;太小时网络负载略增,一般 1--3 秒
state MASTER/BACKUP 初始状态 像「上班第一天先填:主班/备班」 为什么实际由 priority 决定?最终谁当 MASTER 由优先级比较决定,state 只是启动时的「期望」,避免两边都以为自己是主
track_script 追踪脚本 脚本失败时降低本机优先级,让对端接管 像「前台生病就按铃,让备班顶上」
preempt / nopreempt 是否抢占 主恢复后是否立刻抢回 VIP 像「原主回来了,要不要立刻还他岗位」

健康检查类型对比(为什么选哪种?)

类型 说明 适用场景 为什么?
TCP_CHECK 只连端口 端口在即认为可用 最简单、开销小;不关心 HTTP 内容时够用
HTTP_GET 发 HTTP 请求、校验状态码 Web 服务 能发现「进程在但接口 500」的情况,比 TCP 更准
MISC_CHECK 自定义脚本 复杂逻辑(如查库、调接口) 脚本返回 0 认为成功,灵活但需自己写检查逻辑

🏗️ Keepalived 架构

工作原理

Keepalived组件
📡 VRRP Stack

虚拟路由冗余协议
👁️ Checkers

健康检查
⚖️ IPVS Wrapper

IPVS 包装器
🔄 VIP 漂移
✅ 后端健康检测
📋 IPVS 规则管理
🛡️ 高可用
⚖️ 负载均衡

核心组件

组件 功能 生活类比
VRRP Stack 实现 VRRP 协议,处理 VIP 漂移 前台之间的通讯系统
Checkers 检查后端服务器健康状态 健康检查员
IPVS Wrapper 管理 IPVS 规则 负载均衡规则管理员

VRRP 协议

VRRP (Virtual Router Redundancy Protocol) 是 Keepalived 实现高可用的核心协议。
👤 Client 🛡️ Backup Director 👑 Master Director 👤 Client 🛡️ Backup Director 👑 Master Director 正常状态 Master 故障 💥 广播我是 MASTER (Priority 100) 我是 BACKUP (Priority 90) 发送请求 停止广播 等待超时后成为 MASTER 发送请求

VRRP 优先级

状态 优先级范围 说明
MASTER 1-255 优先级最高的成为 MASTER
BACKUP 1-255 优先级较低的等待
默认值 100 Keepalived 默认优先级

⚙️ Keepalived 配置详解

配置文件结构

bash 复制代码
# 配置文件位置
/etc/keepalived/keepalived.conf

# 配置结构
global_defs          # 全局定义
vrrp_instance NAME    # VRRP 实例
virtual_server IP PORT # 虚拟服务(可选)

全局配置 global_defs

bash 复制代码
global_defs {
   notification_email {
     admin@example.com    # 告警邮件地址
     ops@example.com
   }
   notification_email_from keepalived@example.com
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id LVS_DEVEL    # 路由标识,唯一即可
   vrrp_skip_check_adv_addr
   vrrp_strict
   vrrp_garp_interval 0
   vrrp_gna_interval 0
}

VRRP 实例配置

bash 复制代码
vrrp_instance VI_1 {
    state MASTER           # 角色:MASTER 或 BACKUP
    interface eth0         # 网络接口
    virtual_router_id 51   # 虚拟路由 ID (0-255)
    priority 100           # 优先级 (1-255)
    advert_int 1           # VRRP 广播间隔(秒)

    authentication {
        auth_type PASS     # 认证类型
        auth_pass 1111      # 认证密码
    }

    virtual_ipaddress {
        192.168.1.100      # VIP 地址
    }

    track_script {
        chk_nginx          # 追踪脚本
    }
}

配置参数解析

参数 说明 示例 注意事项
state 初始状态 MASTER/BACKUP 实际由优先级决定
interface 绑定接口 eth0 VIP 将绑定到此接口
virtual_router_id VRID 51 同一 VRRP 组必须相同
priority 优先级 100 值越大越优先
advert_int 广播间隔 1 秒,越小切换越快但开销越大
virtual_ipaddress VIP 地址 192.168.1.100 可以有多个

为什么 track_script 的 weight 常设负数? 脚本失败时表示本机应用异常,应降低本机优先级,让 BACKUP 因优先级更高而接管 VIP;若设正数则失败后本机优先级反而升高,无法触发切换。

为什么 virtual_router_id 两边必须一样? VRID 标识「同一个虚拟路由器」;只有 VRID 相同的节点才会互相比较优先级、协商谁当 MASTER。若一边 51 一边 52,就变成两个互不相关的组,可能两台都认为自己是 51 组的 MASTER,导致 VIP 冲突或无法切换。


🚀 Keepalived 部署实战

环境拓扑

后端服务器
虚拟IP
LVS集群
💓 VRRP 心跳
🖥️ Director1

192.168.1.10

👑 MASTER

Priority: 100
🖥️ Director2

192.168.1.11

🛡️ BACKUP

Priority: 90
🌐 VIP: 192.168.1.100
🖥️ RealServer1

192.168.1.20
🖥️ RealServer2

192.168.1.21
🖥️ RealServer3

192.168.1.22

Director1 配置(MASTER)

bash 复制代码
# /etc/keepalived/keepalived.conf

global_defs {
   router_id LVS_DIR1
}

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
    }

    # 可选:健康检查脚本
    track_script {
        chk_httpd
    }
}

# HTTP 健康检查脚本(可选)
vrrp_script chk_httpd {
    script "killall -0 httpd && exit 0 || exit 1"
    interval 2
    weight -20
    fall 2
    rise 2
}

Director2 配置(BACKUP)

bash 复制代码
# /etc/keepalived/keepalived.conf

global_defs {
   router_id LVS_DIR2
}

vrrp_instance VI_1 {
    state BACKUP           # 初始状态为 BACKUP
    interface eth0
    virtual_router_id 51   # 与 MASTER 相同
    priority 90            # 优先级低于 MASTER
    advert_int 1

    authentication {
        auth_type PASS
        auth_pass 1111      # 与 MASTER 相同
    }

    virtual_ipaddress {
        192.168.1.100      # 与 MASTER 相同
    }

    track_script {
        chk_httpd
    }
}

vrrp_script chk_httpd {
    script "killall -0 httpd && exit 0 || exit 1"
    interval 2
    weight -20
    fall 2
    rise 2
}

配置 IPVS 规则(可选)

Keepalived 可以直接管理 IPVS 规则:

bash 复制代码
# 在 keepalived.conf 中添加
virtual_server 192.168.1.100 80 {
    delay_loop 6
    lb_algo rr
    lb_kind DR
    persistence_timeout 50
    protocol TCP

    real_server 192.168.1.20 80 {
        weight 1
        TCP_CHECK {
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }

    real_server 192.168.1.21 80 {
        weight 1
        TCP_CHECK {
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }

    real_server 192.168.1.22 80 {
        weight 1
        TCP_CHECK {
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
}

启动和测试

bash 复制代码
# 1. 安装 Keepalived(两个 Director 都执行)
yum install keepalived -y

# 2. 启动服务
systemctl enable keepalived
systemctl start keepalived

# 3. 在 Director1 查看 VIP
ip addr show eth0

# 应该看到:
# inet 192.168.1.10/24 brd 192.168.1.0 scope global eth0
# inet 192.168.1.100/32 scope global eth0  <-- VIP

# 4. 在 Director2 查看 VIP(应该没有)
ip addr show eth0

# 5. 测试故障切换
# 停止 Director1 的 Keepalived
systemctl stop keepalived

# 6. 在 Director2 查看 VIP(应该有 VIP 了)
ip addr show eth0

🔄 VRRP 状态转换

状态机图

启动
优先级非最高
优先级最高
收到 MASTER 的优先级降低
自己优先级降低
MASTER 超时
3次超时
恢复正常
Initialize
BACKUP
MASTER
Fault
拥有 VIP

响应 ARP 请求

定期广播 VRRP
等待 MASTER

监听 VRRP 广播

准备接管

抢占模式 Preempt

⏱️ Preempt 延迟
✅ 立即抢占

默认
🕐 延迟抢占

preempt_delay
🔄 快速切换
📌 平稳切换

抢占模式配置

bash 复制代码
vrrp_instance VI_1 {
    # ... 其他配置 ...

    # 抢占模式(默认启用)
    preempt

    # 抢占延迟(秒)
    preempt_delay 300
}
模式 说明 适用场景
preempt 高优先级节点立即抢占 高可用要求高
preempt_delay 延迟抢占,避免频繁切换 网络不稳定环境
nopreempt 不抢占,主从角色固定 维护窗口时使用

📊 健康检查

检查类型

👁️ 健康检查
🔌 TCP_CHECK
🌐 HTTP_GET
🔒 SSL_GET
📜 MISC_CHECK
连接端口检查
HTTP GET 请求
HTTPS GET 请求
自定义脚本

TCP_CHECK 示例

bash 复制代码
real_server 192.168.1.20 80 {
    weight 1
    TCP_CHECK {
        connect_port 80
        connect_timeout 3
        nb_get_retry 3
        delay_before_retry 3
    }
}

HTTP_GET 示例

bash 复制代码
real_server 192.168.1.20 80 {
    weight 1
    HTTP_GET {
        url {
            path /index.html
            status_code 200
        }
        connect_timeout 3
        nb_get_retry 3
        delay_before_retry 3
    }
}

MISC_CHECK 示例

bash 复制代码
# 使用脚本检查
real_server 192.168.1.20 80 {
    weight 1
    MISC_CHECK {
        misc_path "/usr/local/bin/check.sh 192.168.1.20"
        misc_timeout 5
    }
}

⚠️ 常见问题与故障排查

VIP 无法 ping 通



未开放
已开放
⚠️ VIP 无法 ping 通
MASTER 有 VIP?
📋 检查配置
防火墙规则?
🔥 开放 ICMP
🌐 检查网络连通性
检查 state & priority
检查网关配置

解决步骤

bash 复制代码
# 1. 确认 MASTER 有 VIP
ip addr show eth0 | grep 192.168.1.100

# 2. 检查 VRRP 广播
tcpdump -i eth0 vrrp

# 3. 检查防火墙
iptables -L -n | grep -E "ICMP|VRRP"

# 4. 开放必要的端口
iptables -I INPUT -p vrrp -j ACCEPT
iptables -I INPUT -p icmp --icmp-type echo-request -j ACCEPT

频繁切换

🔄 频繁切换
⏱️ 增加 advert_int
🌐 检查网络稳定性
🕐 调整 preempt_delay
📜 增加 track_script 延迟

解决方案

bash 复制代码
# 1. 增加广播间隔
advert_int 3

# 2. 添加抢占延迟
preempt_delay 60

# 3. 调整脚本检查间隔
interval 5

💡 最佳实践

生产环境配置建议

  1. 使用认证 :auth_type PASS + auth_pass,防止未授权设备加入同一 VRID 组
    为什么? 否则同一网段有人误配相同 VRID 会参与抢主,造成 VIP 乱漂。生活例子:对讲机要设频道,不能谁都能插话。
  2. 调整优先级差距 :主备至少差 20 分(如 100 vs 80)
    为什么? 差距太小或同分时,网络抖动可能导致反复抢主;track_script 降权时也要保证降完后仍明显低于对端。
  3. 配置抢占延迟 :preempt_delay 60--300 秒,避免主恢复后立刻抢回导致抖动
    为什么? 主短暂丢包后会丢 MASTER,若立刻抢占又抢回,可能和 BACKUP 来回切换。生活例子:原主回来先等几分钟再接班,避免刚交班又换人。
  4. 监控 VRRP 状态 :监控 MASTER/BACKUP、VIP 所在节点,异常告警
    为什么? 单靠 Keepalived 自身不提供集中监控,需用脚本或监控系统读状态、做告警。
  5. 测试故障切换 :定期停主节点 Keepalived,确认 VIP 漂到备、业务可用
    为什么? 不演练的话真故障时可能发现配置错误、防火墙或脚本问题。

检查清单

bash 复制代码
# 1. 配置文件语法检查
keepalived -t

# 2. 查看配置
keepalived -C

# 3. 测试启动(不后台运行)
keepalived --dont-fork

# 4. 查看日志
tail -f /var/log/messages | grep keepalived

# 5. 查看 VRRP 状态
cat /proc/net/vrrp/eth0

🔀 同行软件对比与 Keepalived 配合应用

Keepalived 配合其他软件的应用

Keepalived 只负责「谁持有 VIP」和可选「LVS 规则 + 健康检查」,实际业务由其他软件提供。以下为常见组合及 Keepalived 在其中的作用。

组合 配合软件 Keepalived 在其中的作用 典型场景
LVS + Keepalived LVS(ip_vs) 为 LVS Director 做主备:VIP 漂移 + 可选通过 virtual_server 配置 IPVS 规则与 RealServer 健康检查 四层负载均衡高可用,多台 Director 共享一个 VIP
Nginx + Keepalived Nginx 为 Nginx 做主备:两台 Nginx 绑定同一 VIP,主挂则备接管;不管理 Nginx 进程,需配合脚本或 systemd 启停 七层反向代理/HTTP 负载高可用
HAProxy + Keepalived HAProxy 与 Nginx 类似:VIP 漂移实现 HAProxy 主备,后端健康检查由 HAProxy 自身完成 四/七层负载、TCP 代理高可用
MySQL + Keepalived MySQL(主从或 MHA 等) 为「当前主库」绑 VIP:主库故障后由 MHA/脚本提升从库并漂 VIP,应用始终连 VIP 数据库读写入口高可用,应用不关心主从 IP
Redis + Keepalived Redis(主从/哨兵) 为当前 Redis 主节点绑 VIP;主切换后 VIP 漂到新主,应用连 VIP 即可 Redis 主从切换对应用透明
RabbitMQ + Keepalived RabbitMQ 为当前主节点绑 VIP,配合镜像队列或脚本实现主备切换 消息队列入口高可用

典型架构示意(LVS + Keepalived)

后端
LVS
Keepalived_主备
客户端
访问 VIP
💓 VRRP
👤 客户端
🛡️ Keepalived MASTER

VIP 192.168.1.100
🛡️ Keepalived BACKUP
⚖️ ip_vs 规则

DR/TUN/NAT
🖥️ RealServer 1
🖥️ RealServer 2

生活类比:Keepalived = 「谁举着总机号码牌」;LVS/Nginx/MySQL = 「真正接电话、干活的人」。号码牌(VIP)漂到哪台,流量就打到哪台。

选型小结(什么时候用 Keepalived?)

需求 更贴合的方案
只要 VIP 主备、简单双机 Keepalived
LVS Director 高可用 Keepalived + LVS(Keepalived 可配 virtual_server 管 IPVS)
Nginx/HAProxy 主备 Keepalived + Nginx/HAProxy(Keepalived 只做 VIP,应用层自己启停)
数据库/Redis 主库 VIP Keepalived + 主从/哨兵/MHA 等(脚本或外部逻辑提升主,Keepalived 漂 VIP)
多资源、多节点、需 STONITH/约束 Corosync + Pacemaker,或 Heartbeat + Pacemaker

🎯 总结

Keepalived 是 LVS 集群高可用的最佳选择,简单高效且专为 LVS 设计。

核心要点记忆口诀

  • Keepalived 专为 LVS,轻量级配置简单
  • VRRP 协议传心跳,优先级决定谁做主
  • preempt 慎用,避免频繁切换伤不起
  • 健康检查要配置,后端异常要剔除
  • 简单场景用它好,复杂集群用 Pacemaker

生活类比总结

  • VRRP = 前台之间的通讯协议
  • MASTER = 当前值班的前台
  • BACKUP = 备用前台,随时待命
  • VIP = 总机电话号码
  • 抢占 = 原主人回来后要不要让位

最后提醒:Keepalived 虽然简单,但也要做好监控!定期测试故障切换,确保 HA 真正可用!


📚 官方文档与参考

资源 链接/说明 用途
Keepalived 官网 keepalived.org 项目介绍与入口
配置手册 keepalived.conf(5) Keepalived Manpage 权威配置说明,推荐查阅
案例:VRRP 故障转移 Case Study: Failover using VRRP 故障转移配置示例
LVS / HA 相关 本仓库 LVS 负载均衡HA 高可用集群Heartbeat 指南 与 LVS、Heartbeat、Pacemaker 对比与配合
相关推荐
爱莉希雅&&&24 天前
LVS+Keepalived+DNS+Web+NFS 高可用集群项目完整部署流程
运维·nginx·dns·lvs·keepalived·nfs·ipvsadm
市安1 个月前
基于 LVS+Keepalived+NFS 的高可用 Web 集群构建与验证
运维·服务器·网络·lvs·keepalived·ipvsadm
遇见火星1 个月前
LVS+Keepalived+Nginx 高可用架构揭秘
nginx·架构·lvs·keepalived
云计算-Security2 个月前
基于 Keepalived 的 Redis 主备高可用架构设计与实现
redis·keepalived
Red丶哞2 个月前
LVS+Keepalived+HAProxy
lvs·keepalived·haproxy
m0_488777653 个月前
LVS+Keepalived群集
lvs·keepalived
siriuuus3 个月前
Linux keepalived 基础知识
linux·运维·服务器·keepalived
一周困⁸天.4 个月前
Keepalived双机热备
linux·运维·keepalived
神秘人X7075 个月前
Keepalived 高可用配置文档
linux·keepalived·高可用