Pacemaker是依赖Corosync通信层的状态驱动资源协调系统，核心由CIB、PEngine和CRM三大引擎构成，通过约束定义资源拓扑关系，强制启用STONITH保障共享存储安全。

Pacemaker 不是独立运行的“高可用软件”，它必须和底层通信层（如 Corosync）协同工作，才能构成完整可用的 HA 架构。理解它的逻辑，关键在于跳出“单个服务启停”的思维，转向“状态驱动的资源协调系统”。

Pacemaker 的核心不是执行命令，而是持续决策

它不靠人工触发切换，而是基于实时集群视图，不断比对“当前状态”与“期望状态”，自动计算并执行最小变更路径。这个过程由三大引擎驱动：

• CIB（Cluster Information Base）：所有配置（资源定义、约束、节点属性）和当前状态快照都存于此，是 Pacemaker 的唯一事实源；
• PEngine（Policy Engine）：每次集群状态变化（如节点离线、资源失败），它就重新解析 CIB，按规则推演最优资源分布方案；
• CRM（Cluster Resource Manager）：把 PEngine 的决策转化为具体动作——启动、停止、迁移、清理，并调用对应资源代理（RA）执行。

资源不是孤立的服务，而是带关系的拓扑单元

你在 Pacemaker 里定义的从来不只是一个 VIP 或一个数据库，而是一组有依赖、有顺序、有位置倾向的资源集合。例如：

• VIP 必须在文件系统挂载之后才启用；
• 数据库必须在 VIP 和文件系统都就绪后才能启动；
• 这三个资源必须运行在同一节点上（排列约束）；
• 如果主节点恢复，资源默认不会自动切回（需显式设置 resource-stickiness 或迁移阈值）。

这些逻辑全部通过约束（constraints）表达，而非脚本先后顺序。少了约束，Pacemaker 就只剩“随机调度器”。

STONITH 不是可选功能，而是安全底线

很多初学者禁用 stonith-enabled=true 是为了快速验证流程，但这等于拆掉刹车试车。当网络分区发生时，没有 fencing 机制，两个节点可能同时认为自己是主节点，对共享存储并发写入，直接导致数据损坏。Pacemaker 明确要求：只要涉及共享资源（如 NFS、DRBD、SAN），就必须配置 STONITH 设备或代理，并确保其能真实切断故障节点的 I/O 或电源。

Corosync 不是 Pacemaker 的插件，而是它的神经系统

Pacemaker 自身不发心跳、不判断节点存活、不管理组播通信。它完全依赖 Corosync 提供的：

• 成员资格视图（谁在线、谁已退出）；
• 消息可靠投递（配置变更、状态同步）；
• Quorum 计算结果（集群是否具备法定人数）。
  一旦 Corosync 停摆或配置错误（如多播地址冲突、节点名不匹配），Pacemaker 立即失去上下文，无法做出任何有效决策。

配置不是一次写完就结束，而是持续校验的过程

执行 pcs resource create 后，配置只是写入 CIB；真正生效要等 PEngine 下一轮评估。常用验证步骤包括：

• pcs status 查看实时资源分布与节点状态；
• crm_verify -L 检查配置语法与逻辑一致性（尤其注意 STONITH 警告）；
• pcs constraint list 确认约束已加载且优先级合理；
• pcs resource cleanup <resource> 清理失败历史，避免残留状态干扰下次决策。

不复杂但容易忽略