2. RHEL高可用集群架构与核心组件

RHEL 高可用集群不是单一软件，而是一组协同工作的组件栈。理解这套架构的关键，是分清“谁负责决策、谁负责通信、谁负责操作、谁负责隔离、谁负责仲裁”。在 RHEL 7/8/9 中，标准栈由 Pacemaker、Corosync、pcs/pcsd 以及 stonith 设备共同构成，它们各自承担不同职责，又通过明确的接口耦合在一起。

一、组件分层与职责边界

从下往上看，Corosync 是集群通信引擎，负责成员关系维护、心跳检测和消息传递。它不决定资源该跑在哪里，只保证节点之间“能可靠地互相说话”。Pacemaker 是集群资源管理器（CRM），运行在 Corosync 之上，负责集群状态机、资源调度、故障检测和恢复决策。pcs 是命令行管理工具，pcsd 是它的后台守护进程，二者共同提供配置、查询和远程管理能力。stonith 是隔离机制，当节点状态不可信时，通过带外电源、IPMI、iLO、虚拟机管理接口等方式强制重启或断电，防止“脑裂”导致数据损坏。

这四层的关系可以用一句话概括：Corosync 负责“看得见彼此”，Pacemaker 负责“决定谁做什么”，pcs/pcsd 负责“让人能管”，stonith 负责“在必要时强制清场”。

二、Pacemaker：集群的“大脑”

Pacemaker 的核心是 CIB（Cluster Information Base），它是一份 XML 格式的集群配置与状态数据库，记录资源定义、约束、节点属性和当前运行状态。Pacemaker 内部由多个守护进程协作：pacemakerd 负责拉起其他组件，pengine 是策略引擎，根据 CIB 和当前状态计算“理想状态”，crmd 负责执行决策，stonithd 负责调用隔离设备，attrd 管理节点属性，lrmd 在本地执行资源代理。

资源代理（Resource Agent）是 Pacemaker 操作资源的“手”。RHEL 提供 LSB、OCF、systemd、service 等多种类型，生产环境优先使用 OCF。例如一个 OCF 资源 ocf:heartbeat:IPaddr2 负责管理浮动 IP，ocf:heartbeat:Filesystem 负责挂载文件系统。Pacemaker 不直接“懂”Apache 或 PostgreSQL，它通过资源代理的 start/stop/monitor 动作来操作。

三、Corosync：集群的“神经系统”

Corosync 负责节点发现、成员关系维护和消息传递。它使用 Totem 协议，通过单播或组播在节点间发送心跳。关键参数包括 token（心跳超时，默认 3000ms）、consensus（共识超时）、join（加入超时）。如果 token 超时，Corosync 会认为节点失联，触发 Pacemaker 重新计算资源归属。

Corosync 还负责 quorum 投票。每个节点一票，当存活节点数超过总节点数一半时，集群拥有 quorum，可以正常决策；否则进入无 quorum 状态，Pacemaker 默认会停止资源，避免脑裂。对于两节点集群，通常需要配置 two_node: 1 或使用 quorum 设备，否则一个节点故障后剩余节点无法获得多数票。

四、pcs 与 pcsd：管理入口

pcs 是命令行工具，pcsd 是运行在 2224 端口的守护进程，提供 Web 界面和远程命令执行。典型初始化流程如下：

# 在 node1 上认证节点
pcs host auth node1 node2 node3 -u hacluster -p password

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

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

# 查看状态
pcs status
pcs quorum status

执行 pcs status 后，应看到三个节点均为 Online，quorum 显示 Quorate。若某节点显示 OFFLINE 或 quorum 显示 No quorum，则需检查 Corosync 通信和防火墙端口（5405/udp、2224/tcp）。

五、stonith 隔离机制

stonith 是“Shoot The Other Node In The Head”的缩写。当 Pacemaker 无法确认某节点状态时，必须通过带外方式强制隔离该节点，否则该节点可能仍在运行资源，导致双写。常见设备包括 IPMI、iDRAC、iLO、PDU、虚拟机 fence 等。

配置示例：

pcs stonith create fence_node1 fence_ipmilan \
  ipaddr=192.168.10.11 login=admin passwd=secret \
  lanplus=1 pcmk_host_list=node1

pcs stonith create fence_node2 fence_ipmilan \
  ipaddr=192.168.10.12 login=admin passwd=secret \
  lanplus=1 pcmk_host_list=node2

配置后必须测试：pcs stonith fence node1，观察 node1 是否被强制重启，且 pcs status 中 fence 历史记录正确。未测试的 stonith 配置等于没有隔离能力。

六、quorum 仲裁原理

quorum 的本质是“多数决”。假设 3 节点集群，quorum 为 2。若 node1 和 node2 存活，它们拥有 2 票，可以决策；若只剩 node1，则只有 1 票，无 quorum，Pacemaker 会停止资源。对于 2 节点集群，通常需要 two_node: 1 让 Corosync 在只剩一个节点时仍认为有 quorum，但这会带来脑裂风险，因此必须配合 stonith 使用。

七、组件协同的完整链路

当 node1 上的资源故障时，完整链路是：Corosync 检测到心跳异常 → Pacemaker 的 pengine 重新计算 → crmd 决定在 node2 启动资源 → stonithd 先隔离 node1 → lrmd 在 node2 执行资源代理 start → 资源恢复。整个过程可在 /var/log/cluster/corosync.log 和 pcs status 中观察。

理解这套架构后，后续配置资源、约束、故障切换和排障时，就能快速定位问题出在通信层、决策层还是隔离层。