SAP HANA在全闪存架构Virtual SAN上的性能测试（上）

　　肯定有很多读者期待SAP HANA在Virtual SAN上的性能表现，为此我们进行了专门的测试。需要注意的是，目前SAP尚未授权将HANA运行在任何超融合架构之中（包括Virtual SAN）。VMware目前正在努力沟通，希望SAP HANA可以增加对Virtual SAN的支持。通过阅读本文，读者可以对SAP HANA在全闪存架构Virtual SAN上的性能有大体了解。

　　注释：本次性能测试分为上下两个部分，本文为上半部分，主要描述SAP HANA在不同工作负载，不同存储策略配置下的性能影响。下半部分主要描述SAP HANA在各种故障场景下的弹性性能。

　　通过实际性能测试，结果表明在启用Virtual SAN 6.2新特性的前提下，Virtual SAN可以胜任SAP HANA的工作负载。Virtual SAN在作为产品数据库的同时还可以向SAP HANA提供快速的备份和恢复平台。

　　Virtual SAN引以为傲的基于存储策略的管理（Storage Policy Based Management，SPBM）可以在Virtual SAN数据存储上对VMDK进行存储策略管理。这意味着运行在其上的SAP HANA数据库虚拟机可以针对不同的应用需求使用不同的存储策略。

　　图一 Virtual SAN的SPBM可以针对应用需求在空间使用率、性能及可用性上找到平衡点

　　测试中我们采用4台双路ESXi主机，每台主机配有两颗Intel Xeon CPU E5-2670 @ 2.3GHz v3处理器，256GB内存，2块400GB的Intel SSD作为缓存层以及8块400GB的Intel SSD作为容量层（即每台主机拥有两个磁盘组），网络配置基于万兆网络。

　　SAP HANA数据库虚拟机的操作系统为SUSE Linux Enterprise 11 sp3 64位，数据库服务器版本为1.00.112.02，虚拟机硬件配置如下：

　　SAP HANA HWCCT （Hardware Configuration Check Tool） 文件系统测试参数如下：

　　async_write_submit_active = on

　　async_write_submit_blocks = all

　　param async_read_submit = on

　　max_parallel_io_requests = 256

　　VMware在Virtual SAN 6.2中引入了校验和，去重/压缩以及纠删码（RAID 5/6）等新特性。为了全面验证这些新特性对SAP HANA的支持，并且评估启用新特性后对性能结果的影响，我们对Virtual SAN在以下5种不同类型的存储策略下的性能进行了测试。需要注意的是，在全闪存架构中，数据直接从容量层的SSD读取，因此不需要闪存读取缓存预留，系统默认均为0%。

　　如表中所示，为了尽可能让集群中的所有磁盘协同处理读写工作负载以提升性能，我们将存储策略的条带宽度设置为8。测试1a为典型的VMDK精简部署配置，测试1b中的VMDK使用厚置备延迟置零。而测试1c~1e分别启用了Virtual SAN 6.2中的新功能。

　　在以上所有测试案例中，我们使用SAP HANA HWCCT进行文件系统测试，并以数据盘的1MB随机I/O和日志盘的4K顺序I/O作为关键性能指标。此外，为了展现Virtual SAN不同存储策略配置的性能差异，我们将测试1a的结果作为性能基准，并以对比基准的百分比辅助进行对比。

　　从图二对比可知，不启用任何新特性的厚置备配置获得了最佳的写入吞吐性能。这是由于厚置备磁盘在部署时就已预留存储空间，这可以避免对象在工作过程中的负载不均衡，使工作负载均匀分布在所有磁盘组上。

　　图二 不同测试场景下的数据盘1MB随机I/O写入吞吐量

　　此外，测试1a与1d的写入吞吐量几乎相同，这是由于两者除了启用去重/压缩特性这一差别外，其他存储策略完全相同。HWCCT文件系统测试的数据尺寸非常小，因此所有的工作负载都保留在缓存层。而去重/压缩操作只有在数据从缓存层下落到存储层时才会执行。因此，在HWCCT文件系统测试中，启用去重/压缩特性对测试结果几乎没有影响。

　　虽然相比测试1a的基准性能，启用校验和（1c）和纠删码（1e）的写入吞吐量结果较差，但也能够满足关键性能指标。造成性能变差是由于启用校验和与纠删码导致的写入增加。

　　如图三所示，从读取性能的角度来说，在所有测试场景中，测试1b拥有最好的读取性能。而其他测试场景的读取性能相差不大，这是因为这些测试场景都是基于精简置备的。另一方面，由校验和与纠删码导致的I/O增加并不会影响读取工作负载，因此测试1c与测试1e的读取性能几乎相同，甚至比基准测试性能稍好。

　　图三 不同测试场景下的数据盘1MB随机I/O读取吞吐量

　　从覆盖写入延迟的角度来说，数值越低越好，所有的Virtual SAN配置策略都可以在400微秒内执行4KB顺序I/O。事实上，这些场景中的测试差异几乎可以忽略不计，因为差异实在太小，差值最大也就60微秒。

　　图四 不同测试场景下的日志盘4KB顺序I/O写入延迟

　　从覆盖写入吞吐量的角度来说，由于我们仅在数据盘上应用纠删码功能，而日志盘均使用测试1a的默认精简置备策略（在本测试中，我们没有对场景1e进行测试）。覆盖写入吞吐量在测试1a，1b以及1d之间的差别又一次十分之小，不超过7%。由于I/O写入增加对小尺寸块的I/O影响十分小，因此在场景1c的测试中，启用校验和功能后只比基准性能低了10%。

