Pacemaker：集群资源管理器

8次阅读

获取下载链

微信关注「软件教程管家」公众号，回复 pacemaker

一台服务器挂了，服务能不能自己漂到另一台上继续跑，是很多线上系统最怕被问到的问题。Pacemaker 就是管这件事的集群资源管理器：它协调多节点之间相互依赖服务的配置、启动、监控与故障恢复。本篇讲清楚：高可用集群到底交给 Pacemaker 管什么、部署前先确认什么、装完先改哪几处配置，并给出分支与集群形态的取舍结论。

Pacemaker 软件信息表

项目	内容
软件名称	Pacemaker
软件类型	高可用集群资源管理器
所属项目	ClusterLabs 高可用集群栈
实现语言	C
适用平台	Linux（具体发行版与依赖以 INSTALL.md 为准）
核心职责	服务配置、启动、监控、故障恢复
获取方式	官方仓库源码与发行版软件包

版本选择：高可用集群先定分支与集群栈

结论先行：用当前受支持的发布分支搭新集群，不要拿已冻结的旧系列或主分支直接上生产。主分支面向新开发，功能最新但变动也最频繁；受支持的发布分支经过收敛，更适合承载线上服务；已冻结的旧系列只适合查资料与做迁移对照，不适合新部署。

选择	适合谁	不适合谁
当前受支持的发布分支	要上线生产高可用服务、求稳的团队	要尝鲜未发布新功能的人
主分支	参与开发、验证新功能的开发者	直接承载线上业务的团队
已冻结的旧系列	维护历史系统、做迁移对照的人	新建集群的团队

安装与部署：只抓关键卡点

先按仓库里的 INSTALL.md 核对操作系统、运行时依赖与集群通信组件：据官方文档说明，摘要里没有完整列出这些前置条件，跳过这一步直接装，装完才发现缺组件是最常见的返工。
先把集群通信层与节点互信配通，再定义任何资源：节点之间连不通、互相认不出来，后面所有资源定义都无从谈起。
资源定义先从一个最简单的服务起步，跑通启动、停止与状态监控，再逐步加依赖关系与约束，不要一次性把全套依赖写进去再排错。
正式接管业务服务之前，先做一次故障演练：主动停掉一个节点或一个服务，看资源是否按预期漂移与恢复，演练没通过不要上线。
把集群配置纳入版本管理：资源定义、约束与故障策略改动都有记录，出问题才能回溯到某一次变更。

装完必改设置：高可用集群跑稳的四处配置

集群属性配置（集群管理工具的全局属性）：把仲裁与节点失联后的处理策略按节点数定下来，体感差别是网络分区时集群不再两边各行其是，脑裂风险被关在策略之内。
资源监控间隔（资源定义中的监控操作参数）：给每个受管服务设合理的监控间隔与超时，体感差别是服务假死能被及时发现，而不是等用户报障才知道服务早已停摆。
故障恢复策略（资源定义中的恢复与迁移参数）：明确失败后是原地重启、还是漂移到其他节点、重试几次后放弃，体感差别是故障发生时系统按预定剧本行动，而不是每次都靠人工半夜登录处理。
资源启动顺序与依赖约束（约束配置）：把相互依赖的服务写成明确的先后顺序与同节点约束，体感差别是集群重启后服务按正确顺序依次起来，不再出现依赖服务还没就绪、下游服务先启动失败的连锁报错。

使用 Pacemaker 的注意事项

它不是单机服务管理器：据官方文档说明，Pacemaker 需要置于完整的高可用集群环境中评估，只有一台机器时不要硬套这套方案，单机场景用系统自带的服务管理就够了。
资源代理范围要提前确认：据官方文档说明，摘要没有列出具体资源代理与第三方集成清单，要管的服务类型是否已有现成代理，必须先查文档或源码确认，缺代理时要自己写或另选方案。
故障策略必须演练过才算数：纸面上的恢复策略没经过断网、宕机演练，等于没有策略，上线前至少跑一次节点故障与服务故障两种演练。
升级要按分支走：跨大版本升级前先看该分支的升级说明与兼容性提示，集群各节点尽量保持版本一致，混用版本容易出现行为不一致。
不要把集群配置只留在某台机器上：配置丢失或节点重建时，没有版本化的配置就等于要重新搭一遍集群。

适用人群与横向对比

适合的人群是：需要在多个节点之间管理服务生命周期、监控资源状态并执行恢复流程的系统管理员与平台工程师，以及建设高可用基础设施的团队。不适合的人群是：只需要单机服务启停的个人用户，以及还没有集群通信、节点规划与故障演练条件的团队——先补齐集群基础再谈资源管理。

横向看，Pacemaker 的分工边界是资源层：它管的是服务在节点之间怎么起、怎么监控、挂了怎么办；至于服务本身的部署、配置下发与应用发布，那是另外一层工具的职责。把这两层混在一起，要么是集群配置里塞满应用部署逻辑，要么是部署工具越俎代庖做故障漂移，最后两边都不好维护。

再补一个选型时的判断方法：先列出必须被集群管理的服务清单，再逐个确认每个服务有没有现成资源代理、监控方式是否满足要求、故障后能不能接受自动漂移带来的短暂中断。这三项都确认通过，Pacemaker 才算真正适合；任何一项含糊，都应该先在测试集群里验证通过再谈上线，否则上线后才发现的缺口，修起来比事前验证贵得多。