Skip to content

RoCE 网络概述 ​

《H3C RoCE 网络开局一本通》拆分章节,文档版本:6W102。

返回总目录 · 下一篇


1.1 RDMA 的产生背景 ​

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

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

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

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

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

图 1-1 传统 TCP/IP 数据传输过程

数据复制 ​

图示


图 1-2 RDMA 数据传输过程 ​

数据复制

图示

1.2 RDMA 技术分类 ​

目前, RDMA 网络主要有 IB、 iWAPR 和 RoCE 三种类型。

图示

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

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

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

  • 其中 ROCE 分为 RoCEv1 和 RoCEv2 两代。

  • RoCEv1 协议:基于以太网承载 RDMA, RoCEv1 协议是一种以太网链路层协议,允许同一以太网广播域(VLAN)中的两个主机进行通信,只能部署于二层网络,它的报文结构是在原


有的 IB 架构的报文上增加二层以太网的报文头,使用以太网类型(EtherType) 0x8915 标识 RoCE 报文。

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

图示

1.3 为什么 RoCEv2 协议需要无损网络环境 ​

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

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


1.4 智能无损网络的技术架构 ​

图示

1.4.1 物理层 — 硬件支持 ​

针对智算网络,通算高性存储网络场景,要求大带宽,高密接入能力,通常选择交换机。 针对广域无损网络场景,带宽密度要求较低,并且要求大 Buffer 缓存能力,更高的灵活业务感知和处理能力,通常使用路由器。

1.4.2 链路层 — 流量控制技术 ​

PFC (Priority-based Flow Control,基于优先级的流量控制)是构建无损以太网的必选手段之一, 能够逐跳提供基于优先级的流量控制。

1. PFC 工作原理 ​

PFC 允许网络设备根据不同的数据流的 802.1p 优先级进行流量控制。 PFC 允许在一条以太网链路上创建 8 个虚拟通道,并为每条虚拟通道指定一个 802.1p 优先等级。当特定优先级的流量拥塞时, 网络设备可以向对端设备发送反压信号(PFC PAUSE 帧),要求对端设备停止发送特定优先级的流量,以防止缓冲区溢出和数据丢失。这种个别流量控制方式允许网络在某些流量拥塞时保持流畅, 同时防止对其他流量造成干扰。

如图 1-3 所示, Device A 和 Device B 之间存在多个 802.1p 优先级的流量,每个优先级的流量采用单独的虚拟通道转发。当 Device B 设备指定优先级的报文发生拥塞时,设备会根据本端收到报文的 802.1p 优先级进行判别,从而确定对报文的处理方式:

  • 如果 Device B 收到报文的 802.1p 优先级开启了 PFC 功能,则接收该报文,并向对端 Device A 发送 PFC PAUSE 帧,通知对端设备暂时停止发送该类报文。

  • 对端 Device A 设备在接收到 PFC PAUSE 帧后,将暂时停止向本端发送该类报文。当拥塞仍然存在时,此过程将重复进行,直至拥塞解除。


  • 如果 Device B 收到报文的 802.1p 优先级未开启 PFC 功能,则直接将报文丢弃。

  • Device B 收到的其他 802.1p 优先级的报文不受影响,可以正常处理。

如果 Device A 发生拥塞,也会采用上述过程通知 Device B 之停止发送该优先级的流量。

图 1-3 PFC 工作原理示意图

图示

如图 1-4 所示,当 Device B 的出接口上某个队列产生拥塞时,导致本设备对应流量的入接口缓存超过门限, Device B 向所有上游设备(数据报文的来源)发送 PFC PAUSE 帧。 Device A 接收到 PFC PAUSE,会根据 PFC PAUSE 的指示,停止发送对应优先级的报文,并将数据存储到本地接口的缓存空间。如果 Device A 本地接口的缓存消耗超过缓存门限,则也向上游设备发送 PFC PAUSE。 如此,一级一级的发送 PFC PAUSE,直到抵达网络终端设备,从而消除网络节点因拥塞造成的丢包。 Device E 接收到 PFC PAUSE 后,对该队列报文进行缓存,未达到 Device E 的缓存门限时, 不向上游设备发送 PFC PAUSE。

图 1-4 多级设备之间的 PFC PAUSE 帧处理示意图

图示

2. PFC 死锁检测 ​

PFC 死锁的产生 ​

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


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

图 1-5 PFC 死锁产生示意图

图示

触发 PFC 死锁检测 ​

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

图 1-6 触发 PFC 死锁检测示意图 ​

图示

PFC 死锁判定 ​

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

图 1-7 PFC 死锁判定示意图

图示


PFC 反压帧触发门限是缓冲区中某 802.1p 优先级报文在该存储空间使用的资源上限。该 802.1p 优先级报文占用的资源达到上限后,会触发设备发送 PFC PAUSE 帧。

PFC 死锁恢复 ​

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

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

3. PFC 死锁预防 ​

PFC 死锁预防是指设备通过识别易造成 PFC 死锁的业务流,修改队列优先级,从而预防 PFC 死锁的发生。

PFC 死锁预防的产生背景 ​

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

图 1-8 环网 PFC 死锁示意图

