企业官网建设流程全解析

简介：这份资源为 InfiniBand 架构规范第一卷 Release 1.9 的官方草案 PDF，2024 年 8 月 31 日记录，面向数据中心网络工程师、高性能计算研究人员及存储互连领域的技术人员，用于追踪 InfiniBand 最新规范演进、支撑高性能网络方案设计与技术预研。文档完整收录了自 2000 年 1.0 至 1.9 的全部修订历史，并重点梳理了各版本引入的关键特性：1.3 集成 XRC，1.4 增加虚拟化与 RoCE 附录，1.5 引入 MPE 附录、速率限制器与最小带宽保证，1.6 添加扩展操作码和 VERIFY 操作，1.7 增加网络探测附录，1.8 新增 NeVerMore 解决方案及 XDR FEC 模式等。这些细节能帮助读者全面理解 IB 的协议演进逻辑与设计取舍。全部内容收于 1 个 PDF 文件，压缩包大小 14.39MB，适合离线阅读与权威引用。目前已有 841 人学习，对需要做技术预研、方案选型或深度理解 IB 底层协议的工程师具有扎实的参考价值。

1. IB Specification Vol 1-Release-1.9-Draft-2024-08-31：一份难啃但对运维很有用的行业基准

做 GPU 集群或者 HPC 机房的人，应该都见过 InfiniBand 交换机背板上那条粗线，以及 ibstat 输出的那个“Rate: 400Gb/s”之类的结果。但真正把这个链路从“能通”推到“性能符合预期”的，是 IB 协议栈底层的这套规范。标题里这份文档，就是 IB（InfiniBand）架构规范的第 1 卷，1.9 版本草稿，2024 年 8 月 31 日签发。它管的核心范围是物理链路、链路层数据包、网络层路由、传输层语义，以及子网管理的基本模型。换句话说，你在 NVIDIA 的早期接入节点上看到的那一套参数，最终都能在 Vol 1 里找到出处。适合读它的人不是写驱动的内核开发者，而是要在真实机房把速率、MTU、SL 映射、缓冲区信用、拥塞控制调正常的网络工程师。正因为它难啃、没有“例子工程”，大部分人拿到手翻两页就放弃了，反而导致后续在集群上踩了一堆很基础的坑。

2. Vol 1 在整套规范里管哪一段：架构分区与交付物全貌

2.1 物理层在 Vol 1 中的地位：链路速率、宽度与编解码的尽头

InfiniBand 和以太网最大的差异之一，是 IB 的物理层从规范层面就把“链路宽度”“单通道速率”“编解码方式”“前向纠错”全部写死成可选能力的集合。你在 Vol 1 里不会看到“建议千兆”这类字眼，看到的是一张明确的速率表：SDR、DDR、QDR、FDR、EDR、HDR、NDR，一直到 XDR。每个速率对应的单通道比特率是固定的，链路宽度则以 1x、2x、4x、8x、12x、16x 这些倍数为单位。实际端口速率，是“单通道速率 × 通道数”，再扣除编解码开销之后得到的“有效数据速率”。

我一般会把 Vol 1 的物理层当成交互的核心依据。比如一个新的 HDR 交换机接入现有 EDR 结构里，问题往往不出在“能不能亮”，而是出在“自动协商后跑到什么速率”。如果两边一个支持 50Gb/s 单通道的自适应，另一个只支持 25Gb/s，协商结果会落到 25Gb/s。Vol 1 定义了这种自适应链路训练的过程，但没规定设备的策略偏好。结果就是：同一批设备在同一个子网里，因线缆品质、端口配置不同，出现半速降级、FEC 不一致、误码率升高的现象。

配置上的参考做法是：给所有端口制定统一的“目标速率”策略，不依赖自动协商。更具体地说，在子网管理器里可以对 switch port 做速率限制，强制端口在 4x HDR 或者 4x EDR 这类明确档位，而不是让端口自选。这样做牺牲了一点灵活性，却换来了整个子网的行为一致性。对于跑 RDMA 训练作业的集群，一致性通常比单点的峰值更重要，这一点在 Vol 1 的链路训练和链路错误恢复章节里反复强调过。

