SDS与超融合平台性能评估分析.docx

SDS/超融合平台性能评估分析企业存储系统IOPS的测试报告，数值除了最右边的SDS（软件定义存储）/超融合，SDS/超融合一项选择了其它测试方法获得的混合读写IOPS。?简单来说，早期磁盘阵列IOPS受限于HDD机械硬盘的平均访问时间，到了SSD时代介质的瓶颈相对容易解决。我给出的参考值不能充分代表所有厂商，也并不是每家厂商都积极参与SPC-1这样的军备竞赛，因为性能不是存储的全部。比如同样是全闪存高端多控阵列（AFA），有的可能只是在4K读IOPS达到200万，而这并不能简单评价为“性能差”，因为它同时还打开了重复数据删除和压缩等数据服务。?在初创的All-Flash Array厂商中，有些已经是分布式控制器的架构。随着多副本和纠删码技术的流行，人们也慢慢开始不再对FC、iSCSI这些标准协议情有独钟。未来的NVMe over Fabric如果还是只限于Initiator-Target一对一，那么专用客户端和一些非标准块存储协议就有存在的价值。?如今，我们看到在一些使用标准服务器硬件的软件定义存储，其每节点贡献的性能已经开始不逊于专门优化的闪存阵列控制器，并且具有更好弹性的和扩展性。有了这些再加上逐渐的成熟，越来越多的传统存储用户开始青睐SDS和超融合（HCI）。?下面开始介绍本次测试的内容，大体上分为前后两部分，包括随机IOPS、顺序带宽这些基准测试结果，以及模拟SQL Server OLTP的表现。?第一部分：IOPS、带宽和SSD性能的发挥?从IOPS测试看分布式存储软件的效率?注：上表中的延时都是在虚拟机中直接收集的（如无特别说明，以下同），相当于用户/应用最实际的感受。?我们部署了一个4节点SDS/超融合集群，每节点上除了系统盘之外，有7块SATA SSD参与组建分布式存储，并采用最常见的3副本配置。每台物理机上使用20个虚拟机（共80 VM）进行测试。?我们测出的4节点4KB随机读最大性能为1,587,480 IOPS，平均每节点接近40万IOPS，此时的平均延时为3.23ms。总共28个SSD平均贡献56,595IOPS，这里使用的Intel SSD S3610官方标称4KB随机读IOPS为84,000，分布式存储软件的效率还不错吧？?如果要看低延时IOPS，在0.36ms的IOPS为864,843，平均每节点也超过了20万。我们虽然没有使用NVMe SSD，但可以给大家看一个之前的测试参考——在《Intel Optane P4800X评测(3)：Windows绑核优化篇》中Intel P3700在128队列深度下达到46万IOPS的峰值，对应的延时为226μs。初步预计换成NVMe SSD将有更好的表现（CPU等配置可能也需要升级）。?上图为在2节点上进行4K随机读测试的最高性能，每节点贡献44万IOPS反映出了SDS/超融合的线性扩展能力和本地读优化（后面我还会细谈这个主题）。另外此时从物理机OS看到的存储读延时只有0.28ms，可见虚拟机中的延时很大一部分是由于队列，高I/O压力对VM内CPU有明显的开销。?这时读者朋友可能会问，你们测试的是哪家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.6TB的54,491 4KB随机写并未达到稳态。对这一点我们并不是太在意，因为本次测试考察的是SDS存储软件的效率，SSD写表现快一点不是坏事吧：）?同理，由于企业级SSD是有带掉电保护的写缓存，所以在较低队列深度下SDS/超融合集群也能有较好的表现——330,264 100%随机写对应的延时只有0.48ms。?如果在物理节点上看，写延时也降低了不少。大家都知道直接在物理节点中测试SDS效果更好，但由于本文评估的是虚拟化超融合环境，所以仍然以应用感知的VM内延时结果为准。?再谈副本数量与可靠性?有的朋友可能记得我写过一篇《为什么ScaleIO和VSAN不要求三副本？》，其中提到VSAN“不打散”所以双副本可用，而ScaleIO通过保护域和故障集的配合、以及重构速度来保障2副本可靠性。?也就是说双副本的应用不是完全没有限制的，包括Ceph在内的更多强一致性分布式存储软件，大多建议生产环境使用三副本。我在这里想说的一点就是，在POC等性能测试中，对于建议三副本的SDS产品使用双副本测试固然能看到更好的数字，但实际使用又是另一种情况。?对于宣称良好支持双副本的分布式存储，也