• 产品与解决方案
  • 行业解决方案
  • 服务
  • 支持
  • 合作伙伴
  • 关于我们

智算网络技术白皮书-6W101

手册下载

智算网络技术白皮书-6W101-整本手册.pdf  (2.99 MB)

  • 发布时间:2026/5/12 19:33:33
  • 浏览量:
  • 下载量:

智算网络技术白皮书

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Copyright © 2026 新华三技术有限公司 版权所有,保留一切权利。

非经本公司书面许可,任何单位和个人不得擅自摘抄、复制本文档内容的部分或全部,并不得以任何形式传播。

除新华三技术有限公司的商标外,本手册中出现的其它公司的商标、产品标识及商品名称,由各自权利人拥有。

本文中的内容为通用性技术信息,某些信息可能不适用于您所购买的产品。


 

1 智算网络概述·· 1

1.1 智算网络产生背景·· 1

1.1.1 算力需求爆发:大模型时代的计算挑战·· 1

1.1.2 计算与网络协同面临瓶颈:传统架构难以满足智能计算需求·· 1

1.1.3 智算网络应运而生:新一代计算范式·· 2

1.2 智算网络面临的核心挑战·· 2

2 智算网络技术架构·· 4

2.1 技术架构综述·· 4

2.2 智能无损网络·· 4

2.3 智能流量调度体系·· 5

2.4 高可用保障机制·· 5

2.5 智能运维平台·· 5

3 智能无损网络·· 6

3.1 智能无损网络简介·· 6

3.1.1 产生背景·· 6

3.1.2 技术框架·· 8

3.2 PFC· 9

3.2.1 PFC简介·· 9

3.2.2 PFC的工作流程·· 9

3.2.3 PFC死锁检测·· 10

3.2.4 PFC死锁预防·· 12

3.2.5 PFC的价值·· 14

3.3 ECN· 15

3.3.1 ECN简介·· 15

3.3.2 ECN的基本原理·· 15

3.3.3 ECN的价值·· 17

3.4 IPCC· 17

3.4.1 基本概念·· 17

3.4.2 实现原理·· 18

3.5 iNOF· 20

3.5.1 iNOF简介·· 20

3.5.2 iNOF的基本原理·· 22

3.5.3 iNOF的价值·· 24

4 智能流量调度体系·· 25

4.1 SprayLink· 25

4.1.1 产生背景·· 25

4.1.2 技术价值·· 25

4.1.3 工作机制·· 25

4.1.4 应用场景·· 26

4.2 LBN· 27

4.2.1 技术介绍·· 27

4.2.2 技术价值·· 27

4.2.3 工作机制·· 28

4.2.4 应用场景·· 29

4.3 DLB· 29

4.3.1 技术简介·· 29

4.3.2 技术优势·· 29

4.3.3 技术原理·· 30

4.3.4 在智算网络中的应用场景·· 31

4.4 FGLB· 31

4.4.1 产生背景·· 31

4.4.2 技术原理·· 32

4.4.3 技术总结·· 34

4.4.4 在智算网络中的应用场景·· 34

4.5 Traffic Matrix· 35

4.5.1 Traffic Matrix简介·· 35

4.5.2 Traffic Matrix的生成方式·· 36

4.6 路径导航·· 37

4.6.1 产生背景·· 37

4.6.2 端网协同路径导航技术·· 37

4.6.3 端侧解耦路径导航·· 41

4.7 大小流区分调度·· 43

4.7.1 技术介绍·· 43

4.7.2 技术价值·· 44

5 高可用保障机制·· 45

5.1 DPSH· 45

5.1.1 产生背景·· 45

5.1.2 技术价值·· 45

5.1.3 应用场景·· 45

5.2 ISDF· 46

5.2.1 产生背景·· 46

5.2.2 技术价值·· 47

5.2.3 技术分类·· 48

5.2.4 有状态流静默工作机制·· 48

5.2.5 无状态流静默工作机制·· 50

5.2.6 端口静默工作机制·· 51

5.2.7 应用场景·· 52

5.3 M-LAG·· 53

5.3.1 M-LAG简介·· 53

5.3.2 M-LAG系统GIR· 55

5.3.3 M-LAG VLAN双活网关·· 56

5.3.4 M-LAG的价值·· 57

5.4 光模块通道保持技术·· 58

5.4.1 技术背景·· 58

5.4.2 技术实现·· 58

6 智能运维技术·· 59

6.1 AD-DC智算版·· 59

6.1.1 产生背景·· 59

6.1.2 关键技术·· 60

6.1.3 系统架构·· 61

6.2 基于gRPCTelemetry· 62

6.2.1 技术简介·· 62

6.2.2 组网模型·· 62

6.2.3 工作模式·· 63

6.2.4 技术优势·· 64

6.3 基于ERSPANTelemetry· 65

6.3.1 技术简介·· 65

6.3.2 工作机制·· 65

6.3.3 技术价值·· 66

6.4 网络显微镜技术·· 67

6.4.1 技术介绍·· 67

6.4.2 技术价值·· 69

6.5 UFA· 70

6.5.1 产生背景·· 70

6.5.2 系统组成·· 70

6.5.3 技术优势·· 72

6.5.4 原理机制·· 72

6.5.5 应用场景·· 74

6.6 iFIT· 76

6.6.1 技术介绍·· 76

6.6.2 技术价值·· 78

6.6.3 应用场景·· 79

6.7 MOD·· 80

6.7.1 技术简介·· 80

6.7.2 工作机制·· 80

6.7.3 技术价值·· 81

6.8 Telemetry Stream·· 82

6.8.1 技术简介·· 82

6.8.2 工作机制·· 82

6.8.3 技术价值·· 83

6.9 RDMA Telemetry· 84

6.9.1 产生背景·· 84

6.9.2 技术优点·· 84

6.9.3 I/O质量可视功能技术实现·· 85

6.9.4 吞吐量可视功能技术实现·· 92

6.9.5 RDMA Telemetry可视化·· 94

6.9.6 典型组网应用·· 95

6.10 光模块诊断可视化·· 97

6.10.1 技术简介·· 97

6.10.2 工作机制·· 97

6.10.3 技术价值·· 98

7 智算网络部署方案·· 99

7.1 云上场景部署方案·· 99

7.1.1 部署场景推荐·· 99

7.1.2 典型组网·· 99

7.1.3 资源分区说明·· 100

7.1.4 网络平面规划·· 101

7.2 云下场景部署方案·· 101

7.2.1 部署场景推荐·· 101

7.2.2 典型组网·· 101

7.2.3 资源分区说明·· 102

7.2.4 网络平面规划·· 103

8 智算网络典型应用场景·· 103

8.1 AI大模型训练与移动端部署中的一体化应用·· 103

8.1.1 客户痛点·· 103

8.1.2 解决方案·· 103

8.1.3 客户价值·· 104

8.2 超大规模AI算力集群中的应用·· 104

8.2.1 客户痛点·· 104

8.2.2 解决方案·· 105

8.2.3 客户价值·· 106

9 参考文献·· 106

 


1 智算网络概述

1.1  智算网络产生背景

1.1.1  算力需求爆发:大模型时代的计算挑战

人工智能已全面进入大模型时代,其最显著的特征是模型规模的指数级膨胀。以自然语言处理为例,模型参数量已从数亿、千亿级别迅速突破至万亿规模,且增长势头不减。这种规模化竞赛直接导致了计算需求的爆炸式增长。与此同时,多模态融合、科学智能、自动驾驶等更复杂场景的兴起,不仅拓宽了AI的应用边界,也对底层算力的规模、效率和可用性提出了前所未有的紧迫要求。

算力需求呈现出如下显著特征:

·     计算需求激增。训练一个万亿参数级大模型需要协调上万块高性能GPU持续运行数月,其计算量相当于传统超算中心数年的运算总量。

·     实时性要求提升。自动驾驶决策系统需在10毫秒内完成环境感知与路径规划,元宇宙场景渲染要求每秒处理PB级数据流,这些场景对计算时效性提出了前所未有的要求。

·     能耗压力凸显。单次大模型训练的电力消耗可达千万千瓦时级别,相当于一个中小型城市数日的用电总量。传统计算模式在能效比上面临严峻挑战。

图1 算力需求的显著特征

 

1.1.2  计算与网络协同面临瓶颈:传统架构难以满足智能计算需求

传统计算架构与数据中心网络在设计之初并未针对大模型训练等高并发、强同步的智能计算场景进行优化,导致计算与网络协同效率低下,形成瓶颈。具体表现在以下方面:

·     计算侧瓶颈:

¡     资源孤岛问题:企业、科研机构的算力资源分散且独立,难以协同,资源利用率低。

¡     资源调度僵化:传统虚拟化技术依赖预分配的固定资源配额,无法适应AI训练中突发性梯度同步。

¡     扩展性限制:传统数据中心受限于供电与散热能力,传统风冷单个机柜功率密度难以突破50kW(空气冷却极限为75kW),导致单数据中心GPU集群规模通常不超过8000块。当尝试部署更大规模集群时,可能会出现因冷却系统崩溃导致训练中断的情况。

·     网络侧瓶颈:

¡     端到端时延过高:协议栈处理与交换机排队引入额外延迟,难以满足低时延应用的严苛需求。

¡     负载不均问题:静态负载均衡策略引发哈希冲突,部分链路过载而其他链路闲置。

¡     运维问题:传统监控手段通常仅支持秒级粒度,难以有效识别瞬发性或毫秒级网络异常,导致故障定位效率低下,严重影响业务连续性。

·     协同失效:计算与网络割裂的代价

¡     资源利用率低下:计算任务与网络传输分离,导致数据传输成为瓶颈。

¡     运维复杂度激增:计算任务与网络故障相互耦合,传统监控手段(如SNMP)无法捕捉微突发流量。

图2 计算与网络协同面临瓶颈

 

1.1.3  智算网络应运而生:新一代计算范式

为突破上述限制,智算网络作为一种新型计算基础设施范式应运而生。其核心是通过构建高带宽、低时延、智能化的全局资源调度网络,实现对分布式异构算力的统一纳管与协同调度。

随着AI技术持续向更大规模、更复杂场景演进,智算网络正在成为支撑数字经济发展的新型基础设施,其战略价值已获得广泛共识。

1.2  智算网络面临的核心挑战

随着AI大模型迈入万亿参数时代,传统网络架构在支撑新一代智能计算需求时面临系统性瓶颈。大模型参数量级跃迁,不仅带来算力需求的指数增长,更对计算基础设施的网络协同能力提出了前所未有的要求。在这一背景下,智算网络亟需突破以下核心挑战:

·     超大规模无损传输挑战

在大模型训练场景下,传统网络架构难以满足AI计算对零丢包、超低延迟的严苛需求。当模型参数量达到万亿级别时,分布式训练中频繁的梯度同步会产生持续的微秒级微突发流量,极易引发网络拥塞和丢包。这种突发流量往往超出传统交换机的缓冲容量,导致有效带宽利用率骤降,严重影响训练效率。

·     动态流量调度挑战

大模型训练采用AllReduce通信模式。AllReduce是分布式深度学习中的核心通信操作,用于高效聚合所有计算节点(如GPU)的梯度数据。其核心特点是:

¡     全局同步:所有节点必须完成本地梯度计算后才能启动通信,形成严格的同步屏障。

¡     结构化聚合:采用特定的通信拓扑(如环状的Ring AllReduce或树状的算法),将全局聚合任务分解为多轮有序的点对点通信与计算,以优化带宽利用、减少通信延迟

¡     结果一致性:所有参与节点在操作结束后,都会获得完全相同的全局聚合结果,从而确保后续参数更新的一致性。

AllReduce通信模式的强同步性和超大规模性,对网络负载均衡提出了前所未有的要求。在万卡级集群中,参数服务器架构可能产生数万个并发连接,传统静态负载均衡算法会导致严重的哈希冲突问题。同时,训练任务不同阶段对网络的需求差异巨大,需要实时感知计算状态的自适应调度能力,这对现有网络资源分配机制形成严峻考验。

·     持续可靠运行挑战

大规模分布式AI训练(如大语言模型训练)对网络可靠性提出了前所未有的严苛要求。长达数周甚至数月的连续训练任务,要求网络保持极高的可用性与稳定性。在此类场景下,即使是由设备老化或配置错误引发的间歇性、微秒级的网络丢包或延迟抖动,也可能破坏分布式计算的同步过程,导致训练效率下降、任务时间延长,甚至造成训练进程中断,带来算力与时间成本损失。

·     智能运维诊断挑战

传统网络监控手段已无法满足智算环境下的运维需求。大模型训练产生的微突发流量远超传统SNMP协议的采样能力,使得关键故障征兆被遗漏。当计算、存储、网络问题相互耦合时,运维人员缺乏有效的端到端追踪工具,导致故障定位时间呈指数级增长,严重影响业务连续性。

图3 智算网络面临的挑战

 

这些挑战共同构成了制约AI算力发展的关键瓶颈,反映出传统网络架构在面对智能计算新范式时的系统性不足。从超大规模无损传输到动态流量调度,从持续可靠运行到智能运维诊断,每一个挑战都直接影响着大模型训练的效率和可靠性。突破这些挑战不仅需要网络技术的创新升级,更需要建立网络与计算深度融合的新型基础设施架构。只有攻克这些难关,才能真正释放智能计算的潜力,为AI产业的持续发展提供坚实支撑。

2 智算网络技术架构

2.1  技术架构综述

面对超大规模无损传输、动态流量调度、持续可靠运行和智能运维诊断四大核心挑战,传统技术架构已显现出明显的局限性。智算网络构建了全新的技术架构体系,为智能计算提供坚实的网络支撑。

4所示,智算网络的技术架构主要包括智能无损网络、智能流量调度体系、高可用保障机制和智能运维平台四部分。通过这四部分的协同创新,解决了智能计算场景下的网络瓶颈问题。各技术组件既独立演进又深度融合,形成了支撑万亿参数模型训练的全栈解决方案。

图4 智算网络技术架构

 

2.2  智能无损网络

随着AI大模型训练规模进入万亿参数时代,传统TCP/IP协议栈在高性能计算网络中的瓶颈日益凸显。在分布式训练过程中,海量GPU节点间的梯度同步会产生微秒级微突发流量,而TCP/IP的协议栈处理、数据拷贝及基于丢包的拥塞控制机制,往往导致网络拥塞、延迟抖动和丢包问题,严重影响训练效率。例如,在传统以太网环境下,当链路利用率超过60%时,TCP的吞吐量会急剧下降,而AI训练任务通常需要90%以上的稳定带宽利用率,这对网络传输提出了近乎苛刻的要求。

为突破这一限制,智算网络采用RDMARemote Direct Memory Access,远程直接内存访问)技术来优化通信性能。RDMA通过绕过操作系统内核、实现零拷贝数据传输,将通信延迟从毫秒级降至微秒级,显著提升了分布式训练的并行效率。然而,RDMA(尤其是基于以太网的RoCEv2协议)对网络环境的要求极为严格:由于RoCEv2基于UDP协议,缺乏TCP的重传机制,任何微小的丢包或拥塞都会导致性能断崖式下降。因此,要充分发挥RDMA的高性能优势,必须依赖智能无损网络来提供低时延、零丢包的传输保障。

智能无损网络通过分层技术体系构建高可靠的底层传输平面,确保RDMA协议能够稳定运行:

·     在协议层,PFCPriority-based Flow Control,基于优先级的流量控制)机制可对关键流量(如梯度同步)进行无损保障,避免缓冲区溢出导致的丢包;ECNExplicit Congestion Notification,显式拥塞通知)、IPCCIntelligent Proactive Congestion Control,智能主动拥塞控制)则能提前感知拥塞并动态调整流量,形成闭环的拥塞控制体系;在存储网络应用场景中,智能无损网络还提供了iNOFIntelligent Lossless NVMe Over Fabric,智能无损存储网络)功能,通过对iNOF主机的快速管控,提升存储网络的易用性,实现以太网和存储网络融合。

·     在硬件层面,采用智能无损交换芯片实现高速、低延迟的数据交换。

2.3  智能流量调度体系

大模型训练特有的AllReduce通信模式对网络负载均衡提出了全新挑战。在万卡级集群中,传统的静态负载均衡算法往往导致严重的哈希冲突,造成部分链路过载而其他链路闲置的资源浪费问题。智算网络通过创新的智能流量调度体系,显著提升了网络资源利用率,降低了通信延迟。

·     动态流调度:Spraylink多路径喷射技术打破了传统ECMP的局限性,实现流量在多条路径上的均匀分布。

·     智能负载均衡:通过LBNDLBFGLB等多级调度机制,从节点级、机架级到集群级实现资源的全局优化。

·     路由优化:基于计算感知的路径导航技术,降低传输延迟。

·     QoS保障:通过大小流区分调度与流量矩阵(Traffic Matrix)辅助决策,优先保障关键业务。

2.4  高可用保障机制

大模型训练任务往往需要连续运行数周甚至数月,任何网络中断都可能导致价值数百万美元的计算资源浪费。智算网络设计了全方位的高可用保障机制:

·     快速故障恢复方面,采用M-LAG技术实现跨设备的链路聚合保护;DPSH分布式保护技术则为关键流量提供1:1的实时镜像保护。

·     静默故障检测与自愈:ISDF静默故障检测技术采用数据面故障检测、远程故障通告和快速路径切换机制,实现毫秒级网络收敛。

·     物理层链路保障:光模块通道保持技术通过灵敏的端口状态检测,实现了光链路通道的实时切换,从而降低了故障发生率,保障训练任务的连续性。

2.5  智能运维平台

为解决故障诊断难题,H3C打造了针对智算网络的智能管控平台——AD-DC智算网络运维分析平台(简称AD-DC智算版)。AD-DC智算版是专门为AI算力集群和模型训练场景打造的全栈智能化管控方案。作为AI数据中心的“大脑”,AD-DC智算版通过统一管理计算、网络和存储资源,解决了传统AI数据中心部署和运维的难题。该平台显著降低了技术门槛,帮助用户快速部署AI算力集群,同时大幅减轻运维压力。

智算网络支持的智能运维技术包括:

·     深度监测模块采用网络显微镜技术,可捕捉微突发流量,通过拥塞贡献流分析精准定位瓶颈点;UFA未知流量分析引擎能够识别异常流量模式,提前发现潜在安全隐患;iFIT随流检测技术实现从入口到出口的全路径追踪,配合MOD多维诊断引擎快速定位丢包原因。光网络诊断模块提供光模块SNR信噪比、分通道误码率等关键指标的实时可视化展示,支持提前发现物理层隐患。

·     数据采集层通过gRPCERSPANTelemetry streamRDMA Telemetry等多种技术,实现网络设备秒级、全量的数据采集。

该智能运维平台将平均故障定位时间从小时级缩短至分钟级,大幅提升运维效率。

3 智能无损网络

3.1  智能无损网络简介

3.1.1  产生背景

随着高性能计算、大数据分析、人工智能以及物联网等技术的飞速发展,集中式存储、分布式存储以及云数据库的普及,业务应用有越来越多的数据需要从网络中获取,这些应用对数据中心网络的交换速度和性能要求越来越高。

传统的TCP/IP软硬件架构及应用存在着网络传输和数据处理的延迟过大、存在多次数据拷贝和中断处理、TCP/IP协议处理消耗CPU资源等问题。RDMARemote Direct Memory Access,远程直接内存访问)技术的内核旁路机制允许应用与网卡之间直接读写数据,使得服务器内的数据传输时延降低。同时,RDMA利用相关的硬件和网络技术,使服务器网卡之间可以直接读内存,实现了高吞吐量、超低时延下低CPU开销的效果。

