4节点近160万IOPS:SDS/超融合测试不能只看数字

本文涉及的产品
RDS SQL Server Serverless,2-4RCU 50GB 3个月
推荐场景:
云数据库 RDS SQL Server,基础系列 2核4GB
性能测试 PTS,5000VUM额度
简介: SQL Server OLTP模拟混合读写IOPS 62万,平均每节点超15万。

SQL Server OLTP模拟混合读写IOPS 62万,平均每节点超15万。


前不久有位朋友问我,随着近些年来企业存储的发展,每个阶段大致可以达到什么性能水平?直到前两天,我才想起来5年多前写过一篇《SPC-1:闪存 vs.磁盘新旧势力的战场》(链接http://storage.chinabyte.com/264/12249264.shtml),从一个侧面分析了企业级SSD大范围应用前夜的产品技术格局。到今天我想再补充一个简单的图表:

 

上面数值除了最右边的SDS(软件定义存储)/超融合之外,仍然参考自几份SPC-1测试报告,具体数字进行了一定模糊处理,以免大家对号入座:)SDS/超融合一项选择了其它测试方法获得的混合读写IOPS,一方面目前参与SPC-1测试的分布式/软件定义存储还不多(具体原因我放在本文结尾部分);另外如果用更多节点数量在这里“欺负”传统存储,可能也有点不够厚道吧:)

 

简单来说,早期磁盘阵列IOPS受限于HDD机械硬盘的平均访问时间,到了SSD时代介质的瓶颈相对容易解决。我给出的参考值不能充分代表所有厂商,也并不是每家厂商都积极参与SPC-1这样的军备竞赛,因为性能不是存储的全部。比如同样是全闪存高端多控阵列(AFA),有的可能只是在4KIOPS达到200万,而这并不能简单评价为“性能差”,因为它同时还打开了重复数据删除和压缩等数据服务

 

在初创的All-Flash Array厂商中,有些已经是分布式控制器的架构。随着多副本和纠删码技术的流行,人们也慢慢开始不再对FCiSCSI这些标准协议情有独钟。未来的NVMe over Fabric如果还是只限于Initiator-Target一对一,那么专用客户端和一些非标准块存储协议就有存在的价值。

 

如今,我们看到在一些使用标准服务器硬件的软件定义存储,其每节点贡献的性能已经开始不逊于专门优化的闪存阵列控制器,并且具有更好弹性的和扩展性。有了这些再加上逐渐的成熟,越来越多的传统存储用户开始青睐SDS和超融合(HCI)。

 

下面开始介绍本次测试的内容,大体上分为前后两部分,包括随机IOPS、顺序带宽这些基准测试结果,以及模拟SQL Server OLTP的表现。

 

第一部分:IOPS、带宽和SSD性能的发挥

 

IOPS测试看分布式存储软件的效率

 

注:上表中的延时都是在虚拟机中直接收集的(如无特别说明,以下同),相当于用户/应用最实际的感受。

 

我们部署了一个4节点SDS/超融合集群,每节点上除了系统盘之外,有7SATA SSD参与组建分布式存储,并采用最常见的3副本配置。每台物理机上使用20个虚拟机(共80 VM)进行测试。

 

我们测出的4节点4KB随机读最大性能为1,587,480 IOPS,平均每节点接近40IOPS,此时的平均延时为3.23ms。总共28SSD平均贡献56,595IOPS,这里使用的Intel SSD S3610官方标称4KB随机读IOPS84,000,分布式存储软件的效率还不错吧?

 

如果要看低延时IOPS,在0.36msIOPS864,843,平均每节点也超过了20万。我们虽然没有使用NVMe SSD,但可以给大家看一个之前的测试参考——在《Intel Optane P4800X评测(3)Windows绑核优化篇》中Intel P3700128队列深度下达到46IOPS的峰值,对应的延时为226μs。初步预计换成NVMe SSD将有更好的表现CPU等配置可能也需要升级)。

 

