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

服务器高可用架构是保障业务连续性的核心基础设施。在IDC数据中心和云服务器选型场景中,双节点高可用集群是最小可用单元,也是理解集群原理的起点。本文以CentOS 9为例,使用Corosync+Pacemaker搭建一个完整的双节点高可用集群,覆盖资源代理配置、Fencing机制和故障自动切换全流程。

Corosync与Pacemaker架构关系解析

Corosync负责集群成员管理和消息传递,提供节点间的通信层和法定人数(Quorum)机制。Pacemaker是集群资源管理器,运行在Corosync之上,负责定义资源行为、监控健康状态和执行故障转移。两者配合的工作流:Corosync检测到节点失联 → Quorum计算触发 → Pacemaker执行资源迁移 → 备节点接管服务。双节点场景下Quorum无法自然形成多数,需配置第三方仲裁设备(如diskless SBD或QDevice)。

环境准备与基础配置

两台服务器的基本信息:

node1: 192.168.10.11(主节点)

node2: 192.168.10.12(备节点)

VIP: 192.168.10.100(浮动IP)

前置条件:两台服务器时间同步(NTP/Chrony),主机名解析正常(/etc/hosts配置),防火墙放行集群端口。

配置hosts文件(两台均执行):

# /etc/hosts
192.168.10.11  node1
192.168.10.12  node2

安装集群组件:

dnf install -y pacemaker corosync pcs psmisc policycoreutils-selinux
systemctl enable pcsd
systemctl start pcsd

设置hacluster用户密码(两台均执行):

echo "hacluster:your_password" | chpasswd

集群认证与初始化

在node1上执行节点认证:

pcs cluster auth node1 node2 -u hacluster -p your_password

创建集群:

pcs cluster setup mycluster node1 node2

启动集群并设置开机自启:

pcs cluster start --all
pcs cluster enable --all

验证集群状态:

pcs status cluster
# 预期输出:两节点均为online
pcs status corosync
# 预期输出:两节点membership一致

双节点Quorum问题与QDevice配置

双节点集群天然缺少Quorum(需要3票中的2票,但只有2票存在),任何节点宕机都会导致集群冻结。解决方案是部署QDevice作为第三方仲裁。在独立服务器上安装QDevice:

dnf install -y corosync-qnetd
systemctl enable corosync-qnetd
systemctl start corosync-qnetd

在集群节点上添加QDevice:

pcs cluster qdevice add model net host=qdevice-host
pcs cluster quorum status
# 确认QDevice vote为1,总votes为3

配置后,单节点故障时集群仍能维持Quorum,Pacemaker正常执行故障转移。

资源配置:浮动IP与Nginx服务

添加浮动IP资源:

pcs resource create VirtualIP 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 timeout=10s \
  op start timeout=40s \
  op stop timeout=30s

设置资源启动顺序和同位置约束:

pcs constraint colocation add Nginx with VirtualIP INFINITY
pcs constraint order VirtualIP then Nginx

这样确保Nginx只在持有VIP的节点上运行,且IP总是先于Nginx启动。

Fencing机制:SBD配置与故障隔离

没有Fencing的集群在脑裂场景下可能造成数据损坏。双节点环境推荐使用SBD(Storage-based Death)+ 共享磁盘方案:

# 在两台节点安装sbd
dnf install -y sbd

# 初始化SBD分区(在共享磁盘上)
sbd -d /dev/sdb create

# 修改Pacemaker配置启用SBD
pcs property set stonith-enabled=true
pcs property set no-quorum-policy=freeze
pcs stonith create sbd_fencing stonith:external/sbd \
  pcmk_delay_max=30s

SBD的工作原理:节点失联后,存活节点通过共享磁盘写入终止消息,失联节点读取后自行执行reboot强制关机,确保故障节点彻底释放资源。

故障切换测试与运维要点

手动迁移资源验证故障转移:

# 将所有资源迁移到node2
pcs resource move Nginx node2

# 验证
pcs status resources
# VirtualIP和Nginx应在node2上运行