TCP/IP协议相比,RDMA具有以下优势:

·     低时延:RDMA的内核旁路机制,允许应用与网卡之间的直接数据读写,将服务器内的数据传输时延降低到接近1微秒。

·     CPU负载:RDMA的内存零拷贝机制,允许接收端直接从发送端的内存读取数据,极大的减少了CPU的负担,提升了CPU的效率。

图5 传统TCP/IP数据传输过程

 

图6 RDMA数据传输过程

 

RDMA网络主要有IBiWARPRoCE三种类型。

·     IBInfiniBand,无限带宽):基于InfiniBand架构的RDMA技术,由IBTAInfiniBand Trade Association)提出。搭建基于IB技术的RDMA网络需要专用的IB网卡和IB交换机,主要应用于高性能计算用户,成本较高。

·     iWARPInternet Wide Area RDMA Protocol,互联网广域RDMA协议):基于TCP/IP协议的RDMA技术,由IETF标准定义。iWARP支持在标准以太网基础设施上使用RDMA技术,但服务器需要使用支持iWARP的网卡。

·     RoCERDMA over Converged Ethernet,融合以太网RDMA协议):基于以太网的RDMA技术,也是由IBTA提出。RoCE支持在标准以太网基础设施上使用RDMA技术,但是需要交换机支持无损以太网传输,需要服务器使用RoCE网卡。

其中RoCE分为RoCEv1RoCEv2两代。

·     RoCEv1协议:基于以太网承载RDMARoCEv1协议是一种以太网链路层协议,允许同一以太网广播域(VLAN)中的两个主机进行通信,只能部署于二层网络,它的报文结构是在原有的IB架构的报文上增加二层以太网的报文头,使用以太网类型(EtherType0x8915标识RoCE报文。

·     RoCEv2协议:基于UDP/IP协议承载RDMA,可部署于三层网络,它的报文结构是在原有的IB架构的报文上增加UDP头、IP头和二层以太网报文头,通过UDP目的端口号4791标识RoCE报文。RoCEv2支持基于源端口号HASH,采用ECMP实现负载分担,提高了网络的利用率。RoCEv2协议克服了RoCEv1仅限于单个广播域(VLAN)的限制。RoCEv2可以在L2L3网络中使用,它通过改变数据包的封装方式,包括IPUDP报头,实现L3路由功能。这使得RoCEv2可以在具有多个子网的网络中使用,从而实现更好的可扩展性。

 

当前分布式存储、HPC高性能计算、AI人工智能等场景广泛采用RoCEv2RDMA over Converged Ethernet version 2)作为以太网上的传输协议来降低传输时延和CPU负担。

RoCEv2网络是基于无连接协议的UDP协议,相比于TCP协议,UDP协议传输速率更高、占用CPU资源更少,但是由于其不像TCP协议那样有滑动窗口、确认应答等机制来实现可靠传输,出现网络丢包时,依靠上层应用检查到后再做重传,会大大降低RDMA网络的传输效率。所以为了发挥出RDMA真正的性能,突破数据中心大规模分布式系统的网络性能瓶颈,就需要为RDMA搭建一套不丢包的无损网络环境,其关键就是解决网络拥塞。因此,以太网交换机需要支持无损网络的部署才能支持RoCEv2协议及其相关应用。

3.1.2  技术框架

智能无损网络是一系列网络技术的集合,它一方面通过流量控制技术和拥塞控制技术来提升网络整体的吞吐量,降低网络时延,另一方面通过智能无损存储网络等技术实现网络和应用系统融合优化。智能无损网络技术可以为AI人工智能、集中式/分布式存储、HPC等应用场景提供“无丢包、低时延、高吞吐”网络环境。

智能无损网络主要包括:

·     流量控制技术:在节点间应用的防丢包技术,属于“链路”级别技术,而非端到端整网流量控制方案。流量控制技术主要是指IEEE 802.1Qbb定义的PFCPFC主要部署在网络边缘的交换设备。连接计算或存储节点的边缘网络设备在检测到接收缓存即将溢出时,向发送端发送“暂停帧”(PFC Pause Frame),临时停止特定优先级队列的数据发送,避免队列拥塞丢包。通常为了避免整网业务瘫痪,与PFC共同部署的还包括PFC死锁检测、PFC死锁预防。

·     拥塞控制技术:是端到端的防丢包技术,避免整网任意位置发生流量拥塞。拥塞控制技术的核心是基于ECNExplicit Congestion Notification,显式拥塞通知)通过拥塞通知报文告知发送端降速来避免拥塞丢包,本文主要介绍ECN门限设置方式和手段。

·     存储网络融合:在存储网络应用场景中,智能无损网络提供了iNOFIntelligent Lossless NVMe Over Fabric,智能无损存储网络)功能,通过对iNOF主机的快速管控,提升存储网络的易用性,实现以太网和存储网络融合。

3.2  PFC

3.2.1  PFC简介

为了控制以太网交换机之间或网卡与交换机端口之间链路流量超出接收端处理能力,造成接收端丢包,IEEE 802.3工作组定义以太网的流量控制技术。流量控制技术是在两个节点间的链路上应用的防丢包技术,属于“链路”级别技术而非端到端整网流量控制方案,因此又称为链路级流控技术。常用的链路级流控技术是PFCPriority-based Flow Control,基于优先级的流量控制)。

PFC允许网络设备根据不同数据流的优先级进行流量控制。当接收缓存中特定优先级对应的流量即将溢出时,网络设备可以向对端设备发送反压信号(PFC PAUSE帧如7所示),要求对端设备停止发送特定优先级的流量,以防止缓存溢出和数据丢失。这种个别流量控制方式允许网络在某些流量拥塞时保持流畅,同时防止对其他流量造成干扰。

图7 PFC PAUSE帧结构

 

3.2.2  PFC的工作流程

8所示,PFC工作原理如下:

(1)     Device A通过直连端口向Device B持续发送不同802.1p优先级标识的业务流量。Device B接收端口收到流量后,根据端口的优先级映射关系将802.1p标识的业务流量放到对应的队列中等待转发。例如,Priority1的流量进入缓存队列1

(2)     当缓存队列1的流量未及时转发,缓存空间虽未溢出但队列长度超出了PFC反压门限XOFF时,Device B立即向Device A发送PFC PAUSE帧。PFC PAUSE帧中e[1]置为1,表示队列1的流量要暂停发送一段时间,Device A按照PFC PAUSE帧的指示暂停发送对应优先级的流量。此时,Device ADevice B之间其他优先级的流量可以正常处理。如果缓存队列1持续超出XOFF,则Device A将会持续接收到多个PFC PAUSE帧,对应优先级流量一直处于暂停发送状态。

(3)     当拥塞情况缓解后,缓存队列1中的流量被转发,队列长度低于PFC反压解除门限XON此时Device BDevice A发送RESUME消息,允许缓存队列1的流量正常发送。

图8 PFC工作原理示意图

 

3.2.3  PFC死锁检测

1. PFC死锁的产生

PFC死锁是指多个设备之间,因为环路等原因,同时出现了拥塞(各自端口缓存消耗超过了阈值),又都在等待对方释放资源,从而导致的“僵持状态”(所有交换机的数据流永久堵塞)。

9所示,多个设备发生拥塞后互相发送PFC PAUSE帧,使PFC PAUSE帧在网络内泛洪,导致网络内设备无法转发报文,使整网业务瘫痪。

图9 PFC死锁产生示意图

 

2. 触发PFC死锁检测

10所示,Device B的端口Interface收到来自Device APFC PAUSE帧后,停止发送对应优先级队列的报文。Device B启动PFC死锁检测定时器,在检测周期内检测该优先级队列收到的PFC PAUSE帧。

图10 触发PFC死锁检测示意图

 

3. PFC死锁判定

11所示,如果在PFC死锁检测周期内,Device B上端口Interface的指定优先级队列一直处于PFC XOFFPFC反压帧触发门限)状态,即在检测周期内该优先级队列持续不断地收到PFC PAUSE帧,则Device B判定Device A发生死锁,进入死锁状态。

图11 PFC死锁判定示意图

 

4. PFC死锁恢复

设备检测到某个接口发生死锁后,将启动自动恢复定时器。在自动恢复周期内,设备将关闭该接口的PFC功能和PFC死锁检测功能,以忽略接口收到的PFC PAUSE帧。同时,设备对数据报文执行转发或丢弃动作(由管理员手工配置),以规避PFC死锁问题。

在自动恢复定时器超时后,设备将开启PFC功能和PFC死锁检测功能。如果经过死锁恢复后,仍不断出现PFC死锁现象,管理员可以设置PFC死锁的触发上限,当PFC死锁发生次数到达上限后,设备将强制关闭PFC功能和PFC死锁检测功能。待排除故障后,需要管理员手工恢复PFC功能和PFC死锁检测功能。

3.2.4  PFC死锁预防

PFC死锁预防是指设备通过识别可能导致PFC死锁的业务流并调整其队列优先级,从而防止PFC死锁的发生。

1. PFC死锁预防的产生背景

12所示,正常情况下,业务流量转发路径为A-B-C-D。当网络的防环机制出现问题时,将会导致业务流量从DA转发。故障流量在A-B-C-D间转发,形成环路。如果网络设备A~D接口的缓存空间中使用的资源达到PFC XOFF门限,则网络设备向故障流量的上游发送PFC PAUSE帧。PFC PAUSE帧在环网中持续发送,最终导致所有设备进入PFC死锁状态,整网断流。

图12 环网PFC死锁示意图

 

2. PFC高风险业务流

PFC死锁预防功能中定义了端口组概念,如13所示,设备Dinterface 1interface 2属于同一端口组。当设备D检测到同一条业务流从该端口组的接口上进出时,即说明该业务流是一条高风险业务流。此类业务流易形成PFC PAUSE帧环路,引起PFC死锁。

图13 PFC高风险业务流

 

3. PFC死锁预防工作原理

当前PFC死锁预防功能仅对携带DSCP值的业务流量生效

设备收到报文后,会根据报文的DSCP值以及设备上dscp-dot1p的映射关系,将该报文加入指定dot1p优先级的队列转发。PFC死锁预防功能工作原理为:

(1)     部署端口组:管理员提前规划,将可能产生PFC PAUSE帧的接口划分到同一端口组。例如,一台Leaf交换机,将其上行口划分到同一端口组中。

(2)     识别高风险业务流。

(3)     修改映射关系:设备收到报文后,修改报文的DSCP值和对应的dot1p优先级,使报文在新的dot1p优先级队列中使用新的DSCP值转发。

14所示,Device A发送指定DSCP值的业务流量。Device B收到业务流量后,根据报文的DSCP值以及设备上dscp-dot1p的映射关系,让业务流量在队列1中转发。如果Device B检测到该业务流量为高风险业务流,易引起PFC死锁,则Device B会修改业务流量队列优先级,使业务流量切换到队列2转发,这样就可以规避队列1可能产生的PFC PAUSE帧,预防PFC死锁的产生。

图14 PFC死锁预防工作原理示意图

 

3.2.5  PFC的价值

在智算网络中,PFC是构建高效RoCE无损以太网的基础技术之一,对于保障AI训练、HPC任务的吞吐和稳定性至关重要。PFC的价值主要体现在:

·     PFC是高性能RoCEv2应用的基石:运行在以太网的RDMA传输层协议(RoCEv2)本身没有重传机制。一旦网络因拥塞发生丢包,整个数据流就会中断,导致性能急剧下降,完全丧失了RDMA的低延迟优势。PFC通过在物理链路层面防止缓冲区溢出,确保了零丢包,为RDMA提供了稳定、可预测的网络环境。这是RoCEv2能够实现高性能通信的基石。没有PFCRoCEv2在实际生产网络中几乎无法使用。

·     确保关键业务无丢包:网络需要同时为不同用户或不同业务(如AI训练、视频渲染、在线交易)提供服务。利用基于优先级的PFC技术,网络管理员可以为关键业务(如AI训练)分配最高优先级,为其他业务分配较低优先级。当发生拥塞时,PFC PAUSE帧只会暂停低优先级的流量,而高优先级的流量依然可以无中断地传输。这种精细化的流量控制实现了业务之间的隔离和保障,避免了“劣质流量驱逐优质流量”的问题。

·     配合ECN提升网络的吞吐率:PFC可与显式拥塞通知ECN技术结合,实现链路级无丢包和端到端拥塞控制的协同,提高算力网络的整体吞吐率。

3.3  ECN

3.3.1  ECN简介

ECNExplicit Congestion Notification,显式拥塞通知)是一种端到端防丢包的拥塞控制技术,可以避免设备出接口上拥塞丢包的发生。ECN利用IP报文头中的DS域来标记报文传输路径上的拥塞状态。支持ECN功能的终端设备网卡可以通过报文中的ECN标记判断出传输路径上是否发生了拥塞,从而调整报文的发送速率,避免拥塞加剧。

图15 IPv4报文头中的ECN示意图

 

15所示以IPv4报文为例,IP报文头中DS域的最后两个比特位被定义为ECN域,RFC 3168ECN域的取值进行如下规定:

·     ECN域的取值为00时,表示该报文不支持ECN功能。

·     ECN域的取值为01或者10时,表示该报文支持ECN功能,分别记为ECT0)或ECT1)。

·     ECN域的取值为11时,表示该报文在转发路径上发生了拥塞,记为CE

3.3.2  ECN的基本原理

16所示,ECN功能一般可以和WRED策略配合应用在网络中。在部署了ECN功能和WRED策略的网络模型中,存在三类设备角色:

·     转发设备(Congestion Point):报文在网络中转发路径上经过的设备,转发设备支持ECN功能,可以标记和识别报文中ECN域。报文在转发设备的接口上可能发生拥塞,所以转发设备又称为Congestion Point,转发设备需要部署ECN功能的WRED策略。

·     报文接收端(Notification Point):接收端设备网卡支持ECN功能,可以识别报文中取值为0110或者11ECN域。接收端同时作为拥塞通知的发起设备,收到ECN域取值为11的报文时,将每隔时间周期T1发送拥塞通知报文给报文发送端,要求发送端降低报文发送速率。

·     报文发送端(Reaction Point):发送端设备网卡支持ECN功能,从发送端发出报文的ECN域的取值为01或者10。发送端同时作为拥塞通知的应答设备,收到拥塞通知时,将以一定的降速比率降低当前自身发送报文的发送速率,并开启计时器,当计时器超出时间T2T2>T1)后,发送端设备未再次收到拥塞通知,则发送端认为网络中不存在拥塞,恢复一定的报文发送速率。当计时器在时间T2T2>T1)内,发送端设备再次收到拥塞通知,则发送端进一步降低报文发送速率。

图16 部署ECN功能的WRED策略的组网图

 

转发设备(Congestion Point)对接收到的数据报文进行识别和处理的具体处理方式如下:

·     当转发设备的报文在出方向排队,该队列的长度小于下限QL_minQL_min也称为ECN低门限)时,不对报文进行任何处理,转发设备直接将报文从出接口转发。

·     当转发设备的报文在出方向进入队列排队,该队列的长度大于下限QL_min但小于上限QL_maxQL_max也称为ECN高门限)时:

¡     如果设备接收到的报文中ECN域取值为00,表示报文发送端不支持ECN功能,转发设备按照未开启ECN功能的WRED策略处理,即随机丢弃接收的报文。

¡     如果设备接收到的报文中ECN域取值为01或者10,表示报文发送端支持ECN功能,将按照WRED策略中的线性丢弃概率来修改部分入方向报文的ECN域为11后继续转发该报文,所有入方向接收到的报文均不丢弃。

¡     如果设备接收到的报文中ECN域取值为11,表示该报文在之前的转发设备上已经出现拥塞,此时转发设备不处理报文,直接将报文从出接口转发。

·     当转发设备的报文在出方向进入队列排队,该队列的长度大于上限QL_max时:

¡     如果设备接收到的报文中ECN域取值为00,表示报文发送端不支持ECN功能,转发设备按照未开启ECN功能的WRED策略处理,即丢弃接收的报文。

¡     如果设备接收到的报文中ECN域取值为01或者10,表示报文发送端支持ECN功能,将100%修改入方向报文的ECN域为11后继续转发该报文,所有入方向接收到的报文均不丢弃。

¡     如果设备接收到的报文中ECN域取值为11,表示该报文在之前的转发设备上已经出现拥塞,此时转发设备不处理报文,直接将报文从出接口转发。

合理设置ECN门限可以缓解拥塞同时保证网络的时延和吞吐率。

H3C提供了多种设置ECN门限的技术:

·     时延ECN:时延ECN技术允许管理员为队列设置转发时延阈值T。转发芯片用报文从出端口转发的时间戳减去报文到达入端口的时间戳,得到报文在设备中转发处理的总延时dnode。如果dnode超出了设置的时延阈值T,则该端口队列将触发ECN功能,缓解拥塞情况

·     动态ECN:基于实时变化的队列共享缓存占用情况,动态ECN功能调整ECN的触发门限,合理自动设置ECN高门限,缓解拥塞。

·     AI ECN:利用设备本地的AI业务组件,按照一定流量模型算法动态优化ECN门限。

3.3.3  ECN的价值

在智算网络中,ECN是构建高效RoCE无损以太网的基础技术之一,对于保障AI训练、HPC任务的吞吐和稳定性至关重要。ECN的价值主要体现在:

·     实现无损传输与保障计算连续性:ECN仅标识拥塞发生,而非同WRED策略一样直接丢包,从根本上避免了因拥塞导致的重传,确保了大流量计算作业的无中断运行,保障了计算任务的连续性和整体效率。

·     端到端的协同机制降低传输时延:通过AI ECN或动态ECN等技术合理设置ECN,可以实现端到端的网络协同,避免网络中出现丢包和重传的过程,减少了传输时延和抖动。这也是RoCEv2得以部署和应用的基础。

·     保障网络吞吐率和资源利用率:通过避免不必要的丢包和重传,ECN减少了网络中的无效流量,将宝贵的带宽资源更多地用于有效数据的传输。发送端根据ECN标记进行的主动降速,是一种比TCP超时重传或激进降窗更为温和的流量调控方式,有助于维持网络管道的高利用率,从而在整体上提升智算集群的网络吞吐能力。

3.4  IPCC

3.4.1  基本概念

IPCCIntelligent Proactive Congestion Control,智能主动拥塞控制)与ECN技术类似,也是一种通过拥塞通知报文来通知发送端降低报文发送速率的拥塞控制技术。IPCC是由网络设备主动发起的拥塞控制技术。用于转发RoCEv2报文的网络设备接口如果开启了IPCC功能,则设备根据该接口的拥塞情况,主动发送拥塞通知报文通知发送端降低发送速率。设备可以基于接口队列的拥塞程度,智能计算需要发送的拥塞通知报文数量,精准调整发送端速率,避免过度降速。

IPCC和传统ECN技术的对比如1所示。

表1 IPCC和传统ECN技术对比

技术对比

IPCC

传统ECN

发送拥塞通知报文位置

转发报文的网络设备

报文的接收端

报文拥塞的响应过程

直接主动响应。由网络中出现拥塞点的设备发送拥塞通知给报文发送端,拥塞点快速触发,通知发送端降速

间接被动响应。被标记的报文需传播整条转发路径抵达接收端后再由接收端发送拥塞通知报文通知发送端降速

发送端降速的效果

