Keepalived、Pacemaker 与 Corosync 高可用集群生产实战

高可用并不是“两个节点加一个 VIP”。生产 HA 需要同时处理故障检测、仲裁、脑裂、Fencing、资源依赖、数据一致性、网络分区、维护与回切。Keepalived 适合 VRRP/VIP 与健康联动；Corosync 提供集群通信和成员关系；Pacemaker 负责资源调度、约束和故障恢复。本文讲清三者的适用边界和生产方法。

错误的双主、共享存储并发写或错误 Fencing 可能造成数据损坏和服务中断。不要在未验证 STONITH、仲裁和应用一致性前，把两节点集群直接用于关键数据库。

一、先区分高可用层次

网络入口高可用：VIP 在节点间漂移，常用 Keepalived；
无状态服务高可用：负载均衡 + 多实例通常优于主备；
有状态资源高可用：需要资源管理、数据复制、仲裁和 Fencing；
应用原生高可用：数据库/消息系统自身复制与选举；
灾难恢复：跨站点、备份与重建，不等于本地 HA。

在能使用应用原生集群时，不应只靠 VIP 掩盖数据复制和一致性问题。

二、Keepalived 与 VRRP

Keepalived 通过 VRRP 在多个节点中选出 Master，由 Master 持有 VIP。Backup 监测通告，超时后接管。

客户端 → VIP
          ├─ node-a MASTER（持有 VIP）
          └─ node-b BACKUP

基础示意：

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 120
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass replace-me
    }
    virtual_ipaddress {
        10.20.30.50/24 dev eth0
    }
}

生产应使用安全网络隔离，示例认证不能被视为强加密边界。

三、单播、多播与网络要求

云网络和部分数据中心不支持 VRRP 多播，需要配置 Unicast Peer。无论哪种模式，都要验证：

VRRP 协议是否被 ACL/安全组放行；
节点间 MTU、丢包和延迟；
VIP 的 Gratuitous ARP/邻居通告能否更新交换机和客户端缓存；
跨 VLAN、路由、IPv6 NDP 的行为；
虚拟化平台是否允许漂移地址；
网络分区是否会造成两边都持有 VIP。

“节点能 Ping 通”不代表 VRRP 和 GARP 一定正常。

四、Track Script 与健康联动

Keepalived 可以根据脚本调整优先级或进入 Fault。健康脚本必须快速、稳定、超时明确，不能执行耗时全链路任务。

vrrp_script chk_service {
    script "/usr/local/sbin/check-service.sh"
    interval 2
    timeout 1
    rise 3
    fall 3
    weight -30
}

常见误区：

只检查进程存在，不检查端口或关键功能；
检查依赖过深，外部短暂故障导致 VIP 频繁漂移；
脚本没有超时并阻塞；
权重不足以改变选举结果；
所有节点执行同一错误检查，同时退出服务。

五、防止频繁切换

通过 rise/fall、合理检测周期、优先级和 nopreempt 等策略减少抖动。是否自动回切取决于业务：

自动回切可恢复首选节点，但会再次中断连接；
不抢占更稳定，但需要维护后人工回切；
有状态服务应先确认数据角色，不能只按节点优先级抢回 VIP。

六、Corosync 的角色

Corosync 提供集群成员、通信和 Quorum。需要独立稳定的集群网络，配置节点 ID、地址、传输和预期票数。

监控：

corosync-quorumtool -s
corosync-cfgtool -s
pcs status corosync

时间、网络抖动、MTU、防火墙、组播/单播和节点身份错误都可能导致成员关系震荡。

七、Quorum 与两节点集群

Quorum 的目标是让网络分区后只有有权的一侧继续管理资源。两节点集群天然面临 1:1，常配置 two-node 模式并依赖可靠 Fencing，或引入 QDevice 提供外部投票。

不能简单设置 no-quorum-policy=ignore 后就认为问题解决。若双方在网络分区中都继续运行有状态资源，会形成脑裂。

三节点也不代表绝对安全，如果三个节点位于同一故障域或 Fencing 失效，仍可能造成事故。

八、Fencing / STONITH 是核心

Fencing 用外部机制确保故障节点无法继续访问共享资源，常见方式包括 IPMI/Redfish、电源控制、虚拟化平台关机、云 API 或存储隔离。

为什么仅“停止服务”不够：失联节点可能仍运行，只是集群网络断开；它可能继续写共享磁盘或响应旧 VIP。Fencing 提供确定性隔离。

生产要求：

每个节点都有可从其他节点执行的 Fence 设备；
凭证最小权限并安全保存；
动作、超时、重试和主机映射正确；
定期真实测试，不只执行 monitor；
Fence 控制路径不与业务网络同故障域；
两节点避免同时互相 Fencing 的竞态。

九、Pacemaker 资源模型

Pacemaker 可管理 OCF Agent、systemd 服务、VIP、文件系统、数据库等资源。资源应提供可靠的 Start、Stop、Monitor，并正确返回状态。

