我们已经讨论过了 用它取笑你，现在我们终于交付了带有 Intel Optane Review 的 VMware vSAN。 这将标志着对 vSAN 的第三次主要审查，从 混合 vSAN 6.0 的多部分回顾 随后是 vSAN 6.2 的全闪存回顾. 这一次，我们没有利用我们的 Dell PowerEdge R730xd 集群，而是使用运行 vSAN 2029 的 Supermicro 的 24U-TN4R2T+ 24U、6.7 托架服务器。 对于存储，我们使用全 NVMe 配置，写入层采用 Intel Optane P4800X (375GB) SSD，容量层采用 Intel P4500 (2TB) SSD。
我们已经讨论过了 用它取笑你，现在我们终于交付了带有 Intel Optane Review 的 VMware vSAN。 这将标志着对 vSAN 的第三次主要审查，从 混合 vSAN 6.0 的多部分回顾 随后是 vSAN 6.2 的全闪存回顾. 这一次，我们没有利用我们的 Dell PowerEdge R730xd 集群，而是使用运行 vSAN 2029 的 Supermicro 的 24U-TN4R2T+ 24U、6.7 托架服务器。 对于存储，我们使用全 NVMe 配置，写入层采用 Intel Optane P4800X (375GB) SSD，容量层采用 Intel P4500 (2TB) SSD。
对于那些不熟悉 vSAN 的人来说，VMware 的超融合基础架构针对 vSphere 进行了优化，更倾向于存储。 换句话说，vSAN 是软件定义数据中心构建块的一个步骤，旨在简化存储和存储管理，同时提供更好的性能。 vSAN 通常通过称为 VMware vSAN ReadyNodes 的认证计划进行销售，该计划是经过认证的硬件与 VMware 软件的组合。 大多数主要服务器供应商都提供 ReadyNode 配置，有些还提供 vSAN 作为设备。
与 ReadyNode 想法类似的是英特尔的 Select Solutions。 英特尔精选解决方案是经过验证的硬件和软件堆栈，符合英特尔提出的要求。 主要服务器供应商投放市场的解决方案必须能够复制或超过英特尔概述的基准性能，并且他们必须为客户提供详细的部署指南。 我们用于本次审核的设置属于此类，具体来说，它是一个面向 VMware vSAN 的英特尔精选解决方案。 顾名思义，该解决方案专为 VMware 环境设计。
面向 VMware vSAN 的英特尔精选解决方案有两种配置：“基本”和“增强型”。 我们的配置位于这些配置的中间位置； 它基本上是具有升级 CPU 的基本配置。 通过将 Optane SSD 用于写入层，我们的系统旨在满足关键业务应用程序的延迟需求。
Supermicro 2029U-TN24R4T+ 规格：
- Supermicro 2029U-TN24R4T+ 服务器 (x4)
- CPU：2 x Intel Xeon Gold 6152 处理器，2.10 GHz，22 核
- 内存：384GB RAM（12 x 32 GB 2,666 MHz DDR4 DIMM）
- vSAN 磁盘组，每个节点 2 个：
- vSAN 缓存层：2 个 375GB Intel Optane SSD DC P4800X 系列 NVMe SSD
- vSAN 容量层：4 个 2TB Intel DC P4500 系列 NVMe SSD
- 网络：
- 英特尔以太网融合网络适配器 X710 10/40 GbE（vSAN 专用链路，vMotion/VM 流量/管理拆分到其自己的 VLAN）。
- 性能
- 4KB 随机，队列深度 16，R/W：高达 550/500K IOPS
- 4KB 随机，队列深度 16，混合 70/30 R/W：高达 500K IOPS
- 每日工作日：30
- 性能
- 顺序读取：3200MB/s
- 顺序写入：1050MB/s
- 随机 4K 读取：490,000 IOPS
- 随机 4K 写入：38,000 IOPS
- DWPD 0.75 随机； 4.62顺序
应用程序工作负载分析
第一个基准包括 通过 SysBench 的 MySQL OLTP 性能 和 Microsoft SQL Server OLTP 性能 具有模拟的 TPC-C 工作负载。
每个 SQL Server VM 都配置有两个虚拟磁盘，一个 100GB 用于引导，另一个 500GB 用于数据库和日志文件。 从系统资源的角度来看，我们为每个虚拟机配置了 16 个 vCPU、64GB DRAM 并利用了 LSI Logic SAS SCSI 控制器。 这些测试旨在监控对延迟敏感的应用程序如何在具有适度但不过分的计算和存储负载的集群上执行。
SQL Server 测试配置（每个虚拟机）
- Windows服务器2012 R2的
- 存储空间：分配 600GB，使用 500GB
- SQL Server的2014的
- 数据库大小：1,500 规模
- 虚拟客户端负载：15,000
- 内存缓冲区：48GB
- 测试时长：3 小时
- 2.5 小时预处理
- 30分钟采样期
在超融合平台上的 SQL Server TPC-C 测试中，我们研究了混合模式、全闪存 (AF) 模式和全闪存数据缩减 (AF DR) 下整个集群的工作负载平衡。 不出所料，Optane 的 AF 模式表现稍好，总得分为 12,605 TPS，单个虚拟机的得分在 3,148.56 TPS 到 3,152.66 TPS 之间。 这总体上略好于总得分为 12,472 TPS 的非 Optane 版本的 vSAN。 在启用 DR 的情况下，我们看到 Optane 的总得分达到 12,604 TPS（仅比关闭 DR 时低一个 TPS），单个虚拟机的得分在 3,148.7 TPS 到 3,153.5 TPS 之间。 与 DR 的总得分为 11,969 TPS 的非 Optane 版本相比，这是一个相当大的飞跃。 这里值得注意的是，Gold CPU 可能是一个限制因素，而对于 Platinum CPU，还有更多优势。
对于SQL Server TPC-C测试，我们最关注的变量是平均延迟。 交易性能中的小差距不会显示完整的故事。 在我们的平均延迟测试中，AF Optane 的总得分仅为 16.5 毫秒，单个虚拟机的延迟时间范围为 14 毫秒至 21 毫秒。 在 Optane 版本上使用 DR 后，聚合的延迟仅为 17 毫秒，单个虚拟机的延迟为 13 毫秒至 21 毫秒。 与非 Optane vSAN 相比，这是一个很大的改进，在没有 DR 的情况下总得分为 52.5ms，在有 DR 的情况下为 261ms。
系统性能
每个 Sysbench VM 配置了三个虚拟磁盘：一个用于引导 (~92GB)，一个用于预构建数据库 (~447GB)，第三个用于测试中的数据库 (400GB)。 从系统资源的角度来看，我们为每个虚拟机配置了 16 个 vCPU、64GB DRAM 并利用了 LSI Logic SAS SCSI 控制器。
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，我们查看每个的 8VM 配置。 Optane AF 的总得分为 10,699 TPS，是非 Optane 版本 4,273 TPS 的两倍多。 在启用 DR 的情况下，Optane 达到 8,668 TPS，而非 Optane 的 DR 为 3,625 TPS。
对于 Sysbench 平均延迟，基于 Optane 的 vSAN 在启用 DR 的情况下确实能够以 23.95 毫秒和 29.62 毫秒的总分脱颖而出。 这与启用 DR 的非 Optane 的 60.05ms 和 71.05ms 相比。 在这两种情况下，Optane 的延迟都不到一半。
平均第 99 个百分位数的延迟再次表明基于 Optane 的 vSAN 在 DR 开启时的总得分分别为 42.9 毫秒和 55.63 毫秒，而非 Optane 的 126.02 毫秒和 DR 开启时为 212.42 毫秒。
VDBench 工作负载分析
在对存储阵列进行基准测试时，应用程序测试是最好的，综合测试排在第二位。 虽然不能完美代表实际工作负载，但综合测试确实有助于为具有可重复性因素的存储设备建立基线，从而可以轻松地在竞争解决方案之间进行同类比较。 这些工作负载提供了一系列不同的测试配置文件，包括“四个角”测试、常见的数据库传输大小测试，以及来自不同 VDI 环境的跟踪捕获。 所有这些测试都利用通用的 vdBench 工作负载生成器，以及一个脚本引擎来自动化和捕获大型计算测试集群的结果。 这使我们能够在各种存储设备上重复相同的工作负载，包括闪存阵列和单个存储设备。
简介：
- 4K 随机读取：100% 读取，128 个线程，0-120% 重复率
- 4K 随机写入：100% 写入，64 线程，0-120% iorate
- 64K 顺序读取：100% 读取，16 个线程，0-120% 迭代
- 64K 顺序写入：100% 写入，8 个线程，0-120% 迭代
- 综合数据库：SQL 和 Oracle
- VDI 完整克隆和链接克隆跟踪
对于 VDBench 测试，我们将只查看 vSAN 的 Optane Supermicro 版本，我们将查看是否启用 DR（从此处称为 DR）或关闭（从此处称为 Raw）。 在我们对峰值 4K 随机读取的第一次测试中，Raw 在大约 440K IOPS 之前具有亚毫秒延迟，并以 521,599 毫秒的延迟达到 4.65 IOPS 的峰值。 DR 在超过 1 毫秒之前开始，峰值为 406,322 IOPS，延迟为 7.32 毫秒。
对于 4K 随机写入，Raw 运行在 1ms 线下，但一直保持在 150K IOPS 左右，并达到 202,081 IOPS 的峰值，延迟为 8.4ms。 DR 达到约 114K IOPS，延迟为亚毫秒级，峰值为 183,947 IOPS，延迟为 1.43 毫秒，然后性能急剧下降，延迟激增。
接下来我们看看 64K 顺序工作负载。 对于读取，Raw 具有亚毫秒级延迟性能，直到大约 54K IOPS 或 3.5GB/s，峰值为 85,319 IOPS 或 5.33GB/s，延迟为 4.69ms。 DR 在 1 毫秒以上开始，峰值为 73,583 IOPS 或 4.6GB/s，延迟为 4.23 毫秒。
对于 64K 写入，Raw 在突破 12 毫秒之前仅达到约 1K IOPS，然后以 40,869 IOPS 或 2.55GB/s 的峰值达到 5.58 毫秒的延迟。 DR 始终具有亚毫秒级延迟性能，但峰值仅为 7,303 IOPS 或 456MB/s，延迟为 623μs。
继续我们的 SQL 工作负载，Raw 在大约 330K IOPS 之前具有亚毫秒级延迟，并以 385,159 毫秒的延迟达到 2.34 IOPS 的峰值。 DR 几乎一直保持在 1 毫秒以上，峰值显示为 321,504 IOPS，延迟为 3.02 毫秒。
对于 SQL 90-10，Raw 在突破 300 毫秒之前达到了大约 1K IOPS，并以 363,550 的延迟达到 2.52 IOPS 的峰值。 DR 的峰值为 299,132 IOPS，延迟为 3.26 毫秒。
我们的 SQL 80-20 测试发现 Raw 在不到 277 毫秒的时间内运行超过 1K IOPS，峰值为 332,949 IOPS，延迟为 2.79 毫秒。 DR 的峰值为 285,010 IOPS，延迟为 3.42 毫秒。
接下来是我们的 Oracle 工作负载。 Raw 在大约 262K IOPS 之前具有亚毫秒级延迟，峰值为 323,706 IOPS，延迟为 3.27 毫秒。 DR 达到 211,993 IOPS 的峰值，延迟为 2.07 毫秒，然后再次出现性能下降和延迟峰值。
对于 Oracle 90-10，Raw 在大约 315K IOPS 之前具有亚毫秒级延迟性能，并以 354,590 毫秒的延迟达到 1.67 IOPS 的峰值。 DR 的峰值为 279,356 IOPS，延迟为 2.24 毫秒。
在 Oracle 80-20 测试中，Raw 在 1 毫秒内运行直到大约 273K IOPS，峰值为 322,616 IOPS，延迟为 1.85 毫秒。 DR 能够达到 263,425 IOPS 的峰值和 2.36 毫秒的延迟。
接下来，我们切换到我们的 VDI 克隆测试，完整和链接。 对于 VDI Full Clone Boot，Raw 具有亚毫秒级的延迟性能，直到大约 240K IOPS，然后达到 293,335 IOPS 的峰值和 3.3 毫秒的延迟。 DR 在下降前达到 181,527 IOPS 的峰值和 5.31 毫秒的延迟。
VDI FC Initial Login 的 Raw 开始时间接近 1 毫秒，然后迅速通过并达到 153,513 IOPS 的峰值，延迟为 5.6 毫秒，然后略有下降。 DR 在性能下降和延迟激增之前达到了大约 68K IOPS 和 5.3ms 延迟的峰值。
使用 VDI FC Monday Login，Raw 在大约 58K IOPS 之前具有亚毫秒级延迟，然后以 152,660 毫秒的延迟达到 3.14 IOPS 的峰值。 DR 具有更好的峰值延迟 (1.64ms)，但仅达到 64,201 IOPS 的峰值性能。
对于 VDI LC 引导，Raw 的运行延迟为亚毫秒级，直到大约 170K IOPS，峰值为 209,676 IOPS，延迟为 2.21 毫秒。 使用 DR，它达到 119,036 IOPS 的峰值和 3.99 毫秒的延迟。
转到 VDI LC 初始登录，Raw 在 1K IOPS 之前保持在 29ms 以下，并以 92,951ms 的延迟达到 2.62 IOPS 的峰值。 对于 DR，它在略低于 64K IOPS 时达到峰值，延迟大约为 2.3 毫秒，然后下降。
最后，通过查看 VDI LC Monday Login，Raw 在突破 35 毫秒之前达到了大约 1K IOPS，并以 101,997 毫秒的延迟达到 4.65 IOPS 的峰值。 使用 DR，峰值约为 47K IOPS，延迟为 1.82 毫秒，然后性能下降。
总结
VMware 的超融合存储解决方案有多种形式； 此特定迭代使用四台 Supermicro 2029U-TN24R4T+ 服务器进行计算。 对于存储，此版本的 vSAN 利用英特尔傲腾 P4800X SSD 形式的英特尔傲腾和英特尔 P4500 固态硬盘形式的 NVME 存储。 此特定构建是英特尔新精选解决方案的一部分，尤其是面向 VMware vSAN 的英特尔精选解决方案。 它可以被视为经过 VMware 和 Intel 认证的 vSAN ReadyNode，以达到必要的性能指标。
在性能方面，在我们的应用程序工作负载分析中，我们将 vSAN 的 Optane 版本与我们之前在戴尔/东芝设备上测试的 vSAN 全闪存版本进行了对比。 对于 SQL Server，Optane 配置在打开和关闭数据缩减 (DR) 时的得分几乎相同，总得分为 12,605 TPS（无 DR）和 12,604 TPS（有 DR）。 这标志着与启用 DR (11,969 TPS) 的全闪存、非 Optane 版本相比有了相当大的飞跃。 在延迟方面，Optane 版本显示出显着改善，无 DR 时的总得分仅为 16.5 毫秒，启用 DR 时仅为 17 毫秒，不到 vSAN 6.2 上 SAS 全闪存版本延迟的一半。 借助 Sysbench，vSAN 的 Optane 版本的 TPS 是全闪存版本的两倍多，总得分为 10,699 TPS Raw 和 8,668 TPS（启用 DR）。 这种趋势随着延迟和最坏情况的延迟而持续，在两种情况下都不到一半，总得分分别为 DR 的平均 24 毫秒和 30 毫秒，以及最坏情况的 60 毫秒和 71 毫秒。
对于我们的 VDBench，Optane vSAN 在原始性能方面有几个亮点，包括 4K IOPS 的 522K 读取、4K IOPS 的 202K 写入、64GB/s 的 5.33K 读取和 64GB/s 的 2.55K 写入。 启用 DR 后，我们看到 vSAN 在 406K 读取时达到 4K IOPS，写入时达到 184K IOPS（随后急剧下降），在 4.6K 时读取速度为 64GB/s，在 456K 时写入速度仅为 64MB/s，但延迟低于 1ms。 vSAN 继续表现强劲，SQL 达到 385K IOPS，364-90 达到 10K IOPS，333-80 达到 20K IOPS，DR 达到 322K IOPS，299-90 达到 10K IOPS，285-80 达到 20K IOPS。 在 Oracle 中，Raw 在 324-355 中具有 90K IOPS、10K IOPS 和 323-80 中的 20K IOPS 的相当强劲的性能。 Oracle 中的 DR 也很强大，峰值为 212K IOPS（下降前），279-90 为 10K IOPS，263-80 为 20K IOPS。
包含 Optane SSD 显然对 vSAN 的写入性能有很大影响。 这甚至考虑到驱动器只有 375GB，而 vSAN 支持 600GB 的写入层驱动器容量。 因此，我们有可能通过拥有更大的驱动器来获得更多的写入性能。 这些 Intel 配置也有相当大的上行潜力，因为更快的互连是合格的，并且使用了更激进的 RAM 和 CPU 配置，就像在 Plus 选项中一样。 英特尔现在还为读取层提供了更快/更好的驱动器； P4510 是对 P4500 的重大改进。 重点是，与其将这些数据作为 Optane 的最佳表现，不如将这些数据更多地用于设置中端服务器配置的基线，如果场合需要，这些配置还有很多东西可以提供。 同样重要的是要考虑到 vSAN 处于有利地位，可以在新的存储和服务器技术进入市场时继续受益——这对于传统设备供应商来说要实现得多。
然而，要点很明显，随着 vSAN 的成熟，VMware 明智地走在了 Intel Optane SSD 等新兴技术的前沿。 这使 vSAN 在 HCI 市场的性能方面具有显着优势。 虽然许多 HCI 解决方案很乐意满足具有中等性能配置文件的 ROBO 用例的需求，但 vSAN 继续寻找最佳合作伙伴来创建在边缘同样令人满意的解决方案，因为它们正在为下一代数据中心奠定基础看起来像在 SDDC 世界中。 基于 Optane 的 vSAN 集群非常适合后者，为所有应用程序工作负载提供尽可能最佳的写入延迟。
