4. InfiniBand子网管理器（SM）原理与部署

InfiniBand 子网要真正“活”起来，除了物理链路和子网前缀，还必须有一个逻辑上的“大脑”来发现拓扑、分配 LID、下发路由并持续监控链路状态，这个角色就是子网管理器（Subnet Manager，SM）。没有 SM，交换机和 HCA 之间即使物理连通，也无法完成地址分配和路由计算，节点之间不能建立正常的 IB 通信。理解 SM 的原理与部署，是 InfiniBand 组网从“能插上线”走向“能跑业务”的关键一步。

一、SM 的职责与 OpenSM / UFM 的角色分工

SM 的核心工作可以概括为四件事：拓扑发现（Discovery）、LID 分配、路由计算与下发、状态监控与重配置。SM 通过发送 SMP（Subnet Management Packet）遍历子网中的每个节点和端口，读取 NodeInfo、PortInfo、SwitchInfo 等属性，构建出完整的子网拓扑；随后为每个端口分配 LID（Local Identifier），并基于路由算法（如 Min Hop、Up/Down、Fat-Tree 等）计算转发表，写入交换机的线性转发表（LFT）。当链路发生 up/down 变化时，SM 需要重新扫描并更新转发表，保证业务不中断或快速恢复。

在 NVIDIA InfiniBand 生态中，SM 有两种典型实现：OpenSM 和 UFM（Unified Fabric Manager）。OpenSM 是开源的、轻量级的子网管理器，通常随 MLNX_OFED / DOCA 驱动一起安装，适合中小规模集群或作为 UFM 的备份 SM。它以命令行方式运行，配置文件为 /etc/opensm/opensm.conf，支持通过 opensm 命令启动，日志默认写入 /var/log/opensm.log。UFM 则是 NVIDIA 的商业化 Fabric 管理平台，除了 SM 功能外，还提供图形化拓扑视图、性能监控、告警、审计、REST API 以及多子网管理能力，适合大规模生产环境。

两者的角色分工可以这样理解：UFM 是“主控 + 运维平台”，OpenSM 是“可独立运行的 SM 引擎”。在生产环境中，常见做法是让 UFM 作为主 SM，同时在一台独立服务器上运行 OpenSM 作为备份 SM，通过优先级（priority）决定谁成为 master。这样既获得 UFM 的可视化与运维能力，又避免 UFM 单点故障导致整个子网失去管理。

InfiniBand 子网管理器（SM）角色分工与主备选举 UFM（主 SM） Priority = 15（高） 拓扑视图 / 监控 / 告警 REST API / 多子网管理 OpenSM（备 SM） Priority = 5（低） opensm.conf 配置 日志 /var/log/opensm.log SMP 优先级比较 高优先级胜出 → Master InfiniBand 子网（Subnet Prefix: 0xfe80::/64） SM 通过 SMP 管理所有节点与交换机 SMP 下发 SMP 下发 IB 交换机 A LID: 0x0001 IB 交换机 B LID: 0x0002 IB 交换机 C LID: 0x0003 HCA 节点 1 HCA 节点 2 HCA 节点 3 主 SM 备 SM

二、主备 SM 选举机制

一个子网中可以有多个 SM 同时运行，但同一时刻只能有一个处于 master 状态，其余处于 standby 状态。选举的核心依据是 SM 优先级（priority），取值范围通常为 0～15，数值越大优先级越高。当多个 SM 同时存在时，它们会通过 SMP 交换 SMInfo 属性，比较优先级；优先级高者成为 master，优先级相同则比较 GUID（全局唯一标识符），GUID 较小者胜出。

主备切换的触发条件包括：master SM 进程退出、主机宕机、网络隔离导致心跳丢失，或管理员手动切换。切换过程中，standby SM 会重新扫描拓扑并下发转发表，业务可能出现短暂中断（通常在秒级）。为了减少切换影响，建议将主备 SM 部署在独立的管理服务器上，并通过带外管理网络保证它们之间的连通性。

在 OpenSM 中，优先级通过配置文件设置：

