1. Pacemaker高可用方案概览
1.1 Linux高可用体系结构
在 Linux 高可用领域，Pacemaker是核心的资源管理器，而 Corosync 提供组网、成员资格和消息传递，构成高可用集群的底层架构。Pacemaker + Corosync 的组合能够实现对关键服务的自愈能力、自动故障转移，以及对集群状态的可观测性与可控性。
对于需要连续性运行的生产系统，高可用方案往往围绕资源的创建、约束、以及故障隔离展开。本文将以 Pacemaker 为核心，结合 STONITH（ fence）设备实现可靠的故障隔离，确保在分区时避免数据不一致与脑裂现象。
1.2 Pacemaker在高可用方案中的角色
Pacemaker负责资源的生命周期管理、故障转移策略、以及在发生故障时对资源进行自动迁移。通过与 Corosync 的通信实现集群成员的状态同步，并通过各种资源代理（ocf、systemd、LVM 等）对不同服务进行封装。
在实际部署中，STONITH提供硬件级别的故障隔离，确保集群在分区情况下不会出现数据冲突。通过设置合适的 资源属性、约束 与 优先级，可以实现对主服务的稳健保护与按策略的故障转移。
2. 环境准备与前提
2.1 硬件与网络拓扑
建议采用至少三节点的集群，以实现多数表决并提升容错能力，确保 quorum 机制正常工作，避免脑裂。每个节点应具备独立的网络路径、对关键存储的并发访问能力，以及冗余电源与网络设备，以降低单点故障对服务的影响。 网络拓扑一致性 是高可用方案成败的关键因素。
在数据库或存储密集型场景中，节点之间需要共享存储或通过同步复制来确保数据一致性。此时要额外关注 存储带宽、延迟和并发访问控制，并在拓扑设计阶段预留扩展能力。
2.2 软件依赖与版本规划
操作系统建议使用 CentOS/RHEL 8/9、或 Debian/Ubuntu 的长期支持版本，确保与 Pacemaker、Corosync 及 fencing 代理的版本兼容性。通过官方仓库或受信任镜像源进行安装，避免二进制不匹配导致的集群不稳定性。软件版本一致性有利于集群行为在不同节点间保持一致。
核心组件包括 pacemaker、corosync、以及 fence-agents，并可能根据硬件厂商提供厂商特定的 fencing 客户端。准备阶段应先确认各节点的时间同步与域名解析稳定，以避免时钟漂移带来的群组成员认知差异。
# 安装依赖（示例，按发行版调整）
sudo apt-get update && sudo apt-get install -y pacemaker corosync fence-agents-all
# 或在 RHEL/CentOS 上
sudo yum install -y pacemaker pacemaker-cli fence-agents-all corosync
3. Pacemaker集群搭建步骤
3.1 集群初始化与证书管理
在开始搭建前，确保各节点的主机名唯一且可解析，时间同步到同一时间源。使用 pcs 工具进行集群的认证、初始化与启动，可以显著简化工作流。初始化阶段的正确性决定后续故障转移行为的稳定性。
通过统一的鉴权、授权和集群设置，可以确保成员之间的互信，降低后续运维成本。集群初始化需要一致的配置来避免分布式一致性问题的产生。
# 集群认证与初始化示例
pcs cluster auth node1 node2 node3 -u hacluster -p yourpassword --force
pcs cluster setup --name ha-cluster node1 node2 node3 --force
pcs cluster start --all
pcs status
3.2 配置STONITH与资源代理
STONITH 是高可用体系的核心安全组件，负责在节点失效时对故障节点上的资源进行切断，防止数据不一致。务必启用 fencing，并为环境选择合适的 fence 设备，如 IPMI、IPMI-over-LAN、或 iLO/DRAC 等硬件接口。STONITH启用是前提。
在配置阶段，可以先创建一个基础的 fencing 设备并启用全局保护。
# 启用STONITH并创建 fence 设备（示例）
pcs stonith create fence1 fence_ipmilan ipaddr=192.168.1.100 login=user password=secret
pcs property set stonith-enabled=true
3.3 常用资源示例与属性
常用资源包括虚拟IP、数据库实例、Web 服务等。为每个资源设置监控周期、超时与重试策略，合理使用 ocf 资源代理可以提升可移植性与互操作性。对关键资源应配置 资源监控间隔 与 超时策略，确保在网络抖动时不会频繁触发不必要的转移。
下面给出一个典型的资源创建示例，便于快速上手并理解依赖关系与约束的作用。
# 创建虚拟IP与Web服务资源示例
pcs resource create vip ocf:heartbeat:IPaddr2 ip=10.0.0.100 cidr_netmask=24
pcs resource create websrv ocf:heartbeat:apache configfile="/etc/httpd/conf/httpd.conf" \
op monitor interval=30s timeout=20s
# 设置资源约束：VIP必须与Web服务在同一节点上就绪，或以某种策略迁移
pcs constraint colocation add vip with websrv INFINITY
pcs status
4. Pacemaker实战配置与故障处理
4.1 迁移、约束与优先级策略
在实际生产中，往往需要通过 location constraint、colocation 与 order 约束来实现迁移策略、提高关键资源的可用性，并确保优先级较高的资源在故障时获得更高的可用性保障。通过这些约束，可以将故障转移路径、优先节点、以及资源的并发控制进行精细化管理。
合理的约束组合能够降低误转移的概率，提升整体集群的稳定性。对不同服务进行分层管理也是常见做法，例如数据库优先级高于应用服务器，以确保在资源紧张时数据库仍保持高可用。
4.2 监控、告警与日志定位
对集群进行持续监控是保障可用性的关键环节。使用 pcs status、/var/log/pacemaker.log 等日志路径可以快速定位问题根源。为了提升运维效率，通常还会接入 Prometheus 与 Grafana，将集群指标可视化，形成直观的看板。
在出现故障时，了解节点间的通信状况、资源状态以及STONITH的执行记录，是排查问题的第一步。保持对日志的定期轮换与归档，也有利于长期的容量规划与故障趋势分析。
# 查看当前集群状态与资源情况
pcs status
# 查看集群详细日志与最近事件
tail -n 200 /var/log/pacemaker.log
4.3 故障模拟与演练场景
通过故障模拟，可以验证故障转移策略的有效性与时效性。常见场景包括节点故障、网络分区、以及 fencing 设备断连等。演练时建议记录转移耗时、资源可用性、以及跨节点的顺序依赖是否得到满足。通过 pcs resource migrate、pcs constraint 与实际演练，可以逐步优化策略。
# 将 VIP 及相关资源从一个节点迁移至另一个节点
pcs resource migrate vip
pcs status
# 动态修改约束以适应演练结论
pcs constraint add relocate vip --resource vip --score INFINITY
5. Linux高可用方案的监控与持续运维
5.1 监控指标与告警
建立全面的监控体系，覆盖集群健康、资源状态、网络延迟与存储状态。Prometheus 与 Grafana 的结合能够将指标可视化，提升运维效率与可观测性。通过告警规则，可以在资源降级、节点下线或 fencing 事件发生时及时通知团队。
同时，应该对 /var/log/pacemaker.log 与系统日志进行聚合与告警，确保在极端情况下也能快速定位根因。持续的监控有助于提前发现容量瓶颈与配置不合理的问题。
5.2 备份、演练与数据一致性
定期备份关键配置与数据，是保持长期可用性的基础。对 Pacemaker 配置、证书、以及相关资源的定义进行版本化管理，配合定期的演练，能显著降低不可用时间。本文所述的高可用方案依赖于对配置的稳定性与一致性保障，因此建议建立自动化备份与演练流程。
# 备份 pacemaker 配置
sudo tar czf /var/backups/pacemaker-$(date +%F).tar.gz /etc/pacemaker /var/lib/pacemaker
# 备份关键数据库（如有）
mysqldump -u root -p'password' --all-databases > /var/backups/db_all.sql
