2. RHEL集群基础与Pacemaker/Corosync架构

在RHEL高可用体系中，真正让两台或多台服务器“看起来像一台”的，并不是某个单独的服务，而是一组协同工作的组件。理解这套组件的分工，是后续搭建、排障和调优的基础。本节围绕集群资源管理器、成员关系、仲裁机制、集群配置文件，以及使用 pcs 与 crm shell 搭建双节点基础集群展开。

一、Pacemaker与Corosync的分工

RHEL高可用集群由两个核心守护进程构成：Corosync 负责集群成员关系与消息传递，Pacemaker 负责资源管理与决策。可以这样理解：Corosync是“神经系统”，负责让节点之间互相感知、传递心跳和投票信息；Pacemaker是“大脑”，根据Corosync提供的成员状态，决定资源应该运行在哪个节点上。

Corosync使用Totem协议在节点间建立环形或全互联通信，通过心跳判断节点存活。当某个节点在规定时间内没有响应心跳，Corosync会将其标记为不可达，并把成员变化通知Pacemaker。Pacemaker收到后触发资源重新计算，必要时在存活节点上启动资源，实现故障转移。

Pacemaker内部由多个组件协作：CIB（Cluster Information Base）保存整个集群的配置与当前状态；CRMd（Cluster Resource Management daemon）是决策核心；LRMd（Local Resource Management daemon）在本地执行资源启停；PE（Policy Engine）根据CIB和约束计算资源应处位置；stonithd负责隔离设备管理。这些组件共同构成资源管理器。

二、成员关系与仲裁机制

集群成员关系由Corosync维护。每个节点启动Corosync后，会尝试加入现有集群；如果集群尚未形成，则参与选举。节点之间通过心跳确认存活，一旦心跳超时，该节点被判定为失效，成员列表随之更新。

仲裁（Quorum）是防止“脑裂”的关键机制。简单说，仲裁要求集群中超过半数节点在线，才允许继续运行资源。双节点集群中，两个节点都在线时票数为2，满足多数；若一个节点失效，剩余节点只有1票，不满足多数，集群会停止资源运行，避免两个节点同时操作同一份数据。因此双节点集群通常需要配置仲裁设备（quorum device）或使用two_node模式配合stonith隔离，才能在一节点故障时仍能继续服务。

仲裁状态可通过 pcs status 查看，输出中会显示 Quorum: Yes/No 以及各节点票数。若显示 Quorum: No，即使节点在线，资源也不会被启动。

三、集群配置文件

Pacemaker的配置保存在CIB中，底层以XML格式存储，通常位于 /var/lib/pacemaker/cib/cib.xml。Corosync的配置位于 /etc/corosync/corosync.conf，定义集群名称、节点列表、通信接口、心跳间隔等。两者分工明确：Corosync配置决定“谁能加入、怎么通信”，Pacemaker配置决定“资源怎么跑、跑在哪”。

使用 pcs 命令时，大部分操作会自动写入CIB，无需手工编辑XML。例如创建资源、设置约束、配置stonith设备，都会实时反映到CIB中。查看当前完整配置可用 pcs config show，查看CIB原始XML可用 cibadmin --query。

四、使用pcs搭建双节点基础集群

以下示例假设两台RHEL主机：node1 与 node2，均已安装 pcs pacemaker corosync fence-agents-all，并配置好主机名解析与时间同步。示例参数为教学假设，实际部署需按环境调整。

# 在两台节点上分别设置 hacluster 密码
echo "ClusterPass123" | passwd --stdin hacluster

# 启动并启用 pcsd
systemctl enable --now pcsd

# 在 node1 上认证 node2
pcs host auth node1 node2 -u hacluster -p ClusterPass123

# 创建双节点集群，指定心跳网卡与加密
pcs cluster setup mycluster node1 node2 --force

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

# 查看状态
pcs status

执行 pcs cluster setup 后，pcs会自动生成Corosync配置并分发到各节点。启动集群后，Corosync建立成员关系，Pacemaker开始管理资源。此时若执行 pcs status，应看到两个节点均为 Online，且 Quorum: Yes。

接下来配置隔离设备（stonith），这是生产集群的必要步骤。示例使用 fence_ipmilan，实际环境可替换为 fence_vmware_soap、fence_redfish 等：

pcs stonith create fence_node1 fence_ipmilan \
  ipaddr=192.168.10.101 login=admin passwd=IPMIpass \
  lanplus=1 pcmk_host_list=node1

pcs stonith create fence_node2 fence_ipmilan \
  ipaddr=192.168.10.102 login=admin passwd=IPMIpass \
  lanplus=1 pcmk_host_list=node2

pcs property set stonith-enabled=true

随后创建第一个资源，例如浮动IP：

pcs resource create ClusterVIP ocf:heartbeat:IPaddr2 \
  ip=192.168.10.200 cidr_netmask=24 \
  op monitor interval=30s

pcs status

资源创建后，Pacemaker会根据默认策略将其启动在某个节点上。使用 pcs resource move ClusterVIP node2 可手动迁移，观察资源是否在目标节点启动、原节点是否释放。若迁移成功，说明成员关系、仲裁与资源管理链路均正常。

五、crm shell的定位

crm shell（crm）是Pacemaker的另一种交互式管理工具，提供更接近配置语法的操作方式。在RHEL中，pcs 是官方推荐工具，功能覆盖更全、与RHEL集成更好；crm 则适合习惯交互式编辑或需要批量导入配置的场景。两者最终都操作同一份CIB，因此可以混用，但不建议同时用两种工具编辑同一配置，以免产生冲突。

掌握以上内容后，集群的“骨架”已经建立：Corosync负责成员与通信，Pacemaker负责资源与决策，仲裁保证一致性，pcs负责日常操作。后续的资源约束、故障转移策略和高级资源类型，都建立在这一基础之上。