📚 课程目录第4章子网管理器（SM）

4. 子网管理器（SM）

核心原理：SM 是 IB 子网的“控制面大脑”

InfiniBand 网络与以太网最大的区别之一，在于它不是一个“即插即用、自学习”的网络。IB 子网中的所有转发行为——数据包从哪个端口进、从哪个端口出、走哪条物理链路、使用什么 SL（服务等级）——都必须由子网管理器（Subnet Manager, SM）预先计算并下发。SM 运行在子网中的某个节点上（通常是交换机或专用管理服务器），通过子网管理接口（SMI）与所有端节点（HCA、交换机、路由器）通信。

SM 的核心职责可以概括为四个动作：发现（Discovery）、计算（Routing）、配置（Configuration）、监控（Monitoring）。启动时，SM 发送 SMP（Subnet Management Packet）广播，发现所有在线节点和链路；然后根据拓扑计算最短路径或自定义路径，生成线性转发表（LFT）；接着将 LID（局部标识符）、LFT、SL2VL 映射等参数下发到每个交换机端口；最后持续监听拓扑变化（如链路断开、新节点加入），并触发重新配置。

关键认知：IB 网络的数据平面（Data Plane）是“哑”的——交换机本身不学习 MAC 地址，也不运行路由协议。所有转发决策都依赖 SM 下发的表项。如果 SM 失效且无备份接管，整个子网将进入“冻结”状态，新流量无法建立，已建立的 QP（队列对）连接也会因路径重试超时而中断。

SM 配置方法与关键参数

在 Mellanox/NVIDIA 环境中，SM 通常运行在 OpenSM 守护进程中。配置的核心文件是 opensm.conf，但多数生产环境通过命令行参数或运行时选项进行调优。以下是最常用的配置维度：

优先级（Priority）：决定主备选举结果。数值范围 0~15，数值越大优先级越高。主 SM 通常设为 8，备 SM 设为 4~7。
心跳间隔（Heartbeat Timeout）：主备之间通过 SMP 或专用通道交换心跳。默认 1 秒，建议根据网络规模调整到 2~3 秒，避免误切换。
LFT 计算方式：支持 minhop（最小跳数）、updn（上下行规则）、fat-tree（胖树优化）等算法。生产环境推荐使用 fat-tree 或 updn，避免 minhop 在非对称拓扑中造成拥塞。
重试与超时：sweep_interval 控制 SM 扫描子网拓扑的频率，默认 10 秒。链路抖动频繁时，可适当增大到 30 秒，减少不必要的重配置。

# 启动主 SM（在管理服务器上）
opensm -g 0x98039b03009f3dca -p 0 -B -F /etc/opensm/opensm.conf \
       --priority 8 --lid 1 --smkey 0x1234

# 启动备 SM（在另一台服务器上）
opensm -g 0x98039b03009f3dcb -p 0 -B -F /etc/opensm/opensm.conf \
       --priority 4 --lid 2 --smkey 0x1234

# 查看当前 SM 状态
opensm -Q  # 查询主 SM 信息
ibstat    # 查看本机 SM 状态

生产建议：不要将 SM 运行在计算节点上。计算节点的 OS 重启、驱动升级或高负载都可能导致 SM 进程中断。独立管理服务器或交换机内置 SM 模块是更稳妥的选择。

冗余与故障切换机制

IB 子网允许同时存在多个 SM，但同一时刻只有一个处于 Master 状态，其余为 Standby 或 Discovering 状态。主备之间通过 SM 状态协商（基于 SMP 中的 SMInfo 属性）完成选举。选举规则依次比较：

SM 优先级（Priority）—— 数值大者胜出；
SM GUID（全局唯一标识）—— 数值小者胜出（作为 tie-breaker）。

当主 SM 发生故障（进程崩溃、网络分区、服务器宕机）时，备 SM 在心跳超时后自动进入 Master 状态，并执行全量重发现（Full Rediscovery）。这个过程包括：重新扫描所有交换机端口、重新计算路由表、重新下发 LFT 和 SL2VL 映射。对于 100~200 节点的中小型子网，切换时间通常在 1~3 秒内完成；对于超大规模集群（超过 1000 节点），可能需要 5~10 秒。

