背景
本系列前序文章可参考：
2025 年 12 月 31 日，OpenAtom openEuler （简称“openEuler”或 “开源欧拉”） 24.03 LTS SP3 首个超节点操作系统正式上线，促进 openEuler 异构融合系统升级，加速释放超节点异构算力。灵衢超节点打破传统主机边界，在超低时延、多协议归一的灵衢总线级互联的超节点域内，通过计算资源全量池化、平等互联，实现计算资源的灵活组合、超大规模组网和系统高可用性。
超节点的全量池化、平等互联等结构对超节点整体可靠性带来较大挑战，本文主要介绍异构融合软件可靠性技术在灵衢内存池化场景的相关设计与实现，消除可靠性风险提升超节点业务可用度。文章按照如下思路进行组织：
首先介绍当前灵衢超节点的可靠性挑战，从灵衢架构导出当前灵衢通算场景（当前聚焦内存池化场景）的一些关键问题；
然后针对这些问题结合灵衢软硬件能力进行补足与增强，提升整体可靠性与可用性；
最后介绍灵衢可靠性相关技术的后续演进计划。
灵衢超节点可靠性挑战
图 1 - 灵衢通算超节点架构
灵衢超节点通过高速互联的灵衢总线（Unified-Bus，简称 UB，文章后续内容中可能会二者混用）将计算节点连接起来，提供更高的互联带宽，并提供资源池化能力。内存与设备等硬件资源突破原有的硬件边界，提供跨节点进行内存和设备借用与共享的能力。这一架构带来更高的交互灵活性与性能提升的同时，也对可靠性带来了更大的挑战，主要包括以下几个方面：
故障扩散
由于灵衢超节点内存（设备）资源池化，故障从单节点扩散到超节点内其他节点，导致故障的影响范围扩大且不可预知，以内存池化为例：
图 2 - 内存池化架构
内存池化包含借用与共享两类场景：借用场景中内存提供方将自己的空闲内存借给其他节点使用，多用于内存容量需求较大的场景；而共享场景则是将内存提供给多个使用方共享使用，用于需要多实例跨主机交互的分布式应用场景。
两种场景下都存在跨节点访问内存的需求。相比单机，跨节点访问内存的路径变长，故障模式增加，且提供方节点的故障可能扩散到单个或多个使用方节点：
提供方内存出现 UCE 类故障，可能会扩散至其他使用方节点业务。 提供方节点故障，包括 OS panic、计划性复位或异常掉电重启，可能会扩散至其他内存使用方节点的业务。 提供方 UB 控制器或驱动出现故障，可能会扩散至其他内存使用方节点的业务。
其中故障的范围取决与内存借用/共享的配置范围。
灵衢总线新增故障模式
UB 互联网络总线化，新增了 UB 硬件故障类型，包括 UB 控制器（MMIO 故障、msgQ 故障、UDMA 故障、UB MEM 故障）、UMMU 故障、UB 链路故障等，这些故障可能导致更多的单点或跨节点故障，需要软硬件层面去应对。
更高的亚健康风险
灵衢通算超节点为高密集成的 Scale-up 架构，其中包含大量光模块和连线，带来亚健康风险。光模块的可靠性本身较低，可能导致光链路降 lane 引发通信亚健康故障；超节点引入更多的器件，也会导致整体可用度降低。
灵衢超节点可靠性提升
针对灵衢通算超节点可靠性的现有问题，提出以下两类措施：一类为针对灵衢架构所引入故障的消减和处理措施，补齐灵衢可靠性短板；一类为针对具体场景（如数据库、虚拟化等）基于灵衢总线高带宽及池化等架构特点进行的可用性提升措施，构筑相比原生服务器更高的可用性能力。两类措施结合使用，此消彼长提升灵衢通算超节点整体可靠性。
灵衢超节点故障消减措施
针对灵衢超节点故障的消减（补短板）依赖对灵衢可靠性故障有明确的感知与精细化处理，来消除故障的影响及范围。后续会从 UB 故障的处理框架、故障快速通知、UB 故障感知与处理、UB 内存故障容错、节点故障检测与处理几个方面进行展开介绍。
UB 故障处理框架
在《灵衢基础规范 2.0》（https://www.unifiedbus.com/zh/docs/UB-Base-Specification-2.0-preview-zh）中第 10.6.2 章节中，将故障分为三类：
A 类：此类错误的特征是 UB Fabric 的物理拓扑是完好的，错误发生之后能对应到单个事务，错误发生之后不影响其它事务的执行。 B 类：此类错误的特征是 UB Fabric 的物理拓扑是完好的，但错误发生之后无法对应到单个事务，仅能对应到单个 UB Entity、TP Channel 或 Jetty 等（UB Entity 级错误、TP Channel 级错误、Jetty 级错误等），需要对错误单元的全部资源进行处理。 C 类：此类错误的特征是设备级或端口级的公共资源发生错误。
图 3 - UB 可靠性处理框架
各个组件的分类及作用如下：
硬件&固件层：
UB Memory、Bus Controller、UB Entity 等组件：硬件在运行中可能会发生故障，此时硬件会上报对应的错误至 UB Firmware。 UB Entity：发生业务类故障（A&B 类）则直接上报至对应的 UB Entity driver 驱动。 UB Firmware：接收硬件上报的故障事件，将消息通知至 OS。 OS 已有组件（OS Component）：
APEI 驱动：硬件故障按照 APEI 规范要求上报，并被 APEI 驱动处理。 raceevent：内核记录各种事件的机制，此处主要针对硬件错误发生时，硬件会通过 APEI 驱动上报对应的 non_standard_event 事件。 rasdaemon：rasdaemon 会监听 EDAC/traceevent 上报的事件，并记录相关的日志，供上层服务监听并进行对应的处理。 UB 新增组件（UB OS Componet）：
UBus Driver：负责接收 UB Firmware 通过 APEI 上报的 C 类错误，并通知对应的模块进行处理。 sysSentry/sysSentry Service：当紧急事件（OOM、panic、reboot 等）发生时将相关的紧急事件阻塞，并上报事件到 UBPRM 中，防止发生数据丢失或业务中断，同时也负责统一管理通过 UB event 上报的事件。 OBMM：处理内存相关错误，Home 侧内存故障时， OBMM 对相应内存进行标记，防止被再次使用访问。 UVB：在 Home 侧节点发生故障时，通过该模块将故障信息广播至其他节点进行处理。 vfio-ub：当使用中断软通知机制，设备发生故障后上报至 vfio-ub，然后通过 KVM 通知到虚拟机。 厂商自定义组件（Vendor Component）：
FMA：内存故障隔离通知链，业务可通过该通知链，根据需要跳过 OS 处理内存故障隔离逻辑，自行进行内存故障处理。 UB Entity driver：处理 UB 各种故障的驱动，可根据业务逻辑需要自定义处理逻辑。
灵衢相关硬件故障通过这一框架进行上报与处理，可确保所有相关故障能够被截获并处理，是整体灵衢可靠性短板补齐的期初。
故障快速通知
故障场景下需要有可靠高效的通知手段，确保所有相关故障信息与事件可以通知到对应组件进行处理。
我们期望系统故障及异常事件发生时，能够在故障的处理流程中，利用可靠的通信方式将节点故障信息通知集群内其余节点，要求通知时间 <100ms。
支持检测故障场景包括：
服务器操作系统发生 panic 操作系统发生下电、复位等操作 其他硬件类故障事件可以在系统提供故障通知时进行增强
主要利用劫持操作系统的故障回调处理函数，当故障发生时，通过灵衢总线进行跨节点的通信操作。由于劫持的故障是确定性故障，因此相比原有心跳检测方案，无需进行心跳超时的检测，主要的时延消耗是通信开销以及消息转发时间开销。
图 4 - UB 故障快速通知流程
主要流程及步骤如下：
系统故障劫持：基于内核故障通知链，劫持操作系统复位、panic 等故障，支持在系统故障前进行业务紧急逃生。 故障处理模块：调用业务提前注册系统故障处理回调，触发虚拟机原子性快照。 故障跨节点通知：基于灵衢 UVB 以及内核态 URMA 接口实现用户态故障时消息快速通知，通过多链路广播以及重发方式确保消息发送可靠性。 故障消息接收处理：目的端节点 sysSentry 内核态通过 UVB 以及 URMA 接口接收故障节点消息，并将消息转发给用户态通知模块。 故障事件上报：用户态服务（libvirtd、MXE 等）通过订阅对应的故障消息事件，sysSentry 通知 libvirtd 进行虚拟机重放恢复。
通过上述方式提供故障场景可靠的高性能通信通道，作为后续可靠性手段的通信基础。
灵衢故障感知与处理
接下来介绍针对具体故障的处理，针对远端内存故障，其检测与处理流程如下：
图 5 - 远端内存故障检测框架
借用/共享内存场景下，内存出现故障时，需要 User 侧和 Home 侧同时检测和上报：
Home 侧内存故障上报： Home 侧内存控制器上报内存故障至 UB Firmware。 UB Firmware 将故障上报至 OS。 OS 内核中的 APEI 驱动通知 traceevent 和 OBMM。 User 侧读远端内存故障： UB Firmware 触发 SEA/SEI 中断。 OS 内核 APEI 驱动上报故障给 traceevent。 User 侧写远端内存故障： UB Firmware 上报 UB event 给 UBus Driver。 UBus Driver 将故障信息上报给 sysSentry。 sysSentry 上报消息给 sysSentry Service。 sysSentry Service 上报故障信息给 UBPRM 和运维服务
业务或 UBPRM 可通过订阅 sysSentry 远端内存故障访问失败类型的事件，接收对应的故障信息，并根据收到的故障信息对故障内存隔离或者业务进行恢复操作。
Home 侧内存故障隔离与恢复： APEI 驱动对故障内存进行隔离。 OBMM 将故障内存标记为不可借出。 User 侧读远端内存故障隔离与恢复： 当远端内存上线到 NUMA node 时，故障内存会被 APEI 驱动隔离，并发送 SIGBUG 给使用内存的业务进程。 当远端内存上线到 char device 时，sysSentry Service 通过事件的方式通知 UBPRM、运维服务、业务等订阅者，订阅者可做相应的故障处理，例如隔离内存或重新申请内存。 运维服务 UBPRM 监控 rasdaemon 日志，并进行相应故障处理。 User 侧写远端内存故障隔离与恢复： sysSentry 发送 SIGBUG 给使用内存的业务进程。 sysSentry Service 通过事件的方式通知 UBPRM、运维服务、业务等订阅者，订阅者可做相应的故障处理，例如隔离内存或重新申请内存。
UB 内存故障容错
linux 下对内存错误（UCE 错误）的处理策略为用户态进程触发的错误杀死对应进程/线程，内核态访问引起的错误会导致系统 panic。由于池化内存访问链路更长，还可能受提供方节点故障影响，其可靠性相比本地内存挑战更大，为了消减远端内存故障对本节点的影响，我们限定池化内存使用范围，专款专用，只允许用户态进线程使用池化内存，避免系统 panic 扩大故障影响范围。
另外用户态进程在运行中也可能会陷入到内核，对于这类特定处理场景我们也进行了相关细分的 UCE 容错处理，避免用户态陷入内核处理远端内存所导致的系统 panic，提升整体可靠性，包括如下场景：
uaccess 用户态访问，如 copy_{from, to}_user, {get, put}_user cow 写时复制 dump_user_range() 场景 页迁移场景
节点故障检测与处理
当 Home 侧节点发生 panic/reboot 时，该节点借出的内存将无法访问，会影响 User 侧的业务进程，需要截获对应节点故障事件并通知到管控面进行处理。
图 6 - 节点系统故障检测框架
详细通知流程如下：
Home 侧节点内核故障流程中（例如 panic、reboot、shutdown 流程等）通知 sysSentry 即将复位重启。 sysSentry 通过 URMA/UVB 通道进行故障事件广播。 故障事件从 Home 侧节点的 URMA/UVB 通道发送到管理节点的 URMA/UVB 通道。 管理节点的 sysSentry 收到故障事件，通过 sysSentry Service 通知到管理节点 UBPRM。
UBPRM 可通过 sentryctl 相关命令配置 sysSentry 开启对 panic/reboot 事件劫持、配置跨节点通信必备参数配置，通过订阅 OS panic 以及 OS reboot 类型事件来监听 panic/reboot 事件。
当 UBPRM 收到 sysSentry Service 上报的故障通知后，可采取相应的故障隔离和恢复措施，例如将 Home 侧节点内存迁移至其他节点并解除和故障节点的借用关系，确保使用池化内存的业务不受影响。
图 7 - 借用内存紧急回迁
使用方收到借出方节点 panic 通知后，判断本地内存容量是否足以支撑回迁内存数据，如果不足则会触发紧急借用流程，从其他正常节点再次触发内存借入。然后在本节点通过内核页迁移操作进行内存数据搬移，将数据从故障节点借出内存搬移到新的内存块中，防止借出方故障导致的业务访存失效。
灵衢超节点可靠性增强措施
内存不足场景增强
传统服务器的存算固定配比，在业务突发或一些峰值访问的时候经常会出现内存不足的问题；灵衢超节点将内存域由单机扩展到整个超节点，可以通过自由灵活的内存借用等方式消除特定节点的内存不足影响，提升业务的整体可用性。
图 8 - 单机系统内存不足场景处理策略
上图展示了单机系统下内存不足的一些处理策略，系统中维护了内存水线，当内存使用超过一定水线设置时，会触发系统的内存回收操作，将部分数据换出至磁盘，这类换入换出操作会导致业务性能下降；更进一步时会导致业务申请内存操作阻塞，系统重新进行内存整理，直至最后系统内存耗尽，部分业务因为 OOM 被杀死，导致业务异常终止。
而超节点下可以通过内存主动借用或 OOM 确定性预防等手段保障业务的服务质量，避免业务的降级或 OOM-kill，业务运行不受影响。
图 9 - 灵衢超节点内存不足场景应对方案
如图所示，基于灵衢超节点内存池化能力，可以在节点内存不足时有管控面组件主动触发内存借用，使用内存冷热数据搬移来避免远端内存访问性能的影响，将热数据留在本地内存；在内存不足时也可以通过热迁移将业务疏散至空闲的节点。还提供了 OOM 确定性预防技术，在 OOM 事件发生后触发紧急内存借用，避免 OOMkill。
虚机极速热迁移
上文中提到，可以通过热迁移进行业务疏散，在云场景中经常会遇到碎片整理、亚健康主机疏散、机器升级和主机热点等情形，可以通过热迁移方式进行业务搬移。而灵衢超节点提供了超节点内部的高带宽和池化能力（设备池化和内存共享），可以加速热迁移优化中断时间，该技术方案的核心在于将传统热迁移（容器或虚拟机）中的数据传输部分使用灵衢高带宽通道进行优化，可以在 one-copy 情形下达成 4U8G 规格虚机中断时间 50ms 的中断时间目标。
虚机异地快恢
对于云上关键客户的重点虚机，我们提供异地快恢技术解决因软硬件故障（如服务器系统 panic）导致的业务虚机以外宕机问题；传统的 HA 方案恢复耗时可能需要 3-5 min，严重影响客户业务及 SLA 指标。
针对该场景，业界通用手段为采用主动容错，该方案的资源开销和业务影响都比较大，以 Qemu Colo 为例：
主动同步：虚机运行时需要经常进行主备同步，对虚机业务性能影响较大 资源冗余：双主机需要同时运行主备虚机，CPU 和内存资源需要占用双份 设备限制：由于主动状态同步及其他各种约束，导致其适用范围 VCPU 数量不超过 8 个，不支持设备直通等
我们基于灵衢资源池化的优势，探索新型被动容错机制，破除传统 HA 各种限制的同时，实现秒级虚机故障异地快速恢复。
图 10 - 异地快恢架构设计
异地快恢基于灵衢的设备池化及内存共享能力，构建虚机原子性快照、虚机确定性重放和一致性协同控制等能力，实现虚拟机在故障场景下的秒级快速恢复。
虚机原子性快照： 设置 CheckPoint，对虚机运行关键状态（VCPU 陷出事件、IO、网络包等）进行实时的原子性快照，并利用双缓存机制对状态数据的完整性进行保护，以应对瞬时故障的随机性。当故障发生时，利用池化内存将状态数据同步到目标节点。 虚机确定性重放： 基于从池化内存中恢复的故障瞬间快照数据，将虚机运行状态回溯到上一个 CheckPoint，并对可能丢失的 In-Flight 事件进行确定性重放，保证快恢前后虚拟机状态一致性。 虚机一致性协同控制： 一致性协同包括出现故障前，配合云管软件在备节点预创建备虚拟机，并在主虚拟机状态发生变化时，及时进行备虚拟机的状态同步。在 OS 发生故障、用户态网络不通的场景下，构建基于 UB 链路的快速故障通知能力（ sysSentry 模块），实现故障通知时间 <100ms。
总结与展望
本篇文章以灵衢通算超节点为例介绍了异构融合 OS 可靠性可能遇到的问题和对应解决方案，对于超节点架构创新所引入的新的故障类型和故障扩散问题，我们通过精细的故障感知与精确故障处理等方式来减少故障影响，补齐超节点架构下的可靠性短板；同时也利用灵衢超节点架构优势（如高带宽互联和资源池化）提升一些关键场景关键业务的可用性，构建更有竞争力的高可用特性。
本文介绍的补短板能力主要集中在内存借用场景，后续针对灵衢通算超节点新增的池化设备或新增场景还需要进行进一步补齐。另外高可用竞争力特性也与具体业务场景相关，后续可能继续针对云虚拟化、大数据、数据库等关键场景构造更多高可用技术，提升整体可靠性。还可以通过增强超节点关键组件的故障巡检及预测能力，基于故障巡检预测结果及时进行故障疏散。
除故障消减和可用性增强之外，我们还计划针对灵衢通算超节点的故障定位定界、性能调优和运维进行优化，由于超节点池化架构的灵活性，给故障和性能问题的定位分析带来了更大挑战，后续我们计划通过收集超节点相关拓扑信息和关键组件故障信息，结合 AI 提供针对灵衢超节点的智能运维工具，提供更快的定位效率和更高的故障/性能问题定位成功率。
openEuler sig-Long 已面向开发者开源核心技术方案，诚邀行业伙伴、高校与个人开发者交流合作方向。可添加小助手微信加入 sig-Long 微信技术交流群，或访问 AtomGit 平台了解相关材料、提交 issue (https://gitee.com/openeuler/sysSentry)。
