4、多路径路由概念：为什么需要多路径、多路径与负载均衡的关系、多路径的挑战

各位好，我是老张。今天咱们聊聊多路径路由。说实话，这个主题在InfiniBand网络里特别关键。我见过不少刚入行的工程师，一听到「多路径」就觉得是锦上添花的功能。其实不然，它直接决定了你的集群能不能跑满带宽。

4.1 为什么需要多路径？

先问个问题：单路径有什么不好？

你想想看，一个典型的HPC集群，动辄几百上千个节点。如果每个节点之间只有一条路可走，那会发生什么？

• 单点瓶颈：某条链路一旦被占满，后面的流量就得排队。我见过一个案例，某研究所的集群，就因为一条链路打满，整个作业的MPI通信延迟飙升了3倍。
• 故障无备份：链路断了，节点就失联了。这在生产环境里是不可接受的。
• 带宽浪费：明明有那么多空闲链路，流量却只走一条，你说亏不亏？

说白了，单路径就像一条单车道的高速公路。早晚高峰，堵到你怀疑人生。

多路径的核心价值，就是让流量分散到多条物理链路上。我个人的习惯是，只要集群规模超过32个节点，就一定要启用多路径。否则，你就是在浪费硬件资源。

4.2 多路径与负载均衡的关系

很多人把多路径和负载均衡混为一谈。其实它们的关系，更像是「手段」和「目的」。

多路径是手段：它提供了多条可选的物理路径。

负载均衡是目的：我们希望流量在这些路径上均匀分布，避免某条路径过载。

我在项目中遇到过一种情况：明明启用了多路径，但流量还是集中在某几条链路上。后来一查，是哈希算法选得不对。默认的L4哈希，对于MPI这种长流，效果很差。

这里我列一下常见的负载均衡策略：

策略	原理	适用场景	我的评价
基于流的哈希	对五元组做哈希，决定路径	TCP/IP流量	简单，但容易哈希冲突
基于包的轮询	每个包轮流走不同路径	短消息通信	乱序风险高，慎用
自适应路由	根据实时拥塞动态选路	HPC/MPI	效果好，但实现复杂
加权分发	根据链路带宽分配权重	异构链路	适合混合速率场景

我个人比较推荐自适应路由。虽然它需要交换机支持，但效果确实好。嗯，这里要注意：自适应路由对交换机的处理能力有要求，老旧的交换机可能扛不住。

4.3 多路径的挑战：乱序与死锁

多路径不是万能的。它带来了两个头疼的问题：乱序和死锁。

4.3.1 乱序问题

为什么会乱序？很简单：同一个流的数据包走了不同的路径，到达时间不一样。接收端收到包的顺序，和发送端发出的顺序不一致。

这对TCP来说还好，因为TCP有序列号，可以重组。但InfiniBand的RDMA操作，尤其是RC（可靠连接）服务，对乱序非常敏感。

我曾经在一个项目中，因为乱序导致RDMA Write操作频繁重传。性能直接腰斩。排查了三天，最后发现是哈希算法把同一个QP的包分到了不同路径。

解决乱序的常见方法：

• 保持流内有序：同一个QP的包走同一条路径。这是最常用的方法。
• 使用UD（不可靠数据报）服务：UD本身不保证顺序，应用层自己处理。
• 开启包重组：部分高端交换机支持硬件重组，但会增加延迟。

4.3.2 死锁问题

死锁，说白了就是「你等我，我等你，谁也动不了」。在多路径网络中，死锁更容易发生。

想象一个场景：路径A上有包要去路径B，路径B上有包要去路径A。如果两条路径的缓冲区都满了，双方都无法前进，就死锁了。

InfiniBand的死锁主要分两种：

• 路由死锁：由于路由环路或缓冲区依赖导致的死锁。
• 协议死锁：由于Credit机制或流控导致的死锁。

怎么避免？我总结了几条经验：

1. 使用无环拓扑：比如Fat-Tree，天然无环。
2. 开启VL（虚拟通道）：把不同优先级的流量分到不同VL，避免互相阻塞。
3. 设置合理的缓冲区大小：太小容易死锁，太大浪费资源。
4. 启用死锁检测与恢复：部分交换机支持自动检测死锁并丢弃包。

我记得有一次，客户反馈集群偶尔卡死。我远程登录一看，是某个交换机的缓冲区配置太小，加上多路径流量交织，触发了死锁。调整缓冲区后，问题解决。

4.4 实战建议

说了这么多，最后给几条实战建议：

• 先评估，再启用：不是所有场景都需要多路径。小集群（<16节点）单路径就够了。
• 监控是关键：启用多路径后，一定要监控每条链路的利用率。我习惯用ibdiagnet和perfquery。
• 测试要全面：不要只测带宽，还要测延迟和乱序率。用ib_write_bw和ib_send_lat就够了。
• 留好回退方案：万一多路径出问题，能快速切回单路径。我在生产环境里就备着一套单路径配置。

好了，这一章就到这里。多路径是个好东西，但用不好就是灾难。下一章咱们聊聊具体的路由算法，比如DOR和自适应路由的对比。到时候见。