软硬件层面的RAS技术系统性综述

RAS指的是Reliability可靠性、Availability可用性、Serviceability可服务性这三个属性，主要用于衡量计算机系统的稳定性和可维护性。

从单机到智算中心，算力每跃升一个量级，硬件故障率就几乎线性翻倍。若缺乏系统化的RAS设计，每一次微小失效都可能触发checkpoint丢失、作业重排、GPU空转，从而浪费算力投资。

本文将拆解 RAS 技术体系，先厘清 RAS 的核心定义与度量指标，再从硬件与软件层，剖析软硬件协同下 RAS 技术的全景，再对典型的RAS进行举例说明。

一、RAS的相关概念

1．RAS

RAS是在上个世纪60年代由IBM在推出System/360 大型机时明确提出并系统化实践的。IIBM System/360目标是创建了一个从科学计算到商业事务处理都能覆盖的统一、可扩展的计算机家族，因此系统必须足够可靠、稳定，这样才能跑企业的核心业务。IBM将可靠、稳定这个愿景用RAS进行承载，还使用了量化指标（平均无故障时间、现场换模件时间）来对其进行度量。（蓝色巨人真不愧是IT界的先驱）。

(1)Reliability可靠性：系统能“多久不坏”的能力。

Intel文档中给的定义是：可靠性通常指系统持续产生正确结果、确保数据完整性的能力。高可靠性系统的组件故障发生率低，且具备检测、隔离、修正、记录错误并发出信号的能力。

常见衡量指标有：

MTBF：平均无故障时间。越高说明系统可靠性越高，故障发生的频率越低。

MTTF：平均失效前时间。越高说明系统或组件的寿命越长，可靠性越好

AFR：年故障率

FIT：10^9 小时内的失效次数

(2)Availability可用性：系统坏的时候还能继续用的能力。

Intel文档中给的定义是：可用性指系统即使在出现错误或故障时，仍能保持运行的能力。高可用性系统具备故障处理能力，可剔除故障单元或在降级模式下运行，最大限度减少应用中断，延长系统正常运行时间。

常用衡量指标有：

可用性百分比：常用“9 的数量”来描述（如 “4 个 9”“5 个 9”），9越多可用性越强。

比如容错机的可用性一般需要5个9，即99.999%。代表系统在连续运行1年时间里最多可能的业务中断时间是5.26分钟（(1-99.999%)*365*24*60）。

可用性有多贵呢？

2024年ITIC对全球 1000 多家企业进行的每小时停机成本调研表明，90% 以上的中型和大型企业，单次一小时停机的平均成本已超 30 万美元。这些成本尚不包括诉讼、民事或刑事处罚费用。

(3)Serviceability可服务性/可维护性：系统坏了多久能修好。

Intel文档中给的定义是：可服务性通常指轻松识别、诊断故障并完成修复的过程，目标是缩短系统停机时间。高可维护性系统的故障可快速修复，使系统尽快恢复至完全运行状态。

常见衡量指标有：

MTTR：平均修复时间（含定位+换件+恢复）

MTTD：平均故障检测时间

热插拔覆盖率：可在线更换部件数/总部件数

诊断准确率：一次定位即命中故障根因比例

2．NFR

上个世纪60年代，“软件危机”日益凸显，软件项目经常超期、软件质量低下、且难以扩展和维护。所以大家认识到，仅仅关注系统要做什么（“功能”）是不够的，还得关心系统做的怎么样才行，做的怎么样，就是NFR（Nonfunctional Requirements ）。

那么NFR有哪些呢？参考下面这张图：

NFR包含性能、可扩展性、可移植性、兼容性、可靠性、可用性、可维护性、安全性、本地化、易用性等。

其中可靠性、可用性就是RAS的RA，而Serviceability可服务性则是可维护性的一个子项。

既然RAS是NFR的一个子集，那么为什么大家都还喜欢说RAS呢？笔者认为，有三方面的原因：

