Keepalived 高可用集群部署与配置实践

Keepalived 高可用集群部署与配置实践

1. 概述

1.1 高可用集群

在服务器集群架构中，按功能可分为三类：

单点故障（Single Point of Failure）是可用性的最大威胁：任一关键组件失效即导致整个业务中断。高可用集群通过建立冗余机制解决这一问题，常见冗余模式有两种：

• 主备模式（active/passive）：一台承载业务，一台待命，通过心跳感知故障并接管。利用率约 50%。
• 双主模式（active/active）：两台同时承载不同业务，互为备份。利用率可达 100%，但要求每台节点具备承载全部业务的能力。

1.2 可用性度量

系统可用性通常以 SLA（Service-Level Agreement）指标衡量，计算公式：

A = MTBF / (MTBF + MTTR)

其中 MTBF 为平均无故障时间，MTTR 为平均修复时间。提高可用性的核心手段是降低 MTTR，即缩短故障恢复时间，Keepalived 的自动故障切换正是这一思路的典型实现。

1.3 Keepalived 功能定位

Keepalived 是 VRRP 协议在 Linux 用户空间的软件实现，最初设计目标是实现 LVS（IPVS）服务的高可用，通过脚本接口可扩展至 Nginx、HAProxy 等任意服务。其核心能力包括：

• 基于 VRRP 协议完成虚拟 IP（VIP）地址的自动漂移
• 为 VIP 所在节点生成并维护 IPVS 规则
• 对 IPVS 集群中的后端服务器（RS）进行健康状态检测
• 通过脚本调用接口影响集群事务，支撑非 LVS 场景的高可用

2. VRRP 协议

2.1 协议背景

VRRP（Virtual Router Redundancy Protocol，虚拟路由冗余协议）用于解决静态网关的单点风险。网络中所有主机将默认网关指向同一台路由器时，该路由器故障将导致全网断连。VRRP 将多台物理设备抽象为一台虚拟路由器，对外仅暴露虚拟 IP，由持有该 IP 的设备承担转发职责，故障时自动转移。

2.2 关键概念

2.3 工作原理

master 周期性向组播地址（默认 224.0.0.18，可自定义）发送通告报文，报文携带优先级等信息。backup 监听通告：

• 持续收到优先级更高的通告，则维持 backup 状态；
• 超过 3 个通告周期（3 × advert_int）未收到 master 通告，判定 master 故障，backup 升级为 master；
• 新 master 绑定 VIP 并发送免费 ARP 报文，通知网络中其他设备 VIP 对应的 MAC 已变更；
• 原 master 恢复后，在默认抢占模式下通过更高优先级的通告重新夺回 VIP。

3. 实验环境

实验在 VMware 虚拟化环境中进行，采用 NAT 网络模式：

部署前置要求：

• 各节点时间同步（chrony 或 ntp）；
• 关闭防火墙及 SELinux；
• 各节点间主机名可互通（通过 /etc/hosts，非必需但建议配置）。

4. 安装与配置结构

4.1 软件安装

[root@KA1 ~]# dnf install keepalived -y[root@KA1 ~]# systemctl enable --now keepalived.service[root@KA1 ~]# ps axf | grep keepalived2326? Ss0:00 /usr/sbin/keepalived-D2327? S0:00\_ /usr/sbin/keepalived-D

主配置文件为 /etc/keepalived/keepalived.conf，配置示例存放于 /usr/share/doc/keepalived/，系统服务单元的环境配置文件为 /etc/sysconfig/keepalived。

4.2 配置文件结构

keepalived.conf 由三大部分组成：

GLOBAL CONFIGURATION global_defs { } # 全局参数：邮件通知、router_id、组播地址 VRRP CONFIGURATION vrrp_script { } # 业务健康检查脚本定义 vrrp_instance { } # 虚拟路由器实例，一个实例对应一组主备节点 LVS CONFIGURATION virtual_server_group { } # 虚拟服务器组 virtual_server { } # IPVS 集群定义，用于 LVS 高可用

4.3 全局配置段