出现拥塞点的网络设备根据拥塞接口上队列长度和缓存占用,智能计算需要发送的拥塞通知报文个数,精确控制发送端降速

报文接收端如果持续收到ECN域取值为11的报文时,将每隔一定时间周期发送拥塞通知报文给报文发送端降速,降速效果滞后于拥塞点的实际变化

应用场景

仅对RoCEv2报文生效

对于TCPUDP等报文均能生效,适用范围更广

硬件支持要求

需要硬件芯片和驱动支持

需要硬件芯片和驱动支持

 

1比较可知,IPCCECN功能基础上进行改进,使转发设备具备发送拥塞通知报文的能力,对于网络中拥塞控制更加准确和迅速。

3.4.2  实现原理

由于IPCC功能仅对RoCEv2报文生效,下面先简单介绍RoCEv2报文的结构和关键信息。

RoCEv2InfiniBand是目前主流的RDMA协议。但相较于InfiniBandRoCEv2是基于以太网的RDMA协议。如17所示,RoCEv2基于UDP协议封装,其目的端口号固定为4791RoCEv2InfiniBand的主要区别在数据链路层和网络层。RoCEv2报文传输层继承了InfiniBand报文中传输层的Base Transport HeaderExtended Transport Header的结构和信息。

图17 RoCEv2InfiniBand报文格式对比

 

根据InfiniBand Architecture Specification标准,BTHBase Transport Header,基本传输层报文头)中包含了RoCEv2报文的关键信息,部分字段含义如下:

·     OpCode:表示RoCEv2的操作类型,也标识了BTH之后携带的ETHExtended Transport Header,扩展传输层报文头)的类型。具体类型包括但不限于:

¡     Send:此类操作用于发送端向远端请求传递数据,发送端不指定接收端存储数据的地址。

¡     RDMA Write:此类操作用于发送端向远端请求写入数据,发送端会在报文中指定接收端存储数据的地址、key(关键值)和数据长度。

¡     RDMA Read:此类操作用于发送端向远端请求读取数据,发送端会在报文中指定远端请求数据的地址、key和数据长度。

¡     ACK:表示ACK报文,远端接收到一组RoCEv2报文,会反馈的应答消息。

操作类型为SendWriteReadRoCEv2报文也被称为RoCEv2数据报文。

·     Destination QPDestination Queue Pair):目的端的队列编号,用来标识一条RoCEv2流。通常,在RoCEv2数据报文中执行SendRDMA WriteRDMA Read操作时,发送端和目的端都会创建队列,生成一个队列对QP发送队列用于存储发送端的消息和请求,接收队列用于存储远端发送的消息或请求。Destination QP是建立RoCEv2流表的关键信息。

·     ACK Request:应答响应要求标记位,表示是否要求远端发送ACK的响应。

·     PSNPacket Serial Number):表示RoCEv2报文的序列号,可通过检测PSN是否连续来判断是否存在丢失的数据包,若出现丢包,就会返回NAK报文。

图18 IPCC工作原理图

 

IPCC的工作原理如18所示。

·     建立RoCEv2流表:在转发设备上,启用了IPCC功能的接口复制经过该设备的RoCEv2数据报文,并将其上送到设备的CPU处理。根据RoCEv2报文的源IP地址、目的IP地址和目的QP信息建立RoCEv2流表。RoCEv2流表中包括流量的入方向接口和出方向接口、出接口队列的相关信息。

持续存在RoCEv2流量时,设备上保持并维护RoCEv2流表。如果出接口上发生拥塞,则可以根据RoCEv2流表定位到该业务流的出入接口。

·     智能计算拥塞通知报文数量:转发设备对接口中启用了IPCC功能的队列进行检测,根据队列长度以及队列占用缓存空间的比率变化智能计算主动发送的拥塞通知报文数量。

¡     当队列长度增加,队列缓存占用率较少,则发送少量拥塞通知报文给发送端,缓解队列拥塞,但不会使发送端过度降速;

¡     当队列长度增加,队列缓存占用率较多,则发送较多的拥塞通知报文给发送端,快速缓解队列拥塞,降低转发时延。

¡     当队列长度减少,队列缓存占用率较少,则不发送拥塞通知报文给发送端,防止降速造成吞吐率下降;

¡     当队列长度减少,队列缓存占用率较多,则发送少量拥塞通知报文给发送端,在尽量保证吞吐率和时延性能的情况下缓解队列拥塞。

转发设备根据RoCEv2流表中的地址信息构造拥塞通知报文,并主动将拥塞通知报文发送给发送端。发送的拥塞通知报文数量为上一步中计算出的报文数目。发送端收到拥塞通知报文后,通过降低RoCEv2报文的发送速率来缓解网络拥塞。

IPCC功能克服了传统ECN所面临的局限性,它通过更精细的算法来确定何时以及如何发送拥塞通知报文。这种改进方法依赖于对网络状况的实时分析,以计算出恰当的拥塞通知报文发送频率。该机制确保拥塞通知的发送既迅速又精确,以便及时地缓解网络拥塞情况,而不会引起不必要的性能下降。IPCC功能通过动态调整通知报文的发送,优化了网络流量管理,从而提高了整个网络的数据传输效率和稳定性。

3.5  iNOF

3.5.1  iNOF简介

iNOFIntelligent Lossless NVMe Over Fabric,智能无损存储网络)是一种以太网和存储网络的融合优化技术。它能实现海量存储设备的自动发现,网络故障的快速感知,并将存储设备的加入和离开第一时间通知给智能无损网络内的所有设备,为实现智能无损网络的“无丢包、低时延、高吞吐”提供基础支持。

1920所示的iNOF网络中,包括以下三个重要元素:

·     iNOF主机:支持iNOF协议的网络服务器和磁盘设备,以下简称主机。

·     iNOF交换机:用于接入主机且支持iNOF功能的交换机。

·     iNOF域(Zone):iNOF使用域来管理主机。当域内有主机加入或者离开,iNOF会将这个主机的加入和离开信息通知给同一域内的其它主机,以便其它主机能够感知同一域内任一主机的加入或者离开。

图19 iNOF直连组网示意图(小规模组网)

 

图20 iNOF跨交换机组网示意图(大规模组网)

 

3.5.2  iNOF的基本原理

iNOF在运行过程中,会用到如2所示的报文自动发现主机、快速感知网络故障或者通告主机状态变化和同步配置。

表2 iNOF相关报文描述表

报文名称

发送方——>接收方

报文描述

扩展的LLDP通告报文

主机——>iNOF交换机

用来告知直连的iNOF交换机,本主机的加入以及主机参数的变化

iNOF状态通知报文之通知报文

iNOF交换机——>主机

用来通知同一域中的其它主机,有主机离开iNOF

iNOF状态通知报文之ACK报文

主机——>iNOF交换机

用来对收到的通知报文的确认

iNOF报文

iNOF交换机——>iNOF交换机

用来同步配置以及将本地检测到的主机状态变化告知对端iNOF交换机

 

2. 扩展的LLDP通告报文

iNOFLLDP通告报文进行了扩展,重新定义了LLDP通告报文中的部分字段来实现主机加入通告功能。iNOFLLDP通告报文的重新定义主要体现在以下方面:

·     通过ChassisIDPortID字段携带主机标识,用“ChassisID+PortID”唯一标识一台主机。

¡     Chassis ID:采用主机上接入iNOF网络的端口的MAC地址(例如0800-271a-494f)表示。

¡     PortID:采用“前缀+端口名称”的格式表示。前缀采用固定字符串。

·     通过新增LLDP扩展TLV携带主机iNOF参数

图21 iNOF扩展TLV格式

3. iNOF状态通知报文

iNOF通知报文是一类自定义的以太网帧,其EtherType字段取值为固定的预留值,在不同规范中,取值不同。当某主机的网络状态发生变化(例如加入、离开或者接入链路故障等)时,与主机直连的iNOF交换机检测到主机网络信息变化,会给直连的、同一域中的其它主机发送状态通知报文,使得其它主机能尽快感知到网络状态的变化,以便其它主机和新主机及时建立连接、和离开的主机断开连接,或者快速地进行链路切换。

状态通知报文分为两种:

·     通知报文:在iNOF交换机上生成、发给主机的报文,用于通知主机的网络信息变化。

·     ACK报文:在主机上生成、发给iNOF交换机的报文,用于对收到的通知消息进行确认。

iNOF通知报文的格式如22所示,

图22 iNOF状态通知报文格式

 

4. iNOF报文

BGPiNOF新增了BGP iNOF地址族,并通过BGP Update消息中的MP_REACH_NLRIMultiprotocol Reachable NLRI,多协议可达NLRI)携带iNOF路由信息。在BGP iNOF地址族中,设备可以交互iNOF路由信息,iNOF路由信息用于传递主机的加入或离开消息,以及iNOF的配置信息。

23所示为BGP iNOF报文格式。报文中BGP Header区域的Type字段取值为2,表示该报文为BGP Update消息。BGP iNOF报文的Unfeasible routes length字段取值固定为0iNOF路由信息封装在Path Attributes字段。

图23 BGP iNOF报文格式

 

3.5.3  iNOF的价值

在智算网络中,iNOF具有以下部署价值:

·     自动化拓扑感知,加速业务上线

在智算网络中,服务器和分布式存储节点常需动态扩容或替换。传统方式依赖人工配置IP、路由和多路径策略,耗时且易错。iNOF通过扩展LLDP协议,实现了主机(服务器/磁盘)接入时的自动识别与通告。iNOF交换机实时感知新设备加入,并通过状态通知报文广播给同域内所有订阅主机。

·     故障快速感知机制,保障算力连续性

AI训练等长周期任务中,若某块远程NVMe存储因链路故障不可达,传统网络可能需数十秒甚至分钟才能检测到连接中断(TCP Keepalive超时),造成GPU空转、梯度同步失败。当网络故障时,iNOF交换机能够快速检测到故障,并将故障状态信息同步给网络中的其他iNOF交换机以及通知同一iNOF域中的其他主机。如果该网络故障影响了存储设备,则网络服务器会快速断开与该存储设备的连接,将业务切换到冗余路径。

·     基于BGP反射器架构,实现可扩展的智能无损网络

小规模直连组网难以满足现代智算中心成百上千节点的需求。iNOF复用BGP协议栈与路由反射器技术,构建了可扩展的控制平面,支撑大规模组网。

4 智能流量调度体系

4.1  SprayLink

4.1.1  产生背景

随着数据中心对高性能网络的需求日益增长,RoCERDMA over Converged Ethernet)等低延迟、高带宽协议在大规模集群中得到广泛应用。然而,实际网络环境中通常同时承载大流量的“大象流”(如业务数据)和对丢包极为敏感的小流量“老鼠流”(如RoCE报文)。传统的负载均衡机制往往导致大象流集中在少数链路上,引发严重拥塞,而其他链路资源利用不足,带宽利用率低下。同时,RoCE对报文有序性的严格要求进一步增加了负载均衡的复杂度。

为了有效解决上述难题,H3C推出了SprayLink(逐包喷洒)技术。该技术通过端网协同的逐包负载分担机制,实现流量在多条路径上的均匀分布,显著提升链路带宽利用率,缓解拥塞压力。同时,SprayLink确保RoCE等敏感业务的报文有序且可靠传输,全面优化网络性能与资源效率,助力高性能数据中心网络的稳定与高效运行。

4.1.2  技术价值

SprayLink技术的核心价值可高度概括为以下四大方面:

·     高带宽利用率:通过逐包负载分担结合动态负载度量,实现多链路总带宽利用率超过95%,显著优于传统基于哈希的逐流负载均衡方案。

·     精细负载均衡:以逐包为粒度进行负载分担,特别针对大流量传输进行优化,避免链路拥塞,提升整体网络稳定性。

·     强动态适应性:基于实时带宽和队列深度测量的Spray HASH算法,能够智能感知网络负载变化,动态调整路径选择,实现精准高效的流量调度。

·     兼顾协议特性与性能:在数据中心RoCE环境中,区分不可乱序的协议报文与可乱序的数据报文,确保敏感流量的低延迟和高可靠传输,全面提升网络性能。

图24 SprayLink技术价值

 

4.1.3  工作机制

SprayLink通过识流分类动态选路乱序重组三个步骤,保障RoCEv2网络负载均衡与报文有序,提升吞吐、降低时延,实现高性能可靠传输

图25 SprayLink实现机制

 

4.1.4  应用场景

在某数据中心的RoCE网络中,流量特征如下:

·     RoCE业务大象流:主要用于AI训练,约占总带宽的70%

·     普通业务老鼠流:包含HTTPS请求与响应、应用间API调用及少量数据的查询、增删改操作,约占总带宽的20%

·     RoCE协议报文老鼠流:用于RoCE网络的建立与维护,约占总带宽的10%

传统负载分担方式中,大象流往往集中于单一路径,导致部分链路负载过高,而其他链路利用率偏低。负载不均不仅降低整体带宽利用率,还可能引发高负载链路上的业务异常和性能瓶颈。

26所示,在该数据中心网络中应用SprayLink技术后,实现了流量的逐包动态负载分担:

·     大象流与老鼠流根据链路实时负载指标(如带宽利用率和队列深度)被智能分配至多条路径,确保精细化且均衡的流量调度。

·     针对RoCE协议报文,SprayLink保证按流负载均衡,避免报文乱序,保障网络的无损传输和高可靠性。

整体方案显著提升链路带宽利用率,有效降低网络拥塞风险,保障数据中心RoCE网络的稳定高效运行。

图26 SprayLink应用场景

 

4.2  LBN

4.2.1  技术介绍

LBNLoad Balance Network)是新华三推出的网络级负载均衡技术,主要用于解决多入口多出口场景下流量分布不均、出口端口拥塞的问题,尤其适用于AI智算网络上行下行带宽1:1的高性能网络环境。

LBN通过对入端口和出端口进行分组和智能编排,并建立一对一的映射关系,确保来自同一入口的流量始终固定转发到指定的出口。这种方式不仅保持了逐流转发的数据包顺序,还能让多个出口端口承担均衡的流量负载,从而提升网络整体吞吐率。

4.2.2  技术价值

LBN具有以下技术价值:

·     流量精确负载分担:避免部分出口过载、部分闲置的情况。

·     满足复杂网络需求:适用多入口多出口的AI算力网络。

·     提升网络吞吐率:充分利用出口带宽资源。

图27 LBN技术价值

 

4.2.3  工作机制

LBN的工作机制分为三个阶段:

(1)     用户将入端口加入LBN组后,设备为LBN组中每个入端口设置LBN值,例如为Port 1设置LBN值为0

(2)     对出端口进行编号。根据路由表中每个等价路由组内的出端口顺序或二层聚合口成员端口的加入顺序,为出端口从0开始编号。例如,Port 4Port 5Port 6的编号依次为012

说明

路由表中所有相同目的地址不同下一跳可达的等价路由组成一个等价路由组。

 

图28 对出端口进行编号

 

(3)     每个等价路由组与每个LBN组形成映射关系。将每个LBN组中入端口的LBN值依次对每个等价路由组内的出端口数量进行取余运算,形成每个入端口与出端口的映射关系。例如,Port 1LBN值为0,等价路由组A中存在3个出端口。LBN03取余为0,则Port 1对应的流量出端口是编号为0Port 4

图29 形成映射关系

 

4.2.4  应用场景

LBN技术支持应用在等价路由(ECMP)场景和二层以太网链路聚合场景:

·     等价路由场景:同一目的地址存在多个等价下一跳时,LBN可以将不同入口的流量固定映射到不同的出端口。

·     二层以太网链路聚合场景:当多个入口流量经过聚合口(包含多个成员端口)转发时,LBN可将入端口与聚合成员端口进行一一绑定,实现精确分担。

4.3  DLB

4.3.1  技术简介

AI分布式训练(如All-Reduce通信模式)和大规模推理场景中,网络流量的不均衡会导致严重的“木桶效应”,即少数拥塞或高负载的节点/链路会拖慢整个集群的性能。传统基于哈希的静态负载均衡无法感知后端实时的负载变化,极易造成流量倾斜。因此可以使用DLBDynamic Load Balance,动态负载分担)技术,它通过实时感知网络状态与计算节点负载,动态调整流量分布,实现真正的“物尽其用”。

4.3.2  技术优势

·     实时感知与动态调整:快速响应网络拥塞和节点负载变化,实现精准流量调度。

·     提升资源利用率:避免局部过热,充分挖掘整个计算池的潜力,提升整体吞吐量。

·     降低任务完成时间:动态调度流量减少排队和重传,显著缩短AI训练和推理任务的端到端耗时。

·     增强系统弹性:在节点故障或性能下降时,自动将流量迁移至健康节点。

图30 DLB技术优势

 

4.3.3  技术原理

动态负载分担通过引入时间戳、实时负载度量(端口带宽负载、队列大小)因子,在时间和带宽空间两个维度优化了负载分担效果。其工作思想就是持续监控链路的负载状态,根据实际情况动态地将报文分配到负载较低的路径上,以实现负载均衡。

动态负载分担可以将流量根据时间间隔分割成多个部分,根据去往目的地每条路径的空闲情况,智能地分配每段流量的路径,确保整条流最大化利用链路资源并且高效地到达目的地。

图31 动态负载分担

 

在业务忙时,DLB流量分担更积极,会更频繁检测各个链路的负载指标,对于流量分配和流量切换更活跃,且调度的粒度更细,并在防止抖动的前提下作动态调整。而在业务闲时,网络整体负载低,各条链路利用率都不高,DLB的调度就会相对保守和平滑,只保持基本的近似均衡和负载分布,且调节动作小、调节间隔更长。

图32 业务闲忙对比

 

4.3.4  在智算网络中的应用场景

·     分布式训练作业:在数千卡的大型训练任务中,DLB可以平衡多个GPU服务器之间的梯度同步流量,避免单个链路拥塞成为瓶颈,显著缩短一次迭代的时间。

·     大规模模型推理服务:面对波动的在线请求,DLB可以将推理请求动态分发到负载最低的推理实例上,保证服务响应时间(SLA),同时提升集群的整体吞吐量。

4.4  FGLB

4.4.1  产生背景

在智算网络常用的Spine-Leaf组网中,如果使用通过传统hashDLB等手段进行负载,则存在如下缺陷:

·     路径调优时缺乏“全局视野”,即只能以本地链路状态作为依据进行负载分担,对于远端的拥塞则无法处理(例如下图中Leaf无法感知SpineLeaf端的拥塞)。

图33 FGLB产生背景

 

·     极难感知突发拥塞并捕获拥塞流。

·     发生拥塞后需要人工干预,在复杂场景中人工调优困难。

为了解决上述问题,H3C推出了FGLBFlexible Global Load Balance,灵活全局负载分担)技术。FGLB能够自动感知网络内的拥塞位置,并实时捕获拥塞时刻的流信息,从中挑选出适宜的带宽流进行快速路径切换。同时,FGLB会实时整网同步并计算路径质量,在路径切换和负载分担时可以综合全局状态选取最佳路径,提升整网业务性能。

4.4.2  技术原理

1. 技术原理简介

FGLB技术在SpineLeaf之间通过协议报文来传播链路信息和流表信息,然后各设备通过报文同步的信息实现负载分担以及路径切换。

2. 流量转发模式

FGLB技术存在两种流量转发模式:

·     调带宽模式:Leaf设备根据LQ报文中携带的链路带宽信息,对发往对端Leaf设备的流量进行类似于UCMPUnequal Cost Multiple Path,非等价多路径)的负载分担转发,以充分利用链路带宽,减少拥塞发生。

