Keepalived 高可用集群：从原理到企业级实践

一、高可用集群概述

高可用集群（High Availability Cluster）旨在通过冗余机制消除单点故障（SPoF），确保关键业务服务的连续可用性。根据功能，集群主要分为以下几类：

LB（负载均衡）：如 LVS、HAProxy、Nginx，用于分发请求，提升系统吞吐能力。
HA（高可用）：如数据库、Redis 集群，通过主备或双主模式保证服务不中断。
HPC（高性能计算）：通过并行计算解决复杂科学或工程问题。

系统可用性通常用 SLA（服务等级协议）衡量，计算公式为 A = MTBF / (MTBF + MTTR)，常见指标如 99.9%（每月停机约43分钟）、99.99%（约4.3分钟）等。

二、VRRP 协议核心原理

VRRP（虚拟路由冗余协议）是 Keepalived 的基石，用于解决静态网关的单点故障风险。

2.1 关键术语

虚拟路由器（Virtual Router）：由多个物理路由器组成的逻辑实体。
VRID：虚拟路由器标识，范围 0-255，同一虚拟路由器内所有节点必须一致。
VIP（Virtual IP）：对外提供服务的浮动 IP 地址。
VMAC：虚拟 MAC 地址，格式为 00-00-5e-00-01-VRID。
Master/Backup：主设备和备用设备，通过优先级（priority）决定角色。

2.2 工作机制

VRRP 通过周期性通告（心跳）维持主备状态，支持抢占和非抢占两种模式，并可配置简单字符或 MD5 认证确保通信安全。

三、Keepalived 详解

3.1 简介与架构

Keepalived 是 VRRP 协议的软件实现，最初为高可用 IPVS 服务设计。其核心组件包括：

VRRP Stack：负责 VIP 的通告与状态维护。
Checkers：对 Real Server 进行健康状态检测。
IPVS Wrapper：根据配置生成 IPVS 规则。
System Call & SMTP：支持状态转换时调用脚本及邮件通知。

3.2 安装与基础配置

环境准备需确保各节点时间同步（如使用 NTP/Chrony），并建议关闭防火墙和 SELinux。

主配置文件为 /etc/keepalived/keepalived.conf，由三部分组成：

全局配置（global_defs）：定义邮件通知、路由标识等。
VRRP 实例配置（vrrp_instance）：定义每个虚拟路由器。
LVS 配置（virtual_server）：定义虚拟服务器及后端 RS。

一个基础的 Master 节点配置示例如下：

bash 复制代码

! Configuration File for keepalived
global_defs {
   router_id KA1
}
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 {
        172.25.254.100/24 dev eth0
    }
}

四、核心功能与高级配置

4.1 工作模式

抢占模式（默认）：高优先级主机恢复后立即夺回 Master 角色，可能导致 VIP 频繁漂移。
非抢占模式（nopreempt） ：各节点均配置为 state BACKUP，高优先级主机恢复后不抢占，需配合 priority 区分主备。
抢占延迟（preempt_delay）：高优先级主机恢复后延迟指定时间（默认300秒）再抢占，平衡可用性与稳定性。

4.2 单播与多播

默认使用多播（如 224.0.0.18）通信。在跨网段或禁用多播的环境中，需配置单播：

bash 复制代码

unicast_src_ip 192.168.1.10
unicast_peer {
    192.168.1.20
}

注意：启用 vrrp_strict 时无法使用单播。

4.3 日志与子配置文件

启用详细日志需修改 /etc/sysconfig/keepalived，添加 KEEPALIVED_OPTIONS="-D -S 6"，并在 /etc/rsyslog.conf 中配置 local6.* /var/log/keepalived.log。

为便于管理，可使用 include 指令引入子配置文件：

bash 复制代码

