“VMware vSAN + NVMe 命名空间”的创新用法：单块 SSD 化身为 24 台设备，显著提升存储性能
免责声明：此处测试的技术目前不受 VMware 支持，而且可能永远不受 VMware 支持。不建议在任何生产环境中使用，尤其是需要 VMware 支持的环境。
NVMe™ 正在成为主流，行业中的许多公司都在推动采用这项技术作为更高的性能标准，包括用于 vSAN™ 的 VMware。NVMe 协议专为固态硬盘 (SSD) 而构建，与传统 SAS/SATA 存储相比具有许多性能优势，其中最重要的可能就是降低延迟。PCIe 接口上的 NVMe 协议绕过了 SAS/SATA 协议的大部分堆栈开销，因此能够提供更低的延迟、更多的 IOPS 和更高的吞吐量，同时还减少了 CPU 时钟周期、能量功耗、发热量等。
介绍鲜为人知的 NVMe 命名空间
NVMe 协议的功能之一是命名空间，但熟悉这项功能的人并不多。命名空间允许将 SSD 分割成逻辑上独立的较小驱动器，如分区。但是与分区不同，命名空间各自具有自己的提交和完成队列，可以高度并行化操作。所有 NVMe 驱动器都使用命名空间，但大多数驱动器仅支持单个命名空间，并且预先配置了占用整个驱动器容量的主命名空间。使用 Micron® 9300 MAX NVMe SSD，您可以配置多达 32 个任意大小的独立命名空间。
由于提供的最小容量美光 9300 驱动器为 3.84TB，我意识到将整个 9300 NVMe SSD 用于 vSAN 缓存设备并不合理，因为只需使用 600GB 的容量。然后我有个疯狂的想法，使用命名空间将 SSD 分成较小的逻辑驱动器，并将每个逻辑驱动器作为独立的存储设备呈现给 VMware ESXi 虚拟机管理程序。
“您为什么要这样做？” 扩展！
试想一下，小型 ROBO 配置利用最少的服务器和很少的驱动器插槽。使用传统的 vSAN 配置，您需要多个驱动器来扩展性能，因为 vSAN 在每个附加磁盘组中增加了额外的线程。如果仅限于几个插槽，则基本上会卡在一个磁盘组中，会限制性能（以及容量），因为应为缓存驱动器保留一个插槽。美光 9300 SSD 的单个 U.2 驱动器容量高达 15.36TB，从而实现很高的密度，并且具有命名空间，性能也很高。另一个用例可能是边缘计算，使用的服务器最少。这甚至可以在 vSAN 之外使用，例如作为 RDM 传递到多个 VM 的暂存磁盘。
在准备此演示时，我使用 HCIBench 对使用美光 9300 命名空间的 2 节点配置运行了一些测试。我使用了两台戴尔 R730xd 服务器，每台服务器都配备两个英特尔® 至强® 2690v4 处理器、256GB RAM、一个美光 9300 SSD 和两个 25GbE NIC。目的是了解 vSAN 性能如何随着磁盘组数、每个磁盘组的驱动器容量、存储配置文件等的变化而变化。为了确保比较的公平性，我在每次测试中都使用了相同的 HCIBench 配置，其中包括每个节点 4 个 VM、每个 VM 8 个 VMDK（每个 100GB）和每个 VMDK 4 个线程，总计 128 个未完成 IO。该研究的最大收获是，增加磁盘组的数量可以显著提高性能，三个磁盘组的读取性能几乎是单个磁盘组的三倍。读取和写入性能提升比例如下所示。这些数据是在使用 vSAN 默认存储策略以及禁用重复数据删除和压缩后报告的。
三磁盘组的性能几乎是单磁盘组的 3 倍
如上图所示，读写性能都随磁盘组数的增加而增加。超过三个磁盘组的回报可以忽略不计，所以我坚持使用三个磁盘组。我注意到，读取性能比写入性能更好。请注意，写入测试运行的时间足够长，可以大量去暂存，因此性能较低。如果是数据集在缓存层中 100% 拟合的测试，则数字会高出很多。
在 1 个演示服务器上创建 4 个 vSAN 节点
在这项研究的基础上，我想在 VMworld'19 上展示此功能，但不想只为演示而运送两台笨重的大型服务器。相反，我使用了 2U 4 节点 Supermicro Big Twin (SYS-2029BT-HNC0R)，并决定做完整的 4 节点 vSAN 集群作为演示。四个节点均配备两个英特尔® 至强® Gold 6142 处理器和 384GB 内存。它们各有六个驱动器插槽，其中四个支持 NVMe，尽管我只需要一个。我为每个节点安装了 15.36TB 美光 9300 MAX，以及新的 ESXi 6.7U3 映像（版本 14320388），将其连接到 vSphere Center Server Appliance（6.7U3 版本 6.7.0.40000），并将每个驱动器分成 24 个独立命名空间，三个 600GB 命名空间用于缓存驱动器，21 个 594GB 命名空间用于容量驱动器。配置如下所示。
将 4 节点 vSAN 集群配置为 24 个命名空间
幸运的是，由于这是标准 NVMe 功能，我不需要任何特殊工具来配置命名空间，只需使用内置的 `esxcli nvme` 即可创建这些命名空间。以下命令显示了如何创建命名空间并将其附加到控制器。
另辟：
`esxcli nvme 设备命名空间创建 -A vmhba3 -c 1258291200 -p 0 -f 0 -m 0 -s 1258291200`
附加：
`esxcli nvme 设备命名空间附加 -A vmhba3 -c 1 -n 1`
命名空间创建后，作为独立的存储设备（而不是分区）出现在 vSphere 主机中。就主机所知，命名空间都是独立的物理存储设备。实际上，我是在欺骗 vSAN，让它以为我给了它多个物理驱动器，而事实上我只使用了一个物理驱动器。
当驱动器成为瓶颈时，这根本没有用，但当使用能够提供 850K IOPS 和 3.5+GB/s 吞吐量的驱动器时，将其分割成较小的逻辑驱动器有助于 vSAN（或正在使用的任何应用）通过提高并行化来扩展性能。有关美光 9300 高性能 SSD 功能的更多信息，请访问产品页面。
为了创建演示，我决定使用比 HCIBench 更灵活和可配置的解决方案来生成负载。相反，我创建了自己的虚拟机，这样就可以完全控制它们。每个主机都有两个 VM，每个 VM 有 8 个 VMDK。事实证明，这是虚拟机的理想数量，既能将足够的线程分散到所有命名空间，又能通过尽量减少虚拟机数量来简化管理。我使用 CentOS 7.6 作为操作系统，并为每个系统配备了 8 个 vCPU 和 8GB 的 vRAM 以及单个网络接口。每个 VM 都安装有 8 个 VMDK 作为常规硬盘（非 NVMe 控制器），因为测试表明，两种选择都没有显著的性能差异。我再次使用了禁用重复数据删除和压缩的 vSAN 默认存储策略。
我创建了一个单独的 VM 来运行 Windows Server 2019，并使用 Iometer 工具生成针对主机的负载。为每个主机上的每个 VMDK 分配一个 Iometer 工作者，分别有 16 个和 1 个线程（出众的 IO），用于 4K 随机和 128K 顺序工作负载。理想线程数由简单的试错决定。目标是最大限度提高 4K 随机读取的 IOPS，较大化提高 128K 顺序读取的吞吐量 (GB/s)，同时保持每种读取的合理延迟。到了一定程度，性能将不再提高，但延迟会降低，这时我就会停止增加线程。
获胜的是……性能！
充分的技术谈话 — 让我们谈谈性能。如果我告诉过你，在了解 NVMe、命名空间和美光 9300 SSD 之前，可以通过单个驱动器获得惊人的性能，你可能会说我疯了。然而有了这个解决方案，我能够从单个驱动器中获得比大多数使用 20 多个物理驱动器的解决方案更高的性能……外形尺寸更小……密度更高……功耗更低……发热量更少……降低总体拥有成本……
通过这种配置，我能够推动提升 750K IOPS（4k 随机读取）和超过 11.5GB/s（128K 顺序读取）的速度！事实上，吞吐量如此之高，以至于我不得不在解决方案中添加第三个 NIC，以便 vSAN 可以拥有两个专用 NIC。我每个节点的平均速度超过 21Gbps，有些节点有时超过 25Gbps。这意味着即使将双 10GbE NIC 都分配给 vSAN，并且不为 vMotion、管理或其他网络功能预留空间，我也能获得比双 10GbE NIC 更高的性能。
VMworld’19 上的美光 NVMe 命名空间演示
由于演示在 VMworld 的 Solutions Exchange 中实时运行（不在温度受控的实验室环境中），因此噪音是个问题。我把电源设置降低到“节能”，略微降低了性能，尽管仍然在 4 天内保持了 550K+IOPS。这是直接 4K 随机读取测试，因此吞吐量仅为 2GB /s。如果我将块大小切换为 128K ，会发现吞吐量会跃升至约 8GB /s，而 IOPS 会降低至约 62K IOPS。
请注意，每个节点运行两个 VM，因此每个指标报告八个独立的数字。除了 8 个负载 VM 外，我还使用 Kibana 运行了一个三节点 Elasticsearch 集群（使用在每个 VM 上运行的 Metricbeat 来收集主机指标），以及 vCenter Server Appliance 和 Windows 服务器进行管理。即使此集群中总共运行了 14 个 VM，这些驱动器也能毫不费力即可实现这一性能。
该演示在 VMworld 上引起了广泛关注。我每天就这个配置做了几次演讲，甚至被邀请加入 Virtually Speaking (@virtspeaking) 的播客，讨论 vSAN 的未来、全闪存、命名空间、网络、耐用性、成本、总体拥有成本等问题。
那是我（右）与 Virtually Speaking 的人交谈
我们计划对此进一步测试，并提出更多用例。美光和 VMware 正在谈判中，我们希望在不久的将来看到它成为受支持的配置。别忘了，在 VMworld 2014 大会上，美光存储专家带着全闪存 vSAN 集群亮相，当时人们还对其惊叹不已。人们当时还觉得我们疯了！ 😉
在 Twitter @MicronTechnology 和 LinkedIn 上关注美光，及时了解公司的最新动态。