2. IB技术基础：InfiniBand架构、协议栈、子网管理器（SM）与子网代理（SA）的作用
2.1 InfiniBand整体架构：从端点到交换矩阵
InfiniBand（IB）是一种面向高性能计算（HPC）和人工智能（AI）数据中心的高带宽、低延迟互联技术。与以太网“即插即用”的松散管理方式不同，IB网络采用集中式管理的架构，其核心设计目标是让数据在子网（Subnet）内以极高的效率、极低的丢包率传输。
一个典型的IB子网由以下关键组件构成：
- 端节点（End Node）：如GPU服务器、存储设备，通过主机通道适配器（HCA，Host Channel Adapter）接入IB网络。每个HCA至少有一个端口（Port）。
- 交换机（Switch）：负责在子网内转发数据帧。交换机本身不是端节点，它不产生或消费应用数据，只负责根据转发数据库进行报文转发。
- 子网管理器（SM，Subnet Manager）：运行在某个指定节点（可以是交换机、专用管理服务器或HCA）上的软件实体，是整个子网的“控制大脑”。
- 子网代理（SA，Subnet Administrator）：通常与SM位于同一物理节点，作为端节点查询子网信息的“数据库服务”接口。
2.2 IB协议栈与报文封装
IB协议栈采用分层设计，与OSI模型有对应关系，但更精简高效。理解协议栈有助于在排查问题时定位“是哪一层出了问题”。
| OSI 层次 | IB 协议层 | 核心功能 | 典型问题排查点 |
|---|---|---|---|
| L2 (数据链路) | 链路层 (Link Layer) | 帧封装、流控、CRC校验、链路状态管理 | 链路Down、CRC错误、信号完整性 |
| L3 (网络) | 网络层 (Network Layer) | 全局路由（基于GID）、子网间转发 | 跨子网通信失败、GID配置错误 |
| L4 (传输) | 传输层 (Transport Layer) | 可靠连接（RC）、不可靠数据报（UD）、分段重组 | QP状态异常、重传超时、丢包 |
| L5-L7 (高层) | 上层协议 (Upper Layer) | RDMA操作、Sockets接口、MPI/UCX等 | 应用报错、内存注册失败 |
IB报文在链路上传输时，其基本封装格式为：
| LRH (本地路由头) | GRH (全局路由头，可选) | BTH (基础传输头) | 传输头 (可选) | Payload (数据) | ICRC | VCRC |其中LRH包含源/目的LID（Local Identifier，子网内16位地址），用于交换机在子网内转发；GRH包含128位GID（Global Identifier），用于跨子网路由；BTH包含队列对编号（QP Number）、操作码等关键信息。在排查“LID冲突”或“GID不可达”问题时，本质上就是在检查这些头部字段是否正确。
2.3 子网管理器（SM）的核心职责
SM是IB子网中最重要的控制实体。没有SM，IB交换机端口会停留在初始化状态（Initializing），不会转发任何数据。SM的主要职责包括：
- 子网发现（Subnet Discovery）：SM通过发送管理数据报（MAD，Management Datagram）扫描子网中的所有节点、交换机及链路拓扑。
- LID分配（LID Assignment）：为每个端节点端口分配唯一的16位LID。LID范围：0x0001~0xBFFF为可分配单播地址，0xC000~0xFFFF保留用于多播。
- 路径计算（Path Computation）：基于拓扑和链路状态，计算任意两个端口之间的最优路径（通常使用最短路径优先算法），并生成交换机的线性转发表（LFT，Linear Forwarding Table）。
- 链路状态监控：持续监控所有链路的状态变化（如端口Down、新链路加入），并触发重新配置。
ibstat 查看端口状态时，如果看到 State: Initializing 或 State: Down，通常意味着SM未正确管理该端口。使用 ibswitches 命令可以查看当前SM发现的交换机列表。
2.4 子网代理（SA）的作用与查询机制
SA可以理解为SM的“对外服务窗口”。端节点（如GPU服务器上的HCA驱动）在建立通信前，需要向SA发起查询请求，以获取目标节点的LID、路径信息、服务ID等。SA维护着一个包含子网全部信息的数据库，这些信息由SM在发现和计算过程中持续更新。
常见的SA查询场景包括：
- 路径查询（PathRecord）：源节点向SA询问“到目标LID的最佳路径是什么”，SA返回路径信息，包括源LID、目的LID、SL（服务等级）等。
- 服务查询（ServiceRecord）：应用程序通过SID（Service ID）查找提供特定服务的节点。
- 多播组查询：获取多播组的成员列表和MGID（多播GID）。
在命令行层面，最常用的SA查询工具是 ibqueryerrors 和 perftest 系列中的 ib_write_bw 等。而 ibfindnodesusing 可以基于服务ID查询节点。例如，要查看某个GID对应的路径记录，可以使用：
# 查看SA中缓存的路径记录（部分输出示例）
# saquery -p # 查询所有PathRecord
# 输出示例：
# PathRecord: (SL=0, PKey=0xffff)
# DGID: fe80::1, SGID: fe80::2
# DLID: 2, SL: 0, Port: 12.5 案例：SM故障导致全网通信中断
场景描述：某AI训练集群中，运维人员对核心交换机执行固件升级后，所有GPU服务器之间的RDMA通信全部超时，但SSH管理网络（走以太网）正常。
排查过程：
- 在任意一台GPU服务器上执行
ibstat，发现HCA端口状态为Active，但ibping无法ping通对端节点。 - 执行
ibswitches，发现SM只发现了一台交换机，而实际拓扑中有两台核心交换机。 - 检查SM日志，发现主SM运行在升级的那台交换机上，升级后SM进程未自动恢复，而备份SM（运行在另一台交换机上）因优先级配置错误未接管。
- 手动在备份交换机上启动SM服务：
systemctl start opensm，网络在数秒内恢复。
sm_priority）设置正确。同时，升级操作前应确认SM的故障切换机制已生效，避免“单点脑裂”风险。
2.6 常见误区与排查清单
以下是初学者在理解IB架构时容易混淆的概念，也是实际排障中的高频盲区：
| 误区/盲区 | 正确理解 | 验证命令 |
|---|---|---|
| 认为LID是固定的MAC地址 | LID由SM动态分配，重启后可能变化 | ibaddr |
| 混淆SM与SA的功能 | SM管“路径计算”，SA管“信息查询” | smquery / saquery |
| 以为交换机可以自发转发数据 | 交换机必须等待SM下发LFT后才转发 | ibroute |
| 忽略子网管理器的主备切换 | 主SM故障时，备份SM需在数秒内接管 | opensm -c 查看配置 |
最后，建议在IB网络变更后，立即执行一次完整的子网健康检查，包括：ibdiagnet（检查链路和拓扑完整性）、ibping（验证端到端连通性）、ibqueryerrors（检查链路错误计数）。将SM和SA的运行状态纳入监控告警，是保障IB网络长期稳定运行的基础。