Linux服务器高可用集群搭建：Corosync+Pacemaker双节点实战

高可用集群的核心组件选型

服务器运维中，单点故障是最大的风险敞口。Corosync负责集群通信和成员管理，Pacemaker负责资源调度和故障切换——这套组合已在生产环境运行十余年，成熟度和社区支持远超Keepalived等轻量方案。

本文在两台CentOS 9 Stream服务器上完成双节点HA集群搭建，以Nginx作为受管服务演示故障自动切换。

双节点环境规划与网络配置

节点规划：

node1：192.168.10.11（主节点）
node2：192.168.10.12（备节点）
VIP：192.168.10.100（浮动IP，客户端访问入口）

两台服务器需要双向SSH免密登录和主机名解析：

# 两台节点均执行
hostnamectl set-hostname node1  # node2上设为node2
echo "192.168.10.11 node1" >> /etc/hosts
echo "192.168.10.12 node2" >> /etc/hosts

# 生成SSH密钥并同步
ssh-keygen -t ed25519
ssh-copy-id root@node2

时间同步是集群通信的前提：

dnf install -y chrony
systemctl enable --now chronyd
chronyc sources

安装Corosync与Pacemaker

# 两台节点均安装
dnf install -y pacemaker corosync pcs

# 设置hacluster用户密码（pcs命令需要）
echo "hacluster:YourStr0ngP@ss" | chpasswd

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

节点认证与集群创建：

# 在node1执行
pcs host auth node1 node2 -u hacluster -p YourStr0ngP@ss

# 创建名为hacluster的双节点集群
pcs cluster setup hacluster node1 node2

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

验证集群状态：

pcs status cluster
pcs status nodes

两个节点均显示Online即表示集群通信正常。

集群属性与STONITH配置

STONITH（Shoot The Other Node In The Head）是高可用的关键机制，防止脑裂后双写。生产环境必须配置IPMI或iLO fence设备。测试环境可临时禁用：

pcs property set stonith-enabled=false
pcs property set no-quorum-policy=ignore

生产环境中应配置fence设备：

# 示例：IPMI fence配置
pcs stonith create ipmi_fence fence_ipmilan   ipaddr=192.168.10.200 login=admin passwd=ipmipass   pcmk_hostlist="node1 node2"   op monitor interval=60s

配置Nginx资源与浮动VIP

创建资源组，确保VIP和Nginx在同一节点运行：

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

# 创建Nginx资源
pcs resource create Nginx ocf:heartbeat:nginx   configfile=/etc/nginx/nginx.conf   op monitor interval=20s timeout=10s   op start timeout=40s   op stop timeout=30s

# 将资源加入同一组，保证同节点运行
pcs resource group add WebGroup VirtualIP Nginx

# 设置资源黏性，避免不必要的迁移
pcs constraint location WebGroup prefers node1=100
pcs constraint location WebGroup prefers node2=50

验证资源配置：

pcs status resources
pcs constraint list

故障切换测试与日常维护

模拟主节点故障：

# 在node1上停止集群服务
pcs cluster stop node1

# 在node2上观察
pcs status resources

VIP和Nginx应在30秒内自动迁移到node2。恢复node1后，资源不会自动回迁（因为设置了黏性），除非node2也发生故障。

日常维护命令：

# 将node1设为维护模式
pcs node standby node1

# 恢复node1
pcs node unstandby node1

# 手动迁移资源
pcs resource move WebGroup node2

# 清除手动迁移约束
pcs constraint remove location-cli-prefer-WebGroup

高可用集群不是装完就完的工作。定期验证切换、监控Corosync环形缓冲区溢出、关注Pacemaker的CRM日志，才能在故障真正发生时从容应对。

原创文章，作者：小编，如若转载，请注明出处：https://www.yunthe.com/linux-fu-wu-qi-gao-ke-yong-ji-qun-da-jian-corosyncpacemaker/

高可用集群解决什么问题

单台服务器跑核心业务，硬件故障、系统崩溃、网络中断任何一个出现就是业务完全中断。高可用集群的目标很直接：一台挂了，另一台自动接管，业务恢复时间从小时级压到秒级。Corosync负责集群节点间的心跳通信和成员管理，Pacemaker负责资源调度和故障切换，两者配合是Linux服务器高可用集群的主流方案。

环境准备与基础配置

双节点方案：node1(192.168.1.10)和node2(192.168.1.11)，浮动VIP为192.168.1.100。操作系统用CentOS Stream 9或Ubuntu 22.04。

