24. 高可用与集群基础

本章介绍 RHEL 9 上两种高可用方案：Keepalived（轻量级 VRRP 虚拟 IP 漂移，适合双机热备）和 Pacemaker/Corosync（完整集群资源管理框架，适合企业级多资源高可用）。高可用（HA）的核心目标是消除单点故障，确保服务在节点故障时自动切换，最大限度减少业务中断时间。

实验环境说明

本章需要至少两台节点。使用 VMware 克隆第一阶段完成的 linuxdc 快照，得到第二个节点：

节点	主机名	IP
主节点	`linuxdc`	`192.168.1.100`
备节点	`linuxdc2`	`192.168.1.101`
虚拟 IP（VIP）	—	`192.168.1.200`

24.1 前提条件

两台 RHEL 9 节点均已完成基础配置（第 1–9 章）。

两节点已配置 SSH 密钥免密互信（第 5 章）：

# 在 linuxdc 上执行
ssh-copy-id -p 2222 ops@192.168.1.101
ssh -p 2222 ops@192.168.1.101 "hostname"

两节点时间同步已配置（第 8 章），时间偏差 < 1 秒。

在两节点的 /etc/hosts 中添加互相解析（避免 DNS 依赖）：

# 两节点均执行
tee -a /etc/hosts << 'EOF'
192.168.1.100 linuxdc
192.168.1.101 linuxdc2
EOF

两节点均已切换至 root 环境执行（sudo -i）。

本章操作标注约定

标注 [两节点] 的命令须在 linuxdc 和 linuxdc2 各执行一次；标注 [主节点] 的命令仅在 linuxdc 执行。

24.2 Keepalived 配置（轻量级双机热备）

Keepalived 通过 VRRP 协议在主备节点间协商，主节点持有虚拟 IP（VIP），主节点宕机时 VIP 自动漂移到备节点，实现服务地址的无缝切换。

24.2.1 安装 [两节点]

dnf install -y keepalived

24.2.2 配置主节点（linuxdc，192.168.1.100）

tee /etc/keepalived/keepalived.conf << 'EOF'
global_defs {
    router_id linuxdc
    vrrp_skip_check_adv_addr
    vrrp_strict
}

vrrp_instance VI_1 {
    state  MASTER
    interface ens33           # 确认与实际网卡名一致
    virtual_router_id 51      # 同一 VRRP 组内必须相同（范围 1–255）
    priority 100              # 主节点优先级高于备节点
    advert_int 1              # 心跳广播间隔（秒）
    preempt                   # 主节点恢复后抢占 VIP（默认启用）

    authentication {
        auth_type PASS
        auth_pass linuxdc_vrrp  # 主备节点必须完全相同
    }

    virtual_ipaddress {
        192.168.1.200/24 dev ens33
    }
}
EOF

systemctl enable --now keepalived

24.2.3 配置备节点（linuxdc2，192.168.1.101）

tee /etc/keepalived/keepalived.conf << 'EOF'
global_defs {
    router_id linuxdc2
    vrrp_skip_check_adv_addr
    vrrp_strict
}

vrrp_instance VI_1 {
    state  BACKUP
    interface ens33
    virtual_router_id 51      # 与主节点相同
    priority 90               # 低于主节点（100），确保正常时主节点持有 VIP
    advert_int 1

    authentication {
        auth_type PASS
        auth_pass linuxdc_vrrp  # 与主节点相同
    }

    virtual_ipaddress {
        192.168.1.200/24 dev ens33
    }
}
EOF

systemctl enable --now keepalived

开放防火墙（VRRP 使用 IP 协议号 112）[两节点]：

firewall-cmd --permanent --add-protocol=vrrp
firewall-cmd --reload

24.2.4 验证 VIP 漂移

# [主节点] 确认 VIP 已绑定到 ens33
ip addr show ens33 | grep 192.168.1.200

# 从任意客户端 ping VIP（应持续通）
ping 192.168.1.200

# [主节点] 模拟故障：停止 keepalived
systemctl stop keepalived

