现在存储都喜欢搞性能军备竞赛,世界上最大的组织者就是SPC,各大存储厂商都在其中。目前SPC-1性能的世界冠军是华为OceanStor18000V3,而SPC-2性能冠军则是HPE3PARStoreServ20850。
没有参加测试的其他产品,厂商也往往提供一些参数,比如100万IOPS,在4K100%读的情况下,如果读写比例是70/30,那么性能变为80万IOPS。
用户一般把这些测试叫做herotest。很多用户认为,这些理想测试和自己现实的工作负载差距太大,对它没有什么用。
其实不然,如果你了解你自己的应用I/O,这些herotest还真是可以帮你评估那些存储比较适合你的要求。
大家知道,存储的性能主要和数据块的大小和读写的比例有关。但不同的产品有不同的设计理念,比如XtremIO针对4K负载进行优化,Pure则针对读进行优化,而Nimble则针对重度写进行优化。如果你了解自己的应用对存储的特征,那么理论上来说比较容易找到匹配你应用模式的存储,达成最优。
但用户如何知道自己的应用的负载情况呢?而且要从外部存储的角度来看,因为现代的服务器有大量的Cache,很多读写I/O都在服务器消化了,落到外部存储的I/O特性才有价值。
NimbleStorage公司刚刚发布一款AFA,西瓜哥朋友圈很多人刷屏,以后有时间我再给大家解读。但Nimble的产品,最大的特点不是硬件产品,而是其基于云和大数据的维护平台InfoSight。业界能和其媲美的还有Pure的Pure1。
这个InfoSight的厉害之处就是收集所有的install-base的产品信息,进行大数据分析,然后给用户维护建议,并且可以建立自己的数据库,改善产品。
虽然收集是匿名的,在海外不是问题,但在中国基本行不通。几乎没有用户愿意把产品的运行状况实时在线报送给厂商(高端存储除外),只有出问题的时候允许厂商远程维护。更多是安全考虑,其实也是社会的信任机制不完善所致。因此,中国的厂商只能有羡慕的份,而Nimble和Pure进入中国国内,也可能失去最有竞争力的这个优势。
不过,InfoSight的大数据统计结果,对存储厂商和客户来说,确实有很多参考的价值。首先,Nimble说其已经有了几千个客户,数据量够大;第二,这是用户的真实场景,而且是从存储侧观察到的。
今天,我们就分享一下从InfoSight在去年2月份这1个月收集的数据。我们主要通过其收集的数据来了解真实的应用负载是怎样的,特别是一些通用的负载,我们完全可以借鉴。
首先,我们来看一下现实环境中,IO的大小分布到底是怎样的?
从上面的统计我们可以看出:
>60%的写是小于8K的;
>50%的读小于16K;
另外,IO大小呈两极分化。
>50%的IO大小在4K(包括)和16K(不包括)之间
>20%的IO大小在64K(包括)和256K(不包括)之间
只有~15%的IO大小在16K(包括)到64K(不包括)之间
也就是说,现实生活是一种两极分化的模式。因此我们的存储设计的时候,要重点考虑4-16K和64-256K这个区间的性能。
有些存储厂商不是这么设计的,而32K大小来进行系统优化。因为他们认为I/O的平均大小是32K。这种设计理念并不好。
确实,IO全部平均起来,每个阵列的平均IO大小大部分落在16-64K的区间。
但是,上面的第一个图我们已经很清楚,这个区间的I/O是很少的,并不典型。因此,采用平均IO大小的模型来评估性能是不科学的。
InfoSight也给出了很多典型应用的IO大小的分布情况,关键还有读写比例。我们一块来看一下。
这是VDI的负载的IO分布,我们看到4-8K是最典型,读写比例是91:9。这种场景下,可以参考厂商提供的4K100%读的herotest结果,还是有意义的。当然要看配置相似的情况。
Splunk应用是一款日志分析软件,其典型IO也是4-8K,但读写比例是21:79。这种明显是写多读少的场景,应用优先考虑对读优化得比较好的产品。
SQLSERVER数据库典型IO是8-16K和64-128K,也是一种双峰的状态。读写的比例是63:37。
ORACLE数据库IO典型集中在8-16K,读写比例是65:35。
Exchange2013在4-8K,64-256K都有大量的分布,读写比例是63:37。
但是Exchange2010则又不同,大量分布在32-512K,读写比例75:25。
Exchange2007则集中在8-16K范围,读写比例是92:8。
Exchange2003集中在4-8K,读写比例是91:9。
从Exchange不同版本的对比我们可以看到,其IO特征差距是非常大的。这个要特别注意。
最后看一下文件服务,IO在4-512K之间比较分散,读写比例79:21。
从上面的数据我们可以看出,设计一款通用的存储是比较困难的,因为IO模式差距比较大。但大部分情况,4-16K的IO大小,70:30的读写比例,这个区间的I/O是比较典型的。如果设计一款通用的存储,可能重点的优化区间就是这个了。
厂商通过收集其产品的运行数据,确实能够帮助用户运维,更重要的是可以改进自己的产品。Nimble是每4小时采集一次产品的运行数据,形成自己强大的信息库。今天展示的只是负载方面的信息,还有运行时间,宕机时间,各个版本的分布情况,集群的比例,压缩比信息等等,这些对厂商来说都是无价之宝。Nimble也因此敢提供7年多的维保,而且宣传不靠收维保费来盈利。