物理层里还有一个容易被忽略的部分是“线缆和光模块的编码协商”。Vol 1 把 8B/10B、9B/10B、64B/66B 这几代编码定义了不同开销。你在规划带宽的时候，不能直接拿“单通道速率 × 宽度”当成理论净荷，要把编码开销、FEC 开销和报文头部开销都扣掉。我见到过不止一次，有人拿着 200Gb/s NDR“理论速率”规划存储集群带宽，结果实测只有 170Gb/s 左右，就是没算编码和 FEC 的成本。Vol 1 在物理层、链路层都会给出对应的计算口径，看懂了这一层，后续调优才有依据。

2.2 链路层与网络层：从 LRH 到交换转发，一切都与 LID 相关

链路层在 Vol 1 里定义了 IB 数据包的第一个关键头部 LRH（Local Route Header），里面携带源 LID、目的 LID、虚拟通道（VL）、服务等级（SL），以及用于转发的重要字段“包长”。和以太网的 MAC 地址寻址不同，IB 域内的转发完全依靠子网管理器（SM）预先分配的 LID，LID 只有 16 bit，但在启用扩展 LID 之后，Vol 1 支持更大的寻址空间，这对 4 万节点以上的大规模集群是必须项。

交换机的转发行为相对简单，它看到 LRH 里的 DLID，就查本地的线性转发表，把包从对应端口丢出去。但这里的复杂度在“虚拟通道”上。Vol 1 定义了 VL0 到 VL15，其中 VL15 保留给子网管理包，其余 VL 用于数据。每条物理链路上同时存在多个 VL，每个 VL 有独立的缓冲区信用机制。交换机的仲裁器会按 VL 仲裁表来决定优先发哪个通道，因此你可以通过改变 VL 仲裁权重，实现不同服务等级之间的带宽隔离。

实际排障时，我遇到过“整条链路利用率不错，但时延抖得厉害”的情况。最后查下来是两个应用都跑在 VL0 上，队列互相抢，没有做任何 SL 到 VL 的映射。Vol 1 链路层的仲裁机制本身就是为这个场景准备的，它给了你基于 SL 的 QoS 工具，但如果你的子网管理器配置里所有 SL 都映射到 VL0，等于把这个功能废掉。更合适的做法是对时延敏感的控制面流量走 VL0，对带宽型大数据走另一个数据 VL，仲裁权重按业务类型区分。

网络层的部分，Vol 1 规范了 IB 路由器如何处理跨子网流量。它会在 LRH 之后插入 GRH（Global Route Header），使用 64 bit 的 GID 做全局寻址。GID 通常由子网前缀和端口 GUID 组合而成。路由器的职责是解析 GRH，替换 LRH 的源目的 LID，然后沿下一跳继续转发。从这个意义上讲，Vol 1 的逻辑很清晰：域内用 LID 路由，域间靠 GID 路由，LID 只是所在子网的一个临时标签。子网管理器重启后，LID 可能重新分配，而 GUID 和 GID 是永久标识，这也是我们在做资产管理时会用 GUID 而不是 LID 去标记主机的原因。

2.3 传输层：RC、UC、UD、XRC 这些术语告诉你数据怎么可靠地走

链路层只负责把包从一个端口搬到另一个端口，而传输层才真正定义“两个通道适配器（CA）之间的通信语义”。Vol 1 传输层给出的服务类型，常见的是可靠连接（RC）、不可靠连接（UC）、不可靠数据报（UD），以及扩展的 XRC。RC 提供基于队列对（QP）的可靠字节流，有确认、重传、原子操作等一堆保障机制，是 RDMA 写操作最用得多的类型。UD 则像 UDP，包之间无上下文，适合发管理消息或广播。

