在CentOS高可用架构中，Pacemaker并不是一个单独运行的守护进程那么简单，它和Corosync共同构成资源管理层与成员通信层。Corosync负责节点之间的心跳、成员关系与法定人数计算，Pacemaker则根据集群信息库中的配置，决定每个资源应该运行在哪一个节点，并在节点故障或资源异常时触发迁移。管理员通常不直接编辑XML格式的CIB，而是通过pcs命令行完成绝大部分操作。
一、Pacemaker资源管理的核心概念
Pacemaker将需要高可用的对象统一抽象为资源，包括虚拟IP、文件系统、数据库、Web容器以及自定义脚本。资源本身不直接执行启停，而是由资源代理（Resource Agent）完成。常见资源代理类型包括OCF、LSB和systemd。其中OCF代理功能最完整，支持细粒度监控和参数校验，例如ocf:heartbeat:IPaddr2就是对虚拟IP的一种标准实现。可以通过pcs resource agents list ocf:heartbeat查看当前节点可用的OCF资源代理列表。
集群信息库（CIB）保存资源配置、节点属性、约束关系和当前状态。集群中每一处变更都会先写入CIB，再由策略引擎计算资源应当在哪个节点运行。Pacemaker的策略引擎会读取约束并执行调度，而本地资源管理器（LRM）则调用对应的资源代理来完成启动、停止和监控动作。理解这三层结构有助于排查问题：如果资源状态异常，首先看CIB配置是否正确，再看资源代理的监控输出，最后看节点本地日志。
二、在CentOS上安装并初始化Pacemaker集群
搭建集群前需要准备至少两台互相解析的CentOS主机，并保证时间同步。每个节点都需要安装pacemaker、corosync、pcs以及fence代理。执行dnf install -y pacemaker corosync pcs fence-agents-all即可完成安装。接着在所有节点启动pcsd服务并设置开机自启，命令为systemctl enable --now pcsd。同时需要为hacluster用户设置密码，该用户用于集群节点之间的认证，所有节点建议使用相同密码。
完成基础准备后，在任意节点执行节点认证。假设两台主机名分别为node1和node2，命令如下：
pcs host auth node1 node2 -u hacluster -p your_password pcs cluster setup --name webcluster node1 node2 pcs cluster start --all pcs cluster enable --all
集群启动后，可以用pcs status查看成员状态和资源状态。实验环境通常会暂时关闭Stonith，因为缺少真实硬件fence设备时Stonith会阻止资源正常启动。命令为pcs property set stonith-enabled=false。生产环境不建议直接关闭Stonith，否则脑裂场景下无法安全隔离故障节点。
三、创建并管理常见集群资源
集群中最常见的资源是虚拟IP。它允许客户端通过固定地址访问服务，当主节点故障时，虚拟IP随资源一起迁移到备用节点。下面创建一个名为web_vip的虚拟IP资源，并设置30秒间隔的监控：
pcs resource create web_vip ocf:heartbeat:IPaddr2 \ ip=192.168.10.100 cidr_netmask=24 \ op monitor interval=30s
这里使用反斜杠换行是为了让命令更清晰，实际执行时也可以写成一行。创建完成后，pcs status应当显示web_vip已经启动在某个节点。紧接着可以创建Apache资源，并将它与虚拟IP绑定，避免出现虚拟IP在一个节点而Web服务在另一个节点的情况。
pcs resource create web_site ocf:heartbeat:apache \ configfile=/etc/httpd/conf/httpd.conf \ statusurl=http://127.0.0.1/server-status \ op monitor interval=60s pcs resource group add webgroup web_vip web_site
资源组会强制同组资源在同一节点上运行，并按顺序启动。资源组内部默认存在顺序和共存约束，不需要再手动添加。若需要更细粒度控制，可以使用约束表达依赖关系。例如让虚拟IP先于Web服务启动，并保证它们始终在同一节点，命令如下：
pcs constraint order web_vip then web_site pcs constraint colocation add web_site with web_vip INFINITY pcs constraint location webgroup prefer node1=INFINITY
日常维护中，pcs resource disable web_site可以停止资源而不会触发重新调度，pcs resource enable web_site恢复管理。pcs resource move web_vip node2可以在节点间手动迁移资源，迁移完成后建议执行pcs resource clear web_vip清除临时约束，否则资源会被钉在目标节点。如果资源因为历史失败处于blocked状态，可以执行pcs resource cleanup web_vip重置状态。
四、故障转移验证与运维建议
创建资源后必须验证故障转移。可以先确认资源当前运行节点，然后在另一节点执行pcs cluster stop或直接重启当前节点，观察资源是否自动迁移。正常情况下，Pacemaker会在几十秒内将虚拟IP和Apache服务迁移到存活节点。如果迁移失败，先检查pcs status的Failed Actions部分，再查看journalctl -u pacemaker以及/var/log/messages中的资源代理输出。
生产环境的集群不仅要关注资源能否启动，还要关注法定人数与隔离策略。当节点数较少时，建议明确设置no-quorum-policy=freeze或stop，避免在失去法定人数时出现双主。同时必须配置合适的fence设备，而不是长期关闭Stonith。没有Stonith的高可用集群在网络分区时无法确定节点状态，可能导致共享存储数据损坏。即使使用虚拟机环境，也可以使用fence_virsh等代理模拟隔离。
另外，集群配置变更应走规范流程，避免在业务高峰直接修改资源约束。可以借助pcs cluster cib backup.xml备份当前配置，测试时使用pcs resource unmanage webgroup让资源暂时脱离集群管理，完成变更后再执行pcs resource manage webgroup恢复。这样可以减少误操作对线上服务的影响，也便于快速回滚到历史配置。
