📚 课程目录第3章集群资源管理与约束实战

3. 集群资源管理与约束实战

在 Pacemaker 集群中，资源管理是决定业务能否真正高可用的核心环节。集群软件本身只负责“决定谁在哪里运行”，而资源代理、资源组、克隆与主从资源、以及各类约束，才共同定义了“业务以什么形态运行、按什么顺序启动、在哪些节点上允许运行”。本节围绕这些对象展开，并给出可验证的配置与故障切换观察方法。

一、资源代理类型：资源如何被集群管理

Pacemaker 通过资源代理（Resource Agent，RA）来启停和监控资源。常见的代理类型有三类：

LSB：即 /etc/init.d/ 下的传统 SysV 脚本，通过 start、stop、status 返回码判断状态，功能较弱，通常只提供启动和停止。
OCF：Open Cluster Framework 代理，位于 /usr/lib/ocf/resource.d/<provider>/，支持 start、stop、monitor、promote、demote、notify 等动作，是生产环境首选。
systemd：直接管理 systemd 单元，适合已被 systemd 接管的服务，但监控粒度通常不如 OCF。

选择代理时，优先使用 OCF，因为它能提供周期性监控（monitor），集群可据此发现资源“进程还在但服务已不可用”的中间状态。例如一个 OCF 的 pgsql 资源，其 monitor 动作会实际连接数据库执行查询，而不仅是检查进程是否存在。

二、资源组、克隆资源与主从资源

单个资源往往不足以支撑业务。例如一个 Web 服务需要 VIP、文件系统、Web 进程三者协同，且必须按“先挂载文件系统、再启动服务、最后暴露 VIP”的顺序运行。这时使用资源组（group）最合适：组内资源作为一个整体调度，默认按声明顺序启动、逆序停止，并且始终运行在同一节点上。

pcs resource create WebFS Filesystem device=/dev/vg01/lvweb \
  directory=/var/www/html fstype=xfs op monitor interval=20s
pcs resource create WebIP IPaddr2 ip=192.168.10.50 cidr_netmask=24
pcs resource create WebSrv systemd:httpd
pcs resource group add WebGroup WebFS WebIP WebSrv

克隆资源（clone）用于需要在多个节点同时运行的资源，典型场景是集群文件系统（如 GFS2）或分布式锁。克隆资源在每个节点上运行一个副本，可配合 clone-max、clone-node-max 控制副本数量。

主从资源（master/slave，也称 promotable）是克隆资源的特殊形态，副本分为 Master 和 Slave 两种角色。同一时刻通常只有一个 Master，其余为 Slave。典型场景是 DRBD 双主复制、数据库读写分离。配置时通过 master 关键字声明，并用 promotable 元属性控制提升行为。

pcs resource create DrbdData ocf:linbit:drbd \
  drbd_resource=r0 op monitor interval=15s role=Master \
  op monitor interval=30s role=Slave
pcs resource master DrbdClone DrbdData \
  master-max=1 master-node-max=1 clone-max=2 clone-node-max=1

三、约束：位置、顺序与排列

约束决定资源“在哪里运行、按什么顺序运行、彼此如何共处”。三类约束各有明确职责：

位置约束（location）：控制资源优先或必须运行在哪些节点。常用 score 表示偏好程度，正分表示倾向，负分表示排斥，INFINITY 表示强制，-INFINITY 表示禁止。
顺序约束（order）：规定资源启动/停止的先后关系，可带 mandatory、Optional 以及 symmetrical 控制停止时是否反向。
排列约束（colocation）：规定资源是否必须运行在同一节点，正分表示必须同节点，负分表示必须分离。

pcs constraint location WebGroup prefers node1.example.com=200
pcs constraint location WebGroup avoids node2.example.com=100
pcs constraint order start WebFS then WebIP
pcs constraint colocation add WebIP with WebFS INFINITY

需要注意：资源组内部已经隐含了顺序与排列关系，因此组内资源通常不需要再单独写 order 和 colocation。约束的评分是相对的，多个约束叠加时，集群会综合计算每个节点的得分，选择得分最高且满足强制约束的节点。

四、故障切换行为验证

配置完成后，必须验证故障切换是否按预期发生。验证的核心是观察资源状态迁移、节点角色变化以及业务是否连续。常用命令包括 pcs status、crm_mon -1、pcs resource move 和 pcs resource clear。

例如，将 WebGroup 手动迁移到 node2，观察 VIP 是否随之漂移、httpd 是否在新节点启动、旧节点是否干净停止：

pcs resource move WebGroup node2.example.com
pcs status
pcs resource clear WebGroup

对于主从资源，可模拟 Master 节点宕机，观察 Slave 是否被提升为 Master，以及 DRBD 数据是否保持一致。验证时应同时检查资源是否进入 FAILED、Stopped 或 Started 状态，并确认没有出现资源“双活”或“脑裂”迹象。

五、验证要点与常见问题

验证故障切换时，建议按以下顺序观察：先用 pcs status 确认初始状态，再触发迁移或模拟节点故障，然后观察资源是否在目标节点进入 Started，最后检查业务端口、VIP 连通性和数据一致性。若资源卡在 FAILED，应查看 /var/log/cluster/corosync.log 和 pcs resource debug-start 输出，判断是代理脚本返回码异常、约束冲突，还是节点间通信问题。

注意：位置约束的 score 是相对值，多个约束叠加时可能互相抵消。若发现资源未按预期迁移，应先用 pcs constraint list --full 查看全部约束及其评分，再判断是否存在冲突。

掌握资源代理类型、组、克隆与主从资源，以及位置、顺序、排列三类约束后，集群的资源调度行为就变得可预测、可验证。实际工程中，建议每次变更约束后都执行一次迁移测试，确保故障切换路径与设计一致。