云原生(Keepalived概述)

匀泪2026-02-13 8:28

一、高可用集群基础

1.1 集群核心类型

集群按功能分为四类，核心解决单点故障（SPoF: Single Point of Failure） 问题：

  • LB（负载均衡）：LVS/HAProxy/Nginx（http/upstream、stream/upstream），实现请求分发
  • HA（高可用）：针对数据库、Redis 等核心服务，保障服务持续可用
  • HPC（高性能计算）：用于大规模并行计算场景
  • 高可用核心：通过冗余机制解决单点故障，是后续 Keepalived 的设计基础

1.2 系统可用性指标

  • SLA（服务等级协议） ：企业与客户约定的服务品质 / 性能契约，核心衡量指标为可用性 A

  • 可用性公式 ：A=MTBF/(MTBF+MTTR)

    • MTBF：平均无故障时间
    • MTTR：平均故障恢复时间（高可用核心优化方向：降低 MTTR）

  • 常用可用性标准 （按每月停机时间统计）：

    可用性 每月停机时间 年度停机时间
    99.9% 43.2 分钟 8.76 小时
    99.95% 21.6 分钟 4.38 小时
    99.99% 4.32 分钟 52.56 分钟
    99.999% 25.92 秒 5.26 分钟

1.3 系统故障分类

  • 硬件故障：设计缺陷、设备损耗、自然灾害等不可抗因素
  • 软件故障：程序设计缺陷、Bug、配置错误等

1.4 高可用实现方案

核心为建立冗余机制，通过心跳检测实现节点状态同步，主要模式：

  1. 主 / 备（active/passive）：一主一备，主节点故障后备节点接管，主流模式
  2. 双主（active/active）：两个节点均为活动状态，分担业务，故障时互相接管
  3. 心跳检测 ：主备 / 双主节点间通过心跳报文同步状态，核心为VRRP 协议

1.5 VRRP（虚拟路由冗余协议）

1.5.1 核心作用

解决静态网关单点风险 ，是 Keepalived 的底层核心协议，分为物理层实现 （路由器、三层交换机）和软件层实现（Keepalived）。

1.5.2 核心术语
术语 说明
虚拟路由器 VRRP 构建的逻辑路由器，对外提供统一网关服务
VRID（虚拟路由器标识） 0-255，唯一标识一个虚拟路由器，同组节点必须一致
VIP（虚拟 IP） 虚拟路由器的对外服务 IP，是高可用的核心访问入口
VMAC（虚拟 MAC） 格式为 00-00-5e-00-01-VRID，与 VRID 绑定，替代物理 MAC
Master（主设备） 虚拟路由器中优先级最高的节点，接管 VIP 和业务
Backup（备用设备） 主节点故障后，优先级最高的备节点升级为主节点
Priority（优先级） 1-254，值越高优先级越高，主节点优先级高于备节点
1.5.3 核心技术特性
  1. 通告机制：主节点周期性发送心跳报文，包含优先级、VRID 等信息，备节点监听
  2. 工作方式
    • 抢占式：主节点恢复后，抢占回 VIP（默认模式，可能造成网络抖动）
    • 非抢占式：主节点恢复后，不主动抢占，由当前主节点继续提供服务
  3. 安全认证
    • 无认证：测试环境使用
    • 简单字符认证：预共享密钥，仅前 8 位有效
    • MD5：加密认证，生产环境推荐
  4. 工作模式
    • 主 / 备：单虚拟路由器，一主多备
    • 双主：两个虚拟路由器，节点互为主备（如节点 1 为 VRID1 主、VRID2 备，节点 2 反之）

二、Keepalived 核心部署

2.1 Keepalived 简介

  1. 本质 ：VRRP 协议的开源软件实现，原生为IPVS 服务提供高可用，后扩展至 Nginx/HAProxy/ 数据库等服务
  2. 官网 ：http://keepalived.org/
  3. 核心功能
    • 基于 VRRP 实现VIP 漂移，解决单点故障
    • 自动为 VIP 所在节点生成 IPVS 规则
    • 对 IPVS 集群的后端真实服务器（RS）做健康状态检测
    • 提供脚本调用接口，支持 Nginx/HAProxy 等第三方服务高可用
    • 发送故障通知（邮件 / 脚本）

