本周二（12月5日），在北京朝阳悠唐皇冠假日酒店召开的2017中国存储峰会上，张广彬和曾智强代表企事录技术服务公司发表了题为《网络存储“相对论》的演讲，分享了最近测试高性能存储和网络的一些实践。以下为演讲实录。
连续好几年在存储峰会的技术论坛上开场，以前讲的都比较概念趋势性一些。今天主要讲的不是概念，而是我们最近在一些新技术上的探索和实践。这一场将会由我和我的同事曾智强共同来完成，我先讲前面的这一部分。
我们企事录服务公司，主要致力于新技术、新产品的市场教育，手段通常是分析和测试。分析方面我和曾智强在几年前写过技术分析报告《数据中心2013》，率先提出“硬件重构+软件定义”的理念，并据此展开对前沿技术的解析，这几年行业确实在向着这个方向前进，我们也在这个方向上去践行理念，特别是指导我们的测试工作。这里列出了企事录与几家业内知名企业合作的联合实验室，本次的NVMeoF测试就主要在和青云合作的混合云实验室进行。
这个“相对论”当然只是取一下（爱因斯坦）相对论字面上的意思，网络和存储一定程度上是相对的概念，是可以互相替代的。十多年前听华中科技大学谢长生教授打过一个比喻——信息的传输，可以在空间维度，和时间维度上进行：比如烽火台，把敌人入侵的信号通过烽火台传递到很远的地方，这是在空间维度上的传输；另外一种在时间维度上的传输，比如刻一个碑，几百年甚至几千年以后，这个碑没有损坏，大家还是可以看到记录下来的信息。前者就是网络，后者就是存储，我觉得这个很有启发。
两者结合起来，就是网络存储？当然，我们也可以更抽象的想一想，譬如1968年上映的科幻电影《2001太空漫游》，里面有一个宇宙高智慧结晶的代表，就是黑石，有好事者演算过这个黑石可以存储多少数据，而它还能够自由移动，穿越时空，兼具网络和存储的特性。
十多年前的网络存储，跟现在不一样，专有的存储硬件架构，专有的存储网络（Fibre Channel）。但从使用的角度，通过网络去访问，其实跟访问本地的硬盘，看起来没什么区别。现在我们讲软件定义存储（SDS）和超融合（HCI），软件定义存储的主流是分布式的，在通用服务器上，分布到多个节点来运行，用服务器集群来提供服务。存储和计算分离的场景，两个集群之间的网络显然是可见的，使用和部署的时候可以明显感受到。而超融合，把计算和存储放到了一起，计算看起来访问的是本地存储资源，但实际上也可能是通过网络跨节点访问，它的网络不是很明显，但实际上各个节点之间，也是通过网络才成为一个整体。
超融合是这几年企业级市场上很火的一个概念，我在去年的存储峰会上也讲过《超融合架构的“逆流”？》（存储峰会演讲实录）。超融合当然有很多的优点，最大的优点就是部署简单，这对大型企业，和中小型企业都是适用的。但是，超融合架构更多的适用于中小规模的部署。具体的例子如微软的Azure Stack，微软混合云蓝图中私有云的部分，与Cisco、华为、联想、Dell、HPE的服务器硬件，整合成软硬件一体的解决方案交付。一个集群最少4个节点，最多可以达到12个节点，下一步16个节点，这是典型的超融合部署。
超融合部署的另外一个优势是，利用计算和存储一体的特点，可以把计算节点经常访问的数据，就近放在所在的节点本地，尽量避免跨网络访问。这在网络状况不太好的时候，有很好的效果。如图所示，超融合市场的开创者Nutanix就提供这个功能。
公有云上也有类似的例子，譬如阿里云的第一代块存储是2010年做的，当时阿里云尚处于起步阶段，用的网络还是千兆以太网，就利用超融合的部署方式，来降低网络性能的不利影响。
我们后面也会提到，现在高速的存储，譬如NVMe和3D XPoint这种低延迟存储的出现，存储性能大幅提升以后，网络性能如果跟不上来的话，可以用类似的数据本地化的方法，譬如微软的S2D（Storage Spaces Direct），或者VMware vSAN，都有计划加入数据本地化的功能。
刚才说到阿里云，实际上超融合架构在大型云计算环境下的一个问题，就是计算和存储资源紧耦合的方式不够灵活。譬如阿里云上线了一个集群，可能计算资源很快卖空了，但存储资源还剩很多，那这就是很不经济的一种做法。所以阿里云从第二代块存储技术开始，就采用了计算和存储分离的方式，包括到现在的第三代也是采用分离部署的方式。
另一个例子是AWS的EBS。EBS主要为EC2计算实例服务，AWS有很多类型的EC2实例，C开头的是计算优化的实例，前不久推出了最新一代的C5实例。AWS起步比较早，其虚拟化采用的是Xen，但是最新的一代C5转向了KVM。上周的re:Invent 2017大会上，AWS为了介绍C5，把以前几代实例的计算和存储架构都大致回顾了一下。
这张是C3实例的架构图，左边是硬件架构，右边是软件架构，画出了对应的映射关系。很多IaaS公有云的实例都有本地存储的选项，本地存储的问题在于，其就在实例（通常是VM）所在的物理主机上，如果云主机重启或迁移，本地存储的数据就会丢失。所以本地存储虽然快，但并不被视为持久化存储。持久化的块存储，于AWS就是EBS（Elastic Block Storage，弹性块存储），黄色的虚线框里就是EBS，是一个共享的存储，通过网络访问。从图上的架构可以看到，存储和网络一样，通过网络来访问。这就可以看到C3实例在存储架构上的问题：存储的流量和网络的流量，没有有效的区隔，所以存储的性能可能无法保证。
从2013年底到2015年初，过了一年多，AWS升级到了C4实例。黄色虚线框里还是EBS，注意存储的访问路径，已经和网络区隔开了，所以C4实例的EBS存储，性能和QoS有保证。这也说明了网络和存储的一些联系：有时候存储的变化，实际上是网络的变化。
这是我画的一个图，横轴是时间线，纵轴是SSD或HDD（硬盘）的大致数量。可以看到这是一个发展的曲线，左下角的是已经发生的事情。我们原来为什么会有磁盘阵列？因为硬盘性能太差了，所以要把很多硬盘堆在一起，形成磁盘阵列提供更高的性能（有时是更大的容量）。随着SSD的逐渐发展，刚开始用SSD给硬盘当缓存，使用服务器内置存储，SSD加HDD组成缓存或分层的方案，还可以是纯SSD（全闪存），就可以满足应用的需求。
由于SSD的加入提高了存储的性能，服务器本地的存储就能满足所承载应用的存储性能需求，所以我们可以做成超融合的方案。这个黄色的圆圈的意思是，前几年到未来几年的这个时间区域内，服务器内置存储可以用超融合的方案，一个服务器有10几20几个硬盘或SSD（SSD+HDD或者全闪）。
但是，随着NVMe SSD逐渐普及，以及服务器本身能支持的SSD数量进一步增加，可能又会往另外一个方向变化：一台服务器装满了SSD以后，本地的计算能力（运行的应用负载）已经不能完全发挥SSD的全部性能，所以又要把SSD放到单独设备里面，把存储独立出来，供很多主机访问，还有更高的灵活性。所以往右上角发展，比如说几百片闪存放在一起，甚至将来有可能会上千个闪存放在一起。就像这张NVMe over Fabrics（NVMeoF）规划的远景，将来可以支持千个级别的SSD。NVMe over Fabrics现在已经走向了一些原型阶段，或者是有一些产品出来了。
NVMe over Fabrics要解决的是，计算和存储分离了以后，距离没有产生美，带来的却是带宽和延迟上的挑战。怎么解决这个挑战，接下来的这一部分，有请我们企事录负责测试的合伙人曾智强来讲一讲这方面的情况。
大家好，我是曾智强，我在企事录主要负责（新）技术、产品及解决方案的评估和验证。闪存的出现，确实加大了对存储网络的挑战。业内已经开始着手解决网络的问题，比如NVMe over Fabrics，我们也对NVMeoF做了一些探索和尝试，取得一些成果，今天就给大家分享一下企事录在NVMe over Fabrics方面获得的一些实践经验。
说到NVMe over Fabrics，这是NVMe over Fabrics的一个总体架构示意图。NVMe实际上一个寄存器级的逻辑接口，专为SSD等非易失性存储开发，数据传输通常在PCIe之上。所以在NVMe over Fabrics 1.0规范里面，把NVMe SSD比作是NVMe over PCIe，既然是over在PCIe上面，那是不是也可以over在其他的网络上？比如说企业数据中心最常用的Fibre Channel（FC），或者更常见的以太网，乃至其他更高速的网络上？比如InfiniBand（IB）。InfiniBand和新一代以太网有一个非常好的功能即RDMA（Remote Direct Memory Access，远程直接内存访问），可以有效降低软件层导致的延迟。InfiniBand的带宽一向很高（40Gbps以上），现在以太网的带宽也很高，比如新一代的25GbE，以及100GbE，而且也支持RDMA功能，比如RoCE（RDMA over Converged Ethernet）或iWARP（internet Wide Area RDMA Protocol）。这不仅能显著降低延迟，也有助于提升带宽。
中间红色部分，就是支持RDMA的软件堆栈，包括InfiniBand和以太网，最右边粉色部分，实际上就是Fibre Channel。NVMe over PCIe或者NVMe SSD上的访问规则是由NVMe规范来定义的。
NVMeoF实际是基于NVMe 1.2规范，对协议层进行了扩展。这张图就是NVMeoF的架构，可以看到，其实是在NVMe协议中的NVMe Transport进行了扩展，用以支持InfiniBand和以太网，以及Fibre Channel等等。
从规范来看，NVMe over Fabrics实际上有两种模式，第一个是Memory模式，所有的NVMe SSD就是使用这种模式；另外就是Message模式，通过对NVMe命令进行再次封装，以此实现在其他网络上传输，如果在Fibre Channel上传输的话就使用message模式。此外，比较例外的就是RDMA上，支持RDMA功能实际上有InfiniBand和以太网，而以太网又有RoCE和iWARP两种。NVMe over Fabrics都是支持的，并且memory模式和message都能用在RDMA上。
从逻辑架构上看的话，NVMe over PCIe和NVMe over RDMA上，在软件开销上的增加很小，可以近似的认为跨网络访问和本地访问的延迟几乎是一样的。所以如果用RDMA的话，虽然经过了网络，但其延迟可以非常接近于本地的水平。为了验证NVMe over Fabrics，我们在企事录和青云联合的混合云实验室里设计了一个测试方案。
图上就是测试部署的架构，围绕数据库应用构建的一个典型应用场景。之所以选择数据库应用，是因为数据库对延迟的要求比较高，而Oracle数据库也可以被认为是最关键的企业应用之一。最上面的是Oracle数据库服务器，配备的Intel双路Xeon Platinum 8180处理器，是Intel新一代（SkyLake）处理器中最顶配的型号，配置了256GB内存。这台服务器上一共插了3张网卡，其中一张是Mellanox的CX5网卡，这是一张100Gb/s的网卡；另外两张则是Mellanox的CX3网卡，是10Gb/s的。这三张网卡都支持RDMA功能，也就是RoCE。
Oracle数据库服务器通过两台交换机与最下面的存储服务器相连。右边这台就是100Gb/s交换机，是Mellanox提供的SN2100；左边是Mellanox SX1024交换机，是10Gb/s交换机。最下面的是存储服务器，采用Intel双路Xeon Gold 6154处理器，这是一款高主频的处理器，适合驱动高性能的NVMe SSD，作为存储服务器，也配置了256GB内存。与Oracle数据库服务器一样，也有一张100Gb/s和两张10Gb/s的Mellanox网卡。在存储方面，使用了4个U.2接口的Intel DC P4500SSD，每片SSD的容量是2TB。同时还使用了1片750GB的Intel DC P4800X，这就是传说中的Optane，采用3D XPoint技术，一种全新介质的SSD。
这里要特别感谢一下海天起点公司提供的技术支持。海天起点是一家专注于提供数据库服务的公司，在Oracle数据库的运维、优化和排错方面有着非常丰富的经验。之前讲过，我们这个测试是以Oracle数据库应用来构建的，之所以与海天起点合作，也是需要借助他们的经验来验证Oracle数据库在NVMeoF下的性能表现。同时，他们也非常关注NVMeoF，也希望跟我们一起探索，所以我们一拍即合，做了这个测试。
下面我们来看一下测试方面的情况。这张图展示了在不同接口的大致带宽，比如SATA、10GbE、25GbE、NVMe以及100GbE，我们看到，其带宽基本是以倍数增长的。其中有一项是主流NVMe SSD的带宽，采用PCIe x4通道，实际能达到的带宽大约在3.2GB/s左右。而100GbE的带宽大约在10GB/s左右，差不多是3片NVMe SSD相加的带宽，所以在这个测试里面，我们使用了4片NVMe SSD，以确保存储总带宽超过网络，如下表。
这个表是Intel DC P4500 SSD的性能参数，单片SSD大约能提供51.5万IOPS，这是一个稳定状态下的值。而我们拿到的是全新的SSD，所以在测试的时候，有一定的误差，单片SSD的随机读性能大约是54万IOPS，两片P4500的性能大约在100万左右，4片则在185万左右。单片P4500的带宽在3.2GB/s，随着SSD数量的增加，其带宽基本是线性增长的。
下面我们来看一下在实际测试中的情况。在10GbE iSCSI情况下，其随机读写的性能大约是6万IOPS和5万IOPS。需要注意的是，我们这儿采用的测试是Oracle数据库典型的8KB数据块。然后开启RDMA，也就是使用NVMeoF之后，10GbE的随机读写性能几乎能够翻倍，超过了13.5万IOPS。从图上可以看到，随机写与随机读的性能差不多，与我们的常识相悖——基于NAND Flash的SSD，写性能是要弱于读性能的。这是因为10GbE的带宽已经是瓶颈了，连1片P4500的性能极限都达不到，所以读写性能相差无几。
最后则是100GbE NVMeoF下的性能，随机读写性能为120万和60万IOPS，分别是10GbE iSCSI下的20倍和12倍。可见100GbE的优势非常明显，能够有效地提升NVMe SSD的性能表现。
接下来是在带宽方面的性能表现，我们使用的是64KB数据块进行顺序读写。在10GbE iSCSI情况下，其带宽约为1.2GB/s，在NVMeoF下，其带宽差不多，都在1.2GB/s左右，10GbE的带宽已经成为瓶颈。而在100GbE的NVMeoF下，其顺序读带宽提升了将近10倍，达到了11GB/s；写带宽也提升了5倍，接近6GB/s，差不多已经接近4片P4500 SSD的极限性能。
100GbE能够有效的发挥NVMe SSD的IOPS和带宽，那么在延迟方面呢？下面我们进行了另外一个测试。先看一眼各种存储介质的延迟表现：DRAM最小，在纳秒（ns）级别；然后是SCM（存储级内存），延迟增加了一个数量级；接着是SSD，延迟在微秒（μs）级别，相比DRAM又增加了三个数量级；最后是HDD，延迟在毫秒（ms）级别，相比SSD，延迟又增加了3个数量级。这些存储介质的延迟差距都是指数级的。
在延迟方面的测试，我们使用了Intel DC P4800X SSD。这种采用3D XPoint技术、俗称Optane的SSD，最引人注目的就是延迟极低，Intel官方公布的延迟指标在10微秒左右，我们在NVMeoF测得其读写延迟分别为34微秒和35微秒，相比官方数据，有一定的增加，但还是在同一个数量级，NVMeoF的延迟表现确实非常优秀。
然后是P4500的延迟，这个是在本地测的，读写延迟分别为101微秒和31微秒。这也可以看出RDMA的延迟非常低，即使是跨网络了，其延迟仍与本地SSD的延迟相差不多。可能有人注意到了，不是说SSD的写性能不如读性能吗？为什么你这上面P4500的写延迟比读延迟还低不少，甚至也低于P4800X呢?
这里需要说明，Intel DC P4500 SSD有独立供闪存控制器使用的DRAM，作为写缓存，以加速SSD的写操作，所以写延迟比读延迟还要低。为了保证DRAM里面的数据在突发掉电情况下也能写入到NAND闪存里，所以P4500里面还有两颗电容，来防止数据丢失。而Optane的写入特性很高，数据直接“落盘”的性能不逊于读取时，自然也就不需要DRAM及电容保护。
这张图则是在企事录测试架构下P4500的延迟表现，可以看到，由于加了32队列深度，在10GbE iSCSI模式下，延迟就比较高了，读写延迟分别为9毫秒和10毫秒。但在使用NVMeoF之后，即使是10GbE，其延迟也一下降到了3.7毫秒。仍然受限于10GbE的带宽瓶颈，所以其读写延迟相差无几。而在100GbE的NVMeoF情况下，延迟又降回到了微秒级别，比10GbE iSCSI模式低了一个数量级。
由于时间关系，企事录实验室的这个测试其实还没有做完，因为我们最终的目标是要评估NVMeoF在Oracle数据库应用场景下的性能表现，但我们的测试正在进行中，还没有获得进一步的结果，所以我们今天的分享就到此为止。但是，即使是这样，我们也看到NVMeoF的潜力巨大，确实能够较为充分的利用NVMe SSD的高性能，让跨网络的存储访问获得与访问本地存储相近的性能。我们相信随着NVMeoF技术不断发展成熟，这肯定是未来的方向。