图示

PFC 高风险业务流 ​

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


具有相同 PFC 死锁预防功能配置的接口属于同一端口组。有关 PFC 死锁预防功能配置,请参见相关配置手册。

图 1-9 PFC 高风险业务流 ​

图示

PFC 死锁预防工作原理 ​

目前, PFC 死锁预防仅针对携带 DSCP 值的业务流量。

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

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

  • 识别高风险业务流。

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

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


图 1-10 PFC 死锁预防工作原理示意图 ​

图示

1.4.3 网络层 — 拥塞控制技术 ​

1. ECN ​

基本概念 ​

ECN (Explicit Congestion Notification,显式拥塞通知)是一种拥塞通知技术, ECN 功能利用 IP 报文头中的 DS 域来标记报文传输路径上的拥塞状态。支持该功能的终端设备可以通过报文中的 ECN 标记判断出传输路径上是否发生了拥塞,从而调整报文的发送方式,避免拥塞加剧。

在 RFC 2481 标准中, IP 报文头中 DS 域的最后两个比特位被定义为 ECN 域,并进行了如下定义:

  • 比特位 6 用于标识发送端设备是否支持 ECN 功能,称为 ECT 位(ECN-Capable Transport)

  • 比特位 7 用于标识报文在传输路径上是否经历过拥塞,称为 CE 位(Congestion Experienced)

图 1-11 IPv4 报文头中的 ECN 域示意图

图示

如图 1-11 所示以 IPv4 报文为例, RFC 3168 对 ECN 域的取值进行如下规定:


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

  • ECN 域的取值为 01 或者 10 时,表示该报文支持 ECN 功能,分别记为 ECT (0)或 ECT (1)。

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

实现原理 ​

ECN 功能需要和 WRED 策略配合应用。

如图 1-12 所示,没有开启 ECN 功能的 WRED 策略按照一定的丢弃策略随机丢弃队列中的报文, WRED 策略为每个队列都设定上限长度 QL_max 和下限长度 QL_min,对队列中的报文进行如下处理:

  • 当队列的长度小于下限 QL_min 时,不丢弃报文;

  • 当队列的长度超过上限 QL_max 时,丢弃所有到来的报文;

  • 当队列的长度在上限 QL_max 和下限 QL_min 之间时,开始随机丢弃到来的报文。队列越长, 丢弃概率越高,队列丢弃概率随队列长度线性增长,不超出最大丢弃概率 x%。

图 1-12 WRED 丢弃概率与队列长度示意图 ​

丢弃概率 ​

图示

如图 1-13 所示,在部署 ECN 功能的 WRED 策略的组网图中,存在三类设备角色:

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

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

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


图 1-13 部署 ECN 功能的 WRED 策略的组网图 ​

图示

