InfiniBand基础：架构、子网管理器、端口、链路与分区
在深入多路径负载均衡调优之前，必须先建立对 InfiniBand（IB）核心概念的准确认知。IB 并非普通的以太网“升级版”，而是一种面向高性能计算（HPC）与数据中心的计算网络架构，其设计目标直指极低时延、极高带宽与极低的 CPU 卸载开销。理解其分层结构、管理实体与寻址机制，是后续理解多路径（LMC）、自适应路由（AR）以及拥塞控制的前提。
2.1 InfiniBand 整体架构：从物理链路到协议栈
InfiniBand 采用 通道适配（Channel Adapter） 模型，将计算节点与 I/O 节点通过 子网（Subnet） 互联。一个 IB 子网由交换机（Switch）、链路（Link）、端节点上的通道适配器以及一个逻辑上的子网管理器（Subnet Manager, SM）构成。与以太网“即插即用”的分布式控制不同，IB 子网内的所有转发路径、分区成员关系、速率协商均由 SM 集中计算并下发。
从协议分层看，IB 自上而下分为：传输层（Transport）、网络层（Network）、链路层（Link） 与 物理层（Physical）。其中网络层负责子网内路由（LRH）与子网间路由（GRH），链路层负责流控与错误检测，物理层则定义了 1X、4X、12X 等宽度以及 SDR、DDR、QDR、FDR、EDR、HDR、NDR 等速率。
2.2 子网管理器（SM）与子网代理（SA）
SM 是整个 IB 子网的“大脑”。它运行在某个指定节点（通常为主交换机或专用管理节点）上，负责以下关键任务：
- 发现与枚举： 通过管理数据报（MAD）发现子网内所有节点、交换机、链路及其能力。
- 地址分配： 为每个端口分配唯一的本地标识符（LID，16 位）。LID 仅在子网内有效，类似以太网中的 VLAN 内 MAC 寻址。
- 路径计算： 基于拓扑与链路状态，计算从任意源到目的的最优路径，生成交换机的转发数据库（FDB）。
- 分区管理： 维护分区成员表（P_Key 表），控制哪些端口可以互相通信。
- 多路径支持： 通过配置 LMC（LID Mask Control）值，为同一端口分配多个 LID，从而生成多条等价路径。
与 SM 配套的是 子网代理（Subnet Administrator, SA）。SA 是面向端节点的查询接口，应用可以通过 SA 请求路径查询、获取通信服务质量（QoS）属性或解析分区成员关系。在 Linux 系统中，ibquery、ibping、ibroute 等工具均通过 SA 获取子网信息。
2.3 端口、链路与寻址机制
IB 网络中的每个连接点称为 端口（Port）。端口可以是交换机端口，也可以是通道适配器端口。每个端口拥有两个关键地址：
| 地址类型 | 位数 | 作用范围 | 分配方式 | 调优意义 |
|---|---|---|---|---|
| GUID（全局唯一标识） | 64 位 | 全球唯一 | 出厂烧录 | 用于 SM 识别物理端口 |
| LID（本地标识） | 16 位 | 子网内唯一 | SM 动态分配 | 数据转发依据；LMC 扩展后一个端口可拥有多个 LID |
链路（Link） 是连接两个端口的物理通道。IB 链路支持不同的宽度与速率组合，例如 4X EDR（100 Gb/s）、12X HDR（600 Gb/s）等。链路速率由 SM 在初始化时通过握手协商确定，若两端能力不一致，则降级到双方均支持的最高速率。
在数据发送时，IB 报文头（LRH）中携带 目的 LID 与 源 LID。交换机仅依据目的 LID 查找 FDB 进行转发，不关心 IP 地址或 MAC 地址。这种基于 LID 的转发机制使得 IB 交换机硬件实现极为简单高效，但也意味着路径完全由 SM 预先规划。
2.4 分区（Partition）机制
分区是 IB 网络实现 隔离与安全 的核心机制，类似于以太网中的 VLAN，但实现方式不同。每个分区由一个 16 位的 P_Key 标识，其中最高位表示是否可管理分区。端口在加入分区时，SM 会为其配置 P_Key 表。
通信时，发送端在报文中携带 P_Key，接收端检查该 P_Key 是否在自己的 P_Key 表中。若匹配，则接收；否则丢弃。这一过程在硬件层面完成，不消耗 CPU 资源。
/etc/dat.conf 或 ibv_devinfo 中的 P_Key 并不会改变 SM 侧的实际配置。
2.5 案例：一个典型双机 IB 子网配置
假设有两台服务器（Server A 与 Server B），各配一块双端口 HCA，通过一台 36 端口交换机互联。我们希望验证基础连通性并查看分区与 LID 分配情况。
首先，在 Server A 上查看 HCA 端口属性：
# ibv_devinfo
hca_id: mlx5_0
transport: InfiniBand (0)
fw_ver: 16.29.1016
node_guid: 0x248a070300a1b2c3
sys_image_guid: 0x248a070300a1b2c3
port 1:
state: PORT_ACTIVE (4)
physical_state: LINK_UP (5)
rate: 100 Gb/sec (4X EDR)
base_lid: 0x0002
lmc: 0
link_layer: InfiniBand
# ibstat
CA 'mlx5_0'
Port 1:
State: Active
PhysicalState: LinkUp
Rate: 100
BaseLid: 2
LMC: 0
SM lid: 1
CapabilityMask: 0x02514868
PortLid: 0x0002
PortState: Active
可以看到，当前 LMC 为 0，即每个端口只有一个 LID。若需启用多路径，需在 SM 配置中设置 LMC 值（例如 LMC=2），并重启 SM 或触发重新配置。
接着，使用 ibping 验证 Server A 到 Server B 的连通性：
# ibping -S 0x0002 # Server A 启动服务
# ibping -G 0x248a070300a1b2c4 # Server B ping Server A 的 GUID
若需要查看当前子网中的路径与 LID 分配，可使用：
# ibroute -n 1 # 查看交换机 1 的转发路由表
# smpquery nodedesc 2 # 查询 LID 2 的节点描述
2.6 误区与复盘：LID、GUID 与路径的关系
在调优实践中，以下概念混淆常导致问题定位困难：
- 误以为 LID 是固定的： LID 由 SM 动态分配，交换机重启或 SM 重新发现后，LID 可能变化。因此，依赖 LID 的脚本或配置应使用 GUID 或主机名进行映射。
- 忽略 LMC 对路径的影响： 即使 HCA 支持多路径，若 SM 未配置 LMC，所有流量仍走单一路径。LMC 值增大后，同一端口会获得多个 LID（例如 LID=2, 6, 10），SM 会为每个 LID 计算不同路径。
- 分区与 P_Key 的排障顺序： 当通信失败时，应先检查物理链路（
ibstat显示 Active），再检查 P_Key 是否匹配，最后检查 SM 路由表。许多工程师直接跳到路由层面排查，浪费大量时间。 - 将 IB 的“路由”与 IP 路由混淆： IB 子网内没有动态路由协议，所有路径由 SM 集中计算。若拓扑变化，必须等待 SM 重新收敛（通常秒级），期间流量可能中断。