2.2 Keepalived 架构

Keepalived 分为用户空间 和内核空间，核心组件集中在用户空间，与内核空间的 IPVS、NETLINK 交互。

2.2.1 用户空间核心组件
组件 核心作用
VRRP Stack 处理 VRRP 协议报文，实现 VIP 通告、状态切换
Checkers 对后端 RS / 第三方服务做健康状态检测
System Call 状态切换时调用外部脚本（如故障通知、服务启停）
SMTP 邮件通知组件，实现故障邮件告警
IPVS Wrapper 自动生成 / 删除 IPVS 规则，适配负载均衡集群
Netlink Reflector 网络接口交互，实现 VIP 的绑定 / 解绑
WatchDog 监控 Keepalived 自身进程，防止进程挂死
控制组件 解析 keepalived.conf 配置文件，加载配置
IO 复用器 优化网络 IO 的线程抽象，提升网络处理效率
内存管理组件 提供内存分配 / 释放等通用功能
2.2.2 内核空间
  • IPVS：实现负载均衡的内核模块
  • NETLINK：用户空间与内核空间的通信接口

2.3 环境准备

2.3.1 节点规划（示例）
节点 IP 地址 角色 备注
KA1 172.25.254.20 Master Keepalived 主节点
KA2 172.25.254.30 Backup Keepalived 备节点
VIP 172.25.254.100 虚拟 IP 对外服务入口
WebServer1 172.25.254.40 后端 RS 业务服务器
WebServer2 172.25.254.50 后端 RS 业务服务器
2.3.2 基础环境要求
  1. 时间同步：所有节点通过 ntp/chrony 同步时间，防止心跳检测超时
  2. 防火墙 / SELinux：关闭（或放行 VRRP 协议端口 / 组播地址）
  3. 主机名通信：建议通过 /etc/hosts 配置，实现节点间主机名解析（非必须）
  4. SSH 免密：节点间 root 用户 SSH 密钥认证，方便运维操作（非必须）

2.4 核心文件路径

文件类型 路径 说明
软件包名 keepalived 系统安装包名（yum/dnf 安装）
主程序 /usr/sbin/keepalived 启动程序
主配置文件 /etc/keepalived/keepalived.conf 核心配置，支持子配置文件引入
配置示例 /usr/share/doc/keepalived/ 官方示例配置，含各种场景模板
系统服务文件 /lib/systemd/system/keepalived.service systemd 管理的服务文件
服务环境配置 /etc/sysconfig/keepalived 服务启动参数配置
2.4.1 常见问题

RHEL7 中执行systemctl restart keepalived可能导致新配置不生效，且stop命令无法杀死进程，解决方案：

复制代码 
# 先强制杀死进程，再启动
pkill keepalived
systemctl start keepalived

RHEL9 已修复此问题。

2.5 安装步骤

以 RHEL/CentOS/RockyLinux 为例，使用 dnf/yum 安装：

复制代码 
# 安装
dnf install keepalived -y
# 启动并设置开机自启
systemctl start keepalived
systemctl enable keepalived
# 验证进程
ps axf | grep keepalived

正常启动会出现 2 个 keepalived 进程（主进程 + 子进程）。

2.6 Keepalived 核心配置

配置文件/etc/keepalived/keepalived.conf为类 C 语法 ，支持注释（!/#），核心分为三部分：

  1. GLOBAL CONFIGURATION：全局配置，对所有实例生效
  2. VRRP CONFIGURATION：VRRP 实例配置，定义虚拟路由器、VIP、主备关系
  3. LVS CONFIGURATION：IPVS 配置，定义负载均衡规则、后端 RS、健康检测
2.6.1 全局配置（global_defs）

核心配置项及说明，必配项标注为★：

