4、高可用性概念：HA的定义、IB网络中的单点故障、RTO/RPO

各位好，咱们今天聊聊高可用性。这个词儿在IB网络里，说白了就是——别让业务断了。

我刚开始接触InfiniBand的时候，觉得这玩意儿不就是个高速网络嘛，性能拉满就完事了。直到有一次，一个集群因为一根线缆松动，整个训练任务挂了三天。嗯，从那以后，我再也不敢忽视高可用性了。

4.1 高可用性（HA）的定义

高可用性，英文叫High Availability，简称HA。它的核心目标很简单：系统在出现故障时，依然能对外提供服务。

你想想看，一个IB网络里跑着几百个GPU节点，正在做分布式训练。突然某个交换机挂了，或者某根线缆断了。如果没有HA，整个集群就瘫痪了。有了HA，业务还能继续跑，顶多性能降一点。

我个人习惯把HA理解成三个层次：

• 硬件冗余：双网卡、双交换机、双线缆
• 链路冗余：多路径、链路聚合
• 故障切换：自动检测、自动切换、自动恢复

说白了，HA就是给系统买了一份「意外险」。平时用不上，但真出事的时候，能救命。

4.2 IB网络中的单点故障

单点故障，英文叫Single Point of Failure，简称SPOF。意思就是——只要这个点挂了，整个系统就挂了。

我在项目中遇到过不少单点故障的案例。最典型的有这么几种：

4.2.1 单网卡故障

一台计算节点只有一张HCA卡。这张卡坏了，节点就失联了。你想想看，一个训练任务跑了一半，突然一个节点掉线了，整个任务都得重来。

4.2.2 单交换机故障

整个集群只靠一台核心交换机。这台交换机挂了，所有节点之间的通信都断了。我记得有一次，一个客户的数据中心因为交换机电源模块故障，整个集群停了8个小时。

4.2.3 单线缆故障

一根光纤断了，导致某个节点无法访问存储。嗯，这种问题其实最常见。线缆被踩断、被老鼠咬断、被机柜门夹断……我都见过。

4.2.4 单控制器故障

有些IB交换机是模块化设计的，只有一个管理控制器。这个控制器挂了，交换机虽然还能转发数据，但你没法配置它了。说白了，变成了一个「黑盒子」。

4.3 HA的衡量指标：RTO和RPO

聊完了单点故障，咱们得说说怎么衡量HA的好坏。两个核心指标：RTO和RPO。

4.3.1 RTO（恢复时间目标）

RTO，全称Recovery Time Objective。说白了就是——从故障发生到系统恢复，需要多长时间。

举个例子：

• 如果RTO是5分钟，意味着故障发生后，5分钟内必须恢复
• 如果RTO是1小时，意味着你可以慢慢修，1小时内搞定就行

我个人的经验是：RTO越短，成本越高。你想实现秒级切换，就得部署双活架构，成本翻倍。如果业务能接受几分钟的停机，那用主备模式就够了，成本低很多。

4.3.2 RPO（恢复点目标）

RPO，全称Recovery Point Objective。说白了就是——你能容忍丢失多少数据。

举个例子：

• 如果RPO是0，意味着不能丢任何数据，必须实时同步
• 如果RPO是1小时，意味着可以丢1小时的数据，每小时备份一次就行

在IB网络中，RPO通常跟存储相关。比如分布式文件系统，如果RPO是0，那所有写操作必须同步复制到备节点。如果RPO是5分钟，那可以异步复制，每5分钟同步一次。

4.4 RTO和RPO的权衡

你想想看，RTO和RPO其实是矛盾的：

指标	要求	实现方式	成本
RTO=0	零停机	双活架构、自动切换	极高
RTO=5分钟	快速恢复	主备模式、预配置	中等
RTO=1小时	可接受停机	手动切换、冷备	较低
RPO=0	不丢数据	同步复制	极高
RPO=5分钟	少量丢失	异步复制	中等
RPO=1小时	可接受丢失	定时备份	较低

说白了，没有完美的HA方案，只有适合业务的HA方案。我曾经帮一个客户做方案，他们要求RTO=0、RPO=0，但预算只有10万。嗯，这显然不现实。最后我们沟通了三次，才把需求调整到RTO=5分钟、RPO=1分钟，预算也翻了一倍。

4.5 小结

这一章咱们聊了三个核心概念：

• HA的定义：让系统在故障时依然能提供服务
• 单点故障：网卡、交换机、线缆、控制器，处处是坑
• RTO/RPO：衡量HA好坏的两个指标，决定了方案的成本和复杂度

下一章，咱们会深入IB网络的具体HA方案，包括链路聚合、多路径、故障切换等实战内容。到时候我会分享一些我在项目中踩过的坑，以及怎么填坑的经验。

嗯，今天就到这儿。记住一句话：HA不是锦上添花，而是雪中送炭。平时多花点心思在HA上，出故障的时候你就知道值了。