谁能更快解决企业爆发增长的数据处理业务?

服务器 数据中心
华为通过将闪存与系统深度融合,完全围绕着闪存特点来设计,充分发挥闪存高IOPS、低时延的优势、规避闪存擦写次数有限的劣势,力求为企业用户提供百万级IOPS、微秒级稳定时延的存储服务,满足企业数据中心的长期需求。

 DAL是X国一家大型远洋运输公司,业务包含航运、仓储、陆运、货物装卸、船舶管理等。白天营业时间,大约处理10W笔左右的货物交易订单。夜间非营业时间,需要进行数据整合、数据备份等操作,用于制定仓储计划、船舶调度计划。为了不影响第二天的日间营业,夜间操作必须在凌晨6点之前全部完成。2013年初,DAL计划增加至北美的航线,预计每天交易订单数量会增长到15W笔。当前系统无法在规定时间内消化15W笔交易数据,而交易数据每延迟一天,DAL将损失近10万欧元。通过分析,主要性能瓶颈出现在数据库与磁盘的并发访问量和响应时延上。在业务压力增大时,原存储系统IO时延急剧上升,在峰值时期IOPS达到20W左右,此时存储IO平均时延高达8ms。高时延IO导致数据库运行中80%的时间被用于IO等待,从而导致批处理时间过长。要彻底解决数据库性能问题,必须让存储系统在高IOPS压力的同时将时延控制在一个比较低的水平。最终,将15W笔交易订数据处理时间缩短至规定时间内,支撑业务顺利扩张。

寻找IT效率提升的***途径

随着企业数据中心所承载的业务越来越多,数据越来越频繁的流动和使用,对更低时延,更高服务级别保证等特性的诉求也将愈发明显。各行各业的应用千差万别,无论是全面的企业资源计划,还是用户关系管理,抑或是企业生产过程中的采购、生产、分销等流程,企业管理中的财务、人事、分析决策,都离不开成熟度的高性能IT系统支撑。在公共事务领域,同样也经历着这样的变化。随着云计算和服务器虚拟化进程的加速,IT设备需要从满足从单一应用走向面向多业务整合。用户对等待的时间和结果的可获得性都有越来越高的要求,这对企业IT系统的事务响应时间、并发处理能力、查询作业的时间长度提出了苛刻挑战,越来越多的用户开始关心IT系统的效率优化。总是想尽各种办法提升性能,,比如增加服务器的数量、提升服务器配置、让服务器的负载低于10%等等。这些手段无一例外都是习惯性加强服务器以满足应用数据库性能需求的思维定势,使得大部分用户环境中计算能力超出存储能力,却没有真正消除性能瓶颈。华为通过对近百个有类似问题的用户系统的调查显示,约87%的系统性能问题出现在存储子系统与应用数据库的交互上。换言之,存储子系统的响应时延、并发访问量决定了应用系统的响应时延与并发量,成为整个系统的性能瓶颈。

存储系统响应时间,即时延,正变成一个用户关注的指标,特别是对于很多企业关键应用(mission-critical business)来讲,决定最终用户的体验,不仅仅看IO吞吐量,时延也是非常关键的指标。通过提供稳定的低时延保证,一方面可以保证和改善用户体验,另一方面能够减少服务器的数量,还会在空间、能耗等方面给用户带来更多价值。反过来,时延的改善能促进应用系统对IOPS的需求。对于一个数据密集型的应用,如果数据访问的时延降低了90%,那么客户对IOPS的需求就可能会最多提升10倍。特别是针对OLTP、OLAP这些应用,这样的情况会表现得非常明显,收益也会是巨大的。另外,高性能计算、虚拟桌面等领域对高IOPS也有很大的需求。

特别强调一点,这里讲的是时延保证,即应用响应的***时延,换算成专业术语是99%以上I/O的时延。而非传统意义上的平均时延。99%的时延比平均时延对应用有更大的价值,原因在于当前大多数应用都是在线数据密集型应用,一个用户的请求会产生多个并发的访问,影响最终对用户应用的是这些并发访问中最慢的那个响应。99%的时延正好可以体现这一要求,而平均时延则显得没有多少意义。这就是业界对99%的时延强烈关注的主要原因。如下图所示,随着业务压力不断增长,存储系统处理的IO数目不断增多,而在面对大IO压力(如***IOPS)的情况下仍能保持持续稳定的低时延才是支撑应用快速响应的关键因素。

存储系统性能比拼测试

<1ms稳定时延--一扇即将开启的大门

那么对用户来说,时延究竟要低到什么程度才能更好的满足应用的需求?1ms的时延已经成为一个分水岭,成为闪存存储系统和磁盘存储系统的重要差异,系统必须要设计提供一种良好的分布式并发机制,解决大规模并发访问下低时延的保证问题。当我们将时延降低1-2个数量级时,我们仿佛进入了一个全新的世界。原来感觉很快的处理,现在可能已经变得慢起来。就像汽车与飞机,速度也就差1个数量级,但它们在设计中关注完全不同的问题。当我们将存储时延降低至300-500us时, iscsi协议带来的接近100us的延迟已经变得难以接受,而这在传统的10ms总时延的设备上根本无需关注。微秒级时延让我们进入了新的世界,我们需要以探索的精神,重新审视一下请求处理的各个环节,硬件和软件、架构和协议,使得每一个处理达到us级的精准控制。