# /etc/opensm/opensm.conf 关键参数
sm_priority 5          # 备 SM 设为较低优先级
subnet_prefix 0xfe80   # 子网前缀，必须与主 SM 一致
routing_engine minhop  # 路由算法，需与主 SM 保持一致

UFM 中则通过 Web 界面或 REST API 设置 SM 优先级，并可以查看当前 master/standby 状态。需要注意的是，主备 SM 的 subnet_prefix 和 routing_engine 必须一致，否则切换后路由行为可能发生变化，导致业务异常。

三、子网 ID 规划

子网 ID 由 subnet_prefix 和 SM 的 GUID 共同决定，其中 subnet_prefix 是 64 位值，默认通常为 0xfe80。在单子网环境中，使用默认值即可；但在多子网或需要与以太网融合的场景中，必须提前规划，避免不同子网之间前缀冲突。

规划原则如下：

  • 同一子网内所有 SM 必须配置相同的 subnet_prefix。
  • 不同子网使用不同的 subnet_prefix，便于路由和隔离。
  • subnet_prefix 一旦确定，不建议随意更改，否则所有 LID 和路由表都需要重新生成。
  • 如果使用 UFM 管理多个子网，应在 UFM 中为每个子网分配独立的前缀，并记录在案。

例如，一个包含三个子网的数据中心可以规划为：子网 A 使用 0xfe80，子网 B 使用 0xfe81，子网 C 使用 0xfe82。这样在排查问题时，通过 subnet_prefix 就能快速判断节点属于哪个子网。

四、SM 配置参数调优

OpenSM 的性能和稳定性很大程度上取决于配置参数。以下是一些关键参数及其调优建议：

参数 作用 建议值 / 说明
sm_priority SM 优先级 主 SM 设 15，备 SM 设 5，避免频繁切换
routing_engine 路由算法 中小规模用 minhop；大规模 Fat-Tree 用 updn 或 fat-tree
max_op_vls 最大虚拟通道数 默认 1，高并发场景可适当增加
sweep_interval 拓扑扫描间隔（秒） 默认 10，大规模子网可增至 30，减少 CPU 开销
log_flags 日志详细程度 生产环境建议 0x03，调试时临时提高

调优时需注意：sweep_interval 过小会导致 SM 频繁扫描，增加 CPU 和网络负担；过大则链路故障发现延迟，影响业务恢复速度。建议根据子网规模（节点数、交换机数）和业务对中断的容忍度综合设定。对于超过 1000 节点的子网，通常将 sweep_interval 设为 20～30 秒，并启用增量扫描（--incremental）以减少全量扫描开销。

五、高可用实践

高可用的核心目标是：任何单点故障都不应导致子网管理中断。建议从以下三个层面实施：

  1. SM 冗余：至少部署两个 SM（UFM + OpenSM，或双 OpenSM），配置不同优先级，确保一个故障时另一个能接管。
  2. 管理网络冗余：SM 所在服务器应通过带外管理网络互联，避免业务网络故障导致 SM 之间无法通信。
  3. 配置一致性：主备 SM 的 subnet_prefix、routing_engine、max_op_vls 等关键参数必须一致，建议使用配置管理工具（如 Ansible）统一推送。
实践提示：在切换测试中，可以手动停止主 SM 进程，观察备 SM 是否在 5～10 秒内变为 master，并通过 ibstat 或 iblinkinfo 验证节点 LID 和路由是否正常。如果切换后业务不通，优先检查主备 SM 的 routing_engine 是否一致。
注意：不要在同一台服务器上同时运行 UFM 和 OpenSM 作为主备，因为主机故障会导致两个 SM 同时失效。主备 SM 应部署在不同物理服务器上。

最后，建议为 SM 配置监控告警：监控 master/standby 状态、SM 进程存活、日志中的错误关键字（如 “sweep failed”、“no route”），以及子网中 LID 分配是否完整。这样可以在问题影响业务之前及时发现并处理。

← 上一章 📖 返回目录 下一章 →