(1)整体性强：RAS三要素紧密耦合，互成因果。可靠性是可用性的基础，可服务性是可用性的保障。它们共同定义了系统是否可靠稳定

(2)历史传承：RAS这个概念起源早，并且通过IBM大型机的成功对行业造成了深刻的影响。

(3)行业背景：RAS是基石，系统不可用或者数据出错会导致财务损失和声誉损失，所以招标文件通常会把RAS相关指标作为独立评分项。

3．DFX

Design For X有两种理解，一种是面向产品生命周期各环节的设计，一种是卓越设计（此时X== Excellent）。

这里的X可以替换成生命周期各阶段（制造M、装配A、测试T、供应S等），也可以替换成竞争力各维度（可靠性R、性能P、成本C等）。

DFX思想萌芽于二战期间的并行工程实践，随着自动化制造的发展，在1950年代出现了DFM/DFA的原型，在1989年DFX名词正式出现，之后逐渐扩展和标准化，成为航空航天、汽车、云硬件、DevOps 设备等领域的通用设计范式。

从覆盖范围来看，RAS是DFX的子集。R由DFR覆盖，S由DFS覆盖，而A由DFR+DFS共同支撑。

从层级来看，RAS是目标，而DFX是方法论。在设计阶段，设计师需要考虑如何达成目标。

二、RAS目标如何达成

要达成RAS目标，需要软硬件共同努力：

1.硬件是RAS的基石，主要目标是预防、检测和隔离硬件故障。

CPU、内存、PCIe交换机、网卡、存储等部件的RAS是服务器领域的“传统艺能”。比如CPU检测指令执行和Cache中的错误、内存ECC、PCIe AER、DPC、IO的CRC、存储的RAID等。

2019年由Intel推出的突破内存墙的CXL互联技术，也一直将RAS作为它的重要部分，有专门的白皮书加以说明。

GPU/DPU/NPU作为异构计算/智算中心的重要组成部分，它们的RAS对业务非常重要。最近，ocp针对超大规模厂商面临的GPU丢失、性能未达标准等痛点，联合微软、谷歌、英伟达推出了《OCP GPU and Accelerators RAS Requirements_1.0》，以期缓解这些问题。

硬件层面为了提高可用性，还经常使用冗余组件的方式，提升系统的容错性。

另外，由于在实际测试的过程中，不一定会遇到所有的错误，为了能测试系统对所有错误的处理是否按预期发生，可以使用故障注入卡来模拟错误场景。

2.BMC提供的带外管理能力是可服务性的核心。

BMC可以理解成在服务器内的、独立于主机的另外一台小电脑，有自己的cpu、存储、网络。当主机故障时，用户仍可以登录到BMC，查看服务器状态，对其进行管理。

BMC可以进行硬件监控与错误检测、事件日志记录与故障诊断、远程管理与维护、错误处理与恢复、远程警报和通知，提升系统的RAS。

3.BIOS是RAS体系的第一道守门员

通过BIOS可以允许管理员对RAS功能进行启用和禁用等配置；BIOS负责上电自检POST，并根据策略容错性启动，避免系统带病运行；还能在致命错误时第一时间“冻结现场”，供OS和BMC进行进一步分析处理。

4.OS是RAS软硬件协同的核心枢纽

内核通过标准化框架EDAC、MCE、PCIe错误处理框架，热插拔、接收硬件错误事件，并进行故障隔离、恢复、故障预测等处理提升系统的RAS。

5.上层软件提升运维效率

上层软件（集群管理、故障管理系统等）收集BMC和OS的RAS相关信息，并以用户友好的方式加以展现提升可服务性。可以从上层软件进行故障预测、隔离、降级等操作。

三、代表性RAS特性简述

1．Intel 至强CPU RAS

Intel是CPU的老大，它的安腾系列处理器更是曾经和IBM小型机打擂台的高端处理器，至强系列处理器更是被广泛应用于数据中心场景。因此他的RAS是做的很好的。

我们来看下Xeon6的RAS吧！

（1）它的RAS特性有：