·     调流模式:多条链路等价负载分担,某条链路出现拥塞时,将流量切换至其他链路质量良好的链路中。

3. 调带宽模式的流量转发

在此模式下,Spine会收集去往Leaf的链路带宽信息,然后将其通过协议报文通告给其他Leaf

链路带宽信息完成全网泛洪后,Leaf 1发往Leaf 4的流量会在途径不同Spine的路径之间进行不等价的负载分担转发。负载分担的原则是:链路带宽级别更高的路径将承载更大比例的流量。例如,在34所示组网中,Leaf 1 Leaf 4的流量有两条路径可选——通过Spine 1和通过Spine 2的两条路径。假设通过Spine 2的链路具有更高的带宽级别,两条链路的带宽级别之比为1:3。这意味着,Leaf 1发往Leaf 4的流量中,25%会通过Spine 1转发,而75%会通过Spine 2转发。

图34 流量转发比例

 

4. 调流模式的流量转发

链路状态或链路质量值正常时,Leaf之间的东西向流量通过途径多个Spine的链路进行等价负载分担转发。

当转发路径中出现链路拥塞时(是否发生拥塞由设备自动判断):

·     35所示,如果SpineLeaf间存在多条负载分担链路,且仅部分链路出现拥塞,则会生成流表,将流量切换到剩余未拥塞且链路质量优的链路中。

图35 设备间负载分担链路发生拥塞时流量切换示意图

 

·     36所示,如果Spine 1Leaf 4之间只有一条链路,或所有链路的链路质量均较差,则Spine会通过协议报文向Leaf 1通告流表,使得Leaf 1将去往Leaf 4的流量切换到链路质量较好的路径。

图36 路径切换示意图

 

5. 链路Down时的处理

37所示,当链路Down时,例如Leaf 4Spine 1之间的链路DownSpine 1会向除了Leaf 4之外的三台Leaf设备都发送协议报文。Leaf设备收到协议报文后会将故障的下一跳进行失效处理,并通过剩下的下一跳负载分担转发流量,借此实现链路Down后的快速路径切换。

图37 链路Down时路径切换

 

4.4.3  技术总结

综上,FGLB技术通过多种机制,实现了全局视野调流,不仅能够根据全局链路状态,在避免拥塞的情况下进行负载分担和流量切换,还能在链路发生故障时快速响应, 以满足智算网络的高性能需求。

以道路上的车队为例,FGLB技术可以让每个车队的首车出发时都选择一条即时最佳路线,这条路线是基于当前所有路段的拥堵情况综合评估得出的。同时,为每个路由安装一个特殊的监控摄像头,这些摄像头会定期将路由拥堵情况发送给所有出发地。当路由出现拥堵时,道路管制系统可以决定哪些车队需要通过改道来缓解路由拥堵,并发出调度指令来指示车队路线。

4.4.4  在智算网络中的应用场景

在智算中心内,FGLB技术可以帮助网络有效分摊流量、消除热点,最大化利用CLOS网络的海量带宽,保障核心业务的高吞吐和低延迟。

图38 在智算中心应用FGLB

 

4.5  Traffic Matrix

4.5.1  Traffic Matrix简介

Traffic Matrix(流量矩阵)是一种主要应用在数据中心网络中,为AI大模型训练场景提供流量调度和负载优化的技术。Traffic Matrix由一条或多条流表组成,每条流表中可以定义报文的五元组作为流量的标识信息,同时流表中还指定了该条流量对应的出接口和下一跳用于控制流量的转发。当业务流量匹配到Traffic Matrix流表中的标识信息时,流量优先按照流表中指定的出接口和下一跳查表转发。

图39 Traffic Matrix示意图

 

AI大模型训练场景下,存在突发“大流”,即数目少(仅几十到几百条)、数据量巨大(超过Gbps)的流量。对通用计算业务中的“小流”而言,数据中心网络采用ECMP就可以得到负载均衡效果。但对于“大流”而言,ECMP极易造成网络负载不均衡,引起部分链路拥塞,从而极大地影响GPU并行训练的效率。Traffic Matrix技术可以用于智算网络中的流量调度,实现链路负载均衡。

4.5.2  Traffic Matrix的生成方式

动态Traffic Matrix是指由FGLBFlexible Global Load Balancing,灵活全局负载均衡)方式的自适应路由功能触发生成的Traffic Matrix 表项。在这种场景下,无需SDN控制器也可以实现流量的全局负载均衡。

40所示,Leaf 1去往Leaf 4的业务流量为例,Leaf 1上存在ECMP等价路径:

·     通过Spine 1转发的Link 1Link 2

·     通过Spine 2转发的Link 3Link 4

Spine 1监测到Leaf 1的远端链路Link 2发生拥塞(链路带宽利用率超限、端口队列深度过长)或故障时,Spine 1会生成基于UDPARNAdaptive Routing Notification,自适应路由通知)报文,并通知Leaf 1Leaf 1根据ARN报文中携带的Device ID和下一跳信息,排除ECMP等价路径中拥塞或故障的转发路径,再基于剩下的可用路径生成动态Traffic Matrix流表,指导业务流量转发。

图40 自适应路由动态生成Traffic Matrix示意图

 

4.6  路径导航

4.6.1  产生背景

在进行大规模模型训练时,网络传输呈现出突发性弱、单条流量通道带宽占用大的特征,这使得传统的负载均衡机制面临前所未有的挑战。现有均衡方法往往无法有效应对这种高度动态且集中的流量模式,易导致链路利用不足、拥塞几率上升,并显著拖慢训练进程。当前业内的改进手段多停留在单一侧面优化:仅在网络侧调整交换机调度策略,或只在计算节点端改进任务分发方式。由于缺少对全局状态的统筹感知,这类方案在适用范围、稳定性和性能一致性上都存在明显不足。针对这一瓶颈,新华三提出了路径导航技术,全局规划最佳业务路径,从而实现网络流量的均衡分布,为大规模AI模型训练提供了稳健的网络支撑。

路由导航技术分为如下两种:

·     端网协同路径导航技术:该技术通过端侧主动上报运行状态,结合网络控制器对全局链路状态的持续监测,动态预判潜在拥塞节点,并基于实时负载情况调整数据流向,从而保障数据传输的高效性与稳定性。

·     端侧解耦路径导航技术:该技术采用纯网侧实现方案,无需端侧设备参与或适配,通过NFLBNetwork Flow Load-Balance,网络流负载均衡)机制实现全局路径优化。其核心是基于网侧链路状态与拓扑信息进行集中式决策,动态调整流量路径,确保负载均衡与高效传输。相比端网协同方案,NFLB无需端侧代理部署或状态上报,降低了实施复杂度,同时仍能在大规模AI训练等场景下提供高性能的流量调度能力,尤其适用于端侧封闭或受限的环境。

4.6.2  端网协同路径导航技术

1. 技术简介

端网协同路径导航技术是一种面向智算场景的智能流量调度方案,通过端侧状态上报与网侧全局优化的协同机制,实现网络流量的智能调度与路径优化。该技术充分结合端侧设备的实时状态信息与网络侧的全局拓扑视图,构建端网一体的智能决策体系,为AI训练等高性能计算场景提供最优的数据传输路径。

2. 工作流程

41所示,在智算场景中,端网协同路径导航技术通过全局采集拓扑信息,智能建模+选路,并将路由策略下发给设备,实现路径调优。其工作步骤为:

(1)     AD-DC智算版本对组网进行拓扑采集,收集网络结构信息。

(2)     训练任务启动。

(3)     交换机采集流量数据后,发送给AD-DC智算版。

(4)     AD-DC智算版智能建模和选路,最后将优化后的路由策略下发至交换机,完成业务路径规划。

图41 端网协同路径导航流程图

 

3. 技术优势

·     智能流量均衡:通过多轮迭代优化,实现网络流量的动态均衡分布。

·     拥塞主动预防:基于预测模型提前规避潜在拥塞点。

·     AI训练加速:显著提升大模型训练任务的处理效率。

4. 关键技术

端网协同路径导航主要通过流量时间片建模和基于链路权重的选路算法两种技术实现全局路径调优。

5. 流量时间片建模技术

流量时间片建模技术基于时间维度分析流量行为,构建模型精准量化时间片特征,智能解析流量的串/并行关系。

图42 流量时间片建模示意图

 

工作原理:

(2)     收集流量时间维度信息

通过交换机收集链路上现有流量的传输时间片规律(如flow1flow2的占用时段)。

(3)     识别链路空闲窗口

通过对流量时间片信息建模,获取链路在时间轴上的空闲窗口idle(如flow1flow2传输间隙的空闲时段)。

将空闲窗口idle与待选路流量的时间片δ相匹配。

¡     串行关系:idle>δ表示待选路流量能负载到链路上的空闲窗口,与该链路上已选路的流量为串行关系。

¡     并行关系:idle<δ表示待选路流量不能负载到链路上的空闲窗口,与该链路上已选路的流量为并行关系。

6. 基于链路权重的选路算法

路径导航通过基于链路权重的选路算法为业务流量进行规划,根据流量时间片建模技术识别的串/并行关系,将流量均衡分配到所有可用链路上,避免单链路拥塞并最大化带宽利用率。

图43 并行流量示意图

 

43所示,在同一时间段中,并行flow1flow2flow3三股流量,此时选路算法会通过如下方式进行路径分配:

·     并行流选路:冲突的并行流,路径导航将流分布到不同路径,选择权重较低的链路。选路后,链路权重累加。

·     串行流选路:不冲突的串行流,路径导航可以分配同一路径。选路后,链路权重不累加。

44所示:

(2)     flow2flow3属于不冲突的串行流,算法将其合并分配至leaf1-spine1-leaf2路径。

(3)     flow1属于冲突的并行流,算法将其单独分配至leaf1-spine2-leaf2路径。

图44 链路权重算法示意图

 

4.6.3  端侧解耦路径导航

1. 产生背景

在当前的AI参数网络部署中,部分GPU服务器的端侧生态闭合,不支持开放接口或API供网络控制器获取运行状态。此外,有些服务器由于安全策略、厂商限制或管理规范,无法安装客户端代理程序,也不参与对网络适配功能的配合。这种情况下,传统依赖端侧状态上报的路径导航技术(端网协同路径导航)无法完整部署,造成网络流量引导、性能优化与故障快速定位的能力受限。

为解决上述限制,需要发展一种端侧解耦的路径导航方法,使网络控制器在不依赖服务器端状态上报、不需安装代理软件的前提下,依然能够实现AI参数网流量的智能调度与路径优化。该方法通过仅采集网侧链路状态及网络拓扑信息,结合算法在网络设备侧完成路径计算与负载均衡,从而实现与端侧计算资源的完全解耦。

因此,H3C提出了端侧解耦路径导航——NFLBNetwork Flow Load-Balance),一种新型的、不依赖端侧的、面向参数网络的流量负载均衡与路径导航机制。

图45 端侧解耦产生背景

 

2. 技术优势

46所示,通过解耦,NFLB技术带来如下技术优势:

图46 端侧解耦路径导航技术优势

 

3. 技术原理

端侧解耦路径导航的核心思想是完全依赖网侧链路和拓扑信息实现流量规划,而无需在端侧服务器安装代理或参与协议适配,从而实现端侧解耦。

NFLB的工作流程可分为设备侧流量感知与控制器侧路径规划两部分。

4. 设备侧:流量感知与上报

设备位于AI参数网络的Leaf层,直接连接GPU训练服务器,负责在网侧感知训练过程中的关键RDMA流信息,并通过硬件流表采集报文特征。

(1)     Leaf通过报文五元组(源目的IP、源目的端口号、协议号)以及OPCODE识别流特征,然后根据识别出的流量特征建立流表。

(2)     通过gRPC将流表信息上报给控制器。

图47 设备侧流量感知与上报

 

5. 控制器侧:路径规划与负载均衡

控制器在NFLB功能开启期间,汇总所有Leaf上报的流信息,分析训练迭代期间的网络通信关系,从而完成空间(路径)与时间(调度)的综合优化。

(1)     控制器收集全网流信息,捕获完整训练周期内的通信关系矩阵。

(2)     控制器从上送数据分析出流持续时间、流大小以及时序关系等结果。

(3)     基于流分析结果和收集到的拓扑信息,将流映射到可用路径的链路资源中,并基于时间和空间对路径进行复用或优化。

(4)     控制器将为流量规划的路径下发到Leaf设备,Leaf设备根据下发的路由转发表控制流量的转发。

图48 控制器侧路径规划与负载分担

 

 

4.7  大小流区分调度

4.7.1  技术介绍

大小流区分调度是一种面向数据中心网络的智能流量调度技术,通过在队列调度时对不同类型的流量采用不同策略,实现网络性能优化,满足各类业务对延迟和吞吐的不同需求。

在智算网络中,流量类型繁多,可根据五元组(源/目的IP地址、源/目的端口号、协议号)识别并划分为“大流”和“小流”:

·     大流:数量少但数据量大,占据约90%的总传输数据量,持续时间长、带宽占用高,对时延要求不敏感,如数据备份、迁移、AI大模型训练。

·     小流:持续时间短、带宽占用小,但对响应速度和时延极为敏感,如查询流量、在线请求。

大流可能因为流量调度在同一条链路上传输导致负载不均衡,链路的端口可能因突发大流造成拥塞,影响其他小流的传输。因此,需要将大流识别出来,并进行大小流区分调度,以满足小流的延迟需求和大流的吞吐率需求。

49所示,大小流区分调度机制如下:

(1)     网络管理员配置大流识别参数(流速和尺寸),设备根据识别参数将网络流量中的大流识别出来;

(2)     网络管理员为大流指定丢弃优先级、本地优先级或dot1q优先级,设备根据本地优先级或者dot1q优先级将识别出来的大流映射到特定的队列中,与其他非大流区分调度。一旦发生拥塞,设备也可以根据配置的丢弃优先级,优先丢弃大流报文,以保证小流的低延迟体验。

图49 大小流区分调度示意图

 

4.7.2  技术价值

大小流区分调度技术通过智能识别与差异化调度,实现了延迟敏感型业务与带宽密集型业务的共存优化,具有以下技术价值:

·     保障小流低延迟:避免大流占用关键链路资源影响小流响应。

·     提升网络吞吐率:合理调度大流,充分利用网络带宽。

·     优化链路负载均衡:减少大流集中在单一链路的情况,降低拥塞风险。

图50 大小流区分调度技术价值

 

5 高可用保障机制

5.1  DPSH

5.1.1  产生背景

在链路故障场景中,传统网络主要依赖控制平面的动态路由协议(如OSPFBGP)来感知拓扑变化并重新计算路径。即使结合BFD等快速检测机制,整体收敛时间仍处于毫秒级,难以满足AI计算、高性能存储等业务对网络高可靠性和超低延迟的严苛需求。

为降低对控制平面的依赖,DPSHData Plane Self-Healing,数据平面自修复)应运而生。DPSH将故障的感知、传递与处理功能下沉至数据平面,通过硬件层面实现快速路径切换,将收敛时间缩短至亚毫秒级,显著提升网络的可靠性与稳定性,满足关键业务的高性能保障需求。

5.1.2  技术价值

DPSH通过将智能检测与快速恢复能力下沉至硬件转发层,实现了网络性能的显著提升:

·     降低收敛时延:通过数据平面实现链路故障的快速处理,收敛时间缩短至亚毫秒级,远优于传统控制平面毫秒级的路由重收敛速度。

·     保障业务连续性:链路故障发生时实现流量的瞬时切换,最大限度避免报文丢失和服务中断,尤其适用于金融交易、云计算、AI训练等对网络延迟高度敏感的关键业务。

·     降低控制平面负载:将快速收敛机制下沉至硬件转发层,减少频繁的路由表更新对控制平面的冲击,提升整个网络的稳定性和响应能力。

·     增强数据中心网络韧性:故障处理在设备硬件内部完成,无需依赖复杂的上层协议,简化网络架构,增强系统的可靠性和抗故障能力。

图51 DPSH技术价值

 

5.1.3  应用场景

在数据中心的Spine-Leaf标准组网架构中,通常部署大量服务器以支持高密度数据交换。为满足数据中心网络对高性能和高可靠性的需求,DPSH功能可在SpineLeafBorder设备上部署。借助DPSH数据平面的快速故障收敛能力,当链路发生故障时,业务流量能迅速切换至备用路径,实现无缝切换,确保业务连续性和网络稳定性。

图52 DPSH应用场景

 

5.2  ISDF

5.2.1  产生背景

静默故障是指链路故障、物理接口状态为UP但无法转发流量、转发表项异常、配置错误等管理员难以快速识别、快速处理的故障。此类静默故障往往排故时间较长,对上层业务影响较大。为了解决以上静默故障问题,快速静默故障感知与恢复技术应运而生。

ISDFInstant Silent-Fault Detection and Failover,快速静默故障感知与恢复),是一种完全基于数据平面的故障感知和恢复技术。ISDF实现了从依赖控制平面的协议交互收敛方式,到基于数据平面的实时故障感知与快速换路收敛方式的技术演进。该技术采用数据面故障检测、远程故障通告和快速路径切换机制,实现毫秒级网络收敛,可以显著提升网络可靠性和数据传输效率。

5.2.2  技术价值

图53 技术价值

 

5.2.3  技术分类

图54 技术分类

 

5.2.4  有状态流静默工作机制

ISDF技术主要分为两个部分,分别是静默故障感知和静默故障恢复。有状态流静默,是指静默故障检测的流量为有状态的流量,即流量发送之前需要先建立连接关系;无状态流静默,是指静默故障检测的流量为无状态流量,即流量发送之前不需要先建立连接关系。当前有状态流静默仅支持RDMA流量类型。RDMA静默故障感知主要依赖RoCEv2RDMA over Converged Ethernet)报文中的PSN序列和ACK确认机制,可以实现快速感知静默故障。静默故障恢复是指,当设备感知到静默故障后,发送端设备通过修改报文的Hash seed值,报文携带新的Hash seed值进行转发,从而实现转发路径的快速切换。

1. RDMA静默故障感知

如下图所示,在RoCEv2报文传输过程中,发送端向接收端发送的报文中会携带PSNRoCEv2报文的序列号)。若接收端成功接收报文,则接收端会向发送端回应ACK确认报文,表示接收到ACK确认号前面的所有数据。当发送端超过一定时间后,没有收到ACK报文,则发送端将进行报文重传。报文重传超时将会造成PSN序列号乱序,RDMA静默故障检测正是基于此原理。若接收端收到的报文PSN序列号始终是连续增长的,则表示报文传输正常;若接收端最新收到的PSN序列号≤上一次收到的PSN序列号,则表示网络传输质量不佳,即可能出现了丢包、延迟过大等现象,同时判断网络发生了静默故障。

图55 RDMA静默故障感知原理图

 

2. RDMA静默故障恢复

当设备感知到静默故障后,设备发送的报文将携带如下2个信息,用于进行后续的路径切换:

·     换路标识Flag:表示是否切换过Hash seed,取值为1表示切换过Hash seed;取值为0表示未切换过Hash seed

·     Hash seed:用于在切换路径时,重新进行Hash选路。

如下图所示,Leaf1为发送端设备,Leaf3为接收端设备,Spine1Spine2为中间的传输设备。报文的原转发路径是Leaf1->Spine1->Leaf3。当该链路发生静默故障时,发送端设备Leaf1感知到静默故障,并生成故障流表。Leaf1设备将修改报文Hash seed值,同时将换路标识Flag置为11表示已切换路径)。报文携带新的Hash seed,切换转发路径为:Leaf1->Spine2->Leaf3,从而实现故障恢复。具体实现过程如下:

