论文阅读-Hydra: 用于持久内存和RDMA网络的分散文件系统

论文名称：Hydra: A Decentralized File System for Persistent Memory and RDMA Networks

摘要

新兴的字址持久内存（PM）有可能颠覆内存和存储之间的边界。结合高速RDMA网络，分布式基于PM的存储系统提供了通过紧密耦合PM和RDMA特性来实现存储性能大幅提升的机会。然而，现有的分布式文件系统采用为传统磁盘设计的传统集中式客户端-服务器架构，导致访问延迟过高、可扩展性有限且恢复开销高。本文提出了一种完全去中心化的基于PM的文件系统——Hydra。通过利用本地PM的性能优势，Hydra利用数据访问局部性实现高性能。为加速Hydra节点间的文件传输，文件元数据和数据通过单边RDMA读取进行分离更新。Hydra还对RDMA请求进行批处理，并将RPC分类为同步和异步类型，以最小化网络开销。去中心化使Hydra能够容忍节点故障并实现负载均衡。实验结果表明，Hydra在多线程和并行工作负载上表现出色，明显优于现有的分布式文件系统。

关键词——持久内存、文件系统、RDMA、分布式系统、去中心化

1 引言

新兴的持久内存（PM），如英特尔Optane DC持久内存模块（Optane DCPMM），正在模糊内存和存储之间的界限。字址可寻址、非易失性的PM使应用程序能够直接访问主内存中的持久数据。与传统存储设备（如硬盘驱动器或固态硬盘）相比，PM提供接近DRAM的访问延迟和带宽。支持PM的存储系统承诺显著提高应用程序性能。

近年来，远程直接内存访问（RDMA）技术的进步使程序员能够构建有效的分布式存储系统，将PM存储和RDMA网络结合起来。RDMA是一种内存访问技术，使网络接口卡（NIC）能够直接访问远程存储器。已经提出了几种基于PM的分布式文件系统，旨在利用PM和RDMA网络的优势。与基于磁盘的分布式文件系统不同，这些文件系统在服务器节点上安装PM以存储元数据和数据，并紧密耦合PM和RDMA特性以实现高性能和可靠性。对于元数据和数据管理，这些文件系统采用传统的集中式客户端-服务器架构，使用主内存作为客户端的易失性缓存。在文件访问时，文件元数据和数据从远程服务器获取到本地客户端的内存缓冲区，以响应I/O请求。

然而，传统的集中式客户端-服务器架构在利用PM和RDMA网络在基于PM的分布式文件系统中的全部潜力方面存在不足。首先，与传统基于磁盘的分布式系统相比，基于PM的分布式存储系统的主要性能瓶颈已从存储转移到网络。与历史趋势相反，预期网络延迟将远高于可见未来的PM延迟，这是由于传播延迟和网络往返引起的。本地PM I/O比通过RDMA网络的远程访问大大减少访问延迟。其次，集中式客户端-服务器架构限制了系统的可扩展性。集中式服务器简化了客户端之间的协调，但以牺牲扩展性为代价。当服务器运行在真实的Optane DCPMM上时，问题变得更加严重，因为其I/O性能无法随线程数良好扩展。第三，客户端端的DRAM缓存增加了服务器的成本，并在客户端节点断电或系统故障时引入了高恢复开销。Optane DCPMM的每GB成本仅约为DRAM的39%。此外，基于DRAM的客户端节点必须在恢复期间从头开始重建来自远程服务器的元数据和数据缓存，这会增加恢复开销以及服务器负载。

PM和RDMA技术的独特特性为将单个存储服务器上的本地PM感知文件系统连接到一个机架规模的文件系统集群提供了机会，其中文件元数据和数据在集群节点之间分解，并通过高速RDMA网络连接。在每个集群节点上，文件数据被本地且持久地存储，允许应用程序在运行时利用本地PM的高性能和大容量，并在系统崩溃后快速恢复。然而，在应用端集群节点上使用PM作为持久性存储提出了一系列挑战。不同集群节点上陈旧和最新文件副本之间的同步应该高效且可扩展。去中心化的文件系统集群应该能够优雅地容忍任意节点故障，并在运行时平衡负载。

我们提出了Hydra，一个旨在通过充分利用直接可访问的持久内存和高速RDMA网络来提高可扩展性和容错性的去中心化文件系统。Hydra是第一个分布式持久内存文件系统，在设计过程中系统地优化可扩展性。与严格将存储服务器与客户端分开的传统范例不同，Hydra将它们组合成一组装备了PM的节点，并通过RDMA网络连接它们以形成去中心化文件系统集群。Hydra通过充分利用本地PM的性能优势来最小化I/O延迟，利用数据访问局部性。为加速节点间的文件传输，Hydra提出了不同的文件更新方案，通过单边RDMA读取从远程节点差异传输文件元数据和数据。为实现负载平衡，文件元数据和数据被动态分解和复制到Hydra节点中。Hydra还引入了RDMA请求批处理和RPC分类机制，以发挥RDMA网络的全部潜力，以最小化文件元数据和数据传输的开销。此外，Hydra支持在线节点添加和删除，提供高弹性和灵活性。

本文的贡献包括：

• 我们提出了Hydra，一个完全去中心化的分布式文件系统，充分利用本地持久内存上的数据局部性来实现高可扩展性、高可用性和崩溃一致性。
• 我们设计了差异文件更新方案，通过单边RDMA读取通过差异方式传输文件元数据和数据，加速文件传输和节点恢复。
• 我们描述了Hydra如何容忍任意节点故障并在集群节点之间平衡负载。
• 我们实现并评估了Hydra。实验结果表明，Hydra在多线程和并行工作负载上表现出良好的可扩展性，并明显优于现有的分布式文件系统。 本文的余下部分组织如下。第2节介绍了PM感知文件系统和RDMA网络的背景。第3节介绍了Hydra的设计概览。我们在第4、5和6节分别描述了文件传输机制、集群管理和RDMA优化技术。实验结果在第7节中呈现。第8节讨论了相关工作，第9节总结了本文。

2 背景和动机

Hydra 是一个专为 PM 和 RDMA 网络设计的分布式文件系统。本节介绍了 PM、Hydra 基于的 NOVA 文件系统以及 RDMA 技术的背景。我们最后阐述了需要一个全面去中心化的新型分布式 PM 文件系统的动机。

2.1 PM 和 PM-Aware 文件系统

持久内存（如 STT-RAM、ReRAM 和 PCM）提供数据持久性、字节可寻址性，以及接近 DRAM 的访问延迟和带宽。持久内存直接连接到主内存总线旁边的 DRAM，并且可以通过加载/存储接口进行访问。英特尔 Optane DCPMM 是第一个商用可用的持久内存 DIMM。

PM 的高性能和非易失性吸引了过去十年对本地 PM-aware 文件系统的广泛研究。其中，NOVA 是一种最大化性能并提供强一致性保证的基于 PM 的先进文件系统。NOVA 使用每个 CPU 的空闲列表、日志和索引节点表来确保良好的多核可伸缩性。对于每个文件，NOVA 在 PM 中维护一个单独的日志，其中包含一个 4KB 的日志页面的单链表。索引节点、其日志和数据页面之间的关系如图 1 所示。索引节点中的尾指针指向日志中最新提交的条目。对于每次文件更新，NOVA 在其日志中创建相应的日志条目，并原子性地更新 PM 中的日志尾指针。为了加速文件访问，NOVA 在 DRAM 中维护一个基数树，将文件偏移映射到 PM 中的数据页面地址。

