《12万邮箱ESRP测试：Exchange超融合存储设计漫谈》 原创

继上一篇《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 7500 100,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 Storage FlashArray//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（Locally Repairable Codes，局部可修复编码）了。

LRC属于一种高级纠删码，除了在一些情况下能够从3盘故障中恢复，LRC编码应该主要是降低了计算和重构的开销。

这个表格引用自高毅的文章《深入了解微软S2D软件定义存储技术》，供大家参考。

SSD + HDD混合配置对Exchange的价值

尽管纠删码校验方式能提高容量利用率，但我想大多数用户还是会觉得全SSD对于Exchange

存储来说太奢侈了。所以我在本文中最终推荐的是SSD+HDD混合部署，即S2D固态缓存方案。

首先，为了证明SSD Cache/分层存储在Exchange应用中的先例，我参考了另一份Dell的文档《SC Series Data Progression and Data Reduction with Exchange Server 2016》，我们知道Data Progression就是Compellent当年赖以成名的自动分层存储技术。

Dell SC的分层机制比较丰富，我们可以看到上图中不仅区分驱动器层级，还有RAID级别和磁盘内外圈（Fast/Std）。随着时间优化的结果是，更多冷数据被移动到大容量廉价存储介质。微软S2D混合存储配置要实现的目标是一致的，那么后者除了基础的SSD读/写Cache之外还有那些定义和策略呢？

之前我在《Azure Stack中的超融合存储-S2D进阶篇》中曾经提到过Storage Bus Cache和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 Server 2016 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对本次测试的大力支持！