上图为在2节点上进行4K随机读测试的最高性能,每节点贡献44IOPS反映出了SDS/超融合的线性扩展能力和本地读优化(后面我还会细谈这个主题)。另外此时从物理机OS看到的存储读延时只有0.28ms,可见虚拟机中的延时很大一部分是由于队列,高I/O压力对VMCPU有明显的开销。

 

这时读者朋友可能会问,你们测试的是哪家SDS?先别着急,再看看随机写的表现。

 

如上图,在每个虚拟机设置QD=32时测出的433,620 4K随机写IOPS已经接近4节点集群的峰值。按照这时的数字来计算,落到每个SSD上的IOPS就达到了15,486 x 3=46459(因为是3副本),已经超过了IntelSSD S3610官方标称的27,000稳态随机写IOPS

 

上面是我们在开始测试时SSD简单摸底的成绩——Intel SATA 1.6TB54,491 4KB随机写并未达到稳态。对这一点我们并不是太在意,因为本次测试考察的是SDS存储软件的效率,SSD写表现快一点不是坏事吧:)

 

同理,由于企业级SSD是有带掉电保护的写缓存,所以在较低队列深度下SDS/超融合集群也能有较好的表现——330,264 100%随机写对应的延时只有0.48ms

 

如果在物理节点上看,写延时也降低了不少。大家都知道直接在物理节点中测试SDS效果更好,但由于本文评估的是虚拟化&超融合环境,所以仍然以应用感知的VM内延时结果为准

 

再谈副本数量与可靠性

 

有的朋友可能记得我写过一篇《为什么ScaleIOVSAN不要求三副本?》,其中提到VSAN“不打散”所以双副本可用,而ScaleIO通过保护域和故障集的配合、以及重构速度来保障2副本可靠性。

 

也就是说双副本的应用不是完全没有限制的,包括Ceph在内的更多强一致性分布式存储软件,大多建议生产环境使用三副本。我在这里想说的一点就是,POC等性能测试中,对于建议三副本的SDS产品使用双副本测试固然能看到更好的数字,但实际使用又是另一种情况。

 

对于宣称良好支持双副本的分布式存储,也要像我上面提到的2款那样有相应的理论设计基础到充分的测试和实践验证。毕竟对于企业存储产品来说,数据可靠性重于一切,如果不能保证稳定跑再快也没用

 

微软S2D测试环境:100Gb/s RoCE网络成亮点

 

每节点2E5-2640 v4 10CPU只能算是Intel XeonE5系列中的主流配置,不属于“跑分很漂亮”但更接近大多数用户的环境。

 

以上就是本次微软S2DStorage Spaces Direct)的测试平台——在上海的戴尔客户解决方案中心(CSC)进行,并特邀相关领域专家高翔亲自操刀。

 

高翔Sean)上海维赛特网络系统有限公司 副总工程师

 

早在3年前,高翔老师就主持过微软SOFSWindows Server 2012 Storage Spaces)的测试及相关项目实践,可以说是国内为数不多精通微软Storage Spaces的专家。

 

关于RDMA网络对分布式存储性能的影响,我们先稍后再谈。

 

除了2节点集群,微软建议S2D用户配置3副本(另有部分用途适合纠删码)。

 

我们测出4节点S2D集群的顺序读带宽为10951MB/s,平均每个SSD达到391MB/s,对比下前面列出的裸盘性能效率也不低了。至于2626MB/s的顺序写,考虑到3副本的开销,平均每节点的底层SSD总写入量依然达到了1969MB/s

 

第二部分、SQL Server数据库OLTP模拟I/O测试

 

在下面的测试中,我们选择继续使用DiskSpd + VM Fleet产生存储压力。其中DiskSpd是微软提供的一个类似fioIometer的工具,而VM Fleet则是配合DiskSpd使用的一套脚本,便于同时使用多个虚拟机进行测试。在后续的文章中我们也会用到其它工具,而总的原则如下:

 

1、 尽量避免因存储之外的配置造成测试瓶颈;