include /etc/keepalived/conf.d/*.conf

五、企业级应用实践

5.1 结合 LVS 实现负载均衡高可用

Keepalived 原生集成了对 Linux Virtual Server (LVS, IPVS) 的管理能力，能够实现四层（传输层）负载均衡集群的高可用。该方案的核心是：Keepalived 不仅负责 VIP 的故障转移，还通过其 virtual_server 配置段直接定义和管理 LVS 的虚拟服务器及后端真实服务器（Real Server, RS）的健康检查。

5.1.1 架构原理

该方案通常采用主备模式：

主备 Keepalived 节点：运行 Keepalived 服务，通过 VRRP 协议协商并持有 VIP（如 172.25.254.100）。
LVS Director：Keepalived 节点同时作为 LVS 的负载均衡调度器（Director）。
后端真实服务器集群：一组提供实际服务的服务器（如 Web 服务器）。

5.1.2 配置步骤

1. 配置示例（DR 模式）

bash 复制代码

! Keepalived 配置文件节选 - LVS 虚拟服务器配置
virtual_server 172.25.254.100 80 {
    delay_loop 6                     # 健康检查间隔（秒）
    lb_algo wrr                      # 调度算法：加权轮询
    lb_kind DR                       # 工作模式：直接路由
    protocol TCP                     # 协议类型
    sorry_server 172.25.254.30 80    # 所有 RS 宕机时的备用服务器
# 定义第一个真实服务器
real_server 172.25.254.101 80 {
    weight 1                     # 权重
    TCP_CHECK {                  # TCP 健康检查
        connect_timeout 5        # 连接超时（秒）
        retry 3                  # 重试次数
        delay_before_retry 3     # 重试间隔（秒）
        connect_port 80          # 检查端口
    }
}
# 可继续添加更多 real_server 块
}

2. 关键配置说明

lb_kind：LVS 工作模式，常见有 DR（直接路由）、TUN（隧道）、NAT（网络地址转换）。DR 模式性能最佳，但要求 Director 与 RS 在同一二层网络。
lb_algo：调度算法，如 wrr（加权轮询）、lc（最少连接）、sh（源地址哈希）等。
real_server：定义后端真实服务器 IP 和端口，并配置健康检查机制（如 TCP_CHECK、HTTP_GET、SSL_GET）。

3. 后端 RS 配置要点（以 DR 模式为例）

配置 ARP 抑制 ：防止 RS 响应 VIP 的 ARP 请求，避免 IP 冲突。

bash 复制代码

# 在每台 RS 上执行
echo "1" > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo "2" > /proc/sys/net/ipv4/conf/lo/arp_announce
echo "1" > /proc/sys/net/ipv4/conf/all/arp_ignore
echo "2" > /proc/sys/net/ipv4/conf/all/arp_announce

在 lo 接口绑定 VIP ：使 RS 能够接收和处理目标为 VIP 的数据包。
bash 复制代码
```
# 在每台 RS 上执行
ifconfig lo:0 172.25.254.100 netmask 255.255.255.255 up
```
确保 RS 服务监听所有地址 （如 0.0.0.0）或 VIP。

5.1.3 工作流程

客户端请求发送到 VIP（172.25.254.100）。
主 Keepalived 节点（作为 LVS Director）根据调度算法将请求转发给选中的 RS。
RS 处理请求后，直接响应给客户端（DR 模式特点）。
Keepalived 持续对 RS 进行健康检查。若某 RS 失败，则将其从调度池中移除。
若主 Keepalived 节点故障，VIP 及 LVS 配置规则会随 VRRP 协议漂移到备节点，备节点接管负载均衡职责。

5.1.4 优势与注意事项

优势：
- 高性能：LVS 工作在四层，转发效率高。
- 高可用集成：Keepalived 统一管理 VIP 和 LVS 规则，故障切换自动、完整。
- 灵活的健康检查：支持多种协议和自定义脚本。
注意事项 ：
- 网络要求：DR 模式要求 Director 与 RS 在同一二层网络，TUN 模式需要隧道支持，NAT 模式需要 Director 具备 NAT 能力。
- 配置复杂度：相比 HAProxy 等七层负载均衡器，LVS 配置更底层，需要更多网络知识。
- 健康检查：需根据业务选择合适的健康检查方式（TCP/HTTP/SSL），并合理设置超时和重试参数。

5.2 双主模式

双主模式（Dual-Master Mode）是 Keepalived 中一种高级的高可用部署方式，通过在同一组节点上配置多个独立的 VRRP 实例，让每个节点在不同实例中分别扮演 Master 和 Backup 角色，从而实现互为主备、负载分担的效果。这种模式适用于需要同时为多个服务提供高可用，且希望充分利用节点资源的场景。

5.2.1 架构原理

双主模式的核心原理如下：

在同一台物理节点上定义两个（或多个）VRRP 实例，每个实例拥有独立的 virtual_router_id、priority 和 virtual_ipaddress。
节点 A 在实例 1 中为 Master，在实例 2 中为 Backup；节点 B 则相反，在实例 1 中为 Backup，在实例 2 中为 Master。
每个 VRRP 实例对应的 VIP 会分别由各自的 Master 节点持有，从而实现不同服务流量的分离与高可用。

5.2.2 配置步骤

1. 典型应用场景

Web 服务与数据库服务分离：节点 A 作为 Web 服务的 Master（VIP1），同时作为数据库服务的 Backup（VIP2）；节点 B 作为数据库服务的 Master（VIP2），同时作为 Web 服务的 Backup（VIP1）。
多业务域隔离：不同业务线使用不同的 VIP 和 VRRP 实例，实现逻辑隔离和故障域分离。
资源利用率提升：避免传统主备模式中 Backup 节点长期闲置，让所有节点都能承担部分生产流量。

2. 配置示例

以下配置展示如何在两台节点上实现 Web 服务（VIP: 172.25.254.100）和数据库服务（VIP: 172.25.254.200）的双主模式。

bash 复制代码

# 节点1（KA-Node1）配置：Web 主，DB 备
vrrp_instance VI_WEB {
    state MASTER
    interface eth0
    virtual_router_id 100
    priority 150
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass web_pass
    }
    virtual_ipaddress {
        172.25.254.100/24 dev eth0
    }
}
vrrp_instance VI_DB {
state BACKUP
interface eth0
virtual_router_id 200
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass db_pass
}
virtual_ipaddress {
172.25.254.200/24 dev eth0
}
}

bash 复制代码

# 节点2（KA-Node2）配置：Web 备，DB 主
vrrp_instance VI_WEB {
    state BACKUP
    interface eth0
    virtual_router_id 100
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass web_pass
    }
    virtual_ipaddress {
        172.25.254.100/24 dev eth0
    }
}
vrrp_instance VI_DB {
state MASTER
interface eth0
virtual_router_id 200
priority 150
advert_int 1
authentication {
auth_type PASS
auth_pass db_pass
}
virtual_ipaddress {
172.25.254.200/24 dev eth0
}
}

3. 关键配置说明

virtual_router_id：每个 VRRP 实例的唯一标识，同一实例在所有节点上必须相同，不同实例必须不同（如 100 和 200）。
priority：决定 Master 选举，数值越高优先级越高。在同一实例中，Master 节点的优先级应高于 Backup 节点。
virtual_ipaddress：每个实例对外提供服务的虚拟 IP，不同实例的 VIP 应属于不同网段或同一网段的不同地址。
authentication：同一实例的认证密码必须一致，不同实例建议使用不同密码以增强安全性。

5.2.3 工作流程

节点1 在 VI_WEB 实例中因优先级高（150）成为 Master，持有 VIP 172.25.254.100；在 VI_DB 实例中为 Backup。
节点2 在 VI_DB 实例中因优先级高（150）成为 Master，持有 VIP 172.25.254.200；在 VI_WEB 实例中为 Backup。
客户端访问 Web 服务时，流量走向 VIP 172.25.254.100，由节点1 处理；访问数据库服务时，流量走向 VIP 172.25.254.200，由节点2 处理。
若节点1 故障，VI_WEB 实例的 VIP 172.25.254.100 会漂移到节点2（此时节点2 同时成为两个实例的 Master），Web 服务由节点2 接管；数据库服务 VIP 172.25.254.200 仍由节点2 持有，不受影响。
故障恢复后，根据抢占模式设置决定是否回切。

5.2.4 优势与注意事项

优势：
资源利用率高：所有节点均承担生产流量，避免备份节点闲置。
故障隔离：单个节点故障仅影响其作为 Master 的实例，其他实例仍可由另一节点提供服务。
部署灵活：可根据业务重要性分配不同的优先级和 VIP。

注意事项 ：
- 网络规划：确保每个 VIP 在网络上可路由，且不与现有 IP 冲突。
- 性能考量：单个节点同时作为多个服务的 Master 时，需评估其资源（CPU、内存、网络）是否足够。
- 配置同步 ：双主模式下，两台节点上的 Keepalived 配置文件除了 state 和 priority 可能不同外，其他参数（如 virtual_router_id、advert_int、authentication）必须严格一致。
- 监控与告警：需要监控每个 VRRP 实例的状态，以便及时发现 VIP 漂移或角色异常。

5.3 结合 HAProxy 实现高可用负载均衡

Keepalived 与 HAProxy 结合是构建高可用 Web 负载均衡集群的经典方案。Keepalived 负责 VIP 的高可用漂移，HAProxy 负责七层负载均衡。

5.3.1 架构原理

该方案通常采用主备模式：

Keepalived 主备节点：运行 Keepalived 服务，通过 VRRP 协议协商 VIP（如 172.25.254.100）的归属。
HAProxy 双活：主备节点均安装并运行 HAProxy，配置相同的后端服务器列表。
VIP 漂移：当主节点故障时，VIP 自动漂移到备节点，备节点上的 HAProxy 接管流量。

5.3.2 配置步骤

1. 安装 HAProxy

bash 复制代码

# 在两台 Keepalived 节点上安装 HAProxy
yum install haproxy -y  # CentOS/RHEL
# 或
apt install haproxy -y   # Ubuntu/Debian

2. 配置 HAProxy（两台节点配置相同）

bash 复制代码

# /etc/haproxy/haproxy.cfg
global
    log /dev/log local0
    maxconn 4000
    user haproxy
    group haproxy
    daemon
defaults
mode http
log global
option httplog
option dontlognull
timeout connect 5000ms
timeout client 50000ms
timeout server 50000ms
listen webserver
bind 0.0.0.0:80
mode http
balance roundrobin
server web1 172.25.254.101:80 check
server web2 172.25.254.102:80 check

3. 配置 Keepalived 监控脚本

创建健康检查脚本，用于监控 HAProxy 进程状态：

bash 复制代码

# /etc/keepalived/scripts/check_haproxy.sh
#!/bin/bash
if ! killall -0 haproxy &> /dev/null; then
    exit 1
else
    exit 0
fi

赋予执行权限：chmod +x /etc/keepalived/scripts/check_haproxy.sh

4. 配置 Keepalived（主节点示例）

bash 复制代码

! Configuration File for keepalived
global_defs {
    router_id KA_MASTER
}
vrrp_script chk_haproxy {
script "/etc/keepalived/scripts/check_haproxy.sh"
interval 2
weight -30
fall 2
rise 2
}
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 {
172.25.254.100/24 dev eth0
}
track_script {
chk_haproxy
}
}

5. 备节点配置 ：只需修改 state BACKUP、router_id 和 priority（如 80）。

5.3.3 工作流程

正常运行时，主节点持有 VIP 172.25.254.100，客户端请求发送到该 VIP。
主节点上的 HAProxy 接收请求，按负载均衡算法分发给后端 Web 服务器。
Keepalived 每 2 秒执行一次 check_haproxy.sh 脚本检查 HAProxy 进程。
若主节点 HAProxy 进程异常（脚本返回非 0），主节点优先级降低（100-30=70），低于备节点优先级（80）。
VRRP 协议触发主备切换，VIP 漂移到备节点。
备节点上的 HAProxy 接管流量，服务不中断。

5.3.4 优势与注意事项

优势：
实现 HAProxy 自身的高可用，避免单点故障。
支持七层负载均衡，功能比 LVS 更丰富（如会话保持、健康检查、SSL 终止）。
配置相对简单，维护成本低。

注意事项：
需在两台节点上同步 HAProxy 配置文件。
确保内核参数 net.ipv4.ip_nonlocal_bind=1，允许绑定非本地 IP。
若使用非抢占模式，需将两节点 state 均设为 BACKUP。

5.3 VRRP Script：扩展应用监控

通过自定义脚本监控应用（如 Nginx、Haproxy）状态，动态调整节点优先级，实现应用层高可用。

定义脚本：

bash 复制代码

vrrp_script chk_haproxy {
    script "/etc/keepalived/scripts/check_haproxy.sh"
    interval 2
    weight -30
    fall 2
    rise 2
}

在实例中调用：

bash 复制代码

vrrp_instance VI_1 {
    ...
    track_script {
        chk_haproxy
    }
}

当脚本检测失败（返回非0）时，Master 节点权重降低，触发 VIP 向 Backup 节点漂移。

六、总结

Keepalived 凭借其基于 VRRP 的稳定心跳机制、灵活的配置模式（抢占/非抢占、单播/多播）以及强大的扩展能力（IPVS 集成、VRRP Script），成为构建高可用集群的核心工具之一。在实际部署中，需根据网络环境、业务需求合理选择工作模式，并配合完善的监控与日志，才能构建出真正可靠的高可用架构。