在查看了具有传统架构的 VMware VSAN 集群的性能水平之后 联机事务处理平台 工作负载，我们想了解该平台如何响应要求更高的用例增加的工作负载。 最初的部署是四个 Sysbench VM，每个节点 1 个，但该工作负载并未使磁盘 I/O 达到我们认为资源得到充分利用的足够高的范围。 这类似于运行 POC 的客户，在他们当前工作负载的子集下对其进行测试，但不衡量平台在工作负载随时间增长或迁移更多应用程序数据时的响应情况。 为了更好地了解这个 VSAN 集群在不断增加的 MySQL 工作负载下如何响应，我们将四个 Sysbench VM（每个节点 1 个）基准扩展到总共 8 个和 12 个 VM。
在查看了具有传统架构的 VMware VSAN 集群的性能水平之后 联机事务处理平台 工作负载，我们想了解该平台如何响应要求更高的用例增加的工作负载。 最初的部署是四个 Sysbench VM，每个节点 1 个，但该工作负载并未使磁盘 I/O 达到我们认为资源得到充分利用的足够高的范围。 这类似于运行 POC 的客户，在他们当前工作负载的子集下对其进行测试，但不衡量平台在工作负载随时间增长或迁移更多应用程序数据时的响应情况。 为了更好地了解这个 VSAN 集群在不断增加的 MySQL 工作负载下如何响应，我们将四个 Sysbench VM（每个节点 1 个）基准扩展到总共 8 个和 12 个 VM。
Dell PowerEdge R730xd VMware VSAN 规格
- Dell PowerEdge R730xd 服务器 (x4)
- CPU：八个 Intel Xeon E5-2697 v3 2.6GHz (14C/28T)
- 内存：64 x 16GB DDR4 RDIMM
- SSD：16 x 800GB 固态硬盘 SAS 混合使用 MLC 12Gbps
- 硬盘：80 x 1.2TB 10K RPM SAS 6Gbps
- 网络：4 x Intel X520 DP 10Gb DA/SFP+，+ I350 DP 1Gb 以太网
- 存储容量：86.46TB
系统性能
每个 Sysbench VM 配置了三个虚拟磁盘，一个用于启动 (~92GB)，一个用于预构建数据库 (~447GB)，第三个用于测试中的数据库 (400GB)。 从系统资源的角度来看，我们为每个虚拟机配置了 16 个 vCPU、64GB DRAM 并利用了 LSI Logic SAS SCSI 控制器。
在负载 8 个虚拟机的情况下，我们看到每个 Sysbench 虚拟机消耗 5,200-6,300MHz，总主机资源表明使用了大约 18,000MHz。 这留下了大量的 CPU 资源，每个主机只使用了 22%，尽管在 8 个 Sysbench VM 的工作负载下，我们几乎使用了所有可用的 SSD 缓存。 对于存储影响，我们加载了 16 个 Sysbench 虚拟机以扩大整体占用空间，消耗了 14TB 总 VSAN 存储容量中的约 86.46TB。 然而，在 8 个 VM 工作负载时，这 7TB 中只有 14TB 处于活动状态。 这与 3.5 个虚拟机工作负载中的 4TB 相比。
Sysbench 测试配置（每个虚拟机）
- CentOS 6.3 64 位
- 存储空间：1TB，已使用 800GB
- Percona XtraDB 5.5.30-rel30.1
- 数据库表：100
- 数据库大小：10,000,000
- 数据库线程：32
- 内存缓冲区：24GB
- 测试时长：12 小时
- 6 小时预处理 32 个线程
- 1 小时 32 个线程
- 1 小时 16 个线程
- 1 小时 8 个线程
- 1 小时 4 个线程
- 1 小时 2 个线程
当我们扩展 Sysbench OLTP 工作负载时，我们测得性能从 2,830 个虚拟机的总计 4 TPS 增加到 4,259 个虚拟机的 8 TPS。 结果是性能提高了 50%，工作负载占用空间翻了一番。
随着聚合事务性能的提高，我们测得每个虚拟机的平均延迟从 45 毫秒增加到 60 毫秒。 这比较小的工作负载高了约 33%。
随着 I/O 需求的增加，平均第 99 个百分点的延迟也从 94 毫秒增加到 131 毫秒。
在基准测试运行时，我们从 vCenter 捕获了 CPU、磁盘和网络统计数据。 在 8 VM 测试期间，我们看到 VM-CPU 在 VM 之间的传播范围为 5,275MHz 到 6,393MHz。
每个节点有 2 个 VM 处于活动状态，我们看到混合磁盘活动在工作负载开始后测量到总计 609MB/s。 较大的峰值是在测试开始时预建数据库在每个 VM 内复制自身时测得的。
在 8 台 VM Sysbench 测试期间，来自一台主机的网络流量在测试稳定后测得混合为 391MB/s。
由于此测试的目的是展示 VSAN 如何响应不断增加的工作负载，我们确实在 12 个虚拟机运行后将平台推至 8 个虚拟机。 这是一些工作负载被推到 SSD 缓存之外的转折点。 我们没有绘制此性能图，因为大多数工作负载未完成或未获得适当的分数。 对于完成的虚拟机，我们会看到整个集群的聚合事务性能低至 1000-1500TPS。 我们测量的性能下降当然可以通过更大的闪存设备来缓解，例如 1.6TB SSD 而不是 800GB，或者迁移到全闪存 VSAN 模型，其中溢出到您的读取层没有那么大的I/O 下降。 这强调了适当调整 VSAN 环境的闪存组件大小的必要性，管理员或其经销商合作伙伴应该对工作数据集有很好的了解。 这是 VSAN 平台的关键优势之一； 允许客户定制配置以最好地满足当前和未来工作负载的需求，或者根据需要廉价地更换/添加 SSD。
了解平台的断点在哪里非常重要。 最初部署的工作负载通常会随着时间的推移而增加，无论是虚拟机数量还是存储容量。 每个存储平台都有一个瓶颈（即使是全闪存阵列），这让我们了解了这个四节点 VSAN 集群是如何堆叠起来的。 目前，我们只有一个存储平台成功运行了 12 个和 16 个 Sysbench VM，这是一个建议零售价为 575,000 美元的全闪存阵列。 然而，此 VSAN 集群的未来测试将包括全闪存配置，以尝试达到类似的性能目标。
VMware Virtual SAN 评论：概述和配置
VMware Virtual SAN 评论：VMmark 性能
VMware Virtual SAN 评论：Sysbench OLTP 性能
VMware Virtual SAN 评论：SQL Server 性能
VMware Virtual SAN 评论：扩展的 Sysbench OLTP 性能
VMware Virtual SAN 评论：HCIbench 综合性能
