做影视免费网站违法吗,如何制作简单的宣传片,医疗网站建设模板制作,网站建设基本流程详细说明提到NVMe over Fabric#xff0c;我就会想到它的几种应用场景#xff1a;
1、 存储阵列到主机的网络连接#xff08;替代FC、iSCSI等#xff09;#xff1b;
2、 服务器、本地NVMe存储解耦#xff08;跨机箱/JBOF#xff09;#xff0c;SSD存储资源池化共享#xff…提到NVMe over Fabric我就会想到它的几种应用场景
1、 存储阵列到主机的网络连接替代FC、iSCSI等
2、 服务器、本地NVMe存储解耦跨机箱/JBOFSSD存储资源池化共享
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和ANAAsymmetric Namespace Access
NVMe-oF 1.1规范似乎简单了点除了协议本身之外没有写更多的东西所以这部分就要参考NVMe1.4规范了。 上图是一个双控制器/双端口的NVM子系统示例在EMC DSSD之后使用PCIe直连服务器和存储阵列的应用估计寥寥无几所以该子系统基本上代表了双端口NVMe SSD 和JBOF机箱的设计。比如这里的NSNameSpaceB就可以通过2个NVMe控制器同时提供前端访问。 系统的规模再大点就不是只靠双端口SSD能解决了。多主机通过多个NVMe控制器来访问同一个SSD命名空间我理解这里的Namespace就类似于传统存储的SCSILUN而控制器和NVMe盘之间应该会有PCIe Switch。
上图中Host A对NSID 1的访问就有2个路径。具体到4个Controller可能是x86“刀片”、FPGA或者像Mellanox Bluefield、Broadcom StingrayPS1100R那样的SoC“智能网卡”。
至于什么是Asymmetric Namespace AccessANA非对称命名空间访问呢这有点让我想起了传统存储阵列的ALUAAsymmetric 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管理网关的感觉。同时带有本地盘的服务器节点也能一起组成异构集群。
