Skip to main content
开放网络的先行者与推动者—星融元
加入我们技术支持(Support)  TEL:(+86)4000989811

标签: 技术实现

完整流程揭秘:30分钟搞定中大型园区网络业务开通,可行吗?


关注星融元


30分钟,从无到有,为中大型园区开通有线无线两张业务网,并在一个平台集中管理?

以上绝非夸夸其谈,如果是星融元新一代云化园区网,简直易如反掌!

我们使用全盒式SONiC交换机(Asterfusion CX-M系列)构建了深度云化的园区网络:采用更精简的Spine/Leaf 架构+统一的BGP路由 作为底层网络,依靠单一的云园区控制器(Asteria Campus Controller,ACC)即可快速完成整网的有线无线业务配置——体感近似于“即插即用”

ACC

只需三步

前篇我们已经介绍了一些概要,如果你此前对 TIP OpenWiFi 和 ACC 没有了解,建议先回顾一下:

完整揭秘:新一代园区网络运维管理全流程

配置前,园区网管理员需要将设备信息导入控制器指定组织/场所,按照拟定的网络规划给设备插线上电,后续操作都已高度自动化。

  1. 整网设备连接控制器(借助 DHCP option 自动获取控制器IP地址)
  2. 根据所选场景模板,控制器自动生成拓扑并完成基础网络配置(对用户屏蔽了技术细节,控制器自动计算BGP互联地址并完成整网路由配置)
  3. 开通有线网和无线网业务(基于控制器预置/自定义模板,图形界面一键批量下发)

第一步:设备自动连接控制器

设备上电后,可分两种情况讨论:

网络中已有DHCP Server —— 自动连接

星融元Asterfusion所有设备(包括交换机和AP)都可以作为 DHCP 客户端,出厂默认配置下即会自动发起DHCP请求,从网络中的DHCP Server 获取到 地址和控制器 IP 地址。

自动连接

