高可用（High Availability）是生产环境中绕不开的话题。当一台服务器因为硬件故障、系统崩溃或者计划内维护而停止服务时，我们希望业务能够在极短时间内自动迁移到备用节点上继续运行，这正是 Pacemaker 与 Corosync 要解决的问题。Corosync 负责集群节点之间的心跳通信和成员关系维护，Pacemaker 则站在更高层面管理集群资源，决定某个服务在哪个节点上启动、故障发生后如何迁移。本文以 CentOS Stream 9 为例，完整演示一套双节点高可用集群的搭建过程。
一、理解组件分工：Corosync 管通信，Pacemaker 管资源
很多人把 Pacemaker 和 Corosync 混为一谈，实际上它们的职责边界非常清晰。Corosync 的核心工作是提供一个可靠的多播消息层，集群中每个节点通过它互相交换心跳信息，一旦某个节点失联，剩余节点会重新计算集群成员关系（也就是所谓的 quorum，法定人数）。Pacemaker 建立在 Corosync 之上，它是一个集群资源管理器，负责定义资源（比如一个 IP 地址、一个 Nginx 进程、一个数据库实例），并根据当前集群状态决定资源应该在哪个节点上运行。
举个例子：双节点集群中节点 A 运行着业务服务，节点 B 处于待命状态。当节点 A 的主机突然断电，Corosync 会检测到心跳丢失，Pacemaker 收到成员变更事件后立即在节点 B 上重新启动资源，整个过程通常在几秒到几十秒内完成，无需人工介入。理解了这个分工，后面排障时思路会清晰很多：如果怀疑节点间通信有问题，查 Corosync；如果资源不切换或者切换行为异常，查 Pacemaker 的资源和约束配置。
还需要了解两个重要概念。第一个是 STONITH（Shoot The Other Node In The Head），即隔离机制，当集群无法确认某节点的状态时，通过强制断电等方式确保该节点真正停止，防止出现双主脑裂。第二个是 quorum，即法定票数，双节点集群默认无法形成 quorum（各持一票，没有过半数），因此需要额外配置两节点集群的特殊处理策略。
二、环境准备与基础配置
本次实验使用两台服务器：node1（192.168.10.11）和 node2（192.168.10.11 之外的第二台，192.168.10.12），操作系统均为 CentOS Stream 9。另外准备一个虚拟 IP 192.168.10.100 作为业务访问入口，客户端始终访问这个 IP，不需要关心后端是哪台机器在提供服务。
首先在两台机器上配置主机名解析，编辑 /etc/hosts 文件，加入以下内容：
192.168.10.11 node1 192.168.10.12 node2
接着关闭 firewalld 和 SELinux（生产环境建议按端口精细放行而非直接关闭，此处为了实验简便）：
# 两台节点都执行 systemctl disable --now firewalld sed -i 's/^SELINUX=enforcing/SELINUX=permissive/' /etc/selinux/config setenforce 0
然后安装集群软件包。CentOS Stream 9 的仓库中提供了 pcs、pacemaker 和 corosync，其中 pcs 是集群的配置管理工具，我们主要通过它来完成日常管理：
dnf install -y pcs pacemaker fence-agents-all # 启动 pcsd 服务并设置开机自启 systemctl enable --now pcsd # 为 hacluster 用户设置密码，两台节点密码必须一致 echo "hacluster:YourPassword123" | chpasswd
这里有个容易踩的坑：hacluster 是 pcs 安装时自动创建的管理账户，两台节点的密码必须相同，否则后面执行集群认证会失败。密码设置完成后建议先用 systemctl status pcsd 确认服务正常运行。
三、创建集群并配置认证
基础环境就绪后，在任意一台节点上执行认证操作，让两个节点彼此信任：
pcs host auth node1 node2 -u hacluster -p YourPassword123
认证成功后会提示 node1 和 node2 均为 Authorized。接着创建名为 mycluster 的集群并启动：
pcs cluster setup mycluster node1 node2 pcs cluster enable --all pcs cluster start --all
执行 pcs cluster status 和 corosync-cfgtoolcheck 可以分别查看集群运行状态和 Corosync 链路健康情况。此时用 pcs status 查看会发现集群有如下告警：no STONITH devices 和 quorum 相关警告。这是因为默认策略要求必须配置隔离设备，而双节点集群也没有 quorum。
对于实验环境，我们可以先降低安全策略来跑通流程：
# 实验环境关闭 STONITH 强制要求 pcs property set stonith-enabled=false # 双节点集群忽略 quorum 限制 pcs property set no-quorum-policy=ignore
必须强调：生产环境绝不能简单粗暴地关闭这两项。没有隔离机制的双节点集群一旦发生脑裂，两个节点会同时拉起资源，比如同时挂载同一个存储，可能造成数据损坏。生产环境应配置真实的 fence 设备（如 IPMI、iLO、智能 PDU），或者引入第三个节点、qdevice 仲裁设备来保证 quorum。
四、添加资源与约束规则
集群跑起来之后，接下来定义资源。我们创建一个虚拟 IP 资源和一个 Nginx 服务资源，让客户端通过虚拟 IP 访问 Web 服务：
# 创建虚拟 IP 资源 pcs resource create vip ocf:heartbeat:IPaddr2 \ ip=192.168.10.100 cidr_netmask=24 \ op monitor interval=10s # 创建 Nginx 服务资源 pcs resource create webserver ocf:heartbeat:nginx \ configfile=/etc/nginx/nginx.conf \ op monitor interval=15s
创建完成后用 pcs status 查看，会发现 vip 和 webserver 可能分散在两个节点上，这显然不合理：虚拟 IP 和 Nginx 必须在同一个节点上才有意义。解决办法是使用组资源或者排列约束（colocation），把二者绑在一起，再用顺序约束（order）确保 IP 先于服务启动：
# 将两个资源加入同一资源组，自动绑定在同一节点并保证启动顺序 pcs resource group add webgroup vip webserver
资源组的写法最简单，组内资源会在同一节点上按顺序启动、按逆序停止。如果需要更精细的控制，也可以用约束命令单独表达：
# 等价的约束写法 pcs constraint colocation add webserver with vip INFINITY pcs constraint order vip then webserver # 偏好 node1 作为首选运行节点 pcs constraint location webgroup prefers node1=50
其中 location 约束设置了节点偏好分数，node1 得分更高，资源默认在 node1 上运行。验证高可用效果很简单：在 node1 上执行 pcs cluster stop node1 模拟故障，观察虚拟 IP 和 Nginx 是否在几秒内漂移到 node2；重新拉起 node1 后，根据约束配置资源可以自动回迁，也可以设置 pcs resource defaults update resource-stickiness=100 让资源留在当前节点，避免不必要的来回切换。
五、常见问题与排查思路
搭建过程中最常见的问题是节点之间无法互相认证或心跳不通。排查顺序建议是：先用 ping 确认网络连通，再检查 /etc/hosts 解析是否两边一致，然后看 pcsd 服务状态和 hacluster 密码是否统一。如果 pcs cluster status 显示某节点离线，可以在该节点上查看 /var/log/cluster/corosync.log 日志。
第二个高频问题是资源启动失败。用 pcs resource debug-start webserver 可以手动测试资源代理能否正常启动，常见原因包括 nginx 配置文件路径写错、缺少 resource-agents 包导致找不到 ocf 代理脚本等。资源反复失败触发 failcount 累积后，Pacemaker 会停止重试，此时需要 pcs resource cleanup webserver 清除失败计数。
最后是脑裂防护。生产部署时务必配置 STONITH 设备，例如服务器带 IPMI 接口时可以这样添加：
pcs stonith create ipmi_fence fence_ipmilan \ ip=192.168.10.101 username=admin password=AdminPass \ pcmk_host_list=node1 \ op monitor interval=60s pcs property set stonith-enabled=true
双节点集群还推荐部署 corosync-qdevice 作为第三方仲裁，当节点失联时由 qdevice 投票决定谁能继续持有资源，从根本上避免双节点各执一词的局面。完成这些配置后，建议定期做故障演练，把节点断电、拔网线、杀进程等场景都跑一遍，确认切换时间符合业务容忍度，这套高可用集群才算真正具备了上生产的资格。
PacemakerCorosyncLinux高可用集群修改时间：2026-09-03 14:09:12