提到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管理网关的感觉。同时带有本地盘的服务器节点也能一起组成异构集群。