【论文】DAOS与Lustre对象数据存储性能比较
摘要
高性能对象存储是一项新兴技术，为高性能计算（HPC）存储领域提供了一种备选解决方案，有望解决传统分布式POSIX文件系统中由于过度的一致性保证和元数据规范所导致的长期可扩展性问题。
在本文中，我们对存储类似对象数据的标准文件系统性能进行了评估，其中配置和访问机制未经过为对象访问行为的优化，并将其与使用对象存储系统的优势进行了比较和研究。尽管这种方法未能以标准方式利用文件系统，但此研究使我们能够调查底层存储技术的性能是否比文件系统或对象存储提供的软件界面和基础设施更为关键。
I. 引言
对象存储被视为解决长期存在的可扩展性问题的POSIX文件系统的备选方案，其中包括过度的一致性保证和规范性[1]。数值天气预测（NWP，NumericalWeather Prediction）通常牵涉到类似对象的数据访问，因为全球天气场的大小目前大约为1 MiB，相对较小。与传统的高性能I/O相比，NWP需要先进的语义发现和访问，涉及多个元数据操作。为了满足当前NWP性能需求，我们已经开发了专用领域的对象存储，用于在传统分布式文件系统上实现这种语义索引[2]。随着NWP模拟计划中分辨率的提高，数据集的大小增加了一到两个数量级，并且通用高性能对象存储的出现使得适应NWP中常见的类似对象操作的特定领域存储成为一种越来越指的关注的方案。
在最近的一项研究中，作为验证先前研究的工作，我们评估了DAOS，这是一种备受关注的高性能对象存储。通过模拟NWP应用场景中的I/O模式，我们使用与存储级内存（SCM）相结合的专用基准测试，评估了DAOS在这些操作中的性能[3]。
在本文中，我们回顾了DAOS的性能结果，并将其与使用Lustre获得的相应性能结果进行比较。Lustre是HPC中最流行的分布式文件系统之一，我们对其进行了专门调整，以执行对象操作，并进行了与DAOS的比较。这项工作使我们能够区分使用特定存储硬件所带来的好处与对象存储设计和实施所带来的好处。此外，它还使我们能够得出关于对象存储的一般优势的结论，并提供了在相同硬件和软件环境下比较Lustre和DAOS的实际应用场景数据点。
II. DAOS
分布式异步对象存储（DAOS）[4]是一款开源的高性能对象存储系统，专为大规模分布式非易失性内存（NVM）包括SCM和NVMe而设计。在低级别，它提供键值存储接口，而更高级别的API则构建在其之上。其特性包括事务性非阻塞I/O、细粒度I/O操作、对SCM的零拷贝I/O、端到端数据完整性和先进的数据保护。DAOS应用OpenFabrics Interfaces（OFI）库，以实现在广泛的网络后端上的低延迟通信。
DAOS可被部署为一组I/O进程或引擎，每个服务器节点的物理插槽一个，每个引擎管理插槽内的SCM和NVMe设备的访问。引擎将其管理的存储分区划分为目标以优化并发性，每个目标由一组专用线程管理和导出。DAOS允许在所谓的池中分布式保留空间，这是一种虚拟存储形式。一个池可以为多个被称为容器的事务性对象存储提供服务。容器是一个私有的对象地址空间，可以在不影响同一池中的其它容器的情况下进行事务性和独立修改。应用程序首先需要连接到池，然后打开所需的容器。如果成功授权，应用程序将获得一个句柄，可用于其进程与容器进行交互。
创建时，容器中的对象被分配一个128位的唯一对象标识符，其中96位由用户管理。通过指定其对象类，可以为复制和在池目标之间进行分带配置对象。配置为分带的对象以部分存储，分布在目标之间，实现并发访问。
III. LUSTRE
Lustre [5]是全球HPC站点主要使用的并行文件系统。作为一款开源文件系统，其目标是为各种硬件提供高带宽和高可用性，以服务广泛的用户群。Lustre为分布式数据存储提供了POSIX兼容的接口，使得大量客户端能够同时连接和使用文件系统。
IV. 方法论
模式A：在第一阶段，写应用程序在许多客户节点上运行（通常每个节点多于一个），并发出一系列写入操作。一旦所有写应用程序完成，将运行第二阶段，执行相同数量的读应用程序，发出一系列相应的读取操作。此模式旨在评估存储可以向应用程序提供的最大写入或读取吞吐量，模拟NWP写应用程序与后处理读取应用程序分开运行的场景。 模式B：首先，存储用一些数据预先填充。在此初始化步骤之后，用于基准测试的客户节点的一半发出一系列写入操作，而另一半发出相应的读取操作。此模式旨在评估存储在写入和读取进程之间存在竞争的更现实情景中可以提供的吞吐量。
Field I/O在[3]中详细描述了该基准测试，包括评估NWP应用程序的对象存储性能的方法，该方法在本文中也得到应用。根据该方法，已配置IOR基准测试，以便每个I/O进程发出一个单一的大型I/O操作，包括一系列数据部分（我们将此操作模式称为段模式）。这使得能够评估如果开发的应用程序被优化以在单个I/O操作中收集和传输所有相关数据时可以实现的最大性能，并提供了关于在不处理新操作的情况下存储服务器能够利用的网络带宽和/或存储能力的洞察。
为了对POSIX Lustre执行以对象存储为导向的Field I/O基准测试，我们开发了一个辅助库，该库使用POSIX文件系统概念实现了DAOS API。DAOS池已作为托管在分布式文件系统上的目录进行实现。容器已作为相应池目录下的目录进行实现。键值对象已作为相应容器目录下的目录进行实现。键由键名命名，并作为键值目录中的文件实现，而值则作为该键文件中的内容进行存储。数组对象已作为相应容器目录下的文件进行实现，其名称为数组的对象ID，并包含数组数据。
按照这一设计，Field I/O基准测试使用辅助库执行的每个天气场写入通常涉及以下操作：a）在每个客户进程的专用容器目录中写入数组文件，b）检查在客户节点的所有进程中共享的键值目录中的键值目录的存在，c）在客户节点的所有进程中共享的键值目录中创建和写入键文件。
字段读取通常涉及以下操作：a）检查在与所有客户进程共享的容器目录中的键值目录的存在，b）打开并读取由所有客户进程共享的键值目录中的键文件，c）检查在与客户节点的所有进程共享的容器目录中的键值目录的存在，d）打开并读取由客户节点的所有进程共享的键值目录中的键文件，e）打开并读取在专用于该进程的容器目录中的数组文件。
在IOR运行中，用于量化性能的带宽度量是IOR本身提供的同步带宽，这里称为同步带宽，而在Field I/O运行中，使用非同步应用程序的自定义带宽度量，称为全局定时带宽。这两种度量方法在[3]中有详细描述。
A. NEXTGenIO
我们所展示的基准测试是在NEXTGenIO[7]进行的，该系统为一研究用高性能计算（HPC）系统，由34个双插槽节点组成，搭载Intel Xeon Cascade Lake处理器。每个插槽配备6个256 GiB的第一代Intel Optane数据中心持久内存模块（DCPMM），配置为AppDirect交错模式，没有NVMe设备。每个处理器通过独立的集成网络适配器连接至低延迟的OmniPath网络，每个适配器的最大带宽为12.5 GiB/s。
对于Lustre基准测试，Lustre已经在8个存储节点上进行了部署（每个插槽一个，提供16个对象存储（OST）），另有一个节点专用于元数据服务。文件系统中使用的OST和MDT都挂载在与其相应插槽上连接的Optane SCM上的ext4文件系统上，为每个OST和MDT提供1.5 TB的高性能存储。
为了进行可配置数量的Lustre存储节点的基准测试，已设置了1、2、4和8节点的Lustre池。在运行测试之前，在文件系统中创建一个文件夹，所有测试文件将在其中生成，并使用setstripe命令将该文件夹与具有所需存储节点数量的池绑定。
DAOS的部署是在一个特定基础上单独进行的，根据需要删除并重新部署所需数量的存储节点。每个用于DAOS存储的节点每插槽部署一个单独的DAOS引擎，使用Optane SCM上的完整ext4文件系统，该文件系统适用于该插槽，提供与关联处理器上所有可用核心的访问权限。例如，为了与一个两节点的Lustre配置进行比较（使用两个OST节点和一个MDT节点，总共有4个OSTs），创建并为基准测试提供了一个两节点的DAOS部署。
最多使用了16个节点来执行基准测试客户进程，同时利用了两个插槽和网络接口。客户节点中的SCM未被使用，对I/O性能没有任何影响。
V. 结果
接下来，我们讨论在NEXTGenIO中运行对Lustre和DAOS进行的描述基准测试所得到的性能结果。首先，我们对使用IOR进行的潜在性能进行评估，然后对Field I/O在写入和读取应用程序之间存在竞争和不存在竞争的情况下的真实性能进行分析，并最后评估在这类应用程序中文件或对象大小的影响。
A. IOR结果，潜在性能
在这个测试集中，使用IOR基准测试对不同数量的Lustre和DAOS存储服务器节点运行，旨在分析客户端应用程序可能达到的最大写入和读取性能，并分析随着添加更多服务器节点时存储性能的行为。IOR已按照上述的段模式，遵循访问模式A进行运行。
对于每个服务器节点计数，基准测试已使用相同数量的客户节点运行，两倍数量，以及在可能的情况下四倍数量，目的是有效地利用理论上由服务器网络接口提供的可用带宽。对于这些组合的每一个，基准测试已使用36、48、72和96个IOR进程每个客户节点进行运行，因为在初步测试中发现这些参数对于Lustre和DAOS的性能最佳。每次运行都重复了5次以考虑变异性。
段计数被设置为100，因为发现这是导致带宽变异减小的最小段计数。段大小被设置为1 MiB，以匹配NWP应用场景中的对象或场的大小。这个段配置导致在基准测试运行期间写入和读取大小为100 MiB的文件或对象。
结果如图1所示。每个点表示获得最佳性能的客户节点数和IOR进程数对应的服务器节点数的平均同步带宽。使用空心点表示只能使用最多两倍数量的客户节点，而不是其它基准测试中的四倍。
在这种情况下，总体上Lustre实现了稍高的带宽，除了在具有8个服务器节点配置的读取阶段，该配置仅测试了最多两倍数量的运行基准测试的客户节点。该配置的性能限制解释为，在我们的测试平台和配置中，需要四倍数量的客户节点才能利用所有可用的服务器接口带宽，而在DAOS中，只需要两倍数量的客户节点。由于篇幅有限，省略了显示Lustre最佳客户到服务器节点比例的结果。对于DAOS，这一比例在[3]中得到了解释。
除此特殊情况外，使用Lustre和DAOS获得的写入和读取IOR带宽都呈线性增长。对于Lustre，每增加一个服务器节点，基准测试带宽的增加速度约为6 GiB/s（写入）和9 GiB/s（读取）。对于DAOS，这一增加速度约为5 GiB/s（写入）和7.5 GiB/s（读取）。
B. Field I/O结果
1) 使用DAOS与Lustre的应用性能：与段模式的IOR基准测试不同，Field I/O基准测试涉及类似对象存储的I/O操作。数据元素较小，通常写入或读取单个数据对象需要进行多次I/O操作。
在这个测试集中，Field I/O已经按照与上述IOR测试类似的策略，使用Lustre和DAOS以相似数量的服务器和客户节点运行，分别应用访问模式A和B。在这些运行中，对于所有配置，客户节点的数量最多为服务器节点的两倍。
基准测试已在其默认的完整模式下运行，并在避免使用DAOS容器的模式（称为no-containers）下运行[3]。在与Lustre运行时，使用辅助库将Field I/O适应为POSIX文件系统，no-containers模式中基准测试的每个场写入将涉及较少的元数据操作，但Array文件将写入由所有客户进程共享的单个目录。Field读取将从该共享目录中读取Array文件。
对象大小已设置为1 MiB，每个进程的I/O迭代次数设置为2000，以减小潜在并行进程启动延迟对带宽测量的影响。已选择每个客户节点的进程数量，这些数量被发现可获得最佳性能，为24和36（稍低于DAOS的36和48）。每次运行都重复了5次。
图2和图3分别显示了模式A和B的结果。请注意，在这两个图中，左侧是Lustre的结果，右侧是DAOS的结果，它们使用了不同的y轴刻度。
观察图2中DAOS的模式A结果，在图2（c）和（d）中，我们可以看到no-containers模式下的Field I/O性能优于具有容器的模式。这可能是由于在使用DAOS容器时存在的效率低下，如[3]中所讨论的。没有容器的模式呈线性增长，应用带宽每增加一个服务器节点，大约增加4.5 GiB/s的写入和5.5 GiB/s的读取。
图2（a）中的Lustre结果显示，在no-containers模式下，使用辅助库适应POSIX的Field I/O写入性能较差。这可能是由于在单个目录中执行所有Array文件的写入和读取，如上所述，受到了该目录上的Lustre争用或锁定的影响。
完整模式，其中Array文件分布在多个容器目录中，性能较好，并在写入时达到了最高7.5 GiB/s，但在4个服务器节点处达到了极限。在具有更多服务器节点的基准测试运行中，还使用了更多客户节点，并且每个客户节点被设置为执行额外的固定数量的I/O操作。在此观察到的限制是由于达到Lustre元数据服务器上IOPs限制，我们使用IOR进行基准测试时约为100 KIOPs。Field I/O基准测试运行的测得IOPs速率接近达到缩放极限的位置。在IOR基准测试中，Lustre可以缩放到更大的带宽，因为涉及的IOPs较少。
图2（b）显示，对于读取，Field I/O的两种模式表现相似，而且它们在4个服务器节点以上同样受到限制，这同样是由于达到Lustre元数据服务器上的最大IOPs。我们假设由于在Lustre中读操作不需要锁定/一致性，因此两种模式提供了类似的性能。
在图3中的模式B的结果中，写入和读取带宽需要结合，以便与模式A的结果进行近似比较，其中写入应用程序与读取应用程序同时运行。使用DAOS，no-containers模式的Field I/O表现出色，具有线性扩展，且在8个服务器节点时的综合带宽约为50 GiB/s，高于模式A中单独的带宽。
对于Lustre，完整模式在访问模式B中的写入和读取性能行为与在模式A中观察到的类似，但在4个节点之后的扩展性稍好。no-containers模式不仅在写入方面表现不佳，而且在读取方面也表现不佳，可能是由于并发写入引起的锁定/一致性问题。
就实现的综合应用带宽而言，Lustre在Field I/O模式B的完整模式中可达到约20 GiB/s，达到8个服务器节点，接近模式A中获得的读取带宽，但远低于DAOS在模式B中的任何模式中获得的更高的综合带宽。
从访问模式A的性能结果中，可以观察到DAOS获得的最佳应用带宽与IOR获得的带宽相当，而在Lustre中，它们约为IOR获得的带宽的五分之一。
我们已经确定了可能导致这种性能差异的四个因素：
1. Lustre设计用于大文件I/O，在面对类似对象存储的应用程序时，元数据服务器成为瓶颈。
2. 当Field I/O应用程序在Lustre上运行时，使用辅助库适应POSIX，该库实施了一个使用Key-Value目录和文件的自定义索引机制。使用Lustre自己的目录和文件名进行索引的实现将涉及较少的文件元数据操作，并可能表现更好。
3. Lustre需要4倍数量的客户节点才能达到网络带宽的饱和，但我们只运行了两倍数量的基准测试。
4. DAOS已经针对新的内存技术进行了优化，如SCM，并且可以绕过某些操作的块存储接口。
2) 对象和文件大小的影响：图4显示了在Lustre的Field I/O完整模式和DAOS的no-containers模式下使用访问模式A运行的带宽结果。这次基准测试使用了不同的对象大小，包括1、5、10和20 MiB，以评估未来NWP模型分辨率增加对I/O性能的影响。
所有测试都使用了固定的配置，即2个服务器节点和4个客户节点，并且每个客户进程执行100个I/O操作。基准测试重复了5次，使用与先前Field I/O运行中相同的客户进程数量。对于每个测试的I/O大小，显示了每个客户节点中执行的最高性能的平均带宽。
可以观察到，将对象或文件大小从1 MiB增加到5 MiB对写入和读取均有实质性的好处，对于Lustre和DAOS都是如此。超过5 MiB后，带宽稳定，除了在Lustre读取中，它继续增加。
在这个基准测试配置中，使用1 MiB的对象或文件大小，DAOS的带宽高于Lustre。对于较大的对象或文件大小，两个存储系统提供了相似的写入带宽。对于读取，DAOS在对象大小达到10 MiB时表现优于Lustre，而Lustre在较大文件上表现优于DAOS。
可以使用访问模式B重复这个测试集，以研究在写入和读取竞争下对象或文件大小增加时应用带宽的行为是否不同。同样，也可以研究不同的服务器和客户节点配置。
VI. 相关工作
已经进行了关于用于高性能I/O的对象存储的研究，其中包括CEPH [9] 和 CORTX Motr [10]。然而，迄今为止，这些技术在大规模系统中进行非常密集的数据创建或处理工作负载方面的应用较为有限。DAOS是首批为HPC设计的生产就绪对象存储技术之一，在最近进行的IO-500基准测试中取得了显著的成绩 [11]。
科学界一直在研究对象存储用于I/O操作 [12]，包括使用非易失性内存 [2]。这些研究已经证明了性能和功能方面的优势，但强调了直接移植依赖于对存储介质上对象的定制管理。像DAOS这样的领域无关的对象存储简化了在生产环境中使用NVM的过程。
本文提出的工作在先前关于利用对象存储和NVM技术进行HPC I/O的研究领域取得了进展，扩展了对对象存储方法与使用高性能I/O硬件的益处之间影响的理解和知识。它还拓展了社区对于在许多应用中常见的工作负载模式下，DAOS和Lustre的性能表现的理解。
VII. 结论
通过我们的基准测试和评估工作，我们已经证明了在使用相同底层存储硬件的情况下，Lustre和DAOS可以为大规模的批量数据操作提供类似的性能，例如IOR基准测试模拟的操作以及许多应用程序已经调整为利用这些操作。然而，当转向类似对象存储的I/O操作和工作流时，DAOS显示出显著的性能优势。我们得出结论，由于在实现高性能的同时启用了对象存储功能，DAOS是未来存储平台的理想选择方案。
通过Field I/O基准测试生成的访问模式并不特定于NWP应用场景，也不限定于任何特定的文件格式，因此这些发现适用于重复从多个进程和节点写入和/或读取大小在1到10 MiB范围内的任何对象或文件的其它应用场景。
结果表明，在类似对象存储的NWP应用场景中，DAOS获得的良好性能结果不仅仅是由于使用了高性能的存储硬件，如SCM，而且还由于对象存储的设计特性及其在DAOS中的实现。
然而，在这种情况下，Lustre的性能和扩展性应该通过使用更多的服务器和客户节点进行基准测试来进一步探索和验证，并且可能需要在基准测试中实施额外的优化，以更好地利用文件系统的能力。
---【本文完】---
近期受欢迎的文章：
更多交流，可添加本人微信
（请附姓名/关注领域）
REFERENCES
[1] G. Lockwood, ”What's so bad about POSIX I/O?”. The Next Platform 2017. https://www.nextplatform.com/2017/09/11/whats-bad-posix-io/
[2] S. Smart, T. Quintino, and B. Raoult. ”A High-Performance Distributed Object-Store for Exascale Numerical Weather Prediction and Climate”. In Proceedings of the Platform for Advanced Scientific Computing Conference (PASC '19). Association for Computing Machinery, New York, NY, USA, Article 16, 1–11.DOI:https://doi.org/10.1145/3324989.3325726
[3] N. Manubens, T. Quintino, S. D. Smart, E. Danovaro, and A. Jackson, “DAOS as HPC Storage, a view from Numerical Weather Prediction”, arXiv e-prints, https://arxiv.org/abs/2208.06752, 2022.
[4] Z. Liang, J. Lombardi, M. Chaarawi, M. Hennecke, ”DAOS: A Scale-Out High Performance Storage Stack for Storage Class Memory” In: Panda, D. (eds) Supercomputing Frontiers. SCFA 2020. Lecture Notes in Computer Science(), vol 12082. Springer, Cham. DOI:https://doi.org/10.1007/978-3-030-48842-0 3
[5] P. Braam ”The Lustre Storage Architecture” 2019 arXiv.DOI:https://doi.org/10.48550/arXiv.1903.01955
[6] ”HPC IO Benchmark Repository”, (2022), GitHub repository, https://github.com/hpc/ior
[7] A. Jackson, M. Weiland, M.Parsons, and B. Homolle. ”An Architec-¨ ture for High Performance Computing and Data Systems Using ByteAddressable Persistent Memory”. In High Performance Computing: ISC High Performance 2019 International Workshops, Frankfurt, Germany, June 16-20, 2019. Springer-Verlag, Berlin, Heidelberg, 258–274. DOI:https://doi.org/10.1007/978-3-030-34356-9 21
[8] M. Weiland, H. Brunst, T. Quintino, et al. ”An early evaluation of Intel's optane DC persistent memory module and its impact on highperformance scientific applications”. In Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis . Association for Computing Machinery, New York, NY, USA, Article 76, 1–19. DOI:https://doi.org/10.1145/3295500.3356159
[9] K. Jeong, C. Duffy, J. -S. Kim and J. Lee, ”Optimizing the Ceph Distributed File System for High Performance Computing,” 2019 27th Euromicro International Conference on Parallel, Distributed and NetworkBased Processing (PDP), 2019, pp. 446-451, DOI: 10.1109/EMPDP.2019.8671563.
[10] S. Narasimhamurthy, N. Danilov, S. Wu, G. Umanesan, S. Chien, S. Rivas-Gomez, I. Peng, E. Laure, S. Witt, D. Pleiter, and S. Markidis. ”The SAGE project: a storage centric approach for exascale computing: invited paper”. In Proceedings of the 15th ACM International Conference on Computing Frontiers (CF '18). Association for Computing Machinery, New York, NY, USA, 287–292.DOI:https://doi.org/10.1145/3203217.3205341
[11] A. Dilger, D. Hildebrand, J. Kunkel, J. Lofstead, and G. Markomanolis, ”IO500 10 node list Interational Supercomputing 2021, June 2021, [online] Available:https://doi.org/10.5281/zenodo.5171694
[12] S. Smart, T. Quintino, and B. Raoult ”A Scalable Object Store for Meteorological and Climate Data”. In Proceedings of the Platform for Advanced Scientific Computing Conference (PASC '17). Association for Computing Machinery, New York, NY, USA, Article 13, 1–8.DOI:https://doi.org/10.1145/3093172.3093238
[13] MA. Vef, N. Moti, T. Suß et al. ”GekkoFS — A Temporary Burst Buffer¨ File System for HPC Applications”. J. Comput. Sci. Technol. 35, 72–91 (2020). https://doi.org/10.1007/s11390-020-9797-6
[14] O. Tatebe, K. Obata, K. Hiraga, and H. Ohtsuji. 2022. ”CHFS: Parallel Consistent Hashing File System for Node-local Persistent Memory”. In International Conference on High Performance Computing in Asia-Pacific Region (HPCAsia2022). Association for Computing Machinery, New York, NY, USA, 115–124.DOI:https://doi.org/10.1145/3492805.3492807
[15] A. Miranda, A. Jackson, T. Tocci, I. Panourgias and R. Nou, ”NORNS: Extending Slurm to Support Data-Driven Workflows through Asynchronous Data Staging” 2019 IEEE International Conference on Cluster Computing (CLUSTER), 2019, pp. 1-12, doi: 10.1109/CLUSTER.2019.8891014.