InfiniBand 专题【左扬精讲】—— InfiniBand 子网管理器的三种运行形态：交换机内嵌、服务器 OpenSM 与 UFM 平台
InfiniBand 专题【左扬精讲】—— InfiniBand 子网管理器的三种运行形态：交换机内嵌、服务器 OpenSM 与 UFM 平台
子网管理器是整片 fabric 里唯一一个"必须只有一个、却可能跑在任何地方"的组件。本系列第八篇讲子网初始化时，把 SM 当成一个抽象的角色来用——它发现拓扑、分配 LID、计算路径、激活子网；第九篇讲监控时，把 SM 当成一个会选举、会故障切换的实体来讲。但这个实体本身跑在什么硬件上、以什么形态部署、谁给它发配置、它到底能被信任到什么程度，前面几篇都没有正面回答。而这恰恰是建网第一天就要拍板的决策。
本篇是 InfiniBand 专题【左扬精讲】 系列的 第 13 篇，主题是子网管理器（Subnet Manager）的三种运行形态、选型考量与各自的配置方法。全文按"三种形态分别是什么 → 选型看哪几个维度 → 每种形态怎么跑起来、怎么配、怎么确认它真的在跑"的顺序展开。三种形态分别是：跑在托管交换机内嵌的 MLNX-OS 里、跑在服务器上安装的 OpenSM、跑在统一平台 NVIDIA UFM 上。
开篇必读：课程口语转写里的五组高频误听，本文全部按真实标识符纠正
本篇素材来自一段英文课程的口语转写，转写引擎对专有名词的还原率很低。以下五组对照是全文可复现性的前提——照着转写稿敲命令一定敲不通：
- "m l n x o s" / "m l n X o fed" → MLNX-OS。转写把同一个词在两处听成了两种拼写，课程里指的是同一个交换机操作系统（托管交换机的操作系统），不是服务器侧的 OFED 发行版。
- "m q m eighty seven hundred" → MQSM8700-HS2，"m q m eighty seven ninety" → MQSM8790-HS2。二者都是 Mellanox Quantum 系列 1U HDR 200Gb/s 交换机，SKU 表里 MQSM8700 为托管、MQSM8790 为非托管。本文统一用 4 位简写 QM8700 / QM8790。
- "ib s m" 的拆分 → ib sm，"ibs m dash priority" → ib sm sm-priority，"ibsm routing dash engine" → ib sm routing-engines。口语转写常把一条 CLI 命令拆成两个词，但 CLI 里的连字符与空格是有语义的，见 4.3 节。
- "e tsy in it dot d open SM" → /etc/init.d/opensm，"var log open SM dot log" → /var/log/opensm.log，"e tsy open SM open SM dot comf" → /etc/opensm/opensm.conf。conf 被听成了 comf。
- "the uf m" → UFM（Unified Fabric Manager，统一 fabric 管理器）。课程口语里有时拆成 u f m，有时缩成 uf m，指同一个平台。
还有一处需要单独纠正：转写稿说"内嵌在 MLNX-OS 的 SM 与 DOA OFED 里的 OpenSM 都支持自适应路由和 Dragonfly+ 路由引擎"。这句话对服务器侧成立，对交换机内嵌 SM 不成立——NVIDIA MLNX-OS 文档明确列出内嵌 SM 的能力边界，详见 4.2 节。照转写稿理解会直接导致选型错误。
本篇核心术语：
Subnet Manager 子网管理器 / SM 子网管理器 / SMA 子网管理器代理 / MAD 管理数据报
Managed Switch 托管交换机 / Unmanaged Switch 非托管交换机 / Externally Managed 外部托管
MLNX-OS 交换机操作系统 / On-board SM 板载子网管理器 / In-band 带内管理 / Out-of-band 带外管理
OpenSM 子网管理器守护进程 / opensmd 守护进程包装 / opensm.conf 配置文件
UFM Unified Fabric Manager 统一 fabric 管理器 / UFM Enterprise 企业版 / UFM Telemetry 遥测版
UFM Cyber-AI 智能安全分析版 / Appliance 硬件一体机 / Web UI 基于 Web 的界面
Fabric Discovery 网络发现 / Network Provisioning 网络配置下发 / Congestion Discovery 拥塞发现
SM Priority 子网管理器优先级 / Port GUID 端口 GUID / Heavy Sweep 重扫描
Switch SDK 交换机 SDK / Licensing 授权许可 / Free of Charge 免费提供
本篇核心命令与路径：
show ib sm 查看交换机侧 SM 状态 / ib sm 启用交换机内嵌 SM
ib sm sm-priority 1-15 设置优先级 / ib sm routing-engines 设置路由引擎
ib sm reassign-lids 是否重新分配 LID / ib sm sweep-interval 扫描间隔
/etc/init.d/opensm start 启动 OpenSM 服务 / /etc/init.d/opensm status 查看状态
opensm -d 前台调试运行 / opensm -c 生成配置文件 / opensm --help 查看全部选项
/etc/opensm/opensm.conf 配置文件 / /var/log/opensm.log 详细日志 / /var/log/messages 重大事件
本篇权威依据：
NVIDIA MLNX-OS User Manual —— ib sm 命令族、ib sm sm-priority 取值 0-15、
ib sm routing-engines 支持的引擎名、内嵌 SM 的能力边界与 2048 节点上限
NVIDIA QM87xx 1U HDR 200Gb/s InfiniBand Switch Systems User Manual —— QM8700/QM8790 托管形态
opensm(8) man page —— 日志路径、SUBNET UP 判据、配置文件默认位置
NVIDIA MLNX SM Release Notes 5.10 / 5.11 —— 路由引擎默认值变更历史
NVIDIA UFM Enterprise User Manual —— Settings 菜单结构、SM 配置项表、许可模型
NVIDIA UFM 产品页 —— Telemetry / Enterprise / Cyber-AI 三级能力划分InfiniBandSubnet ManagerOpenSMMLNX-OSUFMManaged SwitchSM Priorityopensm.confFabric ProvisioningSwitch SDKQM8700QM8790Out-of-bandWeb UI
★ 学完这一篇你能掌握什么（渐进式路径：1→2→3→4 不可跳跃）
- 第 1 步 · 分清三种形态的物理差异（第一节、第二节）
• What：托管交换机有独立 CPU 与带外管理口；非托管交换机只有固件、既无带外管理也无 SM 能力；OpenSM 跑在服务器上；UFM 是带 Web UI 的管理平台
• How：能说出"为什么带内管理与带外管理是两件独立的事"，以及非托管交换机不是"简配版托管交换机"，而是另一种设备形态
• Why：理解 "为什么全部交换机都被带内管理，但只有一部分有带外管理"——两条通道服务于两类完全不同的需求- 第 2 步 · 掌握选型的三个维度（第三节、第四、第五节）
• What：规模（节点数）、能力边界（自适应路由 / Dragonfly+）、成本（是否需要额外许可）
• How：能按节点规模给出选型区间，并说出每种形态各自的能力天花板在哪里
• Why：理解 "为什么交换机内嵌 SM 存在规模上限"——它受交换机 CPU 而非内存限制，以及这个限制为什么决定了它只适合中小规模- 第 3 步 · 会跑会配三种形态（第六、第七、第八节）
• What：MLNX-OS 侧用 ib sm 命令族；服务器侧用 /etc/init.d/opensm 脚本与 opensm.conf；UFM 侧用 Web UI 的 Settings 菜单
• How：能在三种形态下分别定位"SM 状态""优先级""路由引擎"三个参数的配置位置
• Why：理解 "为什么三种形态下同一个概念（路由引擎）的配置写法完全不同"——底层实现不同，但语义一致- 第 4 步 · 会比对三种形态（第九节、第十节、第十一节）
• What：三种形态在规模上限、能力覆盖、许可成本、配置入口、故障影响面上各不相同
• How：能对给定规模的 fabric 指出唯一合适的形态，并说明理由；能识别"当前部署形态的最小故障域是什么"
• Why：理解 "为什么 UFM 形态的授权成本随节点数线性增长"——这与 MLNX-OS 内嵌 SM 的免费形成鲜明对比，直接决定 TCO★ 阅读前提 & 本篇不涉及的内容
- 前置知识：本系列第一篇《InfiniBand 架构简介：从五层模型到子网管理》中的 SM / SMA / MAD 三元组与 Fabric vs. Subnet；本系列第八篇《子网初始化：拓扑发现、LID 分配、路径计算与子网激活》中的 SM 六阶段初始化与子网激活；本系列第九篇《SM 监控与拓扑变化：选举、故障切换、扫描与重收敛》中的 Master SM 选举、Light Sweep / Heavy Sweep 与 failover；本系列第十一篇《路由引擎：算法原理、选型对照与 OpenSM 配置验证》中的路由引擎全清单与选型判据。本篇不重复解释这些内容
- 信息来源：本篇出现的全部 CLI 命令（ib sm 命令族）、参数取值范围（ib sm sm-priority 0-15）、交换机型号与端口规格、能力边界表述、OpenSM 服务管理方式、UFM 菜单结构与许可模型，均引自文末「参考资料」列出的 MLNX-OS User Manual、QM87xx Switch Systems User Manual、opensm(8)、MLNX SM Release Notes 与 UFM Enterprise User Manual。课程口语素材仅用于还原讲师给出的组织逻辑与学习目标，不作为技术事实来源
- 本篇不涉及：路由引擎的算法原理与选型判据（第十一篇已完整覆盖）、UFM 的遥测与报表功能细节、OpenSM 的分片（partition）策略编写语法、SHARP 在机内的聚合卸载机制、IB Router 的路由配置
📑 本节目录（按"三种形态 → 选型 → 逐个配置 → 比对"的顺序）
一、SM 的部署形态：为什么会有三种选择
What — 课程开篇给出的三选项，以及它对 SM 职责的拆解
课程开门见山：在 InfiniBand fabric 里运行子网管理器一共有三个选项——在交换机上、在服务器上、或在统一 fabric 管理器（UFM）上。这是全篇的组织框架。
紧接着课程给出了一段对 SM 职责的拆解，这段拆解是理解"为什么形态会影响选型"的前提：
- 基础职责：初始化 fabric、计算转发表、配置节点、并监控变化（initialize the fabric, calculate the forwarding tables, configure the nodes, and monitor for changes）。这四件事是所有形态都必须完成的，属于底线要求。
- 增强特性：高级方案提供诸如自适应路由、Dragonfly+ 路由引擎等增强功能，可能显著提升性能（an advanced solution provides enhanced features such as adaptive routing and a dragonfly plus routing engine that may dramatically improve the performance）。关键句是"如果计划部署这些增强特性，就必须确认所选方案支持它们"——这是形态差异第一次真正产生影响的地方。
- 成本维度：所选方案是否有额外许可费用（is there a need for a special license）。这是形态差异第二次产生影响的地方。
课程随后明确了规模维度：InfiniBand fabric 的规模可能扩展到数百乃至数千个受管节点，因此需要一个能支撑高乃至超大规模 fabric 的 SM 方案。
把三段合起来，选型就只剩三个问题：你的 fabric 有多大？你的拓扑要用增强特性吗？你的预算允许买许可吗？第九至第十一节会把这三个问题变成一棵可执行的决策树。
先看以太网的情形。在以太网里，交换机不参与地址分配，路由协议跑在每台设备上（或由集中式控制器下发），没有哪个组件是"必须唯一存在、且必须由它分配全网标识"的。一台设备故障影响的是它自己；控制平面可以多实例并存、互为备份。
再看 InfiniBand 的情形。LID 是 16 位的单一编址空间，由一个 SM 独占分配；转发表由 SM 逐台编程；子网激活是 SM 单方面推进的全局状态机。这意味着 fabric 的控制平面是单点的、串行的、强序的——它不像以太网那样天然具备分布式可扩展性。
于是"把 SM 跑在哪里"就从一个运维细节升级成了一个架构决策，因为它决定了四件事：（1）SM 用的 CPU、内存与操作系统能力上限在哪（直接决定 fabric 能有多大）；（2）SM 能调用哪些厂商私有能力（直接决定能不能用自适应路由、Dragonfly+ 这类增强特性）；（3）SM 挂了之后谁能让 fabric 继续工作（直接决定故障影响面）；（4）谁在为这个组件付费（直接决定 TCO）。
这四点合起来解释了为什么同一个"子网管理器"在不同形态下会呈现出完全不同的产品——托管交换机内嵌的 MLNX-OS SM 受交换机那颗 x86 CPU 的限制，只能管到 2048 节点且不支持增强特性；服务器上的 OpenSM 突破了这两个限制且免费；而 UFM 在此之上又叠了一层遥测与 AI 分析能力，代价是按节点计费。形态选择的本质，是在这四项之间做取舍。
最后要指出一点本系列反复强调的机制约束：无论哪种形态，SM 依然是单个。UFM 界面可以有多个、UFM 服务器可以做成高可用集群、监控可以分布在所有节点上，但子网管理权在同一时刻只属于一个 Master SM。多实例不等于多主——第九篇讲的选举与 handover 机制在三种形态下完全一致，只是选举发生在哪台设备上不同。
本节关键记忆：3 种形态 + 4 项职责 + 3 个选型维度
- 3 种形态：交换机内嵌 / 服务器 OpenSM / UFM 平台
- 4 项底线职责：初始化 fabric、算转发表、配节点、监控变化——三种形态都必须做到，这是选型的及格线而非差异点
- 3 个选型维度：规模（数百到数千节点）/ 能力边界（自适应路由、Dragonfly+ 等增强特性）/ 成本（是否需要额外许可）
- 1 条硬约束：任何形态下同一时刻只有一个 Master SM——UFM 的高可用不等于 SM 的多主
二、形态一：托管交换机与非托管交换机
What — 课程对两类交换机的定义，以及它们与 SM 的关系
课程的第一条论断非常绝对，需要原样记住：所有 InfiniBand 交换机无一例外都以带内（in-band）方式被 Master SM 管理，这是 fabric 初始化与管理流程的一部分（all infiniband switches with no exceptions are managed in band by the master's subnet manager as part of the fabric initialization and management）。
请注意"带内管理"与"是否托管"是两个正交的维度。带内管理说的是"SM 通过 IB 链路管理交换机"这件事，它对所有交换机都成立，与交换机托管与否无关。而托管与否决定的是"除了带内，还有没有第二条管理通道"。
课程接着给出托管交换机的定义：托管交换机除带内管理外，还能从带外网络被管理；它们有独立 CPU、运行 MLNX-OS 操作系统，因此可以通过 CLI 或 Web UI 访问与配置。而 MLNX-OS 内嵌了子网管理器，可用来管理 fabric。
非托管交换机的定义则更简单也更绝对：非托管交换机（也称外部托管交换机）只有固件，因此既不支持带外管理，也不支持子网管理器能力（have a firmware only therefore no out of band management nor subnet manager capability are supported）。
| 维度 | 托管交换机（Internally Managed） | 非托管交换机（Externally Managed） |
|---|---|---|
| 软件栈 | 固件 + 独立 CPU 上的 MLNX-OS | 仅固件 |
| 带内 SM 管理 | 支持（所有交换机都支持） | 支持（所有交换机都支持） |
| 带外管理 | 支持，独立管理口 | 不支持 |
| CLI / Web UI | 均可 | 均无 |
| 内嵌 SM 能力 | 有，可独立运行 SM | 无 |
| 在 fabric 中的角色 | 交换机 + 可选的 SM 宿主 | 仅是交换机，必须依赖别处的 SM |
最容易踩的第一个坑：把"托管"当成"SM 归属"。
托管交换机可以跑内嵌 SM，但不一定要跑。一台托管交换机在 fabric 里完全可以只是被 Master SM 管理的普通转发设备，它是否承担 SM 角色，取决于你是否执行了 ib sm 命令。而 MLNX-OS 文档明确指出：子网管理器默认是关闭的（disabled by default）。所以"这台交换机是托管的"不能推出"这台交换机在跑 SM"，也不推出"这台交换机不是 Master SM"——只有选举结果才能决定谁是 Master，这一点在第九篇已经讲过。
关于两类交换机的具体型号与规格，以下为厂商公开规格，不含任何推测
课程用了一组具体设备做示例：托管型号 MQSM8700-HS2 与非托管型号 MQSM8790-HS2（SKU 表中的简写为 QM8700 与 QM8790）。二者同属 Mellanox Quantum 系列 1U HDR 200Gb/s 交换机系统：
- 端口配置相同：均为 40 个 HDR 200Gb/s QSFP56 端口，均为 16 Tb/s 聚合交换容量。
- 管理形态不同：NVIDIA 规格表在 Management 与 Subnet Manager 两列上明确区分——QM8700 为 Inband/outband 且 带 Subnet Manager（+）；QM8790 为 仅 Inband 且 不带 Subnet Manager（-）。
- CPU 配置：QM8700 配备 x86 双核 CPU，QM8790 无 CPU。
课程还描述了一个容易忽略的工程细节：带内管理由 SM 承担，带外管理由管理口承担，两者用的是不同的物理路径。课程原话是：SM 通过 InfiniBand fabric 以带内方式管理交换机，用于子网管理目的；托管交换机有一个额外的、不属于 InfiniBand fabric 的管理口，因此用于带外管理；这是一个常规的 RJ45 以太网口，连接到以太管理网络，允许通过 CLI 或 Web UI 远程访问交换机。
这条细节的工程含义要说清楚：带外管理口不通 InfiniBand 链路。它的意义在于，即便 IB 侧完全瘫痪——包括带内管理通道失效——你仍然有一台不依赖 IB 的设备可以登录。这是故障时的最后一条通道，第十一节会展开它的价值。
先看两种形态在物理上的差别。托管交换机是一个带 CPU 的整机：它有自己的处理器、自己的存储、自己的操作系统（MLNX-OS）、自己的管理口，因此具备自主计算与自主交互的能力。非托管交换机则只是一块转发引擎 + 固件：它能在 SM 编程下转发数据包，但它不能自主发起管理交互——没有 CPU 去跑 SSH 服务器，没有 Web 服务可以连，也没有独立的通道能绕过 IB 侧。
这个差别带来一个直接推论：非托管交换机的生命周期完全依附于 SM。它能被配置的唯一途径是带内 SMP 交互，而带内通道的可用性又依赖于它自身在线且链路正常。也就是说，非托管交换机一旦脱离 fabric，就变成一块无法自证状态的硬件。相比之下，托管交换机即使脱离 fabric，你仍然可以通过以太管理口登录上去，读它的固件版本、看它的端口状态、升级它的软件。这是两种形态最本质的可运维性差异。
第二个推论关系到采购与部署成本结构。非托管交换机没有 CPU 与管理口，意味着它在物料成本与机架空间上都更省。当 fabric 从几十台扩到上千台、且每台交换机成本都要乘以节点数时，这个差额会累积成可观的量。反过来，托管交换机的 CPU 与管理口是为"它可能要承担 SM 角色"而预留的——你为那份"可能"付了钱，但绝大多数设备一辈子都不会用到那个能力。
第三个推论是本节最实用的一条：把 SM 角色与设备托管形态解耦。
常见而合理的设计是：只在少数几台（甚至一台）设备上启用内嵌 SM，其余全部用非托管型号。这样既拿到了"SM 就在交换机里、不依赖任何服务器"的便利，又把带外管理这条冗余通道的成本限制在极少数设备上。而如果你的 fabric 规模大到 2048 节点以上、或者需要自适应路由与 Dragonfly+，那么内嵌 SM 这条路本身就走不通——这时候非托管型号反而是唯一合理的选择，因为你的 SM 本来就不在交换机里。
这三条推论合起来给出一条反直觉但很重要的结论：非托管交换机不是"低配版"，在大规模 fabric 里它是"更匹配的版本"。托管能力是为"SM 在这里"服务的；当 SM 明确不在交换机里时，为它付出的 CPU 与管理口就变成了纯粹的冗余成本。第十节的决策树会把这一点落到具体选择上。
本节关键记忆：2 类设备 + 1 个正交维度 + 1 条解耦原则
- 2 类设备：托管（固件 + CPU + MLNX-OS + 管理口，可带内也可带外，可挂内嵌 SM）/ 非托管（仅固件，仅带内，无 SM 能力）
- 1 个正交维度：带内管理与托管状态无关——所有交换机都被带内管理，只有部分有带外管理
- 1 个默认值陷阱：内嵌 SM 默认关闭（disabled by default），"托管"不等于"在跑 SM"
- 1 条解耦原则：SM 角色与设备托管形态应当解耦——只在少数设备上启用内嵌 SM，其余用非托管型号
三、选型的第一个维度：fabric 规模
What — 课程点名的"主要考量"与其依据
课程明确指认了一个主要考量（one major consideration）：fabric 的规模，换句话说，SM 被期望管理的节点数量（the fabric scale or, in other words, the number of nodes the subnet manager is expected to manage）。
课程的论证是：由于 InfiniBand fabric 的规模可能扩展到数百乃至数千个受管节点，因此需要能支撑高乃至超大规模 fabric 的 SM 方案。这条推理直接导致了三种形态的能力分层：小到中型用交换机内嵌，大型用服务器 OpenSM，超大规模与集中管控用 UFM。
规模上限的准确数字，以及它是怎么来的
课程给出的数字是：MLNX-OS 上内嵌的子网管理器可管理最多 2048 个节点的 fabric，这是 x86 架构交换机的 CPU 限制所致（the embedded subnet manager on the mln x os can be used to manage fabrics of up to two thousand forty eight notes. this is due to the CPU limitation for x eighty six base switches as a result）。
这个数字有两处必须注意的细节。
- 其一：2048 是"节点"不是"交换机"。课程说的是 nodes，NVIDIA 文档的表述同样是 manage fabrics up to 2048 nodes on x86 based systems。也就是说被计数的是 HCA 侧的节点，交换机数量远小于 2048。这个区别在接近上限时很关键——如果你的 fabric 有 500 台交换机接 3000 块 HCA，限制先被 HCA 数量触发。
- 其二：限制来自 CPU，不是内存也不是转发表容量。课程把这归因于 x86 架构交换机的 CPU 能力。交换机转发表本身不是瓶颈——NVIDIA 规格表中 QM8700 的线性转发表为 4 × 48K 条目。真正做决定的是那颗 CPU 要在多长的墙钟时间内完成拓扑发现、LID 分配与全网路径计算。这解释了为什么这个上限与节点数近似线性相关：计算量随节点数增长，而 CPU 是固定的。
课程紧接着给出的适配结论是：这一形态适合中小规模 fabric。而它的代价是：交换机内嵌的子网管理器不支持自适应路由、Dragonfly+ 路由引擎等增强特性。这条能力边界会在第四节展开。
先把 SM 在初始化阶段要做的工作列清楚。依据本系列第八篇的六阶段流程，一个 Master SM 在一次 Heavy Sweep 中要完成：发现全部节点与端口（拓扑发现）→ 为每个节点分配 LID → 对每一对源宿计算路径（路径计算）→ 把结果逐台写进交换机的线性转发表（LFT）→ 推进子网激活。
这五步里，只有第二步和第四步的规模效应是"存储型"的。LID 分配要存 N 个 LID，线性转发表要存 × N 条表项——这两项的增长可以用存储容量线性外推，交换机的 ASIC 侧为此准备了专用的表项结构。规格表里 4 × 48K 条目的线性转发表，其量级远超一个 2048 节点 fabric 所需的表项数。
真正非线性增长的是第三步与第四步的执行过程。路径计算在 SM 主机侧完成，它的复杂度随交换机数量与节点数的组合增长；而把这张表写进每一台交换机，则是一个按设备数与表项数相乘的 SMP 事务序列。这些工作的瓶颈在 CPU 的算力与事务吞吐，不在 ASIC 的表项深度。
把这个结论与运维体验对上，就解释了 2048 这个数字的实际含义：它是一个时间约束下的规模上限，不是一个存储约束下的容量上限。换句话说，你不是"装不下"那么多节点，你是"算不完"那么多节点。后者有一个重要后果：节点数的增加会拉长重收敛时间——而重收敛时间正是第九篇讲的、故障后决定"网络多久恢复可用"的那个指标。规模逼近上限时，故障切换的恢复窗口也会同步变长。
最后给出一条容易被忽略的推论：规模上限不可通过加内存绕过。因为限制在算力与事务吞吐上，而交换机内嵌 SM 运行在与转发平面分离的那颗通用 x86 CPU 上，其算力由硬件型号固定。要提升规模能力，只有换宿主这一条路——这正是"形态一"与"形态二"分界的根本原因。第六节到第八节讲的三种配置方法，本质上就是三种不同的宿主方案。
本节关键记忆：1 个主要考量 + 1 个准确数字 + 2 条数字细节
- 1 个主要考量：fabric 规模 = SM 被期望管理的节点数量（课程点名的 one major consideration）
- 1 个准确数字：MLNX-OS 内嵌 SM 支持 最多 2048 个节点的 fabric，课程归因于 x86 架构交换机的 CPU 限制；适配中小规模 fabric
- 细节一：2048 数的是节点（HCA），不是交换机数——交换机数量远小于 2048
- 细节二：限制在 CPU 算力与 SMP 事务吞吐，不是转发表容量（QM8700 为 4 × 48K 条目，远超所需）
- 1 个连带后果：规模逼近上限时 重收敛时间同步变长，因为它与同一套计算工作是同一个瓶颈
四、选型的第二个维度：能力边界（规模与特性）
What — 基础方案与高级方案的职责分界
课程把 SM 能力分成两层。基础（basic）SM 的期望是：初始化 fabric、计算转发表、配置节点、监控变化。高级（advanced）方案则提供诸如自适应路由、Dragonfly+ 路由引擎等增强功能，可能显著提升性能。
课程随即给出选型规则：如果计划部署这些增强特性，就必须确认所选的 SM 方案支持它们。这句话看起来平淡，但它的实际后果是"能力边界比规模更早触发选型收敛"——一个 100 节点的 fabric 如果要用 Dragonfly+，无论它多小，都不能用交换机内嵌 SM。
交换机内嵌 SM 的能力边界，NVIDIA 文档有三行明确列表，本篇逐条对照
MLNX-OS 文档在 Subnet Manager 一节下写明了两条限制，这两条必须原样记住，因为它们直接否定了转写稿里的错误表述：
- 限制一（拓扑）：通过 MLNX-OS 运行的子网管理器不支持 Dragonfly+ 拓扑，也不支持 Fat-Tree 与 Dragonfly+ 的组合拓扑（Subnet manager running via MLNX-OS does not support Dragonfly+ topology or combination of Fat-Tree and Dragonfly+ topologies）。
- 限制二（功能）：通过 MLNX-OS 运行的子网管理器不支持自适应路由、故障路由（即 SHIELD 或 FRN）、拥塞控制、SHIELD 与 SHARP（does not support adaptive routing, fault routing (i.e., SHIELD or FRN), congestion control, SHIELD, and SHARP）。
课程的口头表述与这两条是一致的：课程说内嵌 SM 不支持自适应路由与 Dragonfly+ 路由引擎这类增强特性，并且因为 SM 内嵌在 MLNX-OS 中，不需要额外许可。真正错的是转写稿把这段能力描述同时套到了服务器侧的 OpenSM 上——课程原文明确说的是 DOA OFED 栈内嵌的 OpenSM 支持自适应路由与 Dragonfly+ 路由引擎，与内嵌 MLNX-OS 的 SM 是两回事。
另有一条容易漏掉的相关事实，来自 OpenSM 侧：OpenSM 的自适应路由支持是通过把路由引擎设为 AR 系列引擎来激活的。仅启用自适应路由管理器而路由引擎仍是非 AR 引擎，AR 不会生效。这一条在第十一篇讲路由引擎时已涉及，此处只作为"能力边界不只是开关、还需要配套"的一个例证。
| 能力 | 交换机内嵌 SM（MLNX-OS） | 服务器 OpenSM（MLNX OFED） | UFM（Enterprise 级及以上） |
|---|---|---|---|
| 管理规模 | 最多 2048 节点（x86 CPU 限制） | 面向数百节点的常规用法；更大规模需评估 | 面向大规模与超大规模，UFM 平台定位即为 scale out |
| 自适应路由 | 不支持 | 支持（需配 AR 引擎） | 支持 |
| Dragonfly+ / dfp / dfp2 | 不支持，含 Fat Tree 混合拓扑 | 支持 | 支持 |
| 拥塞控制 / SHIELD / FRN | 不支持 | 随 OFED 版本与路由引擎而定 | 支持（拥塞发现为 Enterprise 能力） |
| 集中遥测 / 拥塞发现 | 无（无此功能层级） | 无（无此功能层级） | 支持（Telemetry 起 / Enterprise 完整） |
| 额外许可 | 不需要（内嵌于 MLNX-OS） | 不需要（MLNX OFED 免费提供） | 需要，按受管设备计费 |
读表提醒：这张表最有用的一列是第三列，不是能力列。
很多人做选型时盯着"支持/不支持"，却漏看了一件更基础的事：这些能力在交换机内嵌 SM 那里不是"没开"，而是"不存在"。NVIDA 文档的措辞是 does not support，而不是"默认关闭但可以打开"。区别在实操上非常关键："没开"意味着有个开关可以找，"不存在"意味着你必须换宿主。文档同一页里 ib sm 命令族里也确实没有自适应路由与 Dragonfly+ 相关的任何配置项——这是可以交叉验证的证据。
先把两类判据的性质区分清楚。规模是一个连续量：你可以把它换算成一个阈值，落在阈值左侧选 A、右侧选 B。而能力边界是离散的存在性判断：要么支持，要么不支持，没有中间地带，也无法用参数调节到"部分支持"。
这个性质差异导致了一个反直觉的结论：在真实项目里，能力维度通常比规模维度更早决定形态。原因很直接——规模是渐变的，会在项目推进中缓慢逼近阈值；而能力需求往往在项目早期就被拓扑设计一次性锁定。一旦你在拓扑设计阶段确定了"用 Dragonfly+ 架构"或"必须开自适应路由"，规模是多少就已经无关紧要了：交换机内嵌 SM 这条路直接被排除。
反过来看，能力维度全部落在服务器侧与 UFM 侧之后，形态收敛就变成了规模与成本的比较。此时 QM8700 与 QM8790 的差别就不再是"选哪个型号"，而是"交换机需不需要 CPU"——而这个答案在 SM 不在交换机里的时候是明确的：不需要。第二节的解耦原则在这里得到第二次应用。
还有一层容易被忽略的连带影响：能力边界会改变"SM 宿主"的可靠性含义。自适应路由与拥塞控制都不是纯软件侧的功能——它们的执行主体是交换机转发面的端口组与散列逻辑，而这些逻辑需要被 SM 用私有 SMP 属性编程。一个不支持这些能力的 SM，即使硬件有能力，也编程不了。这就把"形态"与"交换机是否支持对应硬件特性"绑定在了一起：选了内嵌 SM，就等于放弃了整个 fabric 的自适应路由能力，交换机买了再好的 ASIC 也用不上。
把三节合起来，本篇的选型逻辑可以压缩成一条判断顺序：
- 第一问：拓扑要不要 Dragonfly+ 或自适应路由？要 → 排除交换机内嵌 SM，进入形态二与形态三的比较。
- 第二问（仅当第一问为否）：节点数是否在 2048 以内？是 → 交换机内嵌 SM 可用；否 → 同样排除。
- 第三问：在剩余的形态二与形态三之间，按节点数与运维需求比成本与集中管控能力。
这个顺序的价值在于：它把"必须先排除的那一个"放在最前面，避免了"先按规模选了内嵌 SM、然后才发现拓扑要 Dragonfly+"这种返工。而返工的代价在本系列第九篇的框架下极高——改 SM 宿主意味着全网重收敛。
本节关键记忆：1 个职责分界 + 2 条文档限制 + 1 个判断顺序
- 1 个职责分界：基础（初始化 / 算表 / 配节点 / 监控）vs 增强（自适应路由、Dragonfly+，可能显著提升性能）
- 限制一（拓扑）：内嵌 SM 不支持 Dragonfly+ 拓扑，也不支持 Fat Tree 与 Dragonfly+ 的组合拓扑
- 限制二（功能）：内嵌 SM 不支持自适应路由、故障路由（SHIELD / FRN）、拥塞控制、SHIELD、SHARP
- 1 个措辞要点：是 does not support（不存在），不是"默认关闭"——所以换宿主是唯一出路
- 1 个判断顺序：先看能力（排除内嵌 SM）→ 再看规模（再看 2048）→ 最后比成本
- 1 处转写纠正：增强特性的支持是 DOA OFED 侧 OpenSM 的能力，不是 MLNX-OS 内嵌 SM 的能力
五、选型的第三个维度：成本与许可
What — 课程提出的第三个考量，以及它对三种形态给出的答案
课程的第三个考量非常直接：所选择的 SM 方案的成本是多少，是否需要特殊许可（what is the cost of the subnet manager solution you choose. is there a need for a special license）。
课程对三种形态分别给出了答案，这三条构成了本节的核心事实：
- 形态一（交换机内嵌）：因为 SM 内嵌在 MLNX-OS 中，不需要额外许可（since the subnet manager is embedded in mln x os, no additional licensing is required）。
- 形态二（服务器 OpenSM）：因为 MLNX OFED 是免费提供的，不需要许可（since mln XO fed is offered for free no licensing is required）。
- 形态三（UFM）：UFM 按受管设备计费，依据 UFM 许可协议（ufm is licensed per managed device according to the ufm license agreement）。
把三条并排，得到一个非常清晰的成本结构：前两种形态的 SM 软件成本为零，第三种按节点数线性增长。
UFM 许可模型的准确细节，文档有几处值得单独拎出来
- 计费单位是可累加的。UFM Enterprise 手册写明：UFM 许可按受管节点计费且可累加——如果你为 10 个受管 HCA 装了一个许可，又为 15 个装了另一个，UFM 的许可上限就是 25 个受管 HCA。这意味着许可数量与 fabric 实际节点数之间不存在浪费，也不可能不足，它是精确匹配而非向上取整。
- 许可是安装与运行的前置条件。手册明确：有效的 UFM 许可既是安装也是运行的前置条件。这与"没许可只是功能受限"有本质区别——没有许可，UFM 平台本身就跑不起来。
- 许可对象随版本表述略有差异，核对时以你所用的手册版本为准。UFM Enterprise 软件手册 6.21.2 版本的表述是 按受管 HCA 计费，而 6.20.1.1 版本与 UFM Enterprise Appliance 软件手册的表述是 按受管节点（node）计费；厂商规格表中 Managed Switching Devices 的定义是 fabric 交换机、网关与路由器。三种表述指向的计数对象不完全相同，采购前必须以你手上那份手册的原文为准，本篇不替厂商统一口径。
另一个成本项容易被漏掉：UFM 本身需要一台宿主。UFM 手册指出 UFM Server 软件应安装在中央管理节点上，并建议使用专用服务器以获得最佳性能、避免与其他应用争抢资源。也就是说"选了 UFM"这个决策实际上包含了三笔成本：软件许可 + 一台专用服务器 + 相应的运维人力，而前两种形态不需要额外采购服务器（形态二复用的就是跑 OFED 的那台机器）。
先把课程给的答案放在一边，因为它回答的是"许可"这一个问题，而选型要面对的是"总成本"。课程的三条结论——内嵌无需许可、OFED 免费、UFM 按设备计费——在"软件许可"这一项上是准确且完整的。但如果只按这一项做决策，会在两个方向上出错。
第一个出错方向：低估形态一与形态二的真实成本。
- 形态一的隐含成本在交换机 SKU 上。托管交换机有 CPU、存储、管理口，单价高于同规格的非托管型号。而前面已经论证过，如果你的 SM 本来就不在交换机里，这些硬件就是纯冗余。所以"内嵌 SM 免费"这句话只在"你确实要用它、且交换机数量不多"时成立；在"交换机很多、SM 在别处"的场景里，托管型号相对非托管型号的差价乘以设备数，是一笔实打实的支出。
- 形态二的隐含成本在宿主机的可靠性上。OpenSM 免费，但它要跑在一台 24 × 7 的服务器上，而这台服务器本身需要电源、散热、网络冗余。SM 宿主机的可用性直接决定了 fabric 控制平面的可用性——第十一节会展开这条风险。
第二个出错方向：低估形态三的总成本。许可按节点数增长意味着fabric 每次扩容都要追加许可，这是一个随时间线性增长的运维支出项，而不是一次性投入。同时 UFM 平台还要求一台专用服务器（否则性能与隔离度都会受影响），并且需要人来运维这套平台。而前两种形态的"运维"是搭便车的——MLNX-OS 的管理你已经要做了，OpenSM 所在的 OFED 环境你也要维护。
把这三笔成本放到同一个口径下，TCO 的比较结构是这样的：
- 形态一：软件许可 0 + 交换机 SKU 差价（每台设备）× 设备数 + 既有 MLNX-OS 运维
- 形态二：软件许可 0 + 一台宿主机（若已有则摊薄为 0）+ 既有 Linux/OFED 运维 + 宿主机冗余成本
- 形态三：许可（按节点，随扩容增长） + 一台专用服务器 + UFM 平台自身的运维 + 换来 Telemetry / Enterprise / Cyber-AI 三层能力
这个结构给出一条实用的判断线：形态二的隐含成本主要是风险成本（宿主机单点），形态三的隐含成本主要是货币成本（按节点增长的许可）。如果你所在组织的采购流程对后者更敏感，形态二在成本维度上会显得更优；如果你需要 Telemetry 级别的集中遥测（而它无法从另外两种形态获得），形态三的成本就不是"该不该省"的问题，而是"这个能力从哪来"的问题——因为另外两种形态根本不提供它，不存在用形态二省钱的替代方案。
最后明确一条本文的边界：以上全部为结构性成本分析，不含任何价格数字。厂商定价随版本、渠道与采购量变化，本篇不给也不推测具体金额。若需精确报价，应查阅当期 UFM 许可协议与厂商报价单。
本节关键记忆：3 条许可结论 + 1 个可累加规则 + 3 类隐含成本
- 形态一：不需要额外许可（内嵌于 MLNX-OS）
- 形态二：不需要额外许可（MLNX OFED 免费提供）
- 形态三：需要许可，按受管设备计费，依据 UFM 许可协议
- 1 个规则：许可可累加——10 + 15 个 HCA 的两份许可 = 25 个 HCA 上限，精确匹配 fabric 实际节点数
- 1 条前置条件：有效许可是安装与运行的前置条件，不是"没许可功能受限"
- 3 类隐含成本：交换机 SKU 差价（形态一）/ 宿主机可靠性（形态二）/ 专用服务器 + 平台运维 + 随扩容增长的许可（形态三）
六、形态一实操：在托管交换机上启用并配置内嵌 SM
What — 课程演示的操作序列，以及它给出的三个配置点
课程先给了一句总括：MLNX-OS 操作系统内置了行业标准的 CLI，所以如果你有配置网络设备的经验，这个界面大概率会让你感到熟悉。这句话是给学习者的心理预期铺垫，不是技术事实，但它准确描述了这个界面的定位。
课程随后给出四个动作，构成完整的启用与配置流程：
- 登录：通过控制台连接或建立 SSH 连接登录交换机。
- 进入 enable 模式：输入 enable 命令切换到 enable 模式。
- 进入全局配置模式：输入 configure terminal 进入全局配置模式。
- 启用 SM 并配置：用 show ib sm 判断 SM 是否在运行；SM 默认不运行；输入 ib sm 来运行它。
课程还明确了一个默认值陷阱：子网管理器默认不运行。并且强调：启用后它默认以优先级 0 运行。
动作 1 - 3：登录并进入配置模式
console 直连，或 SSH
---------------------------------------------------------------
console# ssh admin@
Password: ********
从用户模式进入 enable 模式
---------------------------------------------------------------
switch-1133ce > enable
switch-1133ce #
从 enable 模式进入全局配置模式
---------------------------------------------------------------
switch-1133ce # configure terminal
switch-1133ce (config) #
动作 4a：先查状态 —— SM 默认不运行
---------------------------------------------------------------
switch-1133ce (config) # show ib sm
此时输出中不会有运行中的 SM 实体。
原因：MLNX-OS 的子网管理器默认是 disabled 的。
动作 4b：启用 SM
---------------------------------------------------------------
switch-1133ce (config) # ib sm
switch-1133ce (config) #
再次查询，输出中出现 Enabled
---------------------------------------------------------------
switch-1133ce (config) # show ib sm
...
Enabled : Yes
...
ib sm 的 no 形式关闭本节点上的 SM：
switch-1133ce (config) # no ib sm
关键默认值（必须记住）
---------------------------------------------------------------
SM 默认不运行 disabled by default
启用后默认优先级 0 （0 最低，15 最高）优先级这一段是课程强调的重心，也是最容易配错的地方
课程明确提醒：启用后 SM 默认以子网管理器优先级 0 运行，并给出建议：建议把子网管理器优先级改成一个更高的值，不要依赖最低 GUID 作为优先级相等时的仲裁手段（it's recommended to change the subnet manager priority to a higher value and not rely on the lowest goo eyed used as the tiebreaker if priorities are equal）。
课程说"范围是 1 到 15"，这里需要按文档精确化：MLNX-OS 文档给出的取值范围是 0-15，其中 0 表示最不重要、15 表示最重要，默认值是 0。课程的"1 到 15"是建议的取值区间，不是参数的合法范围——0 是合法的，只是表示"最低优先级"这个语义。这个区别在写配置规范时很重要：不要把 ib sm sm-priority 0 当成非法值去排查。
课程同时点出了仲裁规则的完整表述，文档原文是：如果两个或更多活动 SM 拥有相同的最高优先级，则端口 GUID 最低的那个管理 fabric（If two or more active SMs have the same highest priority, the one with the lowest port GUID manages the fabric）。
课程说"不要依赖 GUID 仲裁"，这句话需要准确理解它的含义。它不是说 GUID 仲裁不可靠——那个规则是确定性的、可预测的。它真正的问题是：一旦你依赖 GUID 仲裁，就等于放弃了主动控制权。多台交换机启用内嵌 SM 且优先级相同时，哪一台成为 Master 由它们的端口 GUID 数值大小决定，而不是由你决定。把优先级设成不同值，等于把这件事从"取决于硬件 GUID"变成"取决于你的配置"。这是可运维性与可预测性的差别。
配置点一：SM 优先级
从全局配置模式设置
---------------------------------------------------------------
switch-1133ce (config) # ib sm sm-priority
switch-1133ce (config) # ib sm sm-priority 15
文档口径
取值范围 0-15
0 最不重要（least important）
15 最重要（most important）
默认值 0
文档示例 ib sm sm-priority 1
验证
---------------------------------------------------------------
switch-1133ce (config) # show ib sm sm-priority
SM priority : 15
仲裁规则（文档原文）
---------------------------------------------------------------
If two or more active SMs have the same highest priority,
the one with the lowest port GUID manages the fabric.
课程建议：不要依赖这条 GUID 仲裁
理由：依赖它 = 放弃主动控制权
做法：给每台候选交换机设不同的优先级
配套命令：HA SM 节点管理
---------------------------------------------------------------
switch-1133ce (config) # ib smnode create
switch-1133ce (config) # ib smnode enable
switch-1133ce (config) # ib smnode sm-priority
验证：
show ib smnode
show ib smnodes
示出的 ha-role 取值：offline / unknown / master /
standby / disabled
示出的 ha-state 取值：offline / init / searching /
joining / online / creating /
waiting / leaving / join-sync /
failed / removed / regroup课程留了一个"用问号探索"的技巧，这是本节最实用的一条技巧
课程说：要探索所支持的 SM 设置，使用 ib sm 命令加上问号。这实际上是网络设备 CLI 的通用自省机制，它的价值在于：不查文档也能发现当前固件版本实际支持哪些参数。
课程随后用这个机制枚举出了三类可配置项，这三类恰好是内嵌 SM 的全部能力面：
- （a）新当选的 Master SM 是否重新分配 LID——对应 ib sm reassign-lids。文档说明：启用后 SM "可以"（但不要求）重新分配已配置有效 LID 的节点上的 LID；禁用后 SM 不会重新分配。文档还给出了禁用它的典型理由：某些情况下 SM 必须重新分配 LID，fabric 才能达到稳定状态，或者某个 fabric 选项（如 LMC）才能被完全应用。
- （b）运行哪个路由引擎——对应 ib sm routing-engines，下一小节展开。
- （c）执行 light sweep 的间隔——对应 ib sm sweep-interval。文档给出的取值范围是 0 到 36000 秒，0 表示禁用周期扫描，默认值是 10 秒。
6.1 配置点二：路由引擎（课程的重点强调项）
What — 课程对默认引擎的判断与改动建议
课程在这里给出了本节最重要的一条操作建议：子网管理器默认运行的路由引擎是 minhop，强烈建议改为支持避免信用环的路由引擎，比如 up/down（the default routing engine run by the subnet manager is minhop and it's strongly recommended to change to a routing engine that supports credit loops avoidance like up down）。
这条建议与本系列第十一篇的结论完全一致：Min Hop 是默认引擎、且不阻止信用环；Up/Down 具备死锁免疫。课程在这里把它作为一条操作建议给出，第十一篇把它作为选型判据展开。两篇合起来构成"为什么"与"怎么做"的完整链条。
课程随后给出配置方法：运行 ib sm routing-engines 后跟问号，可以看到子网管理器能运行哪些路由引擎；选择你希望它运行的引擎并回车。
配置点二：路由引擎
先用问号查看本机固件支持的引擎名
---------------------------------------------------------------
switch-1133ce (config) # ib sm routing-engines ?
dor Includes "dor" engine
file Includes "file" engine
ftree Includes "ftree" engine
lash Includes "lash" engine
minhop Includes "minhop" engine
none No routing engines specified; use SM default(s)
updn Includes "up/down" engine
ar-updn Includes "adaptive routing up/down" engine
选择引擎并回车
---------------------------------------------------------------
switch-1133ce (config) # ib sm routing-engines updn
switch-1133ce (config) # ib sm routing-engines minhop updn
文档要点
多个引擎可用空格分隔，按列出顺序依次尝试，
前面的失败后尝试后面的。
no 形式把引擎设为 "none"，即使用 SM 默认引擎。
历史：3.10.4000 起新增 ar-updn
验证：show ib sm routing-engines
与本系列第十一篇的对应关系
---------------------------------------------------------------
minhop 第十一节：不阻止信用环，是默认引擎
updn 第五节：丢弃"先降后升"的路径，死锁免疫
ftree 第七节：沿用 UPDN 剪枝 + 端口序位出口均衡
dor 第八节：DOR，面向 2D/3D 环面
lash 第十一节清单中的 Lash 引擎
内嵌 SM 不支持自适应路由，因此 ar-updn 这一项
虽然在本机命令表中可见，但其能力边界见第四节。
配置点三：扫描间隔（light sweep）
---------------------------------------------------------------
switch-1133ce (config) # ib sm sweep-interval
switch-1133ce (config) # ib sm sweep-interval 20
文档要点
取值范围 0 到 36000 秒；0 = 禁用周期扫描
默认值 10 秒
no 形式 禁用周期扫描
验证 show ib sm sweep-interval把这一节的四个配置点与第九篇的框架对齐，看清它们各自影响什么
- ib sm（启用）：影响的是"这台设备是否参与 Master SM 选举"。启用只是让它成为候选者，不代表它立刻就是 Master——这一点第九篇讲得很清楚。
- ib sm sm-priority（优先级）：影响的是"选举时谁的权重更高"。改优先级不触发重收敛，它只在下次选举时起作用。
- ib sm routing-engines（路由引擎）：影响的是"路径计算用什么算法"。改这一项会触发全网转发表重算——按第十一篇的分类，这是一次完整的 Heavy Sweep，属于破坏性变更。
- ib sm sweep-interval（扫描间隔）：影响的是"多久做一次轻量扫描"。调小会让拓扑变更被发现得更及时，代价是 SMP 流量与 SM CPU 占用上升。
这四类变更的代价差异极大，是本节最需要记住的区分：启用与调优先级是"配置变更"，改路由引擎是"全网级变更"。课程把两者放在同一段里讲，但它们的运维风险完全不在一个量级。
本节关键记忆：4 个动作 + 4 个配置点 + 2 个精确化纠正
- 4 个动作：登录（console/SSH）→ enable → configure terminal → ib sm
- 配置点：ib sm sm-priority 0-15 / ib sm routing-engines / ib sm sweep-interval 0-36000 / ib sm reassign-lids
- 默认值：SM 默认不运行；启用后默认优先级 0；sweep-interval 默认 10 秒
- 纠正一：优先级的合法范围是 0-15，不是 1-15——0 合法，语义为"最低优先级"
- 纠正二：reassign-lids 的默认值是 启用，且禁用它的典型原因是 LMC 之类的 fabric 选项需要被完全应用
- 1 条仲裁规则：优先级相同则端口 GUID 最低者为 Master；课程不建议依赖它
- 1 条实战建议：默认引擎 minhop，建议改为 updn 以避免信用环
七、形态二实操：在服务器上运行 OpenSM
What — 课程对形态二适用性的判断
课程的判断非常直接：对于更大的 fabric，需要更具可扩展性的 SM 方案。一个选项是在安装了 NVIDIA DOA OFED 栈的服务器上运行 OpenSM。课程明确指出：DOA OFED 栈包含一个符合 InfiniBand 规范的子网管理器，名为 OpenSM。
课程还给了一句关于默认值的重要说明：OpenSM 的默认设置是为最多几百个节点的集群这一常见场景设计的（open SM defaults were designed to meet the common case usage on clusters with up to a few hundred notes）。这句话给出的是"默认值面向的规模"，不是"上限"——本篇不把它解读为容量上限。
而形态二的核心优势，课程是明确表扬的：嵌入 DOA OFED 的 SM 支持自适应路由与 Dragonfly+ 路由引擎这类增强特性，可提供更高的规模与弹性；由于 MLNX OFED 是免费提供的，因此不需要许可。
关于"DOCA OFED"这个栈名，需要按厂商现行命名做一次澄清
课程口语说的是 "DOA OFED"。NVIDIA 面向数据中心的 OFED 发行版现行名称是 DOCA（此处指 Data Center Optimized Networking 的软件栈）配合 OFED 的组合，业内通行的写法是 DOCA OFED；而面向 HPC 与 InfiniBand 的经典名称是 MLNX OFED。本文统一使用 MLNX OFED，因为它与本系列第十一篇引用的 MLNX SM Release Notes 属于同一套命名体系；读者在自己的环境中看到的名字可能不同，但要认准"它提供的组件叫 OpenSM"这一点。
课程说 OpenSM 的默认设置是为最多几百个节点的集群这一常见场景设计的。这句话给出的是"默认值面向的规模"，不是"上限"——本篇不把它解读为容量上限。
另一处需要精确化的是 OpenSM 的版本号。课程说 opensm -c 命令会输出 OpenSM 版本号，本例中是 5.11.0。NVIDIA 侧对应的发布说明标题正是 MLNX SM Release Notes 5.11.0。这个版本号在实践中很重要，因为不同版本的默认路由引擎不同，见本节末尾的版本历史说明。
7.1 启动 OpenSM：前台、后台与状态查询
What — 课程给出的三种运行方式，以及它们各自的用途
课程给出三种方式，它们的区别是"前台还是后台"以及"是否由服务管理器托管"：
- （a）前台运行（默认模式）：要以默认模式运行 OpenSM，只需输入 opensm。此时 OpenSM 占用当前终端，日志直接输出到屏幕。这是初次部署与排障时最有用的模式——因为所有错误都直接可见。
- （b）查看全部选项：OpenSM 也可以带 --help 或 -h 运行，以获得完整的选项列表。
- （c）作为守护进程运行：要以此模式运行 OpenSM，输入 /etc/init.d/opensm start。这是生产环境的正确方式，因为它由服务管理器托管，开机自启、崩溃可重启。
- （d）查看状态：要检查 OpenSM 状态，使用 /etc/init.d/opensm status。
课程特别指出了状态输出中的一个关键信息：Standby。课程说：从输出中可以看到正在运行的子网管理器是一个 standby 子网管理器。这需要结合第九篇理解——OpenSM 启动后会先作为候选者加入，如果已有 Master 在运行，它就处于 standby 状态。看到 Standby 不代表出错，它说明选举机制正常工作。
(a) 前台运行 —— 初次部署与排障用
---------------------------------------------------------------
# opensm
占用当前终端，日志直接打到屏幕。
所有错误、告警、选举过程都可见。
Ctrl-C 结束。
(b) 查看完整选项
---------------------------------------------------------------
# opensm --help
# opensm -h
(c) 作为守护进程运行 —— 生产环境
---------------------------------------------------------------
# /etc/init.d/opensm start
Starting IB Subnet Manager. . . . . . . . . . .done
(d) 查看状态
---------------------------------------------------------------
# /etc/init.d/opensm status
opensm (pid 12345) is running...
进阶查询：区分 Master 与 Standby
---------------------------------------------------------------
# smpquery --list （或 smpdump / opensm-ctl）
列出 fabric 中的 SM 实体及其角色
课程指出的现象：状态输出显示运行的是 standby SM。
这不是故障 —— 说明已有 Master，本实例作为候选者待命。
选举机制见本系列第九篇。
systemd 发行版上的等价形式
---------------------------------------------------------------
# systemctl start opensm
# systemctl status opensm
# systemctl enable opensm
Debian/Ubuntu 的 opensm.service 通过 /etc/default/opensm
的 PORTS 变量决定在哪些端口起 SM：
PORTS=ALL 对 ibstat -p 列出的所有端口各起一个实例
PORTS=NONE 禁用 opensm
实际启动的是 opensm@.service 模板单元。
部分发行版仍使用 /etc/init.d/opensm 脚本。7.2 日志文件：两个文件，两种用途
What — 课程对两个日志文件的分工描述，以及由此推出的排障规则
课程这段讲得非常清楚，而且直接给出了一条可执行的排障原则：
- /var/log/messages：只包含通用的、重大的事件（includes only general major events）。
- /var/log/opensm.log：包含所报告错误的细节（includes details of reported errors）。
- 核心原则：所有在 opensm.log 中报告的错误，都应当被视为 InfiniBand fabric 健康状况的指标（all errors reported in open SM dot log should be treated as indicators of in fina ban fabric health）。
把这条原则与第十一篇的验证判据合起来，就能得到一条完整的排障顺序：先在 /var/log/messages 确认"子网是否建立成功"，再在 /var/log/opensm.log 逐条检查错误与引擎名。后者是本系列反复强调的——SUBNET UP 出现不代表路由引擎配置成功，两者必须分开核对。
先看两个文件的实际内容差异。/var/log/messages 记的是离散的重大事件：子网激活成功、Master SM 切换、发生 handover、某台设备被判定为故障。它的写入频率很低——一个稳定运行的 fabric 可能几天才产生几行。/var/log/opensm.log 记的是每一次扫描、每一次 MAD 交互、每一条告警。它的写入频率极高——默认扫描间隔 10 秒意味着持续有内容写入。
这个频率差异决定了两个文件不可能合并，也决定了它们的用途不可互换。如果只有 /var/log/opensm.log，那么在一次大规模重收敛期间，真正的关键事件（"子网已激活"、"Master 已切换"）会被淹没在上万行扫描日志里，运维人员实际上无法找到它。反过来，如果只有 /var/log/messages，那么导致这次重收敛的具体原因（哪条链路 down 了、哪个 Trap 触发了、哪次 MAD 超时）就完全不可见。
更重要的是，两者的写入路径与可靠性特征不同，这决定了它们在故障时的可用性也不同。/var/log/messages 由系统的日志守护进程管理，它的写入不依赖 OpenSM 进程本身是否还活着——这意味着在 OpenSM 已经崩溃或卡死的现场，/var/log/messages 里仍可能留下最后几条记录。而 /var/log/opensm.log 由 OpenSM 自己打开并追加，进程异常终止时缓冲区里的内容可能丢失。
把这条差异落到一条排障规则上，就得到了本节最有价值的一条推论：
- 现场第一动作：先抢救 /var/log/opensm.log，因为它是 OpenSM 自己写的，进程一旦挂掉，未刷盘的内容就永久丢失了。
- 第二动作：再看 /var/log/messages，确认子网是否成功激活、Master 身份是否发生过变化。
- 第三动作：把 /var/log/opensm.log 里出现的每一条 ERROR 逐条当作 fabric 健康指标对待
最后要把课程那条"所有错误都应被视为健康指标"的原则说透它的分量。这句话的实践含义是：不要把 opensm.log 里的 ERROR 当成可以忽略的历史噪声。在一次成功的重收敛过程中，日志里完全可能出现若干条 ERROR——它们记录的是"重收敛之前 fabric 曾经不正常"这个事实。如果 fabric 看起来是好的就把这些 ERROR 清掉或忽略掉，你就丢掉了唯一一份记录"什么地方曾经出过问题"的历史。这也解释了为什么本系列的排障方法反复强调"看日志"而不是"看状态"——状态只告诉你现在，日志告诉你它怎么变成现在这样。
7.3 配置文件：位置、生成时机与版本输出
What — 课程对配置文件位置与生成方式的描述
课程给出了三个事实，每一个都有可核对的具体值：
- （a）内容范围：OpenSM 配置文件包含子网管理参数。第十一篇已经说明，路由引擎也在这个文件里配置。
- （b）默认位置：安装 DOA OFED 时，默认位置是 /etc/opensm/opensm.conf。
- （c）生成时机：该文件在 OpenSM 首次运行时以默认设置被创建；如果希望在运行 OpenSM 之前配置设置，可以用 opensm -c 命令加上文件位置来创建它。
课程随后指出了一个必须注意的行为：opensm -c 命令会输出 OpenSM 的版本号，本例中为 5.11.0。课程强调这一点很重要，因为版本号决定了 OpenSM 支持哪些特性，具体来说，它决定了默认运行哪个路由引擎。
(c) 配置文件：位置与生成
默认位置（安装 OFED 时创建）
---------------------------------------------------------------
/etc/opensm/opensm.conf
在首次运行 opensm 时以默认设置自动创建。
想在首次运行前就写好配置：显式生成
---------------------------------------------------------------
# opensm -c /etc/opensm/opensm.conf
-c 的完整选项名是 --create-config <file_name>
该命令会输出 OpenSM 版本号，例如：
opensm: OpenSM version 5.11.0
加载指定配置文件的选项是 -F / --config <file_name>
不指定 -F 时，使用 /etc/opensm/opensm.conf（若存在）
同目录下的其他默认文件（opensm(8) 手册）
---------------------------------------------------------------
/etc/opensm/opensm.conf 7.4 路由引擎的配置，以及一个必须知道的版本变更
本节是全篇唯一一处需要引入版本历史的配置项，原因是默认值在不同版本间变过
课程明确指出：多个路由引擎可以指定，用逗号分隔，这样如果靠前的路由引擎失败，会按特定顺序尝试后续的路由算法；如果 OpenSM 无法执行所配置的路由引擎，OpenSM 会回退到 minhop 路由引擎。这一段与第十一篇讲的 -R 选项行为完全一致，不重复展开。
课程随后给出的版本变更，是本节最有价值的一条事实：
请注意，从 OpenSM 5.10（2021 年 11 月发布）起，默认路由引擎从 minhop 改成了 updn，并带上了自适应路由（please note that starting open SM five point ten November twenty twenty one release the default routing engine was changed from minho BB to up down with adaptive routing）。
这条事实必须按厂商发布说明精确化，因为它在不同文档体系里有两种表述，而这两种表述不是同一件事：
- 社区版 OpenSM 的表述：opensm(8) man page 长期写作 "instead of Min Hop algorithm (default)"，即社区版 OpenSM 的默认引擎是 minhop。这与第十一篇的引用一致。
- NVIDIA 侧 MLNX SM 的表述：MLNX SM Release Notes 5.10 的变更新历史中写的是 "Changed the default routing engine to be ar_updn instead of minhop"，且 routing_engine 的默认值变更为 ar_updn。5.11 的变更新历史中则记录了"为 UPDN 与 ar_updn 路由引擎新增了根检测算法"。
把两条并列，得到的准确结论是：默认路由引擎是哪一个，取决于你用的是哪一套 OpenSM。
- 用社区版 / 发行版自带的 opensm：默认 minhop（不防信用环）→ 因此第六节那条"建议改为 updn"的建议对你是必要的。
- 用 NVIDIA MLNX SM（5.10 及以后）：默认 ar_updn（Up/Down + 自适应路由）→ 已经具备死锁免疫与 AR。此时"确认实际生效的引擎名"就变成了一条纯粹的核对动作，而不是一个必须修改的动作。
无论哪一种，第十一篇那条验证判据都同样适用：routing_engine 只是"你希望用什么"，日志里 <engine> tables configured on all switches 的前半段才是"实际生效了什么"。这两者在任何版本下都可能不一致。
先把问题的性质说清楚。routing_engine 这个配置项名、opensm.conf 这个文件名、/var/log/opensm.log 这个日志路径，在社区版与 NVIDIA 版之间是完全相同的。这正是它容易误导人的地方——你看到的是同一个名字，却在读两套不同的默认值。
这种"同名不同默认值"的情况，是配置类文档里最难排查的一类问题。因为它不会报错、不会告警、不会在日志里留下痕迹。一台用社区版 OpenSM 的机器和一台用 MLNX SM 的机器，opensm.conf 里可能都没有 routing_engine 这一行，但一个跑 minhop，另一个跑 ar_updn。而 minhop 与 ar_updn 在死锁免疫性上的差别，是本系列第十一篇全部讨论的核心。
把这个差别落到可操作的动作上，结论只有一条：不要依赖默认值，要显式配置并显式验证。
- 显式配置：routing_engine 这一行无论你用的是哪套 OpenSM，都应该手写进 opensm.conf。依赖默认值的配置等于没有配置——因为默认值会随版本、随发行版、随打包方式变化，而你的配置文件不会。
- 显式验证：opensm -c 会输出版本号，这一步应该在部署的第一步做，因为它决定了后续所有配置讨论的前提。在不知道版本的情况下讨论"默认引擎是什么"，这个问题本身就没有确定答案。
- 显式留证：把 opensm -c 输出的版本号记进部署文档。这是本文推荐的一条实践，理由是下一次升级之后默认值可能再变一次，而那时你已经不记得当初装的是哪个版本。
最后补一句关于"静默回退"的机制性提醒，它是本节的延伸。课程说了"如果 OpenSM 无法执行所配置的路由引擎，会回退到 minhop"。把这条与第十一篇的兜底规则合起来：回退发生时，日志里出现的是一行 INFO 级别的 minhop tables configured on all switches，没有 ERROR、没有 WARN。所以"回退"这个状态在业务现象上几乎无法察觉——子网照样激活、流量照样跑、监控面板一切正常。唯一能发现它的动作，是逐字核对那行日志的前半段。这就是为什么本系列把"核对引擎名"列为一条独立的、不可省略的验证步骤。
本节关键记忆：4 种运行方式 + 2 个日志文件 + 1 个版本分支
- 运行方式：opensm（前台，日志到屏幕）/ --help / /etc/init.d/opensm start（守护）/ status（查状态）；systemd 下用 systemctl
- Standby 是正常状态：说明已有 Master，本实例作为候选者待命，不是故障
- 两个日志：/var/log/messages 记重大事件（含 SUBNET UP）/ /var/log/opensm.log 记错误细节（含 <engine> tables configured...）
- 1 条排障原则：opensm.log 里的每条 ERROR 都应视为 fabric 健康指标——不要当噪声清掉
- 配置：/etc/opensm/opensm.conf，首次运行自动创建；opensm -c <路径> 可提前生成并输出版本号
- 1 个版本分支：社区版默认 minhop；MLNX SM 5.10+ 默认 ar_updn——所以不要依赖默认值
- 1 个动作建议：无论哪套 OpenSM，都显式写 routing_engine，并逐字核对日志里的引擎名
八、形态三实操：UFM 平台与 UFM Enterprise
What — 课程对 UFM 的定位，以及三级能力划分
课程把 UFM 定位为：NVIDIA 统一 fabric 管理器（UFM）是一组基于 Web UI 的平台，用于数据中心网络管理。UFM 方案提供增强的实时网络遥测，配合 AI 赋能的 cyber intelligence 与分析能力，以支持向外扩展的 InfiniBand 数据中心。
关于 UFM 与 SM 的关系，课程给了一句关键的架构性陈述：UFM 使用 OpenSM 来发现与配置所有 InfiniBand fabric 设备，从而在 fabric 中启用流量流动。这句话把三种形态串成了一条链：UFM 不是 SM 的替代实现，它是 SM 的运行宿主加上管理界面。UFM 的子网管理器是一个集中的实体，它发现并配置所有 InfiniBand fabric 设备，以在 fabric 中启用流量流动。
关于部署形态，课程说：UFM 可以作为服务器上的服务、容器运行，或在专用硬件一体机（UFM appliance）上运行。
本节的三级能力划分，课程讲得比较压缩，这里按厂商公开的产品说明补全并对齐
课程说：UFM 平台由多个层级的解决方案与能力构成，以满足你数据中心的需要与要求。三个层级分别是：
- 基础级 — UFM Telemetry 平台：提供网络验证工具以监控网络性能与状况；采集并流式输出丰富的实时网络遥测信息、应用工作负载使用情况与系统配置，送到本地或云端数据库做进一步分析。厂商产品页的措辞与之对应：provides network validation tools to monitor network performance and conditions。
- 中级 — UFM Enterprise 平台：增加增强的网络监控与管理；自动化网络发现与网络配置下发、流量监控与拥塞发现。厂商产品页措辞：performs automated network discovery and provisioning, traffic monitoring, and congestion discovery。课程补充了这一层还支持作业调度、配置下发，以及与 Slurm 和平台负载共享设施（LSF）的集成，并支持与 OpenStack、Azure 云、VMware 的网络配置与集成。
- 增强级 — UFM Cyber-AI 平台：包含 UFM Telemetry 与 UFM Enterprise 的全部服务，为降低超级计算运维成本提供预防性维护与网络安全能力。厂商产品页措辞：providing preventive maintenance and cybersecurity for lowering supercomputing opex。
课程明确指出了本单元的教学范围：我们的重点是 UFM Enterprise 平台，而 UFM 自身的遥测与监控选项不在本次培训范围内，若对 UFM 感兴趣应去找相应的 UFM 专项培训。
另一条对部署决策直接相关的事实来自厂商产品页：UFM Enterprise 通过软件容器或专用一体机提供，而 UFM Cyber-AI 以本地部署的 UFM Cyber-AI 专用一体机形式提供。这意味着最高层级反而是形态最固定的——它不做容器或服务形态。
UFM Enterprise 作为"管理 InfiniBand 向外扩展计算环境的平台"，其定位与两种许可细节需要分开读
定位（厂商与手册口径一致）：UFM Enterprise 是一个用于管理 InfiniBand 向外扩展计算环境的强大平台；UFM 让数据中心运维人员能够高效监控与运维整个 fabric，提升应用性能并最大化 fabric 资源利用率。
许可（第五节已述，此处只补三条手册原文层面的事实）：
- 计费对象：按受管设备计费，依据 UFM 许可协议；许可可累加。
- 前置条件：有效的 UFM 许可既是安装也是运行的前置条件。
- 许可对象随版本表述不同：UFM Enterprise 软件手册 6.21.2 写作按受管 HCA，6.20.1.1 与 Appliance 版手册写作按受管节点，采购前以你所用手册的原文为准。
关于"UFM 软件由哪些组件构成"，有一条部署相关的实操事实：UFM 软件包含 Server 与 Agent 两个组件；UFM Server 软件应安装在中央管理节点上；为获得最佳性能并最小化对其他应用的影响，建议使用专用服务器运行 UFM；UFM Agent 是可选组件，应安装在 fabric 节点上。这条事实解释了 7.3 提到的专用服务器成本从哪来。
8.1 UFM 侧配置子网管理器：Settings 菜单的三层结构
What — 课程给出的操作路径，以及它与手册的对应关系
课程对 UFM 侧的操作描述得比较概括，但结构是明确的：
- （a）界面结构：UFM 软件由若干主要的 Web UI 窗口组成，可从屏幕左侧的侧边栏菜单进入。
- （b）Settings 选项卡：Settings 选项卡用于配置 UFM 服务器与 UFM fabric 设置，包括事件策略、设备访问、网络管理、子网管理器与用户管理。手册对应的原文列举为 including events policy, device access, network management, subnet manager, and user management——顺序与课程口述完全一致。
- （c）SM 参数的进入路径：要查看与配置子网管理器参数，在 Settings 下选择子网管理器选项卡；然后在子网管理器选项卡中，按所需配置选择相应的子选项卡。
- （d）路由引擎的进入路径：要查看与配置路由引擎，在 Settings 下选择网络管理选项卡，会看到所支持的路由引擎列表。
把 (c) 与 (d) 并起来看，能得到一条重要的观察：UFM 把 SM 参数按"子网管理器"与"网络管理"两个入口分开组织。而前七节已经反复看到，路由引擎在 MLNX-OS 与 OpenSM 两种形态下都是与 SM 相关的核心参数。UFM 为什么把它放在网络管理下而不是子网管理器下，值得在第十一节展开——它反映了这个参数在平台视角里的定位差异。
UFM 侧：Settings 菜单的两条配置路径
左侧边边栏 -> Settings
---------------------------------------------------------------
Settings 选项卡负责五组配置：
events policy 事件策略
device access 设备访问
network management 网络管理 Subnet Manager > (选择相应的子选项卡)
手册中 SM 参数的分类（节选，括号内为配置项与默认值）
Sweep sweep_interval 10
sweep_on_trap TRUE (enabled)
force_heavy_sweep_window -1
LID reassign_lids FALSE (disabled)
Routing routing_threads_num 0
max_threads_per_core 0
Handover sm_priority 15
ignore_other_sm FALSE (disabled)
Fabric max_seq_redisc 2
Advanced Routing dump_ar FALSE
Logging log_flags 0x03
log_max_size 4096
Misc sharp_enabled 2
exit_on_fatal TRUE (enabled)
值得注意：UFM 侧的 sm_priority 默认值是 15，
而 MLNX-OS 侧 ib sm sm-priority 的默认值是 0。
同一概念，两种形态下默认值不同。
路径二：查看与配置路由引擎
---------------------------------------------------------------
Settings > Network Management > (查看支持的路由引擎列表)
注意：UFM 侧还有一条 MLNX-OS 与裸 OpenSM 都没有的
能力 —— 路由链（routing chain）策略文件
/opt/ufm/files/conf/opensm/routing_chains_policy.conf
用 unicast-step / end-unicast-step 段落定义
按 id 升序尝试的引擎序列。
规则要点（手册原文）：
第一个单播引擎必须覆盖 fabric 中全部交换机与 HCA
（topology id 必须为 0）
引擎的设置顺序按 id 升序，id 顺序必须与期望的
设置顺序一致
路由引擎配置文件中未指定的参数从主 opensm 配置
文件继承
下列参数只在主 opensm 配置文件中生效：
qos 与 qos_* 设置（如 vl_arb、sl2vl）
lmc
routing_engine
部署形态（厂商产品页口径）
---------------------------------------------------------------
UFM Telemetry 软件 / 流式输出到本地或云端数据库
UFM Enterprise 软件容器 或 专用一体机
UFM Cyber-AI 本地部署的专用一体机
许可
---------------------------------------------------------------
按受管设备计费，可累加
有效许可是安装与运行的前置条件先看这个分类差异本身暴露的信息。在 MLNX-OS 侧，路由引擎是 ib sm routing-engines——命令前缀 ib sm 明确表示它属于 SM 配置。在裸 OpenSM 侧，它是 opensm.conf 里的 routing_engine——与 sm_priority、sweep_interval 放在同一个文件里。而在 UFM 侧，它出现在 Network Management 而不是 Subnet Manager 下面。
这个差异反映了 UFM 的产品视角与前两者的技术视角不同。UFM 不是一个"SM 的图形化配置界面"，它是一个把 fabric 运营作为第一目标的平台。在 UFM 的产品逻辑里，"子网管理器"是一组负责 fabric 生命周期的运行参数（扫描、选举、LID、故障切换），而"路由引擎"是决定流量怎么走的一个策略选择——后者在 UFM 的叙述里天然属于"网络管理"的范畴，与拥塞发现、遥测采集这些能力并列。
把这一点落到实操上，有一条直接可用的推论：
- 如果你在 UFM 上找路由引擎却只在子网管理器选项卡里翻，你会找不到它。路径是 Settings → Network Management。这一点在跨形态迁移配置时特别容易踩——因为你在前一种形态形成的肌肉记忆会指向错误的菜单。
- 更重要的是，它提示了 UFM 与前两者的能力边界不同。前两种形态下，路由引擎是"给 SM 的一条指令"；而在 UFM 上，路由引擎是平台的一等管理对象——它有独立的菜单入口、独立的策略文件（routing chain）、独立的验证路径。这就是"平台"与"软件包"的区别：软件包给你一个配置文件，平台给你一套围绕这个对象的完整管理能力。
还有一条值得单独指出的观察，来自 UFM 手册里那三条"只在主配置文件中生效"的参数。手册明确：QoS 及其相关设置（如 vl_arb、sl2vl）、lmc、routing_engine 三个参数只在主 opensm 配置文件里生效，而路由引擎自己的配置文件中未指定的参数则从主配置继承。
这三条构成了 UFM 路由链机制的一个关键约束，也解释了本系列第十一条记录的那条规则的来源：routing_engine 这个参数在路由链场景下不能放在引擎自己的配置文件里。换句话说，路由链不是"多个引擎各自带一套完整配置"，而是"多个引擎共享一套主配置，只有少数几个参数允许各自覆盖"。理解这个约束，就理解了为什么路由链在设计上必须把 qos、lmc、routing_engine 三项收在主配置里统一管理——它们是全局语义，引擎之间的差异只应该体现在算法自身的参数上。
本节关键记忆：3 个层级 + 3 种部署形态 + 2 条配置路径 + 1 个默认值差异
- 3 个层级：UFM Telemetry（网络验证工具 + 实时遥测流式输出到本地或云端数据库）/ UFM Enterprise（自动化网络发现与配置下发、流量监控、拥塞发现、作业调度、Slurm 与 LSF 集成、OpenStack / Azure / VMware 集成）/ UFM Cyber-AI（含前两层全部 + 预防性维护与网络安全）
- 3 种部署形态：服务器上的服务 / 容器 / 专用硬件一体机；Cyber-AI 仅提供专用一体机
- 架构关系：UFM 用 OpenSM 来发现与配置所有 fabric 设备——它是宿主加界面，不是另一种 SM 实现
- 配置路径一：Settings → Subnet Manager → 相应子选项卡（扫描、LID、选举交接、fabric 重发现等）
- 配置路径二：Settings → Network Management → 路由引擎列表——不在子网管理器下
- 1 个默认值差异：UFM 侧 sm_priority 默认 15，MLNX-OS 侧默认 0——同一概念默认值不同，不能互相类比
- 1 个独有能力：路由链策略文件 routing_chains_policy.conf，且 qos / lmc / routing_engine 三项只在主配置生效
九、三种形态的逐项对照
What — 课程收尾给出的"对比"这一步，以及本篇需要补齐的对照维度
课程在收尾时明确安排了这一步：既然已经熟悉了运行子网管理器的不同选项，现在来看这些选项的对比。但课程本身没有给出具体的对比表——本节把前八节的全部事实整理成一张可查的对照表，这是本节唯一的产出。
需要说明的是：本表的所有取值都来自前八节已核实的事实，不包含任何未标注来源的推测。凡是原文未明确给出的，表中一律写"以你所用版本文档为准"，不做填补。
| 对照维度 | 形态一：交换机内嵌 SM | 形态二：服务器 OpenSM | 形态三：UFM |
|---|---|---|---|
| 宿主硬件 | 托管交换机的 x86 CPU（QM8700 配 x86 双核） | 安装了 MLNX OFED 栈的服务器 | UFM Server 节点（建议专用服务器）；或一体机 |
| 软件形态 | 内嵌于 MLNX-OS，无独立进程 | opensm 进程，/etc/init.d/opensm 管理 | UFM Server（+ 可选 Agent），内部使用 OpenSM |
| 管理规模 | 最多 2048 节点（x86 CPU 限制） | 默认设置面向数百节点规模的集群 | 面向大规模与超大规模（平台定位为 scale out） |
| 自适应路由 | 不支持 | 支持（需配 AR 系列引擎） | 支持 |
| Dragonfly+ / dfp / dfp2 | 不支持（含 Fat Tree 混合拓扑） | 支持 | 支持 |
| 拥塞控制 / SHIELD / FRN | 不支持 | 随 OFED 版本与引擎而定 | 支持（拥塞发现属 Enterprise 能力） |
| 集中遥测 / 拥塞发现 / AI 分析 | 无 | 无 | 支持（Telemetry / Enterprise / Cyber-AI 三层递进） |
| 管理界面 | CLI + Web UI（MLNX-OS 自带） | 无图形界面；靠配置文件 + 日志 + OFED 命令行工具 | 完整 Web UI（Telemetry / Events / Jobs / Reports / Settings 等） |
| 软件许可 | 不需要 | 不需要（MLNX OFED 免费） | 需要，按受管设备计费，可累加 |
| 额外硬件成本 | 托管型号比非托管型号贵（CPU + 管理口） | 需一台 24×7 宿主机（若已有则摊薄） | 需一台专用服务器（或一体机） |
| SM 优先级配置 | ib sm sm-priority 0-15，默认 0 | opensm.conf 中 sm_priority | Settings → Subnet Manager，默认 15 |
| 路由引擎配置 | ib sm routing-engines | opensm.conf 中 routing_engine | Settings → Network Management |
| 配置文件位置 | 不适用（命令即时生效） | /etc/opensm/opensm.conf | /opt/ufm/files/conf/opensm/opensm.conf |
| 主日志 | MLNX-OS 系统日志 + show 命令 | /var/log/opensm.log + /var/log/messages | /opt/ufm/file（log_file 默认值） |
| SM 宿主失效后果 | 该交换机同时失去带外管理与 SM 角色 | 需另一台候选者接替（宿主机是控制平面单点） | UFM Server 失效需切换；可做高可用部署 |
读表时必须注意的三处口径差异，避免互相类比
- 其一：三个"规模"字段含义不同，不可直接比较大小。形态一是明确的上限（2048 节点）；形态二是默认值所面向的规模（数百节点），原文未给出上限；形态三是平台的定位描述（面向大规模与超大规模）。只有第一个是硬边界，后两个是取向而非容量。任何"内嵌 SM 支持 2048、OpenSM 支持 3000"式的对比都是错的，因为后两个数字在原文中并不存在。
- 其二：三个"SM 优先级"字段的默认值不同，且语义域不同。形态一默认 0、形态三默认 15（均为文档实测值），形态二在本文引用的手册中未给出默认值，因此表中留空而不填补。更重要的是：这三个字段虽然名字相近，但它们作用于不同形态下的选举实现，跨形态迁移配置时不能直接照搬数值。
- 其三："SM 宿主失效后果"这一行是本表最重要的差异，也是第十一节的主题。注意形态一那一格：托管交换机一旦故障，它同时失去带外管理通道和 SM 角色——这意味着"把 SM 放在托管交换机上"这个选择，隐含了一个风险耦合。
本节关键记忆：15 个对照维度 + 3 处口径差异
- 结构差异的根本：形态一是"设备自带能力"，形态二是"软件装在通用服务器"，形态三是"平台 + 界面 + 许可证"
- 能力差异的根本：形态一不支持自适应路由与 Dragonfly+，且这不是开关问题而是能力缺失
- 成本差异的根本：前两种软件许可为零，第三种按节点线性增长
- 3 处口径差异：规模字段含义不同（仅形态一是硬上限） / 优先级默认值不同且语义域不同 / 路由引擎在 UFM 上归在网络管理下
- 1 条最易踩的结论：表中只有 2048 是硬边界，其余规模描述都不是容量上限
十、选型决策树：从节点规模落到唯一形态
What — 把前八节的信息压成一个可执行流程
课程把选型讲成了三条并列的考量，但三条并列的表述无法直接执行——因为它们不是等价的：有的能一步排除某个形态，有的只能在剩余形态之间比较。本节把它们重排成一条有顺序的判断链。
重排的依据在前三节已经给出：第四节的结论是能力维度比规模维度更早触发收敛；第三节的结论是规模上限由 CPU 决定、不可通过加内存绕过；第五节的结论是前两种形态软件许可为零、第三种按节点计费。
把三个问题排成有顺序的链条，理由是它们对决策空间的压缩强度不同。
第一问：拓扑是否需要 Dragonfly+，或者是否必须开自适应路由？
- 如果答案是"需要"：交换机内嵌 SM 立即被排除，决策空间从 3 变成 2。依据是第四节引用的文档原文——内嵌 SM 不支持自适应路由、不支持 Dragonfly+ 拓扑、不支持其与 Fat Tree 的组合。
- 如果答案是"不需要"：三个形态都还在候选池里，决策空间不变。
- 这一步为什么必须放第一位：因为它唯一能在完全不参考数字的情况下排除一个形态。其余两问都需要输入（节点数、预算），而这一问只需要一个布尔判断。把最容易判断的问句放最前，能避免"先查了半天节点数才发现拓扑用不了"。
第二问：节点数是否在 2048 以内？（仅当第一问为"不需要"时才需要问）
- 如果在 2048 以内，且预算敏感：形态一可用。软件许可为零、不需要额外服务器、不需要额外运维人力。但必须同时接受两条限制：不支持增强特性（第一问已确认不需要），以及交换机型号必须选托管型。
- 如果超过 2048：形态一同样被排除，理由不是能力而是算力——CPU 限制不可通过加内存绕过（第三节）。
- 这一步为什么必须放第二位：因为它的排除依据是硬的、不可协商的。而第三问（成本）的答案是相对的、可以讨价还价的。把硬约束放在软约束前面，是决策树设计的基本原则。
第三问：在形态二与形态三之间，怎么选？（第一问排除了形态一之后才进入这一步）
走到这一步，决定因素已经不是技术可行性，而是运营形态的偏好。给出一组可对照的判据：
- 选形态二（服务器 OpenSM）的信号：你已经有 24×7 的运维能力与 Linux 主机；你不需要集中遥测与拥塞发现（注意这是"不需要"，不是"有更好但可不要"）；你希望避免按节点计费的持续支出；你的团队熟悉命令行与配置文件，而不是 Web 界面。
- 选形态三（UFM）的信号：你需要 Telemetry 级别的实时遥测流式输出到数据库做分析——这项能力在前两种形态里根本不存在，所以这不是"省不省"的问题，而是"要不要"的问题；你需要拥塞发现与自动化网络配置下发；你需要与 Slurm / LSF 作业调度集成；你需要把 fabric 运维交给一个专职团队，因为 UFM 平台本身需要人来运维。
- 需要额外纳入考虑的两点：（1）形态二存在控制平面单点——宿主机故障需要有接替方案（第十一节展开）；（2）形态三的许可是随 fabric 扩容而增长的持续支出，如果你的 fabric 规划期还有多轮扩容，这条成本要按全周期计算。
最后说明这棵树的一个使用纪律。三问的顺序不可改，但更重要的是——每一问都应当被记录下来。因为"我们的 fabric 选了形态二，因为第一问确认不需要 Dragonfly+"这样一句话的决策依据，比"我们用 OpenSM"这种结论有用得多：前者可以在未来某个时刻被重新检查（如果拓扑需求变了，第一问的答案会变，决策就该重做），而后者只是一句无法追溯的事实陈述。这一点在第十一节会再次出现——因为重做这个决策的代价是全网重收敛。
决策树的一个常见误用，以及它的危害
误用方式：先按节点数选形态，再回头确认能力需求。这种顺序在实际项目中非常常见，危害在于它把"可以避免的重做"变成了"必须执行的重做"。
把代价说清楚。假设某 fabric 已经按"500 节点、预算敏感"选定形态一、上线运行一年。一年后业务方要求引入自适应路由。此时的处境是：形态一从设计上就不支持这个特性，且如第四节所述，这不是"打开某个开关"能解决的。必须更换宿主——要么改用服务器 OpenSM，要么采购 UFM。
而"更换宿主"在第九篇的框架下意味着什么？意味着 fabric 的控制平面要换主机、意味着一次完整的初始化与子网激活、意味着按第十一篇的分类这属于全网级变更。更麻烦的是：原本托管交换机上的 SM 角色要撤销、原本带内管理的路径要重新规划、而所有非托管交换机在整个过程中无法被带外管理。
因此本篇给出一条可执行的纪律：把第一问的答案写进架构文档，并注明它是一个约束而不是一个偏好。
"不需要自适应路由"与"我们决定不用自适应路由"是两种完全不同的表述：前者是一个被确认过的客观约束，可以在需求变化时被重新检查；后者只是一个当前的选择，当有人问起时无法给出有依据的回答。前者可审查，后者不可审查。架构文档的价值就在于把选择固化成可审查的记录。
本节关键记忆：3 问 + 3 种结果路径 + 1 条使用纪律
- 第 1 问（能力，顺序不可改）：需要 Dragonfly+ 或自适应路由？需要 → 排除形态一；不需要 → 三形态候选
- 第 2 问（规模）：节点数 ≤ 2048？超过 → 排除形态一（算力限制，不可绕过）；在范围内 → 形态一可用，但交换机必须选托管型
- 第 3 问（运营形态）：不需要集中遥测 → 形态二；需要 Telemetry / 拥塞发现 / 作业调度集成 / 专职运维 → 形态三
- 1 条使用纪律：把第一问的答案作为"约束"而非"偏好"写进架构文档——需求变化时决策才能被重新检查
- 1 个常见误用：先按节点数选、后确认能力 → 代价是更换宿主引发的全网重收敛
十一、故障影响面：SM 跑在哪里决定了故障时的后果
What — 本节要补上的一个课程未展开但决定成败的维度
课程在选型时给出的三个维度是规模、能力、成本。本节补充第四个维度：故障影响面。这不是课程内容，但它是前三节结论的直接推论，且本系列规范要求不引入未经核实的信息——因此本节只使用前八节已核实的事实做推演，不引入任何新的厂商声明。
推演的起点是第九篇已经讲清的一个机制：子网管理权在同一时刻只属于一个 Master SM。因此Master 所在的宿主一旦失效，fabric 的控制平面就进入无主状态，直到另一台候选者完成选举。
11.1 三种形态下的宿主失效路径
| 失效对象 | 直接后果 | 恢复依赖 | 可观测性影响 |
|---|---|---|---|
| 形态一：托管交换机（它同时是 SM 宿主） | 失去 SM 角色 + 失去带外管理通道 | 另一台启用内嵌 SM 的设备完成选举；但该设备也可能不带外管理口 | 若它是非 Master 设备且型号为非托管型，则完全失联；若为托管型，可从管理口读固件与端口状态，但无法读它是否被 SM 编程 |
| 形态二：OpenSM 宿主机 | 控制平面无主 | 另一台装了 OpenSM 的主机完成选举 | 宿主机本身可通过带外方式登录检查日志——但它与 IB 侧已断开，SM 交互全部失败 |
| 形态三：UFM Server | 控制平面无主；Web UI 同时不可用 | UFM 高可用部署的成员接替 | 宿主机仍可带外登录；但失去的是整个管理界面，而非某个参数 |
先把耦合的结构说清楚。托管交换机把三个角色放在同一台物理设备上：（1）它是一台转发设备，被带内管理；（2）它是 SM 的宿主，运行 Master SM；（3）它是一个带独立管理口的管理终端，可被带外访问。
第 2 与第 3 个角色的耦合是硬件层面的，不可通过配置解除。因为这台设备要提供带外管理口，就需要那颗 CPU 与那个 RJ45 口；而要运行 SM，也需要那颗 CPU。两者共用同一颗 CPU。这意味着 CPU 所在硬件层面的任何故障（供电、总线、CPU 本身）会同时击穿这两个角色——而这两件事在物理上是同一个东西，配置层无法把它们拆开。
把这个耦合的后果与前八节的结论连起来看，就得到一个必须正视的场景：
- 你在托管交换机上启用了内嵌 SM，它通过选举成为 Master。
- 这台设备的硬件发生故障。
- 后果一（控制平面）：Master 失效，fabric 进入无主状态，等待另一台候选者选举。
- 后果二（可观测性）：这台设备同时失去了带外管理口。如果它是唯一的托管型设备，那么现在你既没有 Master，也没有任何可以带外登录的终端。
- 后果三（若 fabric 用的是非托管型号）：其余所有交换机都是非托管型，没有 CPU、没有管理口，无法被带外访问。此时你唯一的交互手段就是让另一台 OpenSM 或内嵌 SM 完成选举并把 fabric 拉起来——而在此之前，你对那台故障设备无法做任何主动检查。
这个场景的严重性不在于"会故障"，而在于故障发生时你的信息是空的。没有管理口意味着你不知道那台设备的固件版本、不知道它的端口状态、不知道它是否在上电。而这些信息恰恰是判断"是设备故障还是光模块故障"所必需的。所以结论不是"不要用形态一"，而是"用形态一时，必须至少保证 fabric 里有第二台带外可达的设备"。
把这条结论推广成三条部署纪律，它们是本节最有价值的产出：
- 纪律一：SM 宿主与带外管理终端应当是两台不同的设备。让 SM 跑在 A 交换机上，同时保证 B 交换机有带外管理口且 B 不承担 SM 角色。这样 A 故障时，你还能通过 B 的管理口做初步判断。这条纪律的实质是：不要让"我唯一的观察窗口"和"我最主要的故障点"是同一个东西。
- 纪律二：fabric 里应当至少有两台设备启用了 SM 候选资格，且优先级不同。这直接对应第六节"不要依赖 GUID 仲裁"那条建议——优先级不同意味着 Master 切换时你有可预测的结果，而不是"看谁的 GUID 小"。
- 纪律三：形态二与形态三都必须准备一个"接替宿主"的预案。因为控制平面单点在这两种形态下同样存在，只是失效对象从交换机变成了服务器。第九篇讲的 handover 与选举机制是通用的，但"另一台机器上是否已经装好了并启动着 OpenSM"是个纯粹的运维问题，不在任何产品文档的覆盖范围内。
最后把三个维度与本节这个维度合并，得到本篇的完整选型框架：规模、能力、成本、故障影响面。前三个是课程明确给出的，第四个是由本系列前十一篇的机制事实推演出的补充。而推演的方法与前十一篇的惯例一致：只看已核实的机制，不引入任何未经厂商文档确认的声明。
本节关键记忆：1 个补充维度 + 1 个风险耦合 + 3 条部署纪律
- 1 个补充维度：故障影响面——课程未列，但由第九篇"唯一 Master"机制直接推出
- 1 个风险耦合：托管交换机上的 SM 角色与带外管理口共用同一颗 CPU，硬件故障会同时击穿两者，配置层无法拆开
- 纪律一：SM 宿主与带外管理终端必须是两台不同设备——不要让唯一的观察窗口等于主要的故障点
- 纪律二：至少两台设备有 SM 候选资格且优先级不同——让切换结果可预测
- 纪律三：形态二与形态三都要预备接替宿主——控制平面单点在两种形态下同样存在
- 1 条方法论：本节只做机制推演，不引入新的厂商声明，符合本系列"禁止推测"的要求
十二、常见误区与纠正
What — 把前十一节的易错点集中处理
本节汇总六条最容易在实操中出错的认识，每一条都给出错误的来源与正确的依据。这六条不是新内容，是前十一节结论的"反命题"形式——而反命题形式往往比原命题更容易被记住，也更容易在踩坑时被检索到。
| 常见误区 | 为什么错 | 正确依据 |
|---|---|---|
| "托管交换机就等于 SM 在交换机上" | 托管描述的是设备形态（有没有 CPU 与管理口），不描述 SM 是否在运行 | MLNX-OS 文档：子网管理器默认是关闭的。ib sm 执行后才运行。是否为 Master 由选举决定，不由型号决定 |
| "非托管交换机功能少，将就用" | 非托管交换机不是低配版，而是另一种设备形态：无 CPU、无管理口、无带外管理、无 SM 能力 | 课程定义：只有固件，因此既不支持带外管理，也不支持 SM 能力。大规模 fabric 里它反而是更匹配的型号 |
| "交换机内嵌 SM 关掉自适应路由就行" | 是能力不存在，不是开关没开 | MLNX-OS 文档措辞是 does not support adaptive routing / Dragonfly+；且 ib sm 命令族中无对应配置项——换宿主是唯一出路 |
| "priority 范围是 1-15，0 是非法的" | 课程口述的"1 到 15"是建议区间，不是参数的合法取值范围 | MLNX-OS 文档：范围 0-15，0 最不重要，15 最重要，默认值 0。ib sm sm-priority 0 合法 |
| "opensm.log 里的 ERROR 可以清掉" | 它记录的是"fabric 曾经不正常"这一历史事实，是唯一一份该问题的历史记录 | 课程原则：opensm.log 中报告的所有错误都应被视为 fabric 健康指标 |
| "配置了 routing_engine 就等于生效了" | 配置是意图，实际生效的引擎可能因失败回退而不同 | 课程 + 手册：OpenSM 无法执行所配置引擎时会回退到 minhop。判据是日志里 <engine> tables configured on all switches 的前半段 |
六条误区里有四条集中在"默认值与能力边界"，这本身就是一个值得注意的规律
前四条误区的共同成因是"把某个具体取值当成了普遍规则"。托管与非托管的形态定义、does not support 与"默认关闭"、优先级 0 是否合法——这三条都是"某个具体取值 ≠ 一般规则"的变体。它们在文档里都能找到明确答案，但因为答案散落在不同的手册章节里，读的时候很容易只记住其中一半。
后两条误区的成因不同，是"把状态指标与历史记录混淆"，以及"把配置意图与实际结果混淆"。这两条属于运维习惯问题，不是知识问题——它们需要通过流程约束来防范，而不能靠读文档解决。
给出一条可执行的对策，它同时覆盖这六条：建立一份"部署基线记录"。它至少应包含四项：
- （1）形态选择及决策依据（不是只写结论，见第十节）；
- （2）SM 宿主的设备清单与优先级设置（写明各台设备的优先级数值，不写"按 GUID 仲裁"）；
- （3）各形态下的关键参数实际值（路由引擎、扫描间隔、日志路径）及其对应的日志判据；
- （4）接替宿主的方案与切换步骤。
这份记录的价值在故障时才体现出来——而这正是第十一节说的"故障发生时你的信息是空的"这个问题的对策。它不能替代带外管理通道，但它能在带外通道可用时，把"需要做什么"从回忆变成查表。
本节关键记忆：6 条误区 + 1 个成因规律 + 1 份部署基线记录
- 误区 1-4 成因相同：把某个具体取值当成了普遍规则——形态定义、能力边界、优先级范围三处最易错
- 误区 5-6 成因不同：状态与历史混淆 / 意图与结果混淆——属运维习惯问题，需流程约束而非文档
- 1 份部署基线记录（4 项）：形态与决策依据 / SM 宿主清单与优先级 / 关键参数值与日志判据 / 接替宿主方案
- 其价值：不能替代带外管理通道，但能在通道可用时把"需要做什么"从回忆变成查表
十三、FAQ 高频问答（20 组）
本节围绕子网管理器部署形态的 20 个高频易错点展开，覆盖形态定义、能力边界、CLI 精度、版本差异与许可模型五类。题目中的命令名、参数范围、文件路径与许可表述，均引自文末「参考资料」列出的 MLNX-OS User Manual、QM87xx Switch Systems User Manual、opensm(8)、MLNX SM Release Notes 与 UFM Enterprise User Manual。
- Q1. 三种运行子网管理器的形态分别是什么？
在交换机上、在服务器上、或在统一 fabric 管理器 UFM 上。更具体地说：托管交换机内嵌的 MLNX-OS SM、安装在 MLNX OFED 栈里的 OpenSM、UFM 平台（内部使用 OpenSM）。课程把这三条作为本单元的组织框架，第九至十一节把它变成可执行的决策树。
- Q2. 所有 InfiniBand 交换机都被带内管理，这句话对吗？
对，课程说"无一例外"。所有 InfiniBand 交换机都以带内方式被 Master SM 管理，这是 fabric 初始化与管理流程的一部分。关键在于这与"托管与否"无关——托管交换机额外有带外管理通道，非托管交换机没有。带内管理对两者都成立，这是两个正交的维度。
- Q3. 非托管交换机是不是"功能少的托管交换机"？
不是，它是另一种设备形态。课程定义：非托管交换机（也称外部托管交换机）只有固件，因此既不支持带外管理，也不支持 SM 能力。它没有 CPU、没有管理口、无 CLI 与 Web UI。在大规模 fabric 里它反而是更匹配的型号——因为 SM 本来就不在交换机里，为 CPU 与管理口付的钱是纯冗余。
- Q4. QM8700 与 QM8790 的区别是什么？
同规格、不同管理形态。二者都是 Mellanox Quantum 系列 1U HDR 200Gb/s 交换机，均为 40 个 QSFP56 200Gb/s 端口、16 Tb/s 聚合容量。NVIDIA 规格表在 Management 与 Subnet Manager 两列明确区分：QM8700 为 Inband/outband 且带 SM（+），配 x86 双核 CPU；QM8790 为仅 Inband 且不带 SM（-），无 CPU。SKU 表里的完整 OPN 分别是 MQSM8700-HS2F / HS2R 与 MQSM8790-HS2F / HS2R。
- Q5. 交换机内嵌 SM 能管多大的 fabric？为什么有上限？
最多 2048 个节点，原因是 x86 架构交换机的 CPU 限制。两个必须注意的细节：（1）2048 数的是节点（HCA），不是交换机数——交换机数量远小于 2048；（2）限制来自 CPU 算力与 SMP 事务吞吐，不是转发表容量——QM8700 的线性转发表为 4 × 48K 条目，远超所需。推论：这不是"装不下"，是"算不完"，且规模逼近上限时重收敛时间会同步变长。
- Q6. 交换机内嵌 SM 支持自适应路由和 Dragonfly+ 吗？
不支持，这是能力缺失而非开关未开。MLNX-OS 文档两条限制原文：不支持 Dragonfly+ 拓扑，也不支持 Fat-Tree 与 Dragonfly+ 的组合拓扑；不支持自适应路由、故障路由（SHIELD 或 FRN）、拥塞控制、SHIELD 与 SHARP。措辞是 does not support，且 ib sm 命令族中确无对应配置项——换宿主是唯一出路。这两种增强特性是服务器侧 DOA OFED 里 OpenSM 的能力。
- Q7. 选型时应该先看节点数还是先看能力需求？
先看能力。能力维度是离散的存在性判断，要么支持要么不支持，没有中间地带；规模维度是连续量，可以用阈值处理。更实际的原因是：规模会在项目推进中渐变，而能力需求往往在拓扑设计阶段就被一次性锁定。先按规模选了内嵌 SM、之后才发现拓扑要 Dragonfly+，代价是更换宿主引发的全网重收敛。建议把"不需要自适应路由"写成约束而非偏好，便于日后复查。
- Q8. ib sm sm-priority 的取值范围是 1-15 吗？
合法范围是 0-15，课程口述的"1 到 15"是建议区间。文档明确：范围 0-15，0 表示最不重要，15 表示最重要，默认值是 0，文档示例给的是 ib sm sm-priority 1。0 是合法的，只是语义为"最低优先级"，不要把 ib sm sm-priority 0 当成非法值去排查。另外注意 UFM 侧 sm_priority 的默认值是 15，与 MLNX-OS 侧的 0 不同，跨形态不能直接照搬数值。
- Q9. 课程说"不要依赖 GUID 仲裁"，为什么不依赖它还不行？
因为那个规则是确定的、但不可控的。文档原文：如果两个或更多活动 SM 拥有相同的最高优先级，则端口 GUID 最低的那个管理 fabric。课程的意思不是"这条规则不可靠"，而是"依赖它等于放弃主动控制权"——哪一台成为 Master 由硬件 GUID 数值决定，而不是由你决定。把优先级设成不同值，等于把这件事从"取决于硬件"变成"取决于你的配置"。这是可运维性与可预测性的差别。
- Q10. 托管交换机默认就在跑 SM 吗？
不跑，MLNX-OS 的子网管理器默认是关闭的（disabled by default）。必须执行 ib sm 才会启动它；同时启用后默认以优先级 0 运行。推论："这台交换机是托管的"不能推出"它在跑 SM"，更不能推出"它是 Master"——只有选举结果能决定谁是 Master。配套的 HA 节点命令是 ib smnode <hostname> create / enable / sm-priority，可用 show ib smnode 观察 ha-role（offline / unknown / master / standby / disabled）。
- Q11. /etc/init.d/opensm status 显示 Standby，是出问题了吗？
没有，这是正常状态。课程特别指出了这个现象。OpenSM 启动后先作为候选者加入，如果已有 Master 在运行，它就处于 standby 状态——看到 Standby 说明选举机制正常工作。要确认全网状态应查 show ib sm（交换机侧）或 smpquery 列出的 SM 实体及其角色，而不是把 Standby 当成故障。systemd 发行版上用 systemctl status opensm 替代该脚本。
- Q12. /var/log/messages 和 /var/log/opensm.log 分别记什么？
前者记重大事件，后者记错误细节。课程：/var/log/messages 只包含通用的、重大的事件（含 SUBNET UP）；/var/log/opensm.log 包含所报告错误的细节。两条实操推论：（1）排障顺序是先 messages 确认子网是否建立，再 opensm.log 查具体原因；（2）opensm.log 由 OpenSM 进程自己写，进程挂掉时未刷盘内容会丢，所以现场第一动作是先抢救这个文件——而 messages 由系统日志守护进程管理，不依赖 OpenSM 是否存活。
- Q13. OpenSM 的配置文件在哪？什么时候生成？
默认位置 /etc/opensm/opensm.conf，首次运行时以默认设置自动创建。课程：如果希望在运行 OpenSM 之前配置设置，可以用 opensm -c 命令加上文件位置来创建它（-c 即 --create-config <file_name>）。加载指定配置用 -F / --config，不指定时使用 /etc/opensm/opensm.conf。同目录下的其他默认文件还有 ib-node-name-map、partitions.conf、qos-policy.conf、prefix-routes.conf、per-module-logging.conf、torus-2QoS.conf。
- Q14. 为什么课程特别强调"记录 OpenSM 版本号"？
因为不同版本的默认路由引擎不同，这直接决定死锁免疫性。社区版 opensm(8) man page 长期写作 "instead of Min Hop algorithm (default)"，即默认 minhop（不防信用环）；而 MLNX SM Release Notes 5.10 记录的是 "Changed the default routing engine to be ar_updn instead of minhop"，5.11 则记录了为 UPDN 与 ar_updn 新增的根检测算法。课程举例的版本是 5.11.0。结论：routing_engine 无论哪套 OpenSM 都应显式写入配置文件，并逐字核对日志里的实际引擎名——因为回退发生时只有一行 INFO，没有 ERROR 与 WARN。
- Q15. 多个路由引擎怎么配？失败会怎样？
用逗号分隔，按顺序尝试；全失败时回退 minhop。课程：多个路由引擎可以指定，用逗号分隔，这样如果靠前的路由引擎失败，会按特定顺序尝试后续的路由算法；如果 OpenSM 无法执行所配置的路由引擎，OpenSM 会回退到 minhop 路由引擎。10.11 节的兜底规则补充：若引擎列表中包含 no_fallback，则不启用回退——环面与 Dragonfly+ 场景应关闭兜底，因为在有环拓扑上"回退到 minhop"等于"回退到不防死锁的引擎"。MLNX-OS 侧对应命令是 ib sm routing-engines，用空格分隔。
- Q16. UFM 有哪几个层级？分别提供什么能力？
Telemetry / Enterprise / Cyber-AI 三级，能力递进。Telemetry：网络验证工具 + 采集并流式输出实时遥测、应用工作负载使用与系统配置到本地或云端数据库做进一步分析。Enterprise：在 Telemetry 之上增加自动化网络发现与配置下发、流量监控、拥塞发现；课程补充它还支持作业调度、Slurm 与 LSF 集成、OpenStack / Azure / VMware 集成。Cyber-AI：包含前两层全部 + 预防性维护与网络安全。本单元聚焦 Enterprise，课程明确说 UFM 自身的其他选项不在本次培训范围内。
- Q17. UFM 和 OpenSM 是什么关系？UFM 是另一种 SM 实现吗？
不是。UFM 使用 OpenSM 来发现与配置所有 InfiniBand fabric 设备。课程原文：UFM 使用 OpenSM 来发现与配置所有 InfiniBand fabric 设备，从而在 fabric 中启用流量流动。所以三种形态不是三种 SM 实现，而是三种宿主与界面——UFM 的子网管理器是一个集中的实体，它发现并配置所有 fabric 设备以启用流量流动。同时注意"子网管理权同一时刻只属于一个 Master SM"这条约束在 UFM 下同样成立，UFM 的高可用不等于 SM 的多主。
- Q18. UFM 里路由引擎在哪个菜单下？
在 Settings → Network Management，不在 Subnet Manager 下。课程：要查看与配置子网管理器参数，在 Settings 下选择子网管理器选项卡，然后在子网管理器选项卡中按所需配置选择相应的子选项卡；要查看与配置路由引擎，在 Settings 下选择网络管理选项卡。Settings 共负责五组配置：events policy、device access、network management、subnet manager、user management。这个分类差异反映了 UFM 的平台视角与前两种形态的技术视角不同——跨形态迁移配置时特别容易因为肌肉记忆而找错菜单。
- Q19. UFM 的许可怎么计费？可以累加吗？
按受管设备计费，依据 UFM 许可协议；许可可累加；有效许可是安装与运行的前置条件。手册示例：为 10 个受管 HCA 装一个许可、再为 15 个装另一个，则 UFM 的许可上限是 25 个受管 HCA——是精确匹配 fabric 实际节点数，不是向上取整。注意计费对象随版本表述不同：UFM Enterprise 软件手册 6.21.2 写"按受管 HCA"，6.20.1.1 与 Appliance 版写"按受管节点"，规格表中 Managed Switching Devices 的定义是"fabric 交换机、网关与路由器"，采购前以你所用手册原文为准。
- Q20. 把 SM 放在托管交换机上，最大的风险是什么？
风险耦合：SM 角色与带外管理口共用同一颗 CPU，硬件故障会同时击穿两者。因为提供带外管理口需要那颗 CPU，运行 SM 也需要那颗 CPU，配置层无法把它们拆开。后果是：SM 宿主故障时不仅失去 Master，还同时失去了唯一的带外登录通道；若其余设备是非托管型，则完全没有可以带外访问的终端，只能靠另一台候选者选举把 fabric 拉起来。对策不是"别用形态一"，而是"用形态一时必须保证 fabric 里有第二台带外可达的设备"——即 SM 宿主与带外管理终端应当是两台不同的设备。
FAQ 总纲（口诀式速记）
- 1 句总纲：三种形态 = 三种宿主与界面，不是三种 SM 实现；UFM 内部用的就是 OpenSM
- 1 个正交维度：带内管理对所有交换机成立，与托管状态无关；托管只决定有没有第二条通道
- 2 类交换机：QM8700 Inband/outband + SM（x86 双核）/ QM8790 仅 Inband + 无 SM；均为 40 端口 / 16 Tb/s
- 1 个硬数字：内嵌 SM 最多 2048 节点（数节点不是交换机），因 CPU 算力受限，不是转发表容量
- 1 条最易错边界：内嵌 SM 对 AR 与 Dragonfly+ 是 does not support，不是默认关闭——换宿主是唯一出路
- 1 个选型顺序：先看能力（排除形态一）→ 再看规模（再看 2048）→ 最后比成本与运营形态
- 1 个默认值陷阱：内嵌 SM 默认不运行，启用后默认优先级 0；而 UFM 侧 sm_priority 默认 15
- 1 条精度纠正：ib sm sm-priority 范围是 0-15，0 合法；课程口述的 1-15 是建议值
- 1 条仲裁规则：优先级相同则端口 GUID 最低者为 Master；课程不建议依赖它，因为那等于放弃控制权
- 1 条默认引擎建议：默认 minhop，建议改为 updn 以避免信用环
- 2 个日志分工：/var/log/messages 重大事件（含 SUBNET UP）/ /var/log/opensm.log 错误细节（含引擎名）
- 1 条排障原则：opensm.log 里每条 ERROR 都应视为 fabric 健康指标，不要当噪声清掉
- 1 个 Standby 说明：status 显示 standby 是正常状态，说明选举机制在工作
- 1 个版本分支：社区版默认 minhop；MLNX SM 5.10+ 默认 ar_updn——所以不要依赖默认值
- 1 个配置纪律：无论哪套 OpenSM 都显式写 routing_engine，并逐字核对日志里的引擎名
- 1 个定位纠偏：增强特性是服务器侧 OpenSM 的能力，不是 MLNX-OS 内嵌 SM 的能力
- 1 条 UFM 独立能力：路由链策略文件 routing_chains_policy.conf，且 qos / lmc / routing_engine 三项只在主配置生效
- 1 个部署形态提醒：UFM Cyber-AI 只提供专用一体机，Enterprise 才有容器与服务形态
- 1 条风险耦合：托管交换机上 SM 与带外管理共用一颗 CPU——对策：宿主与管理终端必须是两台不同设备
- 1 份应建记录：部署基线记录（形态与依据 / 宿主清单与优先级 / 关键参数与日志判据 / 接替宿主方案）
十四、Roadmap 后续预告
本篇是 InfiniBand 专题的第十三篇。它的位置是：本系列第一篇《InfiniBand 架构简介：从五层模型到子网管理》讲清了分层、报文结构与三层地址，本系列第八篇《子网初始化：拓扑发现、LID 分配、路径计算与子网激活》讲清了 fabric 怎么从线缆变成能传数据的子网，本系列第九篇《SM 监控与拓扑变化：选举、故障切换、扫描与重收敛》讲清了子网建立之后如何持续运行与故障重收敛，本系列第十一篇《路由引擎：算法原理、选型对照与 OpenSM 配置验证》讲清了路径计算这一步内部到底发生了什么，本篇补上了 "这个组件本身跑在哪里、以什么形态部署、有什么能力边界与成本结构"这个环节。这五篇合起来覆盖了"物理连接 → 拓扑发现 → 路径计算 → 子网激活 → 持续监控与重收敛 → 承载这一切的 SM 宿主形态"的完整链路。
接下来的方向，按由 SM 宿主向它依赖的底层机制、以及由"部署形态"向"运行期机制"深入的顺序包括：
- SM 选举与 handover 的完整算法：本系列第九篇讲了选举与故障切换的机制框架，但没有展开 Master 判定规则、优先级比较、handover 状态迁移的完整状态机。本篇第六节引用的 ha-role（offline / unknown / master / standby / disabled）与 ha-state（offline / init / searching / joining / online / creating / waiting / leaving / join-sync / failed / removed / regroup）两组取值，正好是那个状态机的两个投影。
- 链路层信用流控的完整机制：本系列第十、十一篇反复用到"信用按虚拟通道分配与授予"这个前提，但没有展开信用本身怎么计算、缓冲怎么划分、信用环在缓冲级别上如何精确成立。这是理解全部死锁讨论的物理基础。
- 组播转发表 MFT 与组播路由：本系列讨论的全部是单播 LFT（属性 0x0019）。组播用 MFT（0x001B）与 MLID，走的是生成树而非最短路径，死锁免疫的论证方式与单播完全不同。
- QoS 策略的配置与验证：本篇第八节提到 UFM 侧 qos 相关配置项与"只在主配置生效"的约束，第十一篇指出 VL 递增会占用 QoS 通道、Dragonfly+ 场景下 SM 侧 QoS 需设为 FALSE。这些替代方案怎么写、怎么验证生效，需要配合 smpquery 读表回读。
- 自适应路由管理器的完整配置：本篇反复提到"支持自适应路由"与"需配 AR 系列引擎"这两个条件，但没有展开 AR 管理器本身的配置文件结构、端口组的生成规则、ageing 与散列策略。散列端口（scatter-ports）与 GUID 路由顺序这两项 MLNX-OS 独有选项也在此列。
- SHIELD 机制与故障路由：本篇第四节把 SHIELD / FRN 列为内嵌 SM 不支持的功能，但没有展开它们的工作机制。这是一套独立于路由引擎的链路级保护机制，与本系列第十一篇讲的三种"绕开故障"是不同层次的方案。
- 拓扑变化后的路径重算耗时测量：本系列第九、十一篇都强调改路由或故障会触发全网重算，但没有给出这个重算在实际规模下的耗时数据。第三节已经论证了规模上限来自 CPU 算力，那么这个算力在不同规模下的实际表现就是一个必须实测、不能推测的工程指标。
- 软 RoCE 与硬件 InfiniBand 在子网管理上的差异：rxe / Soft-RoCE 没有真实的 SM 与转发表硬件，许多子网管理机制在软实现中并不存在或被简化，排查时不能把两者行为直接类比。
如果你在实践中遇到具体问题——例如改了 ib sm routing-engines 但重收敛后行为没变、/etc/init.d/opensm status 显示 Standby 却不确定是否正常、UFM 界面里找不到路由引擎选项、在 UFM 上配置了许可但节点数超出预期——欢迎在评论区留言，我会挑出共性问题单独扩展一篇专题。
浙公网安备 33010602011771号