# 清除手动约束(否则资源不会自动回迁)
pcs resource clear Nginx

模拟节点故障:

# 在node1上执行
echo c > /proc/sysrq-trigger
# 节点立即崩溃,Pacemaker应在30秒内完成资源接管
# 在node2上检查:
pcs status resources

日常运维注意事项:定期检查pcs status输出,关注Quorum状态和资源运行位置;日志排查路径/var/log/pacemaker.log/var/log/corosync.log;升级集群组件前务必备份/etc/corosync/corosync.conf和CIB配置;生产环境建议部署监控告警体系,对节点离线和资源切换事件设置即时告警。

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

(0)
小编小编
上一篇 2026年8月3日
下一篇 2026年8月3日

相关推荐

Linux服务器高可用集群搭建:Corosync+Pacemaker实现双机热备



服务器高可用集群是保障业务连续性的核心基础设施。当主节点发生硬件故障或服务异常时,集群需在秒级内完成故障切换,将服务迁移到备用节点继续运行。Corosync负责集群通信与成员管理,Pacemaker负责资源编排与故障决策,两者配合是Linux环境下最成熟的HA方案。

Corosync与Pacemaker高可用架构原理

Corosync提供集群节点间的可靠消息传递,基于Totem协议实现节点成员管理和心跳检测。Pacemaker作为集群资源管理器,运行在Corosync之上,根据预设策略决定资源在哪个节点运行。

典型双机热备架构包含以下组件:

– Corosync:集群通信层,维持心跳与仲裁
– Pacemaker:资源管理层,控制服务启停与迁移
– PCS:命令行管理工具,简化配置操作
– Fencing设备:强制隔离故障节点,防止脑裂

脑裂是双节点集群最大的风险源。当两个节点间通信中断但都在运行时,可能出现资源争抢和数据损坏。引入仲裁节点(QDevice)或Fencing设备是解决脑裂的必要手段。

双节点集群环境准备与网络配置

实验环境使用两台CentOS 9 Stream服务器:node1: 192.168.1.10(主节点)、node2: 192.168.1.11(备节点)、VIP: 192.168.1.100(浮动地址)

每台服务器需要两块网卡,一块用于业务通信,一块用于心跳直连。心跳链路使用交叉线直连或独立VLAN,避免业务网络拥堵导致心跳丢失。

配置hosts解析并确保时间同步:

# 两台节点均执行
echo 192.168.1.10 node1 >> /etc/hosts
echo 192.168.1.11 node2 >> /etc/hosts
dnf install -y chrony
systemctl enable --now chronyd

安装Corosync+Pacemaker并初始化集群

安装必要软件包:dnf install -y pacemaker corosync pcs

设置hacluster用户密码(两节点均执行),PCS通过此用户认证。

在node1上认证节点并创建集群:

pcs cluster auth node1 node2 -u hacluster -p YourStr0ngPass
pcs cluster setup mycluster node1 node2 --force
pcs cluster start --all
pcs cluster enable --all

验证集群状态:pcs status cluster 和 pcs status corosync

配置Fencing与仲裁防止脑裂

双节点集群必须配置Fencing设备。生产环境使用IPMI或iLO进行硬件级Fencing:

pcs stonith create ipmi_fence fence_ipmilan \
ipaddr=192.168.1.10-ipmi login=admin passwd=secret \
pcmk_hostlist=node1 op monitor interval=60s

对于双节点集群,还需配置仲裁策略:pcs property set no-quorum-policy=ignore 和 pcs property set stonith-enabled=true

生产环境中建议添加第三个轻量仲裁节点(QDevice),避免no-quorum-policy=ignore带来的风险。QDevice只需极低配置,1核CPU+512MB内存即可。

Nginx高可用资源配置与故障切换测试

以Nginx服务为例,配置VIP和Nginx资源:

pcs resource create vip ocf:heartbeat:IPaddr2 \
ip=192.168.1.100 cidr_netmask=24 op monitor interval=30s
pcs resource create nginx systemd:nginx op monitor interval=20s timeout=10s
pcs constraint colocation add vip with nginx INFINITY
pcs constraint order start vip then nginx