·     发送端设备:Leaf1根据故障流表匹配故障报文,并修改故障报文的Hash seed值。报文有了新的Hash seed,因此根据新Hash seed值进行Hash选路,选择的转发路径为Leaf1-> Spine2报文携带该Hash seed,被发送至传输设备Spine2

设备支持如下两种修改Hash seed值的方式:

¡     自动修改Hash seed值:设备使用预设的算法更新Hash seed值。

¡     手动修改Hash seed值:管理员通过命令行手动配置Hash seed值。

·     传输设备:Spine2根据报文携带的新Hash seed,重新Hash选路转发,报文被转发至接收端设备Leaf3

·     接收端设备:Leaf3接收报文。

图56 RDMA静默故障恢复原理图

 

5.2.5  无状态流静默工作机制

如下图所示的组网场景中,Leaf1为流量发送端、Leaf3为流量接收端,Spine1Spine2为核心转发设备。当Spine1Leaf3之间的链路发生故障时,ISDF无状态流静默感知和恢复技术的具体工作流程如下:

·     Spine1上部署流静默故障检测实例,当检测实例测量出存在流传输质量不符合预期(即流的丢包率达到管理员配置的阈值)时,Spine1设备将生成静默故障告警信息。

·     Spine1将静默故障告警信息以故障流表的形式,通过通告报文发送给Leaf1,指导Leaf1进行报文转发路径切换。

·     Leaf1收到故障流表后,将流量切换到轻负载链路进行发送。

图57 流静默工作机制示意图

 

5.2.6  端口静默工作机制

当接口的丢包率过高时,可能导致业务流量的传输质量下降,影响用户体验和业务连续性。通过开启端口静默故障监测功能,可以实时监测接口的丢包率。当检测到接口的丢包率超过预设的门限值时,系统会产生端口静默故障事件,并通知业务模块处理接口故障,例如关闭接口,避免继续影响业务流量。端口静默感知技术的具体工作流程如下:

·     启动条件:在设备接口开启端口静默故障监测功能后,若接口流量带宽百分比低于启动门限值,则不激活端口静默故障监测功能。当接口流量带宽百分比达到启动门限值,则激活端口静默故障监测功能。

·     检测机制:端口静默故障监测功能激活后,系统会周期性监测接口出入方向的丢包率。若检测到丢包率超过丢包故障门限,系统会产生端口静默故障事件(如关闭接口),并通知相关模块进行相应的处理。

图58 端口静默工作机制示意图

 

5.2.7  应用场景

某企业对网络性能和可靠性要求较高,此时可以部署ISDF功能,实现基于数据平面的静默故障快速感知和恢复。如下图所示,Leaf1Leaf3为发送端设备和接收端设备,Spine1Spine2为传输设备。由于某种原因报文无法通过Leaf1->Spine1->Leaf3路径转发,用户希望能够快速感知故障,并及时将业务流量切换到备份链路上。此时可以在Leaf1上部署ISDF功能,当Leaf1感知到静默故障后,将业务流量切换到Leaf1->Spine2->Leaf3路径。

图59 ISDF应用组网图

 

5.3  M-LAG

5.3.1  M-LAG简介

M-LAGMultichassis Link Aggregation,跨设备链路聚合)是基于IEEE P802.1AX协议的跨设备链路聚合技术。M-LAG将两台物理设备虚拟成一台设备来实现跨设备链路聚合,从而提供设备级冗余保护和流量负载分担。

在智算网络中,除了用于训练和推理的超节点网络和集群网络外,仍需要传统的DCNData Communication Network)网络,即UECUltra Ethernet Consortium,超以太网联盟)规范中定义的Frontend网络,Frontend网络是数据中心内部连接所有计算节点与外部世界(如其他数据中心或互联网终端客户)的运营网络。M-LAG技术主要应用在DCN网络中,将可靠性从链路级提高到设备级。

图60 M-LAG跨设备链路聚合的网络模型

 

61所示,Device ADevice B组成的M-LAG系统中:

·     M-LAG主设备:部署M-LAG且状态为Primary的设备。

·     M-LAG备设备:部署M-LAG且状态为Secondary的设备。

·     peer-link链路:M-LAG设备间的交互M-LAG协议报文及传输数据流量的链路。peer-link可以是聚合链路,也可以是Tunnel隧道,管理员需要根据不同组网环境选择peer-link链路。当采用聚合链路作为peer-link链路时,建议将多条链路进行聚合。一个M-LAG系统只有一条peer-link链路。

·     peer-link接口:peer-link链路对应的接口,可以是聚合接口,也可以是Tunnel接口。每台M-LAG设备只有一个peer-link接口。

·     Keepalive链路:M-LAG主备设备间的一条三层互通链路,用于M-LAG主备设备间检测邻居状态,即通过交互Keepalive报文来进行peer-link链路故障时的双主检测。

·     M-LAG组:用于部署M-LAG设备之间的配对,M-LAG设备上相同编号的M-LAG接口属于同一M-LAG组。

·     M-LAG接口:M-LAG主备设备与外部设备相连的二层聚合接口。为了提高可靠性,需要使用动态聚合。M-LAG设备上相同编号的M-LAG接口属于同一M-LAG组。M-LAGIDM-LAG接口编号。

图61 M-LAG系统示意图

 

M-LAG设备间通过peer-link链路上交互DRCPDistributed Relay Control Protocol,分布式聚合控制协议)报文和Keepalive报文建立和维护M-LAG系统。在M-LAG系统正常工作时,M-LAG系统的主备设备负载分担共同进行流量转发。如果M-LAG系统中出现故障(无论是接口故障、链路故障还是设备故障),M-LAG系统都可以保证正常的业务不受影响。

5.3.2  M-LAG系统GIR

M-LAG系统不仅提供更高的可靠性保障,还支持GIRGraceful Insertion and Removal,平滑插入和移除)功能,可以做到业务不中断的情况下独立维护或者在线升级。

62所示,GIR提供了一种设备隔离方案,可协助M-LAG系统中单个设备进行独立维护或升级。通过一键GIR模式切换将设备置于维护模式,处于维护模式的设备将停止多个路由协议等业务功能,流量切换至备份冗余设备或路径中转发。当完成维护或者升级操作之后,再将设备快速切换到普通模式,恢复业务功能同时使流量正常通过维护升级后的设备处理。

图62 M-LAG系统通过GIR功能独立维护或者升级

 

5.3.3  M-LAG VLAN双活网关

M-LAG VLAN双活网关是指组成M-LAG系统的两台M-LAG设备均作为用户侧的网关,回应用户侧的ARP/ND请求并转发用户侧的报文,以提高网关的可靠性。两台M-LAG设备同时作为三层网关,通过动态路由协议连接用户侧设备。此时:

·     当一条接入链路发生故障时,业务流量可以快速切换到另一条链路,保证可靠性。

·     两条接入链路可以同时处理用户流量,以提高带宽利用率,使流量在两条接入链路上负载分担。

63所示,M-LAG双活网关主要用于接入侧设备通过动态路由接入M-LAG的组网环境中。在M-LAG系统与用户侧设备之间建立动态路由协议邻居:

·     M-LAG设备Device ADevice B上各创建一个相同编号的VLAN接口(例如Vlan-interface100),该接口作为网关接口,具有相同的IPv4地址、IPv6地址和MAC地址,且M-LAG接口允许该VLAN通过。

·     在该VLAN接口下配置IP地址不同的M-LAG虚拟地址,用于IGP/BGP动态路由协议邻居建立,使得M-LAG设备和Device C之间建立IGP/BGP邻居,M-LAG设备之间也会建立IGP/BGP邻居。

图63 动态路由接入M-LAG示意图

 

M-LAG VLAN双活网关的工作机制为:

·     M-LAG设备采取本地优先转发原则,设备收到报文后直接转发,无需绕行peer-link链路到对端M-LAG设备转发。例如,M-LAG设备Device A收到Device C发送的ARP请求,则直接向Device C发送ARP应答报文,无需转发到Device B处理。

·     当一条链路发生故障时,流量可以快速切换到另一条链路,保证可靠性。例如,Device ADevice D之间链路故障,则流量处理方式为:

¡     访问Device C的下行流量快速切换到Device B处理,不再转发到Device A

¡     访问Device D的上行流量,转发到Device B时,处理完成后直接向Device D转发;转发到Device A时,流量将通过peer-link链路绕行到Device B处理,然后向Device D转发。

·     Device C的两条接入链路可以同时处理用户流量,以提高带宽利用率,使流量在两条接入链路上负载分担。

5.3.4  M-LAG的价值

M-LAG技术通过其独特的冗余机制,为DCN网络提供高可靠的保障机制,其核心价值包括:

·     消除单点故障,构建高可靠的网络接入层:M-LAG将可靠性从链路级提升至设备级。当其中一台M-LAG成员设备完全宕机时,另一台设备能够无缝接管所有流量,实现亚秒级的故障切换。

·     实现多路径负载均衡,最大化链路利用率:两台设备组成的M-LAG系统可以提供更多接入端口,支持更大规模的服务器集群接入。M-LAG支持双活技术,在AI训练中,梯度同步的流量可以同时通过两条上行路径,有效降低了网络瓶颈风险,缩短了训练时间。

·     简化网络拓扑与配置,降低运维复杂度:M-LAG在提供高级别可靠性的同时,保持了网络的简洁性。相较于IRF等虚拟化技术,在升级或分裂时可能面临复杂的数据重建和配置风险。M-LAG可以通过GIR保障独立维护和升级,几乎不影响业务。

5.4  光模块通道保持技术

5.4.1  技术背景

在现代人工智能的训练环境中,大规模的计算卡通常通过光纤链路进行数据交换,以确保高效的协同工作。然而,光纤链路的中断可能导致训练任务暂停。这种中断不仅会引起系统的暂时停滞,长时间的故障甚至可能迫使训练中断数小时甚至数天,严重延误AI模型的开发进度,并显著增加运维时间和成本。

在实际应用中,光纤链路中断往往是由于光模块中的个别通道出现问题,但其他通道仍然具备正常工作的条件。因此,如果在个别通道出现问题时,能够保持其他通道的正常工作,就可以降低训练任务中断的频率和影响,从而提升整体系统的稳定性和效率,有效支持AI模型的持续开发与优化。

针对由个别通道故障引发的光纤链路中断问题,光模块通道保持技术提供了一种有效解决方案。该技术通过灵敏的端口状态检测,实现了光链路通道的实时切换,从而降低了故障发生率,保障训练任务的连续性。

5.4.2  技术实现

1. 总体实现

光模块通道保持技术总体实现如下:

(1)     开启光模块通道保持功能,监测端口状态变化。

(2)     如果监测到端口出现down状态,则检查对应端口的所有通道。

(3)     如果仅存在部分通道故障,光模块仍然存在可用通道,则将流量切换到可用的通道上,端口更新为UP状态。需要注意的是,通道一般按组工作,任一通道异常会导致所属组内其他通道无法工作。

(4)     如果所有通道均故障,光模块无可用通道,则端口仍然为down状态。

图64 光模块通道保持技术实现示意图

 

2. 通道切换

在检测到仅有部分通道故障时,系统能够迅速把数据流量切换到其他正常工作的通道。这种智能流量管理策略确保了即便某个通道失效,也不会影响整个训练任务的进行。

·     当光模块无故障时,所有通道均正常工作,参与流量转发。

·     当光模块部分通道出现异常时,设备会将异常通道所在组内的所有通道均阻塞掉,仅使用正常的通道组进行流量转发。

图65 通道切换示意图

 

如上图所示,400G光模块包含4个通道,其中,Lane 0Lane 1属于同一个通道组,Lane 2Lane 3属于同一个通道组。当Lane 0异常时,设备会将Lane 0Lane 1均阻塞掉,仅使用Lane 2Lane 3转发流量。

6 智能运维技术

6.1  AD-DC智算版

6.1.1  产生背景

随着人工智能与深度学习技术的飞速演进,算力需求呈现爆发式增长,GPU服务器集群规模正从数千卡迅速扩展至数万卡甚至更高,尤其在支撑多模态大模型训练时,这一趋势更为显著。集群规模的指数级扩张,带来了前所未有的运维复杂性:故障根源往往横跨计算域、网络域和存储域,涉及软件、硬件、驱动、配置、性能等多维度问题,单一域的监控数据难以支撑精准的根因分析。例如,网络传输效率下降可能并非由网络链路故障直接导致,而是源于服务器网卡驱动兼容性问题或后端存储I/O瓶颈,此类隐性因素易使问题被误判为网络层异常,从而延长故障定位周期。

与此同时,高效的训练复盘对优化模型收敛性、提升资源利用率和降低成本至关重要。它能通过分析训练过程中的瞬时事件(如毫秒级性能波动)、模型结构与超参数,识别潜在风险并指导后续优化。但传统运维体系严重依赖离散化监控工具,缺乏对训练过程的流级、毫秒级数据采集能力,且计算、存储、网络域的日志与指标分散在孤立系统中,无法实现全局关联分析。这使得故障复盘流于表面,难以捕捉瞬时瓶颈,更无法为资源调度和模型迭代提供数据支撑。

面对上述挑战,仅靠局部优化已无法满足大规模集群的运维需求。亟需一套具备全流程运维能力的解决方案:它必须支持高精度实时数据采集(如GPU利用率、网络吞吐量)、全域日志分析、跨域信息整合与分析、智能化瓶颈识别与优化建议,从而将故障定位从“经验驱动”转向“数据驱动”。

AD-DC智算版,又称为AD-AIDCApplication-Driven Artificial Intelligence Data Center,应用驱动的人工智能数据中心),正是为此而生——它基于统一数字底盘,融合计算、网络与存储域的监控组件,提供一站式入口,实现从部署、实时监控到闭环优化的全流程覆盖。通过智能分析引擎,AD-AIDC不仅破解了跨域故障定位与训练复盘的行业难题,更奠定了未来智算中心大规模集群高效运维的基石。

图66 AD-AIDC简介

 

6.1.2  关键技术

AD-AIDC面向万卡级超大规模AI数据中心,集自动化部署、智能流量调度、全域可视化监控、训练前后故障防控与优化分析于一体,并支持新一代DDC组网,实现算力、网络、存储的高效协同,大幅缩短部署周期、提升资源利用率与训练稳定性,助力AI任务高速顺畅运行。

AD-AIDC关键技术包括:

·     端网自动化开局:突破性采用端网协同、意图建网理念,通过意图驱动的自动化部署流程和智能化的故障检测与响应实现部署效率的跃升。

·     路径导航:通过多轮迭代收集流量信息,智能规划最佳业务路径,并将路由策略下发至交换机,从而实现网络流量的均衡分布,减少拥堵,显著提升任务处理效率,加速AI大模型的训练进程。

·     端网存全局可视:对计算(端)、网络(网)、存储(存)等核心基础设施,以及虚拟化、容器和操作系统等全域资源的统一、透明、实时、多维的可视化监控与管理。通过全局可视化体系,运维人员可在统一界面实时掌握智算中心的整体运行健康状况。

·     训前检测:在训练任务开始前,AD-AIDC通过一键巡检与一键压测,提前发现并解决计算、网络、存储等领域的潜在故障,确保集群环境处于最佳状态,从源头上降低训练过程中的故障风险。

·     训中监控:训练过程中,AD-AIDC通过全域实时监控和智能分析,帮助运维人员及时掌握集群运行状态,快速感知和定位潜在故障。

·     训练复盘:训练结束后,AD-AIDC支持对整个训练过程进行多维度的回溯分析,助力用户优化未来的训练任务和基础设施配置。

·     支持DDC组网:AD-AIDC提供了极简部署方案和全局视野的智能运维工具,有效解决DDC大规模组网时配置复杂、人工操作耗时且易出错、开局周期长、租户资源调度困难等问题;同时针对VOQ+信元转发模式导致的网络黑盒化,提升故障定位的效率和准确性。

6.1.3  系统架构

67所示,AD-AIDC主要由以下四个组件组成。

·     SeerEngine控制组件:AD-AIDC系统的核心之一,负责智算网络、计算节点及存储节点的自动化配置,使得数据中心能够高效地进行硬件和网络资源的配置和管理,确保整个数据中心的运行效率和性能最大化。

·     SeerAnalyze分析组件:专注于智算业务的网络和计算节点监控,以及流量分析和路径展示。该组件提供深入的分析和可视化工具,帮助管理员理解数据流动,监控系统性能,并识别潜在的瓶颈或问题区域。

·     IOM控制组件:负责监控计算、存储及第三方设备的通用基础架构信息。它为智算中心的基础设施元素提供全面的监控功能,确保所有关键组件的健康状态和性能可控。

·     Unisystem组件:AD-AIDC系统中专门负责计算与管理系统的部分,用于批量服务器部署和管理。Unisystem组件简化了服务器的部署过程,使大规模环境中的服务器管理更为高效和易于操作。

图67 AD-AIDC系统架构

 

6.2  基于gRPCTelemetry

6.2.1  技术简介

Telemetry是一项监控网络设备性能和故障的远程数据采集技术。基于高性能开源软件gRPC Google Remote Procedure CallGoogle远程过程调用)可以实现Telemetry,使网络设备自动读取其接口流量等各种数据并实时上报给采集器,为网络质量分析和优化提供大数据基础。

6.2.2  组网模型

基于gRPCTelemetry主要用于自动化运维系统,该系统包括以下网络组件:

·     网络设备:对需要监控的数据进行采集,并通过gRPC报文上报给采集器。

·     采集器:接收和保存网络设备上报的监控数据。

·     分析器:分析监控数据,可以通过图形化等方式呈现分析结果。

·     控制器:根据分析结果,通过NETCONF等方式调整网络中的设备配置。

网络设备持续推送实时数据到网管侧的采集器,网管侧可以及时监测到网络质量问题并快速进行调整,形成一个闭环的自动化运维系统。

图68 基于gRPCTelemetry组网模型

 

6.2.3  工作模式

gRPC支持Dial-inDial-out两种模式。

1. Dial-in模式

在该模式中,网络设备作为gRPC服务端,采集器作为gRPC客户端。采集器向网络设备发起gRPC连接,并下发订阅。gRPC连接建立后,网络设备向采集器推送订阅数据。

图69 Dial-in模式示意图

 

2. Dial-out模式

在该模式中,网络设备作为gRPC客户端,采集器作为gRPC服务端。在网络设备上配置采集器需要获取的数据(称为“订阅”),由网络设备主动发起到采集器的连接,并向采集器推送订阅数据。

图70 Dial-out模式示意图

 

6.2.4  技术优势

·     高效压缩数据

gRPC使用GPBGoogle Protocol Buffers)编码格式,将数据高效地序列化和压缩为二进制编码,提高数据传输性能。传输后的GPB编码可被反序列化为编程语言对象。

图71 高效压缩数据

 

·     兼容多种编程语言

gRPC客户端和服务端通信的前提是使用相同Proto文件。 Proto文件作为一种IDL(接口定义语言),可生成多种编程语言的服务端/客户端初始代码。不同语言的服务端/客户端可通过Proto文件定义的Request/Response消息格式进行通信。

图72 兼容多种编程语言

 

·     利用HTTP/2加强传输性能

gRPC协议集成了HTTP/2协议。 HTTP/2是运行在TCP之上的应用层协议,具有首部数据压缩、多路复用、流量控制等性能增强特性。

6.3  基于ERSPANTelemetry

6.3.1  技术简介

