InfiniBand 架构：子网管理器、LID 与 UFM

IB 不是"快一点的以太网"

这是理解 InfiniBand 的第一步。它是另一套完整体系，和以太网在每一层都不同：

所以 IB 的运维知识不能从以太网直接迁移。好消息是：它的很多难题被架构消掉了—— 比如不需要配 PFC/ECN，因为链路层本来就不丢包。

Credit 流控：为什么天生无损

以太网的发送方是"先发出去，堵了再说"。IB 反过来：

接收方告诉发送方：我还有 N 个 credit（缓冲单元）
发送方：只发不超过 N 个单位的数据
接收方处理完，归还 credit
credit 用完 → 发送方停下等待，而不是把包丢掉

这是逐跳的、硬件实现的背压。对比一下 RoCE 那节： RoCE 要靠 PFC 模拟这个效果，而 PFC 是"事后踩刹车"，还会反压扩散、可能死锁。

IB 的无损是网络自带的，RoCE 的无损要靠人配。 这就是两者最本质的运维差异。

子网管理器：整张网只有一个大脑

以太网交换机各自学习转发表。IB 完全不同：一个子网里有一个 SM（Subnet Manager） 负责发现拓扑、分配地址、计算并下发所有转发表。

SM 启动
  ↓ 扫描整个子网，发现所有 HCA 与交换机端口
  ↓ 给每个端口分配 LID
  ↓ 按路由算法计算路径
  ↓ 把转发表（LFT）写进每台交换机
  ↓ 之后持续监控，拓扑变化就重算

SM 可以跑在交换机上（内置）或某台服务器上（opensm / UFM）。

# 谁是 SM，在哪
sminfo
ibstat | grep -i sm_lid

sminfo                    # 当前 SM 的 LID 与优先级
ibnetdiscover | grep -ci switch    # 能不能正常发现拓扑

LID 与 GID：两套地址

绝大多数集群只有一个子网，所以日常打交道的是 LID；GID 主要在 RoCE 场景里用 （RoCE 那节 讲的 show_gids 选 index 就是它）。

必会的六条命令

① ibstat —— 本机 HCA 的状态

ibstat

CA 'mlx5_0'
	CA type: MT4129
	Firmware version: 28.42.1000
	Port 1:
		State: Active            ← 必须 Active
		Physical state: LinkUp   ← 必须 LinkUp
		Rate: 400                ← 必须符合预期
		Base lid: 37
		LMC: 0
		SM lid: 1
		Link layer: InfiniBand

四个必看字段：State、Physical state、Rate、Link layer。

Initializing 这个状态很有诊断价值：它精确指向 SM 问题，因为端口从 Initializing 变成 Active 正是 SM 的工作。

② ibdev2netdev —— 设备名与网卡名的对应

ibdev2netdev -v

mlx5_0 port 1 ==> ens1f0np0 (Up)
mlx5_1 port 1 ==> ens1f1np0 (Up)

多卡机器上这条最实用：NCCL_IB_HCA 里写的是 mlx5_x， 而 ethtool、ip 用的是 ens1f0np0，两套名字靠它对上。

③ iblinkinfo —— 全网链路一览

iblinkinfo | head -20

Switch 0xb8cef60300a1b2c0 QM9700:
   1    1[  ] ==( 4X 400Gbps Active/ LinkUp)==>  37    1[  ] "node-101 mlx5_0"
   1    2[  ] ==( 4X 400Gbps Active/ LinkUp)==>  38    1[  ] "node-102 mlx5_0"
   1    3[  ] ==(      Down/ Polling)==>            [  ] ""

一眼能看出哪个端口没接、哪条链路速率不对。批量检查：

# 找出所有非 400Gbps 的活动链路（降速）
iblinkinfo | grep Active | grep -v '400Gbps'
# 统计各速率的链路数
iblinkinfo | grep -o '[0-9]*Gbps' | sort | uniq -c

④ ibdiagnet —— 一次性全网体检