NOVA和Hydra的文件结构。文件日志包含inode更新条目和文件写入条目。这些文件写入条目包含指向数据页面的指针。

由于 NOVA 充分利用了 PM 的性能优势和 CPU 的多核可伸缩性，其基于日志结构的文件设计自然适合 Hydra 的线性化的差异文件更新方案，我们基于 NOVA 实现了 Hydra。具体来说，Hydra 继承了来自 NOVA 的日志结构文件布局和可扩展内存分配器的设计。在 Hydra 中，头指针和尾指针也用于通过链表维护连接的文件日志。过时的文件可以通过传输和重放差异文件日志与其最新版本同步。然而，我们还对日志条目的内容进行必要的调整，以使 Hydra 能够管理分布式集群节点上的日志和数据页面。Hydra 还在每个 CPU 上维护一个索引节点表、日志和 PM 空闲页面列表，以避免全局锁定。这有助于 Hydra 避免在每个集群节点上出现可伸缩性瓶颈。

2.2 远程直接内存访问

RDMA 通过直接访问远程服务器的内存提供低延迟和高带宽的远程内存访问。在可靠连接（RC）模式中，节点通过一对发送/接收队列（队列对，QP）连接。应用程序通过向发送队列中放置工作队列条目（WQE）来发起 RDMA 请求。完成 RDMA 请求后，网络适配器通过向完成队列（CQ）发布完成队列条目（CQE）来信号完成。应用程序可以通过轮询 CQ 来接收请求已成功完成的通知。

RDMA 支持读/写操作（单边动词）以及两个节点之间的发送/接收操作（双边动词）。单边动词通过直接访问远程主机暴露的预注册内存区域来提供更高的吞吐量，而无需通知主机 CPU。对于双边动词，远程 CPU 参与处理 RDMA 请求。此外，RDMA 还提供原子动词，如比较交换（CAS）和获取增加（FAA），以原子方式更新远程内存中的 64 位数据。现有基于 RDMA 的 RPC 请求通过单边动词或双边动词发送。通过单边动词发送的请求写入服务器上的专用消息缓冲区。服务器线程忙于检查消息缓冲区以查看新请求到达情况。这种设计提供了低延迟的 RPC 处理，但会造成高服务器 CPU 开销，这不适合可扩展的去中心化系统。Hydra 采用双边动词来实现其 RPC，以消除接收方忙碌消息检查的成本，从而在集群节点之间平衡负载。

2.3 分布式 PM 文件系统中的挑战

新兴的高性能 PM 和 RDMA 技术都是高性能分布式存储系统的吸引人组件。将这些硬件技术纳入分布式文件系统中在系统可扩展性、访问延迟和容错性方面提出了新挑战。

系统可扩展性。在传统的客户端-服务器架构中，集中式的元数据节点用于处理整个集群中的元数据访问。即使采用了复制和分区等技术，元数据节点仍然容易受到来自大量并发访问的文件访问倾斜的影响。此外，由于 RDMA 网络适配器的内存有限，随着活动 QP 数量的增加，其可扩展性下降，导致文件系统无法在重负载下提供可扩展的元数据服务。

访问延迟。与传统分布式文件系统组件（如硬盘和以太网）相比，PM 和 RDMA 网络提供了更高性能，暴露了存储栈内的延迟瓶颈。在客户端，用户、内核和网络缓冲区中的过多数据复制大幅增加了远程数据访问的延迟。在服务器端，传统的 RPC 处理程序在请求处理过程中引入了大量 CPU 开销。此外，文件数据通常以粗粒度传输，而 PM 和 RDMA 网络支持字节可寻址数据访问，导致严重的写放大和增加的数据访问延迟。

容错性。分布式文件系统应该能够容忍系统故障，同时保持文件数据和元数据的高可用性。分布式文件系统的潜在故障包括集群节点故障和网络分区。然而，采用集中式客户端-服务器架构的分布式文件系统容易受到这两者的影响。尽管一些文件系统通过复制方法提高了可用性，但它们仍然在故障切换期间遭受高文件访问延迟和暂停文件服务的影响。

分布式 PM 文件系统需要新方法来改善系统可扩展性，最小化访问延迟，并优雅地容忍故障。因此，我们提出 Hydra，一个充分利用持久内存和高速 RDMA 网络独特特性的全面去中心化 PM 文件系统。

3 设计概述

Hydra是针对配备PM和RDMA网络的服务器集群构建的。图2总结了其高级设计组件，并概述了Hydra系统的概况。在Hydra中，文件更新的典型I/O工作流程包括四个阶段：（1）权限检查阶段。Hydra通过轻量级分布式锁模块获取写权限。去中心化文件锁通过低开销的RDMA原子操作进行传输（第4.3节）。 （2）文件同步阶段。每个Hydra节点都以日志结构的布局管理其本地文件。为了获取最新的文件元数据和数据，或处理来自远程节点的复制请求，Hydra利用差异文件更新方案（第4.2节）通过单边RDMA读取高效地传输差异文件日志。 （3）本地I/O阶段。Hydra使用本地节点上的最新文件数据为I/O请求提供服务，利用数据局部性实现高性能。文件更新后，新的日志条目被附加到文件日志中。 （4）数据传输阶段。Hydra向远程节点发出RPC请求以提交更新。为了减少网络开销并提供可扩展的性能，Hydra采用RDMA请求批处理和RPC分类机制（第6.1节）。

Hydra的架构。Hydra充分利用本地PM的访问局部性和通过差分文件更新实现高效文件传输，从而为应用程序提供高可扩展性和可用性。

此外，Hydra通过利用差异文件更新方案实现了系统崩溃后的快速恢复（第5.1节）和负载均衡期间的高效迁移（第5.2节）。Hydra还在每个集群节点上提供了正常的POSIX接口，并支持在运行时动态添加或删除集群节点，为应用程序提供了高弹性和灵活性。总体而言，Hydra实现了以下设计目标：

• 可扩展的性能：多核和多节点的可伸缩性对于Hydra充分发挥PM和RDMA网络的性能优势至关重要。Hydra通过将文件数据放置在应用程序侧的PM中利用数据局部性来提高整体性能，并通过采用RDMA请求批处理和RPC分类机制实现多节点可扩展性。
• 低开销的文件传输：Hydra利用文件日志的线性一致性来实现差异文件更新，在集群节点之间同步过时的文件。文件通过单边RDMA读取在节点之间差异化同步，从而加速文件传输并消除远程CPU瓶颈。
• 高可靠性和可用性：文件元数据和数据在所有去中心化的Hydra节点之间进行动态复制，使Hydra能够在没有数据丢失的情况下容忍节点故障。在节点故障的情况下，应用程序可以故障转移至集群中的任何其他节点。
• 轻量级的一致性机制：由于没有中央元数据服务器来调节并发文件更新，我们使用锁令牌来授予文件粒度的写权限，以协调Hydra集群中的同时文件访问。令牌通过本地/RDMA的比较和交换（CAS）操作进行简单交换，最大限度地减少了一致性开销。
• 高弹性：Hydra支持在运行时动态添加或删除集群节点，为应用程序提供高弹性和灵活性。

为实现这些设计目标，与传统的分布式文件系统严格区分集群管理节点、元数据服务器节点、数据服务器节点和客户端节点不同，Hydra将它们的功能结合到一个单一的去中心化文件系统模块中。在文件访问时，Hydra通过直接在本地PM上执行文件I/O来利用局部性。如果本地文件过期或不存在，Hydra将差异化地更新文件为集群中的最新版本。至于复制，Hydra中的每个文件默认具有至少两个副本（主副本和辅助副本）的元数据和数据，分布在集群节点之间。这使得Hydra能够容忍任意单个节点故障而不会丢失数据。