ERSPANEncapsulated Remote Switch Port Analyzer,封装远程端口镜像)是一种三层远程镜像技术,通过复制指定端口、VLANCPU的报文,并将复制的报文发送到远程数据监测设备,使用户可以利用数据监测设备分析这些报文(称为镜像报文),以进行网络监控和故障排除。

6.3.2  工作机制

ERSPAN支持端口镜像和流镜像两种实现方式。

1. 端口镜像

73所示,端口镜像方式的ERSPAN通过在源设备上复制指定端口、VLANCPU上收发的全部流量,为其添加包含目的地址的ERSPAN/GRE封装后,利用IP网络将封装后的报文转发至远程的数据监测设备。这种方式能全面监控某个端口、VLANCPU的所有网络活动,适用于需要将整条链路或整个网段的流量完整复制并远程监控的场景,如集中式网络故障排查或安全审计。

图73 端口镜像方式的ERSPAN

 

2. 流镜像

74所示,流镜像方式的ERSPAN基于QoS策略,仅对网络中符合特定条件(如匹配特定的IP地址、协议类型等)的报文进行复制、封装,然后发送到远端数据监测设备。该方式能实现对流量的精细区分和选择性捕获,节省了带宽和分析资源,主要用于对特定应用或已知可疑流量的针对性故障诊断与安全分析。

图74 流镜像方式的ERSPAN

 

6.3.3  技术价值

基于ERSPANTelemetry将传统的网络镜像能力与现代的可观测性理念相结合,其核心价值在于为大规模、分布式的网络提供了一种灵活、真实且精细的数据采集与输送方案,为网络的自动化运维、智能分析和安全保障奠定了坚实的数据基础。

具体体现在以下几个方面:

·     实现全栈、真实流量的远程可观测性:突破了传统网元设备日志和SNMP指标的局限,能够将网络中真实、完整的数据包(而不仅仅是摘要统计数据)跨越三层网络传输到任意位置的数据监测设备。这为网络分析提供了最高保真度的原始数据。

·     提供无侵入式的精细化数据采集:与需要代理(Agent)或深度嵌入设备内核的采集方式不同,ERSPAN是一种旁路监听技术。它通过复制流量进行操作,不会影响原始报文的转发路径和性能,保证了业务网络的稳定性和安全性。

·     赋能主动与智能化的网络运维:持续输送的真实流量数据,使得运维团队能够从被动响应故障转变为主动发现潜在问题(如微突发、应用性能劣化),并为基于人工智能的运维提供数据基础,实现根因分析、容量预测和自愈网络的闭环。

6.4  网络显微镜技术

6.4.1  技术介绍

网络显微镜是一种针对高性能网络的精细化监测与分析技术,旨在毫秒级乃至亚毫秒级地捕捉网络运行状态和瞬时异常,帮助管理员快速定位问题、分析原因并进行优化调整。它特别适用于低延迟、高吞吐、稳定性要求高的网络环境,例如智算网络。

网络显微镜提供了四大分析工具,帮助管理员实现上述功能。

图75 网络显微镜四大分析工具

 

2. 毫秒级流量分析

毫秒级流量分析功能针对指定流量,提供高精度、细粒度的实时流量监控能力。对网络中各类流的吞吐量进行毫秒级统计,帮助管理员及时捕捉微突发和拥塞事件,精确掌握流量变化趋势。

通过下发ACL规则,对特定流量进行匹配。当收到符合条件的报文时,会根据报文的五元组信息(源IP地址、目的IP地址、源端口号、目的端口号和协议号)动态建立对应流表。然后通过数据分析平台,将不同流量的吞吐量随时间变化情况以折线图方式展示,便于直观分析流量特征和网络性能趋势。

图76 毫秒级流量分析折线图

 

3. 毫秒级端口分析

开启毫秒级端口分析功能,设备会周期性监控并采集端口队列中的各种关键数据,包括流量统计、转发速率、缓存使用情况和报文ECNExplicit Congestion Notification,显式拥塞通知)计数等。管理员可以根据实际需求自定义采集的数据类型,并将采集到的数据上报给数据分析平台进行进一步处理和可视化展示。

4. 拥塞流分析

拥塞流分析可以实时捕获导致网络拥塞的流量的五元组信息。当接口的缓存使用率第一次超过上限阈值(拥塞警戒线)时,设备会立刻开始采集接口缓存内的流信息(五元组信息)。当接口缓存使用率第一次低于下限阈值时,停止采集,并将这一时间段内采集到的流信息提供给数据分析平台进行分析和可视化展示。

根据数据流的占比情况,能够帮助网络管理员识别异常流量并定位分析具体拥塞原因和流量。

图77 数据流的占比情况

 

5. 时延分析器

时延分析器可以检测统计出接口的报文在单板或设备内处理和转发的时延,并进行时延等级的划分。用户可以根据实际情况,自定义配置各个等级的具体时延门限值,例如,将时延在0200纳秒内的报文划分到时延等级0,将时延在201400纳秒内的报文划分到时延等级1。然后在数据分析平台以可视化的形式展示时延分布情况。

管理员通过分析这些时延等级的分布情况,即不同等级的流量占比,可以更全面地评估当前网络的传输质量和流量拥塞状况。

6.4.2  技术价值

网络显微镜通过毫秒级的精细化监控和分析,为高性能网络提供了全方位的可视化运维能力,其价值主要体现在以下几个方面:

·     实时监控采集:支持在极短的周期(毫秒级)内采集数据,包括接口流量、缓存使用等,确保对每一个细小的网络波动进行实时监控。

·     实时上报与可视化:将监控和采集到的数据通过gRPC等协议及时上报到数据分析平台,并在数据分析平台实时可视化展示,使网络管理员能够在第一时间获取数据。这种实时数据上报机制避免了因延迟导致的问题放大和复杂化。

·     性能数据分析与评估:持续监控采集网络性能相关的各类数据,为后续网络管理员对拥塞趋势分析和网络性能评估提供基础数据。

·     优化与调整:根据实时数据分析结果,网络管理员可以对网络进行细粒度的优化调整。例如,通过自动或手动的方式优化调整网络关键参数或局部结构,以确保网络的高效运行。

图78 网络显微镜技术价值

 

6.5  UFA

6.5.1  产生背景

随着网络设备规模的不断扩大,网络设备承载的业务越来越多,用户对网络运维提出了新的更高的要求。全面监控整网流量信息,并能够及时检测和发现网络异常,对当前的网络运维至关重要。传统的网络监控技术,其各有优缺点,但是总体来说,均无法实现对整个网络的流量进行监控和保障。

统一流量分析(Unified Flow AnalysisUFA)是一种依托芯片能力实施的全网流量监控和分析技术。该技术旨在深入分析全网流量,帮助用户快速检测和准确定位网络故障,从而提升网络运维效率。

开启统一流量分析功能后,设备将对所有进入设备的TCP/UDP/VXLAN流量进行NetAnalysis统计分析。设备会基于流量的五元组等信息创建流表并收集流量统计数据,之后将统计结果上传至网络流分析数据处理器(NAP)进行进一步处理。通过分析数据流的转发路径、识别TCP异常以及分析转发丢包等操作,网络流分析数据处理器能够更全面地帮助用户了解网络中的数据流量走向。

6.5.2  系统组成

一个典型的统一流量分析系统由三部分组成:NDENetAnalysis Data Exporter,网络流数据输出者)、NAPNetAnalysis Processor,网络流分析处理器)和NDANetAnalysis Data Analyzer,网络流数据分析器)。NDENAP通常集成在一台设备上。

·     NDE:一般由设备的转发芯片来承担该功能。NDE通过流过滤规则中所定义的规则来筛选出需要进一步分析的特定业务流量。一旦识别出与流过滤规则相匹配的数据流,NDE会将这些数据上送至NAP,以便进行进一步的分析和处理。

·     NAP:通常为CPU的内置芯片承担该功能,主要负责接收NDE上送的数据流,并对其进行处理与分析。完成分析后,NAP会将结果发送给NDA

·     NDA:为一个具有图形化界面的网络流量分析工具,旨在简化数据的获取、展示和分析过程,以便用户使用。

如下图所示,当业务流途径多台设备时,只要往返方向路径相同,途径的每台设备都能够获取到该业务流的双向流量。这使得可以在这些设备上对有关该业务流的丢包、时延等各种指标信息进行分析。

图79 系统组成

 

6.5.3  技术优势

图80 技术优势

 

6.5.4  原理机制

1. 主要功能

统一流量分析技术可以实现对全网流量进行统计和分析,其依托设备内置芯片能力,可以做到1:1采样,同时不影响设备的转发性能。统一流量分析技术包括如下功能:全流分析、随流检测(iFIT)、丢包镜像(MOD)和超大时延流上报。

图81 主要功能

 

2. 工作流程

统一流量分析的具体工作流程如下:

(1)     NDE角色一般由设备的转发芯片承担,负责采集流量数据并生成硬件流表。

(2)     NDE会根据配置,定期向NAP上送硬件流表。

(3)     NAP角色一般由设备的CPU内置芯片承担,负责根据NDE上报的硬件流表,建立软件流表,并进行流量分析。NAP将根据配置信息,定期向NDA上送分析结果。

(4)     NDA是一个网络流量分析工具,具有图形化的界面。NDA收到NAP上报的流量分析结果后,通过可视化界面方式向用户展示。

图82 工作流程

 

统一流量分析的四个功能共用上述工作流程,其区别在于不同功能上报的流表信息有所不同,具体区别如下:

·     全流分析:该功能针对整网流量进行检测分析,其上报的流表信息最全面,主要包括流量的五元组信息、流开始和结束时间、VLAN IDVXLAN ID、出入芯片报文数等。

·     随流检测(iFIT):该功能主要针对网络实时流量进行检测分析,其上报的流表信息主要包括流量的五元组信息、iFIT染色位、iFIT染色周期、iFIT绑定接口信息等。

·     丢包镜像(MOD):该功能主要针对流量的丢包情况进行检测分析,其上报的流表信息主要包括流量的五元组信息、丢包报文数、丢包原因等。

·     超大时延流上报:该功能主要针对超大时延流进行检测分析,其上报的流表信息主要包括流量的五元组信息、报文的时延信息等。

6.5.5  应用场景

1. 端到端检测场景

如下图所示,在Spine-Leaf组网场景中,用户仅需要对流量经过的两端设备进行深入分析。此时,可以配置统一流量分析技术的随流检测(iFIT)功能对端到端流量进行检测分析。具体需求如下:

·     实现对Border1Leaf1之间的端到端流量进行检测分析。

·     实现对Border2Leaf2之间的端到端流量进行检测分析。

·     实现对Border1Leaf3之间的端到端流量进行检测分析,流量在Border1Border2之间走M-LAG通道。

图83 端到端检测场景

 

2. 逐点检测场景

如下图所示,在Spine-Leaf组网场景中,用户需要对网络流量经过的全部设备进行深入分析。此时,可以配置统一流量分析技术的随流检测(iFIT)功能对流量进行逐点检测分析,具体需求如下:

·     实现对Border1Leaf1之间的流量进行逐点检测分析。

·     实现对Border2Leaf2之间的流量进行逐点检测分析。

·     实现对Border1Leaf3之间的流量进行逐点检测分析,流量在Border1Border2之间走M-LAG通道。

图84 逐点检测场景

 

6.6  iFIT

6.6.1  技术介绍

1. 简介

iFITIn-situ Flow Information Telemetry,随流信息测量)是一种网络性能指标测量技术,应用于IPVXLAN网络。它可随流直接测量业务流的SLA(包括丢包、时延、抖动、实时流量等)参数,具有部署方便、测量精度高等优点。

2. 网络模型

iFIT使用多点(多个测量点)收集、集中(单个分析器)计算的网络模型。

图85 iFIT网络模型

 

该模型中包含以下元素:

·     目标流:iFIT测量的对象,是网络中符合特定匹配规则的业务流。网络管理员可以通过匹配规则(ACL)定义目标流的特征,例如某个网段。iFIT会根据报文的五元组自动将流量分成不同的目标流,并进行分别测量。

图86 iFIT目标流

 

·     入节点(Ingress):目标流进入测量网络的设备。主要负责:

¡     对业务流按五元组建立目标流和染色。

¡     收集目标流的统计数据并上报给分析器。

·     中间节点(Transmit):主要负责:

¡     自动识别iFIT目标流。

¡     收集目标流的统计数据并上报给分析器。

·     出节点(Egress):iFIT目标流离开测量网络的设备。主要负责:

¡     自动识别iFIT目标流。

¡     收集目标流的统计数据并上报给分析器。

¡     iFIT目标流去染色后,将目标流转发给下一跳。

·     分析器(Analyzer):负责收集入节点、中间节点、出节点上送的统计数据,并完成数据的汇总和计算。

·     MPMeasurement Point,测量点):MP和三层物理接口绑定,负责执行测量动作和产生统计数据。根据职责不同,MP分为入MP(流量入口测量点)、出MP(流量出口测量点)和中间MP三种类型。

3. 工作流程

iFIT工作流程分为三个阶段:设备时间同步、设备收集数据上报给分析器、分析器进行分析与计算数据。

图87 iFIT工作流程

 

4. 统计数据上报机制(Telemetry

iFIT采用基于gRPC协议的Telemetry技术向分析器上报统计数据。Telemetry是一项监控设备性能和故障的远程数据采集技术。

iFIT组网中,iFIT设备作为gRPC客户端,iFIT分析器作为gRPC采集器。设备采用gRPC Dial-out模式,主动与分析器建立gRPC连接,并将设备上订阅的iFIT统计数据推送给分析器。

6.6.2  技术价值

iFIT具有测量精度高、快速排障、精准定位、丢包原因上报、无需部署高精度PTP、带宽无额外损耗等技术价值。

图88 iFIT技术价值

 

6.6.3  应用场景

iFIT是一项面向新一代网络的智能化监测技术,可广泛应用于IP网络与VXLAN 网络场景,包括数据中心网络、AD-DC网络以及智算网络等多种复杂环境。

iFIT能够在不中断业务的前提下,实现持续性、细粒度的业务性能采集与分析。管理员可以实时掌握业务流在网络中的完整传输路径及其性能变化曲线,做到从端到端的全链路透明化监控,显著提升定位精度与响应速度,第一时间精确地定位故障。

图89 iFIT应用组网

 

6.7  MOD

6.7.1  技术简介

MODMirror On Drop,丢包镜像)是一种专门用来监控报文在设备内部转发过程中发生丢包的技术。一旦MOD监控到设备内部发生丢包,就会立即收集丢包发生的时间、丢包原因和丢弃报文特征,并上报给远端采集器,以便管理员及时了解设备内部发生的丢包情况。

图90 MOD技术简介

 

6.7.2  工作机制

MOD是一种基于Flow Group流表的丢包检测机制,核心流程包括:

(1)     流表生成:基于Flow Group定义的ACL规则对网络流量进行匹配,识别出需要重点监控的关键业务流。当报文首次命中ACL规则时,动态创建对应的流表项,记录其特征(如源/目的IP、端口、协议类型等五元组信息),实现对目标流量的精准捕获与跟踪。

(2)     流量匹配与分类:在流表建立后,持续对经过设备的报文进行匹配判断。若报文命中已生成的流表项,则将其归类为待监控对象,进入精细化丢包检测流程;未命中流表的普通流量则按常规转发处理,不参与后续丢包统计,从而降低系统开销。

(3)     丢包原因监控:针对已匹配流表的关键报文,实时监控预设的丢包场景(如ACL策略拒绝、队列溢出、缓冲区不足、策略限速丢包等)。仅对这些特定原因导致的丢包事件进行记录和分析,提升检测的针对性与准确性。

(4)     丢包信息上报:当关键报文因监控范围内的原因被丢弃时,设备自动生成丢包日志,包含丢包原因、时间戳以及对应流表中的特征信息(如五元组、入接口、服务类型等),并通过标准协议(如gRPCUDP等方式)上报至采集器或运维分析平台,支持故障快速定位与根因分析。

图91 MOD工作机制

 

6.7.3  技术价值

MOD技术的核心价值在于通过智能流表匹配与精细化监控,实现关键业务流的高效丢包检测与精准故障诊断,具体体现在以下四个方面:

·     精准流量捕获:基于Flow Group的动态流表生成技术,利用五元组等关键特征精准识别重点业务流,避免全流量监控带来的资源浪费,实现监控对象的颗粒化筛选与精准定位。

·     低开销高效检测:通过流表分类机制区分关键流与普通流,仅对目标流量进行深度丢包分析,显著降低系统计算与存储负担,确保检测效率与设备性能的最佳平衡。

·     场景化根因定位:聚焦ACL拒绝、队列溢出等典型丢包场景,结合接口、QoS等级等多维流特征精准记录丢包事件,直接关联具体网络策略或资源瓶颈,快速锁定故障根因。

·     标准化运维协同:采用结构化日志与开放协议(gRPC/UDP)进行数据上报,兼容主流分析平台,构建检测、记录、上报闭环,提升网络可观测性与运维自动化水平。

图92 MOD技术价值

 

6.8  Telemetry Stream

6.8.1  技术简介

Telemetry Stream是一种高性能网络监控技术,利用设备芯片级的数据采集能力,实时捕获关键转发信息(如入/出端口、时间戳等),并主动推送至采集器,实现对网络路径和时延的精准监测与分析。

图93 Telemetry Stream技术简介

 

6.8.2  工作机制

Telemetry Stream支持基于真实业务流量的逐跳时延测量,其工作流程如下:

(1)     时间同步:所有参与测量的网络设备通过PTPPrecision Time Protocol)实现纳秒级时间同步,确保各节点时间基准高度一致,为精准时延计算提供坚实基础。

(2)     报文识别与采样:设备在入接口侧通过预配置的ACL规则对业务流量进行筛选,匹配符合条件的报文。随后,依据预设采样率(如1:100)采用随机或确定性方式进行抽样,有效避免对高负载链路造成性能影响。

(3)     报文复制与封装:选中的采样报文在转发路径之外无感复制,避免业务流量干扰。复制报文被添加专用Telemetry Stream封装头,形成独立的测量数据包。

(4)     数据传输与上报:封装后的采样数据包通过带外或带内通道发送至集中式Telemetry采集器(Collector),独立于原始业务路径,确保测量过程对业务转发无任何影响。

(5)     时延计算与结果共享:采集器接收来自各节点的封装报文,结合各节点时间戳信息,精确计算逐跳转发时延,并将结果进行分析与共享,支持网络性能优化和故障定位。

图94 Telemetry Stream工作机制

 

6.8.3  技术价值

通过将高精度时间同步与灵活采样相结合,Telemetry Stream不仅能够抓取原始报文,更能为每个报文打上精准的时间戳,并将报文上报给采集器,为网络性能优化与故障定位提供真实、精细的数据基础。

图95 Telemetry Stream技术价值

 

6.9  RDMA Telemetry

6.9.1  产生背景

随着RoCEv2在智算中心关键业务中的普及,其网络性能的稳定性已成为业务连续性的基石。然而,传统网络监控技术(如SNMPNetAnalysis等)无法满足RoCEv2网络的极端性能监测需求,主要体现在:

·     精度不足:传统工具采样间隔通常在数百毫秒级,无法捕捉微秒级的延迟突增(延迟尖刺)。

·     检测粗糙:丢包检测多基于软件计数器估算,无法精确定位万分之一的微量丢包,而此类丢包在RoCEv2网络中会触发重传,导致延迟急剧上升。

·     实时性差:被动轮询模式存在监控盲区,难以实时感知瞬时拥塞,往往在业务已受影响后才能发现异常。