部署了 ECN 功能的 WRED 策略的转发设备(Congestion Point)对接收到的数据报文进行识别和处理的具体处理方式如下:

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

  • 当转发设备的报文在出方向进入队列排队,该队列的长度大于下限 QL_min 但小于上限 QL_max (QL_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 门限可以缓解拥塞的同时保证网络的时延和吞吐率。

上述 ECN 域标识的修改过程是转发设备在出方向报文检测到拥塞后,修改入方向报文 ECN 域标识。 设备在处理过程中存在一定延时,为了加快该流程,转发设备在出方向队列检测到拥塞后,直接修改出方向报文的 ECN 域标识,这个技术称为 Fast ECN。

相较于未部署 ECN 功能的 WRED 策略,部署了 ECN 功能的 WRED 策略具备如下优势:

  • 通过合理设置 WRED 策略中队列长度的下限值,可以使转发设备提前感知到路径上的拥塞, 并由报文接收端通知报文发送端放缓发送速率。

  • 在转发设备上,对超出队列长度上限值的报文仅标记 ECN 域为 11,而不再丢弃报文,避免网络中报文丢弃和重传的过程,减少了网络时延。

  • 网络中出现拥塞时,发送端在一定时间内逐步降低报文发送速率,在拥塞现象消失后,发送端逐步提升报文发送速率,避免出现网络吞吐量在拥塞前后快速振荡的情况。

  1. ECN Overlay

基本概念 ​

ECN Overlay 功能是指在 VXLAN 网络中使用 ECN 功能,即在 VXLAN 网络中设备出接口发生拥塞时,报文的 ECN 域可以被标记为 CE,并且设备可以正常传递携带 CE 标记的报文,而不会丢失 ECN 域中的标记信息。

实现原理 ​

VXLAN 网络中拥塞发生的位置不同,报文 ECN 域处理流程和传递 ECN 信息的过程略有不同。如图 1-14 所示, VXLAN 隧道入节点的出接口发生拥塞为例,报文 ECN 域处理流程和传递 ECN 信息的过程为:

  • (1) ECN 信息的映射:在 VXLAN 隧道的发起端检测到拥塞时,设备将原始 IP 报文的 ECN 域标记为 CE。报文发送时,将原始 IP 报文进行 VXLAN 封装,此时设备将原始 IP 报文 ECN 域的 CE 映射到 VXLAN 报文外层 IP 头部的 ECN 域中。

  • (2) ECN 信息的传递:在 VXLAN 网络中传递的报文将携带 CE 标记, Underlay 的中转设备不进行修改。

  • (3) ECN 信息的恢复:在 VXLAN 隧道的终结端解封装 VXLAN 报文时,执行第一步中相反的操作, 即设备将 VXLAN 报文外层 IP 头部的 ECN 域中的信息复制到原始 IP 报文的 ECN 域中。

如果 VXLAN 网络的中转发设备的出接口上发生拥塞,则仅在 Underlay 的中转设备上标记 VXLAN 报文外层 IP 头部的 ECN 域,并且在 VXLAN 隧道的终结端将 ECN 域中的信息复制到原始 IP 报文的 ECN 域中。如果 VXLAN 隧道出节点的出接口发生拥塞,则仅需要执行上述 ECN 信息的恢复步骤。

图 1-14 ECN Overlay 工作原理示意图 ​

图示

3. 大小流区分调度 ​

网络中充斥着各种各样的流量,我们可以简单的将其分为大流和小流。


  • 大流(Elephant Flows,大象流):大流通常是业务数据流量,如文件传输、数据库同步和数据备份信息。大流的特点是数量虽少,却占用了网络中相当大的带宽资源,对吞吐率有要求, 对时延不敏感。大流占网络流总数的 10% 左右,但其承载了网络总数据量的 85%。

  • 小流(Mice Flows,老鼠流):小流通常是用来建立连接的协议流量,如网页请求、协议信令消息等等。小流的特点是它们在网络中出现非常频繁,数量众多,但每个流的数据量小, 对时延敏感,对带宽和吞吐率的要求较低。网络流量中的绝大多数都是小流。

突发大流引起的网络拥塞,可能会增加小流的时延,并引发小流丢包。因此,在调度流量避免拥塞时,优先保障小流的调度和时延至关重要。在无损网络中我们希望将大小流区分调度,以满足小流的延迟需求和大流的吞吐率需求。

如图 1-15 所示,大小流区分调度机制如下:

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

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

图 1-15 大小流区分调度示意图 ​

图示

图示

图示

4. 大小流自适应缓存 ​

大小流区分调度可以在一定程度上解决小流被大流阻塞的问题,但在网络中如果绝大多数流量都是小流的场景或者突发流量等情况下,通过静态配置识别参数的大小流区分调度功能优化的效果不佳, 例如数据中心网络中绝大多数流量是对时延更敏感的小流。对于上述场景,可以开启大小流自适应缓存功能。

在设备上,小流队列和大流队列共享一块缓存空间来调度报文。开启大小流自适应缓存功能可以动态调节小流队列和大流队列所占共享缓存空间的大小。 大小流自适应缓存功能的工作机制如下:

  • (1) 如下图所示,缺省情况下,设备中的不同队列均分共享缓冲区,队列之间允许互相抢夺竞争缓冲区资源。网络拥塞时,造成拥塞的队列可能竞争得到较多的共享缓冲区资源。共享缓冲

区占满之后,大小流均采取尾丢弃的策略来丢弃报文,即新进入缓冲区的大流和小流均被丢弃,丢弃的报文引发重传机制,重传的报文时延变大,因此,小流的时延无法保障。 图 1-16 未启用大小流自适应缓存功能

图示

  • (2) 启用大小流自适应缓冲技术后,如果发生网络拥塞出现丢包,系统自动调整大流为 WRED 拥塞管理策略,标记大流的丢弃优先级为黄色,并且降低大流的 WRED 丢弃门限,队列长度超出 Qlmin 门限,开始丢弃大流。系统限制大流可占用的共享缓存区降低到 Qlmin 门限以内。 大流减少的缓冲区资源被小流抢占。

图 1-17 启用大小流自适应缓存功能时小流丢包

图示

  • (3) 一段时间周期内,如果仍出现网络拥塞和丢包现象,则继续降低大流的 WRED 丢弃门限,限定大流可用的共享缓存区大小。系统可以多次降低大流可用的共享缓存区大小。

  • (4) 一段时间周期内,如果不再出现丢包,则逐渐恢复大流的 WRED 丢弃门限,直到大流最终恢复到缺省的尾丢弃策略。


图 1-18 启用大小流自适应缓存功能时小流不再丢包 ​

图示

5. AI ECN ​

背景简介 ​

各个队列转发的数据流量特征会随时间动态变化,网络管理员通过静态设置 ECN 门限时,并不能满足实时动态变化的网络流量特征:

  • ECN 门限设置过高时,转发设备将使用更长的队列和更多缓存来保障流量发送的速率,满足吞吐敏感的大流的带宽需求。但是,在队列拥塞时,报文在缓存空间内排队,会带来较大的队列时延,不利于时延敏感的小流传输。

  • ECN 门限设置偏低时,转发设备使用较短的队列和少量缓存尽快触发来降低队列排队的时延, 满足小流对时延的需求。但是,过低的 ECN 门限会降低网络吞吐率,影响吞吐敏感的大流, 限制了大流的传输。

另一方面网络中如果同时部署了 PFC 和 ECN 功能时,我们希望 ECN 门限设置可以保证设备优先触发 ECN 功能,降低报文发送端的速率缓解拥塞情况,而非先触发 PFC 功能直接通知发送端停止发送报文。只有当 ECN 功能触发后未缓解拥塞,拥塞反而严重恶化时才触发 PFC 功能,此时通知发送端停止数据报文发送,直到拥塞缓解后再通知继续发送数据报文。 ECN 和 PFC 同时部署减缓拥塞时的作用顺序应如下图所示:


图 1-19 ECN 和 PFC 同时部署减缓拥塞示意图 ​

图示

由图 1-19 流程可知,当拥塞发生时,从转发设备发送 ECN 域标记为 11 的数据报文到报文发送端降速的过程中,发送端仍以原速率持续发送数据报文,这段时间内网络中的拥塞将进一步恶化,只有合理并动态设置 ECN 低门限,设备才能尽量避免 PFC 触发影响网络中的吞吐率。 基于以上原因,我们需要一种智能地实时 ECN 低门限控制功能,这种功能称为 AI ECN 功能。 实现原理

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


图 1-20 AI ECN 功能实现示意图 ​

图示

设备内的转发芯片会对当前流量的特征进行采集,比如队列缓存占用率,流量吞吐率,当前大小流占比等特征数据,然后将网络流量实时信息传递给 AI 业务组件。

AI ECN 功能启用后, AI 业务组件收到推送的流量状态信息后,将智能的对当前的流量特征进行判断,识别当前的网络流量场景是否符合已知的流量模型。

  • 如果该流量模型符合大量已知流量模型中的一种, AI 业务组件将根据已知流量模型推理出实时 ECN 门限最优值。

  • 如果该流量模型不符合已知流量模型, AI 组件将基于现网状态,在保障高带宽、低时延的前提下,对当前的 ECN 门限不断进行实时修正,最终计算出最优的 ECN 门限配置。

最后, AI 业务组件将最优 ECN 门限下发到设备转发芯片中,调整 ECN 门限。

AI ECN 能够根据流量特征和变化而实时调整 ECN 门限:

  • 当队列中小流占比高时,降低 ECN 触发门限,保证多数小流的低时延性。

  • 当队列中大流占比高时,提高 ECN 触发门限,保证多数大流的高吞吐性。

根据设备芯片和硬件能力, AI ECN 功能实现的模式有三类,采用不同的 AI ECN 功能模式,设备获取 ECN 门限的方式不同:

  • 网络中设备的 ECN 门限由分析器集中计算并传递给设备,实现拥塞通知功能,这种方式 AI ECN 功能由分析器完成计算分析,对设备本身硬件能力要求较低。

  • 设备本地实现的分布式 AI ECN 功能,设备智能地为队列设置最佳的 ECN 门限,这种方式 AI ECN 功能对设备硬件算力要求较高,可能消耗设备 CPU 资源。


  • 设备的神经网络功能实现的 AI ECN 功能,神经网络算法智能地为队列设置最佳的 ECN 门限, 需要设备硬件芯片支持该功能的算法。

6. IPCC ​

基本概念 ​

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

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

表 1-1 IPCC 和传统 ECN 技术对比

技术对比IPCC传统ECN
发送拥塞通知报文位置转发报文的网络设备报文的接收端
直接主动响应。由网络中出现拥塞点的间接被动响应。被标记的报文需传播整
报文拥塞的响应过程设备发送拥塞通知给报文发送端,拥塞
点快速触发,通知发送端降速
条转发路径抵达接收端后再由接收端
发送拥塞通知报文通知发送端降速
出现拥塞点的网络设备根据拥塞接口报文接收端如果持续收到ECN域取值
发送端降速的效果上队列长度和缓存占用,智能计算需要
发送的拥塞通知报文个数,精确控制发
送端降速
为11的报文时,将每隔一定时间周期发
送拥塞通知报文给报文发送端降速,降
速效果滞后于拥塞点的实际变化
应用场景仅对RoCEv2报文生效对于TCP、UDP等报文均能生效,适用
范围更广
硬件支持要求需要硬件芯片和驱动支持需要硬件芯片和驱动支持

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

实现原理 ​

由于 IPCC 功能仅对 RoCEv2 报文生效,下面先简单介绍 RoCEv2 报文的结构和报文的关键信息。 RoCEv2 和 InfiniBand 是目前主流的 RDMA 协议,但相较于 InfiniBand, RoCEv2 是基于以太网的 RDMA 协议。如图 1-21 所示, RoCEv2 是基于 UDP 协议封装的,其中 RoCEv2 报文的目的端口号固定为 4791。 RoCEv2 和 InfiniBand 主要变化在数据链路层和网络层, RoCEv2 报文传输层继承了 InfiniBand 报文中传输层的 Base Transport Header 和 Extended Transport Header 的结构和信息。


图 1-21 RoCEv2 与 InfiniBand 报文格式对比 ​

图示

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

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

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

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

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

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

  • 操作类型为 Send、 Write 和 Read 的 RoCEv2 报文也被称为 RoCEv2 数据报文。

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

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


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

  • 图 1-22 IPCC 工作原理图

图示

IPCC 的工作原理如图 1-22 所示。

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

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

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

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

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

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

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


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

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

1.4.4 传输层 — 流量调度和转发技术 ​

传输层的流量调度和转发技术,对应到无损网络,最重要的功能是实现负载均衡,良好的负载均衡能够有效的避免拥塞的产生,提升带宽有效利用率。

1. 负载均衡技术体系 ​

图示

负载均衡在不同的业务场景,随着流量模型,以及外部配套约束,不同的负载均衡技术,会产生不同的效果。其流量模型特点如下:

  • 低熵: AI 工作负载的流量数量和多样性要小得多,而且流量的模式通常是重复和可预测的。

  • 周期突发性:在时间维度上,流量通常在毫秒级的时间粒度上突发特性。

  • 大象流:对于每个突发,每条流量的强度可以达到网卡上限,也达到网络光互联带宽上限。

  1. 静态 ECMP

实现原理

设备上存在多条等价路由时,可以根据报文中的 N 元组信息(源 IP 地址、目的 IP 地址、源端口、 目的端口和 IP 协议号)配置逐流进行负载分担,可以通过命令行选择部分 N 元组参与 hash 计算。


在某些复杂的组网环境中,单一的负载分担算法不能满足负载分担的需求,可能出现设备负载分担不均匀的时候。这种情况下可以通过指定不同的负载分担算法来实现设备负载分担算法切换,保证负载分担均匀。

优势 ​

实现简单,应用成熟广泛,无需依赖端侧配合,仅需要交换机支持即可完成部署。

劣势 ​

Hash 效果依赖 N 元组样本,比如在智算中心场景,流量呈现低熵,突发,大象流的特征,容易出现 hash 不均,多条大象流挤占一个出端口,导致拥塞。

使用建议 ​

建议优先采用端网融合类技术进行负载均衡,无法使用时(如 GPU CCL 未开放接口),可使用本技术。

当 GPU 网卡可以支持多 QP,通过调整 hash 算法和 hash 因子,配合做 N 元组规划等调优方式时可采用静态 ECMP 的方案。

通常使用以下两种方式提升 hash 效果:

  • 多 QP

在无损网络中,首先需要网卡间使用 RDMA 协议建立 QP 会话,然后才传输数据报文,而同一对网卡之间,可以建立多个 QP,源目的 IP 不变,目的端口和协议号不变,但不同 QP 的源端口号变化的方式,增加了熵,提升 hash 效果;理论上不断提升 QP 会话数量,即可打破低熵的瓶颈,但此方式对网卡会形成性能压力,故 QP 会话也存在上限,业界大型 AI 智算网络,通常使用 4QP, 8QP, 16QP 等。”

  • N 元组规划

智算中心业务,流量低熵,但交换机具备输入 N 元组,提前预知该流量选择下一跳转发出口的能力。

Leaf 建议配置源 IP 地址 hash,比如 128 口交换机,下行 64 口接 GPU 网卡,可规划出来 64 个网卡 IP 地址,使得该网卡发出来的报文,在交换机上按照源 IP 地址 hash,能够 hash 均匀。 此方式可以通过网络管理员手工执行,也可以通过在控制器配置路径导航功能自动执行。

  • 调整 hash 算法 hash 因子

通过 ip load-sharing mode 命令行,调整 hash 算法, hash 因子等方式来改变 hash 结果,尝试提升负载均衡效果(不同产品支持的命令情况不同,具体相应产品的配置命令手册)。

3. LBN ​

产生背景 ​

静态 ECMP 的方式,经常出现多个入口的流量选择同一个下一跳,导致拥塞的情况,可以通过多 QP, N 元组规划,调整 hash 算法 hash 因子的方式调优。但实际智算场景下,还存在一类 GPU 采用 GPU 直出网卡的硬件方案,不支持多 QP,此时 ECMP 的调优显得比较困难,在此情况下, H3C 提出了 LBN (Load Balance Network,负载均衡网络)技术,来应对此类场景。

工作原理

LBN 技术仅支持应用在等价路由场景和二层以太网链路聚合场景,本文主要描述等价路由场景。 在等价路由场景, LBN 的工作原理如下:


  • (1) 用户将入端口加入 LBN 组后,设备为 LBN 组中每个入端口设置 LBN 值,也就是配置命令行中的 index 值,例如为 Port 1 设置 LBN 值为 0, Port2 设置 LBN 值为 1, Port3 设置 LBN 值为 2。

  • (2) LBN 为每一个入端口标识一个 LBN 值,交换芯片使用该 LBN 值作为 hash 因子计算,而不再使用 N 元组作为 hash 因子进行 hash 计算。也即是, LBN 是一个端口级别的低熵技术。

  • (3) LBN 会为每一个入物理端口的所有流量,计算出一个相同的出物理端口。

图 1-23 LBN 应用在等价路由场景

图示

LBN 的 LBN 值,和出端口之间的映射关系,将每个 LBN 组中入端口的 LBN 值依次对每个等价路由组内的出端口数量进行取余运算,形成每个入端口与出端口的映射关系。例如:

  • Port 1 的 LBN 值为 0,等价路由组 A 中存在 3 个出端口。 LBN 值 0 对 3 取余为 0,则 Port 1 对应的流量出端口是编号为 0 的 Port 4。

  • Port2 的 LBN 值为 1,等价路由组 A 中存在 3 个出端口。 LBN 值 1 对 3 取余为 1,则 Port 1 对应的流量出端口是编号为 1 的 Port 5。

  • Port3 的 LBN 值为 2,等价路由组 A 中存在 3 个出端口。 LBN 值 2 对 3 取余为 2,则 Port 1 对应的流量出端口是编号为 2 的 Port 6。

  • 而出端口的编号 0,1,2 的编号值,则是出端口的对端 IP 地址的大小排序,最小的是编号 0,第二小的是编号 1,以此类推。

优势 ​

实现简单,不需要网卡和 GPU CCL 配合,是一种解耦的技术。

劣势

LBN 本身使用的是入端口的 LBN 值作为 hash key,不使用报文的流量 N 元组作为 hash key,更加低熵,在 1:1 收敛比的环境,能保障 Leaf-Spine 上行 hash 均匀,但会加剧 Spine-Leaf 下行的拥塞概率。

LBN 技术的故障倒换,是重新进行上述的入端口 LBN 值和出端口的映射关系计算,一个出端口故障后,会导致 2 个入端口的流量映射到一个出端口上,加剧拥塞概率。为了应对故障场景的拥塞问


题, H3C 开发了 LBN 增强功能,对故障端口涉及到的流量,重新 HASH 到没有故障的端口转发, 消减端口故障后拥塞概率。

使用建议 ​

建议优先采用端网融合类技术进行负载均衡,无法使用时(如 GPU CCL 未开放接口),可使用本技术。

LBN 技术主要应用在对接 GPU 直出网卡,且封闭的 GPU 场景。

在 Spine-Leaf 下行存在多路径 ECMP 选路的场景下, LBN 技术可解决多路径选路 hash 计划问题。 建议在 128 卡以下小型组网的场景使用,规避在大型组网下, Spine-Leaf 下行拥塞较为频繁的问题。

  1. UDF Dest QP

实现原理 ​

AI 智算流量 ECMP 转发,可以根据报文中的 N 元组信息(源 IP 地址、目的 IP 地址、源端口、目的端口和 IP 协议号)配置逐流进行负载分担。而智算流量特征本身是低熵的特性,可以通过多 QP 会话增加熵的方式提升负载均衡效果,但是受限网卡性能,通常在 4QP, 8QP, 16QP 左右,依然存在低熵负载不佳的可能性。

针对这种情况, H3C 开发了 UDF Dest QP 负载均衡技术,其原理是在传统的 5 元组的基础上再增加一个 hash 因子,来提升 hash 效果。

如图 1-24 所示, RoCEv2 的报文格式如下,其源目的 IP 在 IP Header,源目的端口号在 UDP Header, IB 头在 UDP 头后,其中有 24 bit 的 Dest QP 字段,随着网卡开启多 QP,除了源端口号在变化以外,还产生了 Dest QP 字段的变化,也可以作为一个 hash key,丰富 hash 算法的熵,进一步提升 hash 效果。

图 1-24 RoCEv2 报文格式

图示

优势 ​

实现简单,只需要网卡支持多 QP 即可,无需更深入的配合,交换机网络和计算端侧可实现解耦部署的同时,实现一定程度的 hash 效果进一步提升。

劣势 ​

需要网卡支持多 QP,只是在 ECMP 的基础上增加熵,缓解 ECMP 的问题,一定程度提升 hash 效果,但无法彻底规避 ECMP 逐流的多路径 hash 计划问题。

使用建议


建议优先采用端网融合类技术进行负载均衡,无法使用时(如 GPU CCL 未开放接口),可使用本技术。 GPU 使用标准 RDMA 网卡(比如 CX7),支持多 QP。

尽量在网卡性能范围内,开启尽量多的 QP 会话。

  1. 路径导航

静态 ECMP 通过 N 元组规划的方式进行调优,此方式依赖手工执行,且只能针对一台交换机局部调优,无法做到全局调优。而路径导航采用了端网融合思路,通过智能检测全网路径情况,对业务流量进行路径规划,是一种端网融合的负载均衡技术。

工作原理

  • (1) SDN 控制器从集成通信库获取训练任务流量通信关系,也就是网络中会产生哪些流量。

  • (2) SDN 控制从交换机获取网络 topo 信息,也就是网络中的所有路径 Path。

  • (3) SDN 结合上述信息,集中式算路,目标是构建流量不相交路径 Path,尽量避免流量选择重合的链路。

路径导航主要包含两种实现方式:

  • 方式 1:网侧预选 — Traffic Matrix

  • SDN 控制器对交换机下发 Traffic Matrix 流表,交换机对数据报文,优先按照 Traffic Matrix 流转发,确保流量转发路径符合不相交算路目标;

如果出现网络故障, Traffic Matrix 流表出现下一跳不可达的情况,流表失效,交换机还自动对该流量切换至 ECMP FIB 表转发。

  • 该方案消耗交换机的 ACL 资源,且 Traffic Matrix 流表的底层 ACL 刷新较慢,故障倒换丢包较多。

• 方式 2:端侧调度 — 源端口号规划 SDN 控制器通知 CCL,按照符合要求的源端口号创建 QP 会话,后续流量封装携带该源端口号转发,交换机按照源端口号 hash,将流量按照控制器期待的转发路径 Path 进行转发; 该方案需要 CCL 配合,网卡支持被 CCL 调用,进行源端口号规划。

如果出现网络故障,交换机 ECMP 机制可确保自动冗余保护,但有一定的概率产生局部拥塞, 此时可以再次对网络进行重优化, CCL 调用网卡接口,进行源端口号重新编辑修改的方式, 让流量避开拥塞点。

目前主流的网卡,都提供 API 接口,支持被 CCL 调用编辑,修改源端口号,且修改源端口号, 只会产生极个别的少量丢包,对 AI 训练任务的影响极小。


图 1-25 路径导航工作原理 ​

图示

优势 ​

实现端网融合,基于全局视角统一规划路径,避免局部负载分担不均问题,端侧调度方案不占用设备 ACL 资源,降低交换机设备载荷,整体负载均衡效果好。

劣势 ​

依赖端侧能力,要求 GPU CCL 开放接口和控制器进行适配,且网卡支持被 CCL 调用, QP 会话创建可指定,可修改源端口的能力,属于一种网络和计算端耦合联动的方案。

使用建议 ​

建议优先采用路径导航技术进行负载均衡。

首选端侧调度 — 源端口规划的方式,此方式具备网络故障丢包少,可快速实现故障后重优化的优势。

  1. DLB 的逐流模式

产生背景 ​

传统的以太网链路聚合、等价路由采用逐流负载分担机制。在该机制下,设备会根据报文的 N 元组等特征,通过 HASH 算法为数据流选择一个下一跳。对于特征相同的流量,哈希算法会选择相同的等价等价路由下一跳或聚合成员链路。这种方法实现了不同数据流在不同链路上的负载分担,也避免了报文乱序。

这种方式选择的下一跳是固定的,不能根据实际的转发情况和链路负载情况变化,因此也被称为静态负载分担。它的缺点如下:

  • 没有考虑负载分担链路中各成员链路的利用率,从而会出现成员链路之间的负载分担不均衡, 尤其当大数据流出现时会加剧所选中成员链路的拥塞甚至引起丢包。

  • 在多跳路径上容易出现 HASH 极化,导致报文在多次转发后负载不均匀。


图 1-26 流量在等价路由的多条路径上实现负载分担 ​

图示

DLB (Dynamic load balance,动态负载均衡)的出现弥补了静态负载分担的缺陷。它在芯片引入了硬件流表(FlowSet),可以记录某条流的状态,结合等价路径的状态信息,可以实现根据实时拥塞状态的等价路径成员的动态选择,优先选择负载较轻的链路进行转发。

工作原理 ​

DLB 通过引入时间戳、实时负载度量(端口带宽负载、队列大小)因子,在时间、带宽空间两个维度优化了负载均衡效果,提供了动态、智能的 HASH 机制。

等价路由和聚合组通过配置动态负载分担模式,实现 DLB 功能。配置动态负载分担模式后,设备可以根据链路的负载分担情况,优先选择负载最轻的路径进行转发。动态负载分担有三种模式(本功能的支持情况请以设备的实际情况为准),其中逐流模式有以下两种:

  • Eligibility 模式: Eligibility 模式下,同一个数据流中时间间隔小于等于 flowset-inactive-time 的报文组成一个 FlowSet。设备基于 FlowSet 选取当前负载较轻的成员链路进行转发,同一 FlowSet 中的数据包的转发链路相同。具体过程如下:

  • a. 具有一定特征的流量第一次进入设备转发,则被认为是新的流,设备为之创建 Flowset; 同时为之设置 flowset-inactive-time 老化计时器。

  • b. 设备在 flowset-inactive-time 周期内,计算出当前等价路由组中负载较轻的路径,转发该流量,在该周期内,具有相同特征的流量会使用相同的转发路径,并实时刷新 flowset-inactive-time 老化计时器,维持本 Flowset 为有效状态(会话保持)。

  • c. 超过 flowset-inactive-time 老化时间周期,如若未有流量维持该 Flowset 有效,则该 Flowset 记录被老化,即使后续再有该 Flowset 相同特征的流量到来,设备认为是一个新的流,创建新的 Flowset,重新 HASH 到负载较轻的路径。


图 1-27 Eligibility 模式 ​

图示

  • 固定模式(Fixed 模式):

  • 固定模式会为数据流的第一个数据包选择负载较轻的路径,同一个数据流的后续数据包使用第一个数据包的转发路径。

  • 图 1-28 固定模式(Fixed 模式)

图示

关于等价路由模式和聚合动态负载分担的详细介绍,请参见产品配套的“三层技术 -IP 路由”中的 “ IP 路由基础”,以及“二层技术 - 以太网交换”中的“以太网链路聚合”配置和命令手册。

优势 ​

实现简单,无需依赖端侧配合,仅需要交换机支持即可完成部署,和网卡配合使用负载均衡效果极好。

劣势 ​

经过测试和部分项目商用表明, DLB 的逐流模式,不论是 Eligible 还是 Fixed 模式, hash 效果均不算太理想,商用案例也较少;

Eligible 模式采用子流的方式调度,父流切割为子流依赖时间间隔 t 参数,该参数是一次性配置,而流量的实际间隔是一个比较复杂因素,动态变化, t 参数可能导致一个连续的流量被切割开走不同的路径,导致报文乱序,引发网卡的判丢重传,进而影响训练性能。

使用建议 ​

建议优先采用端网融合类技术进行负载均衡,无法使用时(如 GPU CCL 未开放接口),可使用本技术。


DLB 的逐包 Spray 喷洒模式 ​

实现原理 ​

除了 DLB 的逐流模式, DLB 还支持逐包 Spray 喷洒模式。

Spray 模式采用逐包负载分担机制,设备基于数据包选取当前等价路由组中负载最轻的路径进行转发。同一个数据流的多个数据包的转发链路可能不同,因此接收端可能会出现报文乱序的问题,在该模式下需确保接收端支持报文乱序重组的功能。

图 1-29 Spray 模式

图示

优势 ​

和网卡配合使用负载均衡效果极好。

劣势 ​

同一条数据数据流,被切割为数据包粒度调度,不同的数据包可能走不同的路径,导致到达目的地的时间不一致,导致了报文乱序,需要网卡支持 AR 乱序重排功能;

ECMP, ECMP 增强的逐流负载均衡技术,是按照数据流的粒度在调度,也就是同一条数据流,最后结果是走同一个路径 Path,不会产生乱序,同时还具备以下优点:

利于可视化运维,流级别展示路径 Path,以及时延,丢包,拥塞程度等指标采集;

不会导致拥塞反压,丢包重传等问题扩散化;网络设备节点,或者部分链路故障导致的网络内部带宽资源减少,低于计算端侧通信要求,就会产生拥塞,或者网络出现模块质量不稳定, CRC 丢包等问题,导致数据包重传,这些都只会影响经过事故点的流量,而不会扩散影响其他业务数据流。 以上逐流的优点,反过来均是逐包方案的劣势:

不利于运维,同一条流量的数据包转发路径不同,无法获得流级别的时延,丢包,拥塞指标,或者网络报告时延劣化,丢包,拥塞等告警,不容易映射到具体被影响的流;

拥塞反压,丢包重传的扩散化,各种原因导致的一个端口拥塞,因为该端口可能所有的流量都有报文经过, ECN 和 PFC 可能影响所有的流量,导致拥塞扩散化,所有的发送端网卡均被压制,导致利用率扩散化的下降。或者是网络出现模块质量不稳定, CRC 丢包等问题,导致经过该点的所有流量均出现丢包,网卡扩散性大面积发起重传,影响整个网络的吞吐性能。

使用建议 ​

建议优先采用端网融合类技术进行负载均衡,无法使用时(如 GPU CCL 未开放接口),可使用本技术。

推荐在 GPU 网卡支持 AR 乱序重排,且网络有良好的运维体系,能较好的维持网络 topo 稳定性, 及时发现网络拥塞,丢包等场景下使用。


1.5 无损网络典型应用场景 ​

目前 RoCE 网络主要应用于智算中心和高性能计算中心、金融存储网络环境中的参数网络和高性能存储网络。

1.5.1 人工智能计算中心的参数网和存储网 ​

在人工智能计算中心, RoCE 网络分为参数网络和高性能存储网络两种类型:

  • 参数网络:

  • 参数网络是业务区的 RoCE 网络,用于为 GPU 服务器、高性能计算服务器之间提供高带宽无丢包的互联能力,其流量特征主要为:

主要是指智算中心内连接 GPU 的参数网,其流量特征如下:

  • 低熵: AI 工作负载的流量数量和多样性要小得多,而且流量的模式通常是重复和可预测的。

  • 周期突发性:在时间维度上,流量通常在毫秒级的时间粒度上突发特性,呈现周期性可预测规律。

  • 大象流:对于每个突发,每条流量的强度可以达到网卡上限,也达到网络光互联带宽上限。

  • 高性能存储网络:

高性能存储区的 RoCE 网络用于为 GPU 服务器、高性能计算服务器和高性能存储之间提供高带宽无丢包的互联能力。其流量特征为 GPU 服务器和存储节点之间大量东西向通信流量,而业务网元和存储节点数量 N: 1,在整个 RoCE 存储网络中普遍存在多打一的情况。

1.5.2 传统通算数据中心的高性能存储网络 ​

传统虚拟化数据中心,云计算数据中心场景,为各个行业,互联网提供互联网服务,其中,诞生的网元数据的存储和读取,需要高性能存储区的 RoCE 网络用于为业务服务器和高性能存储之间提供高带宽无丢包的互联能力。

其流程特征为:

业务网元和存储节点之间大量东西向通信流量,而业务网元和存储节点数量 N: 1,在整个 RoCE 存储网络中普遍存在多对一的情况。