明明是全闪存阵列,为何存储性能仍然不够快

原创
存储
软件定义的超融合虽然有着诸多的优势,但对软件开发商提出了非常高的要求,他们非但要精通各种语言、系统和架构,还必须要熟悉硬件本身的性能,这样才能够保证开发出来的软件能够全部发挥硬件的性能。

   【51CTO.com原创稿件】软件定义基础架构,软件定义存储,软件定义存储。目前,用软件定义超融合的方式替代专用服务器、专用网络、专用存储设备等传统基础架构的方法,已经成为了行业的热点。英特尔系统架构师朱海峰先生曾在某超融合大会上公开表示,未来的大型数据中心的建设,将采用标准X86硬件构建作为整个数据中心的基础架构,通过软件厂商比较强的软件定义能力来实现存储、网络和计算等功能,并通过各种软件定义的解决方案来实现超融合。这也就意味着,软件定义已经成为行业的重点技术。

  软件定义的主要目的是减化部署流程,提高易用性,降低运维成本。当然,最重要的是能够发挥硬件的全部性能,合理分配利用硬件资源,节省硬件开支。

  不过,软件定义的超融合虽然有着诸多的优势,但对软件开发商提出了非常高的要求,他们非但要精通各种语言、系统和架构,还必须要熟悉硬件本身的性能,这样才能够保证开发出来的软件能够全部发挥硬件的性能。

  关于软件定义带来的硬件性能的损失,比较典型的例子就是软件定义存储导致的磁盘性能的下降,这主要是在全闪存时代背景下,磁盘性能有了非常大的提升,如果在软件定义的过程中还是按照传统机械硬盘的性能还编写系统,那就完全无法发挥闪存的性能。笔者在某超融合的大会上,就曾遇到过一家专门作软件定义存储解决方案的厂商,它们针对Flash时代开发出了裸金属软件定义存储技术,非常好的解决了软件定义存储无法充分发挥全闪存硬件性能的问题。

  这里,笔者与大家共同分享一下他们的解决方案和研发思路,希望对大家有所启发。

  我们知道,在Flash之前,存储性能的发展是严重滞后于其它硬件性能的发展的,虽然大家通过各种方法来提高磁盘的存储性能,但相较于其它硬件的发展,存储的性能提升并不理想。在Flash时代,存储硬件性能的问题迎刃而解。不过,很多厂商在替换全闪存阵列后,发现存储的性能并没有提高多少,这主要是软件和系统出现了问题。

  由于Linux标准的API并没有提供高性能的场景设计,因此操作系统成为了影响系统整体性能的瓶颈,无论你在一个设备上插入多少硬件,调用多少资源,都会发现一个节点一二十万iops就到了这些软件定义存储的上限了,这是因为Linux系统的任务调度,内存管理,以及系统调用,都是非常缓慢,完全不适合Flash时代的需求。

  如何解决这一问题呢,裸金属软件定义存储技术是通过以下两种方法解决的:

  一是硬件访问要绕过操作系统(stack-bypass);

  二是软件运行要绕过操作系统(os-bypass)。

  对于硬件的访问要绕过操作系统(stack-bypass)这种技术业内已经有相对比较成熟了,也比较容易实现。比如英特尔提供的DPDK/SPDK,Mellanox的RDMA,都不需要经过操作系统就可以直接访问硬件。但是,软件运行绕过操作系统(os-bypass)的难度却比较大。首先,要绕过操作系统的内存管理,直接访问物理内存,自己来实现内存管理,这中间要考虑NUMA,染色等问题,工程量非常大。其次,任务调度也要考虑的非常清楚,过去解决高并发问题的时候大家就会采用多线程的机制,但是多线程一般在数百并发的时候会变得比较困难,通过引入了协程技术,把任务之间的协作来分配时间片,每个任务处理完之后自动放弃时间片,而不是操作系统让他强制放弃时间片。另外,在事件处理上过去通过操作系统标准来实现,每个事件都跟时间有关,包括硬件系统的时钟中断。但是这个技术并不是非常的高效,在这方面可以采用polling技术,没有时间延期的。

  在多核同步上,目前 CPU的核数越来越多,过去编程的时候大家会采用生产者、消费者模型,用线程用来处理任务,但是到现在多核同步并不是一个非常高效的方案,这主要是因为NUMA和cachemiss问题,虽然说NUMA问题CPU解决的还可以,但是仍然不够理想,这时可以采用run-complete模型,每个CPU的核从他接受到任务,到完成任务中间不再任何跳转,避免隐性的CPU开销。

  通过以上的方案,能够拿掉尽可能多的环节,包括进出Linux的网络堆栈、Linux的存储堆栈,这样就能够让剩下的流程全是在硬件上运行的。最后,通过这些技术的运用,能够让存储的性能与硬件性能几乎完全一致,不带来硬件性能的任何衰减。

  以上,是某厂商针对全闪存时代在软件定义过程中出现的影响硬件性能的解决方案,笔者分享给大家,希望提供一些参考。

【51CTO原创稿件,合作站点转载请注明原文作者和出处为51CTO.com】

责任编辑:张诚 来源: 51CTO
相关推荐

2018-04-27 14:47:05

全闪存 存储

2017-08-21 15:34:18

闪存阵列厂商存储

2017-12-21 17:25:46

存储

2018-05-03 09:05:02

全闪存阵列存储

2016-05-26 09:07:00

IBM存储IBM存储

2013-07-01 08:07:01

融合存储惠普世界之旅全闪存

2023-12-01 16:43:49

全闪存存储机械硬盘高性能计算

2018-08-08 10:45:46

NVMeoF

2015-01-15 15:40:48

戴尔

2018-09-27 11:56:04

全闪存存储阵列

2017-10-11 08:21:07

闪存数据中心存储

2017-06-30 13:26:56

华为

2014-07-11 16:31:37

惠普

2018-05-15 09:03:36

2016-12-15 09:58:19

NetApp

2018-06-27 10:19:15

HPE全闪存

2017-12-11 17:19:10

闪存CIO硬件

2018-07-09 08:50:58

全闪存存储容量

2018-05-11 09:25:46

全闪存阵列实践
点赞
收藏

51CTO技术栈公众号