这里最容易被误解的，是很多同学把“链路层不丢包”等同于“传输层不需要丢包重传”。实际上，Vol 1 规定的“基于信用的流控”只保证端口缓冲区不会因拥塞而丢包，但不保证光模块上的误码、FEC 纠正失败、交换芯片内部异常不会造成包损坏。一旦 ICRC 校验失败，接收方照样丢弃数据包。RC 服务会把这种情况交给重传机制处理，而 UC/UD 就直接丢了。因此，在规划高性能集群时，如果业务用的是 UD 类型，就别指望 IB 的“无损网络”替你兜底。

Vol 1 传输层还有一个重要概念叫“操作类型”。最常用的是 RDMA Write、RDMA Read、Send/Receive 和原子操作（Atomic）。RDMA 写可以直接把数据写到远端内存地址，不需要远端 CPU 介入，这是 AI 训练里 all-reduce 之所以能利用网卡卸载的基础。但 Vol 1 也给了“原子性”约束：原子操作作用在 64 bit 对齐的地址上，且在目标节点上表现为排他性。到了 Vol 1 的 1.9 草稿阶段，传输层的总体框架没有翻天覆地的变化，更多是把链路速率的提升、错误确认策略、拥塞控制语义补齐，让这些旧机制在更高带宽下仍然有效。

3. 把规范用起来：从带宽计算到参数核查的可执行读法

3.1 用一段脚本解析速率表，算清“理论带宽”和真实净荷

Vol 1 的物理层里有一张“速率-编码-通道”的关系表，所有带宽规划最终都要回到这张表。我读规范第一遍时，光记数字记不住，后来写了个小脚本直接算，顺便验证不同编码方式的开销。下面这段话是一个最小实现，用来从单通道速率、编码效率、通道数推算有效带宽的上限，注意这里还没有算报文头部和 FEC。

# ib_bandwidth.py # 依据 IB Vol 1 物理层速率表做“有效净荷带宽”初算 rates = { "SDR": (2.5, 8/10), "DDR": (5.0, 8/10), "QDR": (10.0, 8/10), "FDR": (14.0, 9/10), "EDR": (25.0, 64/66), "HDR": (50.0, 64/66), "NDR": (100.0, 64/66), "XDR": (200.0, 64/66), } lanes = [1, 4, 8, 12, 16] def effective_gbps(speed: str, width: int) -> float: line_rate, code_eff = rates[speed] # 单通道速率 * 编码效率 * 通道数，得到可用净荷比特率 return line_rate * code_eff * width for speed in ("SDR", "EDR", "HDR", "NDR", "XDR"): for w in (4, 8): gbps = effective_gbps(speed, w) # /8 转成字节，再 /1000 转成 GB/s print(f"{speed}-{w}x: {gbps/8/1000:.2f} GB/s")

这段代码的逻辑很简单：单通道速率乘以编码效率，再乘链路宽度。例如 EDR 单通道 25Gb/s，64B/66B 编码的有效率约 97%，4x 链路就是 25×0.97×4，得到约 97Gb/s，折合约 12GB/s。HDR 的 50Gb/s 如果是 8x 链路，算出来的数字约 48.4GB/s。实际场景里，这个值还要接着扣 IB 网络报文头（LRH+BTH+ICRC 等）以及 FEC 的开销。

关键理解是：Vol 1 里写的“速率”是物理层的线缆比特速率，不是应用能拿到的速率。我们做容量规划时，要把最大链路层帧大小（MTU 通常 4092 或 4096 字节）去掉 40 字节到 60 字节头部后的载荷比例也算进去。假设 MTU 为 4096，扣掉 LRH 8 字节、BTH 12 字节、ICRC 4 字节这类开销，实际数据载荷大概占 99% 左右，这个比例还算能接受。真正吃掉带宽的是编码层的开销和长距离传输时开启的 FEC，两者加起来可能让“标称 400Gb/s”的端口只能跑出 340Gb/s 到 370Gb/s。

