北京迈络思科技有限公司亚太及中国区解决方案营销总监张辉:智能网络释放 NVMe Over Fabrics 无限可能

  • ODCC /
  • 25 April 2018

探讨一下网络相关的话题,今天很多专家在讲存储本身的东西,大部分讨论的是单个硬盘或者在单个节点之内或者一个服务器之内能到多好的性能、多低的延迟。实际大规模部署的时候要考虑存储节点到存储节点之间要通信,包括部署的规模性,即所谓的扩展性。那网络就不得不单独讨论一下。
今天我带给各位的汇报和分享有三部分,第一部分是NVMe Over Fabrics概要,第二是在规范里或者业内的网络需求上有哪些方面以及如何实现,最后是业内有一些国内外的同仁基于NVMe Over Fabrics做了一些测试,跟大家做一些分享交流,为大家未来做NVMe实施时做一个参考。

北京迈络思科技有限公司亚太及中国区解决方案营销总监张辉

第一块是NVMe Over Fabrics概要,这个趋势大家可能也都比较熟,两个轴,蓝色这边是扩展性的变化,右边黄色是时延的变化。从标准委员会或者从规范来讲,也希望延迟越来越低,从现在主流的100个微秒左右,降到10个微秒左右。另外是扩展性的问题,现在可能是在单机上的一块两块甚至更多块,最多单机的24块,最多插36块,未来肯定希望更多的应用享受的或者体会更高性能的介质更高性能存储的红利,它的扩展性带来了一些挑战,希望更多的成百上千,甚至数据中心的这些比较关键的应用都能体会到NVMe的优势。扩展性越来越高,从单体的到几十个,甚至成千上万的规模,这是从制定规范或者整个业内看待两个趋势,第一个是延迟越来越低,另外一个是扩展性越来越好。
这个图相信大家都比较熟悉,介质的性能越来越高,这里面提到几个变化,对网络的需求也提出同样的要求,第一,带宽本身也要追得上,肯定需要更高的带宽网络,但是实际上不止是带宽本身的要求,还有协议方面的如RDMA/RoCE,同时对Fabric提出了一些更具体的要求。
我的从业经历中一度没有觉得软件会变成整个系统的瓶颈,我一直觉得软件很快。从图上也能看出来,因为早期硬盘的延迟太大,6-10个毫秒的延迟,软件,包括软件本身在200个微秒,有几十倍的差距,大家一定是找影响最大的部分,那就是介质这块。所以能看到,包括截止到之前,所有专家在讨论说从硬盘到SSD,到SSD里面了,从SSD各种介质到最新的Optane,以及未来DIMM的东西。会发现这个趋势是延迟越来越低,甚至到现在的10个微秒,会发现软件在整个存储系统里延迟的比重已经很高了,软件协议堆栈变成最大的瓶颈。只有RDMA绕过CPU和内核,把延迟能做到十微秒,解决这个问题。未来期望能看到软硬件的延迟整体在十微秒以内,这是更进一步的畅想。
再看一下NVMe Over Fabrics的一些东西,NVMe Over Fabrics的技术规范大家都看到了,我简单总结几点,第一个是可靠,要基于信用流控,简单讲就是不丢包,不能因为拥塞导致丢帧或者导致包的丢失,再一个是NVMe优化的客户端,意味着说现在接受和传送的所有的命令必须是原生的NVMe的命令,不能再有转化层。再一个是低延迟的网络,本身介质已经很低了,至少保证对我整个介质能发挥出来,官方对这个也有一个相对比较具体的要求,他希望Fabric延迟不超过10微秒。第四,降低延迟,减少CPU消耗。我不知道大家有没有玩过NVMe的盘,如果玩了大家可以知道,如果没有一些负载的卸载,它会相当消耗CPU。这里提出要求,要求你的adapter能直接帮应用程序注册地址,希望内存和硬件的adapter能直接通讯。第五是整个网络的扩展能力。
如果一直玩存储的或者也有公司对RDMA不陌生,简单讲了一下RDMA,绿色的箭头是TCP/IP的流向,有三次拷贝,每一次拷贝都意味着有一个资源的浪费,另外,每一次的拷贝,因为在内核里,一定是消耗CPU的,延迟一定少不了。RDMA刚好相反,不经过内核,不需要多次拷贝。远端和本地的服务器内存直接通过硬件的网卡直接通讯,第一个就是不经过内核,延迟降低。另外一个对CPU的消耗几乎没有了,在存储领域,RDMA的优势能得到更大的发挥。
随着技术发展,RDMA开始“移植”到以太网,应用也越来越多。在同样的以太网上,只是协议不同,导致结果会有什么区别。看一下带宽,这个是个50G的网络,上面是TCP/IP,峰值也能到6GB的样子,但是能发现不稳定,只是峰值能到那么多。再看下面的RoCE,很快能爬升到理论值的上线6GB,平稳的维持在这个峰值。RoCE在同样的网络上,它的存储率和效率对带宽的利用率要比TCP高很多。再一个是看CPU利用率,对CPU的消耗很大,这里面能看到在TCP/IP里,CPU基本上是40%多的消耗。再看RoCE应用,会发现找不到那根线,因为RoCE或者RDMA不太需要CPU的协调,所以发现在RoCE里CPU消耗率几乎为0。另外一个,NVMe Over Fabrics的卸载,数据有两个东西,一个是数据路径,一个是管理路径,我们有没有必要让所有的数据处理都经过CPU,意思就是说管理通过CPU,数据这部分不经过CPU,那就大大降低了CPU的消耗,所以会有在NVMe环境下对CPU的卸载,把数据流经不经过CPU。另外一个数据,Offload,蓝色是不卸载的情况,绿的是卸载的情况,绿的几乎不太消耗,你要不卸载情况下,对CPU消耗相当高,这是了Mellanox的ConneX 智能网卡,S配了4代块SSD,会发现CPU消耗差不多有40%多会用来做数据处理。大家都知道买CPU过来是做计算的,,应该术业有专攻,大家知道CPU很贵,更贵的CPU应该做更宝贵的计算工作,IO就应该交给网络来处理。另外就是纠删码的卸载,纠删码需要计算的时候,也特别消耗CPU,我们曾经有合作伙伴也做过支持EC的存储系统,他有这个功能但是不敢打开的原因,他说一打开以后,发现CPU就暴走掉了,也可以用智能网卡做纠删码的卸载,这部分IO的计算用智能网卡来做,这样也会降低CPU消耗,让你得到磁盘高利用率的同时能降低CPU的使用率。
再回顾到刚才我讲的那几个点,无损网络,今天上午发布的里面有专门的章节,在这里有提到需要无损网络的配合,我举了两个例子,一个是InfiniBand,一个是高速以太网,再一个是客户端优化,这块我不是特别担心,因为现在各个厂已经意识到,整个生态系统都在努力。低延迟的网络,InfiniBand也好,包括我们的以太网,它的延迟会在纳秒级别,这个无疑是配合整个NVMe Over Fabrics最好的网络,网络本身的延迟越低越好,行业规范里提到10个微秒,是说在你原有基础上的网络的端到端的延迟,中间包括交换机的延迟不能超过10个微秒,比如现在你用一些相对比较普遍的交换机,交换机本身可能就有8个微秒,RDMA虽然快,但还有协议的开销,使用这种交换机也可能达到不了整个行业标准或者整个用户的期望值。再一个是减少对CPU的消耗,降低延迟,第一个是NVMe Over Fabrics卸载,另外是EC卸载,另外是RDMA卸载。最后一个是扩展性,扩展性我最不担心,InfiniBand扩展性包括以太网的扩展性已经在广泛使用。
前面讲了NVMe Over Fabrics,最后给大家分享一些数据,我们现在看到的一些测试的结果。我自己看了哪些数据还是比较兴奋,整体来讲满足业内对Fabrics的要求:延迟不超过10微秒,CPU利用率很低,性能和本地直连存储相差甚微。NVMe Over Fabrics要满足行业标准对它的要求,尽可能降低对CPU减少利用率,实测使用RoCE的话,能达到这个效果,和本地的CPU利用率差不多。这张图相对复杂一些,主机端和Target CPU的利用率,我直接说结果,除了一些必须的额外的开销,NVMe Over Fabrics对CPU的消耗很少,额外开销基本上可以忽略的状态,反观iSCSI对整个CPU利用率还是相当高的。尤其随着你的容量的增加或者随着NVMe盘的数量增加,会发现你的CPU不够用了。CPU利用率是我给大家的提醒,在高性能同时,可能要付出高CPU的付出,如果你们前期没有做好Fabrics规划,可能要付出的成本比较高。同样如果做好规划,会发现对CPU的消耗没那么高。
我的汇报就到这!