（2）RAS带内管理首选eMCA2.0的方式:

eMCA2.0架构能在错误信号发送时，向上层软件传递所有严重级别（CE、UCNA、SRAR、UCE）的更丰富错误日志。

它提供增强型错误报告，支持与“固件优先模式（FFM）” 错误处理对齐的多种属性。

（3）RAS带外管理:

有两种方式可供选择，一种是BMC和SMM配合实现，另一种是将RAS处理卸载到BMC。

2．OCP GPU RAS

当前 CPU、内存、I/O、存储等传统硬件的 RAS 技术已成熟，但 GPU/NPU 等 AI 专用硬件的 RAS 机制仍不完善 ——XPU（GPU/NPU）相关故障已成为 LLM 训练中的 “首要硬件故障”，频繁中断训练任务。

下表统计了Llama 3 预训练过程中 “非预期中断” 的具体原因及占比，可见 GPU 相关故障占比很高：

所以当前业界也在进行这方面的研究工作。比如，OCP近期就推出了GPU RAS规范，

该规范聚焦于超大规模场景下GPU 使用过程中的RAS，对GPU系统中组件的RAS要求如下：

(1)内存

内存相关RAS 要求包括内存错误检测、纠正与报告。此外，还需支持以下系统级功能：

页面下线（Page Offlining）、行重映射（Row-Remapping）、坏页屏蔽（Bad-Page Map Out）、错误隔离（Error Containment）

(2)Cache

缓存错误检测、纠正与报告

(3)Accelerator Core

设备核心逻辑内部各类错误的检测、纠正与报告

(4)PCIe I/O

基础错误处理：需支持 PCIe 规范定义的错误检测、纠正与报告功能（AER），同时需支持根端口外设 I/O（Root Port Peripheral I/O, RP_PIO）错误报告。

系统级功能：需支持DPC、暴力热插拔 等系统级功能。

应拒绝执行会消耗“有毒传输层数据包（Poisoned TLPs）” 的操作，并通过向主机发送 “有毒标记” 或拒绝执行任何使用损坏数据的操作，防止主机消耗损坏数据。

(5)互联和交换

需支持供应商自定义的错误检测、纠正与报告功能。此外，还需具备遥测（Telemetry）能力，以检测链路完整性问题。

(6)Re-timers

需支持PCIe 链路信号完整性相关错误及协议错误的收集。

(7)内核AER/DPC/HP 处理

需要包含AER/DPC/热插拔处理，提供和设备驱动以及带内管理的接口

(8)GPU驱动

错误处理器和供应商自定义的RAS操作

(9)加速器管理控制器AMC

在持久化存储空间中收集并存储错误信息，以便通过BMC及超大规模基础设施工具（Hyperscale Infrastructure Tools）进行离线错误日志收集。

(10)IMA带内管理代理

通过带内方式（In-band）收集错误事件，采用Redfish 架构，将收集到的日志呈现给超大规模基础设施（Hyperscaler Infrastructure）。

(11)BMC

遥测数据聚合、RAS 操作策略、FRU隔离提示

规范还对错误报告、错误注入进行了说明。

感兴趣的小伙伴可以从下面地址下载全文阅读学习：

www.opencompute.org/documents/ocp-gpu-and-accelerators-ras-requirements-1-0-final-pdf

NPU相关的也有研究工作正在进行中。

四、总结

纵观全文对 RAS 技术体系的拆解可见，硬件层的冗余架构、故障检测是系统稳定的 “物理基石”，OS内核故障处理、上层应用则是“价值转化器”，将硬件的基础能力转化为业务可感知的持续可用与高效修复，成为支撑金融、医疗、智算等关键领域系统稳定运行的核心支柱。

随着AI技术的发展，GPU/NPU等加速器被广泛应用于智算中心，而相比于传统的数据中心场景，加速器的RAS不成熟，这个场景下面临的新技术新挑战是行业研究热点。不过，相信在行业最好的头脑们的”范弗里特弹药量“级的投入下，这个挑战一定会得以解决的。