本文内容非商业用途可无需授权转载，请务必注明作者及本微信公众号、微博 @唐僧_huangliang，以便更好地与读者互动。
本文希望能带大家读懂应用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
对本次测试的大力支持！
注
：本文只代表作者个人观点，与任何组织机构无关，如有错误和不足之处欢迎在留言中批评指正。
进一步交流
技术
，
可以
加我的
QQ/
微信：
490834312
。如果您想在这个公众号上分享自己的技术干货，也欢迎联系我：）
尊重知识，转载时请保留全文，并包括本行及如下二维码。感谢您的阅读和支持！《企业存储技术》微信公众号：
HL_Storage
长按二维码可直接识别关注
历史文章汇总
：
http://www.10tiao.com/author/index?authorId=691
