24 - 高可用与集群基础（Keepalived + HAProxy / Corosync + Pacemaker）

前提条件

已完成 Web 服务、数据库、VPN 配置（Nginx 或 Apache2 + MariaDB 可用）
以 root 身份登录，或 ops 用户执行 sudo -i 切换至 root 环境
系统运行在 Debian 12 Bookworm
准备两台虚拟机：主节点 linuxdc1（192.168.1.100）+ 备节点 linuxdc2（192.168.1.101）
两台节点可互相 SSH 免密登录（用于集群通信）
VIP（虚拟漂移 IP）约定：192.168.1.200

全局参数

主节点 linuxdc1 / 192.168.1.100，备节点 linuxdc2 / 192.168.1.101
VIP 192.168.1.200，SSH 端口 2222，运维用户 ops

两种方案定位

维度	Keepalived + HAProxy	Corosync + Pacemaker
核心能力	L4/L7 负载均衡 + VIP 漂移	通用集群资源管理
适用服务	无状态 Web 前端	有状态服务（数据库、主从切换）
配置复杂度	低	高
依赖条件	两节点独立部署相同服务	需要 STONITH 或仲裁机制
推荐场景	Nginx / Apache2 前端高可用	MariaDB / PostgreSQL 故障切换

方案一：Keepalived + HAProxy（Web 前端高可用）

1. 两台节点均安装软件

apt update
apt install -y keepalived haproxy

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

cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.bak-$(date +%F)
vim /etc/haproxy/haproxy.cfg

最小化生产配置示例（负载均衡到两台后端 Nginx）：

global
    log /dev/log local0
    log /dev/log local1 notice
    chroot /var/lib/haproxy
    stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
    stats timeout 30s
    user  haproxy
    group haproxy
    daemon

defaults
    log     global
    mode    http
    option  httplog
    option  dontlognull
    option  forwardfor
    option  http-server-close
    timeout connect  5s
    timeout client  50s
    timeout server  50s

frontend http_front
    bind *:80
    default_backend web_backend

backend web_backend
    balance roundrobin
    option  httpchk GET /
    server node1 192.168.1.100:8080 check inter 2s rise 2 fall 3
    server node2 192.168.1.101:8080 check inter 2s rise 2 fall 3

# 可选：HAProxy 状态监控页
listen stats
    bind *:8404
    stats enable
    stats uri /stats
    stats refresh 10s
    stats auth admin:StrongPass123!

后端端口说明

HAProxy 监听 80，后端 Nginx 改为监听 8080，避免端口冲突。两台节点的 Nginx 均需修改监听端口：listen 8080;。

haproxy -c -f /etc/haproxy/haproxy.cfg    # 语法检查
systemctl restart haproxy
systemctl enable haproxy

检查点

haproxy -c -f /etc/haproxy/haproxy.cfg 输出 Configuration file is valid。ss -tuln | grep 80 显示 HAProxy 监听 80 端口。

3. 配置 Keepalived — 主节点（linuxdc1）

vim /etc/keepalived/keepalived.conf

vrrp_script chk_haproxy {
    script "killall -0 haproxy"    # 检查 haproxy 进程是否存活
    interval 2
    weight   -20                   # 检查失败则优先级降低 20
}

vrrp_instance VI_1 {
    state  MASTER
    interface ens33                # 替换为实际网卡名
    virtual_router_id 51           # 同一 VRRP 组必须一致
    priority  100                  # 主节点优先级高
    advert_int 1

    authentication {
        auth_type PASS
        auth_pass vrrp_secret_2024  # 两节点必须相同，生产改用强密码
    }

    virtual_ipaddress {
        192.168.1.200/24
    }

    track_script {
        chk_haproxy
    }
}

4. 配置 Keepalived — 备节点（linuxdc2）

配置与主节点相同，仅修改以下两处：

state    BACKUP      # MASTER → BACKUP
priority 80          # 100 → 80（低于主节点）

5. 启动并验证

两台节点均执行：

systemctl enable --now keepalived
systemctl status keepalived

在主节点确认 VIP 已绑定：

ip addr show ens33 | grep 192.168.1.200

检查点

主节点 ip addr show ens33 显示 192.168.1.200/24，备节点不显示该 IP。浏览器访问 http://192.168.1.200 能正常返回页面。

6. 故障切换测试

在主节点停止 Keepalived：

# 主节点执行
systemctl stop keepalived

在备节点确认 VIP 已漂移：

# 备节点执行
ip addr show ens33 | grep 192.168.1.200
# 应显示 192.168.1.200/24

浏览器访问 http://192.168.1.200 仍可正常访问（由备节点接管）。

恢复主节点：

# 主节点执行
systemctl start keepalived
# 因主节点 priority 更高，VIP 自动漂移回主节点（抢占模式默认开启）

检查点

主节点 Keepalived 恢复后，ip addr show ens33 再次在主节点显示 VIP，备节点 VIP 消失。/var/log/syslog | grep -i keepalived 中有 Entering MASTER STATE 记录。

方案二：Corosync + Pacemaker（有状态服务集群）

1. 两台节点均安装软件

apt install -y corosync pacemaker pcs

设置 hacluster 用户密码（两台节点相同）：

passwd hacluster
# 输入相同密码，如 HaCluster2024!

2. 初始化集群（在主节点执行）

# 认证两台节点
pcs host auth linuxdc1 linuxdc2 \
    -u hacluster -p HaCluster2024!

# 创建集群
pcs cluster setup ha_cluster linuxdc1 linuxdc2

# 启动并启用集群
pcs cluster start --all
pcs cluster enable --all

3. 基础配置（两节点场景）

