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），有的可能只是在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。
更多应用针对性的S2D测试数据，我们将在后续的文章中继续分享。敬请关注：）
最后，特别感谢上海戴尔客户解决方案中心Tony Wang对本次测试的大力支持！
附1：RDMA性能影响、SSD混合存储规则
笔者之前还写过2篇S2D相关的东西：
现在看来，一年多之前由于资料有限，当时写的一些技术点还不够准确。比如一位微软的朋友就曾指出：“Built-In Cache”和“ReFS Real-Time Tiering”在S2D里可以都看成是缓存技术，区别主要在于后者是先将数据写入副本分层来改善纠删码的性能。
回过来接着看前面的架构图：本次测试使用了4台Dell PowerEdgeR630服务器，比较豪华的一点是100Gb/sRDMA作为S2D集群互连网络，包括Mellanox ConnentX-4双端口100Gb网卡和Dell Networking S6100-ON交换机。
上图来自微软提供的参考数据，启用RDMA之后，S2D的IOPS和延时性能都有明显的改善。如果说在RDMA网络下S2D的效率才能充分发挥，换个角度也证明微软于RDMA（包括SMB Direct）方面在业内较早地进行了比较充分的优化。
另外说明一点，在这阶段测试中我们并未使用每台服务器上的1个NVMe SSD，因为不符合当前Windows Server 2016 S2D的规则。S2D支持SSD + HDD或者NVMe + SSD的缓存配置，但要求Cache层SSD每节点不少于2个。关于混合S2D配置与全闪存的性能差异，后续我想在另一篇文章中给大家介绍。
附2：企业存储系统发展的三个阶段
1、5-10年前的传统HDD磁盘阵列
相信许多朋友都看到过以下这组公式，根据硬盘的平均访问（寻道+旋转）延时来计算单盘的IOPS参考值：
15000rpm 硬盘 1000/(2+3.5)≈180
10000rpm 硬盘 1000/(3+3.5)≈150
7200rpm 硬盘 1000/(4.17+8)≈80
利用每块硬盘的IOPS，乘以盘数（主轴数量）可以得到一个存储系统的经验IOPS值，比如设计合理的情况下256块15K HDD可达4-6万随机读IOPS，此时控制器的处理能力往往还不会是瓶颈。随机写的情况相对复杂一些，RAID 1的写惩罚=2，RAID 5/6写惩罚则是4/6，所以我们看到各存储厂商在测试SPC-1这些交易类型的BenchMark时，大多会选择RAID 1（双副本镜像）以获得较好的表现。
上图来自于6年前某高端存储（8控制器）的SPC-1测试报告，在此只用于技术举例无意提及品牌型号。它配置了1920块15K HDD硬盘，按照总共45万IOPS来计算，平均每块盘贡献大约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%）的日志/顺序写入。在数据块大小方面，分为4KB和SMIX两种类型，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能贡献2万IOPS就算效率比较高的。再加上性能更高的双端口NVMeSSD刚开始成熟，人们普遍更加看好Server SAN/分布式软件定义存储（SDS），特别是超融合（HCI）部署形态的发展。
3、分布式软件定义存储
如今虽然Server SAN/SDS厂商如雨后春笋般涌现，但参与SPC-1的热度似乎不如以前高。SPC组织收费高昂是一方面，此外一位国内做存储研发比较资深的朋友还告诉我一些限制：SPC-1 V1应该是只支持UNIX和Windows客户端；SPC-1 V3加入了Linux，但还是要求FC、iSCSI、iSER这些标准块设备连接协议，专用客户端访问的存储产品无法参与测试。
这样一来，像VMware VSAN、Dell EMC ScaleIO、微软S2D（Storage Spaces Direct，基于SMB3协议）等主流软件定义存储产品就不太适合用SPC-1来测试。Ceph其实也是如此，iSCSI/FC网关显然没有原生的librbd效率高。
从性能角度来看，Server SAN/SDS的扩展性普遍不错，而单节点IOPS并不是都能做到很高，达到10万IOPS每节点就算比较好的了，这方面其实我也撰文讨论过。