4 文件传输

在本节中，我们描述了Hydra如何显著加速集群节点之间的文件传输。首先，我们说明了Hydra如何差异化地更新文件元数据和数据。然后，我们讨论了Hydra如何在集群节点之间保持一致性。最后，我们通过一些典型的目录和文件操作示例总结了Hydra的设计。

4.1 分布式文件管理

如图3所示，Hydra没有集中式管理节点。相反，从每个文件的视角来看，Hydra在集群节点之间有三种类型的文件副本分布。

Hydra集群的全局和本地视图。在Hydra集群上创建目录和文件之后（步骤1-4），每个节点包含整个文件集的一部分，但集群中的所有文件对每个节点都是可访问的。对于新连接的节点，Hydra会创建辅助副本以便于目录和文件的访问（步骤5和6）。

主要副本是文件的权威副本。在Hydra中，每个文件都有一个主要副本，它是同步更新的。主要副本具有文件的最长元数据日志，以及完整的文件数据副本。默认情况下，创建文件的节点被指定为其主节点。主节点的标识存储在inode中，它可能会因迁移（在负载平衡期间）或主要选举（在节点故障时）而发生变化。在这些情况下，Hydra将另一个节点指定为主节点，并通过RPC向所有相关节点广播消息。

次要副本是文件的复制副本。持有次要副本的节点是在文件创建时（第5.2节）通过二次选择算法的变体确定的。除非调用fsync来同步文件，否则次要副本是异步更新的。用户设置次要副本的数量。默认情况下，在Hydra集群中每个文件有一个次要副本。

辅助副本是文件的额外副本。当文件被复制到Hydra节点时，文件本身和其父目录必须与其他节点同步，以保持本地文件系统视图的目录树结构。如果本地节点当前没有文件/目录的主要或次要副本，Hydra将创建其辅助副本。这确保每个Hydra节点能够通过目录树遍历检索其所有本地文件，并且即使Hydra集群中的所有其他节点都丢失，它也可以像本地文件系统一样运行。在节点的PM使用率很高时，将以LRU方式逐出这些文件的副本。这些副本将在下次访问文件时从主/次要节点检索。

Hydra为应用程序提供了高可用性。如图3的第4步所示，在Hydra的集群节点中，文件及其副本是分布在集群节点中的。每个节点只包含整个文件集的一部分，但Hydra集群中的所有文件对每个节点都是可访问的。本地节点上过期或不存在的文件的辅助副本仅在其被访问时与最新版本同步。从每个文件的视角来看，我们将持有文件主/次要副本的节点称为文件的主/次要节点。

Hydra节点使用唯一的8位全局ID进行标识，默认情况下通过对节点的RDMA地址进行哈希生成。Hydra集群中的所有节点定期通过心跳消息进行通信。心跳消息包含当前CPU、网络和PM使用情况，用于负载平衡。

4.2 差异化文件更新

Hydra使用差异化文件更新方案（diff-update）来更新本地节点上陈旧（或不存在）的文件/目录，使其与远程节点的最新版本同步。如图2所示，Diff-update在Hydra中被广泛应用于在各种场景中传输目录和文件。因此，差异化更新的本地和远程传输开销对于Hydra集群的整体性能和可扩展性至关重要。我们在本节中介绍了差异化更新涉及的步骤。

文件版本验证。在从远程节点拉取元数据和数据之前，Hydra首先通过本地和远程验证来验证本地文件（或目录）的版本是否是最新的或陈旧的。首先，Hydra检查本地节点是否是文件的主节点或令牌持有者（第4.3节）。由于任何已提交的修改都会在主节点中得到反映，且只有令牌持有者才能修改文件，因此无论是令牌持有者还是主节点的文件内容都是最新的。

如果本地验证失败，Hydra会转向远程验证。Hydra向主文件副本的文件元数据发出小型RDMA读取，以检索日志页数以及头部和尾部指针（图4的第1步）。头部指针用于指示文件日志的起始点，而尾部指针用于计算文件的日志长度。如果本地日志长度与远程日志长度匹配，则本地文件是最新的。这是因为Hydra通过锁令牌（在第4.3节讨论）协调文件锁定。对于任何文件，只有一个节点能够修改它并增加其日志长度。因此，最新的文件版本是具有最长日志长度的节点的文件副本。如果本地文件是最新的，则整个同步过程只需要一个网络往返。否则，本地文件已经过时。Hydra启动差异元数据和数据更新过程。

差异文件更新。本地（目标）节点与远程（源）节点同步，以不同的方式将本地陈旧文件副本更新到最新版本。

在Hydra中，日志长度通过比较日志页数和尾部指针的偏移量来计算。如图1所示，日志页数是最后一个日志页的逻辑数量。因此，逻辑日志长度实质上等同于Hydra中每个文件的版本号。当向文件分配新的日志页时，日志页数会增加一。在垃圾回收期间，将回收仅包含无效日志的旧日志页。但是，逻辑日志页数不会减少。如果本地和远程日志页数匹配，则Hydra比较尾部指针的页内偏移量，以准确比较日志长度。

元数据更新。Hydra继承了NOVA的日志结构文件设计来组织文件元数据和数据。在Hydra中，通过从源节点向目标节点传输差异化文件日志来实现元数据更新。由于拥有文件最新版本的源节点通常在文件复制过程中成为瓶颈，因此我们选择使用RDMA读取来进行元数据和数据更新，而不是使用RDMA写入。对于源节点来说，单边RDMA读取不仅绕过了其CPU，服务于入站RDMA读取也比发出出站RDMA写入造成的开销小[31]。

如图4所示，在远程验证后，本地缓存了开始和结束日志页的地址。结合两个节点上的页数，Hydra能够计算与本地节点上当前日志尾部匹配的远程节点上相应日志地址。然后，本地节点通过RDMA读取请求拉取当前日志尾部之后的差异日志，更新日志尾部。Hydra递归地拉取后续的日志页（如果有任何），使用当前日志页中的下一页指针，直到本地日志长度与远程日志长度匹配。

当日志页被获取后，Hydra会回放本地节点上的日志以更新元数据。例如，文件模式更改日志会直接应用，而文件写日志会通过使用DRAM中的本地/远程数据页指针来回放，更新文件基数树。

在元数据更新期间，根据请求类型，文件数据可以选择性地进行更新。例如，文件同步侧重于数据完整性，并调用具有数据更新的diff-update。同时，文件打开追求快速日志复制，因此省略了数据更新。在这种情况下，本地数据日志仍然包含对其他Hydra节点上的远程数据的有效指针（即图4中的黑色箭头），可以在未来访问时用于检索文件数据。可选的数据更新通过延迟数据传输来降低diff-update的延迟。

数据更新。如果本地节点在元数据更新时请求数据更新，数据页将通过批量RDMA读取来获取以减少传输开销。在重放文件写日志时，Hydra在本地PM上分配数据页，并异步发出相应的RDMA读取请求以从远程节点获取数据页。在Hydra中，每个文件写日志包含八个全局数据指针槽。每个全局指针封装了一个节点ID（8字节）和保存数据的当前主/次要节点的数据页地址（56字节）。对于数据更新，Hydra会扫描有效地址的指针槽，并选择网络负载最小的节点来传输数据。在数据传输过程中，Hydra会解封全局节点ID和远程页面的逻辑地址，并通过RDMA进行远程内存访问。之后，Hydra会更新日志中的本地数据页地址（即图4中的灰色箭头）。当所有新拉取的日志被重放后，Hydra会拉取CQ以完成文件数据页的批量RDMA读取请求的完成。