# 两节点集群禁用 STONITH（无隔离设备时必须，生产环境应配置真实 STONITH）
pcs property set stonith-enabled=false

# 两节点无需 quorum
pcs property set no-quorum-policy=ignore

生产环境注意

stonith-enabled=false 仅适合实验环境。生产中若无 STONITH（节点隔离），脑裂时两个节点可能同时认为自己是主节点，导致数据损坏（对数据库尤其危险）。真实生产应配置 IPMI/iDRAC 等硬件隔离或使用云厂商提供的 STONITH 资源。

4. 添加集群资源

以 VIP + MariaDB 为例（确保两台节点的 MariaDB 已安装，使用共享存储或主从复制）：

# 创建 VIP 资源
pcs resource create vip IPaddr2 \
    ip=192.168.1.200 cidr_netmask=24 \
    op monitor interval=30s

# 创建 MariaDB 资源
pcs resource create mariadb systemd:mariadb \
    op monitor interval=30s

# 约束：vip 和 mariadb 必须在同一节点
pcs constraint colocation add mariadb with vip INFINITY

# 约束：先启动 vip，再启动 mariadb
pcs constraint order vip then mariadb

查看集群状态：

pcs status

5. 故障切换测试

# 将资源迁移到备节点测试
pcs resource move vip linuxdc2

# 查看状态
pcs status

# 测试完成后解除约束，恢复自动管理
pcs resource clear vip

检查点

pcs status 显示所有资源 Started，VIP 和 MariaDB 在同一节点运行。停止主节点后，pcs status 显示资源已迁移至备节点。

Keepalived 配置参数说明

参数	说明
`virtual_router_id`	VRRP 实例标识，同一组的主备节点必须一致（1–255）
`priority`	节点优先级，值越高越优先成为 MASTER（1–254）
`advert_int`	VRRP 心跳间隔（秒），默认 1 秒
`auth_type PASS`	VRRP 认证方式，`PASS` 为简单密码认证
`weight`	`vrrp_script` 检查失败时优先级的变化量（负值表示降低）

HAProxy 负载均衡算法说明

算法	配置值	适用场景
轮询	`balance roundrobin`	后端性能相近的无状态服务
最少连接	`balance leastconn`	长连接服务（数据库代理、WebSocket）
源 IP 哈希	`balance source`	需要会话保持的应用
URI 哈希	`balance uri`	缓存服务器，相同 URI 固定路由到同一后端

实践任务

在两台虚拟机上配置 Keepalived + HAProxy，实现 VIP 192.168.1.200 漂移，浏览器访问 VIP 确认负载均衡正常
停止主节点 Keepalived，确认 VIP 漂移到备节点，访问不中断
恢复主节点 Keepalived，确认 VIP 漂移回主节点（抢占行为）
（可选进阶）搭建 Corosync + Pacemaker 集群，添加 VIP 资源，测试 pcs resource move 手动迁移

自测问题

1. Keepalived 的 virtual_router_id 和 priority 参数分别代表什么？

virtual_router_id 是 VRRP 实例的组标识（1–255），同一高可用组的所有节点必须配置相同的值，用于区分同一网段中的不同 VRRP 组。若两组 Keepalived 使用相同 virtual_router_id 会相互干扰。priority 决定节点竞选 MASTER 的优先级（1–254，值越大越优先）。正常运行时 priority 最高的节点持有 VIP；当主节点故障时，存活节点中 priority 最高的接管 VIP；主节点恢复后，若 nopreempt 未设置（默认抢占），主节点会重新夺回 VIP。

2. HAProxy 的 balance roundrobin 和 leastconn 的区别是什么？

roundrobin 按顺序依次将请求分配给后端服务器，每台服务器获得相同数量的请求，适合请求处理时间相近、后端性能均等的无状态服务（如静态文件服务）。leastconn 将新请求发送给当前活跃连接数最少的后端服务器，适合请求处理时间差异较大或需要长连接的服务（如数据库代理、WebSocket），能有效避免某台服务器因慢请求堆积而过载。

3. Corosync + Pacemaker 中 no-quorum-policy=ignore 适用于什么场景？

仲裁（quorum）要求集群中超过半数节点存活才能执行资源操作，防止脑裂。对于三节点及以上的集群，此策略有重要意义。但两节点集群中，若一个节点故障，存活节点只占 50%，不满足 quorum 要求，资源将无法启动，高可用失去意义。因此两节点集群必须设置 no-quorum-policy=ignore，允许单个存活节点独立运行资源。这是两节点集群的固有局限，生产中建议使用三节点以上集群或配置外部仲裁（qdevice）来真正解决脑裂问题。

4. 如何确认 VIP 已成功漂移到另一节点？

# 方法一：检查网络接口地址（在两台节点分别执行）
ip addr show ens33 | grep 192.168.1.200

# 方法二：查看 Keepalived 日志
grep -i "entering master\|entering backup" /var/log/syslog | tail -10

# 方法三：从客户端角度验证（在宿主机执行）
ping 192.168.1.200
# 或通过 ARP 查看 VIP 对应的 MAC 地址变化
arp -n 192.168.1.200

VIP 漂移后，arp -n 192.168.1.200 显示的 MAC 地址会变为备节点网卡的 MAC 地址。

总结

Keepalived + HAProxy 是 Web 前端无状态高可用的轻量首选方案，部署简单、故障切换快（秒级）；Corosync + Pacemaker 适合需要精细资源编排的有状态服务集群，功能强大但配置复杂。两者均基于 VIP 漂移实现对客户端透明的故障切换。生产环境中建议结合监控告警和定期故障演练，验证高可用机制真实有效。