VMware 最近添加 NVMe over Fabric (NVMe-oF) 作为 vSphere 7.0 中的存储网络协议选项。 世界上最流行的虚拟化软件现在可以使用最快的共享存储解决方案，这一事实改变了游戏规则，为虚拟化数据中心开辟了全新的用例集。 这也意味着现在有能够在 vSphere 上启用 NVMe-oF 的虚拟机 (VM) 上运行的裸机应用程序。 其中包括人工智能 (AI)、机器学习 (ML)、内存数据库、高性能计算 (HPC)、高频交易 (HFT)、在线交易处理 (OLTP)，以及任何其他需要极低的延迟和大容量存储。
VMware 最近添加 NVMe over Fabric (NVMe-oF) 作为 vSphere 7.0 中的存储网络协议选项。 世界上最流行的虚拟化软件现在可以使用最快的共享存储解决方案，这一事实改变了游戏规则，为虚拟化数据中心开辟了全新的用例集。 这也意味着现在有能够在 vSphere 上启用 NVMe-oF 的虚拟机 (VM) 上运行的裸机应用程序。 其中包括人工智能 (AI)、机器学习 (ML)、内存数据库、高性能计算 (HPC)、高频交易 (HFT)、在线交易处理 (OLTP)，以及任何其他需要极低的延迟和大容量存储。
在 StorageReview.com，我们始终对测试最新技术感兴趣，以了解它们在现实世界中的工作方式。 鉴于我们之前使用 NVMe-oF 的经验，我们完全期望它能够显着提高 vSphere 的应用程序性能。 为了真正了解 NVMe-oF 将如何影响性能，我们将其与 iSCSI 进行比较，iSCSI 是 vSphere 数据中心块存储的当前标准载体。 但是我们的测试将有一个独特的转折点，因为我们不会使用高度专业化的小众技术。 相反，我们将使用当今数据中心中常见的产品。 我们的测试将在戴尔 R720XD 服务器上进行，该服务器通过以 5GbE 运行的 NVIDIA ConnectX-25 双端口适配器连接到 纯存储FlashArray//X 支持 NVMe-oF。
在得出测试结果之前，我们将首先概述 VMware 在 NVMe-oF 方面的支持，然后向您介绍 NVMe 和 NVMe-oF 的一些背景知识，并解释为什么它们的性能比iSCSI。 我们还将介绍在 vSphere 上设置 NVMe 所采取的一些步骤。
VMware 最近启用了 NVMe-oF 支持（2020 年 2016 月），尽管 NVMe-oF 标准于 2018 年发布。Linux 自 2020 年以来就能够使用它，存储阵列中的 NVMe-oF 支持也已经可用了几年. NVMe-oF 被认为是一种新兴但稳定的技术。 7.0 年 XNUMX 月，VMware 发布了 vSphere XNUMX，此版本包括对 NVMe-oF 的支持，允许使用 NVMe over Fibre Channel (NVMe/FC) 或 NVMe over RDMA Converged Ethernet（NVMe-RoCE，也称为NVMe/RDMA）。
NVMe 和 NVMe-oF 概述
直到最近，SSD 还是 事实上的 附加存储的标准媒体。 然而，它们也有一个关键的瓶颈。 SSD 使用 SATA 或 SAS 连接器，这些连接器设计用于 HDD，这严重限制了 SSD 的性能。 为了解决这个问题，一个由 90 多家公司组成的联盟在 2011 年联合发布了一个新的规范，将 SSD 连接到没有这个 SATA 瓶颈的计算机。 该解决方案最终被称为 NVMe。
NVMe 设备速度很快。 SATA/SAS SSD 在过去十年彻底改变了存储行业，而 NVMe 在本世纪彻底改变了存储行业。 例如，在我们最近使用 4K 读取工作负载进行的测试中，我们发现 SATA 驱动器 (Kingston DC500M) 可以提供略低于 80,000 IOPS，但 NVMe 驱动器 (Kingston DC1000M) 可以提供 580,000 IOPS，相差高达 7.25 倍。 有许多技术原因可以解释为什么 NVMe 的性能比 SATA 驱动器高得多，但最重要的原因之一是它具有更短的数据路径。 下图显示了与上一代存储（如 SAS）相比，NVMe 的数据路径如何显着缩短的简化说明。
其性能的提升，加上价格的急剧下降，让NVMe成为了现代数据中心的宠儿。
NVMe 驱动器在数据中心得到广泛应用后不久，人们就意识到这些设备并没有充分发挥其潜力，它们作为直连存储的局限性变得更加明显。 NVMe 设备需要与服务器分离，因此另一组公司联合起来制定了关于如何通过网络交付 NVMe 的规范。 一旦 NVMe 存储的传输机制可用，我们就可以将存储系统中的 NVMe 设备聚合、抽象和共享到许多不同的系统，包括 ESXi 主机。 NVMe-oF 使用目标/启动器术语。
RoCE 允许通过以太网网络进行远程直接内存访问 (RDMA)。 RoCE 有两个版本：RoCE v1 和 RoCE v2。 RoCE v1 允许同一以太网广播域（第 2 层）中的任意两台主机之间进行通信，而 RoCE v2 运行在 TCP（第 3 层）之上，因此是可路由的，允许它连接到以太网广播域之外的主机。 由于其先天的优势和在数据中心的流行度，VMware只支持v2。 在本文中，我们将 RoCE v2 简称为 RoCE。
RoCE 需要 RDMA 网络接口控制器 (rNIC) 而不是标准 NIC。 RoCE 网络通常需要配置优先流量控制，但 Spectrum 交换机在与 ConnectX 适配器一起使用时针对拥塞控制进行了优化，从而允许零配置。 RoCE 非常受欢迎，并且拥有一个繁荣的生态系统，可以提供 rNIC 和 NVMe-oF 子系统。 目前，世界上一些最大的超大规模数据中心正在使用它，这使得 rNIC 的价格比首次推出时大幅下降。
通过使用 RDMA，数据可以直接从 NVMe-oF 设备传输到主机，而不必像使用标准传输控制协议/互联网协议 (TCP/IP) 堆栈那样复制到内存缓冲区。 通过绕过缓冲区，RDMA 减少了主机上的 CPU 使用率并减少了访问远程 NVMe 设备上的数据的延迟。 NVMe-oF 比上一代网络存储技术性能更高的技术原因有很多。 值得注意的是 NVMe-oF 支持的大量队列 (64K)，但也许最有说服力的是 NVMe-oF 数据路径。 下图显示了与 iSCSI 存储相比，NVMe-oF 的数据路径如何短得多的简化说明。
RoCE 使用 UDP，这会影响性能，因为 UDP 需要较少的开销。 但是，RoCE 依赖于端到端兼容性来提供完全无损连接。 尽管现代网络交换机支持无损连接，但必须注意确保不支持无损连接的旧交换机不在 NVMe-oF 的网络路径中。
所有这一切的结果是 NVMe-oF 允许访问网络的 NVMe 驱动器，就好像它们是访问服务器的本地驱动器一样。 早期报告显示，池化存储的延迟约为 100 微秒，而不是 iSCSI 全闪存存储阵列的 500 微秒或更多。
NVMe-oF 与 vSphere
NVMe-oF with vSphere 的要求很简单：
- 支持 RDMA (RoCE) 传输的 NVMe 阵列
- 兼容的 ESXi 主机
- 支持无损网络的以太网交换机
- 支持 RoCE 的网络适配器
- 软件 NVMe over RDMA 适配器
- NVMe 控制器
- 第 2 层和第 3 层的无损网络或使用 NVIDIA 的 ZTR（零接触 RoCE）解决方案的有损网络
- 到 NVMe 目标的专用链接、VMkernels 和 RDMA 适配器
- 专用第 3 层 VLAN 或第 2 层连接
由于 NVMe-oF 是 VMware 的新功能，因此并非所有 vSphere 功能都适用于它。 我们注意到缺少的一些功能包括对共享 VMDK、原始设备映射 (RDM)、vVol 的支持以及从 NVMe-oF 启动的能力。
实施 NVMe-oF
我们使用了 NVIDIA 的 ConnectX-5 rNIC，这是数据中心中最常见的网卡之一。 这些卡是支持 RDMA 的单端口或双端口网络适配器。 它们可用于 PCIe Gen 3.0 和 Gen 4.0 服务器，并支持 1、10、25、40、50 和 100 Gb。 它们具有 750 纳秒的延迟，每秒最多可传递 200 亿条消息。 当与存储工作负载一起使用时，它们支持广泛的加速技术。
对于我们的测试，我们通过一对 NVIDIA 的 Spectrum SN3.0 交换机连接到 Pure Storage 闪存阵列的网络在一对 Dell R5 服务器中以 25GbE 运行 PCIe Gen 720 ConnectX-2010 卡。
我们首先通过输入 esxcfg 来验证我们正在运行 nmlx5_core 驱动程序-nics -l |grep -E '名称|NVIDIA'.
如果我们正在运行 nmlx4_core 驱动程序，我们可以从 ESXi CLI 为它启用 RoCE。
启用 NVMe-oF 的过程（类似于设置和启用 iSCSI 的过程）涉及在 ESXi 主机上配置 vSwitch、端口组和 vmkernel 端口。 主要区别在于我们需要为每个 ESXi 主机添加至少两个软件 NVMe over RDMA 适配器。
我们需要完成的最后一步是通过输入来识别 ESXi 主机的 NVMe 限定名称 (NQN) esxcli nvme 信息获取.
在 Pure Storage 阵列上，它类似于设置 iSCSI 阵列，但有一个很大的例外。 我们需要选择 配置 NQN.
NVMe-oF 与 vSphere 的测试结果
对于此测试，我们保持所有东西不变，但织物除外。 我们想要评估的是从更传统的 iSCSI 迁移到 RoCE 的影响。 需要明确的是，这不是存储基准测试。 这是一项检查，旨在了解 NVMe-oF 在几乎不需要更改的 VMware 环境中的优势。 我们使用两台 Dell EMC PowerEdge 服务器和一台 Pure FlashArray//X R2 作为存储后端。
我们的测试计划包括测量 8 个虚拟机（每个 ESXi 主机上 4 个）的总体性能，并使用 vdBench 测量传统的四个角和混合工作负载。 每个 VM 消耗 64GB 的存储空间，每个工作负载的总占用空间为 512GB，可用于比较协议更改时的性能变化。
要解释这些结果，请注意对于吞吐量来说，改进更好，而在延迟方面，减少更好。
在我们测量 4% 负载下 80K 随机读取性能的第一个工作负载中，我们测得吞吐量增加了 14.6%，读取延迟降低了 21.4%。
接下来，查看 64K 顺序读取工作负载中的读取带宽，我们看到吞吐量提高了 81.3%，延迟减少了 36.8%——同样是在 80% 的负载下。
虽然测量到的最大收益是在读取工作负载中，但我们还查看了一些常见的混合工作负载，其中第一个是 SQL 90/10。 在此工作负载中，我们测得在 78.2% 负载时延迟最多减少了 100%，在 43.4% 负载时延迟减少了 80%。
最后，在我们的 Oracle 90/10 工作负载中，我们发现 13.2% 负载时的延迟下降了 100%，35.7% 负载时延迟下降了 80%。
在此测试中，RoCE 显然在企业常见的大量工作负载方面有了很大的改进。
结语
我们的测试证明，现实世界中的 NVMe-oF 不仅仅是一个概念。 NVMe-oF 可以使用您数据中心当前的硬件提供出色的性能，例如带有 Gen 3.0 PCI 插槽的服务器、NVIDIA 的 ConnectX-5 NIC 和 Pure Storage FlashArray//X R2（Pure 现在出货 //X R3，具有更大的性能）性能改进）。
在我们的测试中，我们看到了小型和大型块读取工作负载的显着提升。 为了查看现实世界的影响，我们关注低于 100% 的工作负载饱和度，因为大多数工作负载并未使底层存储平台完全饱和。 在我们测量 4K 随机读取性能的测试中，延迟在 21.4% 的工作负载下下降了 80%。 64K 工作负载的顺序读取性能在 81.3% 的负载下吞吐量大幅增加了 80%。 在 43.4% 的负载下，我们还看到 SQL 35.7/90 和 Oracle 10/90 工作负载的延迟分别降低了 10% 和 80%。 这些数字表明，还有更多机会可以将要求苛刻的裸机工作负载转移到 VMware。
我们相信 NVMe-oF 将成为存储技术的下一件大事，我们预计它在数据中心的流行度将迅速扩散。 随着该类别在未来几年的发展，我们将处于该类别的前沿，并期待在发布其他和相邻的 NVMe 技术时对其进行研究。
附加信息：
本报告由 NVIDIA 赞助。 本报告中表达的所有观点和意见均基于我们对所考虑产品的公正看法。