故障场景	切换时间	对业务影响	推荐缓解措施
SM 进程崩溃（OS 存活）	< 2 秒	新建 QP 失败，已有连接短暂重试	使用 systemd 守护自动重启；备 SM 常驻
服务器宕机 / 网络分区	3~10 秒	所有依赖 SM 的路径重算，可能丢包	双 SM 部署在不同机架/电源域
链路抖动导致反复重配置	持续振荡	LFT 频繁更新，数据面不稳定	调整 sweep_interval，检查光模块/线缆

案例：双 SM 配置实战与验证

某 GPU 集群使用 8 台交换机（2 台核心 + 6 台叶），共 128 个计算节点。初始配置仅运行一个 SM 在管理服务器上，某次管理服务器因内核升级重启，整个集群的 IB 通信中断了 15 分钟（直到 SM 服务手动拉起）。复盘后决定部署双 SM：

主 SM：管理服务器 A（IP 10.0.0.10），优先级 8，LID 1；
备 SM：管理服务器 B（IP 10.0.0.11），优先级 5，LID 2；
两台服务器通过独立管理网段（非 IB）互联，心跳走 TCP 443 端口。

# 服务器 A 上验证主 SM 状态
$ opensm -Q
SM: 0x98039b03009f3dca
  State: MASTER
  Priority: 8
  LID: 1

# 服务器 B 上验证备 SM 状态
$ opensm -Q
SM: 0x98039b03009f3dcb
  State: STANDBY
  Priority: 5
  LID: 2

# 模拟故障：在 A 上执行 systemctl stop opensm
# 等待 3 秒后，在 B 上查询
$ opensm -Q
SM: 0x98039b03009f3dcb
  State: MASTER
  Priority: 5
  LID: 2

切换完成后，检查所有交换机端口的 LFT 是否已重新下发：

# 在核心交换机上查看转发表
ibswitches -l
# 确认所有端口处于 Active 状态
ibportstate -G 0x98039b03009f3dca 1

常见误区：不要以为备 SM 会“热同步”主 SM 的 LFT。实际上备 SM 在接管后必须从零开始重新发现拓扑。如果网络规模很大，这个过程可能耗时较长。建议在备 SM 上启用 --fast_reboot 选项，利用缓存的部分拓扑信息加速启动，但前提是拓扑没有发生结构性变化。

误区与复盘：SM 配置中的典型陷阱

误区一：SM 优先级设置过高导致频繁切换。如果主备优先级只差 1（如 8 和 7），当主 SM 短暂抖动时，备 SM 可能立即抢占，而主 SM 恢复后又抢回，造成“乒乓效应”。建议优先级差至少 3 以上。
误区二：忽略 SM 的 GUID 稳定性。某些虚拟化环境中，SM 的 GUID 会随虚拟机迁移而变化，导致主备选举结果不可预期。务必为 SM 绑定固定的 GUID（通过 opensm -g 指定）。
误区三：所有交换机都启用内置 SM。部分交换机默认开启内置 SM，如果未配置优先级，它们可能参与选举并意外成为主 SM，导致路由策略不符合预期。应在非管理交换机上禁用内置 SM（sm_disabled）。
误区四：故障切换后未验证数据面。SM 切换成功不代表业务无损。切换后应主动检查：ibdiagnet 验证拓扑完整性，ib_read_lat 测试端到端延迟，确认所有 HCA 的 LID 和 GID 未发生冲突。

复盘结论：SM 的冗余设计不能只停留在“多跑一个进程”的层面。必须从选举优先级、心跳网络独立性、GUID 固定、切换后验证四个维度系统设计。建议每季度进行一次主备切换演练，记录实际切换时间，并对比 SLA 要求。对于超大规模集群，可考虑将 SM 部署在带外管理网络中，彻底隔离 IB 数据面故障对 SM 的影响。