NVMe over Fabric
计算、存储、网络是现代企业IT硬件基础架构的核心。基于Flash和新一代PCM固态存储的SSD正在极大的改变企业存储的格局。可以说NVMe就是针对新型的Non volatile memory而量身定制的。对于今天的应用来说，基于NVMe协议的SSD可以提供对性能、延迟、IO协议栈开销的完美优化。而对于计算和网络来说，如何能够适应这种存储上的变化，则是在NVMe协议逐渐走向成熟后需要解决的一个核心问题。一个简单的例子就是今天随便一个SSD高达几十万IOPS的随机读写性能对于今天的单机应用来说简直是过于浪费了。同时，固态存储也带来了客观上高密存储的可能性。今天的基于2.5# U.2接口的NVMe SSD可以轻易做到10TB以上的容量。如果一个服务器接入8个这样的SSD，可以实现80TB的存储容量。
解决这样问题的关键，则是通过共享机制，并将存储容量池化在多个计算节点间共享使用。显然，这与存储的虚拟化和云化以及软件定义存储的方向是吻合的。从更广泛的意义上来说，公有云和私有云正式通过了高度的共享和灵活的配置来实现成本节约，可靠性提升和便利管理。
从下面的Wikibon ServerSAN Research Project报告结果来看，基于DAS和传统的SAN，NAS的市场正在被超大规模企业云和企业Server SAN存储方式逐渐取代。而决定这种替换的速度，则是来源于新技术的可行性以及企业对于采纳这些新技术的接受程度。NVMe over Fabrics把NVMe协议在单系统时代提供的高性能、低延迟和低协议负担的优势进一步发挥到了NVMe存储系统互连结构中。在这种结构里，基于NVMeover Fabrics的主机可以通过互连结构访问到任何一个数据中心的存储节点，而这种访问是具有同样高性能、低延迟和低协议负担的优势。更加难能可贵的是，NVMe over Fabrics协议是构造在其他的传输层协议基础之上的，因此可以使用原来的传输层协议配合NVMe over Fabrics的协议实现这些优势，并不需要摒弃数据中心已经建设好的硬件环境。
在NVMe overFabrics协议诞生之前，基于SCSI的众多互联协议已经在考虑如何改善系统性能并降低CPU的负担了。iSCSI协议提供了基于IP以太网的SCSI互联协议，它仅仅依赖传统的IP网络，提供了可共享的存储方式。由于iSCSI依赖于TCP协议，并且TCP协议本身代价较大，因此它的性能在通常的配置下并不好。为了优化iSCSI的性能，扩展了iSCSIExtensions for RDMA (iSER)。iSER是面向各种RDMA传输层协议的存储协议，由于RDMA效率很高，iSER相比于iSCSI协议来说具有非常好的性能、极低的延迟和CPU使用率。但是由于iSER仍然是基于SCSI这个存储协议进行扩展的，因此在协议栈的组织上仍然受限于SCSI协议的限制，例如队列的数量、深度等。在性能达到几十万IOPS的时候仍然会有较大的协议开销。基于上述原因和出于对未来NVM存储功能要求的需要，NVMeover Fabrics协议应运而生。
NVMe over Fabrics协议定义了使用各种通用的传输层协议来实现NVMe功能的方式。在协议中所指的传输层包括了RDMA，FiberChannel，PCIeFabrics等实现方式。依据具体的传输层不同，又有不同的传输层绑定协议去具体规范每一种互联网络所具体需要实现的传输转换层实现。例如，INCITS540 Fibre Channel – Non-Volatile Memory Express (FC-NVMe)规定了对于Fiber Channel这种媒体所支持NVMeover Fabrics所必需实现的接口方式。
由于NVMeover Fabrics协议的这种灵活性，它可以非常方便地生长在各个主流的传输层协议中。不过由于不同的互联协议本身的特点不同，因此基于各种协议的NVMeover Fabrics的具体实现活跃都是不同的。一些协议本身的协议开销较大，另一些需要专用的硬件网络设备，客观上限制了NVMeover Fabrics协议在其中的推广。下表列出了一些典型的协议的优缺点。
虽然有着众多可以选择的互联方式，这些互联方式按照接口类型可分成三类：内存型接口，消息型接口和消息内存混合型接口。相应的互联类型和例子参见下图。
这些众多的传输层协议中，重点介绍一下RDMA。RDMA（RemoteDirect Memory Access）是一项古老的技术。它通过互联网络把数据直接传入某台计算机的一块存储区域，不需用到多少计算机的处理功能。普通网卡集成了支持硬件校验和的功能，并对软件进行了改进，从而减少了发送数据的复制量，但无法减少接收数据的复制量，而这部分复制量要占用处理器的大量计算周期。为充分发挥万兆位以太网的性能优势，必须消除主机CPU中不必要的频繁数据传输，减少系统间的信息延迟。从下面的图中看出，RDMA通过网络把数据直接传入计算机的存储区，降低了CPU的处理工作量。当一个应用执行RDMA读或写请求时，不执行任何数据复制。在不需要任何内核内存参与的条件下，RDMA请求从运行在用户空间中的应用中发送到本地NIC（网卡），然后经过网络传送到远程NIC。
RDMA对于NVMeover Fabrics协议的便利性体现在下面几个方面：
§ 提供了低延迟、低抖动和低CPU使用率的传输层协议。
§ 最大限度利用硬件加速，避免软件协议栈的开销。
§ 依赖于开放互联联盟组织维护的Verbs和代码库，RDMA定义了丰富的可异步访问的接口机制，这对于提高IO性能是至关重要的。
RDMA依据底层的不同，可进一步分成InfiniBand，RoCE和iWarp。它们的区别主要是底层实现协议的不同。其中InfiniBand需要依赖于专用的InfiniBand网络，因此可以提供非常好的服务质量，而RoCE和iWarp则可以基于以太网络，并使用专用的RDMANIC和Switch来实现高服务质量。RoCE的两个版本中，v2依赖于UDP/IP协议提供了在局域网中灵活的路由和拥塞控制功能；iWarp则是基于TCP协议提供了更加灵活的网络互联方式。
在各种RDMA中，定义了硬件操作的基本原语。在软件层面，需要执行RDMA操作的命令按照硬件制定的方式组织成命令请求项，并添加到位于内存中的工作队列中。硬件再依次从这些队列中取出命令开始执行；命令的执行结果会记录到一个完成队列中，这个完成队列也是处于内存中的，因此可以为软件层面感知到并进行后续处理。
由于RDMA底层实现可以使用任意一中接口方式实现详尽的功能，在每种协议背后又有众多的厂商支持，为了统一应用接口，便于软件开发人员理解和使用RDMA，每种RDMA协议定义了Verbs用于异步操作实现RDMA的语义。Verbs是一种比API更加底层的编程方式，根据使用方式的不同，可分为两类：
1、控制路径Verbs，用于管理RDMA的资源，通常需要上下文切换。例如Create，Destroy，Modify，Query，Workwith events。
2、数据路径Verbs，用于使用Handle来发送、接收数据的操作，不需要上下文切换。例如PostSend，PostReceive，PollCQ，Requestfor completion event。
而对于RDMA至关重要的远端内存空间，在RDMA协议中是通过内存区域（MR）来进行描述。定义内存区域实际上就是把这个虚拟内存锁定到物理内存中，并告诉NIC对应的关系。这样，依据MR的Key，NIC硬件可以不依赖硬件去操作数据在本地内存和远端的MR之间进行传输。
从上面关于RDMA的介绍来看，RDMA设计初衷就是为了高性能、低延迟访问远端节点的，并且它的语义非常类似本地DMA的过程，因此很自然就可以将RDMA作为NVMe协议的载体，实现基于网络的NVMe协议。但是，毕竟基于网络的传输模型与本地的PCIe传输模型还有种种差异，因此将NVMe协议拓展到互联层面需要解决一系列问题。因此，综合RDMA，FC等等各种不同传输层协议的特点，NVMExpress Inc.提出了NVMeover Fabrics协议实现了一个完整的网络高效存储协议。需要注意的是，NVMeover Fabrics协议的基础是NVMeBase specification，目前特指的版本是NVMExpress revision 1.2.1。
对于NVMeover Fabrics协议来说，要解决下面几个问题：
1、提供对于不同互联透明的消息和数据的封装格式。
2、将NVMe进行操作所需要的接口方式映射到互联网络。
3、解决互联网络的节点发现、多路径等互联引入的新问题。
针对数据封装，协议定义了一整套封装方案。与传统的NVMe协议相比，这套封装方案针对互联做了一些调整和适配。NVMe定义了一套异步的由软件驱动硬件执行相应动作的异步操作机制，发送和完成包仅仅携带必要的描述，而真正的数据和SGL描述符都是放在内存中并且由硬件通过DMA方式取得的。这是基于PCIe的DMA操作延迟很短（1us）的前提而设计的。在互联协议中，节点之间的交互时间大大增加，为了降低两个节点之间不必要的交互，发送请求可以直接携带附加的数据或SGL描述符，完成请求也可以携带需要回传的数据，节约了两者之间交互的负担。
与此同时，为了节约系统交互，在NVMeover Fabrics协议中，完成队列没有使用流控机制，因此需要接收端有足够容纳所有已经发出去的命令的完成队列空间，来容纳所有完成请求。
一次IO的传输过程如下图所示：
1、Initiator端驱动程序封装发送请求并派发给硬件。
2、Initiator端硬件将发送请求发到Target端的发送队列。
3、Target端控制器处理完成IO请求，并准备出来完成请求派发给硬件。
4、Target端硬件将完成请求发到Initiator端的接收队列。
由于发送请求和完成请求可以直接携带数据，从而降低互联中消耗的交互时间。如果不需要请求中携带数据，也可以由Target端在过程中直接从Initiator端获得相应的数据，如下图所示。
通过上述机制，NVMeover Fabrics协议实现了对于NVMe协议的命令和数据传输的扩展。普通的NVMe命令都可以通过这套机制映射，NVMe的标准命令摇身一变，就成为了互联协议的命令。不过还是有一些场景是需要特殊考虑的，为了支持这些场景，协议扩展了NVMe命令，增加了与互联相关的5个命令：Connect，PropertyGet/ Set，AuthenticationSend/ Receive。AuthenticationSend/ Receive主要用于做Initiator端和Target端的安全协议的传递，服从SPC-4。下面重点说一说Connect和PropertyGet/ Set。
在NVMeover Fabrics协议中，约定每个发送队列都与一个接收队列对应，不允许多个发送队列使用同一个接收队列。发送接收队列对是通过Connect命令来创建的。Connect命令携带有HostNQN，NVMSubsystem NQN和HostIdentifier信息，并且可以指定连接到一个静态的控制器，或者连接到一个动态的控制器。一个主机可以通过不同的HostNQN或不同的FabricPort建立到一个NVMSubsystem的多重连接。这种灵活性赋予了NVMeover Fabrics极大的灵活性。按照协议规定，同一个控制器的所有发送接收队列对既可以共享底层的互联通道，也可以分别独占一格底层互联通道，方便根据传输层的特点来进行灵活的选择。
在NVMe协议中，控制器是一个代表与主机进行沟通的接口实体。由于PCIe协议是一种树状拓扑结构，因此一旦控制器所处的PCIePort定下来后，接口所关联的控制器就完全定下来了。而对于NVMeover Fabrics协议来说，一个Fabric的Port可以嵌入多个控制器，因此根据需要不同，可以选择实现静态控制器或动态控制器。动态控制器是一种简单的模型，适用于对主机具有相同的服务特性的需求。静态控制器则适用于有不同需要的场景，Initiator可以查询了解一个FabricPort内部包含的静态控制器各自的能力，然后选择连接到指定的控制器以满足自身的需要。
在经典的NVMe协议中，PCIe空间的BAR0（BAR1）描述了一段内存空间用于对控制器进行基本的寄存器级别的配置。由于Fabrics结构没有等效的实现，因此NVMeover Fabrics协议定义了PropertyGet/ Set分别表示对于控制器端的寄存器读取和写入动作。
至此，NVMe的标准操作就完全被准确和高效地映射成互联网络所对应的使用方式了。为了能满足互联网络的发现机制，NVMeover Fabrics协议定义了发现服务，用于让Initiator主动发现NVMSubsystem和对应的可访问的名字空间。这个服务还同时用于支持多路径功能。该功能依赖于一个特殊的配置成支持发现服务的NVMeSubsystem。Initiator可以连接到该服务器并使用DiscoveryLog Page命令来获取可用的资源。
与NVMeover Fabrics协议一同发布的，还有一份在Linux平台上实现的基于RDMA和FC传输层的NVMe协议的Initiator和Target端的参考代码。这份代码不仅仅包含了协议的驱动实现，也包含了对应的CLI工具和LinuxOS集成支持。相信对整个生态圈来说这会是一个良好的开端。在刚刚落下帷幕的DCTC2016数据中心技术大会中，我们也看到了业界对于此方案的良好的兴趣。其中Broadcom高级架构师Frankie介绍了下一代NVMeOver Fabrics 存储架构、以太网控制器及SoC的设计。Xilinx的展示更加直接揭示了借助Xilinx的FPGA的硬件加速，NVMeover Fabrics在RoCE网络上提供了仅有10us的极低延迟时延。可以说，行业的热情是对于NVMeover Fabrics协议的最好的回应。可以预见，随着Flash成本的持续下降和集成密度的持续增加，随着新型基于相变存储的存储介质的出现和应用，随着业界对于闪存定义存储和存储虚拟化的需求的强化，NVMeover Fabrics必将在高性能存储以及数据中心中发挥越来越大的价值。
[1] http://www.nvmexpress.org/wp-content/uploads/NVMe_over_Fabrics_1_0_Gold_20160605.pdf
[2] http://www.snia.org/sites/default/files/ESF/NVMe_Under_Hood_12_15_Final2.pdf
[3] http://wikibon.com/server-san-explodes-2/
[4] http://www.epc.com.cn/special_report/200504/5043.html
[5] http://www.rdmaconsortium.org/
[6] https://en.wikipedia.org/wiki/NVM_Express
[7] http://www.incits.org
[8] http://dctc2016.eventdove.com/
[9] https://www.openfabrics.org/images/eventpresos/workshops2015/DevWorkshop/Monday/monday_10.pdf
[10] http://www.snia.org/sites/default/files/SDC15_presentations/networking/WaelNoureddine_Implementing_%20NVMe_revision.pdf
[11] http://www.mellanox.com/blog/tag/nvme-over-fabrics/
[12] http://www.theregister.co.uk/2015/08/18/dssd_nvme_fabric_flash_magic/
[13] http://insidehpc.com/2016/06/nvm-express-over-fabrics-specification-released/
[14] https://en.wikipedia.org/wiki/Remote_direct_memory_access