网络工程师的 AI 之路：理解 Flow、Flowlet 和基于包的 LB
2025年4月21日 星期一
网络工程师的 AI 之路：理解 Flow、Flowlet 和基于包的负载均衡
尽管 BGP 支持传统的基于 Flow 的 Layer 3 等价多路径 (ECMP) 流量负载均衡方法，但它并不适合基于 RoCEv2 的 AI 后端网络。这是因为 GPU 到 GPU 的通信会产生大量的“大象流”（elephant flows），而支持 RDMA 的网卡（NIC）会以线路速率传输这些流量。这些流量很容易导致后端网络拥塞。
在 ECMP 中，单个 Flow 的所有数据包都遵循相同的路径。如果该路径变得拥塞，ECMP 不会进行调整或重新路由流量。这导致网络中带宽使用不均匀。一些链路变得过载，而另一些链路则保持空闲。在 AI 工作负载中，当多个高带宽 Flow 同时发生时，这种不平衡会降低性能。
深度学习模型严重依赖于 collective operations，如 all-reduce、all-gather 和 broadcast。 这些操作在 GPU 之间产生密集的流量模式，通常速度达到太比特每秒。 如果这些 Flow 没有均匀分布，则单个拥塞路径可能会减慢整个训练作业。
本章介绍两种替代传统 Flow-Based Layer 3 ECMP 的负载均衡方法：1) 采用自适应路由的基于 Flowlet 的负载均衡，以及 2) 采用包喷射（Packet Spraying）的基于包的负载均衡。 两者都旨在改善基于 RoCEv2 的 AI 后端网络中的流量分配，因为在这些网络中，传统的基于 Flow 的路由通常会导致拥塞和链路利用率不足。 这些高级方法旨在更有效地处理 AI 工作负载的独特流量模式。
RDMA WRITE 操作
在我们探索负载均衡解决方案之前，让我们首先通过一个简化的示例来了解 RDMA WRITE 内存复制操作的工作原理。 在图 12-1 中，我们有两台 GPU 服务器：Host 1 和 Host 2，每台服务器都配有一个 GPU。 此时，内存已经分配和注册，并且队列对 (QP) 已经在双方创建，因此可以开始数据传输。
在 Host 1 的 GPU-0 上，梯度存储在以绿色、橙色和蓝色突出显示的内存区域中。 每个彩色部分代表本地内存的一部分，这些内存将被写入 Host 2 上的 GPU-0。 为了传输数据，Host 1 上的 RDMA NIC 将写入操作拆分为三个 flowlet（绿色、橙色和蓝色）。 不是将整个数据块作为单个连续流发送，而是将每个 flowlet 视为同一 RDMA Write 操作的一个片段。
RDMA Write First
第一个消息在其有效负载中携带 RDMA 扩展传输标头 (RETH)。 此标头告诉接收 RDMA NIC 应该将传入数据写入远程内存中的哪个位置。 在我们的示例中，来自 Host 1 上的 GPU-0 的内存块 1B 的数据被写入 Host 2 上的 GPU-0 的内存块 2C。
RETH 包含 R_Key，它授予写入远程内存区域的权限。 它还包括正在传输的数据的长度和 Host 2 上目标内存位置的虚拟地址。
InfiniBand 基本传输标头 (IBTH) 中的操作码设置为 RDMA Write First，表明这是序列中的第一个消息。 IBTH 还描述了分区键（接口标识符）、目标队列对号和数据包序列号 (PSN)，这些信息有助于确保数据包按正确的顺序处理。
当第一个数据包到达 Host 2 时，RDMA NIC 使用 RETH 标头中的虚拟地址信息将有效负载直接写入内存块 2C。
RDMA Write Middle
第二个消息具有操作码 RDMA Write Middle 和 PSN 2，这告诉接收器此数据包在 PSN 1 的第一个数据包之后到达。 此 Flowlet 的有效负载紧接在前一个块之后写入 Host 2 上的内存块 2D 中。 RDMA NIC 确保基于 PSN 维护顺序，并且由于来自第一个数据包的原始偏移量，它确切地知道将数据放置在何处。
RDMA Write Last
第三个消息具有操作码 RDMA Write Last，表明这是序列中的最后一个消息。 使用 PSN 3，它直接跟随在 PSN 2 之后。 此数据包中的有效负载写入内存块 2E，该内存块紧接在 2D 之后。
在多数据包 RDMA Write 操作中，每个 Flowlet 代表从源 GPU 传输到目标 GPU 的连续数据块。 数据包中的数据必须按正确的顺序到达，因为只有第一个数据包在 RDMA 扩展传输标头 (RETH) 中包含完整的寻址信息。 此标头告诉接收器应该将数据写入内存中的哪个位置。
标记为 RDMA Write Middle 和 RDMA Write Last 的数据包依赖于此信息，并且必须遵循数据包序列号 (PSN) 定义的顺序。 如果数据包乱序传送，则接收 RDMA NIC 无法立即处理它们。 相反，它必须将它们保存在内存中并等待丢失的较早数据包到达。 此缓冲会增加内存使用量和处理开销。 在高速环境中，这可能会导致性能下降甚至数据包丢失，尤其是在重负载下缓冲区已满时。
采用 Layer 3 ECMP 的基于 Flow 的负载均衡
图 12-4 描述了在 AI fabric 后端网络中使用基于 Flow 的负载均衡时出现的问题。 在我们的示例中，我们有四个主机，每个主机都配备了两个 GPU：GPU-1 和 GPU-2。 连接到 GPU-1 的 RDMA NIC 连接到交换机 Rail-1，连接到 GPU-2 的 RDMA NIC 连接到 Rail-2。 Rail-1 和 Rail-2 上的 NIC 之间的流量通过 Spine-1 或 Spine-2 转发。
我们使用基本的数据并行化策略，其中训练数据集被分成小批量并分布在所有八个 GPU 上。 为了简化示例，图 12-4 仅显示从主机 1、2 和 3 上的 GPU-1 到主机 4 上的 GPU-2 的 all-reduce 梯度同步 Flow。 在实际训练中，会在所有 GPU 之间执行全网状 all-reduce 操作。
首先，最左边三个主机上的 GPU-1 开始 RDMA 进程，以将其内存中的数据复制到主机 4 上的 GPU-2 的内存中。 这些 GPU-1 都连接到 Rail-1。 RDMA NIC 没有发送一个大型 Flow，而是将数据分成 flowlet，即来自较大传输的小数据突发。 这些 flowlet 到达 Rail-1 交换机，但不幸的是，5 元组 L3 ECMP 哈希算法为所有三个 Flow 选择相同的上行链路。 由于交换机无法以线速转发所有数据，因此它将一些数据包存储在缓冲区中，从而导致拥塞。 类似的拥塞也可能发生在 spine 交换机上。 如第 12 章前面所述，出口缓冲区溢出可能会触发 ECN（显式拥塞通知）和 PFC（优先级流控制）机制，以防止数据包丢失。
采用自适应路由的基于 Flowlet 的负载均衡
自适应路由是一种动态方法，可主动监控链路利用率并实时响应网络拥塞。 在图 12-5 中，与之前的示例一样，5 元组哈希算法最初为所有 flowlet 选择相同的上行链路。 但是，一旦 Rail-1 和 Spine-1 之间的交换机间链路的利用率超过阈值，自适应路由机制就会检测到负载增加，并开始将一些 flowlet 重定向到另一条不太拥塞的路径，即通过 Spine-2。
通过在多条路径上分配 flowlet，自适应路由有助于减少缓冲区积压并避免潜在的数据包丢失。 这不仅提高了 fabric 中的链路利用率，还有助于为对时间敏感的操作（如基于 RDMA 的梯度同步）保持一致的吞吐量。 在 AI 工作负载中，延迟或数据包丢失可能会减慢甚至中断训练，自适应路由在维护系统性能方面起着关键作用。
采用包喷射（Packet Spraying）的基于包的负载均衡
包喷射是一种负载均衡方法，其中来自同一 Flow 的各个数据包分布在多个等价路径上。 这样做的目的是均匀地使用所有可用链路，并减少任何单条路径上发生拥塞的机会。
但是，在基于 RoCEv2 的 AI 后端网络中，包喷射带来了一些严峻的挑战。 RoCEv2 依赖于无损且按顺序的数据包传送。 当数据包在不同的路径上喷射时，它们可能会乱序到达目的地。 这种数据包重新排序会扰乱 RDMA 操作并降低 GPU 到 GPU 通信的整体性能。
RDMA Write Only
从 ConnectX-5 开始，NVIDIA 的 RDMA NIC 支持 RDMA Write Only 操作，其中每个数据包中都包含一个 RETH 标头。 图 12-7 显示了 RDMA NIC 如何在每个消息的 IBTH 标头中使用 OpCode: RDMA Write Only。 使用此 OpCode，每个消息还包括一个 RETH 标头，其中包含有关为有效负载中携带的数据保留的目标内存块的信息。 这允许接收 RDMA NIC 将数据直接写入正确的内存位置，而无需依赖传输序列中的先前消息。
当与使用包喷射（Packet Spraying）的基于包的负载均衡结合使用时，RDMA Write Only 会带来显着的好处。 由于每个数据包都是独立的并且包含完整的内存寻址信息，因此网络 fabric 可以通过不同的路径转发各个数据包，而无需担心数据包排序或上下文丢失。 这实现了真正的 flowlet 甚至每个数据包的负载均衡，这有助于更均匀地在可用链路上传播流量，避免热点并减少排队延迟。
在 Cisco Nexus 交换机上配置 Per-Packet 负载均衡
在撰写本文时，从 NX-OS Release 10.5(1)F 开始，Cisco Nexus 9000 Series Cloud Scale 交换机（9300-FX3、GX、GX2 和 HX-TOR）支持动态负载均衡 (DLB)——包括基于 flowlet 和 per-packet（数据包喷射）的负载均衡。 DLB 在 IP 路由和 VXLAN fabric 中，对于单播 IPv4 和 IPv6 流量的 Layer 3 物理接口上受支持。
启用 DLB 后，出口 QoS 和访问策略不适用于使用 DLB 的 Flow。 同样，在出口接口上配置的 TX SPAN 不会捕获 DLB 流量。 有关硬件和软件支持的详细信息，请参阅 Cisco 的官方文档。
示例 12-1 显示了启用 per-packet 负载均衡的基本配置：
switch(config)# hardware profile dlb
switch(config-dlb)# dlb-interface Eth1/1
switch(config-dlb)# dlb-interface Eth1/2
switch(config-dlb)# mac-address aa:bb:cc:dd:ee:ff
switch(config-dlb)# mode per-packet
示例 12-1: 配置 Per-Packet 负载均衡 包喷射.
注意： DLB MAC 充当虚拟下一跳 MAC 地址。 它不与任何特定的物理接口绑定。 这会将 MAC 与物理路径分离，从而允许交换机为每个数据包选择不同的出口端口。 必须在所有参与交换机上配置相同的 DLB MAC 地址。 如果您未指定 DLB MAC，则应用默认 DLB MAC 00:CC:CC:CC:CC:CC。
Posted by Toni Pasanen at 13:44 
Email ThisBlogThis!Share to XShare to FacebookShare to Pinterest
Labels: Flowlet, Packet Spraying, RDMA Write
Location: 80110 Joensuu, Suomi
No comments:
Post a Comment
Older Post Home Subscribe to: Post Comments (Atom)