两台机器都执行：

# CentOS
dnf install -y pacemaker corosync pcs resource-agents

# Ubuntu
apt install -y pacemaker corosync pcs

# 启动pcs守护进程
systemctl enable --now pcsd

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

配置节点间互信：

# 在node1执行
pcs host auth node1 node2 -u hacluster -p YourStrongPass

集群创建与Corosync通信配置

创建集群并启动：

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

# 启动集群
pcs cluster start --all

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

验证集群状态：

pcs status cluster

# 预期输出
Cluster Name: myhacluster
Last Updated: Thu Jul 23 06:00:00 2026
Stack: corosync
Current DC: node1 (version 2.1.5) - partition with quorum
Online: [ node1 node2 ]

如果看到两个节点都是Online，集群通信正常。Corosync默认用UDP 5405端口做心跳，防火墙要放行：

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

STONITH配置与仲裁策略

STONITH（Shoot The Other Node In The Head）是防止脑裂的关键机制。生产环境强烈建议配置，哪怕只是用fence_ipmilan做IPMI重启。没有STONITH的集群在故障场景下可能造成数据损坏。

如果没有共享存储的IPMI，可以先用no-quorum-policy临时过渡：

# 禁用STONITH（测试环境用，生产不建议）
pcs property set stonith-enabled=false

# 仲裁丢失时的策略：ignore=继续运行，freeze=冻结资源，stop=停止资源
pcs property set no-quorum-policy=stop

正式环境配IPMI STONITH：

pcs stonith create ipmi_fence fence_ipmilan \
    ipaddr=192.168.1.100 \
    login=admin \
    passwd=adminpasswd \
    pcmk_hostlist="node1 node2" \
    op monitor interval=60s

Pacemaker资源配置实战

创建浮动VIP资源和Nginx服务资源：

# VIP资源
pcs resource create virtual_ip ocf:heartbeat:IPaddr2 \
    ip=192.168.1.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=30s

设置资源绑定和启动顺序：

# 资源必须在同一节点运行
pcs constraint colocation add nginx with virtual_ip INFINITY

# 先启动VIP再启动Nginx
pcs constraint order virtual_ip then nginx

检查约束：

pcs constraint

# 验证资源运行位置
pcs status resources

故障切换测试

把node1设为待机，观察资源是否自动迁移到node2：

# 在node1执行
pcs cluster standby node1

# 观察资源迁移
watch pcs status resources

# 恢复node1
pcs cluster unstandby node1

正常情况下5-10秒内VIP和Nginx就会在node2上启动。用ip addr show在node2上确认VIP绑定，curl访问VIP确认Nginx正常响应。

模拟更极端的场景——直接断开node1的网络：

# 在node1上模拟网络故障
iptables -A INPUT -p udp --dport 5405 -j DROP
iptables -A OUTPUT -p udp --dport 5405 -j DROP

# Corosync心跳丢失，Pacemaker触发故障切换
# 等待约30秒（取决于token超时配置），node2接管资源

记得清除iptables规则恢复node1网络：

iptables -D INPUT -p udp --dport 5405 -j DROP
iptables -D OUTPUT -p udp --dport 5405 -j DROP

集群日常运维要点

集群搭好不是结束，日常运维才是考验。几个关键操作：

查看完整集群状态：

pcs status

清理失败资源：资源故障后Pacemaker会标记为failed，清理后才能重新调度：

pcs resource cleanup nginx

调整心跳超时：默认token超时3秒，云服务器网络抖动可能误判：

# 编辑/etc/corosync/corosync.conf
token: 10000      # 心跳超时改为10秒
token_retransmits_before_loss_const: 10

# 重新加载配置
pcs cluster sync
pcs cluster reload corosync

查看集群事件日志：

journalctl -u corosync -u pacemaker --since "1 hour ago"

常见问题诊断

节点一直Offline：检查Corosync端口5405是否放行，tcpdump -i eth0 udp port 5405抓包确认心跳包在走。

资源启动失败：pcs resource debug-start nginx手动启动看错误输出，常见是服务配置文件问题或端口冲突。

脑裂场景：两台都Online但资源各自运行一份。原因是STONITH未配置且网络分区，必须配好STONITH和仲裁盘。

VIP无法绑定：检查ip addr add 192.168.1.100/24 dev eth0手动执行是否报错，ARP广播有时需要手动触发：arping -c 3 -I eth0 192.168.1.100。