NVMe-over-Fabrics：高性能存储解聚的分析与评估

ACM Transactions on Storage，Vol.号144、第三十一条。出版日期：2018年12月NVMe-over-Fabrics存储解聚Zvika Guz，Harry（Huan）Li，Anahita Shayesteh和Vijay Balakrishnan，Samsung Semiconductor，Inc存储分解将计算和存储分离到不同的节点，以允许独立的资源扩展，从而提高硬件资源利用率。虽然硬盘驱动器存储的分解是常见的实践，但NVMe-SSD（即，基于PCIe的SSD）分解被认为更具挑战性。这是因为SSD明显快于硬盘驱动器，因此延迟开销（由于网络和CPU处理）以及卸载堆栈所需的额外计算周期变得更多31宣布在这项工作中，我们的特点NVMe-SSD分解的开销。我们表明，NVMe-over- Fabrics（NVMe-oF）-最近发布的远程存储协议规范-将远程访问的开销降低到最低限度，从而大大提高了闪存分解的成本效益。具体而言，虽然最近的工作表明，通过iSCSI进行SSD存储分解会使应用程序级吞吐量降低20%，但我们报告的NVMe-oF性能下降可以忽略不计-无论是在使用压力测试时还是在使用更现实的KV存储工作负载时。CCS概念：·硬件→外部存储; ·信息系统→固件;存储管理;其他关键词和短语：NVMe over Fabric、性能表征、网络存储ACM参考格式：Zvika Guz，Harry（Huan）Li，Anahita Shayesteh，and Vijay Balakrishnan.2018年NVMe-over-Fabric存储 分 解 的 性 能ACM Trans.存 储 14 ， 4 ， 第 31 条 （ 2018 年 12 月 ） ， 18 页 。https://doi.org/10.1145/32395631引言NVMe-SDD（即，基于PCIe的SSD）在为数据中心和企业部署中的I/O密集型应用提供服务方面变得越来越流行这是因为与SATA-SSD和SAS-SSD相比，它们的性能非常出色（在带宽和延迟方面），可以很好地满足I/O密集型应用程序（主要是关系数据库和NoSQL数据库）不断增长的吞吐量需求单个当前一代NVMe-SSD可维持高达100万次IOPS，读取延迟为90μ s [56]-比当前一代SAS-SSD高5倍以上，这篇文章的早期版本发表在第10届ACM国际系统和存储会议（ACM '17）上。作者Guz，H.（Huan）Li，A.Shayesteh和V.Balakrishnan;存储器平台实验室，三星半导体公司，3655 N 1st St，San Jose，CA 95134;电子邮件：{zvika.guz，harry.li，anahita.sh，vijay.bala@}samsung.com.允许制作部分或全部本作品的数字或硬拷贝供个人或课堂使用，无需付费，前提是复制品不以营利或商业利益为目的制作或分发，并且复制品在第一页上带有此通知和完整的引用必须尊重本作品第三方组件的版权对于所有其他用途，请联系所有者/作者。版权所有2018由所有者/作者持有1553-3077/2018/12-ART 31https://doi.org/10.1145/3239563ACM Transactions on Storage，Vol.号144、第三十一条。出版日期：2018年12月三十一：2Z. Guz等人图1.一、NVMe-over-Fabrics架构。比SATA-SSD好40倍事实上，许多大型云计算公司已经报告使用基于PCIe的SSD作为其基础设施的一部分[19，31，49，57]。通常，存储设备可以共同位于计算服务器节点内，或者放置在通过网络访问的专用存储节点中。大型云计算公司最初使用横向扩展基础设施，由紧密耦合内存，存储和计算的商品服务器组成数据中心[3，38]。不幸的是，这种方法会导致效率低下和资源利用不足，因为它固定了计算、内存、存储和网络之间的比例数据中心的资源利用不足是一种常见的、有据可查的现象[3，31，36，49]。由于不同资源的使用随时间而变化，主要是彼此独立，因此没有一个单一的静态资源平衡适合服务器在其整个生命周期中支持的每个应用程序。由于大规模改变这些比率在经济上是不可行的[51]，服务器资源往往过度配置，导致总拥有成本增加[3]。具体而言，NVMe-SSD往往在负载（IOPS）和容量方面过度配置：容量过度配置以允许未来的增长，而负载未得到充分利用，因为其他软件开销往往会在达到驱动器限制之前使CPU饱和[11，49]。事实上，基于PCIe的Flash已经被认为是“非常快的”[ 64 ]。资源分解是缓解过度配置问题的常用方法具体地，存储解聚将计算和存储分散到不同的节点（即，不同的服务器），允许根据动态需求独立扩展每个资源在根据特定负载调整基础架构时，它提供了更大的灵活性，因为可以针对具体需求而不是平均或最大预期负载来配置计算和存储反过来，它可以通过减少资源浪费来大大提高数据中心的成本效率尽管有潜在的优点，但存储分解是有代价的。由于存储设备是通过网络访问的，因此每次存储访问都会增加互连延迟，从而对访问时间产生不利影响。此外，额外的网络处理和远程存储协议本身的开销对存储服务器和计算节点上的CPU都造成负担，与直接连接的配置相比，进一步降低了应用吞吐量。硬盘驱动器（HDD）分解是常见的，因为HDD然而，NVMe-SSD最近一项关于通过iSCSI进行NVMe-SSD分解的研究证明了闪存分解的成本优势，但也报告了应用程序级性能平均下降20%[31]。NVMe-over-Fabrics存储解聚的性能表征三十一：3ACM Transactions on Storage，Vol.号144、第三十一条。出版日期：2018年12月NVMe-over-Fabrics（NVMe-oF）[48]是一个最近的协议标准，用于通过支持RDMA的网络访问NVMe设备（参见第2节）。通过利用RDMA，NVMe-oF将数据移动卸载到网卡（NIC），从而减少了在主机和目标上处理远程I/O请求所涉及的处理开销。由于处理开销是使用分散式NVMe-SSD时性能下降的主要原因（参见第4节），因此NVMe-oF预计更适合作为分散式存储的底层远程存储协议。然而，作为相对较新的标准，NVMe-oF及其开销的可用性能表征数据很少。本文将使用NVMe-oF作为远程存储协议，重新审视NVMe-SSD分解。我们表明，NVMe-oF最大限度地减少了应用程序所经历的性能下降，从而显着提高了NVMe分解的效率和可行性。我们还提出了一个详细的NVMe-oF性能分析。首先，在第4节中，我们使用合成压力测试来表征和分解NVMe-oF延迟和吞吐量开销，并将其与iSCSI进行比较。然后，在第5节中，我们使用RocksDB和MySQL作为现实世界I/O密集型工作负载的示例此外，我们还表明，与iSCSI相比，NVMe-oF最后，在第6节中，我们展示了存储服务器的处理效率和可扩展性可以通过使用SPDK NVMe-oF Target [25]进一步总之，本文认为NVMe-oF有助于NVMe-SSD分解：它保留了以前文献中讨论的所有优点，但进一步最大限度地减少了性能影响，从而显著提高了成本效率。2NVME织物Non-Volatile Memory Express（NVMe）是一种经过优化的高性能软件接口标准，用于通过PCIe访问本地非易失性存储器设备[20]。NVMe基于大量深度、成对的提交和完成队列，分配在主机内存中。这些成对的并行队列是NVMe驱动程序和NVMe控制器之间的接口，NVMe驱动程序和NVMe控制器协同管理它们。虽然存在其他专有协议[4，16]，但NVMe是基于PCIe的SSD设备的主导和最广泛的技术。在本文中，我们交替使用术语基于PCIe的SSD和NVMe-SSD。NVMe-over-Fabrics [48]是NVMe标准的最新扩展，它允许通过不同的网络结构访问远程NVMe设备。它消除了到远程设备的I/O路径上不必要的协议转换（如SCSI），从而暴露了NVMe的多对队列设计。其目标是为应用程序提供快速的存储访问，无论NVMe-SSD是本地连接还是远程访问; NVMe-oF旨在将远程访问的开销保持在10μ s以下。NVMe-oF目前支持两种类型的结构传输：RDMA和光纤通道。在这两者中，RDMA在传统HPC领域以及现代数据中心中都享有更广泛的可用性[8，21，30，32，37，42，61]。远程直接存储器访问（RDMA）是一种远程存储器管理能力，其在没有CPU参与的情况下通过网络将数据从一个机器的存储器移动到另一个机器的存储器RDMA通过以下方式实现低延迟、高吞吐量的远程访问：（1）使用零拷贝网络：数据直接传输到应用程序内存或从应用程序内存传输，无需像TCP/IP那样在网络层之间复制数据;（2）使用内核旁路：应用程序直接从用户空间执行数据传输，无需内核参与;（3）消除CPU参与：RDMA传输不会消耗CPU周期或污染CPU缓存。三十一：4Z. Guz等人ACM Transactions on Storage，Vol.号144、第三十一条。出版日期：2018年12月RDMA可以在不同的链路层协议上实现它最初与InfiniBand相关[35]，需要特殊用途的互连。最近的两个基于以太网的替代方案- RoCE和iWARP-提供了一个更具成本效益的解决方案，预计将增加数据中心领域中的RDMA采用。RoCE（融合以太网上的RDMA）[7]基于以太网上的InfiniBand传输，并使用以太网上的RDMA和UDP/IP帧。iWARP（interent Wide Area RDMA Protocol）[9]在面向连接的传输（如TCP）上使用RDMAiWARP和RoCE都需要专门的支持RDMA的交换机，但都可以在基于以太网的现代交换机上运行与InfiniBand相比，这大大减少了基础设施投资1虽然在标准以太网上运行iWARP比运行RoCE更便宜，但RoCE提供更低的延迟，并且拥有强大的追随者。最近，RoCE似乎正在获得动力，并被OEM采用（例如，参考文献[47]）; RoCEv 2是我们的NVMe-oF评估中使用的织物图1（a）显示了主机和目标的NVMe-over-Fabric堆栈。主机驱动程序包含常见的NVMe主机核心以及PCIe和RDMA传输。目标驱动程序包含NVMe目标核心和RDMA传输。这两个驱动程序共享共同的NVMe和NVMe-oF数据结构、排队接口、命令和属性，这些都独立于NVMe传输层。NVMe传输绑定（NVMe-RDMA块）将NVMe-over-Fabrics绑定到NVMe传输层，并且特定于结构协议和物理层。在进行传输之前，主机与目标中的NVM控制器进行关联（连接），从而在I/O提交队列和I/O完成队列之间创建一对一映射NVMe队列与CPU核心对齐，并与RDMA专用发送（SQ）和响应（RQ）队列对和完成队列配对（参见图1（b））。这种具有端到端配对的队列设计将NVMe的固有并行性暴露给远程主机。当关联存在时，NVMe主机驱动程序将NVMe命令和响应封装到结构中立的命令封装中，并将其传递到NVMe RDMA传输。封装体是从主机转移到NVM子系统的NVMe单元[48]。3方法本节描述了我们研究中使用的硬件和软件设置我们的非分解基准配置使用双插槽Xeon E5-2690 v4服务器[23]，具有128 GB DDR4存储。它配备了一个PM 1725 NVMe-SSD [56]-一个高端企业驱动器，支持高达750（120）KIOPS的随机读（写）流量和3GB/s（2GB/s）的顺序读（写）带宽。我们将此配置称为直接连接存储（DAS）或本地服务器。在评估远程存储时，我们使用三个这样的DAS服务器，并将其驱动器移动到指定的存储服务器（称为目标）。三个基线节点现在通过网络访问驱动器，并被称为主机（或网络服务器[31]）。目标节点是四插槽Xeon E7-8890 v4服务器[23]，配备512 GB DDR4内存和相同的三个NVMe-SSD驱动器。为了减少噪音并允许更清晰的比较，我们在所有服务器上禁用超线程以及所有服务器都使用单个ConnectX-4 100 Gb以太网NIC [39]，提供以太网上的RDMA（RoCE）功能，并通过100 Gb以太网交换机连接[40]。对于远程存储配置，我们通过RoCE评估iSCSI和NVMe-oF由于数据中心主要使用以太网，因此我们使用RoCE而不是InfiniBand进行底层互连（如1与iWARP不同，RoCE要求交换机支持数据中心桥接（DCB）。虽然旧交换机不支持DCB，但它在新的高带宽交换机中变得越来越普遍NVMe-over-Fabrics存储解聚的性能表征三十一：5ACM Transactions on Storage，Vol.号144、第三十一条。出版日期：2018年12月第2节）。对于NVMe-oF，我们将每个远程驱动器的I/O队列数设置为44。我们根据已知的最佳实践（例如，[31]）。我们在性能分析中使用两类工作负载首先，对于压力测试，我们使用fio[2]来生成合成I/O流量。我们使用4K随机流量在CPU和远程存储堆栈上创建最高负载 我们还通过使用fio的直接I/O模式绕过了操作系统页面缓存。然后，为了模拟更真实的数据中心工作负载，我们使用RocksDB和MySQL作为两个I/O密集型应用程序的示例，这些应用程序广泛用于许多数据中心的生产堆栈[14，46]。RocksDB [15]是一个流行的KV存储库，既用作可嵌入的单节点，KV数据库，并作为大型分布式数据库管理系统（DBMS）中的存储引擎。我们使用RocksDB我们使用800 B和10 KB值对16 B键进行建模，并使用80/20读写混合。虽然一些RocksDB安装可能与较大的对象一起使用[31]，但我们选择了较小的对象来进一步强调我们的系统。我们还限制了操作系统页面缓存，以便更多的请求将从驱动器而不是从DRAM提供服务。MySQL [45]是一个开源的关系数据库管理系统（RDBMS）。我们使用TPC-C [10]-一种在线事务处理（OLTP）工作负载-来描述MySQL的性能。具体来说，我们使用tpcc-mysql [33]来创建数据库，生成负载，并测量性能（以每分钟事务数（tpmC）报告）。我们将数据库大小设置为500个仓库（50GB），并在每个MySQL服务器上运行两个独立的MySQL实例，每个实例有150个连接在所有配置（DAS、NVMe-oF和iSCSI）中，我们使用单独的驱动器来存储数据库和MySQL日志文件，因为它在所有情况下都可以提高整体性能由于我们的MySQL研究侧重于评估Flash分解可伸缩性（参见第5.2节），因此我们使用多达10个数据存储服务器（而不是其他实验中的3个），并使用8个PM1725驱动器（而不是3个）填充目标节点我们还使用两个额外的客户端来运行tpcc-mysql并驱动事务。客户机的硬件与服务器的硬件类似，尽管它们的规格对于本研究来说并不重要：在所有情况下，我们都虽然所有数据存储都运行TPC-C，但请注意，我们模拟的是多数据库环境，而不是单个集群MySQL部署。所有实例都是独立的，每个实例都对自己的数据库副本进行操作4NVME-OF性能分析在本节中，我们使用合成I/O流量（使用fio生成）来研究NVMe- oF相对于直连存储的开销我们还描述了通过iSCSI进行远程存储访问的特征，以量化通过使用NVMe-oF和RDMA实现的性能节省在第4.1节中，我们检查了最大负载下的性能，在第4.2节中，我们描述了不同系统操作点下的延迟和4.1最大负载表征图2显示了DAS、iSCSI和NVMe-oF在不同读写比下获得的最大IOPS对于DAS和NVMe-oF，我们使用了16个作业，其中有32个动态请求;对于iSCSI，我们使用了44个作业，其中有44个动态请求，因为这些配置为每个设置提供了最佳性能DAS在所有情况下都会使三个驱动器饱和，并作为性能的上限从图中可以看出，NVMe-oF性能（红色条）实际上与DAS相同，所有情况下的差异均小于1%但是，iSCSI吞吐量（绿色条）明显低于DAS和NVMe-oF：在只读测试中，iSCSI提供1.4 MIOPS，仅利用驱动器可用IOPS的60%。 iSCSI性能受到低效的网络堆栈和协议处理开销的阻碍，例如从NVMe到SCSI的不必要的协议转换。在三十一：6Z. Guz等人ACM Transactions on Storage，Vol.号144、第三十一条。出版日期：2018年12月图二、DAS、NVMe-oF和iSCSI可实现的最大吞吐量（IOPS）图3.第三章。DAS、NVMe-oF和iSCSI的主机CPU利用率此外，与NVMe-oF不同，iSCSI不能暴露NVMe随着更多的写操作被添加到指令组合中，由于驱动器的非对称读/写操作（一个PM 1725驱动器可以分别维持750和120 KIOPS的读和写流量），所有配置的整体性能都会下降当总IOPS以及整体系统负载下降时，iSCSI能够支持降低的IOPS，实现接近DAS和NVMe-oF的性能请注意，除了较差的性能外，iSCSI还显著增加了CPU开销，如图3所示。虽然NVMe-oF最多增加4.3%的主机CPU总体利用率，但iSCSI开销可能会增加高达30%。对于需要比fio更多计算资源的实际工作负载，这些开销将进一步降低应用程序性能，因为它们显著减少了整体可用系统资源。图4更深入地介绍了只读测试的CPU利用率，显示了主机和目标上的每核利用率图4（a）中的用户时间表示运行fio应用程序所花费的时间，其中Sys时间用于网络和存储协议以及内核模式处理。除了系统和用户之外，iSCSI配置中的主机还花费大量时间来维护软件中断（软）。这是一个与TCP/IP显著中断处理开销相关的已知问题;它可以从通过亲和性设置分发中断中受益[31]。在我们的实验中，我们没有看到通过设置中断亲和性的明显改善，可能是由于我们机器的高核心数对于NVMe-oF主机，总体CPU利用率从DAS中的13%略微增加到NVMe-oF中的17%，并且处理仅限于一个插槽。相反，在iSCSI设置中，主机中两个插槽上的核心的平均利用率为43%在目标端，图4（b）显示了系统中活动核心的利用率。在96个核中，仅利用了24个核，即，四个可用插座中只有一个图中报告的平均利用率数字涵盖了所有核心，这解释了NVMe-over-Fabrics存储解聚的性能表征三十一：7ACM Transactions on Storage，Vol.号144、第三十一条。出版日期：2018年12月×图四、fio只读测试期间（a）主机和（b）目标的平均每核CPU利用率 我们将DAS视为主机，并在（a）中显示其数据。 为了清晰起见，我们只显示目标节点上的活动核心。图五、目标上不同核心数的总体IOPS和核心利用率低数字。NVMe-oF和iSCSI在活动核心上都具有很高的利用率。但是，请注意，对于只读测试，iSCSI最后，为了进一步研究目标开销和计算要求，我们重复了CPU密集型测试（只读和80/20读/写），同时仅启用目标上可用的核心的子集如图5所示，由于NVMe-oF每个IO需要较少的CPU资源，因此其性能会随着内核数量的减少而缓慢下降即使只有1/12的内核启用（红色对角线），NVMe-oF性能仍然在只读测试的本地存储的90%以内随着可用内核数量的减少，iSCSI性能下降的速度会更 对于只读情况，性能下降超过2，达到相同情况下最大IOPS的26%（绿色对角线）。 NVMe-oF在目标节点上的低开销对于数据中心的成本效率尤其重要，因为它允许存储服务器使用更多的驱动器和更少的处理器（或性能较低的处理器），从而在不牺牲性能的情况下降低总体TCO。4.2延迟和吞吐量分析图6显示了DAS、NVMe-oF和iSCSI在不同请求负载下的延迟我们使用一个4KB的只读请求流，并显示平均和尾部（第95百分位）延迟。从图中可以看出，NVMe-oF在整个负载范围内的性能几乎与DAS相同-除第一次（2%负载）运行外，平均延迟在3.5%的差异范围事实上，NVMe-oF尾喷管在轻到中高负载时略优于DAS相同的三十一：8Z. Guz等人ACM Transactions on Storage，Vol.号144、第三十一条。出版日期：2018年12月×图六、不同请求负载的DAS、NVMe-oF和iSCSI的平均延迟和尾延迟 由于iSCSI较早达到饱和，并且表现出明显更高的延迟，因此我们展示了全范围视图（a）以及DAS和NVMe-oF的放大视图（b）。图7.第一次会议。DAS、NVMe-oF和iSCSI在不同负载下的读取延迟CDFMintrum [43]还报告了NVMe-oF性能略高于DAS的现象，并将其归因于RDMA NIC中的中断合并事实上，在所有实际负载情况下，本地连接的NVMe-SSD的性能和远程NVMe-oF访问的性能几乎相同。与NVMe-oF不同，与本地存储访问相比，iSCSI延迟明显更长。首先，在DAS（和NVMe-oF）延迟开始呈指数级攀升之前，iSCSI就会饱和，1.5 MIOPS，DAS为2 MIOPS其次，即使对于相对较轻的负载，与访问本地存储所需的时间相比，iSCSI也会增加显著的延迟当以50%的驱动器容量运行时，平均延迟为2.5ms-超过本地访问延迟的10尾部延迟的差异甚至更大：为了将第95百分位延迟保持在2ms以下，我们只能以最大驱动器IOPS容量的17%运行相反，DAS和NVMe-oF的第95百分位延迟我们的研究结果表明，与iSCSI不同，NVMe-oF不会给远程访问带来额外的延迟，即使是对延迟最敏感的应用程序也可以部署，而不会带来性能损失。为了进一步比较NVMe-oF和DAS延迟，图7显示了三种不同负载下端到端读取延迟的累积分布（CDF）。所有三种配置的卸载延迟（图7（a）; 1个作业，1个运行中请求）相对接近：DAS、NVMe-oF和iSCSI的平均延迟分别为83.5μ s、95.2μ s和145.8μ sNVMe-oF增加了11.7μ s延迟，非常接近规格iSCSI增加62μ s。虽然更大，但对于大多数数据中心用例来说仍然是可以接受的。类似地，尾部延迟也很接近：DAS、NVMe-oF和iSCSI的第95百分位延迟分别为96μ s、110μ s和197μ s（即，NVMe-oF的开销为14μ s，iSCSI的开销为101μ s然而，当我们增加负载，NVMe-over-Fabrics存储解聚的性能表征三十一：9ACM Transactions on Storage，Vol.号144、第三十一条。出版日期：2018年12月图8.第八条。卸载读取请求的NVMe-oF端到端延迟的细分在系统中（图7（b）和7（c）），iSCSI的开销变得比DAS高得多，而NVMe-oF开销（平均和尾部）保持最小。由于我们希望在这些图中重点关注NVMe-oF，因此我们让iSCSI超出了图的范围。最后，图8显示了未加载NVMe-oF读取延迟的细分。 我们使用ftrace [54]来跟踪每个模块花费的时间，我们使用DAS读取测试来得出本地访问所总体而言，NVMe-oF比本地NVMe访问慢11.7μ s主机上的NVMe-oF相关模块占开销的27%（块层，NVMe驱动程序和RDMA堆栈;参见图1（a））; NVMe-oF目标模块（图1（a）中的RDMA堆栈和NVMe_T网络和交换机使总延迟再增加2.43μ s。最后，额外的13%花费在任何NVMe-oF模块之外。虽然我们没有进一步细分这种延迟，但它包括中断传递延迟、内核调度延迟以及与用户和内核空间之间切换相关的开销英特尔实际上，我们在DAS和NVMe-oF目标节点上运行SPDK的实验在两种配置下都减少了2.84μs。换句话说，与DAS相比，使用NVMe-oF SPDK目标[25]将NVMe-oF卸载读取的额外延迟减少到8.9μ s，并与使用SPDK的本地访问相比保留11.7μ s的开销5离散数据库与KV存储虽然在第4节中我们使用微基准压力测试来表征NVMe-oF性能，但实际数据中心工作负载可能具有非常不同的系统特性，并且通常对节点的I/O系统要求较低。通常情况下，附加驱动器的利用率很低[31，49，65]，因为其他系统瓶颈在驱动器之前饱和。此外，每I/O计算相对于我们的fio测试而言，fio的计算密集度更高，因为（1）fio本质上比完整的应用程序计算密集度更低，（2）DRAM缓存过滤掉了一些I/O，这是我们的直接fio测试没有建模的效果;以及（3）与数据中心服务相关联的各种软件（在本节中，我们将使用RocksDB和MySQL（这两种数据库广泛用于许多数据中心的生产堆栈[14，46]）来描述更现实的闪存分解方案，并量化其预期收益。5.1KV-Store分类图9显示了通过iSCSI和NVMe-oF使用本地存储与远程存储的RocksDB性能（以每秒操作数表示）（有关RocksDB和db_bench配置的详细信息，请参见第3我们使用10KB的对象作为我们的基线，类似于Klimovic等人。[31]，代表典型的RocksDB生产负载。此外，我们还展示了较小的800 B物镜的性能对于更小的对象，每秒执行的事务更多，进一步加重了远程存储设置的压力。如图所示，虽然iSCSI性能明显低于本地存储（性能下降40%），但NVMe-oF性能仅为本地存储的2%，可以忽略不计三十一：Z. Guz等人ACM Transactions on Storage，Vol.号144、第三十一条。出版日期：2018年12月图9.第九条。RocksDB针对DAS、NVMe-oF和iSCSI的最大吞吐量 我们展示了两种对象大小的结果：800B和10KB。图10个。RocksDB工作负载的主机和目标上的平均CPU利用率图十一岁Ro c k s D B NVMe-oF运行200秒期间NVMe-oF目标节点上的瞬时NVMe-SSD带宽。在带宽峰值期间，所有三个驱动器都会饱和（3GB/s读取）DAS。实际上，就整体性能而言，主机在本地访问驱动器时与通过NVMe-oF远程传输在处理开销方面（参见图10），虽然NVMe-oF确实将主机CPU利用率提高了10%，但在大多数情况下，这种适度的开销应该是可以接受的。虽然目标上的CPU利用率已经相对较低，但在第6节中，我们展示了通过使用SPDK NVMe-oF目标可以大幅降低CPU利用率iSCSI的CPU利用率是为了完整性而给出的，但很难将其与NVMe-oF进行比较，因为整体性能要低得多。图11显示了工作负载运行期间NVMe-oF目标节点上NVMe-SSD带宽的波动这些带宽波动是RocksDB后台进程的属性，也是预期的RocksDB行为。如图所示，NVMe-oF目标计算机NVMe-over-Fabrics存储解聚的性能表征三十一：ACM Transactions on Storage，Vol.号144、第三十一条。出版日期：2018年12月图12个。RocksDB读取DAS和NVMe-oF的CDF延迟，具有800 B对象。图13岁DAS、NVMe-oF和iSCSI的TPC-C性能，随着MySQL（和TPC-C）实例数量的 由于DAS配置不跨节点共享资源，因此其扩展性能是从单个服务器的性能预测的。能够使所有三个NVMe驱动器饱和：在带宽峰值期间，所有驱动器都达到3GB/s（驱动器峰值读取DAS和NVMe-oF设置都会使NVMe驱动器饱和但是，请注意，在DAS配置中，三台主机中的每一台都包含一个NVMe SSD，而对于NVMe-oF配置，目标计算机处理所有三个驱动器，峰值SSD带宽为7.8GB/s。最后，图12绘制了db_bench报告的NVMe- oF和DAS的累积读取延迟分布对于图12，我们使用800 B对象，并在降低的负载（70%）下运行，这样我们就不会接近饱和点运行。我们在此图中省略了iSCSI由于我们在使用iSCSI时无法达到相同的负载下的NVMe-oF读取延迟与本地存储相当：NVMe-oF平均延迟比DAS高11%（60μ s），第99百分位延迟开销为可忽略的2%（83μ s）。5.2分解RDBMS图13显示了随着MySQL实例数量的增加，使用本地存储与通过iSCSI和NVMe-oF的远程存储的TPC-C性能（以每分钟事务数表示）（有关MySQL和TPC-C配置的详细信息，请参见第3从图中可以看出，虽然iSCSI性能随着服务器数量的增加而落后，但NVMe-oF性能扩展良好。对于20个MySQL实例，NVMe-oF性能在DAS预计性能的82%以内，而iSCSI性能仅为49.2%。TPC-C是CPU密集型的：运行两个MySQL实例时DAS服务器的CPU利用率为86%。与此同时，NVMe-SSD没有得到充分利用：总I/O带宽仅为612 MB/s-仅为设备3GB/s最大带宽的26%。因此，存储隔离三十一：Z. Guz等人ACM Transactions on Storage，Vol.号144、第三十一条。出版日期：2018年12月×图14个。随着NVMe-SSD驱动器数量的增加，DAS、NVMe-oF和iSCSI的最大TPC-C性能存储分解允许跨多个MySQL服务器共享驱动器，并提供更高的每个驱动器的整体性能与iSCSI不同，NVMe-oF性能不受协议开销的影响，并且比本地存储配置性能高出2倍以上。图十五岁运行越来越多的TPC-C实例时目标节点上的平均CPU利用率虽然两种配置的CPU利用率相似，但请注意，NVMe-oF的整体性能更高。在这种情况下，允许更有效地利用资源，因为它允许在多个MySQL实例之间共享相同的驱动器实际上，当运行20个MySQL实例时，tar-get节点只使用8个驱动器，而本地存储配置将使用20个。图14进一步显示了这一点，它绘制了图13中三种配置中每种配置的所有运行中给定驱动器数量的最大TPC-C性能如图所示，对于相同数量的驱动器，分散存储提供比DAS更高的性能，因为驱动器在多个MySQL实例之间共享;由于相同数量的驱动器支持更多数量的MySQL实例，因此整体TPC-C性能更高。但是，尽管iSCSI开销限制了性能，但NVMe-oF提供的每个驱动器性能是DAS的2倍以上。最后，图15显示了iSCSI和NVMe-oF的目标节点的CPU利用率从图中可以看出，目标CPU的利用率很低，在成为瓶颈之前，它可以支持更多的服务器和驱动器我们没有将扩展到超过20个MySQL实例，因为我们已经耗尽了可用于实验的MySQL服务器的数量6用SPDK提高服务器效率在分散存储环境中，专用存储服务器为多个计算节点提供服务，并针对高存储容量和高I/O性能进行了优化。如第4.1节所示，NVMe-oFNVMe-over-Fabrics存储解聚的性能表征三十一：ACM Transactions on Storage，Vol.号144、第三十一条。出版日期：2018年12月图十六岁对于4 KB随机读取fio工作负载，目标上不同核心数的总体IOPS蓝色虚线显示系统中的最大IOPS，通过在DAS模式下运行来测量驱动器和更少的处理器，从而在不牺牲性能的情况下降低总体TCO在本节中，我们将展示使用SPDK-用户模式NVMe-oF驱动程序-数据中心可以进一步减少目标节点上的开销并提高其效率，而无需更改计算节点或应用程序。SPDK NVMe驱动程序提供比基于内核的驱动程序更高的性能，适用于高性能存储应用程序[63]。具体来说，通过将驱动程序移动到用户空间，SPDK消除了I/O路径上的上下文切换和多个数据副本，从而减少了处理开销并提高了CPU利用率。虽然性能优于操作系统驱动程序，但用户空间驱动程序并不是一个简单的替代品，因为需要修改应用程序才能显式地管理驱动器。除了SPDK本地驱动程序之外，SPDK工具包还包含一个SPDK NVMe-oF目标库[26]，该库提供在用户空间中运行整个NVMe- oF目标路径所需的所有原语该工具包还包含一个SPDK NVMe-oF目标应用程序[25]，该应用程序使用这些原语来实现完整的用户空间NVMe-oF目标。与SPDK驱动程序不同，在存储节点上运行SPDK NVMe-oF目标应用程序不需要在主机端进行任何在本节中，我们将在存储节点上运行SPDK NVMe-oF目标应用程序，并描述其性能优势和CPU负载的减少图16显示了只读fio工作负载的总体性能，此时仅激活目标上96个核心的一个子集（对于NVMe-oF和iSCSI，我们在BIOS中设置活动核心的数量;对于SPDK，我们在启用SPDK目标时通过核心掩码定义核心的数量DAS、NVMe-oF和iSCSI的数据与图5中的数据相同，此处提供这些数据是为了便于比较。从图中可以看出，SPDK NVMe-oF目标仅使用三个活动内核就可以使所有三个相比之下，NVMe-oF需要16个核心才能达到最大性能的90%。图17进一步显示了同一次运行期间活动核心的CPU利用率和目标上的总体系统利用率。与NVMe-oF和iSCSI不同，使用SPDK（橙色实线）运行时活动内核的利用率始终为100%，因为驱动程序以轮询模式运行。但是，使用SPDK的总体系统利用率明显较低：使用三个内核时，目标利用率仅为3.1%，而使用16个内核时，NVMe-oF的目标利用率为15.8%这种CPU负载的减少非常重要，因为它有助于扩展-专用存储服务器可以支持大量设备并提供非常高的I/O性能，而CPU不会成为瓶颈。为了完整起见，图18显示了SPDK在三个核心上运行时目标上的每核心CPU利用率。与NVMe-oF和iSCSI（参见图4（b））相比，三个活动核心得到充分利用，仅保留在用户空间中。最后，我们将RocksDB与SPDK结合使用，以在运行实际数据中心工作负载时实现目标上的预期节省图19显示了RocksDB的性能（以三十一：Z. Guz等人ACM Transactions on Storage，Vol.号144、第三十一条。出版日期：2018年12月图十七岁4KB随机读取fio工作负载的目标节点上的系统利用率（虚线）和活动内核利用率（实线）图十八岁在 3个核心上运行4 KB随机读取fio工作负载（使用SPDK NVMe-oF目标）时，目标节点的平均每核心CPU利用率。核心只存在于用户空间中。图十九岁DAS、NVMe-oF和SPDK NVMe-oF目标的RocksDB吞吐量 虽然在目标上为NVMe-oF启用了所有内核，但SPDK在1、2和3个内核上运行。对于小型对象（800 B），使用SPDK NVMe-oF目标时，DAS和NVMe-oF性能与图9相同，并在图中显示以进行比较。所有配置之间的性能差异很小，但使用SPDK可以进一步降低目标服务器上与NVMe-oF不同的是，SPDK仅用一个内核就能达到RocksDB的本地性能，从而将目标系统的总体利用率从NVMe-oF的12%降低到SPDK的1%。7相关工作分解是一种众所周知的方法，用于实现计算硬件模块化并解决导致过度配置的不平衡资源需求[17]。HDD分解[1，22，34，41，51，62]很常见，因为与访问旋转磁盘上的数据的延迟相比，网络开销微不足道本文重点介绍基于PCIe的SSD分解，由于NVMe-SSD的原始吞吐量和延迟，这带来了重大挑战NVMe-over-Fabrics存储解聚的性能表征三十一：ACM Transactions on Storage，Vol.号144、第三十一条。出版日期：2018年12月Klimovic等人[31]评估使用iSCSI的闪存分解它们表明，即使iSCSI远程访问在应用程序级别引入了20%的吞吐量下降，但分解通过独立扩展CPU和闪存资源弥补了这一开销。我们通过评估NVMe-oF上的分解扩展了他们的工作，并表明NVMe-oF将应用性能影响降至最低，从而大大提高了成本效率和实用性。超融合基础设施（HCI）是一种软件定义的方法，将每个包含计算和存储的通用服务器捆绑到集群池中[53]。它通过虚拟计算平台