3、IB链路聚合协议：动态LAG（802.3ad/LACP）在IB中的实现、静态LAG配置、IB专用聚合协议
好，咱们接着聊链路聚合。上一章讲了为什么要聚合，这一章咱们直接撸起袖子，看看在 InfiniBand 里到底怎么配、用什么协议。
说实话，我第一次接触 IB 的链路聚合时，心里还嘀咕：这不就是以太网那套 LACP 吗？后来踩了坑才发现——嗯，没那么简单。
3.1 动态LAG：LACP在IB中的实现
动态 LAG，说白了就是让交换机和对端设备自己协商，自动把多条链路绑到一起。在以太网里，这个活儿是 LACP（802.3ad）干的。那在 IB 里呢？
IB 其实也支持类似 LACP 的机制，但实现上有些差异。我个人的理解是：IB 的 LACP 更像是一个「轻量版」——它不搞复杂的报文交互，而是利用 IB 自身的链路状态检测机制。
核心流程是这样的：
- 两端端口开启 LACP 模式
- 交换机会定期发送 LACP 数据单元（LACPDU）
- 对端收到后，比较系统优先级、端口优先级、端口号等参数
- 协商一致后，把多个端口聚合成一个逻辑端口
关键点：IB 的 LACP 不依赖标准的 802.3ad 帧格式，而是用 IB 的 MAD（管理数据报）来封装 LACP 报文。这一点很多新手会搞混。
我在项目中遇到过一个问题：两台交换机之间做 LACP，死活协商不起来。后来抓包一看，发现是 MAD 的 MTU 设置不一致。你想想看，两边对不上话，怎么可能握手成功？
3.2 静态LAG配置实战
动态 LAG 虽然方便，但有时候你不想让交换机自己瞎折腾——比如在测试环境，或者你需要完全控制链路成员。这时候就用静态 LAG。
静态 LAG 的配置其实更简单。说白了就是手动指定哪些端口绑在一起，不跑任何协商协议。
我建议的配置步骤：
- 先把所有要聚合的端口 shutdown
- 创建 LAG 接口，指定 LAG ID
- 把端口加入 LAG 组
- 统一配置端口的速率、FEC 等参数
- no shutdown 激活
这里有个坑——我曾经犯过：端口速率不一致。两个 25G 端口和一个 50G 端口绑在一起，结果 50G 那个端口一直丢包。为什么？因为 IB 的静态 LAG 不做速率协商，它默认所有成员速率相同。你想想看，一个快车道一个慢车道，车流能不乱吗？
警告：静态 LAG 下，如果某个端口物理 down 了，流量不会自动切到其他端口。你需要配合监控脚本或者链路检测机制来做故障转移。
3.3 IB专用聚合协议
除了 LACP 和静态 LAG，IB 还有自己的一套聚合协议。这个可能很多做以太网出身的朋友不太熟悉。
IB 专用聚合协议主要有两种：
- 自适应路由（Adaptive Routing）：这不是传统意义上的链路聚合，但它实现了类似的效果——流量在多条路径间动态分发。IB 交换机可以根据实时负载，把报文发到不同的链路上。
- 多路径（Multi-Path）：在 HCA 端，你可以配置多个端口，然后通过 LID 或 GID 的映射，实现多路径传输。这其实是一种主机侧的聚合。
我记得有一次帮客户调优一个 HPC 集群，他们用了 4 条 100G 链路做聚合，但性能死活上不去。后来我发现，他们用的是标准的 LACP，但 IB 交换机其实支持自适应路由。我建议他们换成自适应路由 + 多路径的组合，结果带宽利用率从 60% 直接飙到 95%。
小技巧：如果你的 IB 交换机支持自适应路由，优先用它。LACP 在 IB 里其实有点「水土不服」——它毕竟是以太网的东西，在 IB 的 credit-based 流控下，效果不一定好。
3.4 三种方案的对比
说了这么多，咱们用一张表总结一下：
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 动态 LAG（LACP） | 自动协商，配置简单 | 依赖 MAD 封装，兼容性一般 | 中小规模集群，快速部署 |
| 静态 LAG | 完全可控，无协议开销 | 无故障检测，需手动管理 | 测试环境，或需要精细控制 |
| IB 专用协议（自适应路由/多路径） | 性能最优，原生支持 | 配置复杂，依赖硬件 | 高性能 HPC，大规模集群 |
我个人习惯是：生产环境优先用 IB 专用协议，测试环境用静态 LAG。LACP 嘛——除非客户指定，否则我一般不推荐。为什么？因为我在一个项目里被 LACP 的兼容性问题坑过，两台不同厂商的 IB 交换机做 LACP，结果报文格式不兼容，折腾了两天。
好了，这一章的内容就到这儿。下一章咱们聊聊链路聚合的故障排查——这可是实战中的硬功夫。