目录更新。在差异化更新过程中，目录被视为没有数据的仅为日志的文件。文件创建/删除日志通过将相应的目录项添加到/从其DRAM缓存中重新播放。请注意，在目录中的文件创建日志中，新创建的子文件实际上并没有通过日志重放在本地节点上创建。只有当它们被访问时，它们的相应目录项才会插入到目录中。新创建的子文件仅在被访问时在本地创建并同步。

Hydra采用了一种懒惰的文件同步方法，只在需要时更新底部目录路径上的过时目录。如图3的第4步所示，要在节点4上的目录C中创建文件D，C将与其主节点（即节点3）同步。由于目录C是最新的，递归同步已完成。然后，文件D可以在节点4上本地创建。请注意，目录A和文件B在创建文件D时没有涉及。

通过目录树遍历和按需递归目录更新，懒惰的文件同步方法还确保了Hydra集群中的所有文件对每个Hydra节点都是可访问的。通过解耦目录和其子文件，Hydra消除了在节点之间交换冗余文件修改和目录结构信息的重要通信开销。

一致性保证。在元数据和数据同步完成后，Hydra会更新本地持久内存中文件inode中的日志页数和日志尾部指针，以完成diff-update（图4的第4步）。由于日志尾部指针更新是一个原子操作，因此diff-update的一致性是得到保证的。

文件复制。差异更新促进了Hydra中的高效文件复制。为了启动文件复制，主节点向次要节点发送异步RPC请求（第6.1节）。然后，它同时且异步地处理由次要节点发出的diff-update的入站RDMA读取请求。（除非应用程序调用fsync，强制文件复制同步完成。）当diff-update完成时，次要节点将向主节点发送异步RPC请求以更新全局指针槽。之后，其他节点可以从主节点或次要节点中获取文件数据。相比之下，传统的主复制使用同步的出站RDMA写入和串行链复制方法，导致更高的延迟和更低的可扩展性。

差异更新方法提供了三个主要优势：首先，传输差异文件日志显著降低了传输开销。差异更新使Hydra能够合并打包文件日志中的重复更改，以提高传输效率。其次，处理从目标节点发出的单边RDMA读取消除了源节点的CPU瓶颈，提供了更高的可扩展性。第三，通过解耦文件元数据（日志）和数据，可以通过仅更新元数据到最新版本来同步文件，从而降低文件访问的关键路径延迟。

4.3 分散式分布式锁定

由于大多数数据中心工作负载主要是只读的[32]，Hydra在集群中的所有节点之间支持多个读取者和单个写入者。Hydra使用锁令牌在节点之间协调文件锁。每个文件只有一个全局锁令牌，用于授予对文件副本的某个写入许可。锁令牌由文件的主节点管理。

我们使用一种轻量级的基于令牌的锁定机制，并使用原子操作来最小化令牌传输开销。最初，主节点上的文件锁令牌字段的值被设置为零。为了获取锁令牌，主/非主节点向主节点上的锁令牌发出本地/RDMA比较并交换（CAS）请求。如果成功获取锁令牌，则将主节点上的锁令牌值与节点的唯一8位全局ID交换。当释放锁令牌时，其值将被重置为零。

为了减少节点之间的网络通信量，我们采用一种惰性令牌传输方法。在Hydra中，主节点不会主动撤销锁令牌。相反，当本地节点上的写操作无法获取锁令牌时，CAS操作将返回当前持有令牌的节点ID。在这种情况下，本地节点通过最近的心跳消息确定令牌持有者节点是否存活。如果令牌持有者节点存活，则本地节点将向该节点发送同步RPC消息，然后重试CAS请求，直到锁被释放。接收到消息后，令牌持有者节点将在其待处理的写操作完成后将主节点上的锁令牌值重置为零。如果令牌持有者节点或主节点宕机，本地节点将启动主节点选举（第5.1节）以恢复分布式锁。

与非令牌持有者节点相比，令牌持有者节点在两个方面有所不同。首先，文件在令牌持有者节点上的读取和写入权限都可以由其读写信号量授予，而非令牌持有者节点只能授予读取权限。其次，为了避免不一致的日志，文件的垃圾收集只能在令牌持有者节点上执行。其他节点将从最新的经过垃圾收集的文件副本同步文件日志和数据。

4.4 目录和文件操作

应用程序通过POSIX接口访问Hydra中的目录和文件。在本节中，我们将展示Hydra如何处理对目录（dir）中的文件（file）的目录操作以及对文件的文件操作。请注意，文件可以是目录操作示例中的子文件或子目录。

文件创建。文件创建涉及将新的目录条目（dentry）追加到dir，以及创建文件的元数据。为了追加新的dentry，本地Hydra节点首先通过获取dir的锁令牌来获得向dir插入新dentry的权限，然后调用diff-update来将dir与其主节点同步。

在文件在本地节点上创建后，Hydra向dir的主节点发出RPC请求，通知新插入的dentry，除非本地节点本身就是dir的主节点。主节点将dir与本地节点同步，重放创建文件的新日志，然后回复给本地节点。之后，主节点会异步发出RPC请求（第6.1节）来更新辅助节点上的dir。

文件删除。文件删除可以分解为两个步骤：取消链接（从dir中删除文件的dentry）和驱逐（释放文件占用的存储空间）。取消链接的实现方式与文件创建类似。我们使用同步的文件更新请求来通知dir的主节点和辅助节点删除相应的dentry。然而，驱逐不需要同步完成。Hydra只需要向主节点和辅助节点发出异步RPC请求来释放文件的资源。

目录查找。要在dir中查找dentry，Hydra首先通过diff-update将dir与其主副本同步，然后进行文件查找。如果在查找之前目录过时或不存在，Hydra将从底层递归同步其父目录。

文件打开。如果本地节点当前持有file的锁令牌，则文件的打开方式与本地文件系统相同。对于非令牌持有者节点，Hydra首先获取相应的锁，然后向主节点发出diff-update请求以更新本地文件日志。当diff-update完成后，Hydra唤醒一个后台线程，将文件数据异步复制到本地节点。

文件读取。如果目标数据已经复制到本地节点，Hydra会在本地处理读请求。否则，Hydra使用相应本地文件日志中的指针从主节点获取所请求的数据，以满足读请求。同时，创建数据的本地副本，以便未来的读取可以在本地进行。当本地PM使用率较高时，这些辅助文件副本可能会被驱逐。

文件写入。为了减少延迟，文件写入会定向到本地PM。通过对本地文件进行原子日志尾指针更新来保证文件写入的一致性。当文件写入完成时，将向主节点发出异步RPC请求。主节点上的代理线程（第6.1节）将使用diff-update从本地节点获取更新的数据，然后异步地将更新传播到辅助节点。

文件同步。当应用程序对文件调用fsync时，会向每个主节点和辅助节点发送同步的RPC请求，以使用diff-update将文件日志和数据与本地节点进行更新。

内存映射。为了处理mmap请求，Hydra将持久内存上的页面映射到应用程序的地址空间中。当应用程序取消映射页面时，文件将与主副本同步。

5 集群管理

随着Hydra集群规模扩大到大量节点或为长时间运行的应用提供服务，所有节点正常工作并且所有文件访问均平衡的可能性逐渐降低。在本节中，我们描述了Hydra如何优雅地处理节点故障并在运行时实现负载平衡。

5.1 故障容错