global_defs{notification_email{# 故障切换时的邮件收件人，可多行timinglee_zln@163.com}notification_email_from keepalived@KA1.timinglee.org smtp_server127.0.0.1 smtp_connect_timeout30router_id KA1# 节点唯一标识vrrp_skip_check_adv_addr# 跳过通告源地址检查，降低性能开销#vrrp_strict # 严格模式，生产不建议启用vrrp_garp_interval1# 免费 ARP 发送间隔vrrp_gna_interval1# 免费 NA 发送间隔（IPv6）vrrp_mcast_group4224.0.0.44# 自定义组播地址}

vrrp_strict 启用后，以下任一情况将导致服务无法启动：未配置 VIP、配置了单播邻居、在 VRRP v2 中配置 IPv6 地址。生产环境一般不建议启用。

5. 主备模式部署

5.1 MASTER 节点配置（KA1）

[root@KA1 ~]# vim /etc/keepalived/keepalived.confvrrp_instance WEB_VIP{state MASTER interface eth0 virtual_router_id51priority100advert_int1authentication{auth_type PASS auth_pass1111}virtual_ipaddress{172.25.254.100/24 dev eth0 label eth0:0}}

5.2 BACKUP 节点配置（KA2）

[root@KA2 ~]# vim /etc/keepalived/keepalived.confvrrp_instance WEB_VIP{state BACKUP interface eth0 virtual_router_id51# 与 KA1 保持一致priority80advert_int1authentication{auth_type PASS auth_pass1111# 同组节点密钥必须一致}virtual_ipaddress{172.25.254.100/24 dev eth0 label eth0:0}}

配置要点：

• virtual_router_id 在同一虚拟路由器内必须一致，在同一网络中必须唯一；
• priority 取值 1-254，主节点应高于备节点；
• auth_pass 为预共享密钥，仅前 8 位有效，同组节点必须相同，否则无法互认通告，可能导致双主冲突；
• VIP 可配置多个，支持指定网卡、掩码和标签，生产环境可配置上百个地址。

5.3 语法检查与生效

[root@KA1 ~]# keepalived -t -f /etc/keepalived/keepalived.conf[root@KA1 ~]# systemctl enable --now keepalived.service

5.4 故障切换验证

在 KA1 上抓取组播通告报文，确认 master 状态正常：

[root@KA1 ~]# tcpdump -i eth0 -nn host 224.0.0.4411:38:46.183386 IP172.25.254.50>224.0.0.44: VRRPv2, Advertisement, vrid51, prio100, authtype simple, intvl 1s, length2011:38:47.184051 IP172.25.254.50>224.0.0.44: VRRPv2, Advertisement, vrid51, prio100, authtype simple, intvl 1s, length20

模拟主节点故障并验证 VIP 迁移：

[root@KA1 ~]# systemctl stop keepalived.service[root@KA2 ~]# ifconfigeth0:0:flags=4163<UP,BROADCAST,RUNNING,MULTICAST>inet172.25.254.100 netmask255.255.255.0# VIP 已漂移至 KA2

VIP 的漂移机制：VIP 并非静态绑定于网卡，而是 keepalived 在成为 master 时动态添加、降级时删除的地址。切换完成后立即发送免费 ARP，通知交换机与客户端更新 ARP 缓存，否则数据包仍会发往旧 master 的 MAC 地址，切换实际不生效。vrrp_garp_interval 参数即用于控制该报文的时间间隔。

6. 抢占策略

6.1 抢占模式（默认）

优先级高的节点始终持有 VIP。master 恢复后自动发起抢占，夺回 VIP。适用于无状态服务，切换代价低。

6.2 非抢占模式

VIP 持有者只要通告正常，不做 VIP 迁移，避免主备频繁切换。适用于数据库主从等有状态服务。

vrrp_instance WEB_VIP{state BACKUP# 非抢占模式下所有节点均配置为 BACKUPinterface eth0 virtual_router_id51nopreempt# 启用非抢占priority100advert_int1...}

需注意：非抢占模式下所有节点必须配置为 BACKUP，若存在 MASTER 配置，该节点会按初始状态直接抢占 VIP。

6.3 延迟抢占

master 恢复后延迟指定秒数再抢占，为服务启动预留缓冲时间：

vrrp_instance WEB_VIP{state BACKUP interface eth0 virtual_router_id51preempt_delay10# 延迟 10 秒抢占priority100...}

6.4 三种模式对比

7. 业务服务健康检查

VRRP 仅检测 keepalived 进程与网卡状态，无法感知业务服务故障。当 Nginx 或 HAProxy 进程异常而 keepalived 正常时，VIP 不会迁移，请求仍被转发至故障节点，造成大面积服务不可用。vrrp_script 机制用于解决该问题。

7.1 检查脚本定义

[root@KA1 ~]# vim /etc/keepalived/scripts/check_nginx.sh#!/bin/bashkillall-0nginx# 检测 nginx 进程存活[root@KA1 ~]# chmod +x /etc/keepalived/scripts/check_nginx.shvrrp_script check_nginx{script"/etc/keepalived/scripts/check_nginx.sh"interval1# 检查周期 1 秒weight-30# 失败时优先级减 30fall2# 连续 2 次失败判定故障rise2# 连续 2 次成功判定恢复timeout2# 脚本执行超时user root}vrrp_instance WEB_VIP{state MASTER interface eth0 virtual_router_id51priority100advert_int1authentication{auth_type PASS auth_pass1111}virtual_ipaddress{172.25.254.100/24 dev eth0 label eth0:0}track_script{check_nginx# 关联检查脚本}}

7.2 权重机制

权重机制使 keepalived 的选举结果与业务服务状态绑定：业务故障时本机优先级降低，VIP 自动迁移至健康节点；备节点侧权重逻辑相反（成功加分）。两侧配合形成"健康者持有 VIP"的闭环。

7.3 与 HAProxy 组合部署

HAProxy 监听 VIP 地址提供服务，需先启用内核的 ip_nonlocal_bind 参数，允许绑定本机当前不存在的 IP：

[root@KA1+KA2 ~]# echo 'net.ipv4.ip_nonlocal_bind=1' >> /etc/sysctl.conf[root@KA1+KA2 ~]# sysctl -p[root@KA1+KA2 ~]# vim /etc/haproxy/haproxy.cfglisten webserverbind172.25.254.100:80 mode http server web1172.25.254.10:80 check server web2172.25.254.20:80 check

完整链路为：VIP（Keepalived 保证可用性）→ HAProxy（负载均衡）→ 双 Web 节点（健康检查），各层独立容错。

8. LVS 集群高可用

Keepalived 的原生场景：将 LVS 调度器（Director）部署为主备模式，master 故障时 VIP 与 IPVS 规则一并迁移至 backup，消除 Director 单点。

8.1 RS 端配置

LVS-DR 模式下，RS 需在 lo 接口配置 VIP（回包直接从 RS 返回客户端），同时必须抑制 ARP 响应，避免与 Director 争抢 VIP 的 ARP 请求：

[root@rs1+2 ~]# cd /etc/NetworkManager/system-connections/[root@rs1+2 ~]# cp eth0.nmconnection lo.nmconnection -p[root@rs1+2 ~]# vim lo.nmconnection[connection]id=lotype=loopback interface-name=lo[ipv4]method=manualaddress1=127.0.0.1/8address2=172.25.254.100/32[root@rs1+2 ~]# nmcli connection reload && nmcli connection up lo[root@rs1+2 ~]# vim /etc/sysctl.confnet.ipv4.conf.all.arp_ignore=1net.ipv4.conf.all.arp_announce=2net.ipv4.conf.lo.arp_ignore=1net.ipv4.conf.lo.arp_announce=2[root@rs1+2 ~]# sysctl -p

arp_ignore=1 表示仅应答目标 IP 为本机接口地址的 ARP 请求；arp_announce=2 表示通告时仅使用接口自身 IP 作为源地址。

8.2 Director 端配置

在主备节点上均配置 virtual_server 段，keepalived 通过 IPVS wrapper 自动生成 ipvs 规则：

[root@KA1 ~]# vim /etc/keepalived/keepalived.confvirtual_server172.25.254.10080{delay_loop6lb_algo rr# 轮询算法lb_kind DR# DR 模式protocol TCP real_server172.25.254.1080{weight1HTTP_GET{url{path / status_code200}connect_timeout1retry3delay_before_retry1}}real_server172.25.254.2080{weight1TCP_CHECK{connect_timeout5retry3delay_before_retry3connect_port80}}}

8.3 健康检查类型

Web 服务建议使用 HTTP_GET，可检测进程存活但返回 500 类故障。测试轮询效果时，应使用第三台客户端访问 VIP，避免在 Director 本机测试（本机访问走回环，无法反映真实调度）。

9. 双主模式

主备模式资源利用率约 50%。双主模式通过两个 vrrp_instance、两个不同 VRID，使两台节点分别成为不同 VIP 的 master，业务拆分互为主备。

KA1 配置：WEB_VIP 为 MASTER、DB_VIP 为 BACKUP：

vrrp_instance WEB_VIP{state MASTER interface eth0 virtual_router_id51priority100advert_int1authentication{auth_type PASS auth_pass1111}virtual_ipaddress{172.25.254.100/24 dev eth0 label eth0:0}}vrrp_instance DB_VIP{state BACKUP interface eth0 virtual_router_id52priority80advert_int1authentication{auth_type PASS auth_pass1111}virtual_ipaddress{172.25.254.200/24 dev eth0 label eth0:1}}

KA2 配置：WEB_VIP 为 BACKUP、DB_VIP 为 MASTER（priority 互换，VRID 52 对应的实例优先级为 100），并配置 preempt_delay 10 避免服务未就绪即抢回 VIP。

实现要点：

• 两个实例的 VRID 必须不同，否则相互冲突；
• 两个 VIP 对应不同业务，业务不重叠即不会相互抢占；
• 每台节点须具备承载全部业务的能力，以应对单节点故障；
• 配合 preempt_delay 为服务启动预留缓冲。