复制代码 
! Configuration File for keepalived
global_defs {
    # 故障通知邮箱，可配置多个
    notification_email {
        594233887@qq.com
    }
    notification_email_from keepalived@KA1.timinglee.org  # 发件人地址
    smtp_server 127.0.0.1  # SMTP服务器地址，本地需安装sendmail/mailx
    smtp_connect_timeout 30  # SMTP连接超时时间（秒）
    router_id KA1.timinglee.org  # ★节点唯一标识，建议用主机名
    vrrp_skip_check_adv_addr  # 跳过同一路由器的通告报文检查，提升性能
    # vrrp_strict  # ★严格遵循VRRP协议，生产环境建议注释（与单播/VIP ping冲突）
    vrrp_garp_interval 1  # 免费ARP发送间隔（秒），更新网络ARP缓存
    vrrp_gna_interval 1  # IPv6免费邻居通告间隔（秒）
    vrrp_mcast_group4 224.0.0.18  # VRRP组播地址，默认224.0.0.18
}

关键注意 ：vrrp_strict启用后，无 VIP、配置单播、VRRPv2 有 IPv6 均会导致服务启动失败，且会禁用 VIP 的 ping 响应，生产环境建议注释。

2.6.2 VRRP 实例配置（vrrp_instance）

定义单个虚拟路由器，同组节点的 VRID、认证信息、VIP 必须一致 ，主备节点仅state和priority不同。

1. 主节点（MASTER）配置示例
复制代码 
vrrp_instance VI_1 {  # VI_1为实例名，自定义
    state MASTER  # 角色：MASTER/BACKUP
    interface eth0  # ★绑定的物理网卡，VIP会挂载到此网卡
    virtual_router_id 20  # ★VRID，0-255，同组一致
    priority 100  # ★优先级，1-254，主节点高于备节点（如备节点设80）
    advert_int 1  # 心跳通告间隔，默认1秒
    # 认证配置，同组一致
    authentication {
        auth_type PASS  # 认证类型：PASS（简单密码）/AH（IPSEC，不推荐）
        auth_pass 1111  # 预共享密钥，仅前8位有效
    }
    # 虚拟IP配置，支持多个VIP，可指定网卡/子网掩码
    virtual_ipaddress {
        172.25.254.100/24 dev eth0 label eth0:0  # VIP/掩码 网卡 别名
    }
}
2. 备节点（BACKUP）配置修改点

仅需修改 3 处，其余与主节点一致：

复制代码 
state BACKUP  # 角色改为BACKUP
priority 80  # 优先级低于主节点
# router_id 可改为KA2.timinglee.org（唯一即可）
3. 配置验证
复制代码 
# 检测配置文件语法，无报错则正常
keepalived -t -f /etc/keepalived/keepalived.conf
2.6.3 日志功能启用

默认 Keepalived 日志输出到 /var/log/messages，建议单独配置日志文件，方便排查问题：

  1. 修改服务启动参数

    vim /etc/sysconfig/keepalived
    KEEPALIVED_OPTIONS="-D -S 6" # -S 6指定日志设备为local6

  2. 配置 rsyslog，将 local6 日志定向到单独文件

    vim /etc/rsyslog.conf
    local6.* /var/log/keepalived.log # 新增此行

    重启服务

    systemctl restart keepalived rsyslog

    实时查看日志

    tail -f /var/log/keepalived.log

2.6.4 子配置文件引入（生产环境推荐）

当配置复杂（多实例 / 多 VIP）时，将配置拆分到子文件，通过include引入，提升可维护性：