Hydra通过容忍运行时任意节点故障为应用程序提供高可用性。在图3的第4步所描述的场景中，由于每个文件都有两个副本，因此Hydra可以容忍在运行时任意单个节点故障，并保证所有文件都可以被检索。对于Hydra集群，通过将复制因子设置为n，可以容忍任意n-1个节点的并发故障而无数据丢失。分权使Hydra能够将失败节点与集群的其余节点隔离开来。

节点故障。如果一个文件正在被非主节点访问，而其主节点宕机，则非主节点将启动主节点选举过程，为文件选举新的主节点。主节点选举是基于Paxos共识协议[33]实现的。具有最长文件日志的节点将被选为新的主节点。如果没有存活节点包含另一个文件副本，发起者将成为主节点。一旦选出主节点，新的主节点将向辅助节点发送RPC请求，确保Hydra集群中的所有其他文件副本都是最新的。

节点恢复。如果宕机的节点可以恢复，它将在重新启动后重新加入Hydra集群。然后，它会将根目录更新到最新版本，然后继续提供文件服务。当通过从根目录进行目录树遍历来访问过时的文件时，过时的文件将与最新版本同步。用户还可以运行fsck来强制将所有本地文件更新到最新版本。请注意，由于本地文件日志仍然有效，我们只需要通过diff-update拉取在节点停机期间提交的新生成文件日志，而不是复制整个文件。这显著提高了节点恢复的效率。

5.2 负载平衡

Hydra利用两种选择算法的变体[34]来实现负载平衡。主节点使用两个一致性哈希函数[35]根据文件的inode号选择文件的辅助节点。在两个候选节点之间，选择占用PM更少的节点作为辅助节点。如果Hydra配置了多个辅助节点，则另一个节点是辅助节点的第二选择，其余的辅助节点按照其PM使用率的升序选择。

数据迁移。Hydra采用分层文件系统设计，完全解耦目录及其子文件/子目录，以在Hydra节点之间平衡负载。对于PM使用率较高的Hydra节点，文件数据将迁移到PM使用率最低的节点。

节点添加。新服务器可以灵活地引入Hydra集群中。它们将以唯一的全局ID加入一致性哈希环，使得在其他Hydra节点上创建的新文件可以将它们指定为主节点或辅助节点。

作为一个完全去中心化的文件系统，Hydra在设计的整个过程中都致力于实现高度可扩展性和可扩展性。在集群级别，Hydra支持在运行时动态添加或删除集群节点，以及容忍任意节点故障。这为集群配置提供了高弹性和灵活性，使得分布式文件系统可以在线扩展。在节点级别，Hydra以完全去中心化的方式组织文件，消除了来自集中式元数据管理的瓶颈，提供了高扩展性。节点之间的一致性和一致性也通过轻量级的去中心化分布式锁定方法得到保证，最小化了大规模Hydra集群中的锁交换开销。在文件级别，Hydra通过差分文件更新方案实现文件更新的同步，通过单向RDMA读取。在文件同步过程中，绕过远程CPU，允许来自不同Hydra节点上的应用程序更多并发访问。在数据传输级别，Hydra通过RDMA请求批处理和RPC分类机制实现高可扩展性，以减少网络开销，并促进其他Hydra节点对高并发访问的便利。我们将在下一节讨论这两种机制。

6 实施

在本节中，我们首先展示了我们在批量RDMA请求和对RPC进行分类方面的方法，以实现Hydra节点之间可伸缩的RDMA通信。然后，我们描述了Hydra如何在每个节点上保持数据一致性。

6.1 可伸缩的RDMA通信

与传统存储和网络设备相比，PM和RDMA技术提供了显著更低的延迟、更高的带宽和更高的可扩展性，这暴露了存储栈中的延迟和可扩展性瓶颈。我们为Hydra中的网络通信提出了RDMA请求批处理和RPC分类机制，旨在通过充分利用高速PM和RDMA网络技术进步的好处，实现可扩展的连接管理和请求处理。

RDMA请求批处理。在每个Hydra节点的发送端（图5a）上，Hydra使用每个CPU的RDMA条目列表发出RDMA请求。这避免了请求争用，并允许并行发出和处理请求。当发出RDMA请求时，创建一个包含WR的RDMA条目，并将其附加到相应的条目列表1。64位wr_id的前12位保留用于指示RDMA操作类型（4位）和CPU ID（8位）2。Hydra将RDMA动词发布到QP，并将RDMA请求状态修改为已发布3。当RDMA操作完成时，CQ处理程序将从CQ中拉取CQE4，跟踪具有wr_id的RDMA条目，并将RDMA请求状态更新为已完成5。

Hydra节点的发送方和接收方消息流。Hydra在发送方批处理RDMA请求，并在接收方将RPC请求分类为同步和异步类型。

Hydra能够将多个RDMA请求合并为单个条目，以实现RDMA请求批处理。应用程序的大文件I/O请求或Hydra节点之间的文件数据复制可能会发出大量异步RDMA请求。批处理这些请求显著减少了整体传输延迟。在RDMA批处理条目内的所有RDMA请求完成之前，相应的文件系统功能将被阻塞6。

RPC分类。在每个Hydra节点的接收端（图5b）上，RPC请求被分类为两类：同步和异步。同步RPC请求，例如在fsync期间的文件复制，由具有较高优先级的RPC线程处理，以减少延迟。当RPC请求被CQ处理程序接收1时，该请求将根据其wr_id立即分派到相应的每个CPU RPC线程的等待列表2。

为了实现可扩展的请求处理，Hydra通过工作窃取将CPU的开销分摊到多个RDMA请求中。如果指定的RPC线程当前正忙于处理其他RPC请求，则新的RPC请求将遍历其他RPC线程的等待列表，并选择负载最低的CPU3。请求处理完成后，接收者回复给发送者4。异步RPC请求，例如后台文件迁移，由每个CPU的代理线程处理。这些代理线程充当其他节点的代理，异步执行任务5。异步RPC以较低优先级处理，以最小化性能影响。

6.2 数据持久性

在Hydra中，包括本地文件写入和文件传输期间的入站RDMA读取在内的文件更新的持久性是通过clwb和sfence指令的组合来保证的，将数据从处理器缓存刷新到PM。对于RDMA读取，Intel的Direct Data I/O（DDIO）技术支持RDMA网络和最后一级缓存（LLC）之间的直接通信。由于DDIO显著提高了数据服务的性能，我们在工作中启用了DDIO进行评估。因此，入站RDMA读取的目标变为本地LLC，可能以任何顺序逐出缓存行。为确保文件传输的持久性，Hydra将传输的数据同步刷新到PM。

7 评估

在本节中，我们评估Hydra相对于支持PM和RDMA的现有分布式文件系统以及本地PM感知文件系统的性能。我们的评估回答以下问题：

• 不同的Hydra复制配置如何影响其I/O性能？（第7.2节）
• Hydra在多线程工作负载下与其他分布式文件系统相比表现如何？（第7.3节）
• Hydra的本地和远程文件访问之间的性能差距有多大？（第7.4节）
• Hydra在多节点上如何扩展并行工作负载？（第7.5节）
• Hydra的元数据操作在性能上表现如何？（第7.6节）
• Hydra从故障中恢复需要多长时间？（第7.7节）

7.1 实验设置

我们在一个4节点集群上运行Hydra。每个节点配备两个Intel Xeon Gold 6240 CPU（主频2.6 GHz，36个物理核），384 GB DDR4 DRAM，12个Optane DCPMMs（每个模块128 GB，总共1.5 TB）。每个集群节点都配备了Mellanox ConnectX-5 InfiniBand网络适配器，连接到InfiniBand交换机。