2、 通用性强,易于对比。虽然我们在本文中不做横向比较,但测试过程和结果方便复现,能够为用户和技术同行提供参考价值。

 

我们也考虑过在数据库中模拟交易/查询的测试方法,但其结果受多方面因素影响,包括:执行的SQL复杂(优化)程度、CPU性能、读写比例、内存命中率等等。想要跑出好看的TPSTPM/QPS,许多时候瓶颈会出在CPU核心数x主频而不是存储上,而用户的业务模型又是千差万别的。所以最终还是决定用微软官方建议的SQL Server存储性能评估方法。

 

上图截自《UsingDiskspdforSQLServer》文档中的范例,在听取几位朋友的意见之后,我们觉得40%的写入比例相对于各种OLTP用户平均的情况还是偏高了,因此选择了更有代表性的8KB 70%随机读/30%随机写。

 

对于实际应用来说,SQL Server数据库虚机机在每台物理服务器上的部署数量往往不会很多,但每个VM内的IO并发/队列深度却可能比较大,最终给存储带来的压力应该是同等效果。根据上面图表,在每台物理机80 QD时达到48万读写混合IOPS,延时为0.66ms;当每台物理机总QD达到640测出接近最高的62IOPS(平均每节点超过15万),对应的延时在5ms以内。

 

以上都是4个节点上的虚拟机同时压测。如果数据库只是运行在单个虚拟机,或者是1-2个物理机上,底层存储仍然由4节点Windows Server 2016超融合集群提供,这时又会是什么样的性能表现呢?

 

VM即可发挥一半性能:“另类”S2D扩展性验证

 

由于这里想压测出单个虚拟机在S2D上的最大性能,“1 VM”用的计算尺寸比较大,是16 Core56GB内存,相当于Azure上的D5V2配置。而其它测试每台物理机上20VM用的是A2实例——2 Core3.5GB内存。

 

注:S2D其实也是源自Azure公有云中的存储技术。

 

对于1个虚拟机中的165,405 8KB混合读写IOPS结果,我们比较满意。采用不同节点数量对S2D集群(仍为3副本)加压,2节点混合读写IOPS大约是单节点的1.5倍,4节点大约是单节点2倍。

 

上面的标题为什么称“另类”扩展性验证呢?因为人们普遍用整个集群、大量虚拟机来压测超融合的存储,而往往容易忽略单一负载的效率表现?我除了想验证这一点,还有服务器计算资源对性能发挥的影响(前提是网络在测试环境中不是瓶颈)。不得不承认,3x-4xIOPSVM内(客户端)加上SDS分布式存储软件本身的开销,对于2颗主频一般的10CPU已经够忙活了:)

 

换句话说,如果改用更好的CPUNVMe SSD,就应该能达到下面的测试结果:

 

4节点S2D跑到3百万随机读IOPS,这应该是我目前看到过平均每节点跑得最快的一个分布式存储测试报告,当然盘的配置也比我们实测要高不少——2Intel P3700做缓存层,8个同样NVMeP3500做容量层。

 

从超融合本地读优化到分离式部署

 

通过更多测试,我们观察到S2D3副本配置的情况下,写入数据时会全局打散到所有节点,而在读数据时一旦有副本在本地节点就优先从本地读取,对于超融合应用有助于减少网络的开销(尽管本文的测试环境网络不是瓶颈)。

 

上面只是我们配置过程中的一个截图,可以看到S2D4个用于测试的CSV(集群共享卷)Onwer分别指向了不用的节点,这样在对应服务器上加压时就可以享受到本地读的效果。如果某个Onwer节点故障,会重新选举新的Onwer接管CSV

 

不知是否有朋友会问:我的Hyper-V服务器平均存储压力没有这么大,S2D如此性能水平可否支持为集群外面的主机提供服务?答案是肯定的。

 

上图我在以前的文章中列出过,右边就是Hyper-V集群和SOFS on S2D集群分离部署(非超融合)。应用主机和存储节点通过SMB3协议网络连接,依然可以选用RDMA

 

