1. Pacemaker在Linux高可用中的角色与架构
1.1 原理与核心组件
Pacemaker 是 Linux 集群环境中的核心资源管理器，负责对集群内的服务进行自动化的故障转移与资源调度。Corosync 提供集群通信、成员资格和投票机制，为 Pacemaker 提供高可靠的消息传递与一致性基础。STONITH（Fence/Stonith）是强制隔离故障节点的关键机制，确保在出现故障时不会出现数据破坏或资源冲突。CIB（Cluster Information Base）以 XML 形式持久化集群状态、资源定义和约束，确保集群在故障后能够快速恢复一致状态。
在一个典型的 Pacemaker 集群中，集群管理器负责资源的创建、依赖关系、约束以及故障转移策略，而 Corosync 处理消息传递与 quorum，以确保在网络分区时集群仍能做出一致决策。通过 STONITH，集群能够对失效节点进行断开，以避免“脑裂”带来的双写冲突和数据不一致。
1.2 高可用的实现目标
高可用性目标通常体现在最短的服务不可用时间、可预测的故障转移和数据一致性上。资源级别的故障转移可以让单个服务在节点故障时迁移到其他节点继续运行，节点级别的故障处理则确保整个节点下线后集群仍能工作。通过配置 优先级、约束和资源集群策略，可以实现对核心服务的优先保护与负载均衡。
实战中，管理员需要关注 投票阈值、准入条件、网络分区处理，以及在多活场景下对不同数据中心的分区容错策略。CLI 与图形化工具（如 pcs、crm）结合使用，能更清晰地表达资源关系和故障转移路径。
1.3 参考体系与部署依赖
要实现稳定的 Linux 高可用，需要基于 一致的时间源、稳定的网络互连和可靠的存储方案。在大规模部署中，通常需要对 网络带宽、延迟和抖动做评估，并对日志级别与监控指标进行规划，以便在故障发生时快速定位原因。版本兼容性也是关键，确保 Pacemaker、Corosync 与 PCS 的版本彼此兼容，避免 CIB 结构变更带来的不兼容问题。
2. Linux高可用搭建前的准备与环境
2.1 环境要求与前置条件
搭建 Linux 高可用环境前需要确认 两台及以上节点、一致的操作系统版本、时钟同步（NTP 或 chrony）以及稳定的网络。公共与私网分离可以提高安全性与性能，确保心跳、投票和数据流不互相干扰。对于存储敏感型应用，建议使用共享存储或分布式存储解决方案，并确保在故障时不会丢写。
另外，硬件冗余（电源、网卡、硬盘）和 一致性配置（内核参数、网络 MTU、防火墙规则）也是确保高可用的基础。请提前计划好各节点的角色分配与故障域策略，以便后续的资源定义更清晰。
2.2 安装包与版本选择
Pacemaker 与 Corosync 的版本要互相兼容，通常使用官方源或企业级仓库提供的打包版本。pcs 是一个常用的命令行界面工具，用于管理 Pacemaker 集群，提供直观的创建、查看与修改操作的能力。建议选择稳定的长期版本，以减少中间版本的变更带来的兼容性风险。
在选择发行版时，注意各自对 STONITH 驱动 的支持情况，例如 fence_ipmilan、fence_apc、fence_virt、fence_ipmi 等。确保目标设备可通过网络被强制屏蔽或重启，以实现正确的故障隔离。
2.3 集群拓扑与网络设计
设计应覆盖 多节点、跨数据中心的高可用场景，其中心跳网络、集群通信网络与漂移数据路径应分离并具备冗余。最小化分区风险的策略包括合理配置 quorum、设置 stale-graph 保护和默认投票，以及在分区时走向一致的执行路径。对网段设计要清晰，确保虚拟 IP 与服务流量的路由稳定可达。
在部署前，应对关键网络组件进行可用性测试，例如断网、带宽抖动和丢包场景，确保 Pacemaker 能在限制条件下仍然做出正确的故障转移决策。
3. Pacemaker集群配置详解
3.1 安装与启用 Pacemaker、Corosync、pcs
安装完成后，先启动 Corosync 与 Pacemaker，再加载集群配置。确保 SELinux、防火墙等安全组件对集群端口开放，避免通信失败导致的不可用。以下是常见的安装和初始化步骤要点：
在生产环境中，强烈推荐使用 pcs 进行集群管理，因为它提供更直观的操作和审计能力。
3.2 创建集群与认证
创建集群通常包含三步：认证节点、创建集群、启动集群。通过认证确保节点间的信任关系，随后汇聚为一个集群并启动状态机。确保节点之间的时间一致、用户名和权限正确，以便正确完成认证和后续操作。
# 在集群中的任意一个节点执行
sudo yum install -y pacemaker corosync pcs
sudo systemctl enable --now corosync
sudo systemctl enable --now pacemaker
# 设置集群管理员账户（示例）
sudo useradd hacluster
sudo passwd hacluster# 授权其他节点加入集群
pcs cluster auth node1 node2 -u hacluster -p 你的密码 --force# 创建集群（名称可自定义）
pcs cluster setup --name mycluster node1 node2# 启动集群中的所有节点
pcs cluster start --all# 查看集群状态
pcs status
注意：在多节点环境中，确保每个节点的 clock synchronization 与 hostname 配置正确，否则认证和成员资格可能失败。
3.3 资源管理与约束
资源定义是 Pacemaker 高可用的核心，通过创建虚拟 IP、实际应用服务、以及必要的存储资源来实现故障转移。资源之间的依赖关系与约束决定了故障转移路径，正确的约束能避免资源在错误节点上启动，提升稳定性。
下面给出一个简单的示例，包含虚拟 IP、Web 服务与一个监控脚本的组合资源。你可以通过 pcs 命令来创建和修改这些资源。
# 创建一个虚拟 IP 资源（如 192.168.1.100）用于对外访问
pcs resource create VIP_IP ocf:heartbeat:IPaddr2 ip=192.168.1.100 cidr_netmask=24 op monitor interval=30s# 将 Apache HTTP 服务作为资源进行管理
pcs resource create HTTP_Service ocf:heartbeat:apache configFile="/etc/httpd/conf/httpd.conf" status=0 op monitor interval=60s# 设定资源间的约束：VIP_IP 与 HTTP_Service 必须在同一节点上运行
pcs constraint colocation add VIP_IP HTTP_Service INFINITY# 设置容错策略：如果 VIP_IP 落点不可用，自动切换到能提供服务的节点
pcs constraint order VIP_IP then HTTP_Service
高级用法还包括对数据库、存储、消息队列等服务的专用 OCF 驱动的使用，以及为资源设置自定义监控、迁移策略与资源组的打包。
3.4 STONITH配置
STONITH 用于对失效节点进行物理级隔离，确保在复杂分区或错误写入场景中不会出现写冲突和数据损坏。为集群启用合适的 fencing 设备，并确保设备可被集群访问。常用的实现方式包括 fence_ipmilan、 fence_ipmi、 fence_apc 等。
下面给出一个简化的 STONITH 配置示例，实际环境应结合设备与网络结构进行调整。配置完成后应先在测试环境验证可用性再投产。
# 以 fence_ipmilan 为例创建 fencing 设备
pcs stonith create my-fence fence_ipmilan ipaddr=192.168.1.50 login=admin passwd=secret lan=1# 验证 STONITH 节点隔离功能
pcs stonith show
4. 实战要点与故障排除
4.1 故障转移策略与优先级
优先级（Resource Priority）与约束（Constraints）决定了在节点失败时哪些资源优先迁移以及应该在哪些节点上保持可用。通过设定 资源组、资源顺序和互斥约束，可以实现对关键服务的保护和对非核心服务的弹性扩展。定期对策略进行演练，确保在实际故障时不会出现不可预测的副作用。
在生产环境中，建议为核心业务配置 最小化故障转移时间 的监控与快速诊断路径，例如结合日志聚合、告警阈值和自动化回滚机制，以降低人工干预带来的延迟。
4.2 常见问题诊断
遇到集群不可用或故障转移异常时，优先通过工具获取当前状态：pcs status、crm_mon、以及节点级别的资源状态。查看 CIB 的最新快照，识别是否存在冲突约束、资源死锁或 STONITH 未就绪等问题。
另外，核对网络连接、时钟同步、以及防火墙策略是否影响到集群通信通道。日志分析是关键，应重点关注 /var/log/cluster、/var/log/messages、/var/log/syslog 等日志来源。
4.3 维护与升级实战
维护和升级时，建议采用分阶段、可回滚的策略：先在测试环境验证新版本兼容性，再在部分节点滚动升级，最后完成全量升级。备份 CIB（集群信息库）与关键资源配置，在升级前后进行对比，确保一致性。定期清理过期的约束与资源定义，避免配置冗余导致的性能下降。
在变更管理方面，记录每次修改的目标、影响范围和回滚方案，确保运维团队在需要时能够快速恢复到稳定状态。监控与告警策略应同步更新，以覆盖新资源及新拓扑的变化。