手动切换测试:pcs cluster standby node1,验证VIP已漂移到node2。恢复node1后取消standby:pcs cluster unstandby node1

资源不会自动迁回,因为默认的resource-stickiness阻止了不必要的迁移。这个行为可通过调整stickiness值控制。

监控告警与日常运维要点

集群运行后需持续监控关键指标:节点心跳状态(corosync-cmapctl | grep members)、资源运行位置(pcs status resources)、Fencing设备状态(pcs stonith status)、集群事件日志(journalctl -u pacemaker -u corosync -f)。

常见故障排查方向:心跳网络中断导致节点离线时,检查物理链路和VLAN配置;资源启动失败时,检查OCF脚本返回码和stderr输出;脑裂发生时,Fencing设备应自动隔离故障节点,若Fencing失败则需人工介入确认节点状态后手动恢复。

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

(0)
小编小编
上一篇 2026年8月3日
下一篇 2026年8月3日

相关推荐

Linux服务器高可用集群搭建:Corosync+Pacemaker实现双机热备全流程

服务器高可用架构为什么离不开Corosync+Pacemaker

服务器运维中,单点故障是最大的可用性杀手。业务系统跑在单台物理机或云服务器上,硬件故障、内核崩溃、网络中断任何一个环节出问题,服务直接中断。高可用集群通过冗余节点 + 自动故障转移来解决这个痛点。Corosync负责集群通信和成员管理,Pacemaker负责资源调度和故障恢复,这套组合在Linux服务器领域已经跑了十几年,稳定性经过金融、电信行业大规模验证。相比Kubernetes这类容器编排方案,Corosync+Pacemaker更适合数据库、存储、虚拟机等有状态服务的HA需求。

环境准备与网络配置

双机热备最小部署需要两台服务器,建议配置:

  • 两台CentOS 8/Ubuntu 22.04服务器,最低4核8G
  • 业务网络:eth0,用于实际业务流量
  • 心跳网络:eth1,专用于集群节点间通信
  • 共享存储:iSCSI或FC SAN,用于共享数据
  • 浮动VIP:业务入口IP,故障时自动迁移

网络层面,双心跳链路是硬性要求——单链路一旦断开,集群无法区分网络分区和对端宕机,可能触发脑裂。配置如下:

# /etc/hosts 两台节点互相解析
192.168.1.10  node1
192.168.1.11  node2

# 心跳网络(eth1)
10.0.0.1  node1-hb
10.0.0.2  node2-hb

# 防火墙放行集群端口
firewall-cmd --permanent --add-service=high-availability
firewall-cmd --reload

# 或直接开放端口
firewall-cmd --permanent --add-port=2224/tcp  # corosync
firewall-cmd --permanent --add-port=3121/tcp  # pacemaker
firewall-cmd --permanent --add-port=5405-5412/udp  # corosync multicast
firewall-cmd --reload

安装Corosync与Pacemaker

# CentOS 8
 dnf install -y pacemaker corosync pcs psmisc policycoreutils-python

# Ubuntu 22.04
apt install -y pacemaker corosync pcs

# 启动pcs守护进程(两台节点都执行)
systemctl enable pcsd
systemctl start pcsd

# 设置hacluster用户密码(两台节点保持一致)
echo "hacluster:YourStrongPassword" | chpasswd

# 节点间认证(任意一台执行)
pcs cluster auth node1 node2 -u hacluster -p YourStrongPassword

集群创建与基础配置

# 创建双节点集群
pcs cluster setup myhacluster node1 node2 --token 10000 --wait 60

# 启动集群
pcs cluster start --all

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

# 验证集群状态
pcs status cluster

# 禁用STONITH(测试环境可以先禁用,生产环境必须启用)
pcs property set stonith-enabled=false

# 设置仲裁策略(双节点无仲裁设备时)
pcs property set no-quorum-policy=ignore

