Pacemaker+Corosync是Linux高可用集群主流方案，通过Corosync负责心跳与成员管理、Pacemaker调度资源启停，实现服务自动迁移；需确保时间同步、主机名解析可靠、防火墙放行端口；资源配置须建模依赖关系并设约束；运维禁用手动启停服务，维护前应standby节点，fence设备必须配置测试。
Pacemaker + Corosync 是 Linux 高可用集群最主流的组合方案，核心目标是让关键服务（如数据库、Web、文件共享）在节点故障时自动迁移，实现分钟级甚至秒级恢复。它不依赖共享存储，也不强制要求硬件同构，但对网络稳定性、时间同步和配置一致性要求较高。
一、基础组件分工要搞清
Corosync 负责底层通信与成员管理：节点间心跳检测、消息广播、投票仲裁。它不直接管服务启停，只告诉 Pacemaker “谁还活着”。
Pacemaker 是资源管理器：根据 Corosync 提供的集群状态，决定服务该在哪台机器上运行、怎么启动、失败后是否重启或迁移。
二者配合，类似“哨兵+指挥官”——Corosync 看守大门，Pacemaker 调度任务。
二、部署前必须做好的三件事
- 所有节点时间严格同步：用 chrony 或 ntpd，误差控制在 50ms 内，否则 Corosync 可能误判节点离线；
- 主机名解析必须双向可靠：/etc/hosts 或 DNS 要确保每个节点能通过短名（如 node1）和 FQDN（如 node1.example.com）互相解析；
- 防火墙放行关键端口：Corosync 默认用 UDP 5404/5405（多播）或 5404（单播），Pacemaker 用 TCP 2224（pcs 通信）、3121（CRM 接口）；
三、典型资源配置逻辑
高可用不是简单把服务丢进集群，而是按依赖关系建模：
比如一个 Web 服务依赖 IP 地址、文件系统挂载、数据库连接——Pacemaker 会按顺序启动：先申请虚拟 IP → 再挂载共享存储（如 NFS 或 GFS2）→ 最后拉起 httpd 进程。
若某步失败（如磁盘不可写），后续服务不会强行启动，避免数据错乱。
- 用 pcs resource create 定义资源（IP、FS、systemd 服务等）；
- 用 pcs constraint order 设定启动先后；
- 用 pcs constraint colocation 强制资源同节点运行（如 DB 和它的数据盘）；
四、日常运维避坑提醒
- 不要手动 systemctl start/stop 资源服务：Pacemaker 会检测到状态不一致，可能触发 fence（隔离）动作；
- 节点维护前先 pcs cluster standby node1，让它主动释放资源，而非直接关机；
- fence 设备（如 IPMI、DRAC、AWS EC2 API）必须配好且测试通，否则脑裂时无法安全干掉异常节点；
- 配置变更后执行 pcs resource cleanup 清除错误历史，再用 pcs status 确认全绿；
这套机制不复杂，但细节决定成败。配置不是一次写完就完事，要反复模拟节点宕机、网络中断、资源失败等场景验证行为是否符合预期。