为解决传统监控手段的固有缺陷,RDMA Telemetry技术应运而生。该技术专为RoCEv2网络设计,提供两大核心功能:

·     I/O质量可视:测量GPU服务器与存储服务器之间(基于NVMe over Fabrics over RoCEv2)的I/O读写操作时延。

·     吞吐量可视:测量GPU服务器之间(基于纯RoCEv2)的写操作吞吐量与丢包情况。

通过端到端、分段式的实时性能监测,RDMA Telemetry为高性能数据中心网络提供了全面的可视化解决方案。

6.9.2  技术优点

与传统网络监控技术相比,RDMA Telemetry具有以下显著优势:

·     精准的故障定位能力

¡     通过I/O质量可视功能的三段式测量,它将整个存储网络划分为三个独立的区段进行监控:计算节点到网络设备之间的连接、网络设备之间的传输路径、以及网络设备到存储设备之间的连接。每个区段都根据专门的性能指标进行监控,可以将网络问题精确定位到具体区段。

¡     结合吞吐量可视功能的多维度指标分析,能准确判断问题根源是硬件故障、配置错误还是流量拥塞。

·     实时的性能监控

¡     采用硬件级计数器数据采集,监控精度达到微秒级。

¡     带内遥测技术确保监控数据与业务流量同步更新,无采样延迟。

·     智能化的运维支持

¡     可视报告自动标注异常事件和性能瓶颈。

¡     支持设置自定义告警阈值,及时发现潜在问题。

¡     历史数据分析功能帮助预测网络性能趋势。

·     广泛的场景适应性

¡     完美适配RoCEv2网络的各种应用场景。

¡     无论是分布式存储、AI训练还是金融交易系统,都能提供针对性的监控方案。

6.9.3  I/O质量可视功能技术实现

1. 功能简介

I/O质量可视功能的核心是对存储网络(GPU服务器访问存储服务器)的端到端传输时延进行分段测量。作为RDMA Telemetry技术的重要创新,该功能将复杂的存储路径划分为三个逻辑区段(GPU服务器到交换机、交换机之间、交换机到存储服务器),并分别对每个区段的读写操作时延进行实时毫秒/微秒级监测。

这种精细化的分段测量机制,使运维人员能够直观识别性能瓶颈的具体位置。例如,当应用响应延迟上升时,通过该功能提供的信息,可立即定位问题是源自GPU服务器侧连接异常、核心网络拥塞,还是存储服务器处理缓慢,从而大大缩短了故障定位时间。

2. 系统架构

RDMA Telemetry采用分布式监控架构,由以下两部分组成:

·     控制器+分析器

¡     控制器通过NETCONF接口向设备下发测量配置。

¡     设备通过gRPC功能将测量数据上报给分析器,从而在分析器上可视化展示I/O性能指标——时延。

·     测量设备(Device

支持RDMA Telemetry功能的网络设备。

¡     计算侧端口:设备上连接GPU服务器的端口。它识别NVMe/RDMA特征报文,测量计算侧时延,并将测量数据上报至分析器。

¡     存储侧端口:设备上连接存储服务器的端口。它识别NVMe/RDMA特征报文,测量存储侧时延,并将测量数据上报至分析器。

3. 网络分段测量

RDMA Telemetry将数据中心存储网络分为三段:

·     计算侧:网络设备与GPU服务器之间的部分。

·     存储侧:网络设备与存储服务器之间的部分。

·     网络路径:网络设备之间的部分。

图96 RDMA Telemetry测量模型

 

4. 测量策略

当设备在全局和接口层面同时启用I/O质量可视功能后,RDMA Telemetry将对接口接收的所有RoCEv2流量进行监控测量。为适应不同用户的组网需求并降低网络负载,该技术支持根据用户配置将RoCEv2流量划分为重点保障流量(重保流量)和非重点保障流量(非重保流量),并实施差异化的测量策略。

(1)     重点保障流量:持续监控

重点保障流量是指需要优先监控的关键业务流量。用户可通过源IP地址、目的IP地址或其组合来定义一条或多条重点保障流量规则。当接口检测到匹配重点保障流量规则的流量时,RDMA Telemetry将按照预设周期持续进行测量,并上报测量数据。

(2)     非重点保障流量:轮询监控

非重点保障流量则指除重点保障流量之外的其他RoCEv2流量。对于此类流量:

¡     若设备未启用轮询功能,则不会对其进行测量和上报。缺省情况下,未启用轮询功能。

¡     若设备启用了轮询功能,系统将采用轮询机制选择性地测量和上报非重点保障流量。具体而言,设备会根据设定的轮询端口数,按周期轮流对不同接口的非重点保障流量进行测量和上报。

例如,假设在接口110上启用了I/O质量可视功能,开启轮询功能并设置轮询端口数为4时:

¡     第一周期:测量并上报接口14的非重点保障流量数据。

¡     第二周期:测量并上报接口58的非重点保障流量数据。

¡     第三周期:测量并上报接口91012的非重点保障流量数据。

后续周期将依此规则循环执行。这种设计既确保了关键流量的实时监控,又有效降低了非关键流量的测量开销。

5. 测量指标

基于I/O交互流程,RDMA Telemetry按周期测量并计算以下三类对象的平均值:

·     DPLData Preparation Latency,数据准备时延):仅存在于写操作,用于评估计算侧准备数据的效率。

DPL升高可能指示存在计算侧CPU/内存瓶颈或线程阻塞等情况。

·     RTTRound-Trip Time,双向时延):报文在交换机中传输的往返时延,用于衡量网络性能,通过分解计算侧总时延IOL1Input/Output Latency,输入/输出延迟)和存储侧总时延IOL2计算得出。

如果RTT突增,则表示存在网络拥塞、BGP路由震荡或NIC队列积压等情况。

·     DALData Access Latency,数据访问时延):衡量存储设备处理I/O请求的耗时,分为读操作DAL和写操作DAL,读操作DAL和写操作DAL独立测量,分别反映存储侧的不同处理阶段。

DAL升高,则可能存在SSD延迟高、RAID卡瓶颈或存储软件栈过载等情况。

图97 RDMA Telemetry测量指标

 

6. 读操作交互流程

关键报文以及测量指标

在智算中心场景中,当GPU服务器从存储服务器读取数据时,NVMe-oF over RoCEv2协议规定由存储服务器采用RDMA Write语义,直接将数据写入GPU服务器的内存。此设计的核心优势在于:将需要CPU参与发起和管理的RDMA操作置于存储侧,从而确保GPU服务器CPU在数据传输全程无干预。这不仅实现了仅1次网络往返的理论最低时延,更彻底解放了主机算力,完美契合“算力全用于计算”的核心诉求。

读操作报文交互核心步骤如下:

(1)     发起请求:GPU应用发出读指令,GPU服务器驱动构建NVMe读命令,其中包含GPU服务器内存的目标地址与访问密钥,并通过一次RDMA Send发送至存储服务器。

(2)     执行与回传:存储服务器解析命令,从NVMe SSD读取数据后,由存储服务器CPU发起一次RDMA Write,利用获取的地址与密钥,将数据直接写入GPU服务器的指定内存缓冲区。此过程GPU服务器CPU全程无干预。

(3)     完成确认:存储服务器通过另一条RDMA Send消息发送完成通知,结束本次I/O

读操作交互流程中,流经设备上计算侧端口、存储侧端口的关键报文以及设备记录的测量指标如98所示。

图98 读操作交互流程关键报文及测量指标

 

计算侧从存储侧读取数据过程中涉及的关键报文以及设备记录的测量指标如3所示。

表3 读操作交互流程关键报文与测量指标

步骤

方向

报文类型

RDMA操作

交换机记录的数据

1

计算侧→存储侧

NVMe CMND(读请求)

RDMA Send Only

·     时间戳T1:计算侧端口从GPU服务器收到报文①的时间戳

·     时间戳T2:存储侧端口向存储服务器发送报文①的时间戳

2

存储侧→计算侧

NVMe_DATA(首数据包)

RDMA Write First

时间戳T3:存储侧端口收到来自存储服务器的报文②的时间戳

3

存储侧→计算侧

NVMe_DATA(末数据包)

RDMA Write Last

不记录数据

4

存储侧→计算侧

NVMe RSP(完成响应)

RDMA Send Only Invalidate

·     时间戳T4:存储侧端口收到来自存储服务器的报文④的时间戳

·     时间戳T5:计算侧端口向GPU服务器发送报文④的时间戳

 

读操作中测量指标的计算

·     DALread=T3−T2

·     IOL1(计算侧总时延)=T5−T1

·     IOL2(存储侧总时延)=T4−T2

·     RTT=IOL1−IOL2=(T5−T1) − (T4−T2)

数据读取全流程

下面以训练数据集的存储与读取这一典型场景为例,讲解读操作中RDMA Telemetry测量的全流程。在该场景中,海量的训练数据(如图片、文本)存储在基于NVMe SSD的分布式存储池中。训练集群通过NVMe over Fabrics over RoCEv2协议,以RDMA方式高速读取数据,并直接输送至GPU进行计算。

(4)     训练任务发起请求,计算侧处理

训练任务需要读取下一批训练数据,向存储系统发起读请求。计算侧GPU服务器将请求封装为NVMe-oF命令,并最终由RDMA网卡转换为一个或多个RDMA Send报文,提交给接入交换机。

(5)     请求穿越网络设备(RTT测量点)

RDMA Send报文经过接入交换机和核心交换机转发至存储侧。网络设备(如接入交换机)在入端口记录请求报文的时间戳(T1),并生成流标识,用于关联后续的响应报文(如报文④),从而计算网络往返时延(RTT)。

(6)     存储侧处理与数据返回(DAL测量点)

存储服务器收到请求报文(如报文①)后,解析命令并从本地NVMe SSD读取数据,随后指示网卡将数据封装为一个或多个RDMA Write报文(如报文②,含数据载荷)发送回计算侧。

DAL即为存储侧从接收请求(报文①)到发出第一个数据报文(报文②)的总处理耗时。

(7)     数据交付训练任务(端到端闭环)

计算侧RDMA网卡收到RDMA Write数据报文后,利用RDMA操作将数据直接写入GPU显存或主机内存的预定缓冲区,并通知训练任务数据就绪。

测量价值

当训练任务出现数据供给延迟时,运维人员可通过RDMA Telemetry提供的测试数据快速定位瓶颈:

·     DAL(存储处理段)显著升高,可推断瓶颈在存储侧,原因可能为磁盘性能降低、存储服务过载等。

·     RTT(网络传输延迟)突增,可推断瓶颈在网络,原因可能为网络拥塞、丢包导致重传、链路故障等。在网络设备上部署iFITIn-situ Flow Information Telemetry,带内流信息测量)功能,可以定位出具体的故障链路和故障设备。

·     若端到端延迟均匀增加,需综合排查计算侧、网络、存储负载。

该精细化测量使得智算中心能够保障数据供给流水线的稳定,确保高价GPU算力持续饱和工作。

7. 写操作交互流程

关键报文以及测量指标

在智算中心场景中,当GPU服务器向存储服务器写入数据时,NVMe-oF over RoCEv2协议规定由存储服务器采用RDMA Read语义,主动从GPU服务器内存拉取数据。发起和管理RDMA Read的开销同样由存储服务器CPU承担,确保了GPU服务器CPU的“零打扰”。

写操作报文交互核心步骤如下:

(1)     发起请求:GPU应用发出写指令,GPU服务器驱动构建NVMe写命令,其中包含主机内存源地址、访问密钥,并通过一次RDMA Send发送至存储服务器。

(2)     执行与获取:存储服务器解析命令后,由存储服务器CPU发起一次RDMA Read,利用获取的源地址与密钥,直接从GPU服务器的内存缓冲区中读取数据。此过程GPU服务器CPU全程无干预。

(3)     完成确认:存储服务器将数据持久化至NVMe SSD后,通过另一条RDMA Send消息发送完成通知,结束本次I/O

写操作交互流程中,流经设备上计算侧端口、存储侧端口的关键报文以及设备记录的测量指标如99所示。

图99 写操作交互流程关键报文及测量指标

 

计算侧向存储侧写数据过程中涉及的关键报文以及设备记录的测量指标如4所示。

表4 写操作交互流程中关键报文与测量指标

步骤

方向

报文类型

RDMA操作

Telemetry测量数据

1

计算侧→存储侧

NVMe CMND(写请求)

RDMA Send Only

·     时间戳T1:计算侧端口从GPU服务器收到报文①的时间戳

·     时间戳T2:存储侧端口向存储服务器发送报文①的时间戳

2

存储侧→计算侧

NVMe Read Request(数据拉取请求)

RDMA Read Request

·     时间戳T3:存储侧端口收到来自存储服务器的报文②的时间戳

·     时间戳T4:计算侧端口向GPU服务器发送报文②的时间戳

3

计算侧→存储侧

NVMe_DATA(第1个数据包)

RDMA Read Resp First

时间戳T5:计算侧端口从GPU服务器收到报文③的时间戳

4

计算侧→存储侧

NVMe_DATA(最后数据包)

RDMA Read Resp Last

不记录数据

5

存储侧→计算侧

NVMe RS(写入确认)

RDMA Send Only Invalidate

·     时间戳T6:存储侧端口从存储服务器收到报文的时间戳

·     时间戳T7:计算侧端口向GPU服务器发送报文的时间戳

 

写操作测量指标的计算

·     DALwrite=T3−T2

·     DPL=T5−T4

·     IOL1(计算侧总时延)=T7−T1

·     IOL2(存储侧总时延)=T6−T2

·     RTT=IOL1−IOL2=(T7−T1) (T6−T2)

数据写入全流程

下面以检查点存储这一典型场景为例,讲解写操作的RDMA Telemetry测量全流程。在该场景中,训练任务产生的模型检查点(规模常达数百GB)需被快速保存,其实现方式是:GPU服务器通过拉取式写操作,将数据高速推送至远端的NVMe存储目标。

(4)     训练任务发起写入,计算侧处理

训练任务(如完成一个迭代后)需要写入梯度或检查点,向存储系统发起写请求。计算侧GPU服务器将请求封装为RDMA Send Only报文,提交给接入交换机。

(5)     请求报文穿越网络(数据传输测量点)

RDMA Send Only报文从计算侧网卡发出,经过网络设备转发至存储侧。网络设备在入端口记录RDMA Send Only报文的到达时间戳(T1),并生成流标识,用于关联此次传输事务(如报文①和报文⑤)。

(6)     存储侧接收处理(DAL测量点)

存储侧RDMA网卡收到请求报文(如报文①)后,准备本地存储资源,并返回RDMA Read Request报文(如报文②),请求计算侧发送数据。

DAL即为存储侧从收到请求(报文①)到发出读请求(报文②)的耗时。

(7)     数据传输

计算侧GPU服务器收到RDMA Read Request报文后,向存储侧服务器发送需要写入的数据。

DPL即为计算侧从收到读请求(报文②)到发出第一个数据报文(报文③)的耗时。

(8)     写入完成确认(端到端闭环)

存储侧服务器收到RDMA Read Resp Last报文后,知道数据写入完毕,返回RDMA Send Only Invalidate报文。

计算侧RDMA网卡收到RDMA Send Only Invalidate报文后,确认写入操作完成,并通知训练任务写操作成功。

测量价值

当训练任务出现检查点写入缓慢或梯度同步延迟时,运维人员可通过RDMA Telemetry提供的测试数据快速定位瓶颈:

·     DAL(存储处理段)显著升高,可推断瓶颈在存储侧,原因可能为写入带宽饱和、持久化慢等。

·     DPL(计算处理段)显著升高,可推断瓶颈在计算侧,原因可能为GPU繁忙等。

·     RTT(网络传输延迟)突增,可推断瓶颈在网络,原因可能为网络拥塞、丢包导致重传、链路故障等。在网络设备上部署iFITIn-situ Flow Information Telemetry,带内流信息测量)功能,可以定位出具体的故障链路和故障设备。

·     若端到端延迟均匀增加,需综合排查计算侧、网络、存储负载。

该精细化测量使得智算中心能够保障参数同步与数据持久化流水线的稳定,确保分布式训练的一致性和容灾能力。

6.9.4  吞吐量可视功能技术实现

1. 功能简介

在智算中心的计算平面中,GPU集群间的通信效率直接决定了AI大模型训练的成败。以典型的分布式训练场景为例:当一次反向传播计算完成后,数千张GPU需要通过高效的RDMA Write操作完成梯度同步(如Ring All-Reduce算法)。在这个过程中,任何微秒级的网络波动都会导致GPU等待,形成“通信墙”瓶颈——据测算,万卡集群中每节省1%的训练时间,即可节约数百万美元的计算成本。

然而,传统的网络监控手段如同“盲人摸象”:运维团队能看到端口流量,却看不到业务层的有效吞吐;能发现链路中断,却捕捉不到瞬时的微突发丢包。这导致了一个普遍困境:同一算法两次实验性能差异高达30%,却无法定位是算法问题还是网络问题,研发效率严重受损。

吞吐量可视功能正是为此而生。吞吐量可视功能是针对智算中心计算平面通信性能瓶颈而设计的核心监控能力。它专门监控GPU服务器间基于纯RoCEv2协议的RDMA Write操作流——这正是梯度同步、参数交换等关键训练通信的承载形式。与传统的网络监控不同,我们不仅关注链路层的带宽利用率,更关注应用层的有效数据传输效率。

2. 测量策略

当设备在全局和接口层面同时启用吞吐量可视功能后,RDMA Telemetry将对接口接收的RoCEv2流量进行监控测量。与I/O质量可视功能不同,吞吐量可视功能不会区分重点保障流量(重保流量)和非重点保障流量(非重保流量),而是采用统一的处理策略。

为了平衡监控精度和系统资源消耗,该功能提供了两种工作模式:全量监控模式和轮询监控模式。通过这两种模式的灵活配置,用户可以根据实际网络规模和资源情况,选择最适合的监控策略,既保证关键数据的采集,又避免对系统性能造成过大影响。

·     全量监控模式

当设备未启用轮询功能时,系统会采用全量监控模式(缺省情况下,设备未启用轮询功能):

¡     设备会对所有接口接收的RoCEv2流量进行持续地全量监控,实时测量并上报数据。

¡     这种模式适用于需要全面掌握网络性能的场景,能够提供最完整的监控数据。

¡     由于需要对所有流量进行处理,可能会增加设备的系统负载,建议在资源充足的环境中使用。

·     轮询监控模式

当设备启用轮询功能时,系统会采用轮询监控模式:

¡     设备会根据用户配置的轮询端口数,按周期轮流对不同接口的RoCEv2流量进行采样监控。

¡     每个监控周期内,系统仅对当前轮询到的接口进行测量和上报,其他接口的数据暂不处理。

¡     轮询采用循环机制,确保所有接口都能被均匀覆盖,避免长期遗漏某些接口的监控数据。

这种模式通过减少同时监控的接口数量,有效降低了系统资源消耗,适合大规模部署环境。

轮询机制示例如下,假设在接口110上启用了吞吐量可视功能,开启轮询功能并设置轮询端口数为4

¡     第一周期:测量并上报接口14的所有RoCEv2流量数据。

¡     第二周期:测量并上报接口58的所有RoCEv2流量数据。

¡     第三周期:测量并上报接口91012的所有RoCEv2流量数据。

¡     后续周期继续按此规则循环执行,确保所有接口的流量都能被定期监控。

3. 测量指标

图100 吞吐量可视功能测量指标示意图

 

