NVMe over Fabrics 架构：协议栈、传输层与控制层
好，咱们今天来聊聊 NVMe over Fabrics 的架构。说实话，很多人一上来就盯着性能调优，结果出了问题根本不知道从哪查起。我个人的习惯是，先把这个架构吃透，后面遇到问题才能一眼看穿。
NVMe over Fabrics 说白了，就是把本地 NVMe 的协议，通过某种网络给“拉长”了。你想想看，本地 NVMe 走的是 PCIe 总线，速度快、延迟低，但距离有限。一旦我们要把存储放到远端，就得想办法让 NVMe 的命令和数据，能在以太网、光纤通道或者 InfiniBand 上跑起来。
这个架构分三层：协议栈、传输层、控制层。咱们一层一层剥开来看。
NVMe over Fabrics 协议栈
协议栈是 NVMe over Fabrics 的骨架。它定义了命令怎么封装、怎么传输、怎么应答。我刚开始接触的时候，觉得这东西跟本地 NVMe 差不多，后来才发现，坑全在细节里。
NVMe over Fabrics 的协议栈，从上到下大概是这样的：
- NVMe 命令集：跟本地 NVMe 一样，有 Admin 命令和 I/O 命令。Admin 命令用来管理控制器，比如创建删除队列；I/O 命令就是读写数据。
- NVMe over Fabrics 协议映射层：这一层负责把 NVMe 命令映射到具体的传输层上。不同的传输层（比如 TCP、RDMA、FC）有不同的映射方式。
- 传输层：负责实际的数据传输。可以是 TCP、RDMA（RoCE、InfiniBand）、或者 Fibre Channel。
- 物理层：网卡、线缆、交换机这些硬件。
核心要点：NVMe over Fabrics 不是重新发明了一套协议，而是在 NVMe 协议的基础上，加了一层“Fabrics 映射”。这层映射决定了命令怎么打包、怎么拆包。
我记得有一次，一个同事问我：“为什么 NVMe over Fabrics 的延迟比 iSCSI 低那么多？” 我告诉他，因为 NVMe 的命令集本身就比 SCSI 精简，再加上 Fabrics 映射层几乎不做额外处理，直接就把命令丢给传输层了。说白了，就是“少了一层中间商”。
NVMe over Fabrics 传输层
传输层是 NVMe over Fabrics 的“血管”。它决定了数据怎么从主机端跑到存储端。目前主流的传输层有三种：
| 传输层类型 | 特点 | 适用场景 |
|---|---|---|
| TCP | 基于标准以太网，无需特殊硬件，兼容性好 | 通用场景、跨数据中心、低成本部署 |
| RDMA (RoCE/InfiniBand) | 低延迟、低 CPU 开销，需要 RDMA 网卡 | 高性能计算、延迟敏感场景 |
| Fibre Channel | 传统 SAN 网络，稳定可靠，需要 FC 交换机 | 现有 FC 存储环境升级 |
这里我想重点聊聊 TCP 和 RDMA 的选择。很多人在选型的时候会纠结，我个人的建议是：
- 如果你的网络已经部署了标准以太网，而且对延迟不是特别敏感（比如几十微秒能接受），那 TCP 完全够用。我在项目中遇到过，用 25GbE 跑 NVMe over TCP，延迟大概在 30-50 微秒，对于大多数业务来说已经非常好了。
- 如果你追求极致性能，比如延迟要控制在 10 微秒以内，那 RDMA 是必须的。但要注意，RDMA 的部署和维护成本比 TCP 高不少。我曾经帮一个客户调优 RoCE 网络，光是 PFC 流控就折腾了两周。
我的经验：对于初次部署 NVMe over Fabrics 的团队，我建议先从 TCP 开始。等跑通了，再考虑升级到 RDMA。这样能避免一开始就被复杂的网络配置劝退。
传输层还有一个关键点：队列模型。NVMe over Fabrics 沿用了本地 NVMe 的“多队列”设计。每个队列对（Submission Queue + Completion Queue）可以独立处理 I/O 请求。这意味着，你可以为每个 CPU 核心分配一个队列对，实现真正的并行处理。
为什么会这样？因为 NVMe 的设计初衷就是充分利用现代多核 CPU 的并行能力。你想想看，如果所有 I/O 都挤在一个队列里，那 CPU 核心之间就得互相等待，性能就上不去了。
NVMe over Fabrics 控制层
控制层是 NVMe over Fabrics 的“大脑”。它负责管理连接、处理错误、协调资源。这一层做的事情，说白了就是“让主机和存储能好好说话”。
控制层主要包含以下几个部分：
- 连接管理：主机怎么发现存储设备？怎么建立连接？怎么断开连接？这些都是控制层的事。
- 错误处理：网络断了怎么办？命令超时了怎么办？控制层要能优雅地处理这些异常。
- 资源管理：队列怎么分配？内存怎么注册？这些资源的管理也在控制层。
嗯，这里要注意一个概念：NVMe over Fabrics 的控制器模型。在 NVMe over Fabrics 中，主机端叫 Initiator，存储端叫 Target。Target 上运行着一个或多个 NVMe 控制器。每个控制器可以管理多个命名空间（Namespace）。
我曾经遇到过一个坑：某个客户在部署 NVMe over Fabrics 时，发现主机只能看到部分命名空间。排查了半天，原来是 Target 端的控制器配置有问题，没有把所有命名空间都暴露给主机。从那以后，我每次部署都会先检查控制器的命名空间映射。
避坑指南：我曾经因为忽略了控制层的“心跳机制”，导致生产环境出现大规模断连。NVMe over Fabrics 的控制层有一个 Keep Alive 机制，用来检测连接是否正常。如果这个超时时间设置得太短，网络稍微抖动一下就会断连。建议根据实际网络质量，把 Keep Alive 超时时间设置在 5-10 秒。
控制层还有一个重要的功能：多路径。在 NVMe over Fabrics 中，主机可以通过多条路径访问同一个命名空间。这不仅能提高带宽，还能实现故障切换。控制层负责管理这些路径，决定哪条路径是主路径，哪条是备路径。
我建议你在部署多路径时，一定要测试故障切换的场景。比如，拔掉一根网线，看看 I/O 会不会中断。很多人在实验室里觉得没问题，一上生产就出幺蛾子。
架构总览
说了这么多，咱们用一张图来总结一下 NVMe over Fabrics 的架构：
这张图把整个架构串起来了。你看，主机端和存储端是对称的，中间通过网络连接。控制层贯穿始终，负责协调一切。
最后，我想说一句：NVMe over Fabrics 的架构设计其实非常优雅。它没有引入太多复杂的概念，而是在现有 NVMe 协议的基础上，做了恰到好处的扩展。你只要把协议栈、传输层、控制层这三层搞明白，后面不管是调优还是排错，都会轻松很多。
总结一下：
- 协议栈：NVMe 命令 + Fabrics 映射 + 传输层 + 物理层
- 传输层：TCP 适合通用场景，RDMA 适合高性能场景，FC 适合传统 SAN
- 控制层：管连接、管错误、管资源、管多路径
嗯，架构这部分就先聊到这儿。记住，理解架构是第一步，后面咱们再深入具体的部署和调优。