# [备节点] 验证 VIP 漂移过来
ip addr show ens33 | grep 192.168.1.200

# [主节点] 恢复后 VIP 应漂回（因配置了 preempt）
systemctl start keepalived
ip addr show ens33 | grep 192.168.1.200

检查点

主节点 keepalived 停止后，备节点 ens33 出现 192.168.1.200/24；主节点恢复后 VIP 漂回主节点。

24.3 Pacemaker 集群配置（企业级 HA）

Pacemaker 是 RHEL 9 官方支持的完整集群资源管理器，配合 Corosync 实现节点间心跳通信，支持资源依赖、约束、故障策略和 STONITH 隔离，适合管理多类型资源的企业生产集群。

24.3.1 安装 [两节点]

dnf install -y pcs pacemaker corosync fence-agents-all

# 设置 hacluster 用户密码（两节点密码必须相同）
passwd hacluster

# 启用集群管理守护进程
systemctl enable --now pcsd

开放防火墙 [两节点]：

firewall-cmd --permanent --add-service=high-availability
firewall-cmd --reload

24.3.2 初始化集群 [主节点]

# 节点间认证（需要两节点的 hacluster 账户密码）
pcs host auth linuxdc linuxdc2 \
  -u hacluster \
  addr linuxdc=192.168.1.100 \
  addr linuxdc2=192.168.1.101

# 创建集群并命名
pcs cluster setup ha-cluster \
  linuxdc addr=192.168.1.100 \
  linuxdc2 addr=192.168.1.101

# 启动集群（所有节点）
pcs cluster start --all

# 设置开机自启
pcs cluster enable --all

24.3.3 基础集群配置 [主节点]

# 查看集群状态（两节点均应显示 Online）
pcs status

# 实验环境禁用 STONITH（生产必须启用！见下方警告）
pcs property set stonith-enabled=false

# 双节点集群特殊仲裁策略
pcs quorum update wait_for_all=0 last_man_standing=1

STONITH 生产警告

STONITH（Shoot The Other Node In The Head）是防止"脑裂"（Split-Brain）的关键机制：节点间通信中断时，STONITH 通过带外管理通道（IPMI/iLO/iDRAC 等）强制停止异常节点，确保共享资源不被双写。生产集群必须配置 STONITH（如 fence_ipmilan、fence_apc），否则脑裂时两节点同时持有资源，对数据库等有状态服务将造成不可逆的数据损坏。此处禁用仅为实验演示。

24.3.4 创建集群资源 [主节点]

# 创建虚拟 IP 资源
pcs resource create vip \
  ocf:heartbeat:IPaddr2 \
  ip=192.168.1.200 \
  cidr_netmask=24 \
  nic=ens33 \
  op monitor interval=30s

# 查看资源状态
pcs status resources

# 验证 VIP 已绑定到某节点
ip addr show ens33 | grep 192.168.1.200

添加 Web 服务资源并配置与 VIP 的关联约束：

# 创建 Apache 资源
pcs resource create webserver \
  ocf:heartbeat:apache \
  httpd=/usr/sbin/httpd \
  configfile=/etc/httpd/conf/httpd.conf \
  op monitor interval=30s

# 约束1：VIP 与 webserver 必须在同一节点（colocation）
pcs constraint colocation add webserver with vip INFINITY

# 约束2：VIP 必须先于 webserver 启动（order）
pcs constraint order vip then webserver

# 查看最终集群状态
pcs status
pcs constraint list

检查点

pcs status 显示两节点均 Online，资源 vip 和 webserver 均显示 Started，运行在同一节点上。

24.3.5 测试故障切换 [主节点]

# 记录当前资源运行节点
pcs status resources

# 模拟主节点故障（将其置为 standby）
pcs node standby linuxdc

# 等待资源切换，观察新节点
pcs status

# 恢复节点
pcs node unstandby linuxdc
pcs status

24.4 常见问题与排查

