4节点近160万IOPS：SDS/超融合测试不能只看数字
摘要: 简单来说，早期磁盘阵列IOPS受限于HDD机械硬盘的平均访问时间，到了SSD时代介质的瓶颈相对容易解决。我给出的参考值不能充分代表所有厂商，也并不是每家厂商都积极参与SPC-1这样的军备竞赛，因为性能不是存储的全部 ...
注：上表中的延时都是在虚拟机中直接收集的（如无特别说明，以下同），相当于用户/应用最实际的感受。 我们部署了一个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产品使用双副本测试固然能看到更好的数字，但实际使用又是另一种情况。 对于宣称良好支持双副本的分布式存储，也要像我上面提到的2款那样有相应的理论设计基础到充分的测试和实践验证。毕竟对于企业存储产品来说，数据可靠性重于一切，如果不能保证稳定跑再快也没用。 微软S2D测试环境：100Gb/s RoCE网络成亮点
每节点2颗E5-2640 v4 10核CPU只能算是Intel XeonE5系列中的主流配置，不属于“跑分很漂亮”但更接近大多数用户的环境。 以上就是本次微软S2D（Storage Spaces Direct）的测试平台――在上海的戴尔客户解决方案中心（CSC）进行，并特邀相关领域专家高翔亲自操刀。
高翔（Sean）上海维赛特网络系统有限公司 副总工程师
早在3年前，高翔老师就主持过微软SOFS（Windows 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是微软提供的一个类似fio和Iometer的工具，而VM Fleet则是配合DiskSpd使用的一套脚本，便于同时使用多个虚拟机进行测试。在后续的文章中我们也会用到其它工具，而总的原则如下： 1、 尽量避免因存储之外的配置造成测试瓶颈；2、 通用性强，易于对比。虽然我们在本文中不做横向比较，但测试过程和结果方便复现，能够为用户和技术同行提供参考价值。 我们也考虑过在数据库中模拟交易/查询的测试方法，但其结果受多方面因素影响，包括：执行的SQL复杂（优化）程度、CPU性能、读写比例、内存命中率等等。想要跑出好看的TPS（TPM）/QPS，许多时候瓶颈会出在CPU核心数x主频而不是存储上，而用户的业务模型又是千差万别的。所以最终还是决定用微软官方建议的SQL Server存储性能评估方法。
上图截自《UsingDiskspdforSQLServer》文档中的范例，在听取几位朋友的意见之后，我们觉得40%的写入比例相对于各种OLTP用户平均的情况还是偏高了，因此选择了更有代表性的8KB 70%随机读/30%随机写。 对于实际应用来说，SQL Server数据库虚机机在每台物理服务器上的部署数量往往不会很多，但每个VM内的IO并发/队列深度却可能比较大，最终给存储带来的压力应该是同等效果。根据上面图表，在每台物理机80 QD时达到48万读写混合IOPS，延时为0.66ms；当每台物理机总QD达到640测出接近较高的62万IOPS（平均每节点超过15万），对应的延时在5ms以内。 以上都是4个节点上的虚拟机同时压测。如果数据库只是运行在单个虚拟机，或者是1-2个物理机上，底层存储仍然由4节点Windows Server 2016超融合集群提供，这时又会是什么样的性能表现呢？ 单VM即可发挥一半性能：“另类”S2D扩展性验证 由于这里想压测出单个虚拟机在S2D上的较大性能，“1 VM”用的计算尺寸比较大，是16 Core、56GB内存，相当于Azure上的D5V2配置。而其它测试每台物理机上20个VM用的是A2实例――2 Core、3.5GB内存。 注：S2D其实也是源自Azure公有云中的存储技术。 对于1个虚拟机中的165,405 8KB混合读写IOPS结果，我们比较满意。采用不同节点数量对S2D集群（仍为3副本）加压，2节点混合读写IOPS大约是单节点的1.5倍，4节点大约是单节点2倍。 上面的标题为什么称“另类”扩展性验证呢？因为人们普遍用整个集群、大量虚拟机来压测超融合的存储，而往往容易忽略单一负载的效率表现？我除了想验证这一点，还有服务器计算资源对性能发挥的影响（前提是网络在测试环境中不是瓶颈）。不得不承认，3x-4x万IOPS在VM内（客户端）加上SDS分布式存储软件本身的开销，对于2颗主频一般的10核CPU已经够忙活了：） 换句话说，如果改用更好的CPU和NVMe SSD，就应该能达到下面的测试结果： 4节点S2D跑到3百万随机读IOPS，这应该是我目前看到过平均每节点跑得最快的一个分布式存储测试报告，当然盘的配置也比我们实测要高不少――2个Intel P3700做缓存层，8个同样NVMe的P3500做容量层。 从超融合本地读优化到分离式部署通过更多测试，我们观察到S2D在3副本配置的情况下，写入数据时会全局打散到所有节点，而在读数据时一旦有副本在本地节点就优先从本地读取，对于超融合应用有助于减少网络的开销（尽管本文的测试环境网络不是瓶颈）。 上面只是我们配置过程中的一个截图，可以看到S2D上4个用于测试的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 VSAN、NSX单独销售不同的是，微软将Windows Server 2016数据中心版定位成软件定义数据中心的基础，将所需功能集成，一个License就搞定OS许可+Hypervisor+SDS+SDN。Windows Server 2016三种部署方式：图形化界面、Server Core 和 Nano Server 均支持S2D。 最后，特别感谢上海戴尔客户解决方案中心Tony Wang对本次测试的大力支持！
存储 测试 分布式 集群 微软
前不久有位朋友问我，随着近些年来企业存储的发展，每个阶段大致可以达到什么性能水平？直到前两天，我才想起来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），有的可能只是在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产品使用双副本测试固然能看到更好的数字，但实际使用又是另一种情况。 对于宣称良好支持双副本的分布式存储，也要像我上面提到的2款那样有相应的理论设计基础到充分的测试和实践验证。毕竟对于企业存储产品来说，数据可靠性重于一切，如果不能保证稳定跑再快也没用。 微软S2D测试环境：100Gb/s RoCE网络成亮点
每节点2颗E5-2640 v4 10核CPU只能算是Intel XeonE5系列中的主流配置，不属于“跑分很漂亮”但更接近大多数用户的环境。 以上就是本次微软S2D（Storage Spaces Direct）的测试平台――在上海的戴尔客户解决方案中心（CSC）进行，并特邀相关领域专家高翔亲自操刀。
高翔（Sean）上海维赛特网络系统有限公司 副总工程师
早在3年前，高翔老师就主持过微软SOFS（Windows 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是微软提供的一个类似fio和Iometer的工具，而VM Fleet则是配合DiskSpd使用的一套脚本，便于同时使用多个虚拟机进行测试。在后续的文章中我们也会用到其它工具，而总的原则如下： 1、 尽量避免因存储之外的配置造成测试瓶颈；2、 通用性强，易于对比。虽然我们在本文中不做横向比较，但测试过程和结果方便复现，能够为用户和技术同行提供参考价值。 我们也考虑过在数据库中模拟交易/查询的测试方法，但其结果受多方面因素影响，包括：执行的SQL复杂（优化）程度、CPU性能、读写比例、内存命中率等等。想要跑出好看的TPS（TPM）/QPS，许多时候瓶颈会出在CPU核心数x主频而不是存储上，而用户的业务模型又是千差万别的。所以最终还是决定用微软官方建议的SQL Server存储性能评估方法。
上图截自《UsingDiskspdforSQLServer》文档中的范例，在听取几位朋友的意见之后，我们觉得40%的写入比例相对于各种OLTP用户平均的情况还是偏高了，因此选择了更有代表性的8KB 70%随机读/30%随机写。 对于实际应用来说，SQL Server数据库虚机机在每台物理服务器上的部署数量往往不会很多，但每个VM内的IO并发/队列深度却可能比较大，最终给存储带来的压力应该是同等效果。根据上面图表，在每台物理机80 QD时达到48万读写混合IOPS，延时为0.66ms；当每台物理机总QD达到640测出接近较高的62万IOPS（平均每节点超过15万），对应的延时在5ms以内。 以上都是4个节点上的虚拟机同时压测。如果数据库只是运行在单个虚拟机，或者是1-2个物理机上，底层存储仍然由4节点Windows Server 2016超融合集群提供，这时又会是什么样的性能表现呢？ 单VM即可发挥一半性能：“另类”S2D扩展性验证 由于这里想压测出单个虚拟机在S2D上的较大性能，“1 VM”用的计算尺寸比较大，是16 Core、56GB内存，相当于Azure上的D5V2配置。而其它测试每台物理机上20个VM用的是A2实例――2 Core、3.5GB内存。 注：S2D其实也是源自Azure公有云中的存储技术。 对于1个虚拟机中的165,405 8KB混合读写IOPS结果，我们比较满意。采用不同节点数量对S2D集群（仍为3副本）加压，2节点混合读写IOPS大约是单节点的1.5倍，4节点大约是单节点2倍。 上面的标题为什么称“另类”扩展性验证呢？因为人们普遍用整个集群、大量虚拟机来压测超融合的存储，而往往容易忽略单一负载的效率表现？我除了想验证这一点，还有服务器计算资源对性能发挥的影响（前提是网络在测试环境中不是瓶颈）。不得不承认，3x-4x万IOPS在VM内（客户端）加上SDS分布式存储软件本身的开销，对于2颗主频一般的10核CPU已经够忙活了：） 换句话说，如果改用更好的CPU和NVMe SSD，就应该能达到下面的测试结果： 4节点S2D跑到3百万随机读IOPS，这应该是我目前看到过平均每节点跑得最快的一个分布式存储测试报告，当然盘的配置也比我们实测要高不少――2个Intel P3700做缓存层，8个同样NVMe的P3500做容量层。 从超融合本地读优化到分离式部署通过更多测试，我们观察到S2D在3副本配置的情况下，写入数据时会全局打散到所有节点，而在读数据时一旦有副本在本地节点就优先从本地读取，对于超融合应用有助于减少网络的开销（尽管本文的测试环境网络不是瓶颈）。 上面只是我们配置过程中的一个截图，可以看到S2D上4个用于测试的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 VSAN、NSX单独销售不同的是，微软将Windows Server 2016数据中心版定位成软件定义数据中心的基础，将所需功能集成，一个License就搞定OS许可+Hypervisor+SDS+SDN。Windows Server 2016三种部署方式：图形化界面、Server Core 和 Nano Server 均支持S2D。 最后，特别感谢上海戴尔客户解决方案中心Tony Wang对本次测试的大力支持！
大数据培训、人工智能培训、Python培训、大数据培训机构、大数据培训班、数据分析培训、大数据可视化培训，就选光环大数据！光环大数据，聘请专业的大数据领域知名讲师，确保教学的整体质量与教学水准。讲师团及时掌握时代潮流技术，将前沿技能融入教学中，确保学生所学知识顺应时代所需。通过深入浅出、通俗易懂的教学方式，指导学生更快的掌握技能知识，成就上万个高薪就业学子。 更多问题咨询，欢迎点击------>>>>在线客服！