我们将Hydra与同一集群上的五个分布式文件系统进行比较：CephFS [4]、GlusterFS [6]、NFS [39]、Octopus [2]和Assise [11]。为了公平比较，所有这些分布式文件系统的客户端和服务器都连接到相同的RDMA网络，并在所有四个PM设备配备的集群节点上运行（NFS只有一个服务器节点）。对于基于磁盘的分布式文件系统，我们在服务器节点上使用PM作为元数据和数据的存储设备，并通过替换通信模块来支持RDMA网络。对于Assise，Assise-1r/Assise-3r表示在集群节点中有一个/三个热备份副本。我们还将Hydra与两个本地PM感知文件系统进行比较：EXT4-DAX [40]和NOVA [17]，[21]。

对于Hydra，我们改变复制因子以说明不同存储配置下性能的变化。Hydra-1r/Hydra-2r/Hydra-3r表示在集群节点中有一个主要副本和零/一个/两个次要副本。默认情况下，每个工作负载在本地Hydra节点（主要节点）上运行。对于以读为主的工作负载，Hydra的复制因子不会影响主要节点上的读吞吐量。对于这些工作负载，我们在两个集群节点上设置了Hydra-2r，然后在其中一个节点上预加载文件数据。在实验中，我们比较了在主要节点（Hydra-p）、次要节点（Hydra-s）和需要从主要节点获取所有工作集文件的新连接节点（Hydra-n）上执行的工作负载的吞吐量。我们对每个工作负载运行三次，并报告这些运行的平均值。

7.2 微基准测试

我们使用FIO [41]基准测试评估Hydra的读/写吞吐量。我们对一个1GB文件进行单线程随机I/O操作，使用不同的I/O大小进行一分钟，然后报告平均吞吐量。在同步写工作负载中，在每次写操作后调用fsync。

图6显示了各种I/O大小的读/写吞吐量。Hydra充分利用本地PM的性能优势来提高数据访问局部性，从而最大限度地降低I/O延迟。因此，Hydra的吞吐量在文件读取和异步写入工作负载中的各种I/O大小上接近于NOVA。对于异步写入（图6a），Hydra-3r在4KB的I/O大小下实现了77%的NOVA吞吐量。随着I/O大小的增加，差距迅速缩小。尽管每个文件写入都会发起一个异步RPC请求到每个次要节点，但是次要节点只通过单边RDMA读取同步更新，绕过主节点的CPU。当I/O大小增加时，异步RPC请求的发出频率就会降低。因此，Hydra对大文件写入保持高吞吐量。

FIO性能（对数刻度）。Hydra在不断增加的I/O大小下实现了高吞吐量，并在所有三种工作负载中远远超过了CephFS、GlusterFS、NFS和Octopus，特别是在同步写入方面表现更为突出。

然而，对于同步写入（图6b），每次写操作都会等待所有复制完成。当I/O大小为4KB时，Hydra-2r和Hydra-3r分别实现了NOVA吞吐量的42%和30%。频繁的同步化为数据复制带来了大量的网络流量。然而，Hydra利用差异化文件更新方案只同步最新的日志，通过有效的RDMA读取来降低CPU开销。此外，随着I/O大小的增加，主要瓶颈从日志复制转移到数据复制，Hydra能够批量处理多个RDMA请求，降低数据同步的开销。

对于文件读取（图6c），所有Hydra配置的读取吞吐量非常接近。次要节点拥有文件的另一个完整副本，因此其吞吐量接近主要节点的吞吐量。对于新连接的节点（Hydra-n），文件最初并不存在于本地。当首次读取数据段时，Hydra将该数据段复制到本地节点，使未来的读取变得本地化。同时，Hydra还会发起一个异步请求，将整个文件复制到本地PM。

Octopus在平均读取和写入性能上分别比Hydra-3r差5.1%和3.1%。尽管Octopus绕过内核缓存，但由于FUSE间接层引入了显著开销，文件I/O仍然带来了重大开销。此外，Octopus只通过RDMA网络访问文件数据而没有客户端缓存，导致较高的延迟。由于Octopus中的fsync是无操作的，其同步和异步写入吞吐量接近。

Hydra在吞吐量上远远优于CephFS、GlusterFS和NFS。这三个分布式文件系统由于其基于磁盘的设计，在关键I/O路径上引入了大量的软件开销，使其无法利用PM的直接访问特性和RDMA网络的全部潜力。高远程同步开销进一步降低了它们的同步写入吞吐量。平均而言，Hydra-3r的整体FIO性能超过CephFS、GlusterFS和NFS分别为54.4%、32.9%和7.3%。

7.3 宏基准测试

我们使用三个Filebench [42]工作负载（文件服务器、web代理和varmail）评估Hydra的多线程性能和可伸缩性。表1总结了这些工作负载的特性。每个工作负载的数据集大小设置为32GB，以便进行公平比较。

图7显示了Hydra在集群节点中的Filebench吞吐量以及其他文件系统的吞吐量。我们观察到Hydra在所有三种工作负载中都表现出良好的可伸缩性，并在所有分布式文件系统中实现了最佳性能。Hydra-1r与NOVA之间的性能差距在5%以内。然而，文件复制对于三种工作负载中的Hydra-2r和Hydra-3r产生了不同的影响。平均而言，Hydra-3r在文件服务器、web代理和varmail中分别实现了NOVA性能的91%、88%和78%。由于Optane DCPMM的写入可伸缩性有限，web代理和varmail的吞吐量在八个线程时达到饱和状态。

Filebench性能（对数刻度）。Hydra在所有三种Filebench工作负载中展现出良好的多核可扩展性，并在所有分布式文件系统中实现了最佳的整体性能。Hydra-1r和NOVA的吞吐量曲线高度重叠。

文件服务器模拟了简单文件服务器的I/O活动。Hydra的性能接近于NOVA，并且其吞吐量随着线程数目的增加而高度可伸缩。Hydra利用差异化文件更新方案来降低处理文件服务器中小型异步写入时的CPU开销。因此，Hydra在所有配置下都实现了高吞吐量。在平均下，Hydra-3r在文件服务器中分别比CephFS、GlusterFS、NFS和Assise的性能高出47.3%、21.6%、5.1%和1.7%。

Web代理是一个读密集型工作负载，涉及文件的创建、删除、附加和重复读取。与文件服务器和varmail工作负载不同，web代理工作负载具有较大的目录宽度，因此在这种情况下，目录更新的效率至关重要。幸运的是，由于差异化文件更新方案，Hydra只需同步新创建的目录项日志。此外，这些目录项日志通过出站RDMA读取传输，从而减轻了传输延迟并提高了可伸缩性。对于web代理，Hydra在所有分布式文件系统中实现了最高的吞吐量。

Varmail模拟了一个频繁进行同步写入的电子邮件服务器。在每次fsync期间，Hydra会同时向次要节点发起同步RPC请求，并等待其完成。因此，如图7c所示，Hydra-2r和Hydra-3r的吞吐量非常接近。RDMA请求批处理和RPC分类也降低了文件同步的开销。由于CephFS和GlusterFS在fsync期间引入了高同步开销，Hydra在整体上表现优于CephFS、GlusterFS和NFS分别高出13.9%、16.5%和1.6%。

在varmail工作负载中，Assise-1r在所有分布式文件系统中实现了最佳性能。在Assise-1r中，对日志记录的同步更新大多被后续更新所取代，从而大大降低了Assise的同步开销。Assise的分层租约设计也通过本地化租约管理减轻了网络瓶颈。然而，由于其基于RDMA写入的链式复制设计，Assise的复制开销高于Hydra。平均而言，Hydra-3r在所有三种Filebench工作负载中比Assise-3r高出1.6%。