3.2 子网配置的最小参数集：从端口速率到 MTU 再到 SL 映射

在真实集群上，配置子网管理器（通常跑在 OpenSM 里）时，参考 Vol 1 的约束，我一般只碰几个核心参数，改多了容易出事。首先是一致性参数：整个子网的 MTU。Vol 1 在数据包长度字段上定义得很清楚，路径上所有端口必须支持该 MTU，否则子网管理器在计算路径时会把包标记为“不可达”。实际操作中建议把全网 MTU 统一成 4092 或 4096，既不影响小包转发，也把大帧的带宽利用率拉高。

第二个是端口可达速率。设置方式不是在 OpenSM 里直接指定“HDR”，而是让交换机端口的物理层训练自动完成，但通过“不宣传更高速率”的方式把上限卡住。例如你希望全网跑 EDR，不期望某些端口自动协商到 HDR，那么有两种做法：一是物理上确认线缆和模块只支持 EDR；二是在交换机端口配置里把支持的最高速度上限锁定。Vol 1 在链路训练里其实留了“速度公告”字段，设备厂商据此实现端口能力上报。锁定上限是硬约束，不是软偏好，适合统一建网需求。

第三个容易被忽略的参数是“强化端口计数”和 SL 到 VL 的映射。SL 是服务等级，它出现在 LRH 中，用于区分业务优先级；VL 是链路层虚拟通道，代表在物理链路上占用的独立缓冲区。两者对应关系必须由子网管理器来发布。在 QOS 配置中，把同一 SL 映射到同一个 VL，然后给这个 VL 配置仲裁权重，是标准玩法。配置完成后，要通过sminfo和ibdiagnet验证全网映射一致，避免出现“节点 A 把 SL3 映射到 VL1，节点 B 映射到 VL2”这种割裂状态。

3.3 用 LRH 解析脚本验证链路层数据包，确认实际转发行为

尝试直接用抓包工具看 IB 网络流量是不现实的，IB 链路层不是以太网，即便有镜像端口，标准服务器网卡也收不到。常见做法是：先从交换机计数器和子网管理工具里拿到端到端丢包和错误统计，再按 Vol 1 的数据包格式做局部解析。下面这段 Python 代码展示了解析 LRH 基本字段的最小逻辑，用来处理从 IB 诊断工具得到的二进制抓包片段。

# parse_lrh.py # 解析 IB 数据包前 8 字节 LRH，输出关键转发字段 import struct def parse_lrh(pkt: bytes): # pkt[0:2] 目的 LID dlid = struct.unpack(">H", pkt[0:2])[0] # pkt[2:4] 包含 VL(高4位)、SL(次4位)、LNH(2位)等 raw = struct.unpack(">H", pkt[2:4])[0] vl = (raw >> 12) & 0xF sl = (raw >> 8) & 0xF lnh = (raw >> 6) & 0x3 # pkt[4:6] 低 11 位是包长（以 4 字节字为单位） length_words = struct.unpack(">H", pkt[4:6])[0] & 0x7FF length_bytes = (length_words + 1) * 4 # pkt[6:8] 源 LID slid = struct.unpack(">H", pkt[6:8])[0] return { "dlid": dlid, "slid": slid, "vl": vl, "sl": sl, "lnh": lnh, "len_bytes": length_bytes, } sample = struct.pack(">HHHH", 0x1234, 0x01A0, 0x0100, 0x5678) info = parse_lrh(sample) print(info)

这段代码对应 Vol 1 对 LRH 的定义：前 2 字节是目的 LID，随后 2 字节是 VL、SL 和下一头类型等标志位，再往后 2 字节的包长字段表示“整个数据包有多少个 4 字节字”。这里有个细节，长度字段是编码后的值，需要加 1 再乘 4 才是真正的字节数。这个设计用于处理边界对齐，在实际改包或生成测试包时容易踩坑。