问题现象	排查步骤
Keepalived VIP 未绑定	`journalctl -u keepalived -n 30`；确认 `virtual_router_id` 和 `auth_pass` 两端一致；确认防火墙已放行 VRRP 协议
两节点 VIP 同时出现（脑裂）	检查两节点网络连通性；确认认证密码完全一致；检查 VRRP 多播是否被防火墙过滤
Pacemaker 节点显示 OFFLINE	`journalctl -u corosync -n 20`；`journalctl -u pcsd -n 20`；确认防火墙已放行 `high-availability` 服务
集群资源未启动	`pcs resource cleanup <resource>`；`journalctl -u pacemaker -n 30`
`pcs host auth` 认证失败	确认两节点 hacluster 密码相同；确认 pcsd 服务运行正常

# 集群综合诊断
pcs status --full
crm_verify -L -V                 # 验证集群配置完整性
corosync-cfgtool -s              # Corosync 环路连通测试
journalctl -u corosync -u pacemaker -f   # 实时日志

24.5 实践任务

克隆第二台虚拟机（linuxdc2，192.168.1.101），配置 SSH 密钥免密互信，两节点 /etc/hosts 互相解析。
[两节点] 安装 Keepalived，配置主备角色（VIP 192.168.1.200），开放 VRRP 防火墙规则，启动服务，验证 VIP 绑定在主节点。
停止主节点 keepalived，验证 VIP 漂移到备节点；恢复后漂回。
[两节点] 安装 pcs/pacemaker，设置相同的 hacluster 密码，启动 pcsd，开放 high-availability 防火墙服务。
[主节点] 完成节点认证、集群初始化（pcs cluster setup），启动集群，创建 VIP 资源，验证 pcs status 正常。
创建 webserver 资源，配置 colocation 和 order 约束，验证两资源在同一节点运行。

24.6 自测问题

Q1：Keepalived 的 virtual_router_id 和 priority 各自的作用是什么？

virtual_router_id（VRID）标识同一个 VRRP 竞争组，同组内的主备节点必须使用相同的 VRID（范围 1–255）；同一局域网内不同业务可使用不同 VRID 管理多个独立 VIP（如 VRID 51 管理 Web VIP，VRID 52 管理数据库 VIP）。priority 决定节点竞争 VIP 时的优先级，值越大越优先；主节点宕机后，剩余存活节点中 priority 最高者接管 VIP，主节点恢复后若配置了 preempt（默认），会重新抢占 VIP 回来。

Q2：Pacemaker 中 colocation 约束和 order 约束分别控制什么？

colocation 约束控制资源的运行位置关系：INFINITY 分值表示两资源必须在同一节点，-INFINITY 表示必须在不同节点。例如 VIP 和 Web 服务必须共存于同一节点，否则 Web 服务监听的 IP 不在本机而无法正常提供服务。order 约束控制资源的启动/停止顺序：确保 VIP 先绑定成功，Web 服务再启动（启动）；Web 服务先停止，VIP 再解绑（停止），避免服务在 IP 未就绪时启动或客户端在服务未停止前就失去连接。

Q3：为什么生产集群必须配置 STONITH，禁用的风险是什么？

当集群节点间心跳通信中断（网络分区）时，各节点均认为对方故障，可能同时尝试接管资源——即"脑裂"。STONITH 通过带外管理通道（IPMI/iLO 等）物理断电或强制重启异常节点，确保在资源被另一节点接管之前，原节点已被彻底隔离，不会继续访问共享存储。若禁用 STONITH 发生脑裂，两节点可能同时向同一数据库写入不同数据，造成数据不一致甚至文件系统损坏，这是 HA 集群最严重的灾难场景，且往往难以恢复。

24.7 章节总结

本章介绍了 RHEL 9 高可用的两种方案：Keepalived 提供轻量的 VRRP VIP 自动漂移（配置简单，适合双机热备和无状态服务）；Pacemaker/Corosync 提供企业级集群资源管理（支持多资源类型、colocation/order 约束、STONITH 隔离和自动故障切换）。两者各有侧重，实际部署中也可结合使用：Keepalived 负责 VIP 快速漂移，Pacemaker 负责应用资源的精细管理。STONITH 是生产集群防止脑裂的最后一道防线，不可省略。