2. 链路聚合基础：什么是链路聚合（LAG）、为什么需要LAG、LAG的工作原理（哈希分发）
好，咱们正式开始聊链路聚合。说实话，我第一次接触 InfiniBand 的时候，觉得这玩意儿带宽已经够大了——单条链路就几十 Gbps，还要啥自行车？直到我在一个超算中心做项目，客户跑的是大规模分子动力学模拟，数据量一上来，单条链路直接被打满，丢包、重传、延迟飙升。嗯，那时候我才意识到：带宽永远不嫌多，冗余永远不嫌少。
所以，链路聚合（LAG）就派上用场了。今天这一节，咱们把 LAG 的底裤扒干净。
2.1 什么是链路聚合（LAG）
链路聚合，英文叫 Link Aggregation，简称 LAG。说白了，就是把多条物理链路捆成一条逻辑链路来用。你想想看，本来你只有一根水管，流量大了就堵；现在你并排接了三根水管，流量可以同时走三根，是不是爽多了？
在 InfiniBand 的世界里，LAG 通常是把 2 条、4 条甚至 8 条物理链路绑在一起。每条物理链路可以是 4X（四通道）或 12X（十二通道）的配置。举个例子：
| 物理链路配置 | 单链路带宽 | 4条LAG总带宽 |
|---|---|---|
| EDR 4X | 100 Gbps | 400 Gbps |
| HDR 4X | 200 Gbps | 800 Gbps |
| NDR 4X | 400 Gbps | 1.6 Tbps |
我个人习惯把 LAG 比作「高速公路的并线策略」——不是简单地把车道加宽，而是让多股车流智能地分配到不同车道上。
核心要点：LAG 对上层应用是透明的。你的 MPI 程序、存储协议、甚至操作系统看到的只是一条逻辑链路。底层怎么分流的，它们不关心，也无需关心。
2.2 为什么需要 LAG
这个问题其实很实在。我遇到过不少刚入行的朋友问：单条链路带宽已经几百 Gbps 了，还不够用吗？
答案是：真不够。原因有三：
- 带宽叠加：最直接的需求。单个应用可能吃不满一条链路，但多个应用加起来呢？HPC 集群里几百上千个节点同时通信，流量瞬间就能把单条链路撑爆。LAG 让你可以线性扩展带宽。
- 高可用性：这是我最看重的点。我在一个金融行业的 HPC 项目里吃过亏——一条光纤被施工队挖断了，整个集群的通信中断了半小时。有了 LAG，一条链路断了，流量自动切换到其他链路上，业务零感知。说白了，这就是硬件级别的「容错」。我曾经因为没配 LAG，半夜被电话叫起来处理链路故障，那滋味……嗯，你们懂的。
- 成本效益：买一条 400G 的链路，和买四条 100G 的链路做 LAG，价格差多少？我算过，后者往往便宜 30%-50%。而且，四条 100G 的链路灵活性更高——你可以逐步扩容，而不是一次性砸大钱。
避坑指南：我曾经遇到一个客户，为了省钱，把不同速率（比如 100G 和 200G）的链路绑在一起做 LAG。结果呢？慢的链路成了瓶颈，快的链路也跑不满。记住：LAG 的成员链路最好同速率、同型号、同长度。
2.3 LAG 的工作原理：哈希分发
好，重头戏来了。LAG 是怎么把流量分配到多条物理链路上的？答案就是——哈希分发。
你可能会想：是不是像路由器那样轮询？或者像负载均衡那样看当前链路利用率？都不是。InfiniBand 的 LAG 用的是哈希算法，对数据包的某些字段做哈希计算，然后根据哈希值决定走哪条链路。
为什么用哈希？因为简单、快速、确定性。轮询会导致乱序——同一个流的数据包可能走不同的链路，到达顺序就乱了。哈希保证了同一个流（比如同一个 TCP 连接或同一个 MPI 消息）的所有数据包都走同一条链路，不会乱序。
具体来说，哈希的输入字段通常包括：
- 源 LID（Local Identifier）——类似 MAC 地址，标识源端节点
- 目的 LID——标识目的端节点
- 源 QP（Queue Pair）号——标识发送端的队列对
- 目的 QP 号——标识接收端的队列对
- 服务级别（SL）——类似 QoS 优先级
哈希算法通常是 XOR 或 CRC 的变种。举个例子，假设我们有 4 条链路，哈希值对 4 取模，结果 0 走链路 0，结果 1 走链路 1，以此类推。
// 伪代码示意
hash_value = hash(src_lid, dst_lid, src_qp, dst_qp)
link_index = hash_value % number_of_links
send_packet_on_link(link_index)这里有个细节要注意：哈希的均匀性。如果哈希算法不好，或者流量模式单一，可能导致某些链路负载高、某些链路空闲。我在一个气象模拟项目中就遇到过——所有 MPI 通信的 QP 号都是偶数，哈希结果全落在链路 0 和链路 2 上，链路 1 和链路 3 闲得发慌。
警告：哈希分发不是真正的负载均衡。它只能保证「流级别」的均匀性，不能保证「字节级别」的均匀性。如果你的集群里只有几个大流，LAG 的效果可能大打折扣。这时候，你可能需要考虑更高级的负载均衡方案，比如自适应路由（Adaptive Routing）。
2.4 两种 LAG 模式
InfiniBand 支持两种 LAG 模式，我分别说一下：
静态 LAG（Static LAG）：手动配置，把几条链路绑在一起。交换机端和端节点端都要配。好处是简单、可控，坏处是配置麻烦，链路增减需要手动调整。我个人习惯在小规模集群（几十个节点）里用静态 LAG，因为配置量不大，而且我清楚每条链路的状况。
动态 LAG（Dynamic LAG）：使用 LACP（Link Aggregation Control Protocol）自动协商。交换机自动发现可聚合的链路，自动绑定，链路故障时自动切换。在大规模集群（几百上千节点）里，我强烈建议用动态 LAG。为什么？因为省心。我曾经管理过一个 500 节点的集群，如果每条链路都手动配，配完估计头发都白了。
| 特性 | 静态 LAG | 动态 LAG |
|---|---|---|
| 配置方式 | 手动 | 自动协商 |
| 故障切换 | 手动或脚本 | 自动 |
| 适用规模 | 小规模 | 中大规模 |
| 协议支持 | 无 | LACP |
我的建议：如果你刚开始接触 InfiniBand，先从静态 LAG 入手，理解原理。等熟悉了，再上动态 LAG。别一上来就搞动态，出了问题你都不知道是配置问题还是协议问题。
2.5 小结
这一节咱们把 LAG 的基础讲透了。总结一下：
- LAG 就是把多条物理链路捆成一条逻辑链路，提升带宽和可用性
- 哈希分发是 LAG 的核心，保证同一个流不乱序
- 静态 LAG 适合小规模，动态 LAG 适合大规模
- 注意哈希均匀性，别让流量「偏科」
下一节，咱们会深入实战——怎么在 InfiniBand 交换机上配 LAG，以及怎么验证它是否生效。到时候我会拿一个真实的配置案例来讲，保证你们看完就能上手。