Linux服务器高可用集群搭建：Corosync+Pacemaker双机热备完整配置指南

为什么需要Corosync+Pacemaker高可用方案

生产环境中单点故障是服务不可用的首要原因。Nginx、MySQL、Redis等关键服务一旦所在节点宕机，业务全线中断。Corosync负责集群节点间的消息传递和成员管理，Pacemaker负责资源调度和故障切换，两者组合是企业级Linux高可用的标准方案。

这套方案的核心价值在于：故障检测秒级完成，资源自动切换，无需人工干预。相比Keepalived只能做VIP漂移，Pacemaker能管理任意系统资源——文件系统、IP地址、系统服务、甚至自定义脚本。

环境准备与基础配置

以CentOS 8/AlmaLinux 8为例，两台服务器：

– node1: 192.168.10.11
– node2: 192.168.10.12
– VIP: 192.168.10.100

两台节点均需配置：

# 安装组件
dnf install -y pacemaker corosync pcs pcp

# 启动pcsd服务
systemctl enable --now pcsd

# 设置hacluster用户密码（两台节点都要）
echo "hacluster:YourStr0ngPass" | chpasswd

# 配置hosts解析（两台节点）
cat >> /etc/hosts << 'EOF'
192.168.10.11  node1
192.168.10.12  node2
EOF

集群初始化与节点认证

在node1上执行：

# 节点认证
pcs cluster auth node1 node2 -u hacluster -p YourStr0ngPass

# 创建集群
pcs cluster setup myhacluster node1 node2 --enable --start

# 验证集群状态
pcs cluster status

正常输出应显示两台节点均为Online状态。如果节点显示Offline，检查corosync网络端口5405/5406是否放行：

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

全局配置与STONITH策略

STONITH（Shoot The Other Node In The Head）是高可用的核心安全机制，防止脑裂后双节点同时写入共享存储导致数据损坏。测试环境可以禁用，生产环境必须启用：

# 测试环境：禁用STONITH
pcs property set stonith-enabled=false

# 生产环境：配置fencing设备（以IPMI为例）
pcs stonith create ipmi_fence stonith:fence_ipmilan   ipaddr=192.168.10.100 login=admin passwd=admin123   pcmk_hostlist="node1 node2"   pcmk_hostmap="node1:192.168.10.101;node2:192.168.10.102"   op monitor interval=60s

pcs property set stonith-enabled=true

其他关键属性：

# 忽略法定人数（双节点集群必须设置，否则一台宕机后剩余节点会拒绝服务）
pcs property set no-quorum-policy=ignore

# 资源默认粘性（防止资源频繁切换，优先留在当前节点）
pcs resource defaults resource-stickiness=100

# 默认迁移阈值（失败3次后停止迁移，避免故障节点被反复尝试）
pcs resource defaults migration-threshold=3

Nginx高可用资源配置

以Nginx+VIP双机热备为例：

# 创建VIP资源
pcs resource create vip ocf:heartbeat:IPaddr2   ip=192.168.10.100 cidr_netmask=24   op monitor interval=30s

# 创建Nginx资源
pcs resource create nginx systemd:nginx   op monitor interval=20s   op start timeout=40s   op stop timeout=40s

# 设置资源共置和启动顺序
pcs constraint colocation add nginx with vip INFINITY
pcs constraint order vip then nginx

验证资源状态：

pcs status resources

# 期望输出：
# vip     (ocf::heartbeat:IPaddr2):        Started node1
# nginx   (systemd:nginx):                 Started node1

故障切换测试与验证

手动模拟node1故障：

# 在node1上执行
pcs cluster standby node1

# 观察资源迁移
pcs status resources
# vip和nginx应在10秒内迁移到node2

恢复node1：

pcs cluster unstandby node1

# 由于设置了resource-stickiness=100，资源不会自动迁回node1
# 如需手动迁回
pcs resource move vip node1

共享存储配置：DRBD双主模式

如果Nginx需要共享后端文件，可搭配DRBD实现块级数据同步：

dnf install -y drbd drbd-utils

# /etc/drbd.d/data.res
resource data {
  protocol C;
  disk /dev/sdb1;
  meta-disk internal;
  on node1 { address 192.168.10.11:7789; }
  on node2 { address 192.168.10.12:7789; }
}

# 初始化并启动（两台节点）
drbdadm create-md data
drbdadm up data
# node1上执行（首次）
drbdadm primary --force data
mkfs.xfs /dev/drbd0

将DRBD注册为Pacemaker资源：

pcs resource create drbd_data ocf:linbit:drbd   drbd_resource=data op monitor interval=30s role=Promoted   op monitor interval=60s role=Unpromoted
pcs resource create fs_data ocf:heartbeat:Filesystem   device="/dev/drbd0" directory="/data" fstype="xfs"
pcs constraint order drbd_data then fs_data
pcs constraint colocation add fs_data with drbd_data INFINITY with-role=Promoted

监控与告警集成

Pacemaker事件通过crm_mon输出，结合脚本实现企业微信/钉钉告警：

#!/bin/bash
# /etc/corosync/crm_mon_alert.sh
while read line; do
  curl -s -X POST "https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=YOUR_KEY"     -H "Content-Type: application/json"     -d "{"msgtype":"text","text":{"content":"[HA告警] $line"}}"
done

配置crm_mon回调：

crm_mon --daemon --external-notification /etc/corosync/crm_mon_alert.sh

常见故障排查清单

节点状态Unknown：corosync进程异常。检查systemctl status corosync，查看/var/log/cluster/corosync.log中的心跳超时日志。

资源启动失败：检查pcs resource debug-start vip的输出，常见原因是VIP已被其他节点占用。执行arping -I eth0 192.168.10.100确认。

脑裂恢复：双节点同时持有VIP。立即在次要节点执行pcs cluster stop，确认数据一致性后重新加入集群。预防脑裂靠STONITH，不要在生产环境禁用。

切换耗时过长：默认检测超时60秒。可在资源定义中调整op monitor interval=10s timeout=20s加快故障检测，但过短间隔可能导致网络抖动误判。

双机热备不是终点，而是起点。业务增长后应考虑多节点集群+负载均衡架构，将单点切换升级为多活服务。Corosync+Pacemaker的弹性足够支撑3-8节点的中等规模集群，关键是STONITH和法定人数策略要随节点数调整。