这是交付验收和例行巡检的主力命令：

ibdiagnet -r --pm_pause_time 30

它会检查：拓扑一致性、链路速率与宽度、误码率（BER）、 端口错误计数、SM 状态、固件版本一致性，最后把报告写到 /var/tmp/ibdiagnet2/。

# 关键报告
grep -iE 'error|warning' /var/tmp/ibdiagnet2/ibdiagnet2.log | head -20

# 端口错误计数（symbol errors、link recovery 等）
perfquery -a
# 清零后观察增量
perfquery -R -a

⑤ ibnetdiscover —— 导出拓扑

ibnetdiscover > topo.txt
grep -c '^Switch' topo.txt        # 交换机台数
grep -c '^Ca' topo.txt            # HCA 数量

用来核对"实际接线是否符合设计"。Rail 拓扑那节 讲的"图纸对 ≠ 现场接对"，靠的就是这条命令导出的实际拓扑。

⑥ ibping / ibhosts —— 连通性与成员

ibhosts                 # 子网里有哪些 HCA
ibswitches              # 有哪些交换机
ibping -S               # 服务端
ibping -c 10 <lid>      # 客户端

自适应路由与拥塞控制

IB 的转发表由 SM 下发，默认是静态的：同一对端点之间总走同一条路。 大规模集群里这会导致哈希不均——多条流挤在同一条 spine 链路上。

自适应路由（AR） 让交换机在多条等价路径中按实时拥塞情况选路。 对 AllReduce 这种全员同时通信的模式收益明显。

# 查询 AR 是否启用（具体命令依交换机与 UFM 版本）
# 交换机侧：show adaptive-routing

存储流量也受益——SuperPOD 参考架构 明确提到存储网选 IB 的理由之一就是拥塞控制与自适应路由。

UFM：管理平面

UFM（Unified Fabric Manager）是 IB 的集中管理平台：拓扑可视化、SM 服务、 告警、性能采集、固件管理。

它也解释了一个规划细节：Rail 布线账 里 一个 SU 是 32 个机位却只装 31 台节点——腾出的位置和线缆给 UFM 用。

一份 IB 交付验收清单

# 1. 所有端口 Active/LinkUp 且速率符合预期
for d in $(ibstat -l); do echo "== $d"; ibstat $d | grep -E 'State|Rate'; done

# 2. 全网没有降速或未接的链路
iblinkinfo | grep Active | grep -v '400Gbps'

# 3. SM 存在且有备份
sminfo

# 4. 实际拓扑与设计一致
ibnetdiscover | grep -c '^Switch'
ibnetdiscover | grep -c '^Ca'

# 5. 全网体检无错误
ibdiagnet -r && grep -icE 'error' /var/tmp/ibdiagnet2/ibdiagnet2.log

# 6. 点对点带宽达线速 90%（perftest 那节）
# 7. 集群 busbw 达理论峰值 90%（NCCL 那节）

前五条是 IB 特有的，后两条是所有高性能网络的共同验收标准。

检查点

这节课的落点

• IB 是另一套体系：LID/GID 寻址、SM 统一下发转发表、credit 链路层流控
• credit 机制让它天生无损，所以不需要配 PFC/ECN——这是相对 RoCE 最大的运维优势
• SM 是整张网唯一的大脑；它挂了不会立刻断网，但"一动就出事"，必须配主备
• ibstat 的 Initializing + LinkUp 精确指向 SM 问题
• 六条命令：ibstat（本机）、ibdev2netdev（名字对应）、iblinkinfo（全网链路）、 ibdiagnet（体检）、ibnetdiscover（拓扑）、ibhosts/ibping（成员与连通）
• BER 与符号错误是 IB 特有指标，缓慢恶化是线缆将坏的早期信号，属于静默故障
• 自适应路由解决静态转发表的哈希不均，对 AllReduce 收益明显
• 交付验收五条 IB 专项 + 两条通用（点对点线速、集群 busbw）