　　图五 不同测试场景下的日志盘4KB顺序I/O写入吞吐量

　　我们使用Virtual SAN性能服务监控后台性能，通过性能服务可以具体查看一段时间内的具体数值。在测试期间，我们在Virtual SAN后台捕获到如下延迟数据，可以看到4KB顺序I/O测试中写入延迟持续保持在600微秒之下。

　　图六 通过Virtual SAN性能服务监控后台性能

　　经过实际测试，我们可以得出以下结论：Virtual SAN在启用版本6.2新特性的情况下可以支持SAP HANA的实际工作负载。但是，如果用户想在集群中启用Virtual SAN的新特性并且横向扩展SAP HANA数据库（例如，部署三台不同的SAP HANA数据库在三台不同的主机上），请确保虚拟机首先可以满足HWCCT文件系统关键性能指标。

　　企业级数据库备份与恢复的重要性不言而喻。常规的备份会影响数据库性能，因此通过优化配置降低备份对性能的影响至关重要。虽然数据库备份恢复事件发生的频率并不高。但是一旦出现类似事件，恢复时间至关重要。有多种因素可以决定合适的RTO。由于测试范围的原因，我们主要关注不同的配置下的性能差异。在对比不同配置差异时，我们主要关注以下几个场景：

　　在测试中，我们启用了Virtual SAN中的去重/压缩功能。为了对比测试，我们添加了一台NFS数据存储，将其挂载在每台ESXi主机上作为外部存储。

　　为了进行数据库备份恢复性能测试，我们在SAP HANA虚拟机中额外添加了690GB精简置备的VMDK作为备份存储，如前文所述，该VMDK挂载在新添加的PVSCSI控制器上。

　　本测试场景评估了在执行备份时，不同存储配置对数据库的性能影响。所有的测试场景都达到了HWCCT的关键性能指标。在测试过程中，我们首先使用脚本创建了48个10列的表格，在每张表中插入了800万行的数据。之后，我们使用hdbsql进行全数据备份，备份路径为挂载的备份VMDK。这条命令同时被分发到每台SAP HANA数据库虚拟机上，一旦数据执行就触发。

　　在数据备份和数据执行完成后，我们删除了通过脚本生成的源数据表，以此来测试备份数据恢复。所有的数据执行、备份和恢复任务在所有的SAP HANA虚拟机上同时执行。

　　我们首先对比单台虚拟机的场景2a与2b。由于纠删码导致的I/O写入增加，备份数据到RAID 1的VMDK比备份到RAID 5的VMDK拥有更好的数据执行性能和更少的性能冲击。

　　图七 单台SAP HANA数据库虚拟机在执行备份与恢复时的性能

　　与此同时，由于数据备份是重写入工作负载，备份到RAID 1的VMDK的速度是备份到RAID 5的VMDK的2.5倍。在测试2a中的备份速度大约为322MB/s，而我们从Virtual SAN后台看到实际吞吐量达到了720MB/s。

　　图八 通过Virtual SAN性能服务查看后台实际吞吐量

　　由于数据恢复是重读取工作负载，纠删码对其性能影响微乎其微，因此测试2a与2b在数据恢复速度上几乎相同。两次测试都可以在不到5分钟的时间内完成。

　　接下来，让我们对比将VMDK安置在Virtual SAN与外置NFS数据存储上的区别。测试对比结果为四台虚拟机的平均值。通过查看测试2c与2d的平均数据执行时间，我们可以看到将VMDK放置在外部存储上对数据库的性能影响更小。这是因为备份到Virtual SAN数据存储相比备份到外置存储上（只需要处理数据库工作负载）增加了对Virtual SAN的写入工作负载。但是，由于备份和恢复速度十分依赖外置存储的性能，因此在场景2c（备份在RAID 1配置的Virtual SAN中）中的平均备份速度是场景2d（备份在NFS中）中的3倍。而场景2c的平均恢复时间只有场景2d的四分之一。

　　图九 四台SAP HANA数据库虚拟机同时执行备份与恢复时的性能

　　简而言之，相比使用外置存储，使用Virtual SAN可以消耗更少的备份与恢复时间。如果着重于在备份和恢复期间的数据库性能，也许考虑使用外部存储会是更好的选择。但是，如果没有合适的外部存储用作备份和恢复，可以选择将备份磁盘安置于Virtual SAN中，这样可以极大地缩短备份和恢复的时间，这在设计数据库备份和恢复架构方案中是个很好的选择。

　　实际测试结果表明，即使在启用Virtual SAN 6.2新特性的前提下，Virtual SAN依旧可以胜任SAP HANA的工作负载。Virtual SAN在作为产品数据库的同时还可以向SAP HANA提供快速的备份和恢复平台。此外，关于SAP HANA在Virtual SAN上面对各种场景故障的弹性性能表现，我们将于下半部分详细描述，敬请期待！

　　本文作者为VMware存储与可用性事业部Virtual SAN解决方案团队（Product Enablement，PE）的魏尘/丁楠。Virtual SAN解决方案团队主要负责Virtual SAN与各种行业关键应用平台的融合。通过设计、构建、验证关键应用在Virtual SAN超融合架构下各种场景的性能表现，针对产品特性进行性能调优，并以参考架构——白皮书的方式向客户提供使用Virtual SAN的最佳实践。