验证链路层行为更实际的方法是使用子网管理工具。ibdiagnet能够扫描整个子网，输出各端口的速率、MTU、误码统计和链路状态；ibstatus可以看本机网卡工作参数；perftest里的ib_write_bw则负责在两端跑实际带宽。这套组合比单纯解析报文更接近生产实践。用它们做验收的标准动作是：先固定好 MTU 和速率，再跑ib_write_bw -a做多线程带宽测试，然后对照 3.1 节的净荷上限评估损耗是否合理。

4. 从 1.8 到 1.9 草稿：这版 Vol 1 到底新增了什么值得关注的东西

4.1 草案背后是更高的端口速率和更强的拥塞控制需求

InfiniBand 架构从 1.8 到 1.9 草稿的演进，最大的外部驱动力是 AI 集群的带宽需求暴涨。早期 Vol 1 设计的拥塞控制比较简单：当交换机端口检测到拥塞时，给数据包打一个标记，接收端根据标记向发送端返回 CNP（拥塞通知包），发送端收到后降低注入速率。这个机制在当时够用，但在 GPU 集群中，流量模式往往是“多打一”，即多个节点同时向同一个 GPU 节点写数据。Vol 1 草稿里强调更多的是如何使这种“多打一”模式下的拥塞控制更快收敛，减少对尾部延迟的影响。

和很多数据中心网络的拥塞控制相比，Vol 1 定义的 CC 机制有趣的地方在于它按“流”而非按“报文”做速率调节。它引入了一个拥塞控制映射表（CCT），发送端查表决定当前允许的报文注入速率。1.9 草稿大概率会继续完善相关问题，包括标记阈值的自适应、CCT 的自动校准等。这背后的工程含义是：你不能再把拥塞控制单纯理解为“交换机丢包就降速”，而要把它当成基于反馈的闭环系统，所有设备必须支持同样版本的 CC 语义。

对于生产运维，我建议不要把草案里的新 CC 特性直接开在生产网络上，特别是在固件和驱动没有完全对齐的情况下。更好做法是先在实验室拓扑上做小范围验证，确认新 CC 在“多打一”模式下能明显降低 P99 时延，再逐步扩大范围。InfiniBand 网络设计里，时延抖动对大规模并行训练的影响非常大，CC 做得好的网络和不做的网络，跑同一批任务可能相差 20% 以上。

4.2 NDR/XDR 速率级联与 FEC 的代价

Vol 1 1.9 草稿承载的另一个重头戏是 NDR 和 XDR 速率。NDR 单通道 100Gb/s，XDR 单通道 200Gb/s，配合 4x 或 8x 宽度，单端口就能达到 400Gb/s 甚至 800Gb/s。速率提升带来了一个物理层难题：高频下的信号完整性恶化，必须依靠更强大的前向纠错（FEC）来保证可接受的误码率。FEC 是好事，但它有代价：编解码会带来额外的延迟和带宽开销。在高频链路上，如果不用 FEC，链路可能根本达不到标称速率下的误码要求；如果用了 FEC，实际可用带宽又要再降一截。

这个参数在 Vol 1 物理层是有明确定义的，但在商用设备上，FEC 模式通常是“自动协商”的。实操中的翻车点在于：两端设备的 FEC 模式如果不一致，链路会反复试训。我遇到过一次，两台交换机之间光模块开了 RS-FEC，但服务器网卡侧没开，导致链路状态在 Active 和 Degraded 之间来回跳，最终表现为偶发性的 RDMA 超时。排查时看日志才发现 FEC 模式不匹配。

解决方式也很直接：在交换机端口上强制指定 FEC 模式，并让它与对端一致，而不是依赖自动协商。具体命令各厂商不一样，但核心理念是一致的——把 FEC 当作一个需要全网统一规划的配置项，而不是留给设备自适应。Vol 1 赋予链路的训练能力本身是好的，但生产网络更看重确定性。

