众说纷纭:NVMe over Fabrics阵列到底属不属于SAN?

存储 存储设备
SAN是什么,NVMe over Fabrics(简称NVMeF)阵列又是否属于SAN?Datrium公司表示否定,而E8方面则在一定程度上表示肯定。

SAN是什么,NVMe over Fabrics(简称NVMeF)阵列又是否属于SAN?Datrium公司表示否定,而E8方面则在一定程度上表示肯定。

根据维基百科的解释,SAN全称为存储区域网络,是指“一套能够为统一块级数据存储提供访问的网络……SAN并不提供文件抽象机制,而仅提供数据块级操作; 不过SAN之上的文件系统仍然能够实现文件级访问,此类系统被称为共享磁盘文件系统。”

Techopedia则解释称:“存储区域网络(简称SAN)属于一套安全高速数据传输网络,负责面向统一块级存储提供访问能力。SAN能够使得多台服务器访问同一存储设备网络。”

看起来概念非常简单,但NVMeF阵列却存在一项影响性特质。

[[195623]]

Techterms指出,“SAN属于一套能够为多台计算机所访问的存储设备网络。网络中的每台计算机皆可访问SAN中的磁盘驱动器,但前提是其属于直接接入该计算机的本地磁盘。”

这种方式允许各磁盘驱动器供多台计算机使用,从而简化不同设备之间的信息共享流程。

对于Datrium公司来说,这正是主要问题所在。该公司联合创始人兼CTO Hugo Patterson在接受采访时解释称,“共享机柜内的NVMe看似一种内部驱动器——因此其无法实现数据共享。这并不属于SAN。大家无法在此之上支持VMFS(即VMware文件系统)。”

[[195624]]

Datrium公司CTO Hugo Patterson

他进一步指出,SAN用户能够实现数据、驱动器以及存储机柜的共享。但NVMeF阵列用户却无法进行数据或者驱动器共享。为什么会这样?

这种想法源自在计算机、客户设备或者服务器当中安装本地驱动器。其仅归属于所在主机,而无法被其它计算机所访问。通过NVMe驱动程序实现的PCIe接入SSD就属于此类作法。

而随着NVMeF的出现,NVMeF阵列内的主机服务器与驱动器之间建立起一条远程直接内存访问连接。其中主机服务器会将该远程驱动器视为另一块本地驱动器,且二者之间相互完成分配与映射。除此之外,没有其它服务器会访问该驱动器——意味着其它服务器无法访问该驱动器上的数据。

那么,让我们对此类驱动器进行抽象,并添加其它一些驱动器/分卷管理器。在这里,我们将其湢至阵列控制器当中; 其能够查看全部驱动器并接收一切IO请求。但如果要通过端到端NVMeF实现,则意味着延迟会持续提升而IO操作时耗更长,NVMeF原本维持本地驱动器访问速度不变的要求当然无法实现,而控制器也将如Datrium发布的演示文稿所说成为其中的性能瓶颈。

如果大家能够通过NVMeF直接让主机服务器访问该阵列上的驱动器,则这套阵列在实际上即属于无控制器类别——或者简称JBOF,即简单闪存捆绑。Datrium为此绘制了以下图示:

Datrium公司支持NVMe驱动器,但却并没有在自家产品线中推出NVMeF阵列。该公司指出,内置有NVMeF的阵列并不能解决主机-阵列网络延迟这一难题。

E8公司的观点

Datrium方面并不具备NVMeF阵列,但另一方面初创企业E8则拥有此类产品——这是一套双端口NVMeF JBOF,配备24块6.4 TB SSD。那么在E8公司眼中,NVMeF阵列或者说JBOF是否属于SAN?

该公司创始人兼CEO Zivan Ori指出,“对于这类与光纤通道及SCSI有所关联的SAN,我将其称为NVMeF。这是一种SAN的替代方案或者可以称作下一代SAN。我认为将其称为SAN可能会引起误解。”

在他看来,双控制器阵列无法获得如NVMeF般的竞争优势,除非其具备能够驱动RDMA链接的直连服务器。但在不具备直连服务器的情况下,其无法介入RDMA路径而只能使用阵列控制器堆栈,这无疑会造成额外的延迟提升。Ori认为这正是Pure公司将要面临的重要问题之一。

那么如果E8的客户希望在E8 JBOF当中共享数据,又该如何实现?集群化文件系统正是一个可能的答案,他同时亦提到可以提供一套运行有SAS统计分析应用程序的数据仓库。在安装E8系统之前,SAS应用程序运行在配备有本地NVMe SSD的服务器之上:

但在安装GPFS——即IBM的Spectrum Scale并行文件系统软件——以替代XFS之后,各SAS节点将能够以并发方式实现指向 E8共享NVMe存储的IO访问。

分配控制器级智能

E8公司的系统在每台访问服务器当中设置一个代理,具体如下图左侧所示:

有趣的是,Datrium公司也拥有类似的概念——其在阵列分布式上游内提供面向访问服务器的控制器逻辑。该公司认为,必须要利用这样的访问服务器逻辑方可在NVMe JOBF环境当中提供存储阵列控制器型功能:

以上Datrium演示提出的最后结论在于:“服务器支持型数据管理必须具备更多功能。”

根据我们的理解,这里所指的是原本依靠阵列控制器实现的分卷控制类功能必须在访问服务器中以其它形式实现,而后再由该服务器对NVMeF IO请求加以处理。

另外,当有多台服务器同时访问NVMeF JBOF时,这一分卷管理功能还应当能够在各访问服务器上进行分布,从而协调具体数据访问操作。

Datrium公司此前曾经通过七页演示文稿解释了为何NVMeF JBOF并不属于数据共享SAN,百我们怀疑该公司也许正在开发能够解决这一难题的技术方案。毕竟,如果仍然没有解决办法,其为什么要大费周章地拿出七页演示进行说明?

责任编辑:武晓燕 来源: ZDNet存储
相关推荐

2010-05-12 10:53:05

Java

2014-06-27 09:35:16

机器学习

2010-01-21 15:02:25

2021-04-19 14:28:28

NVMe存储协议

2009-07-22 17:28:14

移动应用商店

2015-09-21 15:41:25

2013-02-25 14:29:31

移动广告挑战

2018-05-29 10:40:08

人工智能AR技术

2012-02-06 23:29:11

2010-11-25 10:48:12

跳槽

2010-04-22 18:06:19

IT人云计算下一代数据中心

2017-09-25 10:36:20

NVMe Over F存储DAS

2015-03-18 10:02:17

移动产业

2017-07-13 13:00:41

数据库Oracle损坏块

2021-08-07 22:16:00

程序员互联网工资

2018-08-17 14:41:21

2020-01-10 10:09:50

程序员技能开发者

2022-11-29 07:59:51

NVMe网络技术

2021-02-26 15:03:01

RAID磁盘阵列

2012-05-03 08:06:39

Windows 7分区
点赞
收藏

51CTO技术栈公众号