3. 子网管理器角色：SM功能、主备机制、与子网管理代理（SMA）的交互
3.1 核心原理：SM 在 IB 子网中的中枢地位
InfiniBand（IB）子网与以太网最大的区别在于：IB 网络并非依靠设备自协商与泛洪广播来转发数据，而是由子网管理器（Subnet Manager, SM）作为唯一权威控制平面，集中计算并下发所有转发规则。SM 负责发现物理拓扑、分配 Local ID（LID）、配置路径表、监控链路状态，并维护整个子网的转发数据库。可以这样理解：IB 交换机本身不具备智能转发能力，它们只是执行 SM 下发的线性转发表（LFT）和交换机转发表，因此 SM 的可用性与正确性直接决定整个 IB 集群的生死。
SM 运行在哪个节点上并不固定，它可以运行在专用管理服务器、存储网关，甚至某个计算节点的软件进程中。但无论运行在哪里，SM 都必须能够通过子网管理接口（SMI）与所有交换机、CA（Channel Adapter）通信。SM 使用子网管理报文（Subnet Management Packet, SMP）完成所有管理操作，而 SMP 的接收方——无论是交换机还是 CA——都内置一个被称为子网管理代理（Subnet Management Agent, SMA）的实体。SMA 是每个 IB 设备上被动响应 SM 请求的“客服窗口”，它负责解析 SMP 并读写设备内的管理数据库。
关键认知：SM 是“大脑”，SMA 是分布在每个设备上的“神经末梢”。SM 主动发起查询/设置，SMA 被动响应。没有 SMA，SM 将无法感知设备存在；没有 SM，SMA 只是一堆无法自我组织的寄存器。
3.2 方法流程：SM 主备机制与故障切换
在生产环境中，SM 绝不能是单点。IB 规范定义了主备 SM 协商机制，允许多个 SM 实例同时运行在子网中，但同一时刻只有一个是 Master，其余均为 Standby。每个 SM 实例在启动时都会向子网内广播包含自身优先权（Priority）和GUID 的 Hello 报文。优先权数值越高（0~15），成为 Master 的可能性越大。当两个 SM 的优先权相同时，GUID 较小者胜出。
主备切换的完整流程如下：
- 心跳监控：Master SM 周期性（默认 1 秒）发送 Hello 报文；Standby SM 监听该报文并维护一个超时计时器（通常为 3 倍 Hello 间隔）。
- 超时判定：若 Standby SM 在超时时间内未收到 Master 的 Hello，则判定 Master 失效。
- 接管准备：Standby SM 进入 Discovering 状态，开始主动发送 SMP 扫描子网拓扑。
- 全量重配置：新 Master 重新执行完整的子网发现、LID 分配、路径计算和 LFT 下发流程。此时网络可能出现短暂的数据面中断（秒级）。
- 状态同步：新 Master 完成配置后，继续周期性发送 Hello，宣告自己成为 Master，其他 Standby 回归监听状态。
运维提示：在 Mellanox/NVIDIA 环境中，使用 opensm 时可通过 -p 参数指定优先权，例如 opensm -p 15 表示最高优先权。建议在专用管理机上配置优先权 15，在备用机上配置 10~14，避免因 GUID 比较产生意外选主。
3.3 案例场景：双 SM 配置与手动切换演练
某 GPU 集群使用两台管理服务器运行 opensm，配置如下：
# 管理节点 A (主)
opensm -p 15 -g 0x98039b03009f3ae6 --guid 0x98039b03009f3ae6 -F /etc/opensm/opensm.conf
# 管理节点 B (备)
opensm -p 10 -g 0x98039b03009f3ae7 --guid 0x98039b03009f3ae7 -F /etc/opensm/opensm.conf当节点 A 因内核升级需要重启时，运维人员观察到节点 B 的日志中出现以下序列：
SM 0x98039b03009f3ae7: Standby -> Discovering (Master timeout)
SM 0x98039b03009f3ae7: Discovering -> Master (sweep done, 128 ports found)
SM 0x98039b03009f3ae7: LID assignment complete (0x0001 - 0x0080)
SM 0x98039b03009f3ae7: LFT programming complete on all switches整个切换过程耗时约 4.2 秒，期间集群文件系统（基于 IB 的 RDMA）出现短暂 IO 延迟，但未发生连接断开。这得益于子网重新配置超时（Subnet Timeout）参数被设置为 2000ms，且 MPI 应用使用了 RC（可靠连接）传输，具备一定的重试容忍度。
3.4 误区与复盘：SM 运维中的常见陷阱
| 误区 | 后果 | 正确做法 |
|---|---|---|
| 所有 SM 使用相同优先权 | GUID 小的节点始终胜出，无法实现预期的主备角色分配 | 明确设置不同优先权，主节点高 3~5 个数值 |
| 忽略 SMA 的响应超时 | SM 反复重试 SMP，导致拓扑发现缓慢 | 检查交换机/CA 的 SMA 是否被防火墙或驱动禁用 |
| 主备切换后未检查 LFT | 部分交换机仍保留旧 LID 映射，造成路径黑洞 | 切换后执行 ibroute 或 sminfo 验证全量 LFT |
| 将 SM 运行在计算节点上 | 计算节点重启导致 SM 丢失，影响全子网 | SM 应部署在专用管理机或存储网关 |
严重警告：切勿在 IB 子网中同时运行两个互不感知的 SM（例如误启动两个 opensm 实例且未配置主备协商）。这会导致两个 SM 同时下发不同的 LFT，交换机将交替执行互相矛盾的转发规则，最终造成全网瘫痪。务必使用 opensm -V 查看当前 SM 状态，并确认只有一个 Master。
3.5 与 SMA 交互的排障要点
当 SM 无法管理某个设备时，首先应确认该设备的 SMA 是否正常响应。使用 ibquery 工具可以直接发送 SMP 查询设备属性：
# 查询交换机端口状态
ibquery -C 0x98039b03009f3ae6 -P 12 NodeInfo
# 查询 CA 的端口 GUID
ibquery -C 0x98039b03009f3ae6 -P 1 PortInfo如果命令超时，可能原因包括：SMA 固件异常、SMP 被交换机 ACL 过滤、或该端口处于 Down 状态。此时应检查物理链路和端口 LED 状态，并使用 ibstat 查看端口物理状态是否为 LinkUp。SMA 是设备固件的一部分，无法单独重启；若 SMA 无响应，通常需要重启设备或进行固件升级。