#为了保证设备能获取到控制器的IP地址
#DHCP Server 需要能响应 option138 字段
#以下是 sc-dhcp-server 的配置参考
subnet 192.168.1.0 netmask 255.255.255.0{
range 192.168.1.100 192.168.1.200;
option routers 192.168.1.1:
option subnet-mask 255.255.255.0:
option capwap-ac-v4 “192.168.10.1” #控制器IP地址

网络中没有DHCP Server ——手动连接

很多初始状态的园区网络场景并没有DHCP服务器,此时我们只需串口接入一台Spine交换机,使能交换机上运行的ucentral-client 容器,并指定控制器IP。

该交换机连接上控制器后会自动从控制器处拿到用来配置其他Leaf交换机的文件,从而让整网设备都同控制器建立起连接。

sonic# config
sonic(config)# ucentral-client enable
sonic(config)# ucentral-client server 192.168.10.1 #控制器IP地址

第二步:自动生成拓扑和基础网络配置

完成设备与控制器连接后即可进入到控制器的规划拓扑标签下新建场景。

ACC控制器内置了名为中小型园区和中大型园区两种场景模板,两者都为Spine-Leaf架构的三层IP路由网络。

区别主要是后者在Spine和Leaf之间添加了一层Aggregation,从而轻松将Leaf交换机数量横向扩展到千台以上来适应更大规模的园区网络。

ACC

管理员仅需根据已拟定好的网络规划选择适合的模板,并设置交换机的对应型号、Spine/Leaf角色和数量,即可自动生成上述典型场景的推荐拓扑。

如下图所示,在生成的拓扑图上点击设备旁的编辑按钮即可继续设置各个互联端口。

ACC自动拓扑

最终效果可参考下图:场景组网下的设备上线状态、链路和接口关系一览无余。

上线状态

此时点击右上方的基础网络配置,即可配置业务网的静态出口路由,或者Spine上行出口链路所使用的动态路由,例如BGP、OSPF、路由汇聚等。

整个过程,用户除了提供IP地址等基础信息,无需关注其他技术细节,ACC控制器将会根据网络拓扑动态生成所需配置。

第三步:批量配置无线和有线业务

无线业务配置

ACC允许用户在设备上线前创建预置配置模板。

点击无线配置标签下的Wi-Fi设置,为无线 AP 配置业务开通必要的基础信息,如 SSID 设置、安全策略等。控制器可以根据管理员的输入,自动生成相应的配置脚本。

控制器支持配置多个无线业务配置,并通过标签区分 (上图示例为default)。无线 AP 接入PoE交换机自动上线并连接到控制器后,便会根据导入库存时设定的标签信息自动拉取与标签一致的配置

无线配置

对于特定场景,管理员也可在高级配置中自定义更改AP的默认配置。

LANs

当部分 AP(比如面板型 AP)提供的有线接口接入了有线终端,用户也可以在LANs处配置诸如上下行接口、VLAN tag、VLAN ID 等信息。

ACC

有线业务配置

与无线业务类似,ACC控制器可在有线业务配置标签下快捷完成配置脚本的生成和下发。可选设置项包括交换机的 VLAN、 DSCP 中继、ACL、DAI/IPSG、802.1x 用户认证信息等。

ACC

ACC

ACC

点击上图“配置”按钮,等待所有执行完毕,我们就已完成园区有线无线业务的开通。根据客户现场测算,以上操作平均用时在30分钟左右。此时整网的交换机、无线AP以及各类终端状态信息皆可在控制器内统一、集中地呈现,用以辅助日常运维管理。

ACC

关于新一代云园区网的可视化运维管理功能,例如设置告警、执行巡检等等我们将在下一篇详细介绍,请持续关注。

A-Lab 杂谈 | 自动化+可视化的智算中心多租户网络配置工具


关注星融元


A-Lab 是星融元服务于新一代网络运维工程师的资讯专栏,你可以在这里找到各类基于开放网络技术架构的配置指导和技术分享。访问地址:https://asterfusion.com/alab-for-netdevops/

论是在通用云数据中心和智算中心,多租户网络的目标都是要允许多个用户或租户共享同一物理基础设施,同时保持各自的隔离和安全性。

多租户网络依赖于虚拟网络技术(如 VLAN、VXLAN 或 NVGRE)实现逻辑隔离。随着部署规模的增大,这些技术的配置和维护可能变得复杂,如果配置不规范,可能导致租户间冲突影响业务运行甚至严重的数据泄露。

今天我们分享的是一款用于多租户网络的配置工具:EasyRoCE-MVD(Multi-Tenant VPC Deployer )。作为星融元AI智算网络方案的附加能力之一,MVD 帮助用户快速实现租户隔离,参数、存储、业务的多网联动和自动化部署。

EasyRoCE Toolkit 是星融元依托开源、开放的网络架构与技术,为AI 智算、超算等场景的RoCE网络提供的一系列实用特性和小工具,如一键配置RoCE,高精度流量监控等… 详情访问:https://asterfusion.com/easyroce/

EasyRoCE Toolkit MVD

  • 根据配置脚本自动批量部署,支持图形化界面呈现配置细节并远程下发
  • MVD工具可独立运行在服务器上,也可以代码形式被集成到第三方管理软件

业务架构

多租户网络架构由 Underlay 网络和 Overlay 网络组成。

Underlay 网络指的是物理网络设施,由交换机、光缆等网络硬件构成,负责底层数据的物理传输,运行高效的路由协议(如 BGP)实现互联,通常采用 Spine-Leaf 架构组网,负责提供提供稳定带宽、低延迟和高可靠性,这是多租户网络的基础。

Overlay 网络是在 Underlay 网络之上构建的虚拟网络,解耦了物理网络与业务需求,为每个租户提供独立的网络空间(如子网、IP 地址、路由)用于实现租户隔离和自定义网络配置,是多租户网络实现的技术核心。

网络设计规划

首先是必不可少的网络规划,这一步需由工程师基于实际业务需求设计逻辑隔离,一般是采用 VLAN、VXLAN 技术划分虚拟网络,规划 IP 地址池及子网,避免地址冲突。VLAN 适合较小规模,而 VXLAN 扩展性更好,适合大规模部署。

作为示例,我们在EasyRoCE-AID(AI基础设施蓝图规划)工具引导下快速完成网络设计,并自动生成包含了以下信息的 JSON 配置文件(mvd.json) 作为 MVD 工具的输入。

form

自动生成配置

MVD 工具将解析上一步骤得到的JSON文件中的设备信息、BGP邻居信息,并为集群中的交换机生成对应配置。 运行过程示例如下:

配置过程

可视化呈现和远程下发

MVD 运行时会以 Exporter 形式将以上配置信息暴露于http监听端口(如18080,18180),该数据可被 Prometheus 调用并将其呈现在 Grafana 界面上,供用户直观浏览现网设备的拓扑信息。 

配置远程下发

用户点进配置文件可看到配置下的具体信息,对其进行二次核对后再自行决定下一步操作,比如选择批量下发或针对某一设备单独下发。

相关产品

星融元(Asterfusion)AI智算网络解决方案采用基于SONiC的开放NOS(AsterNOS)+ 100G-800G 超低时延以太网交换机硬件,全端口支持 RoCEv2 & EasyRoCE Toolkit。如需了解产品详情或项目定制方案请与我们联系。

完整揭秘:新一代园区网络运维管理全流程


关注星融元


前言:传统网络面临的结构性挑战显而易见,尤其是多地多分支机构的大型园区网络,哪怕引入了一个大而全的SDN控制器,但底层仍沿用着复杂的园区网络架构,有线无线两张网分离控制,真实使用体验依旧差强人意。

新一代的园区网应该是什么样的?且不论未来如何,在放眼可见的当下,除了承载常规的办公网业务,园区的网络基础设施已然在面对诸如物联网智能终端接入,频繁的无线漫游,以及各类公有云、本地私有云业务融合等等挑战。

园区网络的云化转型已成必然趋势。论及云化,不单是更高的带宽速率,更是要配合现代化的网络架构和灵活的运维方式,解决复杂业务和管理效率之间的矛盾。

TIP:电信业“开源运动”领导者

TIP(电信基础设施项目)成立于2016年,由Meta(原Facebook)联合多家全球电信运营商、技术公司和行业组织发起,是一个开放协作的行业联盟。其核心目标是推动电信基础设施的开放解耦化和软件化,通过技术创新降低网络部署和运营成本,加速全球通信网络的普及与升级。

TIP 推出的 OpenWiFi 和 OpenLAN Switching为企业园区网络场景带来了基于通用硬件和开源软件的解决方案。

uCentral 作为 OpenWiFi 通信框架的关键核心,是一种标准化数据模型,它定义了网络中关键配置数据的结构和语义,以确保整个网络的一致性和互操作性,并且该协议是开放可扩展的,随社区技术发展平滑演进。

OpenLAN Switching(OLS) 将 OpenWiFi 的管理框架延展到了有线网络,显著扩展了OpenWiFi 的功能。实现形式是在交换机内部以容器形式运行一个客户端(uCentral Client),将有线网络纳入统一管理框架中。

OpenWiFi、OLS、局域网(LAN)

OpenWiFi和OLS 在局域网(LAN)中扮演各自不同角色,通过统一的北向接口与上层管理系统(Cloud SDK )对接,并可复用成熟的开放网络组件(例如SONiC NOS)形成有线+无线、完整的端到端开放网络解决方案

Asteria Campus Controller(ACC) 是星融元基于SONiC+ OpenWiFi/OLS 的云化网络的核心组成部分。

作为一款基于TIP社区标准的轻量级控制器软件,ACC 为园区有线网络和无线网络的统一管理提供了全面的解决方案。它可以无缝管理无线AP(包括第三方白盒AP)和所有搭载着星融元AsterNOS的SONiC交换机,自动执行网络配置和管理等关键任务。正常情况下,为一个中大规模的园区开通网络业务仅需30分钟。

部署方式

ACC支持三种部署方式:

  • 本地部署(以docker形式部署在开放计算平台/服务器)
  • 虚机部署(部署在虚拟机内,网络设备较多时适用)
  • 云上部署(通过访问IP/域名,随时随地查看整网运行状态)

01、ACC 界面概览

登录ACC控制器后我们首先会看到一张全景地图,可以看到控制器纳管的网络自顶向下分为“根节点-组织-场所-设备”四个逻辑层。

ACC

(点开查看gif)

  • 根节点作为系统默认节点,不可调整;
  • 根节点下可建立“组织”,可以简单理解为一个管理域(例如一家公司或园区运营者可支配的管理范围);
  • “组织”下可建立“场所”,对应着不同的办公区域或者分支机构;“组织”支持嵌套结构,即建立子组织,并继续建立子组织下的“场所”;
  • “场所”之下是设备层,展示了分配在该场所的物理网络设备,一般是按照有线设备(交换机)、无线设备(AP)分组。

02、内生的资产管理能力

值得一提的是,控制器内部自带了较为完善的资产管理能力,标准使用流程下即可自动完成数据整理并生成设备清单。

具体来说,我们购入新设备做的第一件事便是进入预计安装部署的组织或场所,比如下图的“1号办公楼”,在库存栏目点击按键选择手动导入设备或者基于模板批量导入。

此处导入的信息主要是设备的角色类型(Spine或Leaf)和序列号。待设备上电,控制器会自动根据设备的MAC将其纳入所属的组织/场所,并无额外操作。

截图

导入完成后便可获得下面这张设备清单,它包含了设备所在场所、型号、名称、管理IP、许可证状态等信息字段。管理员可在此选择特定字段筛选,并在同一界面编辑调整清单信息。此处的“标签”字段对应的是控制器的配置模板,后续设备将据此标签信息从控制器拉取对应配置文件,做到真正的即插即用。

截图

03、ACC带来的运维效率提升

上文已经提到,使用ACC为一个中大规模的园区开通网络业务仅需30分钟,开局效率的大幅提升主要来自于以下几点:

  • 基于场景模板(全三层的Spine-Leaf 架构)自动生成规划拓扑
  • 屏蔽实现细节,由控制器自动计算并通过ZTP机制下发基础网络配置
  • 借助DHCP option 128 为交换机和无线AP同时提供“即插即用”的能力
  • 图形化界面+自定义脚本,一键配置VLAN业务,DHCP中继,以及其他安全协议

下一篇我们将围绕上述内容详细展开,请持续关注。

A-Lab 杂谈 | 十年老网工,为啥这次没把智算服务器一次配通?


关注星融元


A-Lab 是星融元服务于新一代网络运维工程师的资讯专栏,你可以在这里找到各类基于开放网络技术架构的配置指导和技术分享。访问地址:https://asterfusion.com/alab-for-netdevops/

十年弹指一挥,当年的爆款热词“云计算”已然能搭上“传统” 二字当前缀;

十年弹指一挥,机房滚滚轰鸣声中,网工小王不知不觉熬成了老王;

老王不解啊,十年弹指一挥,咱亲手上架的服务器不说上千也有大几百,不就多了几张网卡,配个智算服务器怎会卡了壳?!

客官别笑,通用云计算中心与智算中心在主机侧网络架构层面的确存在显著差异,老网工偶尔走点弯路也是在所难免的啦。今天就让我们快速捋一捋其中缘由。

为啥出错?

传统CPU服务器多采用单网卡出口设计,通过OS内核协议栈实现网络报文转发,其网络拓扑相对简单,主要满足虚拟化资源的弹性调度需求。

源于AI训练任务对网络带宽的严苛要求,智算中心的GPU服务器普遍采用多网卡出口架构,用于接入参数网、存储网、业务网和带外管理网,其中通常会有8张网卡用于接入参数网,或称计算后端网络。而跨服务器的通信大多发生在同轨(Rail)的网卡/GPU之间。(请参考:关于智算的“多轨道网络架构”

多轨道网络架构

老王遇到的机间通信失败问题主要发生在以下两种场景:

场景1

智算业务报文从管理网段发出。两台GPU服务器A和B的8张网卡都接入到一张参数网,对应的网卡A1到A8、B1到B8,它们都分配到不同的网段,同轨网卡之间有互通需求(A1-B1,A2-B2…)

如果没有进行路由规划,通常在GPU服务器A的系统上会看到默认路由是业务网的,8个子网A1~8会产生8条对应的网段路由,报文会命中A的默认路由从管理网段发出,此时A1和B1是无法直接通信的。

场景2

回程通信失败。如果网卡A1到A8、B1到 B8 都分配到同一个网段下的不同IP,在这种情况下在服务器B上通过B1尝试与A1通信,会发现报文可以到达A1,但是回包会命中默认路由之外的代价最低的路由,很可能会从其他7张网卡中的一张出去,导致通信失败。

通信失败情况下可能的系统路由配置:

路由配置

应对思路

当传统路由设置方法在智算环境下失效,一个可行的应对方式是提前规划GPU服务器内的路由,借助Linux的多路由表和策略机制实现更加灵活、精细的流量控制和路由管理功能。

具体而言:在Linux内增加一个自定义路由表,并通过策略路由告知系统,特定源地址的报文根据这张自定义路由表转发,并在该表中增加一条指定目的网段的表项(例如前往10.0.5.0/24的报文从指定网卡发出)。

  • 多路由表(Multiple Routing Tables):Linux支持多张路由表,这些路由表可以通过不同的标识符来区分,每张路由表中可以包含一组路由规则。Linux系统默认会存在一个主路由表,当不特别指定的时候路由规则会写入默认路由表。
  • 策略路由机制(Policy Routing):根据数据包的源目的IP、网卡等条件来选择合适的路由表进行转发。

更高效的实现方式

更高效的办法,当然是用脚本工具批量自动配置啊!

星融元(Asterfusion)AI智算网络解决方案中包含的EasyRoCE Toolkit – IRM工具(In-Node Route Map,GPU服务器内部路由规划)正是用于解决多网卡路由问题——根据已有的IP地址规划表,自动生成并对集群内所有GPU服务器下发内部路由规划和配置。

IRM工具运行过程中需要通过SSH和集群中的所有GPU服务器进行交互,一般运行在管理节点上。

GPU服务器内部路由规划

网工老王仅需完成三步微操:

1、将IRM工具上传到管理节点;

2、指定需要解析的路由规划信息文件。该文件可在EasyRoCE-AID (AI Infrastructure Descriptor,AI基础设施蓝图规划)工具引导下手动填写,形式为下图所示的excel表格,主要包含IP和接口地址规划、Rail平面划分等构造智算网络的必备信息;

IP和接口地址规划、Rail平面划分

3、运行IRM工具脚本。等待上述规划信息完成转换重组后,IRM工具会生成包含路由配置的JSON文件并下发到集群,随后网络运维人员即可查验到所有GPU服务器内部的策略路由都已成功生效,同一个Rail平面内的网段按照预期正常互通。此外,该阶段生成的JSON文件亦可复用于其他客户自定义/第三方工具。

DeepSeek优化徒劳?揭秘99%的AI推理集群都适用的组网设计


关注星融元


DeepSeek的优化,精细但门槛极高

作为开源周的“彩蛋”,DeepSeek于上周六展示了采用混合专家模型(MoE)DeepSeek-V3 / R1 所使用的推理架构的整体方法——从增大吞吐和降低时延的目标出发,再次优化了PD分离架构,不过暂时没有开源代码。

(MoE)DeepSeek-V3 / R1

与Llama等采用张量并行(TP)的Dense(稠密)模型不同,混合专家(MoE)模型通过组合多个专家模型来处理复杂任务,每个专家模型专注于输入数据的不同部分,每次计算任务只需激活特定专家(而非整个神经网络)。

DeepSeek-V3 / R1 的推理系统架构一方面引入了更复杂的跨节点和多节点的传输提升计算效率和改善内存墙,同时也通过异步通信和流水线调度设计,确保由此增加的通信开销被计算任务掩盖。

值得注意的是,根据官方公布的信息,若要充分发挥DeepSeek MoE 模型的能力,起步资源是320卡,且不论在未开源的情况下面临的技术挑战。

综合成本和需求考量,上述面向专家并行的推理系统优化仅在部分toC云计算场景具备一定研究意义。现阶段toB行业大模型以及边缘计算场景仍以Dense模型为主,需要高并发的大集群平台部署可延续现有主流的算力网络设计思路,面向本地低并发需求则可采用大内存单机部署方案。

回顾:AI推理集群的PD分离和流量特征

大模型的推理任务一般分为两个阶段,一是Prefill,处理所有输入的 Token,生成第一个输出 token 和 KV cache,是算力密集型;二是Decode,利用 KV Cache 进行多轮迭代,每轮生成一个 token,需要反复读取前面所有token的 Key 和 Value,瓶颈在于内存访问。

从用户实际体验层面看,推理过程中最关键的指标是 “第一个Token的延迟” (Time To First Token, TTFT) 和后续token输出的延迟(Time Per output Token, TPOT)。

如果 Prefill 和 Decode 两个阶段在同一张GPU卡上运行,则容易发生资源争抢影响到 TTFT 和 TPOT 表现,尤其是当用户输入一段长 prompt 时,不光需要较多算力来支撑prefill运算, 也需要大内存来存储 KV Cache。

 Prefill-Decode

因此,业界通常采用 Prefill-Decode 分离的架构:用高算力卡做 Prefill(prefill server), 低算力卡做 Decode(decode server), Prefill节点在完成计算传输 KV cache 后即可释放本地显存。

参阅:一文揭秘AI智算中心网络流量 —AI推理

AI推理系统的 Scale-out 组网设计

推理集群的工程部署方面,由于 Prefill 和 Decode 采用的GPU并行方式不一样,Prefill和Decode集群是相互独立的,但两个集群间需要互联以同步KV cache。从两个阶段的输入输出来看,Prefill 流量的特征是低频大流量,要求大带宽;Decode 阶段流量的特征是高频小流量,要求低时延。

1、分离网络架构

  • 分为Prefill网络和Decode网络,分别负责本集群内流量,两个集群之间的流量通过互联网络实现
  • 两个网络分别运维管理,但Prefill和Decode GPU之间的流量至少需要3跳

2、统一网络架构

  • 单个网络同时负责集群内和集群间流量
  • 网络统一运维管理,Prefill和Decode GPU之间流量可一跳直达

统一网络架构

我们推荐采用统一网络架构,借助 QoS、自适应路由技术对 Prefill 和 Decode 流量分别处理。

Rail-only 拓扑

Rail-Only

  • GPU服务器内部:每四个GPU作为一组,共享一个并行推理网卡,连接到同一个PCI Switch,两组GPU之间的通信通过两个PCI Switch之间的直连通道完成;
  • GPU服务器之间:同一组号的GPU之间的通信通过交换机直接完成;不同组号的GPU之间的通信,先通过PCI Swtitch将流量路由到另一组的网卡,然后通过交换机完成

小规模并行推理网络拓扑

小规模并行推理网络拓扑

  • 每台推理服务器有8张GPU,2张400G网卡,双归连接到两台CX732Q-N
  • 16个推理服务器(128张GPU)和2个CX732Q-N组成一个PoD。Prefill和Decode服务器可能属于不同PoD
  • 可横向扩展至64个PoD

中大规模并行推理网络拓扑

  • 中大规模并行推理网络拓扑每台推理服务器有8张GPU,2张400G网卡,双归连接到两台CX864E-N
  • 64个推理服务器(512张GPU)和2个CX864E-N组成一个PoD,Prefill和Decode服务器在同一个PoD,服务器间一跳可达
  • 可横向扩展至64个PoD

拓扑设计仅供预览参考,方案均采用星融元(Asterfusion)提供的CX-N系列 AI智算网络产品:基于SONiC的开放NOS(AsterNOS)+ 100G/200G/400G/800G 超低时延以太网交换机硬件,全端口支持 RoCEv2 & EasyRoCE Toolkit。了解产品详情或项目定制方案请与我们联系。

尝试私有化部署DeepSeek?至少九成工程师会忽略这一点


关注星融元


当你尝试在私有集群上部署各类LLM应用,除了关注作为成本中心的算力资源,也一定不要忽视网络侧的配置!未经优化的网络连接,会给你的集群通信性能带来将近80%的损耗,哪怕仅有双机8卡规模。

参考:分析NCCL-Tests运行日志优化Scale-Out网络拓扑

一言以蔽之,上述性能瓶颈来自于网络连接方式与集合通信模式的不匹配。当前智算集群内采用的组网是“轨道优化”多轨道网络架构”,连接方式与一般云计算场景差别巨大。

以适用性最高的 Fat-tree CLOS 组网架构为例(这也是各大智算公有云的首选方法,具有非阻塞的 all-to-all 连接,不依赖于正在训练的模型),下方拓扑中的Leaf/TOR交换机被称为轨道交换机(Rail Switches),它们与所有集群单元内的GPU节点都建立了直接连接。

 Fat-tree CLOS

为什么要有轨道优化?

这个问题可能需要从通信库说起。当我们要利用分布式的GPU集群实现并行计算,集合通信库是关键环节之一。集合通信库向上提供API供训练框架调用,向下连接GPU卡(机内和机间)以完成模型参数的高效传输。目前业界应用最为广泛的是NVIDIA 提供的 NCCL 开源通信库,各个大厂基本都基于 NCCL 或 NCCL 的改造版本作为底座。

NCCL自2.12版本起引入了 PXN 功能,即 PCI × NVLink。PXN 利用节点内 GPU 之间的 NVIDIA NVSwitch 连接,首先将数据移动到与目的地位于同一轨道上的 GPU 上,然后将其发送到目的地而无需跨轨道传输,从而实现消息聚合和网络流量优化。

NVIDIA NVSwitch

轨道优化拓扑即是适应这一通信特征,将不同服务器上位于相同位置(轨道)的NIC连接到同一台交换机上。

由于每个服务器有8张连接计算平面的网卡,整个计算网络被从物理上划分为8个独立并行的轨道(Rail)。由此,智算业务产生的并行通信需求(All Reduce、All-to-All 等)可以用多个轨道并行地传输,并且其中大部分流量都聚合在轨道内(只经过一跳),只有小部分流量才会跨轨道(经过两跳),大幅减轻了大规模集合网络通信压力。

轨道优化聚合了同一对 NIC 之间传递的消息,得以最大限度地提高有效消息速率和网络带宽。反观NCCL 2.12 之前,同样的端到端通信将经过三跳交换机(上图的L0、S1 和 L3),这可能会导致链路争用并被其他流量拖慢。

如何配置多轨架构的智算网络?

首先是需要明确GPU卡的连接方式。如果是N卡,你可以使用nvidia-smi topo -m的命令直接查看。但综合考虑成本因素,要想在更为通用的智算环境下达到GPU通信最优,最好的办法还是在采购和建设初期就根据业务模型特点和通信方式预先规划好机内互联(GPU-GPU、GPU-NIC)和机间互联(GPU-NIC-GPU),避免过早出现通信瓶颈,导致昂贵算力资源的浪费。

下面我们以星融元智算网络方案具体举例,使用CX-N系列RoCE交换机组网。 

CX-N系列产品

100G/200G/400G/800G RoCE 端口,运行企业级SONiC/AsterNOS,转发时延约450~560ns,全面支持 EasyRoCE Toolkit

主机侧的路由配置

智算环境下以GPU卡(而非服务器)为单位的通信模式形成了服务器多网卡多出口环境的路由策略,通常会有8张网卡用于接入参数/计算网,每张网卡位于各自的轨道平面上。为避免回包通信失败,服务器上的网卡配置需要利用Linux多路由表策略路由机制进行路由规划,这与传统云网的配置方式完全不同。

第一步是按照组网规划和网段规划,进行IP地址规划和Rail平面划分。在我们的EasyRoCE Toolkit 下的AID工具(AI Infrastructure Descriptor,AI基础设施蓝图规划)中,Notes字段用于标注Rail编号,即0代表Rail平面0、1代表Rail平面1,以此类推。 

星融元 EasyRoCE AID 工具
截取自星融元 EasyRoCE AID 工具
确认好了上述信息,到这里其实可以开始手动配置了,但你也可以使用另一个EasyRoCE的IRM工具(In-node Route Map,GPU内部路由规划器)。IRM 从AID 生成的配置文件中获取适合当前集群环境的路由规划信息,并且自动化地对集群中的所有GPU服务器进行IP和策略路由配置。

In-node Route Map,GPU内部路由规划器

交换机侧的主动路径规划

交换机侧的主动路径规划

CLos架构下,各交换节点分布式运行和自我决策转发路径容易导致无法完全感知全局信息,在多层组网下流量若发生Hash极化(经过2次或2次以上Hash后出现的负载分担不均)将拖慢集群性能。

为解决满足AI集群规模化部署的通信需求,一般来说我们会通过规范流量路径来解决性能和规模方面的痛点(例如负载均衡、租户隔离等),按照如下转发逻辑去配置RoCE交换机:

  1. 跨 Spine上行流量进入Leaf后根据源IP和是否为跨Spine远端流量,执行策略路由转发给Spine,每网卡对应一个接口:
  • 在上下行流量1:1无收敛的情况下,Leaf的每个下行端口绑定一个上行端口;
  • 在n:1的情况下,上下行端口以倍数关系(向上取整)形成n:1映射。
  1. 跨Spine上行流量在Spine上按照标准L3逻辑转发,在轨道组网中多数流量仅在轨道内传输,跨轨道传输流量较小,网络方案暂不考虑Spine上拥塞的情况(由GPU Server集合通信处理)。
  2. 跨 Spine下行流量进入Leaf后根据 default 路由表指导转发。

当然,这里也可以使用EasyRoCE Toolkit 下的PPD工具(主动路径规划,Proactive Path Definer)自动生成以上配置。以下为PPD工具运行过程。

正在生成配置文件
100%[#########################]
Configuring leaf1's port 
leaf1的端口配置完成 
Generating leaf1'
s ai network config
The ai network config finished.
 
正在生成配置文件
100%[#########################]
Configuring leaf2's port 
leaf2的端口配置完成 
Generating leaf2'
s ai network config
The ai network config finished.
 
正在生成配置文件
100%[#########################]
Configuring leaf3's port 
leaf3的端口配置完成 
Generating leaf3'
s ai network config
The ai network config finished.
 
正在生成配置文件
100%[#########################]
Configuring leaf4's port 
leaf4的端口配置完成 
Generating leaf4'
s ai network config
The ai network config finished.
 
正在生成配置文件
100%[#########################]
show running config
是否需要查看生成的配置(Y|N):

PPD可以独立运行在服务器上,也可以代码形式被集成到第三方管理软件中,利用AID工具来生成最终配置脚本,将配置呈现在统一监控面板(例如Prometheus+Grafana)进行浏览和核对。

PPD

园区网前沿实践:基于开放网络架构的云化路由设计


关注星融元


底层物理网络设计

如下图所示,区别于传统的“接入-汇聚-核心”架构,新一代云化园区比照数据中心网络采用 Leaf-Spine 的 Clos 架构组网,Leaf 和 Spine 层都被设计成独立的 AS 并通过 eBGP 互联,支持终端设备以 1GE 及以上端口速率接入网络。
园区底层物理网的云化升级关键是将 EVPN 和 BGP 等能力下沉到接入级交换机。目前全功能的企业级SONiC(AsterNOS)可稳定运行在园区交换机上,完全支持将此类成熟的云网技术引入园区。
由此,我们构建了足够灵活、可靠的全三层网络来承载园区日益复杂、多变的网络业务,消除了原有传统架构用于业务分区管理的二层网络,也无需引入堆叠架构。
根据实际需求,我们有时也会在 Spine 和 Leaf 之间添加二层交换机,但其唯一功能是扩展端口容量,不会参与路由、EVPN 或 BGP 操作。
这种设计对大型园区的好处十分明显,例如杜绝内网广播风暴,降低网络架构复杂度(一键下发配置模板做到”全自动BGP”);同时也具备一定的内生安全性(例如隔绝了依赖广播的病毒攻击等等),以及高度适应企业数字化转型的云原生特性。

终端IP地址规划和分配

回归到路由设计的话题,构建全三层路由网络的重难点是合理规划和分配 IP 地址。
我们知道,传统园区网络设计中不可避免的一大挑战来自交换机的表项资源,其大小决定了园区接入规模的上限,这也是为什么曾经我们需要大型机框作为核心路由来支持超大型网络。
而在上述的云化园区网里,我们并未引入任何昂贵的机框设备,那么仅凭全盒式的开放交换机设备是如何做到的呢?
园区网架构
简言之,通过聚合路由技术和合理的IP分配策略,我们可以有效节约路由表项资源,并结合多级的 Leaf-Spine 架构将网络平滑扩容到30K+终端接入规模。

两种不同类型的终端路由信息

园区网络中的终端大体可分为漫游和非漫游两种类型。
对于非漫游终端,我们可以使用聚合路由,即将多个终端设备 IP 地址聚合到一个子网路由,以减少交换机表项空间占用。
聚合路由的正常运行需要与 IP 地址分配策略紧密结合,而借助 DHCP Option 82,我们可以确保同一 Leaf 交换机下的所有非漫游终端设备聚合在同一子网内。
DHCP Option 82 即“中继代理信息选项”。园区Leaf交换机作为 DHCP 中继代理设备,会在客户端发起的DHCP请求报文中添加 Option 82 字段,将 DHCP 客户端的位置信息附加进去提供给DHCP 服务器,后者利用该字段信息为主机分配合适的IP地址和其他配置信息;中继代理设备会在将DHCP回复转发给客户端之前删除该字段。
对于漫游终端不会使用聚合路由,而是保留其原有的 IP 地址。即使终端漫游到不同的 Leaf 交换机,也将一直使用原有的主机路由信息接入网络。
Spine 层交换机负责正确维护这些漫游终端的主机路由信息,整网范围皆为“云漫游”域。这种新架构下我们无需建立CAPWAP隧道让流量绕行转发,配置管理上也做到了高度简化。
以上过程中所有二层数据帧都将被转发并转换为三层报文,ARP 侦听机制在其中起到了至关重要的作用。

ARP 侦听机制

终端发起 ARP 请求时,其接入的Leaf 交换机会通过 ARP 侦听机制生成 ARP 和 IP 地址之间的映射(将ARP表项转换为32位主机路由),将这些信息同步到直连的 Spine 设备上,并通过BGP重分发学到的主机路由使其在 Spine 层传播,但不会再发送到其他 Leaf 交换机上。
最终,各类主机的路由信息会以如下方式逐级汇总:
  • Leaf 交换机保存本地连接的主机路由和通往上层 Spine 交换机的默认路由
  • Spine 层交换机维护整个网络的路由,包括整网所有终端的主机路由信息
  • 更上层的网络设备(如FW)路由表存放非漫游终端的聚合路由和漫游终端的主机路由
如此一来,无论是 MAC 地址表还是主机路由表,Leaf 交换机都只存储本地路由和默认路由,只有高性能的 Spine 层交换机维护全局路由信息,从而给后续网络扩容留有充足空间。

BGP 路由快速收敛

我们的整个网络采用 BGP 路由协议,利用 BFD (双向转发检测)实现快速路由收敛。BGP 使用 BFD 监控链路和节点状态,可在单链路或单节点故障时实现快速恢复,故障检测时间约为 150 毫秒,性能可调。发生故障时,流量会自动切换到备用交换机,确保快速恢复端到端服务。

EVPN Multihoming 技术确保终端高可靠接入

为了保证终端访问的可靠性,接入园区网络的服务器可采用 EVPN-Multihoming 技术,将其连接到两个 Leaf 交换机上作为主-主备份的双上行接入;对于无线AP也可以采用类似的设计,将它们连接到两个 Leaf 交换机,以确保在单链路故障时业务不中断。

P4 软件开发环境(Intel P4 Studio SDE)现已开源


关注星融元


Intel P4 Studio 软件开发环境 (SDE)是一套支持用户使用P4语言对P4可编程以太网交换机数据面进行编程的软件包,编译好的数据面程序可以运行在Tofino芯片上或是SDE中的模拟芯片上。该软件包还包含用于构建和安装 SDE 的脚本。

P4 SDE 现已开源

据P4社区网站(P4.org)近期发布的公告 (https://p4.org/intels-tofino-p4-software-is-now-open-source/),原先需由用户向Intel申请使用许可的P4软件包现已开源(仿真模型尚在开源准备过程中)。


开发人员现在可以访问整个源代码,该代码组织在 p4lang 结构内的两个主要存储库中。p4c 存储库现在还包含 Tofino 编译器组件,其子文件夹包括 arch、common、control-plane、driver、midend、test 和 docs。Tofino后端与 bmv2、ubpf 和其他后端处于同一层次。新推出的open-p4studio 存储库包含 Tofino P4 Studio 的所有其他组件,例如 bf_driver、bf_diags、bf_utils 和 tofino_model。

项目地址:https://github.com/p4lang/open-p4studio

仍需从 Intel 获取的内容

  • P4 Insight GUI :用于可视化 P4 程序编译后所使用的硬件资源。(社区正在与Intel沟通,或可将其作为开源发布)
  • 部分 bfrt_python 代码:当前开源项目已包含了一些,但目前尚不清楚是否已包含使用它所需的所有部分。
  • BSP(板级支持包):使 SDE 能够访问和配置物理板上的硬件,例如配置物理以太网端口并管理相关组件,如中继器、重定时器、SFP、QSFP 等。
  • ASIC 专用 Serdes 驱动程序:这些对于运行仿真模型不是必需的,但对于在真实 ASIC 上运行代码至关重要。

星融元X-T系列P4硬件平台

X-T系列:全开放、可编程、高性能的P4可编程硬件平台

X-T系列可编程交换机的主图

当前星融元X-T系列硬件平台规格包含:

48 x 25GE,8 x 100GE/40GE
32 x 100GE/40GE, 2 x 25GE
64 x 100GE/40GE, 2 x 25GE
32 x 400GE, 2 x 25GE
X-T 部分款型支持搭载2块DPU架构的ARM算力扣卡,从而实现x86(SONiC/ONIE/ONL)+P4(可编程高性能硬转发)+ DPU(自定义软转发)的全栈可编程硬件架构,满足高校、科研院所和产业界承载各类创新应用所需。

相关阅读:连接SONiC与P4交换芯片的SDE

P4可编程硬件平台产品开箱图
星融元将以稳定的产品供应支持和稳步推进中的高性能替代方案,为客户业务运行的连续性保驾护航。

RoCE与IB对比分析(二):功能应用篇

近期文章


在上一篇中,我们对RoCE、IB的协议栈层级进行了详细的对比分析,二者本质没有不同,但基于实际应用的考量,RoCE在开放性、成本方面更胜一筹。本文我们将继续分析RoCE和IB在拥塞控制、QoS、ECMP三个关键功能中的性能表现。

拥塞控制

拥塞控制即用来减少丢包或者拥塞传播,是传输层的主要功能,但需要借助链路层和网络层的帮助。

RoCEv2 的拥塞控制机制

RoCEv2通过链路层PFC、网络层ECN、传输层DCQCN三者协同配合,实现更高效的拥塞管理,可见,RoCEv2虽然使用了IB的传输层协议,但在拥塞控制方面有所不同。
  1. 基于优先级的流量控制(PFC)

PFC在RoCEv2中被用于创建无损的以太网环境,确保RDMA流量不因链路层拥塞而丢失。核心原理是下游控制上游某个通道开启和停止发送数据包,控制方式是发送PFC Pause和Resume帧,触发时机是根据下游SW的ingress的队列数量是否达到某个阈值。
而PFC允许在一条以太网链路上创建8个虚拟通道,并为每条虚拟通道指定一个优先等级,允许单独暂停和重启其中任意一条虚拟通道,同时允许其它虚拟通道的流量无中断通过。这一方法使网络能够为单个虚拟链路创建无丢包类别的服务,使其能够与同一接口上的其它流量类型共存。
如图1所示,DeviceA发送接口分成了8个优先级队列,DeviceB接收接口有8个接收缓存(buffer),两者一一对应(报文优先级和接口队列存在着一一对应的映射关系),形成了网络中 8 个虚拟化通道,缓存大小不同使得各队列有不同的数据缓存能力。
当DeviceB的接口上某个接收缓存产生拥塞时,超过一定阈值(可设定为端口队列缓存的 1/2、3/4 等比例),DeviceB即向数据进入的方向(上游设备DeviceA)发送反压信号“STOP”,如图中第7个队列。
DeviceA接收到反压信号,会根据反压信号指示停止发送对应优先级队列的报文,并将数据存储在本地接口缓存。如果DeviceA本地接口缓存消耗超过阈值,则继续向上游反压,如此一级级反压,直到网络终端设备,从而消除网络节点因拥塞造成的丢包。
  1. 显式拥塞通知(ECN)

ECN(Explicit Congestion Notification)是一种IP头部用于的拥塞控制的标记位,允许网络设备在发生拥塞时标记数据包,而不是丢弃它们。
RoCEv2利用ECN位来标记发生拥塞的数据包,接收方在检测到ECN标记后,发送CNP(Congestion Notification Packet)给发送方,后者通过拥塞控制算法(如DCQCN)调整发送速率。
  1. 数据中心量化拥塞通知(DCQCN)

DCQCN(Data Center Quantized Congestion Notification)是一种适用于RoCEv2的拥塞控制算法,是数据中心TCP(DCTCP)和量化通知算法的结合,最初在SIGCOMM’15论文”Congestion control for large scale RDMA deployments”中提出。DC-QCN算法依赖于交换机端的ECN标记。结合了ECN和速率限制机制,工作在传输层。当接收方检测到ECN标记时,触发CNP发送给发送方,发送方根据反馈调整发送速率,从而缓解拥塞。
综上,PFC、ECN、DCQCN分别工作在链路层、网络层和传输层。在RoCEv2中,它们被组合使用,以实现更高效的拥塞管理。
  • PFC:防止数据包在链路层被丢弃,提供无损传输,解决一段链路的问题。
  • ECN/DCQCN:发送方根据拥塞标记主动调整发送速率,减轻网络负载。解决端到端网络的问题。

InfiniBand 的拥塞控制机制

InfiniBand 的拥塞控制机制可分为三个主要部分:
  1. 基于信用的流量控制

IB在链路层实现基于信用的流量控制(Credit-based Flow Control),该机制实现了无损传输,是 InfiniBand 高性能的基础。发送方根据接收方提供的信用(表示可用缓冲区空间)来控制数据包的发送,接收方在处理完数据包后发送信用给发送方,以允许继续发送新的数据包,从而避免网络拥塞和数据包丢失。
如下图所示,发送方当前可用信用值2,通过流水线传输(pipelined transfer)连续向接收方发送数据包,但此时接收方缓冲区已满,发送方会暂停发送新的数据包,直到接收方发送新的信用。
  1. ECN机制
当网络中的交换机或其他设备检测到拥塞时,会在数据包的 IP 头中标记 ECN(Explicit Congestion Notification)。接收方的 CA(Channel Adapter)接收到带有 ECN 标记的数据包后,会生成拥塞通知包(CNP),并将其反馈给发送方,通知其网络出现拥塞需要降低传输速率。
  1. 端到端拥塞控制

发送方的 CA 在收到 CNP 后,根据 InfiniBand 拥塞控制算法调整发送速率。发送方首先降低数据发送速率以缓解拥塞,之后逐步恢复发送速率,直到再次检测到拥塞信号。这个动态调整过程帮助维持网络的稳定性和高效性。IBA没有具体定义特定的拥塞控制算法,通常由厂商定制实现。(HCA,Host Channel Adapters,or IB NIC)

 RoCEv2与IB拥塞控制机制比较

两者的拥塞控制机制比较如下:
拥塞控制机制比较

可见,RoCE与IB的拥塞控制机制基本相同,区别在于IB的拥塞控制机制集成度较高,通常由单个厂家提供从网卡到交换机的全套产品,由于厂商锁定,价格高昂。而RoCE的拥塞控制机制基于开放协议,可以由不同厂家的网卡和交换机来配合完成。
随着大规模AI训练和推理集群的扩展,集合通信流量导致了日益严重的拥塞控制问题,由此出现了一些新的拥塞控制技术,如基于In-band Network Telemetry (INT)的HPCC(High Precision Congestion Control),即通过精确的网络遥测来控制流量,以及基于Clear-to-Send (CTS)的Receiver-driven traffic admission,即通过接收方的流量准入控制来管理网络拥塞等。这些新技术在开放的以太网/IP网络上更容易实现。

QoS

在RDMA网络中,不光RDMA流量要获得优先保证。一些控制报文,如CNP、INT、CTS,也需要特别对待,以便将这些控制信号无损、优先的传输。
  • RoCEv2的QoS
在链路层,RoCEv2采用ETS机制,为不同的流量分配不同的优先级,为每个优先级提供带宽保证。
在网络层,RoCEv2则使用DSCP,结合PQ、WFQ等队列机制,为不同的流量分配不同的优先级和带宽,实现更精细的QoS。
  • InfiniBand的QoS
在链路层,IB采用SL、VL及它们之间的映射机制,将高优先级的流量分配到专门的VL,优先传输。虽然VL仲裁表 (VL Arbitration Table)能够通过分配不同的权重来影响和控制带宽的分配,但这种方式不能保证每个VL的带宽。
在网络层,IB的GRH支持8个bit的Traffic Class字段,用于在跨子网的时候提供不同的优先级,但同样无法保证带宽。
由此可见,RoCE能够为不同的流量类型提供更精细的QoS 保证和带宽控制,而 InfiniBand 只能提供优先级调度,而非带宽的明确保障。

ECMP

  1.   RoCE的ECMP

数据中心IP网络为了高可靠和可扩展性,通常采用Spine-Leaf等网络架构。它们通常在一对RoCE网卡之间提供了多条等价路径,为了实现负载平衡和提高网络拓扑的利用率,采用ECMP(Equal Cost Multiple Paths) 技术。对于给定的数据包,RoCE交换机使用某些数据包字段上的哈希(Hash)值在可能的多条等价路径中进行选择。由于可靠传输的要求,同一个RDMA操作应当保持在同一个路径中,以避免由于不同路径造成的乱序问题。
在IP网络中,BGP/OSPF等协议均可以在任意拓扑上计算出等价路径,然后由交换机数据平面基于IP/UDP/TCP等头部字段(如五元组)计算哈希值并轮流转发到不同路径上。在RoCE网络中,为了进一步细分RDMA操作,可以进一步识别BTH头部中的目的QP信息,从而实施更细粒度的ECMP。
  1.   InfiniBand的ECMP

在控制平面,IB的路由基于子网管理器,在拓扑发现的基础上实现ECMP,但由于集中式的子网管理器与网络设备分离,可能无法及时感知网络拓扑的变化,进而实现动态的负载均衡。
在数据平面,IB的ECMP同样基于哈希计算和轮转机制。

总结

  • 在拥塞控制方面,RoCE结合了PFC, ECN和DCQCN提供了一套开放的方案,IB则拥有基于Credit的一套高度集成的方案,但在应对大规模集合通信流量时均有所不足。
  • 在QoS方面,RoCE可以实现每个优先级的带宽保证,而IB仅能实现高等级的优先转发。
  • 在ECMP方面,两者均实现了基于Hash的负载分担。
总结来看,IB具备已验证的高性能和低延时优势,RoCEv2则在互操作性、开放性、成本效益方面更胜一筹,且从市场占比及认可度来看,RoCEv2逐渐比肩IB;但不得不承认的是,RoCE和IB在应对大规模AI训练和推理中高带宽、突发式和广播型的集合通信流量时,均有所不足,而RoCE基于其广泛的以太网生态系统,能够更快速地拥抱新技术新协议,其潜力和可塑性更胜一筹,未来有望在网络格局中扮演更重要的角色。
  • 10G-800G的全场景互联:星融元CX-N数据中心交换机的单机转发时延(400ns)低至业界平均水平的1/4~1/5;采用BGP-EVPN、VXLAN、MC-LAG等技术构建可靠的大二层网络满足生产网络稳定性需求。
  • 搭载开放网络操作系统:星融元AsterNOS以SONiC为内核、依托容器化的系统架构,并提供RESTful API支持第三方应用快速集成,或对接上层管理调度平台,例如OpenStack,K8s等。
  • EasyRoCE极简运维:支持无损网络一键部署,Prometheus + Grafana 可视化监控大屏配合专用命令行,问题快速定位解决。

参考文档:
https://zhuanlan.zhihu.com/p/643007675
https://blog.csdn.net/essencelite/article/details/135492115
https://support.huawei.com/enterprise/zh/doc/EDOC1100075566/d1e17776
https://www.researchgate.net/publication/4195833_Congestion_Control_in_InfiniBand_Networks

返回资源中心

最新动态

RoCE与IB对比分析(一):协议栈层级篇

近期文章


在 AI 算力建设中, RDMA 技术是支持高吞吐、低延迟网络通信的关键。目前,RDMA技术主要通过两种方案实现:Infiniband和RoCE(基于RDMA的以太网技术,以下简称为RoCE)。

RoCE与IB网络架构概述

RoCE和InfiniBand均是InfiniBand Trade Association(IBTA)定义的网络协议栈,其中Infiniband是一种专为RDMA设计的高性能网络,它从硬件层面确保了数据传输的可靠性,为了进一步发挥RDMA的优势,IBTA在2010年定义了RoCE。RoCE则是Infiniband与以太网技术的融合,它在保持Infiniband核心优势的同时,实现了与现有以太网基础设施的兼容性。具体来说,RoCE在链路层和网络层与Infiniband有所不同,但在传输层和RDMA协议方面,RoCE继承了Infiniband的精髓。
从市场应用占比来看,2000年,IB架构规范的1.0版本正式发布,2015年,InfiniBand技术在TOP500榜单中的占比首次超过了50%,但据最新统计,在全球TOP500的超级计算机中,RoCE和IB的占比相当。以计算机数量计算,IB占比为47.8%,RoCE占比为39%;而以端口带宽总量计算,IB占比为39.2%,RoCE为48.5%。
图1 超级计算机 500 强中 RoCE 和 InfiniBand 的利用率
图2 超级计算机 500 强中 RoCE 和 InfiniBand 的利用率
图2 超级计算机 500 强中 RoCE 和 InfiniBand 的利用率

RoCE与IB报文格式对比

  • RoCE报文格式下图所示:
其中,RoCEv1使用了IB的全局路由头(Global Routing Header),IB BTH是IB的基本传输头(Base Transport Header),ICRC是对InfiniBand层不变字段进行校验的循环冗余校验码,FCS是以太网链路层的校验序列码。
RoCEv2中添加了IP Header和UDP Headrer,引入IP解决了扩展性问题。
图3 RoCE数据包格式
  • IB报文格式如下图所示:
在一个子网(Subnet)内部,只有Local Routing Header(LRH),对应OSI的链路层。在子网之间,还有一个Global Routing Header(GRH),对应OSI的网络层。在Routing Header之上,是Transport Header,提供端到端的传输服务,包括数据的分段、重组、确认和流量控制。接着就是报文的数据部分,包含应用层数据或上层协议信息。最后是不变字段和可变字段的循环冗余校验码(CRC),用于检测报文在传输过程中的错误。
图4 IB数据包格式

RoCE与IB网络层级对比

IB与RoCE协议栈在传输层以上是相同的,在链路层与网络层有所区别:
RoCEv1中,以太网替代了IB的链路层(交换机需要支持PFC等流控技术,在物理层保证可靠传输),然而,由于RoCEv1中使用的是L2 Ethernet网络,依赖于以太网的MAC地址和VLAN标签进行通信,而不涉及网络层(IP层,即OSI模型的第三层)的路由功能,因此,RoCE v1数据包不能实现跨不同的IP子网传输,只能在同一广播域或L2子网内进行传输。
RoCEv2在RoCEv1的基础上,融合以太网网络层,IP又替代了IB的网络层,因此也称为IP routable RoCE,使得RoCE v2协议数据包可以在第3层进行路由,可扩展性更优。
图5 RoCE和IB协议栈对比
  1. 物理层

  • RoCE的物理层基于标准以太网,使用PAM4 (Pulse Amplitude Modulation 4)编码方式和64/66b编码。支持铜缆和光纤,接口有 SFP+、QSFP+ 、OSFP等。支持速率从 10GbE到800GbE。
  • IB的物理层则是专有的,采用更传统的NRZ(Non-Return-to-Zero)调制技术和64/66b编码。支持铜缆和光纤,接口通常为 QSFP、OSFP,支持速率从 10Gbps 到 400Gbps,并可以通过多通道的组合实现更高的总带宽(如 800Gbps)。
对比来看,IB采用的NRZ每个符号只有两个电平,而RoCE采用的PAM4使用 4个不同的电压电平来表示数据,也就是说RZ信号中,每个周期传输1bit的逻辑信息,PAM4每个周期可以传输2bit的信息,因此在相同的波特率下,PAM4的数据传输速率是NRZ的两倍,具有更高的带宽效率,在支持更高速率(如1.6T,3.2T)时具有潜在的优势。目前,六进制(PAM6)和八进制(PAM8)调制技术正处于实验和测试阶段,而InfiniBand(IB)也在逐渐从传统的NRZ(非归零)调制技术转型至PAM4,例如,400G光模块现已能够同时支持IB和以太网标准。相比之下,以太网在调制技术的应用上展现出更为迅速的发展势头。
  图6 频域中 PAM4 与 NRZ 信号的频率内容
  1. 链路层

  • RoCE的链路层是标准以太网,为了在传统以太网上实现无损传输,引入了PFC(Priority-based Flow Control),由IEEE 802.1Qbb标准定义,当交换机的某个优先级队列的缓冲区接近满载时,会发送 PFC帧给上游设备,通知其暂停发送该优先级的流量,防止缓冲区溢出,避免数据包在链路层被丢弃。
此外,以太网引入了ETS(Enhanced Transmission Selection) ,它是DCB (Data Center Bridging)标准的一部分,由 IEEE 802.1Qaz 规范定义。ETS 将流量分配到不同的队列,为每个队列分配一个权重,控制每个流量队列能够使用的带宽百分比,保证高优先级的流量,如RDMA等,获得足够的带宽资源。
  • IB的链路层是专有的,包头称为Local Routing Header,如图所示。
其中,VL是虚拟通道 (Virtual Lanes),SL是服务等级 (Service Level),Source/Destination Local Identifier则是链路层地址。
它内建了对无损传输的支持,这是因为它实现了基于信用的流量控制(Credit-based Flow Control)。接收方在每个链路上提供一个信用值,表示其缓冲区能够接收的数据量。发送方根据此信用值发送数据,确保不会超过接收方的处理能力,从而避免缓冲区溢出和数据丢失。
IB链路层结合SL和VL实现QoS,SL共有16个业务等级,用于标识流量优先级,每个数据包可以根据业务需求被分配到不同的服务等级,通过SL-VL映射,将不同优先级的流量分配到不同的VL上,从而确保高优先级流量(如RDMA)不会因低优先级流量的拥塞而受到影响。
对比而言,IB的链路层由专用硬件实现,效率较高,具有超低时延的特点,而RoCE基于标准以太网硬件,时延稍长。但由于两者都达到了100ns级别,而根据UEC的最新定义,在传输RDMA时,端到端性能要求通常为10μs左右,它们的差别不大。
  1. 网络层

  • RoCE的网络层使用IP,可以是IPv4或IPv6。它采用成熟的BGP/OSPF等路由协议,适应任何网络拓扑并具有快速自愈能力;支持ECN(EXPLICIT CONGESTION NOTIFICATION ),用于端到端的拥塞控制;支持DSCP,替代IB的TRAFFIC CLASS,用于实现QoS。
  • IB的网络层借鉴了IPv6。Global Routing Header的格式与IPv6完全相同,具有128bit地址,只是字段命名不同。但它没有定义路由协议,而是采用子网管理器(Subnet Manager)来处理路由问题,这是一种集中式的服务器,每个网卡端口和交换芯片都通过由SM分配的唯一身份标识(Local ID,LID)进行识别,不具备互操作性,因此很难快速响应网络的变化。
显然,IB网络层是专有的、集中管理的,而RoCE的网络层基于标准以太网和UDP,在互联网数以十亿计算的设备上使用,技术成熟,并在持续发展中;引入SRv6等技术后,IP进一步增强了流量工程、业务链、灵活性和可扩展性等能力,非常适合组建超大规模可自愈的RDMA网络。
  1. 传输层

  1. RoCE

RoCE采用了IB的传输层。RoCEv2协议栈虽然包含UDP,但它仅借用了UDP的封装格式,传输层的连接、重传、拥塞控制等功能由IB传输层完成。UDP层的目的端口固定分配给RDMA协议,源端口则是动态分配的,但在一个连接过程中保持固定。这样可以让网络设备通过源端口区分不同的RDMA数据流。
  1. InfiniBand

IB的传输层采用了模块化的灵活设计,通常包含一个基本传输头BTH(Base Transport Header)和若干个(0到多个)扩展的传输头(Extended Transport Header)。
BTH(Base Transport Header)是InfiniBand传输层头部的一部分。它是InfiniBand网络协议中L4传输层的基本头部,用于描述数据包传输的控制信息。格式如下,
关键信息有:
  • OpCode操作码。由8个bit组成。前3个bit代表传输服务类型,如可靠连接/不可靠连接/可靠数据报/不可靠数据报/RAW数据报等。后5个bit代表操作类型,如SEND/READ/WRITE/ACK等。
  • Destination QP,目的QP号(Queue Pair Number)。与TCP端口号类似,代表了RDMA连接(称为Channel)的目的端。但与TCP端口不同的是,QP由Send/Recv两个队列组成,但用同一个号码标识。
  • Packet Sequence Number,包序列号,简称PSN。与TCP序列号类似,用于检查数据包的传输顺序。
  • Partition Key,分区键。可以将一个RDMA网络分为多个逻辑分区。在RoCE中可采用新一代的VxLAN等技术替代。
  • ECN,显示拥塞通知。用于拥塞控制,包含Forward和Backward两个bit,分别表示在发送和返回路径上遇到了拥塞,在RoCE中被IP头部的ECN替代。
BTH帮助接收方理解该包属于哪个连接以及如何处理接收到的包,包括验证包的顺序、识别操作类型等。
在BTH之后,还有RDMA Extended Transport Header,它包含远端的虚拟地址、密钥和数据长度等信息。格式如下,
其中:
  • VirtualAddress,虚拟地址,代表目的端内存地址。
  • DMA Length,直接内存访问长度,是要读写的数据长度,以字节为单位。
  • Remote Key,用于访问远端内存的密钥。
IB传输层通常由RDMA网卡硬件实现,在IB中称为Channel Adapter(CA),在RoCE中称为RoCE网卡,从而提升RDMA传输的性能。在一些高级的RoCE交换机中,还可以感知IB传输层信息并对RDMA数据流做加速处理。
  1. RDMA操作

借助RDMA扩展头,RoCE和IB的传输层对远程主机的地址进行直接的读写操作(Operation)。
  • RDMA写操作 (RDMA Write)
QP(Queue Pair) 建立后可以直接进行,允许发送方直接写入接收方的内存,不需要接收方的CPU参与,并且无需请求。这种操作方式是 RDMA 高性能和低延迟的核心特性之一。
RDMA Write 是一种单向操作。写入方在写入数据后不需要等待接收方的响应,这种操作与常规的 Send/Receive 模式不同,不需要接收方预先准备接收队列。
  • RDMA读操作 (RDMA Read)
允许发送方从接收方的内存中读取数据,不需要接收方CPU参与。目标地址和数据大小在发送方指定。如下图所示,在一次请求后,可以通过多次响应返回数据,提高了数据传输效率。
图7 RDMA 读操作
  • 发送/接收操作 (Send/Receive)
这是传统的消息传递操作,数据从发送方传递到接收方的接收队列中,需要接收方预先准备接收队列。
在RoCE中,RDMA跳过操作系统的TCP/IP协议栈,直接与RoCE网卡上的传输层连接,借助DMA机制,直接访问本地和远端内存,实现了零拷贝传输,大幅度提升了性能。
同样,IB网卡在硬件上实现RDMA操作,零拷贝传输,两者的性能相当。
当然,无论在RoCE还是IB中,RDMA 连接的初始化、资源分配、队列对 (QP) 管理、以及一些控制路径上的操作(如连接建立、内存注册等)仍然依赖于软件栈。
  1. 应用层

RDMA在数据中心、HPC集群、超级计算机中获得了广泛的应用,用于承载AI训练、推理、分布式存储等数据中心内部的关键业务。
例如,在AI训练/推理时, xCCL或者MPI使用RDMA实现点对点和集合通信;在分布式存储时,NVMEoF, Ceph使用RDMA对网络存储器进行读写操作。
  1. 网络层级对比小结

  • 在物理层,RoCE和IB都支持800G,但PAM4相比NRZ具有更强的升级潜力,以太网成本也低于IB,RoCE更胜一筹。
  • 在链路层,两者均实现了无损传输,RoCE的ETS能够为不同优先的流量提供带宽保证,且RoCE和IB的时延均达到了100ns级别,在实际应用中差不大。
  • 在网络层,RoCE借助IP的成熟的持续发展,更能适应大规模网络。
  • 传输层及以上,RoCE和IB使用同样的协议,没有区别。

RoCE与IB的较量,究竟谁更胜一筹

总的来说,RoCE和InfiniBand都由IBTA定义,没有本质的不同。RoCE实际上是将成熟的IB传输层和RDMA移植到了同样成熟的以太网和IP网络上,是一种强强联合,在保持高性能的同时,降低了RDMA网络的成本,能够适应更大规模的网络。
根据亚马逊的高级首席工程师Brian Barrett,AWS之所以放弃IB方案,主要是因为:“云数据中心很多时候是要满足资源调度和共享等一系列弹性部署的需求,专用的IB网络构建的集群如同在汪洋大海中的孤岛”。
出于AI算力建设对于成本和开放性的考量,越来越多的公司已经在使用以太网交换机用于大规模AI算力中心,例如当前全球最大的AI超级集群(xAI Colossus,造价数亿美元、配备十万片NVIDIA H100 GPU),便是采用64 x 800G,51.2T以太网方案构建集群网络。
CX864E-N是星融元专为AI训练、推理、高性能计算(HPC)等场景设计的一款行业内顶尖规格的RoCE交换机,拥有51.2T的超大交换容量,助力客户用更优的投入成本,实现与IB网络相当的性能。
CX864E-N
  • 8 x CX864E 支持 512 个 GPU 互连,每个端口速度为 400G
  • 192 x CX864E 支持 8192 GPU 互连,每个端口速度为 400G
  • 192 x CX864E 支持 128k ML/AI 节点互连,每端口速度为 100G

参考文献

https://mp.weixin.qq.com/s/PZ_Q5rS5a5YJlczao9SMXw
https://support.huawei.com/enterprise/zh/doc/EDOC1100203347
https://community.fs.com/cn/article/roce-technology-in-high-performance-computing.html
https://ascentoptics.com/blog/cn/understanding-infiniband-a-comprehensive-guide/
https://blog.csdn.net/jkh920184196/article/details/141461235
https://www.servethehome.com/inside-100000-nvidia-gpu-xai-colossus-cluster-supermicro-helped-build-for-elon-musk/

返回资源中心

最新动态

对星融元产品感兴趣?

立即联系!

返回顶部

© 星融元数据技术(苏州)有限公司 苏ICP备17070048号-2