pcs status --full
pcs resource config
pcs constraint config --full
pcs stonith config

不要把任意脚本包装成服务后就认为具备 HA。Stop 必须能确认资源真正停止，Monitor 要区分“进程存在”和“服务可用”。

十、资源约束

三类核心约束：

Location：资源适合在哪个节点；
Colocation：哪些资源必须同机或不能同机；
Order：启动和停止的先后关系。

典型顺序：

存储激活
  → 文件系统挂载
  → 数据库启动
  → VIP 启用
  → 应用探测通过

停止通常反向执行。不要仅配置启动顺序而忽略 Colocation，否则资源可能分别跑在不同节点。

十一、Resource Group 与 Clone

Group 适合始终同机且按顺序启动的一组资源；Clone 适合每个节点都运行的 Agent；Promotable Clone 适合具有主从角色的资源。

分组虽然方便，但组内前一个资源失败可能影响后续全部资源。应按真实依赖划分，而不是把所有服务塞进一个组。

十二、故障阈值与迁移

Pacemaker 会记录失败次数，并根据 migration-threshold、failure-timeout 和操作策略决定迁移或重启。配置前明确：

一次失败是本地重启还是切换节点；
多久清除失败计数；
启动失败是否触发 Fencing；
资源失败会不会导致整个 Group 迁移；
对数据库而言，切换是否先确认数据角色。

阈值过低会频繁漂移，过高会让故障服务长期留在原节点。

十三、共享存储与数据复制

共享存储必须确保同一文件系统不会被两个非集群文件系统节点同时读写。常见保护：

Fencing；
SCSI-3 Persistent Reservation；
集群文件系统；
明确的独占激活；
资源顺序与 Colocation。

DRBD 等块复制也需要角色、Split Brain 和数据选择流程。不要让 Pacemaker 自动启动一个尚未确认数据最新的副本。

十四、数据库高可用边界

Pacemaker 能启动/停止数据库和漂移 VIP，但不能凭空提供数据库级一致性。必须理解：

数据复制模式与确认级别；
哪个节点拥有最新日志；
切换是否可能丢事务；
旧主如何隔离；
回切如何重新同步；
应用连接池如何重连。

对 PostgreSQL、MySQL、SAP HANA 等应优先采用经过支持的 Agent 和厂商架构。

十五、维护模式

计划维护前先区分：Standby 节点、Unmanage 资源和集群 Maintenance Mode。它们含义不同。

维护流程：

确认当前资源、Quorum、Fencing 与告警健康；
将目标节点设为 Standby 或迁出资源；
等待资源稳定；
执行维护；
恢复节点并观察；
决定是否回切；
清理临时约束和失败计数。

忘记清理临时 Move 约束会导致资源长期不按预期调度。

十六、常见故障

VIP 两边同时存在

立即保护业务写入，检查 VRRP 通信、网络分区、优先级、Track Script 和节点状态。有状态服务还要确认是否发生双写。

资源反复迁移

查看 Operation History、失败计数、Monitor 超时、外部依赖和资源 Agent 日志。不要只提高阈值。

节点故障但资源不接管

检查 Quorum、STONITH、no-quorum-policy、资源约束、失败状态和目标节点能否启动资源。没有 Fencing 成功时，Pacemaker 可能正确地拒绝启动另一份高风险资源。

Fencing 超时

检查管理网络、BMC、凭证、主机映射、电源状态、设备并发与超时。不得通过永久关闭 STONITH 绕过。

十七、监控与告警

至少监控：集群成员、Quorum、Corosync 链路、DC 变化、资源状态、失败计数、迁移、Fencing 成功/失败、VIP 归属、GARP、服务端到端探测、共享存储、复制延迟和配置变更。

外部探测应从真实客户端网络访问 VIP，避免仅在节点本机探测。

十八、故障演练

依次演练：服务进程退出、节点关机、业务网断、集群网断、BMC 不可用、磁盘故障、共享存储断开、单侧网络分区和机房故障。每次记录：检测时间、Fence 时间、切换时间、连接恢复、事务丢失和人工步骤。

网络分区演练具有高风险，应在隔离测试环境或严格受控窗口执行。

十九、上线清单

HA 层次与应用原生能力边界清晰；
同一故障域不会同时失去全部节点与 Fence 控制；
Corosync 通信和 Quorum 已验证；
每个节点的 Fencing 真实执行成功；
资源 Agent、约束、超时和阈值符合业务；
有状态服务旧主能够确定性隔离；
维护、切换、回切和数据重同步有手册；
外部探测和全链路故障演练已完成；
HA 之外仍有备份与异地灾备。

参考资料

Keepalived Documentation：https://www.keepalived.org/manpage.html
ClusterLabs Pacemaker：https://clusterlabs.org/projects/pacemaker/
Pacemaker Explained：https://clusterlabs.org/projects/pacemaker/doc/
Corosync Documentation：https://corosync.github.io/corosync/

Keepalived、Pacemaker与Corosync高可用集群生产实战