Storpath
L4 进阶方向全程第 32 / 38 节看完整路径
原理预计 40 分钟

RDMA、InfiniBand 与 RoCE：高性能存储的入场券

GPFS ECE、Weka、NVMe-oF 都跑在 RDMA 上。先弄懂它凭什么快，以及它对网络提了什么条件。

学完这节你能做到

  • 说清内核旁路与零拷贝为什么能同时降延迟和降 CPU
  • 区分 InfiniBand 与 RoCEv2 两条路线各自的代价
  • 解释无损网络为什么要 PFC + ECN，以及 PFC 配错会有多糟
  • 用 ibstat / ib_write_bw 判断一条 RDMA 链路是否真的可用

盘变快之后，瓶颈换人了

L1 的网络课最后留了个尾巴：RDMA 值不值得上。到了 L4 得把它讲完 —— 因为 GPFS ECE、Weka、VastData 这些方案的官方要求里，RDMA 网络不是选配。

先看一组量级。一次 4KB 远程读，时间花在哪：

NVMe 盘本身                      ~80 µs   (早年 HDD 是 5000 µs)
TCP/IP 协议栈往返（内核）         ~30 µs
RDMA 往返                        ~2 µs

HDD 时代，盘 5 毫秒、网络 30 微秒，网络那点开销可以忽略不计。换成 NVMe 之后，协议栈的开销和介质本身进了同一个量级 —— 这就是高性能存储必须处理网络栈的原因。盘不再是瓶颈了，内核成了。

CPU 那边也一样。用普通 TCP 跑满 100GbE，大约要吃掉 8~12 个核心专门做收发包和拷贝。这些核心在存储节点上本来是要留给 EC 编解码和 RocksDB 的。

RDMA 做的两件事

内核旁路（kernel bypass）

普通 TCP 收一个包，路径是这样：

网卡 → 中断 → 内核协议栈 → socket 缓冲区 → 拷贝到用户态 → 应用
                ↑ 上下文切换      ↑ 一次内存拷贝

RDMA 把内核从数据路径上摘掉了。应用直接和网卡打交道，只有建立连接时才走一次内核。没有系统调用、没有上下文切换、没有软中断风暴。

零拷贝（zero copy）

更关键的是这一条。应用先把一块内存注册（register）给网卡，网卡拿到这块内存的地址翻译表，之后可以直接往里 DMA 写数据。

普通 TCP：网卡 → 内核 socket buffer → 用户态 buffer   （至少 1 次拷贝）
RDMA：    网卡 → 应用内存                              （0 次）

这两件事叠加，才有了「延迟降一个数量级、CPU 降一个数量级」的效果。

i注册内存不是免费的

内存注册（Memory Region, MR）要把这块内存锁在物理内存里（pin），不允许被换出，还要在网卡里建立地址翻译表。注册本身很慢，是毫秒级操作。

所以所有 RDMA 程序都是启动时一次性注册一大块，之后反复复用。GPFS 的 pagepool 就是这块内存 —— 这也解释了为什么 GPFS 要求给 pagepool 分配那么多内存，以及为什么改 pagepool 必须重启守护进程。

verbs：单边操作才是杀手锏

RDMA 的编程接口叫 verbs，操作分两类：

类型操作对端 CPU 参与吗
双边SEND / RECV要。对端必须提前挂好 RECV，收到后被通知
单边READ / WRITE不参与。发起方直接读写对端内存，对端 CPU 毫不知情

单边操作对存储的意义很直接：一个客户端从存储节点读数据，可以不打扰存储节点的 CPU。存储节点只在建立连接时授权一块内存区域，之后客户端自己来取。节点数越多、并发越高，这个差别越明显。

三个必知的对象：

QP  (Queue Pair)     一对收发队列，相当于 RDMA 的「连接」
MR  (Memory Region)  注册过的内存区域，带一个 rkey 做访问授权
CQ  (Completion Queue) 完成队列，操作做完了往这儿放一条记录

排障时看到 QP error、CQE error，指的就是这几个东西。

两条路：InfiniBand 与 RoCE

RDMA 只是一套语义，底下的承载有两条路线，选哪条是规划阶段的硬决策。

InfiniBandRoCEv2
网络形态独立的一张网，自成体系跑在以太网上，UDP/IP 封装
无损天生无损，链路层 credit 机制以太网默认会丢包，无损要自己造
管理需要子网管理器（opensm / UFM）用现有的交换机管理体系
可路由同一子网内可路由，能跨三层
交换机专用 IB 交换机支持 DCB 的以太网交换机
运维门槛术语体系独立，但配好了很稳复用以太网技能，但调无损很难

InfiniBand 的 credit 机制值得单独说一句：发送方只有在确认接收方有缓冲区时才发，所以链路层根本不会因为拥塞丢包。这是它「天生无损」的来源，也是 HPC 场景一直用它的原因。

RoCEv2 走的是另一条思路：复用以太网，但以太网是允许丢包的，而 RDMA 对丢包极其敏感（早期实现丢一个包要整个消息重传）。所以必须在以太网上造出无损。

无损三件套：PFC、ECN、DCQCN

ECN  ── 端到端拥塞控制，交换机给包打标记 → 发送端主动降速   【主力】
DCQCN ─ 网卡上实现的降速算法，消费 ECN 标记                 【执行者】
PFC  ── 链路层暂停，让上一跳别发了                          【最后保险】

