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 传输层之上 | 驱动/内核 | 驱动/交换设备 |
| 拆分粒度 | 消息/字节段 | 流 | 流/连接 |
| 乱序风险 | 高(需重组) | 低(同流同链路) | 低 |
| 故障切换速度 | 秒级(需重传) | 毫秒级 | 毫秒级 |
| 适用场景 | 大消息高吞吐 | 多流并发 | 高可用 |
4.3 负载均衡策略与算法
实际工程中,负载均衡并非简单轮询,而是基于链路质量动态调整。常用算法包括:
- 加权轮询(Weighted Round Robin):为每条链路配置静态权重,适合链路规格一致的场景。
- 最小负载优先(Least Load):实时监控各链路队列深度(QD)和带宽利用率,选择当前负载最低的链路发送。
- 基于时延的调度(Latency-aware):通过 InfiniBand 的 SA (Subnet Administrator) 路径查询或 RoCE 的 ECN 标记,感知路径拥塞程度,将延迟敏感流量调度到低时延链路。
- 基于丢包率的反馈调度:跟踪各链路的重传计数(如 ibv_query_qp 的 retry count),对丢包率高的链路自动降权。
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 Keepalive | TCP 超时通常 1~3 秒,RDMA 早已超时断开 | 使用 RDMA CM 的 CM Keepalive 或驱动级链路监控 |
| 忽略接收端重组缓冲 | 大消息拆分后乱序严重,接收端内存溢出 | 合理设置接收端 WR (Work Request) 队列深度和 MSG 大小 |
| 未考虑 PFC 死锁 | 多链路同时拥塞时可能触发 PFC 反压,导致所有链路暂停 | 启用 ECN + DCQCN 或配置合理的 PFC 阈值 |
xmit_hash_policy,导致所有 RDMA 流量哈希到同一端口,另一端口完全空闲。修改为 xmit_hash_policy=layer3+4 后,流量均匀分布,聚合吞吐从 100G 提升至 190G。这说明哈希策略的选择直接影响多链路利用率。