4.3 新增链路能力如何匹配现有子网管理器配置

当你把一块支持 NDR 的网卡装进现有子网，而子网管理器还是老版本时，大概率会出现“端口状态是初始化失败”的现象。原因在于子网管理器不认识新端口的速率能力，无法正确下发路径计算所需的端口属性。Vol 1 草稿新增的链路速率字段必须由新版 OpenSM 或厂商子网管理器解析。所以在引入新硬件之前，先升级子网管理器版本是一个基本前提。

这里有一个比较实用的部署顺序：先在非生产环境把所有交换机固件、网卡固件、OFED 驱动、子网管理器统一升级到支持 1.9 草案的版本，然后只插入少量新端口做链路测试，确认端口速率协商、FEC 匹配、拥塞控制参数对齐。全部验证通过后，再按批次扩容。这样能避免“新网卡插一个死一个”的状态混乱。

另外，Vol 1 草稿里还有一个容易漏的点是 P_Key（分区键）机制的兼容性。P_Key 用于 IB 子网内的隔离，类似 VLAN。不同版本规范对 P_Key 的默认行为没有大的改变，但高版本 IP 在“部分成员”和“完全成员”的定义上更严格。如果集群里不同节点用的固件版本不一致，可能导致 P_Key 不兼容，节点间看不到对方。因此升级链路速率的同时，也应该检查分区配置是否仍然在每个端口上保持一致。

5. 应用 IB Specification Vol 1 时的高频踩坑：五个真实翻车现场

5.1 踩坑一：把“无损网络”理解成永远不会丢包

现象是：总有人拿 IB 是“无损网络”来反驳丢包排查的必要性。实际跑高负载时，RDMA 传输还是出现了重传，吞吐上不去，但交换机统计里没有任何“拥塞丢包”计数。

原因是 Vol 1 所谓“无损”只指链路层基于信用的流控能避免因缓冲区不足而丢包，不包含物理层误码、ICRC 校验失败、接收端处理不过来等情况。一旦发生链路比特错误，FEC 无法纠正后直接丢包，RC 服务触发超时重传。

解决这个问题要在链路层找根因：检查端口物理误码率、FEC 纠正计数、丢包计数。常用命令是ibdiagnet -c查看误码统计，或直接看交换机show interface counters errors。如果误码率持续增长，优先检查光模块功率、线缆质量、端口清洁度，而不是调大缓冲区。

5.2 踩坑二：MTU 设置只看了交换机，没有看主机侧

现象是：全网交换机 MTU 统一配置成 4096，结果部分主机只能跟部分交换机通信，RDMA 连接建立失败，或者吞吐量极低。

原因是 Vol 1 要求路径上所有端到端端口支持相同或者更大的 MTU，而主机侧 HCA 的 MTU 若是默认 2048，子网管理器计算路径时会取 MSU（最小支持单元）作为路径 MTU。于是交换机那边看似配置好了，路径 MTU 却只有 2048，大包被拆分甚至被丢弃。

解决方式是统一主机侧和交换机的 MTU。Linux 下通过ibstat查看物理端口状态，通过 OpenSM 配置default_mtu，并确认 HCA 固件允许 4096 字节。更保险的做法是在测试阶段用ib_write_bw -m 4096强制最大消息长度，验证整条路径的 MTU 是否真的支持 4096。

5.3 踩坑三：所有服务等级 SL 都映射到 VL0，QoS 形同虚设

现象是：一个集群里既跑存储复制又跑 AI 训练，两者一旦同时高峰，就出现互相干扰。时延敏感的存储服务尾延迟飙升，但几个虚拟通道利用率图都是“一条线顶满”。

原因是默认 OpenSM 配置经常把 SL0 映射到 VL0，所有流量全部挤在同一个虚拟通道。Vol 1 的 QoS 能力是依赖多 VL 来物理隔离的，SL 只是标签，VL 才是真正的通道资源。

