DOITAPP
DOIT数据智能产业媒体与服务平台
立即打开
DOITAPP
DOIT数据智能产业媒体与服务平台
立即打开

网络存储“相对论”:NVMe over Fabrics性能实战

本周二(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技术不断发展成熟,这肯定是未来的方向。

未经允许不得转载:DOIT » 网络存储“相对论”:NVMe over Fabrics性能实战