4. 多链路加速原理

4.1 从单链路到多链路:为什么要“加速”

RDMA 单链路通信在带宽、可靠性与故障冗余方面存在天然上限。以 100Gbps 网卡为例,单条物理链路即使跑满,也无法突破端口速率;一旦链路抖动或交换机端口故障,上层应用立刻感知到重传与断流。多链路加速的核心思想是:将多条物理链路抽象为一个逻辑资源池,通过并行传输、动态调度与快速切换,让应用“感觉”到一条更宽、更稳、更快的虚拟链路。

多链路加速并非简单地把数据拆开扔到多条链路上,而是需要解决三个关键问题:

  • 如何拆分:按包、按流还是按字节段拆分,直接影响接收端重组复杂度和乱序程度。
  • 如何调度:根据链路实时带宽、时延、丢包率决定每条链路的发送比例。
  • 如何切换:当某条链路故障时,如何在毫秒级完成流量迁移且不中断 RDMA 连接。
关键认知:多链路加速的目标不是“每条链路都跑满”,而是“整体吞吐最高、时延最低、故障影响最小”。有时故意让某条链路留有余量,是为了给故障转移预留切换空间。

4.2 三种核心技术路径

4.2.1 多路径传输(MP-RDMA)

多路径传输在 RDMA 层之上建立多个子流(Sub-flow),每个子流对应一条物理链路或一条网络路径。发送端将一个大消息(Message)切分为多个 RDMA Send/Write 操作,分别通过不同子流发出。接收端依据消息序号(Message Sequence Number, MSN)重组。MP-RDMA 的核心优势是带宽聚合:单条 100G 链路无法满足的吞吐需求,可以通过 2 条 100G 链路聚合为接近 200G 的聚合带宽。

4.2.2 链路聚合(Link Bonding/Teaming)

链路聚合在网卡驱动或交换机层面实现,将多块物理网卡绑定为一个逻辑网卡(如 bond0)。RDMA 应用看到的仍是单一端口。链路聚合的粒度通常是流级别:同一 TCP/UDP 流或同一 RDMA QP 的所有报文固定走同一条物理链路,避免乱序。常见的哈希因子包括源/目的 IP、源/目的端口、L3/L4 协议号等。

4.2.3 负载均衡与故障转移(Failover)

负载均衡是动态调度策略,故障转移是状态切换机制。两者通常配合实现:负载均衡器持续监控各链路健康状态(通过 InfiniBand 的 MAD (Management Datagram) 查询或 RoCE 的 DCQCN 反馈),当某条链路出现连续丢包或信号降级时,立即将其权重降为 0,并将流量重新哈希到剩余链路。

实现层次对比:
维度MP-RDMA链路聚合负载均衡+故障转移
实现位置RDMA 传输层之上驱动/内核驱动/交换设备
拆分粒度消息/字节段流流/连接
乱序风险高(需重组)低(同流同链路)低
故障切换速度秒级(需重传)毫秒级毫秒级
适用场景大消息高吞吐多流并发高可用
多链路加速原理总览 发送端应用 大消息/多流 拆分与调度层 MP-RDMA 切分 哈希/权重分配 健康状态监控 物理链路 A 100Gbps | 时延 5μs 物理链路 B 100Gbps | 时延 8μs 物理链路 C 100Gbps | 时延 12μs ⚠ 链路 B 故障 接收端应用 重组/去重 重组与确认层 MSN 排序 ACK/NACK 生成 重传请求 断流 故障转移:流量迁移至 A + C 链路状态反馈(时延/丢包率/带宽)→ 动态调整权重 核心机制说明 链路 A:正常承载 50% 流量 链路 B:故障前承载 30%,故障后权重归零 链路 C:故障前承载 20%,故障后提升至 50% → 负载均衡器根据实时 RTT/丢包率调整哈希权重 → 故障转移触发条件:连续 3 次 Keepalive 超时或 BER 超阈值 → 切换时间目标:< 50ms(RoCE v2 环境下)

4.3 负载均衡策略与算法

实际工程中,负载均衡并非简单轮询,而是基于链路质量动态调整。常用算法包括:

  1. 加权轮询(Weighted Round Robin):为每条链路配置静态权重,适合链路规格一致的场景。
  2. 最小负载优先(Least Load):实时监控各链路队列深度(QD)和带宽利用率,选择当前负载最低的链路发送。
  3. 基于时延的调度(Latency-aware):通过 InfiniBand 的 SA (Subnet Administrator) 路径查询或 RoCE 的 ECN 标记,感知路径拥塞程度,将延迟敏感流量调度到低时延链路。
  4. 基于丢包率的反馈调度:跟踪各链路的重传计数(如 ibv_query_qp 的 retry count),对丢包率高的链路自动降权。
重要提醒:RDMA 是有损网络下的尽力传输,但多链路加速不能依赖 TCP 式的重传恢复。RDMA 的重传由硬件完成(Go-Back-N),如果某条链路持续丢包,会导致整个 QP 进入错误状态(IBV_QPS_ERR),所有链路都被迫中断。因此,故障转移必须在硬件重传超时(Timeout)触发之前完成,通常要求切换时间小于重传超时值(典型值 100ms~1s)。

4.4 案例:双口 RoCE 网卡的多链路故障转移

某分布式存储集群使用 Mellanox ConnectX-6 双口 100G 网卡,两个端口分别接入不同的 TOR 交换机。配置如下:

# 创建 bonding 设备
$ sudo ip link add bond0 type bond mode 802.3ad miimon 100
$ sudo ip link set enp175s0f0 master bond0
$ sudo ip link set enp175s0f1 master bond0
$ sudo ip link set bond0 up

# 查看 bonding 状态
$ cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v5.4.0
Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer3+4 (1)
MII Status: up
Active Aggregator: 1
Slave Interface: enp175s0f0
MII Status: up
Speed: 100000 Mbps
Slave Interface: enp175s0f1
MII Status: up
Speed: 100000 Mbps

当拔掉端口 1 的网线时,系统在 100ms 内检测到链路 down,自动将流量切换到端口 2。RDMA 应用(如 NVMe-oF)感知不到链路切换,因为 bonding 驱动在 L2 层完成了 MAC 地址迁移。但需要注意:bonding 模式必须为 active-backup 或 802.3ad,且 RDMA 网卡需要开启 RoCE 的 bonding 支持(通常需要驱动参数 roce_mode=2)。

4.5 常见误区与复盘

误区后果正确做法
所有链路配置相同权重链路质量差异导致慢链路拖累整体吞吐根据实测带宽/时延设置差异化权重
故障转移依赖 TCP KeepaliveTCP 超时通常 1~3 秒,RDMA 早已超时断开使用 RDMA CM 的 CM Keepalive 或驱动级链路监控
忽略接收端重组缓冲大消息拆分后乱序严重,接收端内存溢出合理设置接收端 WR (Work Request) 队列深度和 MSG 大小
未考虑 PFC 死锁多链路同时拥塞时可能触发 PFC 反压,导致所有链路暂停启用 ECN + DCQCN 或配置合理的 PFC 阈值
复盘要点:一次生产环境中,工程师将两条链路绑定为 bond4(802.3ad),但未配置 xmit_hash_policy,导致所有 RDMA 流量哈希到同一端口,另一端口完全空闲。修改为 xmit_hash_policy=layer3+4 后,流量均匀分布,聚合吞吐从 100G 提升至 190G。这说明哈希策略的选择直接影响多链路利用率。