3、多路径技术原理：ECMP等价多路径、多路径哈希算法、路径故障切换、多路径负载均衡模型

各位好，我是老张。今天咱们聊聊RoCE网络里一个绕不开的话题——多路径。说白了，就是怎么让数据包在多个可用路径上“跑起来”，别堵在一条路上死等。

我刚开始接触RoCE的时候，觉得这玩意儿跟普通以太网差不多，加个PFC、ECN就完事了。结果第一次在40节点集群上跑测试，性能直接崩了。查了半天，发现是哈希冲突导致某条链路打满，其他链路闲着。嗯，从那以后，我再也不敢小看多路径了。

3.1 ECMP等价多路径：最朴素的“分叉”思想

ECMP，全称Equal-Cost Multi-Path，等价多路径。它的逻辑很简单：如果去同一个目的地有多条开销相等的路径，那就把流量均匀地撒到这些路径上。

你想想看，这就像你开车去机场，有三条高速都能到，距离一样、收费一样。你肯定希望车流能平均分配到三条路上，而不是所有人都挤在一条路上。

ECMP在RoCE网络里非常常见。比如Spine-Leaf架构里，Leaf到Spine通常有4条、8条甚至更多等价链路。ECMP就是负责把这些链路用起来的“交通警察”。

3.2 多路径哈希算法：流量拆分的“分拣员”

ECMP只是说“我要把流量分到多条路上”，但具体怎么分？这就轮到哈希算法上场了。

哈希算法的作用，是把数据包的特征（比如源IP、目的IP、源端口、目的端口）算出一个哈希值，然后根据这个值决定走哪条路。

常见的哈希算法有几种：

• 基于IP的哈希： 只算源IP和目的IP。简单，但粒度粗。同一个IP对的所有流都走同一条路。
• 基于五元组的哈希： 算源IP、目的IP、协议、源端口、目的端口。粒度细，不同TCP连接可以走不同路。
• 基于流的哈希： 有些设备支持自定义哈希字段，比如加上RoCE的GRH头里的某些字段。

我个人习惯在RoCE场景下用五元组哈希。为什么？因为RoCE的QP（Queue Pair）数量通常很多，五元组能保证不同QP的流量分散到不同路径上。

哈希算法的选择，直接影响负载均衡的效果。你想想看，如果哈希算法不好，比如哈希冲突率高，那就会出现“明明有8条路，结果6条路的流量都挤到同一条路上”的尴尬局面。

3.3 路径故障切换：别让一条路堵死全局

网络设备不是永动机，交换机、光模块、光纤都会出问题。多路径技术必须考虑故障切换。

路径故障切换的核心机制，我总结为三个步骤：

1. 故障检测： 怎么知道一条路断了？常见的有BFD（双向转发检测）、硬件信号检测、链路层协议检测。
2. 路径收敛： 检测到故障后，路由协议（比如BGP、OSPF）重新计算路由，把故障路径从路由表里拿掉。
3. 流量切换： 新的路由表生效后，流量自动切换到剩下的健康路径上。

这里有个关键指标——收敛时间。从故障发生到流量切换完成，这个时间越短越好。RoCE对丢包极其敏感，如果收敛时间太长，丢包会导致QP重传，性能断崖式下跌。

路径故障切换还有一个容易被忽略的点——哈希表更新。ECMP的哈希表是硬件维护的，故障切换时硬件需要重新计算哈希映射。如果硬件处理慢，即使路由表更新了，流量还是可能往故障链路上发。

3.4 多路径负载均衡模型：从“均匀”到“智能”

ECMP加哈希，能解决大部分问题。但还不够。为什么？因为ECMP是“尽力均匀”，不是“真正均衡”。

举个例子：你有4条10G链路，ECMP把流量平均分到4条路上。但如果其中一条路上跑的是大流（比如RDMA Write 10G带宽），其他三条路上跑的是小流（比如控制消息），那这条大流所在的链路就满了，其他链路还闲着。这叫“哈希冲突”。

为了解决这个问题，业界提出了几种更高级的负载均衡模型：

我个人在实际项目中，用得最多的是动态ECMP。为什么？因为静态ECMP太死板，自适应路由又太贵。动态ECMP在成本和效果之间找到了一个平衡点。

下面这张图展示了多路径负载均衡的核心逻辑：

这张图展示了从输入流量到最终路径选择的完整流程。注意那个“故障检测反馈”的虚线回路——它把路径状态信息反馈给ECMP决策模块，实现动态调整。

好了，关于多路径技术原理，今天就聊到这儿。记住一句话：没有完美的负载均衡，只有最适合你场景的方案。选型的时候，多想想你的流量模型、硬件能力、成本预算，别盲目追求“最先进”的技术。

公众号:蓝海资料掘金营，微信deep3321