正确的分工是：ECN 干活，PFC 兜底。ECN 让发送端提前减速，把拥塞消化在源头；PFC 只在 ECN 来不及、缓冲区快满时才触发，防止丢包。

如果你在生产网上看到 PFC pause 帧持续不断，说明 ECN 没起作用 —— 这是配置有问题，不是正常状态。

×PFC 配错，比不配 RDMA 还糟

PFC 是逐跳的暂停，一旦大量触发会带来两个后果：

  • 拥塞扩散（congestion spreading）：A 端口拥塞 → 向上游发 pause → 上游整个优先级的流量全停 → 继续向更上游扩散。最后一个端口的问题能让半个集群卡住，而且被卡住的业务和拥塞源头毫无关系（victim flow）。
  • PFC 死锁：环形依赖下互相等对方解除暂停，谁也不发，链路彻底僵死。这个故障现象极其难查 —— 网络「通」但什么都不动。

还有一个更隐蔽的坑：优先级映射必须端到端一致。网卡按 DSCP 打标、交换机按 PCP 匹配，两边对不上，PFC 就保护不到 RDMA 流量，表现为偶发的严重丢包和性能塌陷。

结论很实际：没有能独立调 PFC/ECN 的网络工程师，就不要在生产上碰 RoCE。宁可先用 100GbE TCP 把业务跑起来。

✓网络那一侧的完整内容在 Netpath

PFC/ECN/DCQCN 的参数细节、Fat-Tree 与 Rail-Optimized 拓扑、IB / RoCE / Spectrum-X 的选型对比，都属于网络工程师的主场，在 Netpath 里有专门的阶段讲。

这节课只覆盖存储工程师需要判断和验收的那一层：够不够用、有没有生效、出问题时该找谁。

该不该上：一份判断清单

该上：

  • 方案本身要求 —— GPFS ECE、Weka、VastData 的官方硬件要求里就写着
  • GPU 训练集群 —— 数据加载不能成为 GPU 的等待理由，且往往已经有 IB 网了
  • NVMe-oF 要做到接近本地盘的延迟

先别上：

  • Ceph 集群 —— 它的 RDMA 支持一直是实验性的，社区主流是 TCP，上了收益也有限
  • 对象存储、备份归档 —— 这类负载对延迟不敏感，带宽才是关键，TCP 足够
  • 团队里没有人能独立调无损网络 —— 这条否决前面所有理由

链路验收：先证明它是通的

拿到一套声称配好了 RDMA 的环境，按这个顺序确认：

# 1. 卡和端口在不在，状态对不对
ibstat                          # 关注 State: Active、Rate: 100
ibv_devinfo                     # 设备详情，link_layer 是 InfiniBand 还是 Ethernet
ibdev2netdev                    # RDMA 设备与内核网卡的对应关系

# 2. RoCE 还要确认 GID 索引（v2 才是可路由的那个）
show_gids                       # 选 RoCE v2 对应的 gid index

# 3. 打一发实际流量（一端起服务，另一端连）
ib_write_bw -d mlx5_0 -i 1            # 服务端
ib_write_bw -d mlx5_0 -i 1 10.68.20.2 # 客户端，看 BW average
ib_write_lat -d mlx5_0 10.68.20.2     # 看 t_avg，应该是个位数微秒

# 4. 无损是否在正常工作
ethtool -S ens1f0 | grep -iE 'pause|prio.*pause'   # pause 帧计数
ethtool -S ens1f0 | grep -iE 'ecn|congestion'      # ECN 标记计数

判读口径：

  • ib_write_lat 的 t_avg 在个位数微秒 → RDMA 确实在工作；如果是几十微秒，多半根本没走 RDMA
  • pause 帧计数缓慢增长是正常的（偶尔兜底），持续快速增长说明 ECN 没起作用，去查交换机配置
  • 带宽跑不到线速的 90%，先看 MTU 和 GID 索引，这两个是最常见的原因
Checkpoint单选

RDMA 的单边操作（READ/WRITE）相比双边（SEND/RECV）最大的价值是什么？

Checkpoint单选

生产 RoCE 网络上，PFC pause 帧计数持续快速增长。这说明什么？

Checkpoint多选

下面哪些场景值得上 RDMA？（多选）

这节课的落点

  • 盘变快之后内核协议栈成了瓶颈，RDMA 靠内核旁路 + 零拷贝把延迟和 CPU 各降一个数量级
  • 内存注册是毫秒级的昂贵操作，所以都是启动时注册一大块反复用 —— GPFS 的 pagepool 就是它
  • 单边 READ/WRITE 不打扰对端 CPU，这是 RDMA 在存储场景最值钱的性质
  • InfiniBand 靠链路层 credit 天生无损；RoCEv2 复用以太网，无损得自己造
  • 无损三件套的分工是 ECN 干活、PFC 兜底，PFC 大量触发是故障信号不是正常状态
  • PFC 配错会拥塞扩散甚至死锁，且优先级映射必须端到端一致
  • 没有能调无损网络的人，就先别上 RoCE
  • 验收看三个数：ib_write_lat 的 t_avg（个位数微秒）、带宽（线速 90%）、pause 帧增长速度

延伸资料

下一课：实验：把 RDMA 接到存储上 →