提到NVMe over Fabric，我就会想到它的几种应用场景：

1、 存储阵列到主机的网络连接（替代FC、iSCSI等）；

2、 服务器、本地NVMe存储解耦（跨机箱/JBOF），SSD存储资源池化共享；

3、 分布式存储/超融合系统内部互连？

关于上面第3点，对技术专家来说应该早有答案，而我会在下文中写出自己的理解和分析，班门弄斧还望大家多指正。

首先，我们来看看当初新闻里宣布的NVMe-oF 1.1主要特性：

• TCP transport supports NVMe-oF on current data center TCP/IP network infrastructure.
• Asynchronous discovery events inform hosts of addition or removal of target ports in a fabric-independent manner.
• Fabric I/O Queue Disconnect enables finer grain I/O resource management.
• End-to-end (command to response) flow control improves concurrency.

我想先聊下这次被正式加入规范的NVMe/TCP。

NVMe/TCP加入、网卡卸载的重要性

与之前的1.0版一样，NVMe over FC protocol (FC-NVMe) 在新规范里的篇幅还是一点点，却仍被排在3种传输协议层的头一个。原因不难想到——那就是光纤通道（Fibre Channel）存储网络的已有投资、用户群，包括SAN交换机和HBA卡等，以及相对更早、更成熟的应用，比如Dell EMC PowerMax等全闪存阵列。

NVMe over Fabric跑在RDMA协议层上可以有3种选择：iWARP、InfiniBand和RoCE，其中IB主要集中应用于HPC领域、iWARP普及的不太乐观，而RoCE的主导和领先者也是Mellanox。

上面我引用了2018年5月一篇The Register记者的采访文章《CTO观点：关于FC-NVMe与NVMe-oF的那些事儿》，当然今天的情况应该会更乐观。

上图中的PDUs是Protocol Data Units（协议数据单元）的缩写，我想这张图不用解释大家也能看懂。

根据我看到的信息，NVMe/TCP并不是在所有的网卡上都能跑出比较理想的性能。这个有点像早期的iSCSI和FCoE，纯软件支持会比较差一些，推荐使用驱动/Firmware支持NVMe/TCP硬件卸载的网卡。

在《VMware vSAN下一目标：NVMe-oF存储扩展？》中我曾列出过上面这张图，Lightbits使用一张FPGA卡来跑NVMe/TCP target和全局FTL等数据服务。这个要想大规模普及，估计离不开initiator端网卡的优化支持。

如今vSAN对NVMe-oF的支持还没有正式宣布，前文中我介绍过2种具体的技术实现方式：

- 使用RoCE连接JBOF SSD扩展柜

- 使用NVMe/TCP连接lightbits闪存“阵列”

除了vSAN之外，对于更多的分布式存储/Server SAN和超融合（HCI）而言，NVMe-oF可以被用于计算资源与存储介质（SSD盘）之间的连接吗？在解释这一点之前，我们先来看看NVMe的另外2个新特性：

Multipath和ANA（Asymmetric Namespace Access）

NVMe-oF 1.1规范似乎简单了点，除了协议本身之外没有写更多的东西，所以这部分就要参考NVMe1.4规范了。

上图是一个双控制器/双端口的NVM子系统示例，在EMC DSSD之后，使用PCIe直连服务器和存储阵列的应用估计寥寥无几，所以该子系统基本上代表了双端口NVMe SSD 和JBOF机箱的设计。比如这里的NS（NameSpace）B，就可以通过2个NVMe控制器同时提供前端访问。

系统的规模再大点，就不是只靠双端口SSD能解决了。多主机通过多个NVMe控制器来访问同一个SSD命名空间，我理解这里的Namespace就类似于传统存储的（SCSI）LUN，而控制器和NVMe盘之间应该会有PCIe Switch。

上图中Host A对NSID 1的访问就有2个路径。具体到4个Controller，可能是x86“刀片”、FPGA或者像Mellanox Bluefield、Broadcom StingrayPS1100R那样的SoC“智能网卡”。

至于什么是Asymmetric Namespace Access（ANA，非对称命名空间访问）呢？这有点让我想起了传统存储阵列的ALUA（Asymmetric LogicalUnit Access）。

如上图，我理解NVMe Controller 1和2可能位于同一模块或者机箱内，而NVMe Controller 3位于另一模块/机箱。这时如果是PCIe Fabric，虚线两边应该拥有各自的PCIe Switch，之间又有互通。举例来说，SSD Namespace B和D同时连接到3个NVMe控制器，位于左边的Controller 1和2访问性能效率应该较高，而Controller 3不是最优路径。

我注意到NS B和D被划在了一个ANA Group，这个感觉也比较像传统存储的LUN分组，包括分配/解除映射、路径策略切换、QoS等操作都可以统一发起。如果存储软件支持快照等高级特性，创建时间点一致的快照可能也会调用这个ANA Group吧。

如果用基于RDMA或者TCP以太网的NVMe Fabric，情况会比PCIe要复杂一些，毕竟系统拓扑的规模也增大了，但原理应该和上面这个基本相同。

分布式存储/超融合支持NVMe-oF的要点

最后是前面留下的那个问题，NVMe规范对SSD的管理粒度只到NameSpace，而大多数对等节点的分布式存储/超融合都需要将底层磁盘（闪存）空间打散成更小粒度的数据块，这时就需要底层有个文件系统或者类似的对象组织结构，读写时产生的跨节点数据操作一般应该是通过私有协议来实现。

那么vSAN在计划中之所以能支持NVMe-oF，应该是将计算节点与JBOF/Lightbits解耦的原因，服务器节点更像是SDS管理网关的感觉。同时带有本地盘的服务器节点也能一起组成异构集群。