本文希望能带大家读懂应用BenchMark的内涵,并由此获得架构设计上的启发。
继上一篇《4节点近160万IOPS:SDS/超融合测试不能只看数字》中模拟了SQL Server OLTP存储负载之后,本文我们再看微软的另一个经典应用——Exchange Server邮件服务器的性能验证。最后再给大家补上一份基于S2D超融合集群的数据库TPC-E测试结果。
测试环境和之前一样,还是在上海戴尔客户解决方案中心(CSC)的微软S2D(Storage Spaces Direct)超融合集群,部署在4台Dell PowerEdge R630服务器上,每个节点7块1.6TB SATA SSD,网络互连为100Gb/s RoCE。
单虚拟机支撑15万邮箱性能?
Exchange Solution Reviewed Program (ESRP) –Storage是一个微软为Exchange Server设计的程序,用来帮助第三方存储测试和发布针对Exchange Server的解决方案,具体会用到一个名为Jetstress的测试软件。
各厂商产品测试报告公布地址:https://technet.microsoft.com/en-us/office/dn756396.aspx
本文的ESRP-Jetstress测试仍然由上一篇中介绍的高翔(Sean)老师完成,他目前担任上海维赛特网络系统有限公司副总工程师。
如果只看测试结果比较简单明了。我们利用Jetstress在Windows Server 2016 S2D超融合集群上的一个虚拟机中,模拟了4个数据库实例,测得总读写IOPS 18218.779(注意这里是半结构化数据,平均读/写大小均超过32KB)。延时都只有1ms左右,而ESRP的标准是20ms以内为合格,这一点对使用SSD的存储来说太容易满足了。
不过,从IOPS测试结果换算出系统支持的邮箱规模却有不同的标准。
上面这段文字引用自测试报告《Dell EMC DSS 7000_DSS 7500100,000 Mailbox Resiliency Microsoft Exchange 2016 Storage Solution》,其中是按照每个邮箱每天收发150个邮件的标准,折合每用户对数据库的平均压力就是0.121 IOPS,其中包含了20%的裕量。
用18218.779除以0.121,得到150,561。如果只是按照这个15万邮箱的性能结果(暂时先不考虑容量),在上面我们列出的微软网站测试发布中,大约可以排在第二高的水平?然而关于Exchange Server的存储规划,以及ESRP测试报告中的“玄机”还远不止于此,本文的讨论也才刚刚开始。
可能有的朋友已经想到了,Exchange单邮箱容量能支持到多大?性价比如何?DAG(database availability groups)高可用如何设计等都是需要考虑的问题。此外,我们只是在一个节点上用单虚拟机测试了Jetstress,如果在更多节点和VM上部署Exchange的话性能会不会更高呢?我想看过上一篇评测的朋友应该会有肯定的答复。
横向对比:从ESRP测试引发的思考
为了搞清一些问题,我专门从ESRP网页下载了几份有代表性的报告作为参考,并且花功夫整理出下面的表格。
在驱动器数量一栏,大容量7200转硬盘统一不加后缀,区别于10K高转速HDD和SSD。
首先,我是挑支持邮箱数最多的几份报告,在10万到20万之间的。然后我又选了一款全闪存阵列(Pure Storage)和一套超融合系统(Nutanix),并将我们测试的微软S2D一同列出。
1. 4款阵列、2款超融合和1款存储服务器
Dell DSS 7000/7500是上表中唯一的传统存储服务器,我在2年前的《DEF2015:4U 90盘位双节点Xeon E5服务器解析》中曾经介绍过,它可以当作每机箱2个45盘位服务器节点来使用。
DSS 7000/7500也是上表中唯一只利用Exchange DAG集群机制来保护磁盘数据的产品,并设计为4个副本(1 Active,3 Passive)。每节点42块大容量硬盘配置为14组RAID 0,这样缩小了故障域,一旦磁盘损坏应用需要重构的也就是3个盘的数据。
需要注意的是,尽管大家都设计了DAG架构,但ESRP实际测试时只用到相当于Exchange数据库的单个副本。所以我们看到,HUS VM、XIV Gen 3.2和Pure Storage实际上只测试了一套阵列,6节点FAS8060相当于是用了3套双控中各一半,Nutanix也需要添加第二套集群来实现DAG。所以对于软件定义存储的微软S2D超融合来说,若部署DAG也应该推荐用2个集群的方式。
2. 20万邮箱不是最快,IOPS最高却只4万邮箱?
接着看这些系统支持的邮箱规模。FAS8060集群模式的20万看上去最高,而它测出的15,011 IOPS却不显突出,原因在于每一份报告预设的IOPS/邮箱数值并不统一。该系统设计的单邮箱IOPS只有0.06…
也就是说,在ESRP测试中几乎只有IOPS才是“真功夫”。与FAS8060成为反差的就是Pure StorageFlashArray//m20,测出了最高的44,945 IOPS,却只标称4万个邮箱。我觉得是因为还要考虑容量因素,20个1024GB SSD的裸容量也才不到20TiB,如果不是Pure Storage还有数据缩减技术的话,该系统每个邮箱支持300MB就不错了。
Pure Storage设计的方案是在2个数据中心各放1套阵列,2个DAG中的数据库在它们之间互备。尽管这份报告文字描述不多,但ESRP实际测试应该也只用了1套阵列和单数据库副本。
所以作为价格不菲的全闪存阵列,索性将预设每邮箱IOPS提高到1,先不论用户是否需要这么快,反正要配更多闪存价格还会上升。我们测试的S2D全闪存配置也会遇到类似的问题,稍后会提出具体的解决方案。
在上面的表格中,我们给S2D预设的每邮箱IOPS是0.12,而我看到测试结果略高的HUS VM(配置480个HDD)报告中也只写到12万邮箱,所以还是保守一些没有把本次测试S2D支持的邮箱数写得更高。
另外一个让我有点奇怪之处,就是Nutanix预设的每邮箱IOPS低至0.03+20%,但实际测试却比这个水平高出不少。
3. 读写比例与数据保护级别的关系
由于副本(镜像)/RAID保护的写惩罚,再加上SSD的工作原理,几乎每款存储的读性能都要比写快不少,那么测试的读写I/O比例也会对结果产生影响。
具体来说,ESRP网站上发布的报告中Exchange数据库写I/O比例基本在30%附近,从28-33%不等,而我们用默认设置测出的写占比却高达43.3%。在这一点上对建议3副本配置的分布式存储尤为吃亏,如果我们也调低写I/O比例的话相信性能数字会更好看。另外副本数量也可以考虑减少?
我这样写并不是空穴来风,因为在Nutanix的报告中就提到,由于DAG层面上已经有2份数据库的拷贝,Nutanix自己的复制因子设为2时,结果就相当于总共4份数据了。
确实,由于DAG数据保护机制的存在,可以说存储双副本可能带来的风险被大大降低了。所以,我觉得S2D也可以考虑这种做法。
如果您觉得2副本+DAG的空间利用率还不够高,也可以考虑微软S2D支持的奇偶校验和纠删码保护的方式,虽然这样做对性能会有影响。
如上表,微软S2D在4-6个节点时支持2+2的Reed-Solomon纠删码保护机制;SSD+HDD混合配置在7-11个节点时支持4+2纠删码;而全SSD则是在9-15节点下支持RS 6+2保护;再往上就是LRC(LocallyRepairable Codes,局部可修复编码)了。
LRC属于一种高级纠删码,除了在一些情况下能够从3盘故障中恢复,LRC编码应该主要是降低了计算和重构的开销。
这个表格引用自高毅的文章《深入了解微软S2D软件定义存储技术》,供大家参考。
SSD +HDD混合配置对Exchange的价值
尽管纠删码校验方式能提高容量利用率,但我想大多数用户还是会觉得全SSD对于Exchange
存储来说太奢侈了。所以我在本文中最终推荐的是SSD+HDD混合部署,即S2D固态缓存方案。
首先,为了证明SSD Cache/分层存储在Exchange应用中的先例,我参考了另一份Dell的文档《SC Series Data Progressionand Data Reduction with Exchange Server 2016》,我们知道Data Progression就是Compellent当年赖以成名的自动分层存储技术。
Dell SC的分层机制比较丰富,我们可以看到上图中不仅区分驱动器层级,还有RAID级别和磁盘内外圈(Fast/Std)。随着时间优化的结果是,更多冷数据被移动到大容量廉价存储介质。微软S2D混合存储配置要实现的目标是一致的,那么后者除了基础的SSD读/写Cache之外还有那些定义和策略呢?
之前我在《Azure Stack中的超融合存储-S2D进阶篇》中曾经提到过Storage BusCache和ReFS Real-Time Tiering这两个概念,当时理解还不完全到位,觉得下面这张图更容易看懂。
这里的HDD应理解为数据位置,而不代表具体的某块物理盘
其中右边绿色的“Capacity Multi-Resiliency virtual disk”是用到了S2D中可选的ReFS Real-Time Tiering功能,这样就可以支持到2层驱动器上的“3个分层”。那么目的和价值在哪里呢?
在这种3层的配置下,最终数据写入路径还是先到左边的SSD Cache(紫色部分),然后迁移到容量层时,为了减少纠删码对HDD写性能的影响,先将数据以镜像保护的形式写入(红色部分,提高速度),然后再向校验码转换(蓝色部分,增大可用容量)。如下图,是不是和Dell SC有点像啊?
也就是说,容量分层中的Hot Data(Mirroring)可以起到SSD Cache写缓存层一个补充的作用。
我个人的建议是,一旦S2D混合配置的容量分层选择纠删码保护HDD,在Exchange应用中启用这部分镜像的写入加速空间还是比较推荐的,毕竟SSD Cache还要兼顾读缓存。除非混合配置中HDD是多副本,或者设计为全SSD纠删码保护。
当数据访问超出Cache容量,性能会下降多少?
如果热数据集能够基本包含在高性能SSD层级中自然是最理想的,但现实情况Cache总是会有一个“命中”的比例。由于本次测试时间和环境所限,我们没有对S2D的SSD Cache + HDD混合配置做详细测试,不过在一篇Intel网站的文章《IOPs performance on NVMe +HDD configuration with Windows Server 2016 and Storage Spaces Direct》中有些不错的验证。
注:上下2张图并不是针对Exchange的测试,供参考。
上面测的是4K随机读,当测试数据集大小超过4TB的缓存范围,性能就开始逐步下降。当然这只是个完全随机访问的验证,不像在真实应用中是有冷热数据的。
8K 70/30混合读写的情况与上面类似。
无论SSD+HDD混合存储还是纠删码,在其它条件相仿的情况下,其性能都不会没有全闪存+副本模式下的S2D好。这时有朋友可能会问:如果换个环境,你们这次的测试成绩(18218 IOPS或12万邮箱)是不是就会打折扣了?
答案是肯定的。不过上文中我也提到测试只用了一个虚拟机,按照我们眼中的最佳实践,仍然可以借鉴上次模拟SQL Server I/O扩展性测试中充分发挥集群资源的方式(见下图)。
鉴于S2D性能的本地读优先特点,如果我来设计Exchange Server,要最大化性能,一定会多少个底层节点就配多少个Exchange服务器,然后把不同的mailbox数据库放到不同的服务器,再在上面启用DAG保护。
——上海维赛特网络系统有限公司副总工程师高翔
注:我们之所以没有在ESRP测试中去尝试更多邮箱数量的极限压测,也是考虑到这套S2D测试环境的SSD容量已经出现瓶颈了。
最后,给大家补上一份在4节点S2D集群上运行SQL Server数据库TPC-E的测试结果。更多内容可以参考《Implementing SQL Server2016 with Microsoft Storage Spaces Direct on Dell EMC PowerEdge R730xd》。
链接:http://en.community.dell.com/techcenter/enterprise-solutions/m/sql_db_gallery/20444653。
再次感谢上海戴尔客户解决方案中心Tony Wang对本次测试的大力支持!