解决方式是在子网管理器的 qos 策略里显式增加映射规则，比如把存储流的 SL 设为 2 映射到 VL2，训练流设为 SL3 映射到 VL3，并为这两个 VL 配置不同的仲裁权重。注意仲裁权重反映的是调度比例，如果两个 VL 都持续满负荷，权重只影响公平性，不产生额外的带宽。

5.4 踩坑四：混合速率拓扑下让端口自由协商

现象是：一个子网里既有 EDR 交换机也有 HDR 交换机，服务器网卡全是 HDR。结果某些节点跑出正常速率，某些节点只有 EDR 速率，而且状态在 Active 和降级之间跳。

原因是 HDR 端口和 EDR 端口对上后，自动协商机制会把双方拉到 EDR，这本没有错，但如果线缆是 HDR 规格，而端口策略没有固定，系统就会反复尝试 HDR 并失败后回退。

解决方式是明确“以低支持的一方为准”，把换机到换机互联的端口手动固定为 EDR 对应配置，避免协商振荡。同时确认所有涉及链路的 FEC 模式一致。混合速率拓扑更适合规划成“分区”，而不是“混接”，也就是把所有 HDR 设备放在一个子网，把 EDR 设备放在另一子网，中间通过 IB 路由器相连。

5.5 踩坑五：启用了扩展 LID，但子网管理器没有同步配置

现象是：集群规模超过 4 万端口后，部分节点收不到路由信息，或节点之间时通时断。

原因是 Vol 1 原生 LID 只有 16 bit，可用地址空间约 49152 个，大规模集群需要启用扩展 LID。但子网管理器侧若不开启对应能力，分发的 LID 可能超出对端支持范围。

解决方式是在子网管理器配置中显式开启 extended LID 支持，同时确认交换机芯片和 HCA 固件版本支持。升级顺序是先升级固件，再开启功能，避免出现“管理器发了大 LID 而节点解析不了”的情况。排障时重点看ibdiagnet -l输出的 LID 分配表是否有非连续或者异常大值。

6. 把 Vol 1 的纸面协议变成可复现的机器核查：一个贴近实战的验收方法

与其把规范从头读到尾，我建议把它当成一份“核查清单”的来源，用脚本把链路状态、速率、MTU、FEC 模式集中落盘，形成环境基线。下面是一段很简单的脚本框架，用于在每台计算节点上收集 IB 端口参数。

# collect_ib_baseline.sh for p in $(ibstat -l); do echo "=== $p ===" ibstat $p | grep -E "Rate|State|Physical|Base MTU" done # 也可以去掉 grep 后完整留档 ibdiagnet -r -o ibdiagnet_full.txt

这段脚本的逻辑是：遍历本机所有 IB 端口，打印速率、状态、物理端口信息，再用ibdiagnet生成整个子网的扫描报告。生产环境里的做法是把这些输出收集到单独日志目录，按日期命名，方便日后对比“升级前后是否引入了链路降级”。

实际操作习惯上，我会额外用ib_write_bw跑一轮标准测试，记录每个节点的带宽基线。测试时要固定消息大小、队列深度和线程数，否则数据没可比性。比如统一用ib_write_bw -q 8 -s 4096 -n 10000这样的固定参数。跑完把吞吐和时延记下来，下一次再做同样测试，比较结果是否差超过 5%。

最后想说一句个人习惯：我拿 Vol 1 这类规范去跟现场对照时，从来不会先看正文的图表，而是先翻它的“状态机”和“计数器定义”。因为现场设备日志里报的错，最终都要落到规范里某个状态迁移或某个计数字段上。你把状态机看懂，设备也能和你对话。带着问题去读规范，比从头啃效率高得多。如果你也是从“链路 Down 但不知道先看哪个日志”的阶段过来，希望我的这些实战踩坑记录能帮你少走一点弯路，也希望这份刚出炉的 1.9 草案在你们集群规划中派上用场。

本文还有配套的精品资源，点击获取