NVMe over Fabric诞生及发展(协议细节及市场现状篇)

来源:互联网 发布:淘宝怎么查虚假交易 编辑:程序博客网 时间:2024/03/29 03:42

经过《NVMe over Fabric诞生及发展》及《NVMe over Fabric诞生及发展——RDMA篇》两篇文章,NVMe over Fabric的发展背景和与之密切相关的RDMA已经介绍完毕,这篇文章将深入NVMe over Fabric内部,探究其设计思路及其规范下一个IO的传输过程。对于NVMe over Fabrics协议来说,要解决下面几个问题:

  1. 提供对于不同互联透明的消息和数据的封装格式;
  2. 将NVMe进行操作所需要的接口方式映射到互联网络;
  3. 解决互联网络的节点发现、多路径等互联引入的新问题。
针对数据封装,协议定义了一整套封装方案。与传统的NVMe协议相比,这套封装方案针对互联做了一些调整和适配。NVMe定义了一套异步的由软件驱动硬件执行相应动作的异步操作机制,发送和完成包仅仅携带必要的描述,而真正的数据和SGL描述符都是放在内存中并且由硬件通过DMA方式取得的。

这是基于PCIe的DMA操作延迟很短(1us)的前提而设计的。在互联协议中,节点之间的交互时间大大增加,为了降低两个节点之间不必要的交互,发送请求可以直接携带附加的数据或SGL描述符,完成请求也可以携带需要回传的数据,节约了两者之间交互的负担。


与此同时,为了节约系统交互,在NVMe over Fabrics协议中,完成队列没有使用流控机制,因此需要接收端有足够容纳所有已经发出去的命令的完成队列空间,来容纳所有完成请求。

一次IO的传输过程如下图所示:


  1. Initiator端驱动程序封装发送请求并派发给硬件;
  2. Initiator端硬件将发送请求发到Target端的发送队列;
  3. Target端控制器处理完成IO请求,并准备出来完成请求派发给硬件;
  4. Target端硬件将完成请求发到Initiator端的接收队列。
由于发送请求和完成请求可以直接携带数据,从而降低互联中消耗的交互时间。如果不需要请求中携带数据,也可以由Target端在过程中直接从Initiator端获得相应的数据,如下图所示。


通过上述机制,NVMe over Fabrics协议实现了对于NVMe协议的命令和数据传输的扩展。普通的NVMe命令都可以通过这套机制映射,NVMe的标准命令摇身一变,就成为了互联协议的命令。不过还是有一些场景是需要特殊考虑的,为了支持这些场景,协议扩展了NVMe命令,增加了与互联相关的5个命令:Connect,Property Get/ Set,Authentication Send/ Receive。Authentication Send/Receive主要用于做Initiator端和Target端的安全协议的传递,服从SPC-4。下面重点说一说Connect和Property Get/ Set。

在NVMe over Fabrics协议中,约定每个发送队列都与一个接收队列对应,不允许多个发送队列使用同一个接收队列。发送接收队列对是通过Connect命令来创建的。Connect命令携带有Host NQN,NVM Subsystem NQN和Host Identifier信息,并且可以指定连接到一个静态的控制器,或者连接到一个动态的控制器。

一个主机可以通过不同的Host NQN或不同的Fabric Port建立到一个NVM Subsystem的多重连接。这种灵活性赋予了NVMe over Fabrics极大的灵活性。按照协议规定,同一个控制器的所有发送接收队列对既可以共享底层的互联通道,也可以分别独占一格底层互联通道,方便根据传输层的特点来进行灵活的选择。


在NVMe协议中,控制器是一个代表与主机进行沟通的接口实体。由于PCIe协议是一种树状拓扑结构,因此一旦控制器所处的PCIe Port定下来后,接口所关联的控制器就完全定下来了。而对于NVMe over Fabrics协议来说,一个Fabric的Port可以嵌入多个控制器,因此根据需要不同,可以选择实现静态控制器或动态控制器。

动态控制器是一种简单的模型,适用于对主机具有相同的服务特性的需求。静态控制器则适用于有不同需要的场景,Initiator可以查询了解一个Fabric Port内部包含的静态控制器各自的能力,然后选择连接到指定的控制器以满足自身的需要。

在经典的NVMe协议中,PCIe空间的BAR0(BAR1)描述了一段内存空间用于对控制器进行基本的寄存器级别的配置。由于Fabrics结构没有等效的实现,因此NVMe over Fabrics协议定义了Property Get/ Set分别表示对于控制器端的寄存器读取和写入动作。

至此,NVMe的标准操作就完全被准确和高效地映射成互联网络所对应的使用方式了。为了能满足互联网络的发现机制,NVMe over Fabrics协议定义了发现服务,用于让Initiator主动发现NVM Subsystem和对应的可访问的名字空间。这个服务还同时用于支持多路径功能。该功能依赖于一个特殊的配置成支持发现服务的NVMe Subsystem。Initiator可以连接到该服务器并使用Discovery Log Page命令来获取可用的资源。

与NVMe over Fabrics协议一同发布的,还有一份在Linux平台上实现的基于RDMA和FC传输层的NVMe协议的Initiator和Target端的参考代码。这份代码不仅仅包含了协议的驱动实现,也包含了对应的CLI工具和Linux OS集成支持。相信对整个生态圈来说这会是一个良好的开端。

在刚刚落下帷幕的DCTC2016数据中心技术大会中,我们也看到了业界对于此方案的良好的兴趣。其中Broadcom高级架构师Frankie介绍了下一代NVMe Over Fabrics 存储架构、以太网控制器及 SoC的设计。Xilinx的展示更加直接揭示了借助Xilinx的FPGA的硬件加速,NVMe over Fabrics在RoCE网络上提供了仅有10us的极低延迟时延。

可以说,行业的热情是对于NVMe over Fabrics协议的最好的回应。可以预见,随着Flash成本的持续下降和集成密度的持续增加,随着新型基于相变存储的存储介质的出现和应用,随着业界对于闪存定义存储和存储虚拟化的需求的强化,NVMe over Fabrics必将在高性能存储以及数据中心中发挥越来越大的价值。

0 0
原创粉丝点击