根据IDC的预测,“2017年到2021年期间,全球软件定义存储市场的复合年增长率将达到13.5%,到2021年收入接近162亿美元。HCI不仅增长最快,复合年增长率为26.6%,同时也是最大的子领域,到2021年收入将达到71.5亿美元。在预测期内,对象存储的复合年增长率将达到10.3%,而文件存储和块存储的复合年增长率将分别达到6.3%4.7%

 

除了技术之外,再谈一下微软S2D在销售策略上的特点:与VMware VSANNSX单独销售不同的是,微软将Windows Server 2016数据中心版定位成软件定义数据中心的基础,将所需功能集成,一个License就搞定OS许可+Hypervisor+SDS+SDNWindows Server 2016三种部署方式:图形化界面、Server Core Nano Server 均支持S2D

 

更多应用针对性的S2D测试数据,我们将在后续的文章中继续分享。敬请关注:)

 

最后,特别感谢上海戴尔客户解决方案中心Tony Wang对本次测试的大力支持!

 

1RDMA性能影响、SSD混合存储规则

 

笔者之前还写过2S2D相关的东西:

微软WS2016原生分布式存储:还在追赶VSAN

Azure Stack中的超融合存储-S2D进阶篇

 

现在看来,一年多之前由于资料有限,当时写的一些技术点还不够准确。比如一位微软的朋友就曾指出:“Built-In Cache”和“ReFS Real-Time Tiering”在S2D里可以都看成是缓存技术,区别主要在于后者是先将数据写入副本分层来改善纠删码的性能。

 

回过来接着看前面的架构图:本次测试使用了4Dell PowerEdgeR630服务器,比较豪华的一点是100Gb/sRDMA作为S2D集群互连网络,包括Mellanox ConnentX-4双端口100Gb网卡和Dell Networking S6100-ON交换机。

 

上图来自微软提供的参考数据,启用RDMA之后,S2DIOPS和延时性能都有明显的改善。如果说在RDMA网络下S2D的效率才能充分发挥,换个角度也证明微软于RDMA(包括SMB Direct)方面在业内较早地进行了比较充分的优化

 

另外说明一点,在这阶段测试中我们并未使用每台服务器上的1NVMe SSD,因为不符合当前Windows Server 2016 S2D的规则。S2D支持SSD + HDD或者NVMe + SSD的缓存配置,但要求CacheSSD每节点不少于2。关于混合S2D配置与全闪存的性能差异,后续我想在另一篇文章中给大家介绍。

 

2:企业存储系统发展的三个阶段

 

15-10年前的传统HDD磁盘阵列

 

相信许多朋友都看到过以下这组公式,根据硬盘的平均访问(寻道+旋转)延时来计算单盘的IOPS参考值:

 

15000rpm 硬盘  1000/(2+3.5)180

10000rpm 硬盘  1000/(3+3.5)150

7200rpm 硬盘   1000/(4.17+8)80

 

利用每块硬盘的IOPS,乘以盘数(主轴数量)可以得到一个存储系统的经验IOPS值,比如设计合理的情况下25615K HDD可达4-6万随机读IOPS,此时控制器的处理能力往往还不会是瓶颈。随机写的情况相对复杂一些,RAID 1的写惩罚=2RAID 5/6写惩罚则是4/6,所以我们看到各存储厂商在测试SPC-1这些交易类型的BenchMark时,大多会选择RAID 1(双副本镜像)以获得较好的表现。

 

上图来自于6年前某高端存储(8控制器)的SPC-1测试报告,在此只用于技术举例无意提及品牌型号。它配置了192015K HDD硬盘,按照总共45IOPS来计算,平均每块盘贡献大约230 IOPS

 

为什么比前面的经验公式要高呢?我认为有以下几个方面的原因

 

a.  SPC-1测试负载中包括一部分顺序读写;

b.  阵列的预读/写缓存有一定I/O合并效果(HDD阵列低于5ms延时也是因为Cache优化);