100所示,以GPU服务器1将数据推送给GPU服务器2为例。吞吐量可视功能定义了三个核心指标来全面评估通信健康度,如5所示。

·     FCTFlow Completion Time,流完成时间)指的是接入交换机Device A收到首个数据报文与收到最后一个数据报文的时间差。

·     FETFlow Effective Throughput,流有效吞吐率)指的是数据入接口的实际有效数据传输速率。

·     FNRFlow NAK Rate,流重传率)用于衡量GPU服务器1侧接入交换机到GPU服务器2之间这段网络的丢包情况。

表5 吞吐量可视功能测量指标描述表

指标

定义

计算公式

意义

FCT

完成单次RDMA写操作的总耗时

FCT = 末包到达时间 - 首包到达时间

直接反映训练迭代中的通信延迟。值越高,GPU等待时间越长,训练速度越慢

FET

RDMA流的实际有效数据传输速率(单位为bps

FET = (总数据量 - 重传数据量)(bit) / FCT(μs) ×10⁶

衡量网络的实际可用带宽。低FET表明带宽未被充分利用,存在隐性瓶颈

FNR

因丢包导致的重传报文占比

FNR = NAK报文数 / 原始报文数(不含重传)

评估网络可靠性。高FNR直接导致有效吞吐下降,并可能引发PFC反压,影响全局

 

4. 运行机制

RoCEv2网络场景,一次RDMA可靠性传输读操作报文交互过程如101所示。吞吐量可视功能基于以下核心机制实现:

(1)     流量识别与采样

发送端(Sender)通过设备(Device)向接收端(Receiver)发送RoCEv2报文,设备上的接口识别RoCEv2报文,将所有RoCEv2报文作为监控对象。

(2)     关键指标测量

设备对每条RDMA流(以PSN序列号标识)进行全生命周期跟踪,主要记录以下数据:

¡     首包到达时间戳(Write First报文)

¡     末包到达时间戳(Write Last报文)

¡     所有NAK重传报文的计数

¡     有效数据量统计(Device收到的总字节数 - 重传字节数)

¡     无效数据量统计(Device收到的重传字节数)

当接收端检测到PSN不连续(如PSN=2丢失)时,会发送NAK请求重传。设备通过识别这些NAK报文,精确统计重传情况,区分有效与无效吞吐。

(3)     数据分析与上报

设备按配置周期(如1秒)计算FCTFETFNR等指标。对于这些测量指标,用户可进行以下操作:

¡     在设备上查看这些指标。

¡     通过gRPC协议将这些指标上报至分析器,分析器可对数据进行分析、加工,生成可视化报表。

图101 RDMA可靠性传输写操作报文交互过程

 

6.9.5  RDMA Telemetry可视化

RDMA TelemetrygRPC功能配合,可以将测量数据通过gRPC协议上送给AD-DC分析器(SeerAnalyzer-DC)。在分析器上图形化展示RDMA Telemetry测量结果。

102所示,SeerAnalyzer-DC支持按照主机IP维度或存储IP维度可视化呈现I/O时延、数据准备时延、数据访问时延、网络RTT等指标。支持查看选中的I/O详情,拓扑图形式呈现主机和存储的交互关系。点击查看详情按钮可查看该主机及存储下I/O时延趋势(如103所示)。

图102 RDMA Telemetry可视化数据

 

图103 RDMA Telemetry可视化趋势图

 

6.9.6  典型组网应用

1. AI训练存储网络I/O质量监测

随着AI训练规模的指数级增长,训练数据的访问性能已成为制约模型训练效率的关键瓶颈。据统计,在千卡级GPU集群训练万亿参数模型时,数据加载阶段的I/O延迟波动会直接导致GPU利用率下降40%以上。传统存储网络监控仅能提供聚合带宽和端口级统计,无法对I/O操作的全链路时延进行分解分析,当出现I/O性能抖动时,运维团队难以快速区分是计算侧数据准备问题、网络传输问题还是存储侧处理瓶颈。

104所示,通过在连接GPU计算节点与全闪存存储阵列的AI训练存储网络中,在关键路径的交换设备上启用I/O质量可视功能,可以实现对每个训练作业I/O操作的全链路时延分解。该方案基于NVMe-oF over RoCEv2读写操作的完整事务周期进行测量,并可视化呈现“计算侧处理时延”、“网络传输时延”、“存储侧时延”三层指标。

AI训练存储网络中应用I/O质量可视功能可以带来如下价值:

·     对于训练作业性能诊断:实现I/O性能问题的精准定界,快速区分计算、网络、存储各环节的责任归属。

·     对于跨团队协作效率:为计算团队、网络团队、存储团队提供统一的性能视图和量化数据,缩短跨域故障协同定位时间。

·     对于基础设施优化:基于长期的时延分量趋势分析,科学指导硬件升级(如CPU/内存扩容)、网络优化(如QoS策略调整)和存储调优(如缓存策略改进)。

图104 AI训练存储网络I/O质量监测示意图

 

2. AI训练计算平面梯度同步性能优化

据研究,在万卡级GPU集群中进行大语言模型训练时,梯度同步通信开销占训练总时间的比例可达40%-60%。基于RoCEv2RDMA写操作承载了All-Reduce等关键集合通信操作,其有效吞吐率和丢包重传情况直接决定了每次训练迭代的速度。传统网络监控工具(如SNMP)无法捕捉微秒级的时延变化,难以为AI训练提供有效的网络质量保障。

105所示,通过在AI训练计算平面中部署RDMA Telemetry吞吐量可视功能,可以实现:

·     精准时延监控:实时测量GPU服务器间RDMA流量的端到端时延(FCT),精度达微秒级。

·     拥塞快速定位:通过NAK报文统计和路径时延分析,快速区分是网络拥塞还是GPU计算瓶颈。

图105 AI训练计算平面梯度同步性能优化示意图

 

6.10  光模块诊断可视化

6.10.1  技术简介

光模块诊断可视化功能是一套针对高速光通信系统的实时监测与分析工具。该功能通过动态采集光模块核心性能参数(误码率、信噪比等),结合多维度数据分析与可视化呈现,为运维人员提供精准的链路质量评估与异常定位能力。

6.10.2  工作机制

光模块诊断可视化功能的工作机制为:

(1)     数据采集:

设备从光模块中获取光转电后的信号、信噪比等数据。

(2)     多维度性能分析和上报:

根据获取到的数据,设备计算如下性能指标,并通过gRPC等方式将计算出的光模块性能指标上报给控制器。

¡     接口级BERBit Error Rate,误码率):每个传输比特(Bit)发生错误的概率,是通信系统最基础的可靠性指标,用来识别接口信号完整性劣化问题。

¡     通道级SERSymbol Error Rate,符号错误率):每个传输符号(Symbol)发生错误的概率。

¡     FECForward Error Correction,前向纠错)纠错能力:FEC是一种通过添加冗余数据在接收端自动纠正传输错误的信道编码技术。光模块诊断可视化功能可以计算纠错前BER和纠错后BER,以衡量纠错能力。

¡     SNRSignal-to-Noise Ratio,信噪比):通过SNR数值评估信号质量,预判因噪声累积导致的潜在故障。

¡     FDRFrequency Domain Reflectometry,频域反射测量)直方图:FDR直方图是一种光纤链路诊断工具,用于可视化分析光纤中的反射事件(如断裂、弯曲、连接器污染等)。它通过测量反射信号的频率响应,生成距离-反射强度的分布图,帮助运维人员快速定位故障点。

(3)     性能指标可视化展示

控制器以可视化方式展示光模块的性能指标,以便运维人员快速识别异常情况并定位故障。

图106 光模块诊断可视化工作机制

 

6.10.3  技术价值

·     精准诊断:通过多维度参数(BERSERFEC)交叉验证,快速区分硬件损伤(如光模块老化)与传输干扰(如EMI噪声)。

·     前瞻性维护:基于SNR趋势和FEC纠错峰值预测寿命衰减,降低突发性中断风险。

·     降本增效:替代传统人工测试,缩短故障定位时间,提升网络可用性。

图107 技术价值

 

7 智算网络部署方案

7.1  云上场景部署方案

7.1.1  部署场景推荐

如下几种情况,建议选择云上场景,基于云的资源管理能力,可提供基础算力资源和算力平台:

·     政府、运营商建设的对外运营公共算力中心。

·     大企业自建,对内运营,服务于不同业务部门的智算中心。

·     GPU服务器数量在32台以上。

7.1.2  典型组网

智算解决方案云上场景典型组网如图108所示。

图108 智算方案云上场景典型组网

 

7.1.3  资源分区说明

按资源分区,各部署区域及说明如下:

·     数据中心出口区:数据中心网络接入互联网,可旁挂出口防火墙等安全设备,提供平台级别的安全防护能力。是智算中心与外部网络之间的连接点,部署两台互联网接口交换机支持和运营商对接,同时配备抗D设备做安全防护;配备一对物理出口防火墙实现内外网络隔离、控制流量和访问策略等基础的安全防护;最后通过出口交换机,提供数据中心内部和其他网络平面的互联能力

·     云外业务区:又称公服区,主要用于部署服务于所有用户的公共业务系统。本方案中主要涵盖两类核心业务:一是AI开发平台,为用户提供全流程的人工智能开发与训练服务;二是监控分析系统,负责采集并分析GPU集群的运行数据与网络流量,以优化整体AI业务的性能与效率。

·     管理区:部署云管理平台、平台级安全系统、统一运维平台,为用户提供统一的系统管理、安全防护和运维运营。

·     带外管理运维区:主要用于运维和管理接入。

·     通用存储区:主要为业务区的通用计算、网络安全和云平台提供块存储,一般采用三副本设计。

·     业务区:部署面向最终用户的各类业务资源。主要包括四类业务资源。

¡     GPU训练计算资源:为AI模型开发与训练提供算力,并接入高性能网络。

¡     GPU推理计算资源:主要为人工智能推理提供GPU能力,如用于模型的评估、测试与线上服务,以验证真实场景性能。

¡     网络安全资源:为业务集群提供负载均衡等外部访问与安全能力。

¡     通用资源:当用户申请了裸金属GPU服务器时,可以配套申请通用资源中的虚拟机,用户通过虚拟机做跳板,可以对所有裸金属服务器进行环境搭建和基础运维。

·     高性能存储区:部署用于人工智能训练的高性能分布式文件存储。其核心功能包括:为训练任务提供数据读写支持,如数据集读取和模型检查点保存;提供管理接口以实现与云平台的交互;并设立专门的网络节点,负责通过外部以太网进行数据的导入与导出。

7.1.4  网络平面规划

按网络平面,智算解决方案云下场景可划分为如下平面:

·     数据中心接入平面:是智算中心与外部网络之间的连接点,部署两台互联网接口交换机以支持和运营商对接,同时配备抗D设备做安全防护;配备一对物理出口防火墙实现内外网络隔离、控制流量和访问策略等基础的安全防护;最后通过出口交换机,提供数据中心内部和其他网络平面的互联能力

·     云外业务平面:一般部署不区分租户的业务,此次部署一组公服TOR交换机,提供公共服务的连接能力

·     云内业务平面:被云控制器管理,通过VXLAN技术形成OverLay的大二层隔离网络,实现各租户的隔离功能,云内业务平面通过spine-leaf架构连接业务区的各资源

·     RoCE网络平面:高速互联网络,提供高带宽无丢包的网络平面。为GPU服务器之间以及GPU服务器和高性能存储之间提供互联的能力

·     通用存储平面:网络安全、云平台一般基于虚拟化进行部署,所依赖的块资源,通用网络平面连通网络安全池和云平台集群,为其提供公共的块存储资源

·     带内管理平面:为云平台管理其他的服务器、存储提供独立的互联网络,网络为独立的Underlay网络,为spine-leaf架构

·     带外管理平面:统一运维平台通过独立的带外网管理各ICT基础设施,一般也是spine-leaf架构,提供独立的underlay网络。同时提供VPN接入能力,方便运维人员安全的接入此网络进行基础的运维。

7.2  云下场景部署方案

7.2.1  部署场景推荐

如下几种情况,建议选择云下场景,基于算力平台调度算力,快速开发AI算法和训练模型:

·     中小企业自建自用、AI开发业务相对单一的智算中心。

·     32台以下GPU服务器。

7.2.2  典型组网

智算解决方案云下场景典型组网如图109所示。

图109 智算方案云下场景典型组网

 

7.2.3  资源分区说明

按资源分区,各部署区域及说明如下:

·     AI平台区:部署AI开发平台,对外为用户提供AI开发的全流程服务,对内通过调用云基础设施的标准化接口,自动化地创建和管理用于AI训练的容器集群,并调度下发计算任务。

·     无损控制区:部署SA/SE,收集GPU服务器的网卡等运行信息,分析整体AI训练流量,用于AI业务调优。

·     业务区:主要部署与最终用户相关的业务。在智算场景下主要包括GPU训练计算资源和GPU推理计算资源。

¡     GPU训练计算资源:为人工智能的算法开发和模型训练提供GPU能力,该资源采用高速互联的GPU集群架构,并接入高性能的RoCE网络以保证通信效率。

¡     GPU推理计算资源:为人工智能推理提供GPU能力,如用于模型的评估、测试与线上服务,以验证真实场景性能。

·     高性能存储区:部署用于人工智能训练的高性能分布式文件存储。其核心功能包括:为训练任务提供数据读写支持,如数据集读取和模型检查点保存;提供管理接口以实现与云平台的交互;并设立专门的网络节点,负责通过外部以太网进行数据的导入与导出。

·     管理区:部署云管理平台、平台级安全系统、统一运维平台,为用户提供统一的系统管理、安全防护和运维运营。

7.2.4  网络平面规划

按网络平面,智算解决方案云下场景可划分为如下平面:

·     数据中心接入平面:是智算中心与外部网络之间的连接点,部署两台互联网接口交换机支持和运营商对接,同时配备抗D设备做安全防护;配备一对物理出口防火墙实现内外网络隔离、控制流量和访问策略等基础的安全防护;最后通过出口交换机,提供数据中心内部和其他网络平面的互联能力。

·     业务平面:承载核心AI平台与各个业务节点间Kubernetes集群通信的网络骨干。该平面采用Spine-Leaf网络架构,负责高速、可靠地连接业务区内的所有计算与服务资源。

·     RoCE网络平面:高速互联网络,提供高带宽无丢包的网络平面。为GPU服务器之间以及GPU服务器和高性能存储之间提供互联的能力。

·     带内管理平面:为云平台管理其他的服务器、存储提供独立的互联网络,网络为独立的Underlay网络,为spine-leaf架构。

·     带外管理平面:统一运维平台通过独立的带外网管理各ICT基础设施,一般也是spine-leaf架构,提供独立的underlay网络。同时提供VPN接入能力,方便运维人员安全的接入此网络进行基础的运维。

8 智算网络典型应用场景

8.1  AI大模型训练与移动端部署中的一体化应用

8.1.1  客户痛点

当前AI大模型在训练和移动端部署过程中面临多重网络挑战:

·     算力与网络瓶颈:传统网络架构既无法满足大规模GPU集群训练的低延迟通信需求,又难以支撑移动端AI应用的高并发实时推理。

·     端云协同困境:移动端设备算力有限,大模型直接部署性能不足;云端推理又面临网络延迟高、带宽受限等问题。

·     部署运维复杂:从训练集群到移动端的全链路网络配置繁琐,传统人工方式效率低下且易出错。

·     扩展适配困难:现有网络缺乏弹性,难以同时应对训练集群扩展和多样化移动终端的接入需求。

8.1.2  解决方案

针对上述痛点,智算网络提供全方位的技术解决方案:

·     高性能异构网络架构:采用RoCE技术构建训练集群无损网络,实现盒式多集群部署,每个集群可支持64台搭载8200G GPU的高性能服务器。组网规模大幅提升,能够有效支撑千卡级GPU集群间的高带宽通信,显著降低通信时延,保障大规模训练任务的高效运行。

·     多层级负载均衡体系:通过LBNDLBSprayLinkFGLB等负载均衡技术,优化流量调度,显著降低远端链路拥塞时的流量转发拥塞风险。

·     端、网、边深度协同:将云端智能、边缘算力与终端应用有机整合,使AI模型能够根据实际场景需求,在算力资源间灵活调度与高效执行,从而为用户提供更敏捷、稳定且低延迟的智能化体验。

·     高效率自动化部署:根据网络拓扑模型,自动化下发RoCE参数及业务网络的配置,提升部署效率。

·     智能化运维平台:部署AD-DC智算平台,全面管理AI算力平台的计算、网络和存储基础设施,实现全生命周期管控。该平台通过端、网全栈可视分析,为企业提供端侧大模型训练的全方位支持,打破了传统的黑盒运维模式。

图110 AI大模型训练与移动端部署中的一体化应用

 

8.1.3  客户价值

通过智算网络的创新应用,客户可获得显著的业务价值提升:

·     运维革新:网络部署效率提升80%,网络部署时间从周级缩短至天级。

·     性能突破:端侧AI应用响应延迟大幅降低,用户体验显著改善。

·     业务创新:支撑AI业务的敏捷迭代与弹性扩展,加速智能应用创新落地。

8.2  超大规模AI算力集群中的应用

8.2.1  客户痛点

在构建超大规模AI算力集群的过程中,主要面临以下关键挑战:

·     算力释放瓶颈:传统网络架构难以支撑千卡/万卡级GPU集群的高频数据交换需求,网络延迟和丢包严重影响训练效率。

·     成本与扩展矛盾:封闭式高性能网络方案硬件成本过高,且缺乏弹性扩展能力,难以适应算力规模持续增长。

·     多租户管理困境:共享算力资源池面临租户隔离不彻底、资源调度不灵活等问题,制约商业化运营。

·     运维黑盒化:大规模网络缺乏可视化管控手段,故障定位效率低下,影响服务连续性。

8.2.2  解决方案

针对上述挑战,智算网络提供了全方位的技术解决方案:

·     高性能网络架构:

¡     采用RoCE技术构建400G超宽无损网络,实现1:1上下行收敛比。

¡     部署Spine-Leaf架构支撑大规模GPU集群通信,显著降低传输延迟。

¡     通过RDMA技术实现GPU直连内存访问,绕过CPU性能瓶颈。

·     多租户隔离机制:采用基于以太网RoCE架构的ACL访问控制机制实现租户间网络隔离,防止数据泄露和性能干扰。

·     智能运营体系:构建SDN统一管理平台,实现全域资源可视化监控。运维人员通过该平台实时掌握网络会话、流量路径及负载分布等状态,以便据此快速完成参数调优、资源配置和故障定位。该平台实现了运维模式从“黑盒”到“可视、可管、可调”的跨越。

图111 超大规模AI算力集群中的应用

 

8.2.3  客户价值

通过部署智算网络解决方案,客户可以获得以下显著收益:

·     性能突破:

¡     训练流程显著提速,充分释放算力潜能。

¡     支撑8K卡集群稳定运行。

·     成本优化:

¡     硬件成本降低40%50%

¡     设备供货周期缩短90%,供应链风险显著下降。

·     运营升级:

¡     故障定位时间缩短90%,运维效率质变提升。

¡     支持千卡到万卡规模的平滑扩展,投资回报周期缩短。

9 参考文献

·     H3C RoCE网络开局一本通》

·     《智能无损网络技术白皮书》

·     M-LAG技术白皮书》

·     H3C ICT知识百科词条 AD-AIDC

·     H3C ICT知识百科词条 液冷》

新华三官网
联系我们