1. 从“IB HCA”这个缩写说起它到底指什么第一次看到“IB HCA”这四个字母很多人会一头雾水。我先把这个缩写拆开讲清楚因为搞混了它和普通网卡的区别后面所有配置都会走偏。IB指的是 InfiniBand一种在高性能计算和数据中心里广泛使用的高速互联架构。它和我们日常见到的以太网是两套不同的体系从物理层到链路层再到传输层几乎每一层都有自己的协议设计。HCA是 Host Channel Adapter 的缩写直译过来叫“主机通道适配器”。你可以把它理解成 InfiniBand 网络里的“网卡”但它比普通以太网网卡承担的责任重得多——它要负责把主机内存里的数据直接搬到网络上还要处理大量的协议卸载工作。为什么这个区分重要因为很多人第一次接触 IB HCA 时会下意识地拿以太网网卡的经验去套结果在驱动、固件、端口状态这些环节上反复踩坑。以太网网卡你插上去系统认了配个 IP 就能通IB HCA 插上去系统认了只是第一步后面还有子网管理器、端口状态机、链路宽度协商、速率协商一整套流程要走。任何一个环节没对齐端口就停在Down或者Initializing状态数据面根本起不来。这篇文章适合谁看如果你是刚接手一套带 IB 网络的集群、需要把 HCA 跑通并验证性能的运维或研发或者你在做 RDMA 相关的应用开发、需要理解底层链路状态对上层的影响那这篇内容会对你有直接帮助。我会从硬件识别、驱动固件、端口状态、性能验证这几个角度把 IB HCA 从“插上去”到“跑起来”的完整链路讲透中间穿插我自己踩过的坑和排查思路。提示本文讨论的是 InfiniBand 架构下的 HCA 使用与调优不涉及任何网络访问相关的工具或方法纯粹聚焦在硬件与协议栈本身。2. 硬件识别与驱动栈别让系统“认不出”你的卡2.1 物理形态与插槽选择IB HCA 常见的物理形态是 PCIe 插卡有单端口和双端口之分。单端口卡只有一个 QSFP 或 QSFP28 笼子双端口卡有两个。选单端口还是双端口取决于你的组网拓扑如果每台机器只需要连一条 IB 链路单端口够用如果要做链路冗余或者多轨组网双端口更合适。插槽选择上有个容易被忽略的点PCIe 代际和通道数直接决定 HCA 能不能跑满它的标称速率。举个例子一块标称 100Gb/s 的 HCA如果插在 PCIe 3.0 x8 的槽位上理论上限大约是 63Gb/s实际跑起来可能只有 50 多 Gb/s。你以为是卡的问题其实是插槽带宽不够。所以插卡之前先确认主板手册里这个槽位的 PCIe 代际和 lane 数别让插槽成为瓶颈。2.2 系统识别lspci 是第一道关插上卡、开机之后第一件事是用lspci确认系统能不能看到这个设备。lspci | grep -i mellanox如果你用的是其他厂商的 HCA把mellanox换成对应厂商的关键词。正常的话你会看到类似这样的输出81:00.0 Infiniband controller: Mellanox Technologies MT28908 Family [ConnectX-6]看到这行说明硬件层面已经被 PCIe 枚举到了。如果什么都没看到先别急着怀疑卡坏了按这个顺序排查卡是否插紧、插槽是否被 BIOS 禁用、主板是否支持这个 PCIe 代际。我遇到过一台机器卡插在了一个和 CPU 直连 lane 共享的槽位上BIOS 里默认把这个槽位关掉了折腾了半天才发现是 BIOS 设置问题。2.3 驱动加载与设备节点硬件认到之后需要确认驱动是否加载。IB HCA 在 Linux 下通常依赖mlx5_core新一代或mlx4_core老一代这类内核模块。lsmod | grep mlx5如果没加载手动加载一下modprobe mlx5_core驱动加载成功后系统里会出现对应的 IB 设备节点通常在/sys/class/infiniband/下面ls /sys/class/infiniband/你会看到类似mlx5_0、mlx5_1这样的目录每个目录对应一个 HCA 端口。这个命名规则要记住后面查端口状态、跑性能测试都会用到。注意有些发行版默认不带mlx5_core模块需要额外安装rdma-core和对应的内核模块包。装完之后建议重启一次让模块和固件在干净的状态下初始化。2.4 固件版本被低估的稳定性因素固件版本这件事平时没人关注出问题的时候往往是元凶。不同批次的 HCA 可能出厂固件版本不一致混在同一套集群里跑轻则性能抖动重则链路反复 up/down。查看当前固件版本cat /sys/class/infiniband/mlx5_0/fw_ver升级固件一般用厂商提供的工具比如mlxfwmanager或mstflint。升级前务必确认目标固件版本和你的驱动版本兼容别盲目追新。我的经验是同一套集群里的 HCA 固件版本尽量统一哪怕不是最新统一比最新更重要。曾经有个集群一半卡是旧固件一半是新固件跑 MPI 作业时偶发超时查了很久才定位到固件差异导致的链路重协商。3. 端口状态机IB HCA 最容易被误解的地方3.1 端口状态到底有哪几种以太网网卡你基本只看 link up 还是 downIB HCA 的端口状态要复杂得多。通过下面这个命令可以看端口状态cat /sys/class/infiniband/mlx5_0/ports/1/state输出可能是这几种之一状态含义是否可通信Down物理链路未建立否Initializing正在初始化等待子网管理器配置否Armed已收到子网管理器配置但还未激活否Active完全激活可以正常通信是ActiveDefer激活但延迟通常出现在特定路由场景是很多人看到Initializing就慌了以为卡坏了。其实Initializing是正常中间态它在等子网管理器Subnet ManagerSM下发配置。如果一直停在Initializing不动那才是问题——大概率是子网管理器没跑起来或者 HCA 和 SM 之间的管理通道不通。3.2 子网管理器IB 网络的“大脑”这是 IB 和以太网最大的区别之一。以太网里每台机器自己管自己的路由IB 网络里有一个中心化的子网管理器负责整个子网的拓扑发现、路由计算和配置下发。没有 SMHCA 端口就永远停在Initializing。SM 可以跑在集群里任意一台机器的 HCA 上也可以跑在专用的管理节点上。检查 SM 是否在运行systemctl status opensm或者直接看进程ps aux | grep opensm如果 SM 没跑启动它systemctl start opensmSM 启动后正常情况下几秒到几十秒内所有 HCA 端口会从Initializing转到Active。如果转了但只有部分端口 Active那就要看是不是有链路质量问题或者 SM 配置里排除了某些端口。3.3 链路宽度与速率协商结果怎么看端口 Active 之后还要确认协商出来的链路宽度和速率是否符合预期。cat /sys/class/infiniband/mlx5_0/ports/1/rate输出类似100 Gb/sec (4X EDR)意思是四通道 EDR总速率 100Gb/s。如果输出是25 Gb/sec (1X EDR)说明只协商到了一个通道带宽只有预期的四分之一。这种情况通常是线缆问题或者端口接触不良换根线或者重新插拔一下往往能解决。查看链路宽度的原始值cat /sys/class/infiniband/mlx5_0/ports/1/link_layer这个一般输出InfiniBand确认你确实在 IB 模式下而不是以太网模式。有些 HCA 支持双模式如果误配成以太网模式端口状态和性能表现都会不一样。3.4 一个真实的排查案例有次一台新上架的机器HCA 端口一直停在Initializing。按顺序查了一遍lspci能看到卡驱动加载正常固件版本也对SM 在别的机器上跑得好好的。最后发现是这台机器的 HCA 端口在 SM 的配置里被手动排除了——之前有人调试时把它加进了黑名单忘了删。把黑名单清掉重启 SM端口立刻变Active。这个案例说明一件事IB 网络的问题不一定在本地。端口状态是本地和 SM 协同的结果排查时要两头看别只盯着本机。4. 性能验证从带宽测试到真实负载4.1 先用 ib_write_bw 摸清底细端口 Active 之后别急着跑业务先用标准工具测一下带宽和延迟确认链路本身没问题。常用的工具是perftest套件里的ib_write_bw和ib_write_lat。服务端ib_write_bw -d mlx5_0 -a客户端ib_write_bw -d mlx5_0 -a server_ip-a表示跑所有消息尺寸从很小的消息到很大的消息都测一遍。你会看到一张表列出不同消息大小下的带宽。重点关注大消息比如 1MB 以上的带宽是否接近链路标称值。100Gb/s 的链路实测单向带宽通常在 90Gb/s 以上算正常低于 80Gb/s 就要查原因了。延迟测试用ib_write_lat小消息下的往返延迟是关键指标。EDR 链路的典型延迟在 1 到 2 微秒之间如果测出来是十几微秒那说明路径上有多余的跳数或者配置有问题。4.2 带宽不达标的常见原因实测带宽低于预期按这个顺序排查PCIe 插槽带宽不足前面提过用lspci -vv看协商出来的 PCIe 速率和宽度。线缆或端口问题看rate文件确认协商速率如果只有 1X 或 2X换线。CPU 亲和性跑测试的进程如果被调度到远离 HCA 所在 NUMA 节点的 CPU 上内存拷贝会跨节点带宽会掉。用numactl绑定到 HCA 同侧的 CPU。消息大小小消息本身带宽就低这是协议开销决定的不是问题。看大消息的带宽才有意义。4.3 从裸带宽到应用性能裸带宽达标不代表应用就能跑满。RDMA 应用比如 MPI、NCCL、分布式存储能不能吃到 IB 的带宽取决于应用有没有正确使用 RDMA 语义。如果应用走的是传统 socket那 IB 的优势基本发挥不出来因为数据要经过内核协议栈拷贝。验证应用是否真的走了 RDMA可以看 HCA 的端口计数器cat /sys/class/infiniband/mlx5_0/ports/1/counters/port_xmit_data跑应用前后对比这个值如果增长明显说明数据确实从 HCA 发出去了。如果应用跑得很欢但计数器不动那大概率走的是别的路径。提示perftest套件里的工具很多ib_write_bw、ib_read_bw、ib_send_bw分别对应不同的 RDMA 操作类型。测的时候根据你的应用实际使用的操作类型来选别只测一种就下结论。5. 日常维护与那些没人告诉你的细节5.1 端口计数器故障的早期信号IB HCA 的端口计数器是排查问题的金矿。除了前面说的port_xmit_data还有几个关键计数器值得定期看port_rcv_errors接收错误计数持续增长说明链路质量有问题。port_xmit_discards发送丢弃计数增长说明拥塞或配置问题。link_downed链路 down 的次数偶发一次可能是线缆松动频繁增长就要查硬件。写个简单的脚本定期采集这些计数器比出了问题再去看要主动得多。我习惯在集群巡检脚本里加上这几项一旦发现异常增长就提前介入。5.2 固件与驱动的版本管理前面提过固件版本要统一驱动版本同理。内核升级之后mlx5_core模块的版本也会跟着变如果新驱动和老固件之间有兼容性问题端口可能起不来。所以升级内核之前先确认一下当前 HCA 固件版本和目标内核自带的驱动版本是否匹配。一个实用的做法是把集群里所有 HCA 的固件版本和驱动版本记录在一张表里每次变更前对照检查。这张表看起来不起眼但能帮你省下大量排查时间。5.3 多端口 HCA 的端口绑定双端口 HCA 在系统里会显示成两个独立端口比如mlx5_0和mlx5_1。如果你的应用需要做链路聚合或者故障切换需要在应用层或者驱动层做绑定。IB 本身不提供类似以太网 bonding 的原生聚合多端口的使用方式取决于你的组网设计——可以是主备也可以是负载分担但都需要应用或中间件配合。5.4 温度与散热HCA 在高负载下发热不小尤其是 100Gb/s 以上的卡。如果机箱风道设计不好HCA 温度过高会触发降频性能直接掉下来。查看温度cat /sys/class/infiniband/mlx5_0/ports/1/hw_counters/temperature不同厂商的路径可能略有差异有的在hwmon下面。温度持续偏高的话检查一下机箱风扇和挡板是否到位。我见过一个机箱HCA 插在最下面的槽位风道被电源挡住跑满负载十分钟就开始降频把卡换到上面的槽位就正常了。6. 关于“ic三极管ib大于ic”这个热词的澄清搜索“IB HCA”的时候会看到一个相关的热词叫“ic三极管ib大于ic”。这里需要澄清一下这个说法来自电子电路领域讲的是三极管工作时基极电流Ib和集电极电流Ic的关系和 InfiniBand HCA 完全是两码事。三极管有三个工作区截止区、放大区、饱和区。在放大区里Ib 控制 IcIc 大约是 Ib 的 β 倍β 是电流放大系数。所谓“ib大于ic”在正常的放大区是不成立的因为 Ic 远大于 Ib。只有在某些特定语境下比如讨论饱和条件或者反向电流时才会出现 Ib 和 Ic 大小关系的特殊讨论。把这个热词放在这里说是因为搜索“IB HCA”的人有可能被这个结果误导。如果你是在查 InfiniBand HCA 的资料看到三极管的内容直接跳过就好两者没有任何关联。这也提醒一件事缩写在不同领域含义完全不同搜索技术资料时带上领域关键词能少走很多弯路。7. 我在实际使用中积累的几条经验折腾 IB HCA 这些年有几条经验是文档里不会写、但实际用起来很管用的。第一条新卡上架先跑一遍 perftest别等业务上来再测。裸带宽和延迟是基线后面业务出问题的时候有基线数据才能判断是链路退化了还是应用本身的问题。没有基线你连“正常”是什么样都不知道。第二条端口状态从 Initializing 变 Active 的时间可以作为健康指标。正常情况下几秒到几十秒如果某台机器要几分钟才变 Active说明 SM 和这台机器的管理通道有延迟可能是线缆质量或者 HCA 固件的问题提前处理比等它彻底不通要好。第三条别忽视线缆。IB 线缆比以太网线缆娇贵弯折半径、接头清洁度都会影响链路质量。我遇到过一根线缆外观完好但内部光纤有微弯导致端口频繁 down换线之后一切正常。备几根已知良好的线缆做替换测试能省很多事。第四条记录每一次变更。固件升级、驱动更新、SM 配置修改都记下来。IB 网络的故障往往不是单一原因而是多个变更叠加的结果。有变更记录回溯的时候才有线索。这套东西说到底就是IB HCA 不是插上就能用的网卡它是一套需要理解协议栈、理解状态机、理解协同关系的硬件。把端口状态、SM、性能基线这三件事管好大部分问题都能在萌芽阶段解决。
InfiniBand HCA 从硬件识别到性能调优：端口状态、子网管理器与 RDMA 实践
1. 从“IB HCA”这个缩写说起它到底指什么第一次看到“IB HCA”这四个字母很多人会一头雾水。我先把这个缩写拆开讲清楚因为搞混了它和普通网卡的区别后面所有配置都会走偏。IB指的是 InfiniBand一种在高性能计算和数据中心里广泛使用的高速互联架构。它和我们日常见到的以太网是两套不同的体系从物理层到链路层再到传输层几乎每一层都有自己的协议设计。HCA是 Host Channel Adapter 的缩写直译过来叫“主机通道适配器”。你可以把它理解成 InfiniBand 网络里的“网卡”但它比普通以太网网卡承担的责任重得多——它要负责把主机内存里的数据直接搬到网络上还要处理大量的协议卸载工作。为什么这个区分重要因为很多人第一次接触 IB HCA 时会下意识地拿以太网网卡的经验去套结果在驱动、固件、端口状态这些环节上反复踩坑。以太网网卡你插上去系统认了配个 IP 就能通IB HCA 插上去系统认了只是第一步后面还有子网管理器、端口状态机、链路宽度协商、速率协商一整套流程要走。任何一个环节没对齐端口就停在Down或者Initializing状态数据面根本起不来。这篇文章适合谁看如果你是刚接手一套带 IB 网络的集群、需要把 HCA 跑通并验证性能的运维或研发或者你在做 RDMA 相关的应用开发、需要理解底层链路状态对上层的影响那这篇内容会对你有直接帮助。我会从硬件识别、驱动固件、端口状态、性能验证这几个角度把 IB HCA 从“插上去”到“跑起来”的完整链路讲透中间穿插我自己踩过的坑和排查思路。提示本文讨论的是 InfiniBand 架构下的 HCA 使用与调优不涉及任何网络访问相关的工具或方法纯粹聚焦在硬件与协议栈本身。2. 硬件识别与驱动栈别让系统“认不出”你的卡2.1 物理形态与插槽选择IB HCA 常见的物理形态是 PCIe 插卡有单端口和双端口之分。单端口卡只有一个 QSFP 或 QSFP28 笼子双端口卡有两个。选单端口还是双端口取决于你的组网拓扑如果每台机器只需要连一条 IB 链路单端口够用如果要做链路冗余或者多轨组网双端口更合适。插槽选择上有个容易被忽略的点PCIe 代际和通道数直接决定 HCA 能不能跑满它的标称速率。举个例子一块标称 100Gb/s 的 HCA如果插在 PCIe 3.0 x8 的槽位上理论上限大约是 63Gb/s实际跑起来可能只有 50 多 Gb/s。你以为是卡的问题其实是插槽带宽不够。所以插卡之前先确认主板手册里这个槽位的 PCIe 代际和 lane 数别让插槽成为瓶颈。2.2 系统识别lspci 是第一道关插上卡、开机之后第一件事是用lspci确认系统能不能看到这个设备。lspci | grep -i mellanox如果你用的是其他厂商的 HCA把mellanox换成对应厂商的关键词。正常的话你会看到类似这样的输出81:00.0 Infiniband controller: Mellanox Technologies MT28908 Family [ConnectX-6]看到这行说明硬件层面已经被 PCIe 枚举到了。如果什么都没看到先别急着怀疑卡坏了按这个顺序排查卡是否插紧、插槽是否被 BIOS 禁用、主板是否支持这个 PCIe 代际。我遇到过一台机器卡插在了一个和 CPU 直连 lane 共享的槽位上BIOS 里默认把这个槽位关掉了折腾了半天才发现是 BIOS 设置问题。2.3 驱动加载与设备节点硬件认到之后需要确认驱动是否加载。IB HCA 在 Linux 下通常依赖mlx5_core新一代或mlx4_core老一代这类内核模块。lsmod | grep mlx5如果没加载手动加载一下modprobe mlx5_core驱动加载成功后系统里会出现对应的 IB 设备节点通常在/sys/class/infiniband/下面ls /sys/class/infiniband/你会看到类似mlx5_0、mlx5_1这样的目录每个目录对应一个 HCA 端口。这个命名规则要记住后面查端口状态、跑性能测试都会用到。注意有些发行版默认不带mlx5_core模块需要额外安装rdma-core和对应的内核模块包。装完之后建议重启一次让模块和固件在干净的状态下初始化。2.4 固件版本被低估的稳定性因素固件版本这件事平时没人关注出问题的时候往往是元凶。不同批次的 HCA 可能出厂固件版本不一致混在同一套集群里跑轻则性能抖动重则链路反复 up/down。查看当前固件版本cat /sys/class/infiniband/mlx5_0/fw_ver升级固件一般用厂商提供的工具比如mlxfwmanager或mstflint。升级前务必确认目标固件版本和你的驱动版本兼容别盲目追新。我的经验是同一套集群里的 HCA 固件版本尽量统一哪怕不是最新统一比最新更重要。曾经有个集群一半卡是旧固件一半是新固件跑 MPI 作业时偶发超时查了很久才定位到固件差异导致的链路重协商。3. 端口状态机IB HCA 最容易被误解的地方3.1 端口状态到底有哪几种以太网网卡你基本只看 link up 还是 downIB HCA 的端口状态要复杂得多。通过下面这个命令可以看端口状态cat /sys/class/infiniband/mlx5_0/ports/1/state输出可能是这几种之一状态含义是否可通信Down物理链路未建立否Initializing正在初始化等待子网管理器配置否Armed已收到子网管理器配置但还未激活否Active完全激活可以正常通信是ActiveDefer激活但延迟通常出现在特定路由场景是很多人看到Initializing就慌了以为卡坏了。其实Initializing是正常中间态它在等子网管理器Subnet ManagerSM下发配置。如果一直停在Initializing不动那才是问题——大概率是子网管理器没跑起来或者 HCA 和 SM 之间的管理通道不通。3.2 子网管理器IB 网络的“大脑”这是 IB 和以太网最大的区别之一。以太网里每台机器自己管自己的路由IB 网络里有一个中心化的子网管理器负责整个子网的拓扑发现、路由计算和配置下发。没有 SMHCA 端口就永远停在Initializing。SM 可以跑在集群里任意一台机器的 HCA 上也可以跑在专用的管理节点上。检查 SM 是否在运行systemctl status opensm或者直接看进程ps aux | grep opensm如果 SM 没跑启动它systemctl start opensmSM 启动后正常情况下几秒到几十秒内所有 HCA 端口会从Initializing转到Active。如果转了但只有部分端口 Active那就要看是不是有链路质量问题或者 SM 配置里排除了某些端口。3.3 链路宽度与速率协商结果怎么看端口 Active 之后还要确认协商出来的链路宽度和速率是否符合预期。cat /sys/class/infiniband/mlx5_0/ports/1/rate输出类似100 Gb/sec (4X EDR)意思是四通道 EDR总速率 100Gb/s。如果输出是25 Gb/sec (1X EDR)说明只协商到了一个通道带宽只有预期的四分之一。这种情况通常是线缆问题或者端口接触不良换根线或者重新插拔一下往往能解决。查看链路宽度的原始值cat /sys/class/infiniband/mlx5_0/ports/1/link_layer这个一般输出InfiniBand确认你确实在 IB 模式下而不是以太网模式。有些 HCA 支持双模式如果误配成以太网模式端口状态和性能表现都会不一样。3.4 一个真实的排查案例有次一台新上架的机器HCA 端口一直停在Initializing。按顺序查了一遍lspci能看到卡驱动加载正常固件版本也对SM 在别的机器上跑得好好的。最后发现是这台机器的 HCA 端口在 SM 的配置里被手动排除了——之前有人调试时把它加进了黑名单忘了删。把黑名单清掉重启 SM端口立刻变Active。这个案例说明一件事IB 网络的问题不一定在本地。端口状态是本地和 SM 协同的结果排查时要两头看别只盯着本机。4. 性能验证从带宽测试到真实负载4.1 先用 ib_write_bw 摸清底细端口 Active 之后别急着跑业务先用标准工具测一下带宽和延迟确认链路本身没问题。常用的工具是perftest套件里的ib_write_bw和ib_write_lat。服务端ib_write_bw -d mlx5_0 -a客户端ib_write_bw -d mlx5_0 -a server_ip-a表示跑所有消息尺寸从很小的消息到很大的消息都测一遍。你会看到一张表列出不同消息大小下的带宽。重点关注大消息比如 1MB 以上的带宽是否接近链路标称值。100Gb/s 的链路实测单向带宽通常在 90Gb/s 以上算正常低于 80Gb/s 就要查原因了。延迟测试用ib_write_lat小消息下的往返延迟是关键指标。EDR 链路的典型延迟在 1 到 2 微秒之间如果测出来是十几微秒那说明路径上有多余的跳数或者配置有问题。4.2 带宽不达标的常见原因实测带宽低于预期按这个顺序排查PCIe 插槽带宽不足前面提过用lspci -vv看协商出来的 PCIe 速率和宽度。线缆或端口问题看rate文件确认协商速率如果只有 1X 或 2X换线。CPU 亲和性跑测试的进程如果被调度到远离 HCA 所在 NUMA 节点的 CPU 上内存拷贝会跨节点带宽会掉。用numactl绑定到 HCA 同侧的 CPU。消息大小小消息本身带宽就低这是协议开销决定的不是问题。看大消息的带宽才有意义。4.3 从裸带宽到应用性能裸带宽达标不代表应用就能跑满。RDMA 应用比如 MPI、NCCL、分布式存储能不能吃到 IB 的带宽取决于应用有没有正确使用 RDMA 语义。如果应用走的是传统 socket那 IB 的优势基本发挥不出来因为数据要经过内核协议栈拷贝。验证应用是否真的走了 RDMA可以看 HCA 的端口计数器cat /sys/class/infiniband/mlx5_0/ports/1/counters/port_xmit_data跑应用前后对比这个值如果增长明显说明数据确实从 HCA 发出去了。如果应用跑得很欢但计数器不动那大概率走的是别的路径。提示perftest套件里的工具很多ib_write_bw、ib_read_bw、ib_send_bw分别对应不同的 RDMA 操作类型。测的时候根据你的应用实际使用的操作类型来选别只测一种就下结论。5. 日常维护与那些没人告诉你的细节5.1 端口计数器故障的早期信号IB HCA 的端口计数器是排查问题的金矿。除了前面说的port_xmit_data还有几个关键计数器值得定期看port_rcv_errors接收错误计数持续增长说明链路质量有问题。port_xmit_discards发送丢弃计数增长说明拥塞或配置问题。link_downed链路 down 的次数偶发一次可能是线缆松动频繁增长就要查硬件。写个简单的脚本定期采集这些计数器比出了问题再去看要主动得多。我习惯在集群巡检脚本里加上这几项一旦发现异常增长就提前介入。5.2 固件与驱动的版本管理前面提过固件版本要统一驱动版本同理。内核升级之后mlx5_core模块的版本也会跟着变如果新驱动和老固件之间有兼容性问题端口可能起不来。所以升级内核之前先确认一下当前 HCA 固件版本和目标内核自带的驱动版本是否匹配。一个实用的做法是把集群里所有 HCA 的固件版本和驱动版本记录在一张表里每次变更前对照检查。这张表看起来不起眼但能帮你省下大量排查时间。5.3 多端口 HCA 的端口绑定双端口 HCA 在系统里会显示成两个独立端口比如mlx5_0和mlx5_1。如果你的应用需要做链路聚合或者故障切换需要在应用层或者驱动层做绑定。IB 本身不提供类似以太网 bonding 的原生聚合多端口的使用方式取决于你的组网设计——可以是主备也可以是负载分担但都需要应用或中间件配合。5.4 温度与散热HCA 在高负载下发热不小尤其是 100Gb/s 以上的卡。如果机箱风道设计不好HCA 温度过高会触发降频性能直接掉下来。查看温度cat /sys/class/infiniband/mlx5_0/ports/1/hw_counters/temperature不同厂商的路径可能略有差异有的在hwmon下面。温度持续偏高的话检查一下机箱风扇和挡板是否到位。我见过一个机箱HCA 插在最下面的槽位风道被电源挡住跑满负载十分钟就开始降频把卡换到上面的槽位就正常了。6. 关于“ic三极管ib大于ic”这个热词的澄清搜索“IB HCA”的时候会看到一个相关的热词叫“ic三极管ib大于ic”。这里需要澄清一下这个说法来自电子电路领域讲的是三极管工作时基极电流Ib和集电极电流Ic的关系和 InfiniBand HCA 完全是两码事。三极管有三个工作区截止区、放大区、饱和区。在放大区里Ib 控制 IcIc 大约是 Ib 的 β 倍β 是电流放大系数。所谓“ib大于ic”在正常的放大区是不成立的因为 Ic 远大于 Ib。只有在某些特定语境下比如讨论饱和条件或者反向电流时才会出现 Ib 和 Ic 大小关系的特殊讨论。把这个热词放在这里说是因为搜索“IB HCA”的人有可能被这个结果误导。如果你是在查 InfiniBand HCA 的资料看到三极管的内容直接跳过就好两者没有任何关联。这也提醒一件事缩写在不同领域含义完全不同搜索技术资料时带上领域关键词能少走很多弯路。7. 我在实际使用中积累的几条经验折腾 IB HCA 这些年有几条经验是文档里不会写、但实际用起来很管用的。第一条新卡上架先跑一遍 perftest别等业务上来再测。裸带宽和延迟是基线后面业务出问题的时候有基线数据才能判断是链路退化了还是应用本身的问题。没有基线你连“正常”是什么样都不知道。第二条端口状态从 Initializing 变 Active 的时间可以作为健康指标。正常情况下几秒到几十秒如果某台机器要几分钟才变 Active说明 SM 和这台机器的管理通道有延迟可能是线缆质量或者 HCA 固件的问题提前处理比等它彻底不通要好。第三条别忽视线缆。IB 线缆比以太网线缆娇贵弯折半径、接头清洁度都会影响链路质量。我遇到过一根线缆外观完好但内部光纤有微弯导致端口频繁 down换线之后一切正常。备几根已知良好的线缆做替换测试能省很多事。第四条记录每一次变更。固件升级、驱动更新、SM 配置修改都记下来。IB 网络的故障往往不是单一原因而是多个变更叠加的结果。有变更记录回溯的时候才有线索。这套东西说到底就是IB HCA 不是插上就能用的网卡它是一套需要理解协议栈、理解状态机、理解协同关系的硬件。把端口状态、SM、性能基线这三件事管好大部分问题都能在萌芽阶段解决。