存储开销。我们通过收集每个节点的PM使用情况来评估Hydra的存储开销，以及不同复制因子的影响。我们在Hydra的一个节点上执行文件服务器工作负载后，测量了文件复制的PM使用情况。由于我们集群中的所有Hydra节点都具有相同的PM容量，Hydra会在其他集群节点之间均匀分配文件副本（次要副本）。对于Hydra-2r/3r，我们观察到复制的存储开销略高于主要节点数据集大小的两/三倍（2.08%/3.17%）。额外的使用开销来自次要节点上少量辅助目录和文件inode。它们用于在每个Hydra节点上维护目录树结构。这使得Hydra即使在所有其他Hydra节点丢失的情况下，仍然可以继续提供其本地文件的文件服务。

负载平衡。正如我们上面所讨论的，Hydra的负载对于静态集群配置是合理平衡的。为了探究Hydra在节点添加后是否重新平衡，我们在具有三个节点的Hydra-3r上运行具有16个线程的Filebench工作负载，然后将另一个节点添加到集群中并重新运行工作负载。我们比较了两种负载平衡技术的性能和PM使用情况：懒惰平衡（Hydra-L）和急切平衡（Hydra-E）。懒惰平衡是Hydra的默认策略，它将新的文件写入引导到新节点，但除非其PM使用率很高，否则不会从旧节点迁移现有文件。另一方面，一些分布式文件系统（例如CephFS的CRUSH算法[43]）采用了急切平衡，在向集群添加节点时会启动后台迁移。Hydra-L的吞吐量与先前运行时相近（在1%之内），而Hydra-E的吞吐量平均下降了4%，这是由于节点通信和后台迁移带来的轻微性能影响。然而，Hydra-E比Hydra-L更快地实现了平衡的数据分布，这将有利于未来其他节点的文件访问，尤其是当Hydra部署在大规模集群中时。我们将快速低开销负载平衡方法的优化留作未来的工作。

7.4 RocksDB

我们用RocksDB[44]展示了元数据和数据复制的高效性，它是基于LSM树的嵌入式键值存储。我们使用db_bench中的三种工作负载来衡量RocksDB的性能：顺序读（readseq）、随机读（readrandom）和随机更新（updaterandom）。对于每个工作负载，我们首先在本地节点上加载包含1000万键值条目的数据库（fillseq），然后报告在本地节点和远程节点上运行1000万键值操作的吞吐量，数据集相同。对于每个工作负载，键大小设置为16字节，值大小设置为4KB。

图8显示了RocksDB的吞吐量。Hydra在所有分布式文件系统中具有最高的吞吐量。对于本地访问，Hydra和NOVA之间的性能差距在4%以内。较少频繁的文件I/O和差异化的文件更新方案帮助Hydra隐藏了前台文件操作的复制开销。在顺序读工作负载中，Hydra-n的性能比CephFS、GlusterFS和NFS分别提高了41%、8.3%和27%。在文件读取期间，CephFS和NFS使用内核缓冲区缓存来实现高吞吐量。由于其高数据管理开销，GlusterFS表现最差。与Hydra-1r相比，Hydra-n的远程随机读性能下降了24%。这是因为Hydra根据文件日志的顺序在工作负载加载期间按顺序写入，将文件数据在后台进行复制。因此，随机读取比本地读取产生更多的访问缺失。

RocksDB性能。由于Hydra采用了差异化文件更新方案和RDMA优化技术，因此Hydra的本地和远程文件访问之间的性能差距很小。

对于本地随机更新，Hydra利用本地PM实现高性能。由于其随机访问模式，CephFS的基于OSD的I/O路径和错误预取使其表现最差。当随机更新由远程节点处理时，除了Hydra之外的所有分布式文件系统都必须经过多个缓存层来同步文件数据。Hydra不仅提供对文件数据的直接PM访问，而且RDMA请求批处理和RPC分类也使Hydra能够通过充分利用RDMA网络的性能优势实现高效的文件传输。对于远程随机更新，Hydra-n的性能优于CephFS、GlusterFS和NFS分别4.9%、2.1%和2.7%。

7.5 MongoDB

我们进一步通过测量流行的NoSQL数据库MongoDB[45]来分析Hydra的并行性能。在MongoDB中，每个更新都被记录到一个日志文件中。在日志持久化之后，MongoDB将更新写入内存映射的数据库文件，并定期调用fsync将其内存刷新到持久存储。我们在MongoDB上运行了YCSB[46]的所有六种工作负载。在YCSB中，每个键值对的大小为1KB（默认值）。对于每个工作负载，我们使用了100万键值条目和1000万操作。线程数设置为8。

图9显示了MongoDB在五个对比文件系统上的吞吐量，Hydra在单一和三重复制配置下的吞吐量，以及在Hydra的四个集群节点上同时运行工作负载的聚合吞吐量。对于单节点性能，Hydra-1r和Hydra-3r的性能接近NOVA，平均比CephFS、GlusterFS和NFS分别快18%、32%和4%。CephFS和GlusterFS受到复杂的数据管理层的影响，而NFS利用内核缓冲区缓存来减少访问延迟。由于I/O活动较少，Hydra比这些传统分布式文件系统的性能优势较小。

在YCSB工作负载下的MongoDB性能。结果是相对于NOVA的吞吐量进行了标准化。Hydra的并行性能随着节点数量的增加具有很高的可扩展性。

Hydra的聚合吞吐量随节点数量显著扩展，表明去中心化充分利用每个节点上的本地PM实现高并行性能。平均而言，Hydra-3r在四个节点上的聚合吞吐量达到了3.8倍NOVA的吞吐量。对于写密集型工作负载（工作负载A和F），Hydra利用差异化文件更新方案将差异文件日志和数据复制到辅助节点，有效缓解了大量日志同步开销。此外，Hydra采用的RDMA优化技术进一步降低了去中心化集群节点的CPU开销。

7.6 MDTest

我们用元数据基准测试MDTest[47]评估了文件系统的元数据性能。我们测量了对目录和文件进行创建、stat和删除操作的吞吐量。我们将MDTest工作负载配置为在目录树中操作，并处理10万个文件。

图10描述了目录和文件元数据操作的吞吐量。在所有分布式文件系统中，Hydra实现了最高的整体元数据吞吐量。对于目录和文件的创建，Hydra-1r的性能接近NOVA。至于Hydra-2r和3r，由于RPC请求传输和处理，它们的吞吐量平均下降了37%。与此同时，所有基于磁盘的文件系统都必须通过为以太网和磁盘设计的复杂软件路径将元数据请求传输到服务器节点，导致比Hydra高几个数量级的延迟。在目录/文件创建之后，Hydra会在本地节点上对其进行缓存以加速未来访问。因此，Hydra在读取目录和文件状态的吞吐量与基于本地PM的文件系统相似。CephFS和NFS利用内核缓冲区缓存提供比GlusterFS更高的元数据读取性能。对于目录和文件的删除，Hydra发送同步的RPC请求以提交删除操作，并发送异步请求以释放存储空间（在第4.4节中描述）。因此，Hydra的性能开销要小得多。与此同时，由于其严格的持久性要求和低效的软件设计，CephFS和GlusterFS的表现要比NFS差。

文件系统元数据操作的吞吐量。Hydra的吞吐量比基于磁盘的分布式文件系统高出数个数量级。

7.7 恢复开销