传统以磁盘为中心的存储,时延***出现在磁盘数据的访问,要想实现微秒级的时延目标,是完全不可能的事情。但随着闪存的规模应用,大量关键数据可以放置到SSD上,完全可以使得数据的访问小于1ms。SSD是依靠低时延来支撑高IOPS的,这与堆砌HDD来增加并发能力进而提高IOPS的做法,是完全不同的,而事实上低时延更能够帮助业务系统提升性能,并减少在存储基础设施上的投资。SSD内部的控制器支持多通道并发访问后端的NAND Flash,所以SSD在支持低响应时延的同时也支持真正的多并发,从而将性能发挥出来。

时延问题的本质是存储介质的问题,如果选择HDD,时延就只能到达10ms水平;如果选择闪存,则可以控制在1ms,乃至300us水平;如果选择DRAM,则可以控制在100us,***可以控制的10us。尽管介质是最为本质的选择,但最终结果往往并不是仅仅选择合适的介质就能完全决定的。时延的问题是一个相当复杂的问题,介质只是里面最关键的一个环节,一个存储请求,从IO接口进入存储系统,到***从IO接口返回给用户,要经过多个临界资源的处理(CPU、锁、Cache、存储介质、内联网络、IO接口等等),要进入多个队列排队,每次排队和处理都会带来时延。再加上优先级的争夺,OS调度带来的干扰,特别是在要求越来越高的时延要求下,软件处理和协议栈开销也将成为被重点关注的对象。

闪存与系统深度融合--微秒级时延的设计思想

首先,必须要针对闪存的特性设计,而不仅仅是在传统阵列的设计上更新闪存盘。众所周知,传统阵列是围绕着缓存(Cache)展开的,一般使用比较节省内存、但是操作相对较为耗时的树形数据结构来作为cache的索引表,由于HDD的速度并不够快,通过Cache技术,传统阵列能够提供读命中,以降低读时延;能够提供回写,以降低写时延。这种设计思路导致如果我们直接将SSD插入传统阵列,只能发挥SSD的一小部分性能。而对于闪存阵列,情况则发生了变化。SSD的时延大约只有数十到数百us,比HDD低出1个数量级以上。在这种情况下,针对传统存储阵列所设计的索引表所引入的时延,变得突出起来,会极大地影响SSD性能的发挥。于是在闪存阵列系统中,必须要选择一种不同于传统存储阵列的数据结构来作为cache索引表。新的数据结构可以适当多占一些内存,但是操作(查找、插入、删除)时延一定要很低。虽然这会导致较高的CPU占用率和内存占用率,但为了得到更好的性能,我们不能也无需在闪存阵列上设计复杂的Cache,应尽量释放CPU来处理更多的IO。由此看来,系统的瓶颈点在不同的系统上发生了迁移,于是在设计和开发时,需要向关键路径要时间、向非关键路径要资源。传统存储阵列是拿时间换空间,而闪存阵列是拿空间换时间。

另一方面,对于HDD,随机访问和顺序访问的数据吞吐量差异超过100倍,而对于SSD,其随机访问和顺序访问的吞吐量差异只有2-4倍。因为HDD的顺序访问和随机访问之间存在巨大的数据交换速率差异,因此传统存储阵列中的各种各样cache算法,都是围绕如何尽量顺序访问HDD来设计的。而SSD的顺序访问和随机访问之间,数据交换速率差异没有那么大,情况发生了巨大的变化。这反映了一个事实:适用于HDD的cache淘汰算法,不一定适用于SSD。实际上,在闪存阵列中,我们更关心的问题是,cache中的数据是否做到了按闪存页面对齐和补满、是否有效防止了一次性访问数据对cache造成了污染、选择淘汰对象时的开销是否合理。通过基于SSD的专利淘汰算法,能够有效识别并区分顺序访问产生的数据、临时访问产生的数据、热数据,并迅速找出低价值数据进行淘汰,同时深度配合华为自研SSD颗粒特性,选择脏数据下刷到SSD时,尽量匹配SSD的闪存页面粒度和ECC校验,从而有效减小SSD的写惩罚和写放大。

随着云计算和服务器虚拟化进程的加速,前端服务器的整合带来了后端存储网络和存储设备的整合,整合的背后,导致存储设备需要从满足单一应用走向面向多业务的整合。存储行业正在发生深刻地革命性的变化,云计算推动了数据中心的整合,也将推动存储走向融合和统一。闪存作为新介质,正在承担主存的使命,驱动着存储架构的变化,向用户和应用提供新的存储评价指标——一致性的低时延。华为通过将闪存与系统深度融合,完全围绕着闪存特点来设计,充分发挥闪存高IOPS、低时延的优势、规避闪存擦写次数有限的劣势,力求为企业用户提供***IOPS、微秒级稳定时延的存储服务,满足企业数据中心的长期需求。

责任编辑:林琳 来源: 51CTO.com
相关推荐

2021-06-01 16:52:27

AI

2012-09-20 11:23:18

Hadoop云计算

2024-09-26 17:07:23

2024-09-21 08:45:45

2011-07-13 08:56:52

服务器大数据

2020-10-28 10:28:23

AI

2015-11-02 16:52:15

华为

2021-07-05 15:11:03

EnginePlus数据智能

2015-08-27 13:15:03

2017-10-27 19:03:20

GrowingIO

2024-09-26 16:48:10

2017-01-19 15:39:47

华为大数据

2012-08-13 13:43:01

企业业务华为

2011-08-19 15:42:12

Hadoop瓶颈数据处理

2019-10-12 05:17:11

物联网大数据IOT

2024-09-24 19:22:21

2024-05-22 15:31:56

2016-11-14 10:06:04

大数据max位图

2022-03-02 11:45:16

Python函数数据分析

2017-07-21 14:22:17

大数据大数据平台数据处理
点赞
收藏

51CTO技术栈公众号