课程导入：学习目标、课程结构、InfiniBand网络基础与多路径概念
1.1 为什么需要关注多路径异常
在HPC与AI集群中，InfiniBand（IB）网络承担着GPU直连通信、并行文件系统IO与分布式训练同步等关键流量。一条链路中断或性能劣化，轻则拖慢作业，重则导致整个集群任务失败。实际运维中，多路径（Multi-Path）机制用于提供冗余与负载均衡，但路径切换并非总是“无缝”的——自适应路由（AR）误判、子网管理器（SM）重配置延迟、端口状态不一致等问题，都可能让多路径成为故障放大器而非保护伞。
本课程将围绕“多路径异常”这一核心场景，从链路层、网络层到协议层逐层拆解，帮助你建立一套可复用的排查方法论。学完本章，你将明确：
- IB网络的基本组成与多路径的工作原理；
- 本课程30章的结构设计与学习路径；
- 多路径异常的主要类型与排查切入点。
1.2 InfiniBand网络基础：从链路到子网
InfiniBand采用点对点串行链路，每个物理端口以4x（四通道）或12x方式捆绑，单端口速率从EDR（100Gb/s）到NDR（400Gb/s）不等。与以太网最大的差异在于：IB网络是子网化管理结构，所有转发决策由子网管理器（Subnet Manager, SM）统一计算并下发。
一个典型的两层IB拓扑包含以下关键对象：
| 组件 | 角色 | 多路径相关要点 |
|---|---|---|
| CA（Channel Adapter） | 端节点（服务器/存储） | 每个CA可拥有多个端口，是多路径的起点 |
| Switch | 数据转发 | 内部维护线性转发表（LFT），由SM填充 |
| SM | 子网控制 | 计算路径并下发，SM故障会导致全网重收敛 |
| LID（Local ID） | 二层地址 | 每个端口至少一个LID，多路径依赖不同LID组合 |
多路径的实现依赖SM为同一对源-目的地址计算多条等价路径。在IB中，这通常通过多个LID（每个端口可分配多个LID）或自适应路由（AR）完成。AR允许交换机基于数据包动态选择输出端口，但这也引入了“路径漂移”的不确定性——这正是后续章节排查的重点。
ibqueryerrors、perftest、sm_poll等专用工具，而非通用网络命令。
1.3 多路径异常的核心类型
根据故障发生的层次，多路径异常可分为以下三类，这也是本课程后续章节的编排主线：
- 链路层异常：物理信号劣化、CRC错误增长、端口误码率超阈值。表现为
ibqueryerrors中symbol_error或link_error_recovery计数持续增加。 - 网络层异常：SM下发的LFT不一致、LID重复分配、路径计算环路。典型场景是SM主备切换后，部分交换机未收到更新导致黑洞路由。
- 传输层异常：QP（队列对）超时重传、丢包导致RC连接断开。多路径场景下，不同路径的延迟差异可能引发乱序，进而触发重传风暴。
1.4 课程结构：30章学习路径
本课程按“基础→工具→场景→进阶”四个阶段组织，每章聚焦一个可独立操作的排查主题：
| 阶段 | 章节范围 | 核心能力 |
|---|---|---|
| 基础篇 | 第1-5章 | IB协议、多路径原理、SM/LFT机制 |
| 工具篇 | 第6-12章 | ibdiagnet、perftest、sm_poll等实战 |
| 场景篇 | 第13-24章 | 链路抖动、SM切换、AR异常等12个案例 |
| 进阶篇 | 第25-30章 | 自动化脚本、监控集成、根因分析框架 |
每章均包含故障现象描述→排查命令→日志解读→根因定位→修复验证的完整闭环。建议按顺序学习，因为后续章节会复用前文介绍的排查命令与判断逻辑。
1.5 本章小结与实验准备
本章建立了三个关键认知：IB多路径依赖SM集中管控、异常可发生在链路/网络/传输三层、排查需结合专用工具与SM状态。在进入下一章前，请确保你的实验环境满足：
- 至少2台安装
mlnx-ofed驱动的服务器； - 1台可运行
opensm的管理节点； - 具备
ibdiagnet、ibqueryerrors、perftest等IB诊断工具。