我们通过测量 Hydra 的恢复时间和 Hydra 恢复全面 I/O 性能所需的时间来评估 Hydra 的恢复开销。为了模拟崩溃，我们首先使用 FIO 加载一个包含八个 4GB 文件的文件集，然后卸载文件系统。之后，我们测量 Hydra 和其他文件系统恢复运行时状态所需的时间。最后，我们在 Hydra 完全恢复性能之前监视其 I/O 吞吐量。

如表 2 所示，Hydra 的恢复时间和其他文件系统的恢复时间都在亚秒级别。对于 Hydra 的恢复，它需要读取超级块以恢复文件系统元数据，例如每个 PM 分配器和索引节点表的利用率，并建立 RDMA 连接到所有其他集群节点。因此，Hydra 的恢复时间略长于 NOVA 的恢复时间。 由于我们采用一种惰性文件同步方法，即只在访问时更新本地过期目录和文件，因此恢复时间不会随着数据大小的增加而增加。为了调查惰性文件同步对 Hydra 运行时性能的影响，我们测量了故障转移后新连接到 Hydra 节点（Hydra-n）上的 FIO 读取操作的前 8 秒动态吞吐量，使用了 8 个线程。FIO 工作负载配置为对文件发出 50% 的随机读请求和 50% 的随机写请求。由于 Hydra-n 没有文件集中文件的本地副本，它必须从其他节点获取文件数据以提供本地 I/O 请求，这会暂时影响性能。如图 11 所示，在故障转移后的前 2-4 秒钟，I/O 吞吐量会受到数据复制的影响。随着 I/O 大小的增加，由于较少的元数据 RPC 传输，复制开销减少，从而缩短了 Hydra 全面恢复 I/O 性能所需的时间。

8 相关工作

持久内存和高速 RDMA 网络的出现为跨服务器拥有大型高性能分布式存储空间提供了机会。在本节中，我们简要介绍与 Hydra 密切相关的工作。

持久内存文件系统。新兴持久内存的有希望特性促进了几个基于 PM 的文件系统 ([12]、[13]、[14]、[17]、[19]、[20]、[21]、[48]、[49]、[50]) 的设计和实现。其中，NOVA [17] 是一个日志结构内核空间文件系统，将元数据和数据存储在 PM 中，并在 DRAM 中维护文件索引。NOVA 结合了日志记录、轻量级日志记录和写时复制技术，为元数据和数据提供强大的原子性保证。另一方面，Strata [49] 是一个用户空间分层文件系统，管理用户空间中的数据访问并在内核空间处理元数据。Strata 利用 PM 的字节可寻址性高效地存储文件日志，并异步地将日志摘要到存储设备上。相较于这些文件系统，SplitFS [19] 利用用户空间库文件系统和内核 PM 文件系统来处理数据和元数据操作。它使用 EXT4-DAX 来管理元数据，并引入了一个新的重连原语以加速文件追加和原子数据操作。Linux 还为现有的文件系统添加了对持久内存的支持，例如 EXT4-DAX [40] 和 XFS-DAX [51]，以允许直接访问持久内存，绕过 DRAM 页面缓存以提高性能。

分布式文件系统。现有的基于磁盘的分布式文件系统，如 CephFS [4]、HDFS [5]、GlusterFS [6]、Lustre [52] 和 GFS [53]，被应用于大规模数据中心部署中。为了实现高扩展性而无需专用元数据服务器，提出了几种去中心化的文件系统，如 GPFS [54]、Farsite [55] 和 DeltaFS [56]。这些文件系统专注于通过在服务器之间分布和复制大块数据块来提供高可用性和可扩展性。为了适应 RDMA 网络，这些基于磁盘的文件系统仅使用 RDMA 库替换通信模块。

Octopus [2] 是一个用户空间分布式文件系统，使用 FUSE [57] 进行文件 I/O。Octopus 引入了自我标识 RPC 和收集-分发事务，以提供低延迟的元数据和数据访问。然而，Octopus 使用静态哈希函数进行文件放置，这限制了其可扩展性并阻止其运行复杂的工作负载。此外，Octopus 既不提供元数据也不提供数据复制，这使其容易受到服务器故障的影响。

Orion [3] 是一个内核空间分布式文件系统，利用 RDMA 提供低延迟文件访问。对于文件 I/O，Orion 使用本地 DRAM 读取缓存和 PM 写入缓冲区来减少网络开销。至于元数据，Orion 使用类似 Mojim 的技术复制文件元数据。所有元数据更新流向一个中央元数据服务器，然后传播到镜像服务器。由于元数据服务器处理所有元数据更新，元数据访问的可扩展性成为 Orion 的瓶颈。

Assise [11] 建立在称为 CC-NVM 的缓存一致性层之上，该层提供了线性化和崩溃一致性。与 Hydra 类似，Assise 利用客户端本地 PM 中的持久缓存实现快速故障转移并最大化局部性。然而，Assise 通过集中式群集管理器协调租约和容错服务。此外，在节点恢复期间，Assise 使自其崩溃以来已写入的每个文件的每个块都无效，这与 Hydra 提出的差分文件更新方案相比显著增加了恢复开销。

据我们所知，Octopus、Orion 和 Assise 是目前仅有的为持久内存（PM）和 RDMA 网络而设计的分布式文件系统。然而，所有这三个文件系统都采用了集中式集群管理和/或数据管理架构，这限制了可扩展性。至于文件复制，Orion 和 Assise 都通过源节点的 RDMA 写操作复制文件，而 Hydra 则通过目标节点的 RDMA 读操作进行复制，其开销较低。Octopus 既不提供元数据复制，也不提供数据复制。

分布式持久内存系统。许多现有系统探索如何利用 RDMA 加速对应用程序的共享内存访问。Hotpot [26] 为应用程序提供全局的共享持久内存空间，并使用多阶段提交协议来确保数据的耐用性和可靠性。AsymNVM [22] 是一个基于不对称持久内存架构的框架。它使用操作日志来减少由于远程持久性而导致的暂停时间，并启用有效的批处理和缓存。Flatstore [29] 是一个基于 PM 的日志结构化存储引擎，将键值存储分离为易失性索引和日志结构化存储，以摊销持久性开销。FileMR [59] 是一个新的内存区域抽象，它结合了 RDMA 内存区域和文件，将持久内存文件系统和 RDMA 控制平面合并在一起。Clover [60] 是一个键值存储系统，将分布式数据平面和集中式元数据平面分离，利用分离持久内存的好处。

已经提出了几种优化 RDMA 网络性能的 RPC 方法。DaRPC [61] 将计算、网络和 RPC 资源分布到 CPU 核心和内存中，以实现高聚合吞吐量。FaSST [24] 是一个基于 RDMA 的 RPC 系统，完全建立在两端 RDMA 动词上，采用不可靠数据报 (UD) 传输来减少 QPs 的数量。ScaleRPC [28] 提出了连接分组，以减少出站消息的 NIC 缓存争用，并实现虚拟化映射来提高入站消息的 CPU 缓存效率。

9 结论

我们实现并描述了 Hydra，这是一个面向高速 PM 和 RDMA 网络的去中心化文件系统。通过利用本地 PM 的性能优势，Hydra 利用数据访问的局部性来实现高性能。为了加速文件传输，文件元数据和数据被分离并通过单向 RDMA 读取进行差异更新。我们通过引入 RDMA 请求批处理和 RPC 分类机制进一步减少网络开销。去中心化设计使 Hydra 能够容忍节点故障并实现负载均衡。我们的评估表明，Hydra 在现有分布式文件系统中表现显著优越，并在多线程和并行工作负载上展现出良好的可扩展性。