企业存储技术 · 2020年06月11日

NVMe-oF 1.1规范:多路径、非对称命名空间和NVMe/TCP

本文内容非商业用途可无需授权转载,请务必注明作者及本微信公众号,以便更好地与读者互动。

引言:总体感觉,NVMe就是在不断引入传统存储SCSI的特性,那么它和分布式存储/超融合又能碰撞出什么火花呢?

今天给大家分享的是NVMe-oF 1.1规范,看下面的图有朋友可能会问:这不是去年10月的文档吗?不错,早在去年7月24日NVMe 1.4规范正式公布时,NVMe-oF 1.1 Specification就进入了45天的批准期,然而直到近几天我才从nvmexpress.org组织官网上下载到它。

image.png

百度网盘分享链接 https://pan.baidu.com/s/1JYJO...\_oSz9QVw

(附NVM Express 1.4__和NVM Express Management Interface 1.1__另外2__个文档)

提到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 over TCP:iSCSI的接班人?_》

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

image.png

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

image.png

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

image.png

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

image.png

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

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

image.png

在《_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规范了。

image.png

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

系统的规模再大点,就不是只靠双端口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)。
image.png

如上图,我理解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,而大多数对等节点的分布式存储/超融合都需要将底层磁盘(闪存)空间打散成更小粒度的数据块,这时就需要底层有个文件系统或者类似的对象组织结构,读写时产生的跨节点数据操作一般应该是通过私有协议来实现。

image.png

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

image.png

此时,我又想起了传统存储的Scale-up和Scale-out...

推荐阅读

本文转载自企业存储技术微信公众号,[原文链接点这里]。
注:本文只代表作者个人观点,与任何组织机构无关,如有错误和不足之处欢迎在留言中批评指正。 进一步交流技术可以加我的微信/QQ:490834312。
尊重知识,转载时请保留全文,并包括本行及如下二维码。感谢您的阅读和支持!《企业存储技术》微信公众号:HL_Storage,也欢迎关注企业存储技术极术专栏,定期更新。
42.jpg
推荐阅读
关注数
5613
内容数
260
关注存储、服务器、图形工作站、AI硬件等方面技术。WeChat:490834312
目录
极术微信服务号
关注极术微信号
实时接收点赞提醒和评论通知
安谋科技学堂公众号
关注安谋科技学堂
实时获取安谋科技及 Arm 教学资源
安谋科技招聘公众号
关注安谋科技招聘
实时获取安谋科技中国职位信息