c.  有些参测阵列并未划分全部容量,使实际的平均访问时间低于全盘范围(类似于短击的效果,只针对机械硬盘)。

 

记得在《存储极客:SPC-1负载分析与AFA寿命评估》一文中,我对SPC-1曾有过粗略研究,根据IOPS计算出写入的数据量。

 

SPC-1是个比较复杂的混合负载,包括约39%的读IO(应该主要是随机)和61%的写I/O,而后者当中至少有接近一半(占整体28%)的日志/顺序写入。在数据块大小方面,分为4KBSMIX两种类型,SMIX是按照一定比例的混合块,经计算其平均I/O大小为14.4KB。整体上看,I/O平均尺寸为6.76KB,写I/O平均8.83KB

 

注:后来推出的SPC-1 V3测试模型有所变化,以上仅针对SPC-1 V1讨论。

 

2、当前的全闪存阵列

 

随着基于NAND闪存SSD的普及,只需要数量少得多的驱动器就可达到以前“堆硬盘”的效果。中端双控AFA阵列普遍能达到数十万IOPS的水平,此时性能瓶颈已经从存储介质转到了控制器上,SPC-1测试平均到每个SAS SSD能贡献2IOPS就算效率比较高的。再加上性能更高的双端口NVMeSSD刚开始成熟,人们普遍更加看好Server SAN/分布式软件定义存储(SDS),特别是超融合(HCI)部署形态的发展。

 

3、分布式软件定义存储

 

如今虽然Server SAN/SDS厂商如雨后春笋般涌现,但参与SPC-1的热度似乎不如以前高。SPC组织收费高昂是一方面,此外一位国内做存储研发比较资深的朋友还告诉我一些限制:SPC-1 V1应该是只支持UNIXWindows客户端;SPC-1 V3加入了Linux,但还是要求FCiSCSIiSER这些标准块设备连接协议,专用客户端访问的存储产品无法参与测试。

 

这样一来,像VMware VSANDell EMC ScaleIO、微软S2DStorage Spaces Direct,基于SMB3协议)等主流软件定义存储产品就不太适合用SPC-1来测试。Ceph其实也是如此,iSCSI/FC网关显然没有原生的librbd效率高。

 

从性能角度来看,Server SAN/SDS的扩展性普遍不错,而单节点IOPS并不是都能做到很高,达到10IOPS每节点就算比较好的了,这方面其实我也撰文讨论过。

