2. 高可用架构基础

在 Lenovo 高可用企业计算集群的设计与实施中，“高可用”不是一句口号，而是一组可以被量化、被验证、被运维的工程指标。理解这些指标，是后续做冗余拓扑、故障切换、容量规划与 SLA 承诺的前提。本节从可用性度量出发，逐步落到单点故障识别与冗余设计原则，并说明它们在 Lenovo 集群中的具体体现。

一、可用性指标与 SLA：把“不宕机”变成数字

可用性（Availability）通常用一段时间内系统可服务时间占比表示：

可用性 = MTBF / (MTBF + MTTR) × 100%

其中 MTBF（Mean Time Between Failures，平均无故障时间）反映系统平均能连续正常运行多久；MTTR（Mean Time To Repair，平均修复时间）反映从故障发生到恢复服务平均需要多久。两者共同决定可用性：提高 MTBF 或降低 MTTR 都能提升可用性，而降低 MTTR 往往更可控、更经济。

业界常用“几个 9”描述可用性等级。以一年 365 天为基准，常见换算如下（示例值，用于理解量级）：

SLA（Service Level Agreement，服务等级协议）就是把可用性目标、故障响应时间、恢复时间目标（RTO）、数据恢复点目标（RPO）等写成可考核的承诺。例如某 Lenovo 集群承载核心数据库，SLA 可约定：可用性不低于 99.99%，RTO ≤ 30 分钟，RPO ≤ 5 分钟。注意：SLA 是“对外承诺”，而 MTBF/MTTR 是“内部度量”，设计时必须让内部指标留有余量，才能稳定兑现 SLA。

二、单点故障：高可用设计的第一敌人

单点故障（SPOF，Single Point of Failure）指系统中某个组件一旦失效，就会导致整体服务中断。识别 SPOF 是高可用设计的第一步。Lenovo 集群中常见的 SPOF 包括：单台管理节点、单条上联链路、单个电源模块、单台存储控制器、单台交换机、单一心跳网络、单实例数据库、单份配置文件等。

识别方法可以按“路径法”进行：从客户端请求出发，沿数据流/控制流逐段检查，任何一段只有唯一实例且无旁路，就是潜在 SPOF。例如：客户端 → 接入交换机 → 负载均衡 → 应用节点 → 数据库 → 存储，若其中任一环节只有单台设备且无冗余，则该环节即为 SPOF。

三、冗余设计原则：从“有备份”到“可切换”

冗余不是简单“多买一台”，而是要让冗余真正可用。核心原则包括：

• 消除单点：关键路径上每个组件至少两个实例，且相互独立。
• 故障域隔离：冗余实例应分布在不同机箱、不同机柜、不同供电、不同交换机，避免同一故障同时影响两者。
• 可检测与可切换：必须有健康检查、心跳与自动/手动切换机制，否则冗余只是“冷备”。
• 避免共因故障：同一版本缺陷、同一配置错误、同一供电回路都可能让冗余同时失效。
• 冗余也要可维护：支持在线更换、在线扩容，避免维护本身造成中断。

在 Lenovo 集群中，这些原则体现为：双管理节点/双控制平面、双上联链路与堆叠/M-LAG、双电源与双路供电、RAID 与多路径存储、数据库主备/集群、心跳与仲裁网络分离、配置与镜像统一管理等。下面用一张结构关系图展示“单点故障 → 冗余替换 → 可用性提升”的核心逻辑。

四、从指标到落地：一个可参考的可用性估算示例

假设某 Lenovo 集群单节点 MTBF 为 20000 小时，MTTR 为 4 小时，则单节点可用性约为 20000/(20000+4) ≈ 99.98%。若采用双节点主备，且切换时间约 5 分钟（0.083 小时），则系统可用性可提升到约 99.999% 量级（示例估算，实际受切换成功率、共因故障影响）。这说明：冗余的价值不仅在于“多一台”，更在于把 MTTR 从小时级压缩到分钟级。

五、实施检查要点

• 列出关键路径上的所有组件，逐一标注是否存在 SPOF。
• 为每个 SPOF 设计冗余方案，并确认故障域是否隔离。
• 配置健康检查与自动切换，定期做切换演练并记录实际 MTTR。
• 把 SLA 目标拆解为各层的可用性预算，避免单层过度承诺。
• 监控 MTBF/MTTR 趋势，用真实数据反推设计薄弱点。

掌握这些基础后，后续的集群拓扑、存储双活、网络冗余与故障切换策略，才有统一的度量尺度和设计依据。