尧图网页设计 
简介InfiniBand 架构规范卷1Release 2.0是IBTA正式发布的高速网络通用规格文档主要面向数据中心和高性能计算领域的架构师、网络工程师及RDMA研发人员用于理清InfiniBand体系结构、虚拟化扩展、RoCE与RDMA增强等核心机制并理解链路层、传输层、子网管理及服务质量等底层规范。压缩包内为单个PDF文档大小约14.65MB正文保留从1.0到2.0的完整修订历史并展开说明虚拟化支持、RoCE-v1/v2附件、MPE内存保护扩展中的原子写与冲刷、Network Probe、大规模radix交换机管理、速率限制器与最小带宽、VPort QoS仲裁以及XDR速率支持等特性方便逐版对照功能演进。相比零散的技术博客这份规范能提供协议设计层面的权威细节适合做技术选型、硬件实现或组网方案评估对需要排查互操作问题、评估新特性影响的团队也是不可或缺的参考依据。目前已有354人学习。1. IB Specification 2.1 在救什么不止是带宽是协议栈我真正把 IB Specification 这个标题当回事是在一个 AI 训练集群里两台 A100 服务器用 100Gb 的 IB 卡直连跑分布式训练实测带宽却只有 40Gb 出头GPU 利用率上不去谁都说不清瓶颈在哪。排查到最后问题不出在硬件而出在子网管理器没拉起来、端口速率协商不一致这些“协议栈层面”的事。IB Specification 2.1 说的不是某一个网卡型号而是 InfiniBand 这套互连规范本身链路层流控、子网管理、LID/GID 寻址、QoS 映射、传输层对偶队列全部被定义在一本规范里。它解决的是高性能计算和 AI 训练场景下以太网“丢包后靠重传兜底”解决不了的延迟问题。本篇我按自己部署过的 IB 网络来拆不背规范条文只讲能上手的机制、命令和坑。2. 协议栈拆开看IB Specification 2.1 把链路、寻址、QoS 管到哪一层2.1 子网管理器为什么是 IB 的控制面“黑匣子”InfiniBand 和以太网最大的区别在控制面。以太网靠 MAC 地址学习完成转发IB 靠一个集中式子网管理器Subnet ManagerSM发现拓扑、分配 LID、计算路径再通过管理报文把配置下发到每个交换机和网卡。普通节点上的 IB 网卡只是子网管理代理SMA它不自己决定转发路径只被动响应 SM 的请求。这个模型决定了 IB 网络的启动顺序SM 先起来全网端口才能拿到地址SM 挂了已经被分配的 LID 不会立刻消失但新的连接和路径计算都会陷入停滞。正因为 SM 是控制面它往往成了排障时最容易被忽略的“黑匣子”。端口状态显示 Active不代表端到端路径可用SM 计算出的路径是最短路径树遇到不对称拓扑或低速链路它也不会自动绕行。Specification 对 SM 的行为描述得非常细但摸底时你只需要确认三件事SM 是否在运行、是否唯一、有没有把路径算对。常见做法是跑一个 opensm然后用命令确认它已经成为 Master# 先生成默认配置方便后面按需改 opensm -c /etc/opensm.conf # 用节点 GUID 固定 SM 身份并后台运行 opensm -g 0x02c9030100a1b2c3 --conf /etc/opensm.conf -B第一条命令是让 opensm 生成一份完整的默认配置里面包含平滑切换、QoS 策略开关、日志级别这些参数。第二条命令里的-g指定 GUID把 SM 的身份钉死--conf指向刚才生成的配置-B让它后台运行。如果日志输出里有Master Subnet Manager说明它已经接管全网。多台机器同时起 opensm 时需要保证优先级不同否则主从选举会抖动全网 LID 会被反复重新分配。2.2 LID、GID 与路径计算寻址不是 MAC 表IB 网络里每个端口有两个地址理解这两个地址是读规范原文的敲门砖。LID 是子网内有效的 16 位本地标识类似以太网里的二层地址但作用范围只限于当前子网GID 是 128 位全局标识由子网前缀加 EUI-64 组合而来用于跨子网或 RoCE 场景。转发全程只看 LIDSM 算好路径后交换机端口会维护一张以 LID 为索引的转发表。因此 LID 分配的稳定性格外重要节点重启、SM 切换都可能让 LID 变化而上层连接如果硬编码了旧 LID就会失联。网卡上拿到的 LID 可以直接用 ibstat 查看ibstat | grep -E Local device ID|Port输出中的Local device ID就是本端口的 LID一般显示成0x0002c9030100a1b2c3这样的十六进制。排查时第一眼先看它是不是全零如果 LID 全零说明 SM 还没分配地址链路必然是通的但上层通信不可用。这类“链路 Active 但 LID 归零”的现象在双机直连场景里尤其常见根因往往是两台机器都装了 opensm 又都没有正确选中 MasterSM 实际处于 init 状态。路径计算也要提防黑匣子效应。SM 默认按最短路径树下发转发表如果网络里存在非对称链路例如左边是 4X EDR、右边是 2X EDRSM 不一定每次都会绕开慢链路。要看清实际路径我会在评估阶段用ibdiagnet -p导出一份路径表确认关键端到端的那一跳落在预期链路上。这个动作看起来多余但在 IB 网络里是唯一能验证“控制面是不是真的按你想的在转发”的手段。等网络跑到几百个节点再靠 ping 去摸路径就不现实了。2.3 VL/SL 与流控丢包由设计避免以太网靠 PAUSE 环或 PFC 做反压但反压风暴一出现整个交换域都可能抖。IB 链路层用的是基于 credit 的流控发送端口只有拿到接收端口回授的 credit 才能继续发没有 credit 就停下来等。这份 credit 与虚拟通道VL绑定每个物理端口可以创建多个 VL不同 VL 之间互相隔离。报文的服务等级SL字段在进入端口时会被映射到某一个 VL而 SL2VL 映射表由 SM 统一配置下发不是网卡自己协商。这个设计把“不同优先级的业务在链路内部怎么排队”变成一张可下发的表。最常用的划分方式如下SL 值典型业务建议 VL0控制与管理流量VL01MPI/RDMA 计算流量VL12存储复制流量VL2SL0 留给 SM 和诊断报文SL1 给计算业务SL2 给存储。这样当存储流量把 VL2 打满时VL1 里的计算流量不会与其争抢同一队列。注意这里的语义区别SL 是报文头上的标签VL 是链路层实际承载通道交换机每个 VL 都有自己的仲裁器。所以配置 QoS 时必须同时看主机侧和交换机侧的 SL2VL 映射只改一头必然出问题。credit 流控失效时会出现 IB 特有的 credit 死锁两端的报文分别占住不同的 VL互相等对方释放 credit。规范靠 VL 仲裁和多路径绕开来缓解但运维侧能做的是不要把所有流量赶进同一个 VL。我见过不少集群把 MPI 和存储复制放在同一个 SL 0 上短时间没问题一旦存储打满整个计算网络的带宽全部塌方这就是典型的把控制面和数据面混在一个队列里导致的灾难。3. 按 IB Specification 2.1 搭一套最小 IB 集群从驱动到 opensm3.1 最小硬件与软件清单两张卡、一根线也能开跑搭建 IB 实验环境不需要整柜交换机。两台服务器各插一块 InfiniBand HCA中间用一根无源铜缆直连就构成一个最小的 IB 子网。这个拓扑里仍然需要有一个节点运行 SMopensm 可以装在主机上没有交换机时SM 直接通过主机网卡发现对端并分配 LID。很多人在这一步就停住了因为他们以为 IB 必须配交换机其实双机直连就能验证 RDMA 语义和大部分性能指标。硬件以外软件栈按发行版略有差异。RHEL/CentOS 系是ibutils、infiniband-diags、rdma-core和opensmUbuntu/Debian 系是rdma-core、infiniband-diags、ibutils2。我习惯把诊断工具和数据面驱动分开看待数据面驱动负责网卡收发诊断工具负责看 SM 和链路状态。下面的安装命令覆盖 Ubuntu 侧最常见的一整套apt install -y rdma-core infiniband-diags ibutils2 opensm perftestrdma-core 提供内核模块和 libibverbsinfiniband-diags 提供 ibstat、ibstatus、ibdiagnetlibibutils2 提供 ibping 这类工具opensm 不用说是 SMperftest 是带宽延迟测试集。装完之后可以先跑一次ibv_devinfo确认驱动已经认到 HCA再继续往下走。3.2 装驱动与固件检查modinfo 与 ibv_devinfo 逐项过IB 网卡最常见的驱动是 mlx5_core对应 Mellanox/NVIDIA ConnectX 系列。装完驱动后第一件事不是测带宽而是检查固件版本和驱动是否匹配。固件版本差太远会出现奇怪的的现象链路能协商到 EDR但 RDMA 报文一上来就丢。检查方式很直接ibv_devinfo -v | egrep hca_id|fw_ver|node_guid|sys_image_guid|max_qp|active_speed这个命令会把每一块 HCA 的固件版本、GUID、最大 QP 数、当前协商速率都打出来。active_speed直接告诉你链路协商到了几倍宽、什么速率25.0 Gb/sec是 EDR14.0 Gb/sec是 FDR。如果这里显示 4X SDR 这种最低档赶紧查线缆和两端端口配置大概率是线缆问题或者端口被限速。还要确认内核里的 rdma 子系统正常挂载。现代内核上直接执行rdma link show会输出每个 IB/RoCE 设备的状态。看到state ACTIVE physical_state LINK_UP才算过了第一关如果是state INIT说明 SM 还没接管链路。这里多说一句很多翻车不是硬件坏了而是驱动加载顺序不对尤其是在容器环境里忘了把/dev/infiniband/*和/dev/rdma_cm都映射进去宿主机看到的是好的容器里全盲。3.3 用 opensm 拉起子网命令、配置与三种启动方式opensm 启动方式有三种前台运行、后台运行、由 systemd 管理。手排障时我建议前台运行因为日志直接打在终端Ctrl-C 停掉也快。确认没问题后再改成后台或服务方式。最基础的前台启动命令只有一行opensm -g 0x02c9030100a1b2c3 --conf /etc/opensm.confproduce默认会往/var/log/opensm.log写日志。启动后立刻看一行关键信息日志里的Master Subnet Manager说明这一实例抢到了主 SM。如果显示Standby Subnet Manager说明同一子网里已经有一个更高优先级的 SM当前节点只是备用。双机直连时如果两台机器都默认自启 opensm有可能出现主备来回切换每次切换都会全端口重新下发 LID正在跑的 RDMA 连接全部断掉。避免方法是在配置里指定优先级一台设成 15另一台设成 5。配置项里还有几个值得提前调的参数subnet_timeout、maxhops、qos_policy_file。前两个影响全网收敛速度qos_policy_file指向 QoS 策略文件如果你想用上一章说的 SL2VL 分层就必须在这里挂一份。没挂 QoS 策略时opensm 会按默认策略把所有 SL 映射到 VL0功能上没问题但存储流量和计算流量就会互相干扰。3.4 确认链路正常ibstatus 与 ibdiagnet 逐行解读链路拉起来之后不要急着跑应用先用诊断工具把状态彻底确认一遍。第一个必看的是 ibstatus它输出比 ibstat 更详细直接能看到物理状态和链路宽度ibstatus关键行是State: Active和Physical state: LinkUp以及Rate: 100这样表示 100Gb/s 的速率。速率和宽度两个值都要盯4X EDR表示 4 个 lane 每个 25Gb/s2X EDR只有 2 个 lane性能直接减半。如果两端 HCA 能力不一致链路会协商到较低的那一档这时候性能不是玄学是协商结果摆在明面上只是你没看。下一步跑ibdiagnet -pe它会把所有端口错误计数器、LID、SM 状态导出来。要关注的是PortErrors部分有没有 CRC error 和 link integrity error。这两个错误出现基本可以断定线缆或光模块有问题或者链路两端在降速抖动。ibdiagnet 跑完还会生成一份ibdiagnet.pm文件里面是 SM 下发的路径表留作后面对比用非常方便。运营一个 IB 网络每次变更后留存这份文件等于给网络买了后悔药。4. 避坑IB 子网管理器与链路层最常见的 5 个翻车现场4.1 现象链路显示 Active但 RDMA 操作直接超时直接出现过一次双机直连IB 卡驱动正常端口状态 Activeibping能通但是跑ib_write_bw时一端报Connection timed out。查了很久才发现两台机器各自都装了一个 opensm并且都以默认优先级启动系统交替选择 MasterLID 分配结果在不断变化RDMA 连接刚建立就被打断。原因在于 SM 主从不稳定。两个相同优先级的 SM 实例在同时工作时会抢主抢主过程中子网会重算转发路径期间新连接无法建立已有连接因 LID 漂移失联。解决办法简单粗暴指定唯一主 SM另一个停掉或降优先级。用opensm --prio 15启动主节点备用节点用--prio 5然后重启所有 IB 服务。这个操作在我们的环境里一分钟后网络恢复稳定。4.2 现象opensm 起来后全网 LID 集体漂移环境不大从头到尾就三台机器一个交换机某天固件升级后发现所有节点的 LID 和升级前完全不同原来写死在应用里的 LID 全部失效。检查后确认是 SM 的 GUID 变了固件升级把 node GUID 重置opensm 实例身份跟着变主从选举重新来了一次全网 LID 也跟着重排。这不算故障但在生产环境里会引起一阵慌乱。解决思路是给 SM 钉一个固定身份不要依赖网卡原有 GUID。在 opensm 启动命令里显式传-g或者在配置文件中写死sm_guid。还有一种更彻底的做法是启用 opensm 的 persistence 文件它会记录上一次 LID 分配结果尽量复用旧 LID。这个特性默认开着但如果日志目录被清过persistence 也就失效了。所以重要节点别在应用里硬编码 LID能走 GID 或主机名解析就走解析这才是治本。4.3 现象配置 QoS 映射后带宽不升反降按文档启用了 QoS 策略把 MPI 流量放在 SL1、存储流量放在 SL2结果全网带宽反而从满速掉到六七成。看端口计数器丢包没有明显增加但吞吐上不去。这就是典型 SL2VL 映射与交换机侧 QoS 不一致导致的现象主机侧把报文标成了 SL1交换机端口却没有对应的 SL1 到 VL1 映射默认全部落到 VL0又触发了链路仲裁的公平限制。QoS 配置必须是端到端的统一动作。主机 HCA、接入交换机、核心交换机三者的 SL2VL 映射表必须一致并且每个 VL 的仲裁权重也要统一考虑主机发起的流量和交换机转发流量。我们最后把 QoS 配置文件固化成一份模板通过自动化下发给所有设备才解决这个问题。调 QoS 最怕只改一半很小的一个映射不一致表现出的就是整体带宽下降而不是报错。4.4 现象MPI 应用时好时坏单测带宽却始终稳定这是最让人头疼的一类问题两台机器之间跑ib_write_bw能跑满一上 MPI 应用就随机卡住有时候几分钟有时候几小时。单测稳定说明物理链路和驱动基本没问题问题出在上层传输选型和参数匹配。MPI 在 IB 上有多种传输路径openib、ucx、rdma_cm不同路径对内存注册、连接建立方式的处理完全不同默认选错就会在特定报文大小或并发度下触发死锁或超时。常见做法是先切到 UCX 传输层并调整超时参数让 MPI 直接走 RDMA 写同时把UCX_TLS限定为rc_verbs或rc_mlx5避免 frc 连接数膨胀。另外要检查ulimit -l锁定内存限制是否够大IB 通信前要做内存注册限制太小会导致注册失败在日志里表现为mlx5_0: create qp failed。这类问题属于慢性的排查时要有耐心一条条排除别一上来就怀疑网卡。4.5 现象IB 与 RoCE 混布在同一子网后出现间歇性失联有些场景是既想用 IB 原生模式又想让部分节点起 RoCE 走以太网兼容结果同一个子网里两种模式并存实际通信时好时坏。根因是 IB 和 RoCE 在报文头、地址解析和服务机制上不一样IB 原生使用 16 位 LID 和 SMP 管理RoCE 使用 GID 和 IP 地址两者不能像一个二层网段里的两种协议那样透明兼容。即便打开同一端口也只能选一种模式不能同时承载。我在实际项目里会把这些节点按模式拆成独立子网分别跑独立 SM需要跨模式通信时通过上层应用层路由完成而不是在链路层强行打通。混布不是不行但必须提前把拓扑隔离设计好否则排障成本远超省下的那几台交换机费用。5. 验证收尾perftest、sminfo 与一套自检清单5.1 用 perftest 做一次端到端带宽与延迟体检perftest 是 IB 网络最可信的验证工具。先在一个节点上起服务端另一个节点连上来测命令如下# 节点 A服务端 ib_write_bw -d mlx5_0 -a -p 5001 # 节点 B客户端节点 A 的地址 ib_write_bw -d mlx5_0 -a -p 5001 10.0.0.1这里-d指定 HCA 设备名-a表示自动探测可用的 GID 索引-p指定端口。执行前要确认两台机器的 ib0 接口已经配置好 IP比如ip addr add 10.0.0.1/24 dev ib0。结果里看两个数吞吐量是否达到该速率档位的预期 EDR 或 HDR 理论值的 90% 以上延迟是否稳定在微秒级。延迟抖动特别大时多半是 QoS 或链路 credit 调度的问题。5.2 用 sminfo 与 ibqueryerrors 检查管理平面物理链路达标不代表控制面无隐患。我会定期跑两条命令做巡检sminfo看当前 SM 的 GUID 和优先级ibqueryerrors.pl看全网端口错误计数。sminfo 能及时发现主 SM 漂移ibqueryerrors 能看到 CRC 错误、包丢弃计数和 credit 不足事件的累积。错误计数不是看到就慌只要不持续增长网络就是稳定状态如果每几分钟就在涨说明链路层有不稳定的对端在反复重传必须查线缆和端口。5.3 一张自检清单收住两端每次交付 IB 网络前我会用一张清单过一遍驱动确认ibv_devinfo输出正常、SM 主从明确且 GUID 固定、所有端口 State Active、SL2VL 映射三端一致、perftest 吞吐达到预期、错误计数器不增长。这套流程走过去网络基本不会在应用上线时给惊喜。这些年踩过的坑告诉我IB 的问题很少出在“网卡坏了”大多数都出在规范里的某些默认行为和我们自己的想当然之间。希望帮到你。本文还有配套的精品资源点击获取 深度解析IB Specification 2.1：子网管理器、QoS与链路层流控机制
简介InfiniBand 架构规范卷1Release 2.0是IBTA正式发布的高速网络通用规格文档主要面向数据中心和高性能计算领域的架构师、网络工程师及RDMA研发人员用于理清InfiniBand体系结构、虚拟化扩展、RoCE与RDMA增强等核心机制并理解链路层、传输层、子网管理及服务质量等底层规范。压缩包内为单个PDF文档大小约14.65MB正文保留从1.0到2.0的完整修订历史并展开说明虚拟化支持、RoCE-v1/v2附件、MPE内存保护扩展中的原子写与冲刷、Network Probe、大规模radix交换机管理、速率限制器与最小带宽、VPort QoS仲裁以及XDR速率支持等特性方便逐版对照功能演进。相比零散的技术博客这份规范能提供协议设计层面的权威细节适合做技术选型、硬件实现或组网方案评估对需要排查互操作问题、评估新特性影响的团队也是不可或缺的参考依据。目前已有354人学习。1. IB Specification 2.1 在救什么不止是带宽是协议栈我真正把 IB Specification 这个标题当回事是在一个 AI 训练集群里两台 A100 服务器用 100Gb 的 IB 卡直连跑分布式训练实测带宽却只有 40Gb 出头GPU 利用率上不去谁都说不清瓶颈在哪。排查到最后问题不出在硬件而出在子网管理器没拉起来、端口速率协商不一致这些“协议栈层面”的事。IB Specification 2.1 说的不是某一个网卡型号而是 InfiniBand 这套互连规范本身链路层流控、子网管理、LID/GID 寻址、QoS 映射、传输层对偶队列全部被定义在一本规范里。它解决的是高性能计算和 AI 训练场景下以太网“丢包后靠重传兜底”解决不了的延迟问题。本篇我按自己部署过的 IB 网络来拆不背规范条文只讲能上手的机制、命令和坑。2. 协议栈拆开看IB Specification 2.1 把链路、寻址、QoS 管到哪一层2.1 子网管理器为什么是 IB 的控制面“黑匣子”InfiniBand 和以太网最大的区别在控制面。以太网靠 MAC 地址学习完成转发IB 靠一个集中式子网管理器Subnet ManagerSM发现拓扑、分配 LID、计算路径再通过管理报文把配置下发到每个交换机和网卡。普通节点上的 IB 网卡只是子网管理代理SMA它不自己决定转发路径只被动响应 SM 的请求。这个模型决定了 IB 网络的启动顺序SM 先起来全网端口才能拿到地址SM 挂了已经被分配的 LID 不会立刻消失但新的连接和路径计算都会陷入停滞。正因为 SM 是控制面它往往成了排障时最容易被忽略的“黑匣子”。端口状态显示 Active不代表端到端路径可用SM 计算出的路径是最短路径树遇到不对称拓扑或低速链路它也不会自动绕行。Specification 对 SM 的行为描述得非常细但摸底时你只需要确认三件事SM 是否在运行、是否唯一、有没有把路径算对。常见做法是跑一个 opensm然后用命令确认它已经成为 Master# 先生成默认配置方便后面按需改 opensm -c /etc/opensm.conf # 用节点 GUID 固定 SM 身份并后台运行 opensm -g 0x02c9030100a1b2c3 --conf /etc/opensm.conf -B第一条命令是让 opensm 生成一份完整的默认配置里面包含平滑切换、QoS 策略开关、日志级别这些参数。第二条命令里的-g指定 GUID把 SM 的身份钉死--conf指向刚才生成的配置-B让它后台运行。如果日志输出里有Master Subnet Manager说明它已经接管全网。多台机器同时起 opensm 时需要保证优先级不同否则主从选举会抖动全网 LID 会被反复重新分配。2.2 LID、GID 与路径计算寻址不是 MAC 表IB 网络里每个端口有两个地址理解这两个地址是读规范原文的敲门砖。LID 是子网内有效的 16 位本地标识类似以太网里的二层地址但作用范围只限于当前子网GID 是 128 位全局标识由子网前缀加 EUI-64 组合而来用于跨子网或 RoCE 场景。转发全程只看 LIDSM 算好路径后交换机端口会维护一张以 LID 为索引的转发表。因此 LID 分配的稳定性格外重要节点重启、SM 切换都可能让 LID 变化而上层连接如果硬编码了旧 LID就会失联。网卡上拿到的 LID 可以直接用 ibstat 查看ibstat | grep -E Local device ID|Port输出中的Local device ID就是本端口的 LID一般显示成0x0002c9030100a1b2c3这样的十六进制。排查时第一眼先看它是不是全零如果 LID 全零说明 SM 还没分配地址链路必然是通的但上层通信不可用。这类“链路 Active 但 LID 归零”的现象在双机直连场景里尤其常见根因往往是两台机器都装了 opensm 又都没有正确选中 MasterSM 实际处于 init 状态。路径计算也要提防黑匣子效应。SM 默认按最短路径树下发转发表如果网络里存在非对称链路例如左边是 4X EDR、右边是 2X EDRSM 不一定每次都会绕开慢链路。要看清实际路径我会在评估阶段用ibdiagnet -p导出一份路径表确认关键端到端的那一跳落在预期链路上。这个动作看起来多余但在 IB 网络里是唯一能验证“控制面是不是真的按你想的在转发”的手段。等网络跑到几百个节点再靠 ping 去摸路径就不现实了。2.3 VL/SL 与流控丢包由设计避免以太网靠 PAUSE 环或 PFC 做反压但反压风暴一出现整个交换域都可能抖。IB 链路层用的是基于 credit 的流控发送端口只有拿到接收端口回授的 credit 才能继续发没有 credit 就停下来等。这份 credit 与虚拟通道VL绑定每个物理端口可以创建多个 VL不同 VL 之间互相隔离。报文的服务等级SL字段在进入端口时会被映射到某一个 VL而 SL2VL 映射表由 SM 统一配置下发不是网卡自己协商。这个设计把“不同优先级的业务在链路内部怎么排队”变成一张可下发的表。最常用的划分方式如下SL 值典型业务建议 VL0控制与管理流量VL01MPI/RDMA 计算流量VL12存储复制流量VL2SL0 留给 SM 和诊断报文SL1 给计算业务SL2 给存储。这样当存储流量把 VL2 打满时VL1 里的计算流量不会与其争抢同一队列。注意这里的语义区别SL 是报文头上的标签VL 是链路层实际承载通道交换机每个 VL 都有自己的仲裁器。所以配置 QoS 时必须同时看主机侧和交换机侧的 SL2VL 映射只改一头必然出问题。credit 流控失效时会出现 IB 特有的 credit 死锁两端的报文分别占住不同的 VL互相等对方释放 credit。规范靠 VL 仲裁和多路径绕开来缓解但运维侧能做的是不要把所有流量赶进同一个 VL。我见过不少集群把 MPI 和存储复制放在同一个 SL 0 上短时间没问题一旦存储打满整个计算网络的带宽全部塌方这就是典型的把控制面和数据面混在一个队列里导致的灾难。3. 按 IB Specification 2.1 搭一套最小 IB 集群从驱动到 opensm3.1 最小硬件与软件清单两张卡、一根线也能开跑搭建 IB 实验环境不需要整柜交换机。两台服务器各插一块 InfiniBand HCA中间用一根无源铜缆直连就构成一个最小的 IB 子网。这个拓扑里仍然需要有一个节点运行 SMopensm 可以装在主机上没有交换机时SM 直接通过主机网卡发现对端并分配 LID。很多人在这一步就停住了因为他们以为 IB 必须配交换机其实双机直连就能验证 RDMA 语义和大部分性能指标。硬件以外软件栈按发行版略有差异。RHEL/CentOS 系是ibutils、infiniband-diags、rdma-core和opensmUbuntu/Debian 系是rdma-core、infiniband-diags、ibutils2。我习惯把诊断工具和数据面驱动分开看待数据面驱动负责网卡收发诊断工具负责看 SM 和链路状态。下面的安装命令覆盖 Ubuntu 侧最常见的一整套apt install -y rdma-core infiniband-diags ibutils2 opensm perftestrdma-core 提供内核模块和 libibverbsinfiniband-diags 提供 ibstat、ibstatus、ibdiagnetlibibutils2 提供 ibping 这类工具opensm 不用说是 SMperftest 是带宽延迟测试集。装完之后可以先跑一次ibv_devinfo确认驱动已经认到 HCA再继续往下走。3.2 装驱动与固件检查modinfo 与 ibv_devinfo 逐项过IB 网卡最常见的驱动是 mlx5_core对应 Mellanox/NVIDIA ConnectX 系列。装完驱动后第一件事不是测带宽而是检查固件版本和驱动是否匹配。固件版本差太远会出现奇怪的的现象链路能协商到 EDR但 RDMA 报文一上来就丢。检查方式很直接ibv_devinfo -v | egrep hca_id|fw_ver|node_guid|sys_image_guid|max_qp|active_speed这个命令会把每一块 HCA 的固件版本、GUID、最大 QP 数、当前协商速率都打出来。active_speed直接告诉你链路协商到了几倍宽、什么速率25.0 Gb/sec是 EDR14.0 Gb/sec是 FDR。如果这里显示 4X SDR 这种最低档赶紧查线缆和两端端口配置大概率是线缆问题或者端口被限速。还要确认内核里的 rdma 子系统正常挂载。现代内核上直接执行rdma link show会输出每个 IB/RoCE 设备的状态。看到state ACTIVE physical_state LINK_UP才算过了第一关如果是state INIT说明 SM 还没接管链路。这里多说一句很多翻车不是硬件坏了而是驱动加载顺序不对尤其是在容器环境里忘了把/dev/infiniband/*和/dev/rdma_cm都映射进去宿主机看到的是好的容器里全盲。3.3 用 opensm 拉起子网命令、配置与三种启动方式opensm 启动方式有三种前台运行、后台运行、由 systemd 管理。手排障时我建议前台运行因为日志直接打在终端Ctrl-C 停掉也快。确认没问题后再改成后台或服务方式。最基础的前台启动命令只有一行opensm -g 0x02c9030100a1b2c3 --conf /etc/opensm.confproduce默认会往/var/log/opensm.log写日志。启动后立刻看一行关键信息日志里的Master Subnet Manager说明这一实例抢到了主 SM。如果显示Standby Subnet Manager说明同一子网里已经有一个更高优先级的 SM当前节点只是备用。双机直连时如果两台机器都默认自启 opensm有可能出现主备来回切换每次切换都会全端口重新下发 LID正在跑的 RDMA 连接全部断掉。避免方法是在配置里指定优先级一台设成 15另一台设成 5。配置项里还有几个值得提前调的参数subnet_timeout、maxhops、qos_policy_file。前两个影响全网收敛速度qos_policy_file指向 QoS 策略文件如果你想用上一章说的 SL2VL 分层就必须在这里挂一份。没挂 QoS 策略时opensm 会按默认策略把所有 SL 映射到 VL0功能上没问题但存储流量和计算流量就会互相干扰。3.4 确认链路正常ibstatus 与 ibdiagnet 逐行解读链路拉起来之后不要急着跑应用先用诊断工具把状态彻底确认一遍。第一个必看的是 ibstatus它输出比 ibstat 更详细直接能看到物理状态和链路宽度ibstatus关键行是State: Active和Physical state: LinkUp以及Rate: 100这样表示 100Gb/s 的速率。速率和宽度两个值都要盯4X EDR表示 4 个 lane 每个 25Gb/s2X EDR只有 2 个 lane性能直接减半。如果两端 HCA 能力不一致链路会协商到较低的那一档这时候性能不是玄学是协商结果摆在明面上只是你没看。下一步跑ibdiagnet -pe它会把所有端口错误计数器、LID、SM 状态导出来。要关注的是PortErrors部分有没有 CRC error 和 link integrity error。这两个错误出现基本可以断定线缆或光模块有问题或者链路两端在降速抖动。ibdiagnet 跑完还会生成一份ibdiagnet.pm文件里面是 SM 下发的路径表留作后面对比用非常方便。运营一个 IB 网络每次变更后留存这份文件等于给网络买了后悔药。4. 避坑IB 子网管理器与链路层最常见的 5 个翻车现场4.1 现象链路显示 Active但 RDMA 操作直接超时直接出现过一次双机直连IB 卡驱动正常端口状态 Activeibping能通但是跑ib_write_bw时一端报Connection timed out。查了很久才发现两台机器各自都装了一个 opensm并且都以默认优先级启动系统交替选择 MasterLID 分配结果在不断变化RDMA 连接刚建立就被打断。原因在于 SM 主从不稳定。两个相同优先级的 SM 实例在同时工作时会抢主抢主过程中子网会重算转发路径期间新连接无法建立已有连接因 LID 漂移失联。解决办法简单粗暴指定唯一主 SM另一个停掉或降优先级。用opensm --prio 15启动主节点备用节点用--prio 5然后重启所有 IB 服务。这个操作在我们的环境里一分钟后网络恢复稳定。4.2 现象opensm 起来后全网 LID 集体漂移环境不大从头到尾就三台机器一个交换机某天固件升级后发现所有节点的 LID 和升级前完全不同原来写死在应用里的 LID 全部失效。检查后确认是 SM 的 GUID 变了固件升级把 node GUID 重置opensm 实例身份跟着变主从选举重新来了一次全网 LID 也跟着重排。这不算故障但在生产环境里会引起一阵慌乱。解决思路是给 SM 钉一个固定身份不要依赖网卡原有 GUID。在 opensm 启动命令里显式传-g或者在配置文件中写死sm_guid。还有一种更彻底的做法是启用 opensm 的 persistence 文件它会记录上一次 LID 分配结果尽量复用旧 LID。这个特性默认开着但如果日志目录被清过persistence 也就失效了。所以重要节点别在应用里硬编码 LID能走 GID 或主机名解析就走解析这才是治本。4.3 现象配置 QoS 映射后带宽不升反降按文档启用了 QoS 策略把 MPI 流量放在 SL1、存储流量放在 SL2结果全网带宽反而从满速掉到六七成。看端口计数器丢包没有明显增加但吞吐上不去。这就是典型 SL2VL 映射与交换机侧 QoS 不一致导致的现象主机侧把报文标成了 SL1交换机端口却没有对应的 SL1 到 VL1 映射默认全部落到 VL0又触发了链路仲裁的公平限制。QoS 配置必须是端到端的统一动作。主机 HCA、接入交换机、核心交换机三者的 SL2VL 映射表必须一致并且每个 VL 的仲裁权重也要统一考虑主机发起的流量和交换机转发流量。我们最后把 QoS 配置文件固化成一份模板通过自动化下发给所有设备才解决这个问题。调 QoS 最怕只改一半很小的一个映射不一致表现出的就是整体带宽下降而不是报错。4.4 现象MPI 应用时好时坏单测带宽却始终稳定这是最让人头疼的一类问题两台机器之间跑ib_write_bw能跑满一上 MPI 应用就随机卡住有时候几分钟有时候几小时。单测稳定说明物理链路和驱动基本没问题问题出在上层传输选型和参数匹配。MPI 在 IB 上有多种传输路径openib、ucx、rdma_cm不同路径对内存注册、连接建立方式的处理完全不同默认选错就会在特定报文大小或并发度下触发死锁或超时。常见做法是先切到 UCX 传输层并调整超时参数让 MPI 直接走 RDMA 写同时把UCX_TLS限定为rc_verbs或rc_mlx5避免 frc 连接数膨胀。另外要检查ulimit -l锁定内存限制是否够大IB 通信前要做内存注册限制太小会导致注册失败在日志里表现为mlx5_0: create qp failed。这类问题属于慢性的排查时要有耐心一条条排除别一上来就怀疑网卡。4.5 现象IB 与 RoCE 混布在同一子网后出现间歇性失联有些场景是既想用 IB 原生模式又想让部分节点起 RoCE 走以太网兼容结果同一个子网里两种模式并存实际通信时好时坏。根因是 IB 和 RoCE 在报文头、地址解析和服务机制上不一样IB 原生使用 16 位 LID 和 SMP 管理RoCE 使用 GID 和 IP 地址两者不能像一个二层网段里的两种协议那样透明兼容。即便打开同一端口也只能选一种模式不能同时承载。我在实际项目里会把这些节点按模式拆成独立子网分别跑独立 SM需要跨模式通信时通过上层应用层路由完成而不是在链路层强行打通。混布不是不行但必须提前把拓扑隔离设计好否则排障成本远超省下的那几台交换机费用。5. 验证收尾perftest、sminfo 与一套自检清单5.1 用 perftest 做一次端到端带宽与延迟体检perftest 是 IB 网络最可信的验证工具。先在一个节点上起服务端另一个节点连上来测命令如下# 节点 A服务端 ib_write_bw -d mlx5_0 -a -p 5001 # 节点 B客户端节点 A 的地址 ib_write_bw -d mlx5_0 -a -p 5001 10.0.0.1这里-d指定 HCA 设备名-a表示自动探测可用的 GID 索引-p指定端口。执行前要确认两台机器的 ib0 接口已经配置好 IP比如ip addr add 10.0.0.1/24 dev ib0。结果里看两个数吞吐量是否达到该速率档位的预期 EDR 或 HDR 理论值的 90% 以上延迟是否稳定在微秒级。延迟抖动特别大时多半是 QoS 或链路 credit 调度的问题。5.2 用 sminfo 与 ibqueryerrors 检查管理平面物理链路达标不代表控制面无隐患。我会定期跑两条命令做巡检sminfo看当前 SM 的 GUID 和优先级ibqueryerrors.pl看全网端口错误计数。sminfo 能及时发现主 SM 漂移ibqueryerrors 能看到 CRC 错误、包丢弃计数和 credit 不足事件的累积。错误计数不是看到就慌只要不持续增长网络就是稳定状态如果每几分钟就在涨说明链路层有不稳定的对端在反复重传必须查线缆和端口。5.3 一张自检清单收住两端每次交付 IB 网络前我会用一张清单过一遍驱动确认ibv_devinfo输出正常、SM 主从明确且 GUID 固定、所有端口 State Active、SL2VL 映射三端一致、perftest 吞吐达到预期、错误计数器不增长。这套流程走过去网络基本不会在应用上线时给惊喜。这些年踩过的坑告诉我IB 的问题很少出在“网卡坏了”大多数都出在规范里的某些默认行为和我们自己的想当然之间。希望帮到你。本文还有配套的精品资源点击获取