目录
相关文章
|
29天前
|
敏捷开发 jenkins Devops
探索软件测试的新篇章:自动化与持续集成的融合之道
【9月更文挑战第31天】 在软件开发的海洋中,测试是确保航船稳健前行的灯塔。本文将引领读者驶入软件测试的新纪元,探索自动化测试和持续集成如何携手共创高效、可靠的开发流程。我们将从基础概念出发,逐步深入到实际操作层面,揭示这一现代软件开发模式的核心价值和实现路径。你将看到,通过代码示例和实践案例,如何将理论转化为提升软件质量的具体行动。
|
18天前
|
分布式计算 Hadoop Shell
Hadoop-35 HBase 集群配置和启动 3节点云服务器 集群效果测试 Shell测试
Hadoop-35 HBase 集群配置和启动 3节点云服务器 集群效果测试 Shell测试
45 4
|
18天前
|
分布式计算 Hadoop Unix
Hadoop-28 ZooKeeper集群 ZNode简介概念和测试 数据结构与监听机制 持久性节点 持久顺序节点 事务ID Watcher机制
Hadoop-28 ZooKeeper集群 ZNode简介概念和测试 数据结构与监听机制 持久性节点 持久顺序节点 事务ID Watcher机制
36 1
|
1月前
|
机器学习/深度学习 人工智能 自然语言处理
自动化测试的未来:AI与机器学习的融合
【9月更文挑战第29天】在软件测试领域,自动化测试一直是提高测试效率和质量的关键。随着人工智能(AI)和机器学习(ML)技术的飞速发展,它们正逐步渗透到自动化测试中,预示着一场测试革命的来临。本文将探讨AI和ML如何重塑自动化测试的未来,通过具体案例展示这些技术如何优化测试流程,提高测试覆盖率和准确性,以及它们对测试工程师角色的影响。
62 7
|
6天前
|
机器学习/深度学习 人工智能 算法
探索软件测试的未来:AI与自动化的融合
【10月更文挑战第15天】在数字化时代的浪潮中,软件测试作为保障软件质量的重要手段,正经历着前所未有的变革。随着人工智能(AI)技术的快速发展和自动化测试工具的不断完善,传统的测试方法正在被重新塑造。本文将深入探讨AI如何赋能软件测试,提升测试效率和准确性,以及自动化测试的未来趋势。我们将通过实际案例,揭示AI与自动化测试相结合的强大潜力,为读者描绘一幅软件测试领域的未来蓝图。
|
1月前
|
Devops jenkins 测试技术
DevOps实践:持续集成与自动化测试的融合之道
【9月更文挑战第29天】在软件开发的快节奏竞赛中,DevOps如同一位智慧的舵手,引领着船只驶向效率与质量的彼岸。本文将揭开DevOps的神秘面纱,探索其核心理念如何通过持续集成(CI)和自动化测试的实践,实现软件开发流程的优化与加速。我们将一同见证代码从构思到部署的旅程,以及这一过程中的关键技术和工具如何协同工作,确保软件质量和交付速度的双重提升。
|
1月前
|
机器学习/深度学习 人工智能 数据挖掘
探索自动化测试的未来:AI与机器学习的融合
【9月更文挑战第29天】在软件测试领域,自动化测试一直是提高效率和准确性的关键。但随着技术的发展,特别是人工智能(AI)和机器学习(ML)的兴起,我们见证了一个新时代的到来——自动化测试的未来正逐渐被重新定义。本文将探讨AI和ML如何改变自动化测试的面貌,从智能测试脚本的生成到测试结果的深度分析,我们将一探究竟这些前沿技术是如何使测试流程更加智能化、高效化,并预测它们将如何塑造软件测试的未来趋势。
|
1月前
|
机器学习/深度学习 人工智能 测试技术
自动化测试的未来:AI与机器学习的融合之路
【9月更文挑战第15天】在软件测试领域,自动化一直被视为提高效率和精确度的关键。随着人工智能(AI)和机器学习(ML)技术的不断进步,它们已经开始改变自动化测试的面貌。本文将探讨AI和ML如何赋能自动化测试,提升测试用例的智能生成、优化测试流程,并预测未来趋势。我们将通过实际代码示例来揭示这些技术如何被集成到现有的测试框架中,以及开发人员如何利用它们来提高软件质量。
69 15
|
1月前
|
敏捷开发 jenkins Devops
软件测试的新篇章:自动化与持续集成的融合
【9月更文挑战第15天】在软件开发领域,质量保障始终是核心议题。随着敏捷开发的普及和DevOps文化的兴起,自动化测试和持续集成(CI)已成为现代软件工程不可或缺的组成部分。本文将深入探讨自动化测试的重要性、实施策略以及如何将其无缝集成到CI流程中,以实现更高效、更稳定的软件开发周期。通过具体案例分析,我们将揭示自动化测试和CI如何相互促进,提升软件交付的速度和质量。
|
1月前
|
机器学习/深度学习 人工智能 自然语言处理
探索软件测试的未来:自动化与人工智能的融合
在本文中,我们将一起踏上一段激动人心的旅程,探索软件测试领域的未来趋势。从手工测试的繁琐到自动化测试的便捷,再到人工智能(AI)技术的引入,我们将揭示这些变革如何影响测试流程、提升效率并减少错误。文章将深入浅出地分析自动化测试工具的进步和AI技术如何赋能软件测试,预测未来可能的发展路径,并提供一些行业案例作为参考。无论你是软件测试领域的新手,还是寻求进阶知识的资深人士,这篇文章都将带给你新的启示和思考。