生产环境警告:禁用STONITH和忽略仲裁策略仅适用于测试。生产环境必须配置fencing设备(如IPMI、iLO、SCSI持久保留),否则脑裂时两个节点同时写共享存储将导致数据损坏。

配置浮动VIP与资源组

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

# 创建文件系统资源(NFS共享存储挂载)
pcs resource create SharedFS ocf:heartbeat:Filesystem \
  device="192.168.1.50:/shared_data" directory="/data" fstype="nfs" \
  op monitor interval=20s timeout=40s

# 创建数据库服务资源(以MySQL为例)
pcs resource create MySQL ocf:heartbeat:mysql \
  binary="/usr/sbin/mysqld" config="/etc/my.cnf" \
  datadir="/data/mysql" pid="/var/run/mysqld/mysqld.pid" \
  op monitor interval=20s timeout=30s

# 创建资源组:VIP + 存储 + 数据库启动顺序
pcs resource group add ha_group VirtualIP SharedFS MySQL

# 设置资源粘性(防止频繁迁移)
pcs resource defaults resource-stickiness=100

# 设置启动顺序约束
pcs constraint colocation add VirtualIP SharedFS INFINITY
pcs constraint colocation add SharedFS MySQL INFINITY
pcs constraint order VirtualIP then SharedFS
pcs constraint order SharedFS then MySQL

故障转移测试与调优

模拟节点故障验证自动切换:

# 在node1上模拟故障:让node1进入standby
pcs node standby node1

# 观察资源是否自动迁移到node2
pcs status resources

# 恢复node1
pcs node unstandby node1

# 模拟网络故障:断开心跳链路
ip link set eth1 down
# 等待30秒观察切换情况
# 恢复
ip link set eth1 up

调优关键参数:

  • resource-stickiness:默认0,设为100+可防止资源在节点恢复后回迁,减少不必要切换
  • migration-threshold:资源在同一节点失败N次后迁移到其他节点,建议设为3
  • failure-timeout:失败计数器重置时间,默认0(永不重置),建议设为300s
  • pcmk_delay_max:双节点 fencing 延迟上限,避免同时fencing,建议20s
# 设置迁移阈值和超时
pcs resource update MySQL meta migration-threshold=3 failure-timeout=300s

# 查看约束和配置
pcs constraint
pcs config show

脑裂防护与生产加固

脑裂(Split-Brain)是双节点集群最大的风险。防护措施:

  1. 仲裁设备:配置QDevice(第三方仲裁节点),推荐使用corosync-qnetd
  2. Fencing:配置IPMI或SCSI Persistent Reservations,故障节点被强制隔离
  3. 双心跳链路:业务网络和专用心跳网络,任一链路断开不触发误切换
  4. 监控告警:集群状态变化实时推送至运维群
# 配置QDevice仲裁(在第三方节点上部署qnetd)
dnf install -y corosync-qnetd
corosync-qnetd -f  # 前台启动测试

# 集群添加QDevice
pcs cluster add qdevice qnetd-node --enable
pcs cluster sync

# 验证仲裁状态
corosync-quorumtool -s

高可用不是装完软件就完事。从网络拓扑到fencing策略,每个环节的配置决策都直接影响故障恢复效果。测试环境中反复演练切换场景,生产上线后才能安心睡觉。

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

(0)
小编小编
上一篇 2026年7月30日
下一篇 2026年7月30日

相关推荐

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和法定人数策略要随节点数调整。

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

(0)
小编小编
上一篇 2026年7月28日
下一篇 2026年7月28日

相关推荐

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/

(0)
小编小编
上一篇 2026年7月23日
下一篇 2026年7月23日

相关推荐

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

高可用集群解决什么问题

单台服务器跑核心业务,硬件故障、系统崩溃、网络中断任何一个出现就是业务完全中断。高可用集群的目标很直接:一台挂了,另一台自动接管,业务恢复时间从小时级压到秒级。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

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

(0)
小编小编
上一篇 2026年7月23日
下一篇 2026年7月23日

相关推荐