温故知新:ScaleIO Oracle性能测试解析

  1. 云栖社区>
  2. 博客>
  3. 正文

温故知新:ScaleIO Oracle性能测试解析

唐僧_1 2018-02-16 13:22:57 浏览906
展开阅读全文

SLOBOrionFIO这些测试工具有何异同?

 

近日看到某分布式存储软件/ServerSAN宣称“提供单节点可达100,000 IOPS的优越性能单节点可达1.6GB/s带宽”,粗略感觉还算可以吧,当然稳定性可靠性比这个更重要。

 

而从性能上来看,ScaleIO在三年前就轻松跑到比它高。上一篇《为什么ScaleIOvSAN不要求三副本?》我们讨论的主要是可靠性方面的设计,今天再带大家解读另一份性能测试报告。

 

0?wx_fmt=jpeg

引用自ESG报告《TransformingCommodity Hardware into Simple, Scalable, High-performance, Shared Storage》,20144

 

上图是测试环境:8节点的ScaleIO超融合集群上运行Oracle 12cRAC数据库,当时的ScaleIO软件版本还是1.2。我看到上周的会议上发布了最新的3.0版本,《Dell EMC World 2017(1)25GEFC多协议交换机和SC5020》一文中可以看到有张图。

 

当年测试用的还是思科服务器,ScaleIO之前对硬件没有特殊要求,标准化服务器理论上就可以。具体的配置包括每台服务器128GB内存、1块系统盘、1700GB PCIe闪存卡、6960GB SATA SSD和双口40Gb InfiniBand HCA

 

所有节点上的SATA SSDPCIe闪存创建两个ScaleIO存储池,实现了一个固定分层存储,应该是分别放置Oracle数据库表和Redo日志。

 

现在情况有了一些变化,我觉得不只是因为Dell EMC合并对VCE产生的影响,还有一个因素——思科也投资了超融合软件厂商并在推自己的方案。我们看到ScaleIO 3.0的新特性中包括增强对NVMe SSDNVDIMM的支持,这些在基于Dell下一代PowerEdge14G服务器R740xdR640ScaleIO Ready Node上都有体现。

 

1OLTP查询8KB 随机IOPS89

 

0?wx_fmt=jpeg

引用自EMC ScaleIO白皮书《High-PerformanceConverged Infrastructure for Oracle Database Deployments》,3年前测试结果不代表现在产品的水平,仅供参考。

 

上图是Oracle Enterprise Manager在随机IOPS测试过程中一小时的监控,期间运行了SLOBSilly Little Oracle Benchmark kit)。ESG报告中的8节点ScaleIO/OracleRAC环境,100% 8KBSLOB SQL Query(查询)生成IOPS838,332EMC在另一份白皮书里对测试参数做了点调整,跑到893,116 IOPS,如下图。

 

0?wx_fmt=jpeg


ScaleIODashboard界面中,还可以看到此时的带宽是6.8GB/s。平均每节点10IOPS出头还不是ScaleIO的最大能力,这一点与压测工具有关,如果换用fio可以跑到更高(下文中会列出相关数字),我认为Orion也是如此。具体原因下面会讨论。

 

2Update操作产生的读写I/O和数据量比例

 

0?wx_fmt=jpeg


继续进行75% Select / 25% Update测试,此时SLOB SQL产生的存储负载为565,522 IOPS。而我看到读/写带宽和IOPS的比例似乎不同,从下面的OracleEnterprise Manager监控结果也可以验证这一点。

 

0?wx_fmt=jpeg


其中Update操作产生的是一个读//写操作,DBWR监测到的磁盘活动为随机读I/O 85%、随机写15%左右,而写入的数据量/带宽所占比例则占到了23%。从这一点来说,SLOB生成的负载是与FIOOrion这样不依赖数据库而直接测试的工具有所不同。

 

3OLAP并发表扫描:4节点11GB/s8节点21GB/s

 

OLAP测试的数据仓库模型,加载了一个300GB TPC-H Lineitem表,数据由另一个工具DBGEN生成。

 

0?wx_fmt=jpeg


由于目的是测试在应用中的存储吞吐带宽,这里的操作是表扫描Oracle Database 12c Enterprise Manager中可以看到4节点集群Parallel Query测试的读性能达到了11.09GB/s,平均每节点贡献2.77GB/s

 

0?wx_fmt=jpeg

上面是sqlplus执行测试和结果显示的截图

 

0?wx_fmt=jpeg


当测试的集群节点增加到8个,我们看到OLAP类并发表扫描的速度提升到21.2GB/sScaleIO集群性能基本上能随节点数线性增长。这个结果与我们在《为什么ScaleIOvSAN不要求三副本?》里列出的一个趋势图相符,该文中还提到ScaleIO平均每节点可以贡献20IOPS。下面我们再看下三年前ESG报告中的另一份数据。

 

4FIO测试结果:53节点850IOPS

 

0?wx_fmt=jpeg


在一个53节点的QA环境中,每台服务器配置双万兆网口和1700GB PCIe闪存卡。使用fio测试工具获得8504KB随机读IOPS3704KB随机写IOPS114GB/s 64KB随机读带宽的表现。平均每节点随机读IOPS可达16万、随机写IOPS接近7

 

关于另外一个测试工具Orion,我在《全闪存阵列的测试与选型参考》和《16Gb FC实测带宽几何、四端口HBA呢?》分别列出过其OLTPOLAP的测试结果,通常使用8KB随机IO或者1MB顺序IO。本文中先不做更多讨论了。

 

5、节点离线测试:RebuildRebalance的影响

 

0?wx_fmt=jpeg


最后再分享点可能对大家有用的——“拔节点”测试。我们看到当8个节点剩下6个时IOPS下降幅度正好在25%的水平,而恢复为8节点健康状况后性能复原。

 

0?wx_fmt=jpeg


上图展示的好像是一个3节点集群,具体配置未知。根据我的理解,这套ScaleIO集群Rebuild数据的速度可达1.1GB/s,此时IOPS11万最多下降到4万。我在上一篇中就提到ScaleIO双副本的可靠性,一方面靠保护域来限制故障影响的盘和节点范围;另一方面就是靠高效率的重构,包括只Rebuild已用数据块和速度表现。而节点恢复上线或者扩容时数据Rebalance的速度不需要有那么高,从绿色曲线也能看出其优先级要低一些,对业务性能的影响也小很多

 

最后再次声明,3年前测试结果不代表最新版本ScaleIO 3.0的水平,仅供参考。

网友评论

登录后评论
0/500
评论
唐僧_1
+ 关注