复制代码 
# 创建子配置目录
mkdir /etc/keepalived/conf.d
# 主配置文件中添加引入语句
vim /etc/keepalived/keepalived.conf
# 在global_defs后添加
include /etc/keepalived/conf.d/*.conf
# 子配置文件编写（如router.conf）
vim /etc/keepalived/conf.d/router.conf
vrrp_instance VI_1 {
    # 内容同2.6.2的VRRP实例配置
}

三、Keepalived 企业级应用实战

3.1 单主架构（Master/Backup）

最常用的高可用架构，一主一备，主节点故障后备节点自动接管 VIP，核心要求：同组节点 VRID、认证、VIP 一致，主节点优先级更高。

3.1.1 完整配置
  • 主节点（KA1）：参考 2.6.1+2.6.2 的主节点配置
  • 备节点（KA2）：参考 2.6.1+2.6.2 的备节点配置
3.1.2 测试验证

  1. 查看 VIP 挂载 ：主节点执行ip addr，可见 eth0:0 网卡绑定 VIP；备节点无 VIP

  2. 心跳抓包：备节点抓包查看主节点心跳报文

    tcpdump -i eth0 -nn host 224.0.0.18

    可见主节点（172.25.254.20）周期性发送VRRP通告，prio 100

  3. 故障模拟：停止主节点 Keepalived 服务

    systemctl stop keepalived

  • 备节点日志会显示VRRP_Instance VI_1 Transition to MASTER STATE
  • 备节点执行ip addr，可见 VIP 挂载到 eth0:0
  • 恢复主节点服务，默认抢占模式下，主节点会重新接管 VIP

3.2 抢占模式与非抢占模式

3.2.1 抢占模式（默认）
  • 特点：主节点故障恢复后，立即抢占 VIP，恢复主角色
  • 问题：可能造成网络抖动（VIP 频繁漂移），影响业务
  • 适用场景：测试环境、对抖动不敏感的业务
3.2.2 非抢占模式（生产环境推荐）
  • 特点：主节点故障恢复后，不主动抢占 VIP，由当前主节点（原备节点）继续提供服务
  • 配置要求 ：所有节点的 state 必须设为 BACKUP ，通过优先级区分默认主备，添加nopreempt参数
配置示例（KA1，默认主节点，优先级 100）
复制代码 
vrrp_instance VI_1 {
    state BACKUP  # 必须为BACKUP
    interface eth0
    virtual_router_id 20
    priority 100  # 高优先级，默认成为主节点
    nopreempt  # ★启用非抢占模式
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        172.25.254.100/24 dev eth0 label eth0:0
    }
}
KA2 配置（备节点，优先级 80）

仅priority 80，其余与 KA1 一致，同样添加nopreempt。

3.2.3 抢占延迟模式（preempt_delay）

介于抢占与非抢占之间，主节点恢复后，延迟 N 秒再抢占 VIP，避免网络抖动，配置示例：

复制代码 
vrrp_instance VI_1 {
    state BACKUP
    priority 100
    preempt_delay 10  # 延迟10秒抢占（默认300秒）
    # 其余配置不变
}

要求：所有节点 state 为 BACKUP，禁用 vrrp_strict。

3.3 VIP 单播配置

3.3.1 背景

默认 Keepalived 通过组播 发送心跳报文，会向整个网络广播，造成网络拥塞；单播仅在主备节点间发送心跳，减少网络流量，生产环境推荐。

3.3.2 配置要求
  1. 禁用vrrp_strict（单播与严格模式冲突）
  2. 在 VRRP 实例中添加unicast_src_ip（本机 IP）和unicast_peer（对端 IP）
3.3.3 配置示例
主节点（KA1，172.25.254.20）
复制代码 
vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 20
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        172.25.254.100/24 dev eth0 label eth0:0
    }
    # 单播配置
    unicast_src_ip 172.25.254.20  # 本机物理IP
    unicast_peer {
        172.25.254.30  # 对端备节点IP，多备节点可添加多个
    }
}
备节点（KA2，172.25.254.30）
复制代码 
vrrp_instance VI_1 {
    state BACKUP
    priority 80
    # 其余配置同主节点
    unicast_src_ip 172.25.254.30
    unicast_peer {
        172.25.254.20
    }
}
3.3.4 单播验证
复制代码 
# 主节点抓包，查看单播心跳
tcpdump -i eth0 -nn src 172.25.254.20 and dst 172.25.254.30
# 可见周期性的VRRP通告报文，仅在主备节点间传输

3.4 故障通知脚本配置

Keepalived 状态切换（主→备 / 备→主 / 故障）时，自动触发脚本执行，实现邮件告警 / 短信通知，核心为 3 个通知钩子函数。

3.4.1 通知脚本类型
钩子函数 触发场景
notify_master 当前节点成为主节点时
notify_backup 当前节点转为备节点时
notify_fault 当前节点出现故障时
3.4.2 配置步骤
1. 编写邮件告警脚本
复制代码 
vim /etc/keepalived/mail.sh
#!/bin/bash
# 目标邮箱
mail_dest='594233887@qq.com'
# 邮件发送函数
mail_send() {
    mail_subj="$HOSTNAME 切换为$1状态，VIP漂移"
    mail_mess="`date +%F\ %T`: VRRP状态切换，$HOSTNAME 变为 $1 状态"
    echo "$mail_mess" | mail -s "$mail_subj" $mail_dest
}
# 状态判断
case $1 in
    master)
        mail_send master
        ;;
    backup)
        mail_send backup
        ;;
    fault)
        mail_send fault
        ;;
    *)
        exit 1
        ;;
esac
# 添加执行权限
chmod +x /etc/keepalived/mail.sh
2. 配置邮件服务（以 163 邮箱为例）

安装邮件工具并配置 SMTP：

复制代码 
# 安装依赖
dnf install mailx sendmail -y
systemctl enable --now sendmail
# 配置SMTP
vim /etc/mail.rc
# 新增以下内容
set smtp=smtp.163.com
set smtp-auth=login
set smtp-auth-user=你的163邮箱@163.com
set smtp-auth-password=你的163邮箱授权码
set from=你的163邮箱@163.com
set ssl-verify=ignore
# 测试邮件发送
echo "测试" | mail -s "Keepalived测试" 594233887@qq.com
3. Keepalived 配置中引入脚本

在 VRRP 实例中添加钩子函数，指定脚本路径：

复制代码 
vrrp_instance VI_1 {
    # 其余配置不变
    notify_master "/etc/keepalived/mail.sh master"
    notify_backup "/etc/keepalived/mail.sh backup"
    notify_fault "/etc/keepalived/mail.sh fault"
    # 开启脚本执行权限（全局配置）
    global_defs {
        enable_script_security  # 开启脚本安全
        script_user root  # 指定脚本执行用户为root
    }
}
4. 测试

停止主节点 Keepalived 服务，备节点会触发notify_master，主节点触发notify_fault，目标邮箱会收到告警邮件。

3.5 双主架构（Master/Master）

3.5.1 背景

单主架构中，备节点长期空闲，资源利用率低 ；双主架构通过两个虚拟路由器（不同 VRID），让两个节点互为主备，各自接管一个 VIP，分担业务，故障时互相接管对方 VIP。

3.5.2 核心原理
  • 节点 1：为 VRID1 的 Master、VRID2 的 Backup，接管 VIP1
  • 节点 2：为 VRID2 的 Master、VRID1 的 Backup，接管 VIP2
  • 每个 VIP 对应一个业务，节点各自处理自身 VIP 的业务，故障时对方接管
3.5.3 双主配置示例（两个节点）
节点 1（KA1）配置
复制代码 
# 全局配置省略，同单主架构
# 虚拟路由器1：VI_1，VRID50，KA1为主
vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 50
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        172.25.254.50/24 dev eth0 label eth0:0  # VIP1
    }
}
# 虚拟路由器2：VI_2，VRID60，KA1为备
vrrp_instance VI_2 {
    state BACKUP
    interface eth0
    virtual_router_id 60
    priority 80
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        172.25.254.60/24 dev eth0 label eth0:1  # VIP2
    }
}
节点 2（KA2）配置

与节点 1互为主备 ，仅修改state和priority：

复制代码 
# 虚拟路由器1：VI_1，KA2为备
vrrp_instance VI_1 {
    state BACKUP
    priority 80
    # 其余同节点1，VIP1=172.25.254.50
}
# 虚拟路由器2：VI_2，KA2为主
vrrp_instance VI_2 {
    state MASTER
    priority 100
    # 其余同节点1，VIP2=172.25.254.60
}
3.5.4 三主架构（拓展）

三个节点配置三个虚拟路由器，每个节点为一个虚拟路由器的 Master、另外两个的 Backup，实现三个 VIP 分担业务 ，核心为优先级交错：

  • 节点 1：VI_1（MASTER，100）、VI_2（BACKUP，80）、VI_3（BACKUP，60）
  • 节点 2：VI_1（BACKUP，60）、VI_2（MASTER，100）、VI_3（BACKUP，80）
  • 节点 3：VI_1（BACKUP，80）、VI_2（BACKUP，60）、VI_3（MASTER，100）

3.6 实现 IPVS 负载均衡的高可用性

Keepalived 原生支持 IPVS，可自动生成 IPVS 规则，对后端 RS 做健康检测，实现负载均衡 + 高可用 一体化，核心为virtual_server和real_server配置。

3.6.1 IPVS 核心配置语法
复制代码 
# 虚拟服务器配置：VIP+端口
virtual_server 172.25.254.100 80 {
    delay_loop 6  # 健康检测间隔（秒）
    lb_algo wrr  # 调度算法：rr(轮询)/wrr(加权轮询)/lc(最小连接)等
    lb_kind DR  # 集群模式：NAT/DR/TUN（大写），生产推荐DR
    protocol TCP  # 协议：TCP/UDP/SCTP
    persistence_timeout 0  # 持久连接时长，0为关闭
    sorry_server 172.25.254.30 80  # 所有RS故障时，备用服务器
    # 后端真实服务器1
    real_server 172.25.254.101 80 {
        weight 1  # 权重，值越高接收请求越多
        # TCP层健康检测
        TCP_CHECK {
            connect_timeout 5  # 连接超时（秒）
            nb_get_retry 3  # 重试次数
            delay_before_retry 3  # 重试延迟（秒）
            connect_port 80  # 检测端口
        }
    }
    # 后端真实服务器2
    real_server 172.25.254.102 80 {
        weight 1
        # 应用层健康检测（HTTP_GET）
        HTTP_GET {
            url {
                path /  # 检测的URL路径
                status_code 200  # 健康状态响应码
            }
            connect_timeout 1
            nb_get_retry 3
            delay_before_retry 1
        }
    }
}
3.6.2 健康检测方式
检测方式 检测层级 适用场景
TCP_CHECK 传输层（TCP） 所有 TCP 服务，如 HTTP/MySQL/Tomcat
HTTP_GET/SSL_GET 应用层（HTTP/HTTPS） Web 服务，检测 URL 返回码 / 内容
SMTP_CHECK 应用层（SMTP） 邮件服务
MISC_CHECK 自定义 调用外部脚本检测
3.6.3 LVS-DR 模式实战（单主 + IPVS）
1. 后端 RS 配置（DR 模式要求）

DR 模式下，VIP 需绑定到 RS 的回环网卡（lo），并关闭 ARP 响应，防止 VIP 冲突：

复制代码 
# 所有RS执行
# 绑定VIP到lo网卡
ip addr add 172.25.254.100/32 dev lo
# 关闭ARP忽略和通告
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
# 安装并启动Web服务
dnf install httpd -y
echo "RS1 - 172.25.254.101" > /var/www/html/index.html
systemctl start httpd
2. Keepalived+IPVS 配置

在单主架构的 Keepalived 配置中，添加virtual_server配置（主备节点配置一致）。

3. 测试验证
  • 正常访问 ：curl 172.25.254.100，会轮询返回 RS1/RS2 内容
  • RS 故障模拟：停止 RS1 的 httpd 服务，请求会全部转发到 RS2
  • 所有 RS 故障 ：请求会转发到sorry_server（备用服务器）
  • Keepalived 故障模拟：停止主节点 Keepalived，备节点接管 VIP 和 IPVS 规则，业务无中断
3.6.4 双主 + 多服务 IPVS 实战

实现HTTP（80 端口） 和MySQL（3306 端口） 双服务的双主高可用，两个节点各接管一个服务的 VIP，分担业务：

  • 节点 1：接管 HTTP VIP（172.25.254.100），为 MySQL VIP（172.25.254.200）的备
  • 节点 2：接管 MySQL VIP（172.25.254.200），为 HTTP VIP（172.25.254.100）的备
  • 每个 VIP 对应一个virtual_server配置，分别调度后端的 Web/MySQL RS

3.7 实现第三方应用的高可用性（VRRP Script）

Keepalived 通过VRRP Script 实现第三方应用（Nginx/HAProxy/MySQL） 的高可用，核心为脚本监控应用状态 ，并根据状态动态调整节点优先级，实现 VIP 自动漂移。

3.7.1 核心原理
  1. 定义监控脚本 ：检测应用是否运行（如端口监听、进程存在），脚本返回0 为健康 ，非 0 为故障
  2. 脚本关联优先级：故障时，节点优先级降低指定值（如 - 30），若低于备节点，VIP 漂移
  3. 恢复时，优先级恢复，非抢占模式下不主动抢占，抢占模式下延迟抢占
3.7.2 VRRP Script 配置步骤
1. 定义监控脚本（vrrp_script）

在global_defs后、VRRP 实例前定义，可被多个实例调用：

复制代码 
# 定义监控脚本，名称为check_haproxy
vrrp_script check_haproxy {
    script "/etc/keepalived/scripts/haproxy.sh"  # 监控脚本路径
    interval 1  # 检测间隔（秒）
    timeout 2  # 检测超时（秒）
    weight -30  # 故障时优先级减30（负值），健康时恢复
    fall 2  # 连续2次检测失败，标记为故障
    rise 2  # 连续2次检测成功，标记为健康
    user root  # 执行脚本的用户
}
2. 编写应用监控脚本

以监控 HAProxy 为例，检测 HAProxy 进程是否存在：

复制代码 
mkdir /etc/keepalived/scripts
vim /etc/keepalived/scripts/haproxy.sh
#!/bin/bash
# 检测HAProxy进程，killall -0仅检测进程是否存在，不杀死
/usr/bin/killall -0 haproxy
# 返回值：0=存在，1=不存在
chmod +x /etc/keepalived/scripts/haproxy.sh
3. VRRP 实例中调用脚本（track_script）

在需要监控的 VRRP 实例中，添加track_script，关联定义的脚本：

复制代码 
vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 50
    priority 100  # 初始优先级100，故障后变为70
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        172.25.254.100/24 dev eth0 label eth0:0
    }
    # 调用监控脚本
    track_script {
        check_haproxy
    }
}
3.7.3 测试验证
  1. 正常状态：HAProxy 运行，节点优先级 100，接管 VIP
  2. 故障模拟：停止 HAProxy 服务，systemctl stop haproxy
    • 脚本检测到故障，节点优先级变为 100-30=70
    • 备节点优先级 80>70，自动接管 VIP
  3. 恢复模拟：启动 HAProxy 服务，systemctl start haproxy
    • 脚本检测到健康，节点优先级恢复为 100
    • 非抢占模式下，备节点继续接管 VIP；抢占模式下，主节点延迟抢占
3.7.4 拓展场景

可通过 VRRP Script 监控任意应用，只需修改监控脚本：

  • Nginx ：killall -0 nginx 或 curl -s 127.0.0.1:80
  • MySQL ：mysql -uroot -p密码 -e "select 1"
  • 自定义业务：检测业务端口 / 日志 / 接口返回值

四、核心注意事项与生产建议

4.1 配置核心规范

  1. 同组 VRRP 实例的VRID、认证信息、VIP必须完全一致
  2. vrrp_strict生产环境务必注释，避免与单播、VIP ping、多 VIP 冲突
  3. 非抢占模式下，所有节点state必须设为BACKUP，仅通过优先级区分默认主备
  4. 单播配置必须禁用 vrrp_strict ，并正确配置unicast_src_ip和unicast_peer
  5. 配置文件语法错误会导致服务启动失败，务必用keepalived -t验证

4.2 网络与环境

  1. 所有节点时间同步，避免心跳检测因时间差超时
  2. 防火墙放行VRRP 协议 （UDP 112）和组播地址 224.0.0.18（组播模式）
  3. DR 模式下，后端 RS 必须绑定 VIP 到 lo 网卡 并关闭 ARP 响应
  4. 多网卡场景，VRRP 实例的interface需指定业务网卡，避免心跳走管理网卡

4.3 高可用优化

  1. 生产环境推荐非抢占模式 +抢占延迟，减少网络抖动
  2. 心跳间隔advert_int建议设为 1 秒，兼顾检测灵敏度和网络开销
  3. 健康检测fall/rise建议设为 2-3 次，避免误判
  4. 启用单播模式，减少网络拥塞，提升心跳可靠性
  5. 配置故障通知脚本，及时发现服务异常
  6. 复杂场景拆分子配置文件，提升可维护性

4.4 故障排查思路

  1. 查看 Keepalived 日志：tail -f /var/log/keepalived.log，定位状态切换 / 配置错误
  2. 检查进程状态：ps axf | grep keepalived，确认进程是否正常运行
  3. 检查 VIP 挂载：ip addr，确认 VIP 是否在预期节点
  4. 抓包验证心跳：tcpdump -i 网卡 -nn host 组播/单播IP，确认心跳报文是否传输
  5. 验证配置语法：keepalived -t -f 配置文件，排查语法错误
  6. 检查脚本执行：手动执行监控 / 通知脚本，确认脚本是否正常工作

4.5 集群拓展

  1. 单主架构可拓展为一主多备，备节点按优先级依次接管
  2. 双主架构可拓展为多主多备，通过多个 VRID 实现多 VIP 分担业务
  3. 结合IPVS+Keepalived，实现负载均衡 + 高可用一体化，替代 Nginx/HAProxy 单节点
  4. 结合VRRP Script，实现任意第三方应用的高可用，适配各种业务场景
相关推荐
弹简特2 小时前
【JavaSE-网络部分04】网络原理-传输层：UDP + TCP 可靠性三大核心机制（确认应答 / 超时重传 / 连接管理）
网络·tcp/ip·udp
运维闲章印时光2 小时前
企业跨地域互联:GRE隧道部署与互通配置
linux·服务器·网络
xixixi777772 小时前
太赫兹通信和可见光通信的区别对比
网络·应用·信号·无线·通信·太赫兹通信·可见光通信
加农炮手Jinx2 小时前
Flutter for OpenHarmony 实战：Injectable — 自动化依赖注入大师
网络·flutter·华为·harmonyos·鸿蒙
z10_142 小时前
住宅代理IP是什么？如何利用住宅代理做海外营销
网络·网络协议·tcp/ip
匀泪2 小时前
云原生(Keepalived实验设定)
服务器·网络·云原生
天荒地老笑话么2 小时前
NAT 下代理最佳实践：HTTP(S)_PROXY/NO_PROXY
网络·网络协议·http
通信大师2 小时前
Cat-M技术详解：5G前行中的低功耗广域网络之星
网络·5g
没有bug.的程序员2 小时前
容器网络深度探究：从 CNI 插件选型内核到 K8s 网络策略安全防护实战指南
java·网络·安全·kubernetes·k8s·cni·容器网络
热门推荐
01GitHub 镜像站点02Claude Code + GLM4.7 避坑指南：解决 Unable to connect to Anthropic services03openclaw配置教程（linux+局域网ollama）04UV安装并设置国内源05Linux下V2Ray安装配置指南06【软考经验分享】软考-中级-嵌入式备考07243 行 microGPT：把“训练 + 推理”拆到骨头里08AI 规范驱动开发“三剑客”深度对比：Spec-Kit、Kiro 与 OpenSpec 实战指南09Spring Flux方法总结10openclaw使用nginx反代部署过程 与disconnected (1008): pairing required解决