通过阅读之前的文章，相信读者对于SQL Server在启用去重/压缩、校验和以及纠删码的全闪存架构Virtual SAN中的性能有了比较细致的了解。本文将重点阐述SQL Server在各种组件故障场景下的弹性性能以及在延伸集群上的性能表现。 Virtual SAN能够在使用低成本x86服务器的情况下提供企业级的可用性，以及在各种故障场景下提供最高级别的数据保护。在Virtual SAN延伸集群上运行关键应用可以确保数据“零丢失”，即使在整个站点故障的情况下也可以确保“零宕机”。 注释：本次性能测试分为上下两个部分，本文为下半部分，主要描述SQL Server在各种故障场景下的弹性性能以及在延伸集群上的性能表现。如需要了解VirtualSAN在启用各种不同新特性后运行SQL Server OLTP工作负载的性能表现，请阅读上半部分。 全闪存架构Virtual SAN具体配置 测试中我们采用4台双路ESXi主机，每台主机拥有两颗12核并可启用超线程的处理器，256GB内存，2块400GB的Intel SSD作为缓存层以及8块400GB的Intel SSD作为容量层（即每台主机拥有两个磁盘组），网络配置基于万兆网络。 SQL Server数据库虚拟机配置 在测试中，SQL Server数据库虚拟机的操作系统版本为Windows Server 2012 R2 64位数据中心版SP1，数据库版本为Microsoft SQL Server 2014企业版SP1，我们在每台ESXi主机上放置一台SQL Server虚拟机，虚拟机的具体硬件配置如下： 标准Virtual SAN集群的弹性测试（磁盘故障、磁盘组故障以及主机故障）测试介绍 在本次测试中，我们测量了200GB类TPC-E OLTP工作负载在四节点全闪存架构Virtual SAN上各种组件故障的场景，包括磁盘故障、磁盘组故障以及主机故障。 测试结果 试结果证明组件故障并不会引起数据库或应用业务的宕机，TPS可以在几百秒内恢复至正常水平。 需要注意的是，全闪存架构Virtual SAN在启用去重/压缩功能后，处理组件故障的方法与之前有所不同：由于去重/压缩基于整个磁盘组，磁盘组中的磁盘故障会导致整个磁盘组不可访问。因此在启用去重/压缩功能后，单块SSD故障与整个磁盘组故障造成的故障影响是相同的。 如图一所示，在未启用去重/压缩功能的情况下： 容量层中单块SSD故障会导致TPS（每秒钟request/事务数量）从1813下降至平均1643，并在160秒内恢复。 单个磁盘组故障会导致TPS从1853下降至平均1659，并在430秒内恢复。 单个主机故障会导致TPS从1568下降至平均1312，并在715秒内恢复。 在启用去重/压缩功能的情况下： 单块SSD故障或单个磁盘组会导致TPS从1760下降至平均1510，并在540秒内恢复。 单个主机故障会导致TPS从1590下降至平均1211，并在560秒内恢复。 图一 Virtual SAN在启用去重/压缩前后不同组件故障的弹性性能对比 在所有这些测试场景中，读取IOPS都会在故障当时受到影响，平均磁盘写入响应时间也会相应增加。但是，在各种组件故障场景中，写入IOPS和读取延迟都没有受到明显的影响。 延伸Virtual SAN集群的弹性测试（站点故障及网络延迟测试）测试介绍 在对延伸集群进行弹性测试验证站点故障的测试场景中，我们在四节点的全闪存架构Virtual SAN集群中放置了4台SQL Server虚拟机，200GB与500GB数据库各两台，并使用Benchmark Factory进行TPC-E工作负载测试。在测试环境中，站点A/B之间的往返网络延迟为2毫秒，站点到见证之间的往返网络延迟为200毫秒。（见证放置在站点C）这一测试验证了全闪存架构Virtual SAN延伸集群在其中一个站点故障的情况下对四台SQL Server虚拟机的影响。 图二 Virtual SAN延伸集群测试场景架构图 如图二所示，在站点A/B各放置2台ESXi主机，初始情况下每个站点运行两台SQL Server虚拟机（200GB与500GB数据库各一台）。在测试中，我们关闭站点B的服务器电源，以模拟整个站点宕机。 此外，我们在Virtual SAN Kernel端口引入延迟来模拟Virtual SAN延伸集群站点间1毫秒、2毫秒以及4毫秒的延迟状况。 测试结果 在站点B宕机后，vSphere高可用服务会在站点A重启站点B的虚拟机以确保服务可用。由于整个集群中只有一半的计算和存储资源可用，因此SQL Server的总体性能会受到影响。如图三所示，总的TPS从原有的7743下降到5856，即性能下降大约24.5%。由于整个系统不再需要镜像写入，平均磁盘写入延迟从7毫秒下降到3.6毫秒，而平均磁盘读取延迟增加到4毫秒。 在图四中，我们可以观察到，随着站点间延迟的增加，总的TPS会逐步下降。 图四不同网络延迟情况下的每秒交易数 除此以外，Virtual SAN的写入延迟也会随之增加，如图五所示，平均磁盘写入延迟从2毫秒逐渐增加到10毫秒，而读取延迟则几乎不变。平均日志写入延迟从5毫秒增加到15毫秒。 图五不同网络延迟情况下的平均读写延迟 经过实际测试结果分析，我们不推荐将SQL Server数据库作为关键业务应用部署在站点间往返网络延迟超过2毫秒的延伸集群中。 总结 在SQLServer等关键业务应用中，故障场景的弹性性能是最重要的性能指标。通过实际测试，我们验证了全闪存架构Virtual SAN在面对各种组件故障时强大的弹性性能。全闪存架构延伸集群可以在物理上分离的数据中心之间提供可靠的OLTP性能，即使在一个站点故障的情况下依旧可以确保业务的完整运行。关于SQL Server在全闪存Virtual SAN 6.2中的更多详细信息，可以点击文末“阅读原文”，查看已经发布的白皮书《Microsoft SQL Server 2014 on VMware Virtual SAN 6.2All-Flash》。 转载自：http://www.obayun.com/sql-server-zai-quan-shan-cun-jia-gou-virtual-san-shang-di-xing-neng-ce-shi-xia.html 文章经作者授权转载 本文转载于微信公众号: SQLServer走起(SQLSERVERZOUQI)，更多微信文章请扫描关注公众号: |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
