简介：这份白皮书是 Mellanox 官方发布的 SX6015 InfiniBand 交换机产品资料，面向数据中心规划、高性能计算、云计算、存储与虚拟化方向的工程师和方案选型人员，旨在帮助读者快速建立对该交换机功能定位与技术优势的整体认知。文档围绕 SX6015 展开，涵盖 56Gb/s InfiniBand 高速互联能力、最多 36 端口的高可扩展设计、热插拔高可靠机制，并逐一分析了高性能计算、云计算、存储和虚拟化等典型应用场景，可作为网络基础架构设计、设备选型及项目方案评估时的实用参考。资源以 1 个 PDF 文件打包，整体大小约 2.44MB，文档结构紧凑、关键规格与场景说明完整，便于离线查阅、团队分享以及后续部署对照。该资源已有 160 人学习下载，适合正在了解 IB 网络、评估高性能数据中心组网方案，或者需要为相关项目准备技术调研资料的读者阅读。
1. 从白皮书到实战：Mellanox SX6015 在 IB 集群里的位置
Mellanox SX6015 是一台 1U 的 IB 交换机，18 个 QSFP 端口，满载 FDR（56Gb/s），在 HPC 机房里最常见的角色不是核心骨干，而是 GPU 节点和存储节点之间的那台聚合层设备。很多人拿到白皮书先翻功率、端口数和 MTBF 数字，真正上线时才发现子网管理器（SM）放在哪、PKey 怎么划、链路降速怎么查，才是决定一组 IB 节点能否正常通信的关键。这篇文章按我部署 SX6015 的习惯，把白皮书没展开讲的硬件模型、组网设计、开局配置到验收手段整理成一条可复现的路径：新手能照着命令走通，老手也能对比自己已有的配置找出松动的地方。
2. 读懂 SX6015 的硬件规格与 IB 数据面特性
2.1 端口形态、FDR 速率协商与常见的降速现场
SX6015 的正面是 18 个 QSFP 端口，每个端口物理形态是 4x，也就是一条 FDR 链路由 4 个 14.0625Gbps 的 lane 组成，合计 56.25Gbps。白皮书里写的“FDR 56G”通常指链路层速率，实际可用带宽还要扣掉 8B/10B 或 64B/66B 编码开销以及 InfiniBand 报文头，这也是为什么 IB 测速脚本里“56G 端口”很难测出完整的 56Gbps 应用层吞吐。SX6015 支持向下协商到 QDR 40G、DDR 20G、SDR 10G，因此混插老一代 HCA 卡时不会直接起不来，只会按低的那个速率工作。
| 链路代际 | 单 lane 速率 | 4x 链路速率 | 常见线缆形态 | SX6015 兼容性 |
|---|---|---|---|---|
| SDR | 2.5Gbps | 10Gbps | CX-4（老设备） | 兼容 |
| DDR | 5Gbps | 20Gbps | QSFP 铜缆 | 兼容 |
| QDR | 10Gbps | 40Gbps | QSFP 铜缆/光模块 | 兼容 |
| FDR10 | 10.3125Gbps | 41.25Gbps | QSFP 铜缆 | 兼容，非标准 |
| FDR | 14.0625Gbps | 56.25Gbps | QSFP 铜缆/光模块 | 原生速率 |
在机房现场看到“端口起不来”，多半不是设备坏了，而是三个原因：线缆是 QDR 时代的旧线、对端网卡固件太老不支持 FDR、或者端口配置里手动锁定过速率。白皮书会写“支持自动协商”，但实际部署中 IB 的自动协商没有以太网那么开放，只要有一端不认 FDR 的 lane 速率，就会整条链路掉到 QDR 甚至 SDR。
确认协商结果不依赖登录交换机，主机侧直接看更直观：
ibstat mlx5_0CA type: Mellanox ConnectX-3 Firmware version: 2.42.5100 Port 1: State: Active Physical state: LinkUp Rate: 56 Base lid: 2 LMC: 0 Link layer: InfiniBand这段输出的Rate: 56就是当前协商出来的速率，单位是 Gbps。如果这里显示 40 或 20，说明链路协商到 QDR 或 DDR 了，优先检查线缆和两端固件版本，而不是在交换机上反复拔插。
2.2 链路层 Credit 机制：IB 无损网络的立身之本
SX6015 这种 IB 交换机与以太网交换机有一个本质差异：IB 从链路层就设计了基于 Credit 的流控。每个接收端口维护一组 Credit 计数器，发送端每发一个报文就要消耗对应缓冲区的 Credit，接收端处理完毕返还 Credit，发送端没拿到 Credit 就不继续发送。这个机制让 IB 网络在正常情况下不会因为接收端来不及处理而丢包。
这个设计对 MPI 这类同步协作型流量特别重要。MPI_Allreduce 这类集合操作对重传极其敏感，一旦出现一个丢包，整个通信组都要停下来等超时，吞吐量掉的数量级不是 10% 而是 5 到 10 倍。所以 SX6015 白皮书里大篇幅强调的“无阻塞架构”，实际含义是任意端口到任意其他端口都能以线速转发，且内部缓存足够撑住 Credit 返还的延迟；如果内部 Buffer 不够，Credit 机制会直接把链路“掐住”，表现为端口状态 Active 但带宽只有几百 Mbps，这是 IB 网络上最隐蔽的故障之一。
交换机侧刷新端口计数，能看到 Credit 相关统计：
switch (config) # show ib port 1/1 countersPort 1/1 counters: Link error recovery: 0 Link downed: 0 Rcv errors: 0 Rcv switch relay errors: 0 Xmit discard: 0 Xmit wait: 0重点看Xmit wait和Link error recovery。Xmit wait不为零说明出现过发送端等待 Credit 的窗口，少量是正常的；如果这个数值持续增长且伴随应用层带宽上不去，大概率是某个端口的入向 Buffer 被占满，需要检查是不是有节点在跑突发流量而没做消息节流，而不是急着加带宽。
2.3 白皮书里不会出现 DPDK，IB 网络有自己的收包路径
搜 Mellanox 资料时经常有人把 DPDK 和 IB 混在一起看，这其实是两套东西。DPDK 解决的是以太网收包路径上内核协议栈开销太大的问题，让用户态程序直接轮询网卡队列；而 InfiniBand 从设计之初就支持 RDMA，应用通过 verbs 接口（libibverbs）直接把数据从用户态内存送到网卡，再由硬件完成内存到内存的数据搬运，根本不经过内核 TCP/IP 栈。
SX6015 是交换侧设备，它不参与任何收包路径，白皮书里当然不会出现 DPDK 相关内容。如果你在机房用 DPDK 的 testpmd 去测 Mellanox 网卡，测的是以太网模式或 RoCE 模式；如果跑的是 IB 模式，正确工具是 perftest 里的 ib_write_bw 和 ib_read_lat。把这两类工具的使用场景分清楚，是排查很多人“IB 网络没有想象中快”这类疑问的第一步。硬件上 SX6015 只认 InfiniBand 报文格式，IPoIB 和 RDMA 数据都通过同一套端口转发，区分它们只在主机协议栈里发生，交换机并不感知。
3. 组网规划与主机接入 SX6015 的落地路径
3.1 单层还是两层：用 SX6015 时拓扑怎么选
SX6015 有 18 个端口，规划时先扣掉上行口再算可用端口。最常见的用法是一台 SX6015 带 16 到 18 个计算节点，存储和登录节点各自占一个口，形成单层扁平网络。这种拓扑下，任意两个节点之间只有一台交换机，延迟最低，也最容易排查问题。
节点超过 18 台时，常见做法是再加一台 SX6015 作为 Spine，两台 SX6015 之间拉 4 条 FDR 链路组成聚合，接入层每台 SX6015 用 2 到 4 个口上行，剩下的口接节点。IB 交换机之间的多条链路可以走聚合，但要注意 IB 的聚合粒度按 LID 和 QP 分配，不像以太网 LACP 那样按流哈希；MPI 这类多 QP 通信能尽量打散，单队列通信可能始终占用同一条物理链路。
规划时还要考虑 LID（Local Identifier）。IB 网络中每台主机在子网里会被 SM 分配一个 16 位的 LID，交换机转发靠的是 LID 而不是 MAC 地址。需要确认链路故障后重新上线时 LID 会变化，因此应用层不要写死 LID，一律用 hostname 解析到 IPoIB 地址或直接使用 rdma_cm 的地址解析。
3.2 子网管理器 SM 放交换机还是放独立主机
InfiniBand 子网必须有一个 SM 负责分配 LID、建立路由表和计算转发路径。SX6015 内部自带嵌入式 SM，也在支持外部 SM 的节点上运行 OpenSM。单台 SX6015 的小集群，直接把嵌入式 SM 打开最省事，省掉一台机器做 SM 的故障依赖；两台 SX6015 组两层时，建议只开一台的 SM，另一台关闭，避免两个 SM 抢 Master 导致全网路由表反复刷新。
SX6015 的嵌入式 SM 由固件内的软件承载，固件升级时 SM 会重启，网络会出现一次短暂的 LID 重新分配，对长任务不友好。因此跑 7x24 小时 MPI 作业的环境，我一般会用一台独立管理节点跑 OpenSM，交换机侧的 SM 关掉；开发和测试环境则直接用嵌入式 SM。
独立节点跑 OpenSM 的常用启动方式：
systemctl start opensm systemctl enable opensm journalctl -u opensm -f启动后用ibswitches确认子网拓扑已经被 SM 掌握：
ibswitchesSwitch : 0x98039b03009f23d0 ports 36 GUID 0x98039b03009f23d0可以看到拓扑里的交换机 GUID 和端口数。如果 OpenSM 起来但ibswitches列不出设备，说明 SM 没有拿到 Master 角色，用smquery state看当前 SM 状态：
smquery state正常输出里State: MASTER才是有效状态，看到STANDBY说明子网里还有更高优先级的 SM，需要确认是哪台设备抢了主角色。
3.3 主机侧接入：rdma-core 装好之后先跑哪几条命令
主机接入 SX6015，第一步不是配 IP，而是先确认 HCA 卡被系统识别并拿到固件。Mellanox 网卡在较新的内核里用 inbox 驱动 rdma-core 就能工作，不一定需要单独安装 MLNX_OFED；但生产环境我倾向于装对应版本的 MLNX_OFED，因为它会把 perftest、ibdiagnet、ibping 这些诊断工具一起带齐。
接入后按顺序跑三条命令，能覆盖大部分链路问题：
ibv_devinfo ibstat ibping -S -C mlx5_0 -P 1ibv_devinfo看设备和端口能力；ibstat看物理链路状态；ibping -S在服务端模式启动节点，对端用ibping -C mlx5_0 -P 1 -G <lid>打过去，能验证两侧的 SM 路径是否通。如果ibstat显示 State Active 但ibping不通，基本可以确定是 SM 的路由表没有刷新，回到 3.2 节检查 SM 角色；如果 State 是 Down，先查线缆和端口速率。
4. SX6015 的 MLNX-OS 开局、分区与 QoS 参数配置
4.1 管理面配置：带外 IP、主机名与固件版本核对
新开箱的 SX6015 默认有一个管理 IP，常见的出厂地址是 192.168.0.1，但不同批次固件可能略有差异，最可靠的是用串口线接 console 口看登录提示。首次登录后我一般先做一个最小化配置：改主机名、配带外管理 IP、关掉不必要的 Web 管理面、确认固件版本。
switch (config) # hostname ib-sw-01 ib-sw-01 (config) # interface mgmt0 ib-sw-01 (config-if) # ip address 192.168.200.2/24 ib-sw-01 (config-if) # no ipv6 enable ib-sw-01 (config-if) # exit ib-sw-01 (config) # show version这里interface mgmt0是交换机带外管理口，不参与 IB 数据转发。no ipv6 enable是我个人的习惯，减少管理面不必要的协议暴露。show version输出的固件版本要和白皮书标注的支持版本对照：如果固件太老，建议先升级再部署，因为早期固件的嵌入式 SM 在部分拓扑下存在邻居表刷新慢的问题，这类问题不会在端口计数器里暴露，只能靠升级解决。
4.2 Partition 与 PKey 的配置步骤：不做分区就是给自己埋雷
IB 的分区机制类似以太网的 VLAN，通过 16 位 PKey 标识一个通信域。不配置分区时，所有端口默认都在default分区（PKey 0xffff）里，这对小集群够用，但只要网络中混入存储节点、登录节点和计算节点，我建议按角色划分分区，防止存储的监控流量和 MPI 计算的流量互相影响。
在 SX6015 上创建分区的常见方式：
ib-sw-01 (config) # ib partition compute ib-sw-01 (config ib partition compute) # pkey 0x8001 ib-sw-01 (config ib partition compute) # member 1/1-16 ib-sw-01 (config ib partition compute) # exit ib-sw-01 (config) # ib partition storage ib-sw-01 (config ib partition storage) # pkey 0x8002 ib-sw-01 (config ib partition storage) # member 17-18member后面的数字是交换机物理端口号，这个例子里 1 到 16 口给计算节点，17 和 18 口给存储。主机侧同样要把 HCA 端口的 PKey 配置为相同的值，否则即使交换机放行，网卡也会在入向丢弃不匹配 PKey 的报文。在 Linux 主机上可以通过echo 0x8001 > /sys/class/infiniband/mlx5_0/ports/1/pkeys/0的方式覆盖第一个 PKey 槽位，但更推荐在 distribute 方式下由 SM 统一下发，减少手工不一致。
| PKey 值 | 用途 | 备注 |
|---|---|---|
| 0xffff | 默认分区 | 所有端口默认都在，通常用于管理 |
| 0x8001 | 计算节点 | 高位为 1 表示完整成员 |
| 0x8002 | 存储节点 | 可与计算节点隔离 |
4.3 QoS 与参考参数：把 MTU、SM sweep 和重试参数一次调对
SX6015 的 QoS 配置项不像以太网交换机那么多，因为 IB 的流控主要在链路层 Credit 上，不需要配置 PFC 或 ECN。真正影响性能的是三个点：链路 MTU、SM 的 sweep 间隔和链路层重试参数。
MLNX-OS 中设置全局 IB MTU：
ib-sw-01 (config) # ib mtu 4092 ib-sw-01 (config) # ib port 1/1 smtu 4092MTU 推荐 4092 而不是更大值。IB 的经典报文最大是 4KB 用户数据加上 40 字节以上头部，4092 在 FDR 链路下能兼顾吞吐和延迟。如果混接过 QDR 的老 HCA，端口 MTU 会自动协商到对端能力，不用统一改小。
链路层重试参数在主机侧更常用：
ibstat -l | while read dev; do echo "device $dev" cat /sys/class/infiniband/$dev/ports/1/rate done链路重传次数在 HCA 侧由驱动参数retry_count控制，常见做法是设成 7 而不是默认的 0，这样链路抖动时有足够的重试空间，又不至于让连接迟迟不报错。注意retry_count调大后，应用层 RPC 超时要设置得比链路重试时间长，否则应用已经在报错了，链路层还在兜底重试。
5. 用白皮书参数给 SX6015 做一次收发验收与排错手法
5.1 三连命令：物理层、吞吐、延迟分开测
验收 SX6015 时不要只跑一次ib_write_bw就算完。我一般按物理层、吞吐、延迟三次测试递进，故障时能直接定位到是哪一段出了问题。
ibdiagnet -c-c参数让 ibdiagnet 遍历所有链路并检查 CRC 错误。跑完看输出末尾的链路错误表格，如果某个端口 CRC 错误数不为零，优先排查对应线缆的连接器是否污染或插接到位。
ib_write_bw -d mlx5_0 -q 8 -s 4194304 --report_gbits-s 4194304是 4MB 消息长度，针对大包吞吐场景；-q 8是 8 个 QP 并发，尽量打满多条通道。FDR 链路上单 QP 一般达不到线速，多 QP 并发时如果吞吐总在某个固定值上不去，去交换机上看show ib port 1/1 counters的 discard 字段。
ib_write_lat -d mlx5_0延迟测试用小包跑，测试结果看双向发送的平均延迟。同一台 SX6015 下两个节点之间 ping delay 超过 3 微秒就值得关注，通常是 SM 把路径算歪了或者 MTU 太小导致拆包。
5.2 端口 up 但吞吐异常的排查顺序
第一步看速率是否协商掉档，第二步看链路 CRC，第三步看 SM 是否把两个节点规划到了同一个交换机端口对，最后才是怀疑线缆。这个顺序不能反，因为多数“慢”其实是协商掉档造成的，根本不是拥塞或丢包。
ibdiagnet -c输出的链路错误表里，重点关注Symbol errors和Link error recovery两列。Symbol error 持续增长说明物理层不稳定，铜缆超过 3 米建议直接换光模块；Link error recovery增多说明链路在反复重训练，老光模块在高温下最容易出现这种问题。把ibdiagnet -c的输出保存下来，下次再出现带宽问题时和旧文件做 diff，新增的错误端口往往就是故障点。
本文还有配套的精品资源，点击获取
