1. 课程导入与高可用工程全景

在关键业务系统里，停机从来不是“服务器重启一下”这么简单。一次计划外中断往往同时触发订单流失、支付失败、客户投诉、SLA 违约赔付和品牌信任下降。以电商交易系统为例，若核心交易链路每分钟承载约 300 笔订单、客单价 200 元，则 10 分钟不可用意味着约 60 万元直接交易损失；若叠加数据库主库故障后的数据修复、人工对账和客户补偿，实际代价通常远高于交易额本身。因此，高可用工程的目标不是“永不宕机”这一口号，而是把故障发生后的业务中断时间压缩到可接受范围，并让恢复过程可预测、可验证、可复盘。

RHEL HA Add-On（High Availability Add-On）正是红帽为企业级 Linux 提供的集群化高可用能力集合。它并不替代应用自身的高可用设计，而是把多台独立服务器组织成一个协同工作的集群，通过心跳、成员管理、资源调度和故障转移，让业务在单点故障时仍能继续提供服务。其核心价值可以概括为三点：第一，把“单机可靠性”升级为“集群级冗余”；第二，把人工切换变成自动故障转移；第三，把零散的启动脚本、VIP、文件系统和数据库服务统一纳入可编排、可观测的资源模型。

技术栈全景：Pacemaker、Corosync 与资源代理

RHEL HA Add-On 的技术栈由三层构成。最底层是 Corosync，负责集群成员关系、心跳检测和消息传递。它通过多播或单播在节点之间持续交换心跳，一旦某节点在设定时间内未响应，Corosync 会将其判定为失效并通知上层。中间层是 Pacemaker，它是集群的“大脑”，负责资源管理、约束计算、故障转移决策和状态机维护。Pacemaker 不直接操作业务进程，而是通过资源代理（Resource Agent）完成具体动作。最上层是 资源代理，常见类型包括 LSB、OCF、systemd、STONITH 等。OCF 代理最常用，它把 VIP、Apache、PostgreSQL、NFS、iSCSI 等对象抽象为可 start、stop、monitor、promote、demote 的标准资源。

理解这三层分工，是后续所有实验和排障的基础。Corosync 决定“谁还活着”，Pacemaker 决定“谁该运行什么”，资源代理决定“具体怎么启动和检查”。三者缺一不可：Corosync 误判会导致脑裂，Pacemaker 约束错误会导致资源漂移，资源代理 monitor 不准确则会让故障转移形同虚设。

集群工程生命周期：从规划到复盘

高可用集群不是装完就结束的软件，而是一项持续运行的工程。完整的生命周期通常包含六个阶段。规划阶段要明确业务 RTO（恢复时间目标）和 RPO（恢复点目标），例如“交易系统 RTO ≤ 5 分钟、RPO = 0”，并据此决定节点数量、仲裁方式和存储方案。部署阶段完成 Corosync 配置、Pacemaker 启动、资源创建和约束定义。验证阶段不能只看 pcs status 是否全绿，而要主动注入故障，观察资源是否按预期迁移。

运维阶段关注日常监控、日志轮转、配置备份和版本变更。演练阶段定期模拟节点断电、网卡故障、数据库进程崩溃等场景，验证切换时间和数据一致性。复盘阶段则把每次故障和演练转化为改进项，更新 runbook 和监控阈值。很多团队失败的原因不是技术选型错误，而是把集群当成“一次性项目”，缺少验证和演练，导致真正故障时才发现 STONITH 未配置、quorum 策略不合理或资源 monitor 间隔过长。

学习路线与关键判断依据

本课程后续将沿着“概念—部署—资源—约束— fencing—存储—数据库—排障—演练”的路径展开。学习时建议始终带着三个问题：第一，这个组件解决的是“检测故障”还是“决策转移”还是“执行动作”？第二，如果它失效，集群会脑裂、停摆还是误切换？第三，我如何用命令和日志证明它工作正常？例如，判断 Corosync 是否健康，可以查看 corosync-cfgtool -s 和 pcs status corosync；判断 Pacemaker 决策是否符合预期，可以查看 pcs status、pcs constraint list --full 和 crm_simulate；判断资源代理是否可靠，可以手动执行 ocf-tester 或查看 /var/log/cluster/ 下的日志。

最后需要强调：高可用不等于容灾，也不等于备份。HA 解决的是节点级故障时的服务连续性，容灾解决的是机房级灾难，备份解决的是数据误删和逻辑损坏。三者是互补关系，不能互相替代。在 RHEL HA Add-On 的工程实践中，只有把技术栈、生命周期和验证方法统一起来，才能让关键业务真正具备可承诺的可用性。