(Fast 22) Hydra : Resilient and Highly Available Remote Memory

[Fast 22] Hydra：弹性和高度可用的远程内存
原文链接

摘要   我们目前的 Hydra 是一种用于远程内存的低延迟、低开销和高可用性的弹性机制。 Hydra 可以在 个位数微秒的读/写延迟内访问基于纠删码的远程内存，与最先进的技术相比，显著提高了性能与效率的权衡——它的 性能类似于内存复制，内存开销降低了 1.6 倍。 我们还提出了 CodingSets，这是一种用于擦除编码数据的新型编码组放置算法，它提供负载均衡，同时将相关故障下数据丢失的可能性降低一个数量级。 使用 Hydra，即使只有 50% 的内存是本地内存，未修改的内存密集型应用程序在出现远程故障时也能实现接近完全内存情况的性能，并且优于最先进的远程内存解决方案 高达 4.35 倍。

1 简介

  现代数据中心正在向分解的范式转变，其中每个资源都通过高速网络结构分离和连接 [4、9、13、35–37、58、61、62、81]。 在这种分散的数据中心中，每个服务器节点都专门用于特定目的——一些专门用于计算，而另一些则用于内存、存储等。 内存作为高性能服务的主要资源，正在成为一个有吸引力的分解目标 [18、19、22、32、39、47、50、58、61]。
  最近的远程内存框架允许未经修改的应用程序通过分布式虚拟文件系统 (VFS) 和分布式虚拟内存管理器 (VMM) [18, 47,50, 58, 65, 81, 87]。 随着 RDMA 的出现，远程内存解决方案现在已接近满足支持可接受的应用程序级性能所需的个位数微秒延迟 [47、58]。 然而，为在大规模集群中运行的异构工作负载实现远程内存面临着相当大的挑战 [19, 24]，其根本原因有两个：

1. 扩展的故障域：由于应用程序依赖于远程内存集群中多台机器的内存，因此它们容易受到各种故障情况的影响。 潜在故障包括远程机器的独立和相关故障、远程内存的逐出和损坏以及网络分区。
2. 大规模下的长尾：应用程序也会受到长尾或远程的延迟响应的影响。 长尾可能来自许多来源，包括由于拥塞和背景流量导致的大型网络中的延迟变化 [41]。

  虽然一个会导致灾难性故障，另一个表现为违反服务级别目标 (SLO)，但两者在生产中都是不可接受的 [58,68]。 现有解决方案主要采用三种方法来解决这些问题：(i) 本地磁盘备份 [50、81]，(ii) 远程内存复制 [30、42、46、64]，以及 (iii) 远程内存擦除编码 [76、80、84、86] 和压缩 [58]。 不幸的是，他们遇到了以下问题的某些组合。

  高延迟：磁盘备份没有额外的内存开销，但在任何相关故障下访问延迟高得无法忍受。 采用第三种方法的系统即使与 RDMA 配对也不能满足远程内存的个位数微秒延迟要求（图 1）。
  高成本：复制具有低延迟，但它会增加一倍的内存消耗和网络带宽需求。 磁盘备份和复制代表了性能与效率权衡空间中的两个极端点（图 1）。

  低可用性：即使是极少数服务器变得不可用，所有这三种方法都会失去对低延迟内存的可用性。 使用第一种方法，如果单个服务器发生故障，则需要从磁盘重建其数据，这是一个缓慢的过程。 在第二种和第三种方法中，即使是少量服务器（例如三台）同时发生故障，一些用户也会失去对数据的访问权限。 这是由于复制和擦除编码将副本和编码组分配给随机服务器这一事实。 当少量服务器同时发生故障时，随机数据放置很容易导致数据丢失 [27、28]（图 2）。
  在本文中，我们考虑了如何缓解这些问题，并提出了 Hydra，这是一种用于远程内存的低延迟、低开销和高可用性的弹性机制。 虽然纠删码以减少存储开销和更好的负载平衡而著称，但对于具有微秒级访问要求（最好是 3-5 微秒）的远程内存而言，它具有挑战性 [47]。 我们演示了如何在减少数据放大开销的情况下，即使在同时发生故障的情况下，也能实现具有个位数微秒延迟的弹性纠删码集群内存。
  我们探讨了在不牺牲应用程序级性能或在存在相关故障时产生高开销的情况下弹性远程内存的挑战和权衡（§2）。 我们还探讨了在同时发生服务器故障的情况下负载平衡和高可用性之间的权衡。 我们的解决方案 Hydra 是一种可配置的弹性机制，可将在线纠删码应用于各个远程内存页面，同时保持高可用性（§3）。 Hydra 精心设计的数据路径使其能够在个位数微秒的中值和尾延迟内访问远程内存页面 (§4)。 此外，我们开发了 CodingSets，这是一种用于纠删码的新型编码组放置算法，可提供负载平衡，同时降低相关故障下数据丢失的可能性（§5）。
  我们将 Hydra 开发为一种可应用于现有远程内存框架的嵌入式弹性机制 [18、22、50、65、81]。 我们将 Hydra 与当今广泛接受的两种主要远程内存方法集成在一起：分解 VMM（由 Infiniswap [50] 和 Leap [65] 使用）和分解 VFS（由 Remote Regions [18] 使用）（§6）。 我们使用生产工作负载进行的评估表明，Hydra 实现了两全其美 (§7)。 Hydra 与基于复制的弹性的性能非常接近，内存开销降低 1.6 倍，无论是否存在故障。 同时，它与基于 SSD 备份的弹性相比，基准应用程序的延迟和吞吐量分别提高了 64.78 倍和 20.61 倍，内存开销仅高出 1.25 倍。 在提供弹性的同时，Hydra 还将应用程序级性能提高了 4.35 倍。 CodingSets 将同时发生服务器故障时数据丢失的概率降低了大约 10 倍。 Hydra 可在 https://github.com/SymbioticLab/hydra 获得。
  在本文中，我们做出以下贡献：

• Hydra 是第一个实现个位数微秒尾内存访问延迟的内存纠删码方案。
• 分布式纠删码负载平衡和可用性权衡的新颖分析。
• CodingSets 是一种新的数据放置方案，可平衡可用性和负载平衡，同时将故障期间数据丢失的可能性降低一个数量级。

2 背景和动机

2.1 远程内存

  远程内存将远程机器中可用的内存公开为由许多机器共享的内存池。 它通常通过众所周知的抽象利用远程机器中的搁浅内存来逻辑实现，例如文件抽象 [18]、远程内存分页 [22,47,50,59,65] 和分布式操作系统的虚拟内存管理 [ 81]。 过去，还提出了用于物理内存分解的专用内存设备 [61、63]。
所有现有的远程内存解决方案都使用 4KB 页面粒度。 虽然一些应用程序使用大页面来提高性能 [57]，但 Linux 内核仍然通过拆分单个大页面在基本 4KB 级别执行分页，因为大页面会导致脏数据跟踪的高度放大 [23]。 现有的远程内存系统使用磁盘备份 [50, 81] 和内存复制 [46, 64] 在故障期间提供可用性。

2.2 远程内存故障

  大型远程内存集群发生故障或暂时不可用的可能性更高，因为内存是被远程访问的。 为了说明在出现此类不可预测事件时可能出现的性能损失，我们考虑了现有文献 [50] 中的弹性解决方案，其中每个页面都异步备份到本地 SSD。 我们在内存数据库系统 VoltDB [17] 上运行事务处理基准 TPC-C [16]。 我们将 VoltDB 的可用内存设置为其峰值内存的 50%，以强制对其工作集的 50% 进行远程分页。

  1.Remote Failures and Evictions 机器故障是大规模集群中的常态，每年有数千台机器由于各种原因（包括软件和硬件故障）而崩溃 [31,33,38,88]。 机架或网段内的并发故障非常普遍，通常每年发生数十次。 甚至集群范围的停电也并不少见——在给定的数据中心每年发生一到两次。 例如，在最近一次谷歌云集群范围内的停电期间，大约 23% 的机器数小时不可用 [6]。

  如果没有冗余，当远程机器出现故障或远程内存页面被逐出时，依赖远程内存的应用程序可能会失败。 由于磁盘操作比远程内存的延迟要求慢得多，因此基于磁盘的容错远不实用。 在出现远程故障的情况下，VoltDB 会经历近 90% 的吞吐量损失（图 3a）； 故障发生后吞吐量恢复需要很长时间。

  2. 背景网络负载 整个大型集群的网络负载可能会出现显着波动 [41, 53]，这会增加 RDMA 延迟和应用程序级落后者，从而导致不可预测的性能问题 [40, 89]。 在存在诱导带宽密集型后台负载的情况下，VoltDB 吞吐量下降约 50%（图 3b）。

  3. Request Bursts 应用程序可以有突发的内存访问模式。 现有解决方案维护内存缓冲区以吸收临时突发 [18、50、74]。 但是，由于缓冲区在其已满时将远程访问延迟与磁盘延迟联系在一起，因此当工作负载经历长时间的突发时，缓冲区可能成为瓶颈。 虽然从远程内存读取页面仍然很快，但在图 3c 中的第 100 秒后将备份页面写入本地磁盘成为瓶颈。 结果，吞吐量下降了大约 60%。

  4. 内存损坏 在远程内存访问期间，如果任何一台远程服务器发生损坏，或者如果内存通过网络损坏，则会发生内存损坏事件。 在这种情况下，磁盘访问会导致类似故障的性能损失（图 3d）。

   弹性的性能与效率权衡 在所有这些场景中，显而易见的替代方案——内存中 2× 或 3× 复制 [46、64]——可有效缓解小规模故障，例如单个服务器丢失 （图 3a）。 当内存中的副本不可用时，我们可以切换到替代方案。 不幸的是，复制会产生与副本数量成比例的高内存开销。

   这违背了远程内存的目的。 在复制系统中避免长尾的对冲请求 [41] 也使其带宽需求加倍。 这导致了一个僵局：要么在出现故障时接受高延迟，要么招致高内存开销。 图 1 描述了在故障和内存使用开销下这种性能与效率的权衡，以提供弹性。 除了权衡空间中的两个极端之外，还有两种主要的替代方案可以以低开销实现高弹性。 第一个是在压缩后将页面复制到远程内存（例如，使用 zswap）[58]，这改善了两个维度的权衡。 但是，当数据位于远程内存中时，其延迟可能超过 10µs。 特别是，在资源稀缺期间，由于 CPU 和本地 DRAM 消耗的解压缩需求激增，访问远程压缩页面的长时间突发甚至会导致延迟增加几个数量级。 此外，这种方法面临着与复制类似的问题，例如长尾导致的延迟膨胀。

   另一种方法是纠删码，它最近从基于磁盘的存储转向内存集群缓存，以减少存储开销并改善负载平衡 [20,25, 76,83,84,86]。 通常，一个对象被分成 k 个数据拆分并编码以创建 r 个大小相等的奇偶校验拆分 (k > r)，然后将其分布在 (k + r) 个故障域中。 现有的擦除编码内存解决方案处理大型对象（例如，大于 1 MB [76]），可以忽略其中 TCP/IP 堆栈的数百微秒延迟。 简单地用 RDMA 替换 TCP 也是不够的。 例如，带有 RDMA 的 EC-Cache（图 1）提供的存储开销低于压缩，但延迟约为 20µs。

   最后但并非最不重要的一点是，所有这些方法在存在相关故障的情况下都会遇到高不可用性 [28]。

2.3 纠删码内存的挑战

   高延迟单独纠删编码 4 KB 页面导致已经很小的数据库产生更小的数据块 (4/k KB)，由于以下主要原因，这导致纠删编码远程内存在 RDMA 上的延迟更高：

1. 不可忽略的编码开销：当将纠删码用于磁盘数据或在具有数百微秒延迟的较慢网络上时，其 0.7 微秒编码和 1.5 微秒解码开销可以忽略不计。 但是，在处理 DRAM 和 RDMA 时，它们变得不可忽视。

2. 长尾和错误：由于纠删码在构建原始数据之前需要进行 k 次拆分，因此任何长尾都会减慢远程读取速度。 为了检测和纠正错误，纠删码需要额外的拆分； 额外的读取会增加另一次往返，使整体读取延迟加倍。

3. 中断开销：拆分数据也会增加每个请求的RDMA操作总数。 两者之间的任何上下文切换都会进一步增加延迟。

4. 数据复制开销：在对延迟敏感的系统中，额外的数据移动会限制尽可能低的延迟。 在纠删编码期间，复制到不同缓冲区的额外数据和奇偶校验拆分可能会快速累加。

  同时故障下的可用性现有的纠删码方案可以不间断地处理小规模故障。 然而，当数量相对较少的服务器同时发生故障或变得不可用时（例如，由于网络分区或相关故障事件），它们很容易失去某些数据的可用性。

  这是因为现有的纠删码方案会在随机服务器集上生成编码组 [76]。 在具有 k 个数据和 r 个奇偶校验拆分的编码方案中，如果 r +1 个服务器同时发生故障，则单个编码组将无法解码数据。 现在在一个有 r +1 个故障的大型集群中，那些 r +1 个服务器对于特定编码组发生故障的概率很低。 然而，当编码组是随机生成的（即，每个编码组都会破坏一组随机的 k+r 个服务器），并且每个服务器有大量的编码组，那么这 r+1 个服务器影响任何一个的概率 集群中的编码组要高得多。 因此，即使极少数服务器同时发生故障，最先进的纠删码方案（如 EC-Cache）也将经历非常高的不可用概率。

3 Hydra 架构

  Hydra 是一种用于现有远程内存技术的纠删码弹性机制，可在远程故障下提供更好的性能效率权衡，同时确保同时发生故障时的高可用性。 它有两个主要组件（图 4）：(i) Resilience Manager 在远程读/写期间协调纠删码弹性操作； (ii) Resource Monitor 处理远程机器中的内存管理。 两者都可以存在于每台机器中，并且无需中央协调即可协同工作。

3.1 Resilience Manager

  Hydra Resilience Manager 为客户端机器提供远程内存抽象。 当未修改的应用程序通过不同的最先进的远程内存解决方案（例如，通过 VFS 或 VMM）访问远程内存时，Resilience Manager 透明地处理 RDMA 通信和纠删编码的所有方面。 每个客户端都有自己的 Resilience Manager，它通过 CodingSets 处理 slab 放置，维护远程 slab 地址映射，执行纠删码 RDMA 读/写。 弹性管理器与远程内存主机上运行的资源监视器通信，执行远程数据放置，并确保弹性。 由于客户端的 Resilience Manager 负责其远程数据的弹性，因此弹性管理器不需要相互协调。

  按照典型的 (k,r) 擦除编码结构，Resilience Manager 将其远程地址空间划分为固定大小的地址范围。 每个地址范围位于 (k + r) 个远程平板中：k 个平板用于 slab 数据，r 个平板用于奇偶校验（图 5）。 地址范围的每个 (k +r) slab 都使用 CodingSets (§5) 分布在 (k + r) 个独立的故障域中。 根据地址- slab 映射，页面访问被定向到指定的（k + r）台机器。 尽管远程 I/O 发生在页面级别，但弹性管理器与远程资源监视器协调以管理粗粒度内存块，以减少元数据开销和连接管理复杂性。

3.2 Resource Monitor

   Resource Monitor 管理机器的本地内存，并根据固定大小 (SlabSize) 内存板将它们公开给远程 Resilience Manager。 不同的 slab 可以属于不同机器的 Resilience Manager。 在每个控制周期 (ControlPeriod) 期间，Resource Monitor 跟踪其本地机器中的可用内存，并在内存使用率低（高）时主动分配（回收）slab 到（从）远程映射。 它还在远程故障或损坏期间执行 slab 再生。

  远程内存中的碎片 在 Resource Monitor 的注册期间，Resilience Manager 注册 RDMA 内存区域并根据其内存需求在远程机器上分配 slab。 内存区域通常很大（默认情况下为 1GB）并且整个地址空间被均匀分割。 此外，RDMA 驱动程序保证内存区域在连续的物理地址空间中生成，以确保更快的远程内存访问。 Hydra 不会在远程机器中引入额外的碎片。

3.3 失效模型

  假设 在大型远程内存集群中，(a) 远程服务器可能崩溃或网络可能分区； (b) 远程服务器可能会出现内存损坏； © 网络可能因背景流量而变得拥挤； (d) 工作负载可能具有突发访问模式。 这些事件可能导致灾难性的应用程序故障、高尾延迟或不可预测的性能。 Hydra 解决了其故障域中的所有这些不确定性。 Hydra虽然可以承受远程网络分区，但由于没有本地磁盘备份，无法处理本地网络故障。 在这种情况下，无论如何都无法访问该应用程序。

  单节点故障与同时故障单节点故障意味着远程机器中的 slab 不可用。 在这种情况下，分配在 slab 上的所有数据或奇偶校验都变得不可用。 当我们将一个 slab 的数据和奇偶校验拆分分布到多个远程机器 (§5) 时，在单个节点故障期间，我们假设该页面只有一个数据或奇偶校验拆分受到影响。

  同时主机故障通常是由于大规模故障而发生的，例如导致多台机器无法访问的电源或网络中断。 在这种情况下，我们假设页面的多个数据和/或奇偶校验拆分变得不可用。 请注意，在这两种情况下，数据都不可用，但不会受到损害。 Resilience Manager 可以检测到不可达并与其他可用的资源监视器通信以重新生成特定的 slab。

4 弹性数据路径

  Hydra 可以根据客户的需要在不同的弹性模式下运行 – (a) 故障恢复：在出现任何远程故障或驱逐时提供弹性； (b) 损坏检测：仅检测远程内存中是否存在损坏； © Corruption Correction：检测并纠正远程内存损坏； (d) EC-only 模式：提供纠删码更快的远程内存数据路径，没有任何弹性保证。 请注意，默认情况下这两种损坏模式都继承故障恢复模式。

  在启动 Resilience Manager 之前，需要根据弹性要求和内存开销问题将 Hydra 配置为特定模式（表 1）。 多种弹性模式不能同时作用，并且模式不会在运行时动态切换。 在本节中，我们介绍了 Hydra 的数据路径设计，以解决 §2.3 中提到的弹性挑战。

4.1 Hydra远程内存数据路径

  为了最大限度地减少纠删码的延迟开销，Resilience Manager 的数据路径采用了以下设计原则。

4.1.1 异步编码写入

   为了隐藏纠删码延迟，现有系统通常执行批量编码，其中将多个页面一起编码。 编码器一直等到一定数量的页面可用。 与磁盘或慢速网络（例如 TCP）访问相比，这种空闲等待时间可能微不足道。 但是，要将远程 I/O 的尾部延迟保持在个位数微秒范围内，就需要避免这种“批处理等待”时间。

  在远程写入期间，Resilience Manager 通过将每个页面分成 k 个拆分（对于 4 KB 页面，每个拆分大小为 4 k KB）在每个单独的页面中应用纠删码，使用 Reed-Solomon (RS) 代码对这些拆分进行编码 [77] 生成 r 奇偶校验分裂。 然后，它将这些 (k +r) 个拆分写入不同的 (k +r) 个已经映射到唯一远程机器的 slab。 每个 Resilience Manager 都可以选择自己的 k 和 r。 这种基于页面的单独编码通过避免“批处理等待”时间来减少延迟。 此外，Resilience Manager 不必在远程读取期间读取同一批次中不必要的页面，从而减少了带宽开销。 在许多远程机器上分布远程 I/O 也增加了 I/O 并行度。

  Resilience Manager 首先发送数据拆分，然后编码并异步发送奇偶校验拆分。 在不影响弹性保证的情况下，将两者解耦隐藏了奇偶校验的编码延迟和后续写入延迟。 在没有失败的情况下，(k + r) 的任何 k 次成功写入都允许恢复页面。 但是，为了确保 r 次故障的弹性保证，必须写入所有 (k + r)。 在故障恢复模式下，当所有(k+r)次写入完成后，才认为一次写入完成。 在损坏校正（检测）模式中，为了校正（检测）Δ 损坏，写入等待 k +2Δ+1 (k +Δ) 被写入。 如果确认由于远程机器故障而无法到达 Resilience Manager，则认为该拆分的写入失败。 Resilience Manager 会在超时期限后尝试将该特定拆分写入另一台远程计算机。 图 6a 描述了故障恢复模式下页面写入的时间线。

4.1.2 后期绑定弹性读

  在读取期间，k+r 个拆分中的任何 k 个都足以重建一个页面。 然而，在故障恢复模式下，为了在出现 Δ 故障时保持弹性，在远程读取期间，Hydra Resilience Manager 并行读取 k +Δ 随机选择的拆分。 一旦 k+Δ 中的任何 k 个分割到达，页面就可以被解码。 额外的 Δ 读取也减轻了长尾对尾部延迟的影响。 图 6b 提供了故障恢复模式下读取操作的示例，其中 k = 2 且 Δ = 1，其中一个数据板（数据板 2）是散乱的。 Δ = 1 在实践中通常就足够了。

  如果简单地“检测并丢弃损坏的内存”对任何应用程序来说就足够了，可以为 Hydra 配置损坏检测模式，避免损坏纠正模式的额外内存开销。在损坏检测模式下，在解码页面之前，弹性管理器等待 k +Δ 拆分到达以检测 Δ 损坏。 在检测到一定数量的损坏后，Resilience Manager 将损坏拆分的机器标记为可能的错误机器，启动后台 slab 恢复操作，并在未来的远程 I/O 期间避免它们。

  为了纠正错误，在腐败纠正模式下，当检测到错误时，它会从其余的 k + r 台机器上请求额外的 Δ+1 次读取。 否则，读取会在 k + Δ 分裂到达后立即完成。 如果远程机器的错误率超过用户定义的阈值 (ErrorCorrectionLimit)，则涉及该机器的后续读取请求将以 k +2Δ+1 拆分请求启动，因为到达错误机器的可能性很高。 这将减少额外 Δ + 1 读取的等待时间。 这一直持续到所涉及机器的错误率低于 ErrorCorrectionLimit。 如果这种情况持续很长时间和/或错误率超过另一个阈值 (SlabRegenerationLimit)，Resilience Manager 会为该机器启动一个 slab 再生请求。

  可以将 Hydra 配置为仅 EC 模式，以访问纠删码远程内存，并从没有任何弹性保证的快速数据路径中受益。 在这种模式下，远程 I/O 在写入/读取任何 k 个拆分后立即完成。 表 1 总结了 Resilience Manager 在远程 I/O 操作期间需要写入/读取的最小拆分数，以在不同模式下提供弹性。

  复制开销 为了在故障后保持运行，内存中复制至少需要整个 4 KB 页面的 r+1 个副本，因此内存开销为 (r+1)×。 然而，远程 I/O 操作可以在 r+1 台机器之一的确认后立即完成。 为了检测和修复 Δ 损坏，复制分别需要整个页面的 Δ+1 和 2Δ+1 个副本。 因此，为了提供对 Δ 损坏的正确性保证，复制需要等到它写入或读取至少 2Δ+1 个副本以及 (2Δ+1)× 的内存开销。

4.1.3 Run-to-Completion

  随着 Resilience Manager 将一个 4 KB 的页面分成 k 个更小的部分，RDMA 消息变得更小。 事实上，他们的网络延迟减少到运行到完成变得比上下文切换更有利的程度。 因此，为了避免与中断相关的开销，远程 I/O 请求线程会一直等待，直到 RDMA 操作完成。

4.1.4 就地编码

  为了减少数据副本的数量，Hydra Resilience Manager 使用就地编码和额外的 r 拆分缓冲区。 在写入期间，数据拆分始终保持在页内，而编码的 r 奇偶校验位被放入缓冲区（图 7a）。 同样，在读取过程中，数据拆分到达页地址，奇偶校验拆分进入缓冲区（图 7b）。

  在故障恢复模式下，只要有 k 个有效分割到达，一次读取就可以完成。 损坏/散乱的数据拆分可能会延迟到达并覆盖有效的页面数据。 为了解决这个问题，一旦 Hydra 检测到 k 个有效拆分的到来，它就会注销相关的 RDMA 内存区域。 然后它执行解码并将解码后的数据直接放在页面目标中。 因为内存区域已经被注销，所以任何后期的数据拆分都无法访问该页面。 在所有远程 I/O 期间，请求直接转发到 RDMA 调度队列，无需额外复制。

4.2 处理不确定性

  远程故障 Hydra 对所有 RDMA 通信使用可靠连接 (RC)。 因此，我们认为由于机器故障/重启或网络分区导致的无法访问是失败的主要原因。 当远程机器变得不可访问时，Resilience Manager 会收到 RDMA 连接管理器的通知。 断开连接后，它首先按顺序处理所有进行中的请求。 对于正在进行的 I/O 操作，它将 I/O 请求重新发送到其他可用机器。 由于RDMA保证了严格的顺序，在先写后读的情况下，读请求会在写请求之后到达同一个RDMA调度队列； 因此，读取请求将不会使用旧数据。 最后，Hydra 标记失败的 slab，并将未来的请求定向到可用的 slab。 如果发生故障的机器中的资源监视器稍后恢复并进行通信，Hydra 会重新考虑该机器以进行进一步的远程 I/O。

  Adaptive Slab Allocation/Eviction Resource Monitor 为 Resilience Manager 分配内存 slab 并主动释放/驱逐它们以避免本地性能影响（图 8）。 它会定期监控本地内存使用情况并维护一个空间，为本地应用程序提供足够的内存。

  当可用内存量缩减到净空（图 8a）以下时，资源监视器首先主动释放/逐出 slab，以确保本地应用程序不受影响。 为了找到驱逐候选者，我们避免了随机选择，因为它更有可能驱逐繁忙的 slab。 相反，我们使用分散式批量驱逐算法 [50] 来选择最不活跃的平板。 为了驱逐 E 个 slab，我们联系 (E +E’ ) 个 slab（其中 E’ ≤ E）并找到其中访问频率最低的 slab。 这不需要维护全局知识或搜索所有平板。 当可用内存量增长超过净空（图 8b）时，资源监视器首先尝试让本地弹性管理器从远程内存中回收其页面并取消映射相应的远程平板。 此外，它会主动分配新的、未映射的平板，远程弹性管理器可以轻松映射和使用这些平板。

  后台板重新生成资源监视器还在后台重新生成不可用的板——由弹性管理器标记。 在再生期间，禁用对 slab 的写入，以防止用陈旧的页面覆盖新页面； 仍然可以不间断地提供读取服务。

  Hydra Resilience Manager 使用放置算法在远程资源监视器中找到内存使用量较低的新再生板。 然后它将重新生成 slab 的任务移交给该资源监视器。 选定的资源监视器通过直接读取该地址区域的 k 个随机选择的剩余有效 slab 来解码不可用的 slab。 重新生成完成后，它会联系 Resilience Manager 以将 slab 标记为可用。 此后的请求转到重新生成的 slab。

5 高可用性 CodingSets

  Hydra 使用 CodingSets，一种新颖的编码组放置方案来执行负载平衡，同时降低数据丢失的可能性。 先前的工作表明，由于导致多个节点同时发生故障的事件导致的数据丢失比由于独立节点故障导致的数据丢失要高出几个数量级 [27、31]。 有几种情况会导致多台服务器同时出现故障或不可用，例如网络分区、部分断电和软件错误。 例如，停电会导致 0.5%-1% 的机器同时发生故障或离线 [28]。 在 Hydra 的情况下，如果并发故障导致特定编码组的 (k + r) 台机器中超过 r +1 台机器死亡，则会发生数据丢失。

  我们受到复制集的启发，复制集是一种在复制相关故障下防止数据丢失的方案 [27、28]，它限制了复制组的数量，以减少数据丢失事件的频率。 使用与先前工作相同的术语，我们将编码组中的每个唯一的 (k + r) 个服务器集定义为一个副本集。 单个编码组中的副本数将为：(C(k+r, r+1)) 。 例如，在 (8+2) 配置中，节点编号为 1,2,…,10，如果它们同时失败（即副本集）将导致失败的 3 个节点将是每 3 个组合 10 个节点：(1,2,3),(1,2,4),…,(8,9,10)，复制集的总数将为 C(10, 3) = 120。

  对于同时恰好影响r+1个随机节点的数据丢失事件，单个特定编码组的数据丢失概率：P[Group] = Num。 (Copysets in Coding Group)/(Total Copysets) = (C(k+r, r+1)) / (C(N, r+1)) ，其中 N 是服务器总数。

  在超过（k + r）台服务器的集群中，我们需要使用多个编码组。 但是，如果每台服务器都是单个编码组的成员，那么如果该组的一个或多个成员过载，就会出现热点。 因此，出于负载均衡的目的，一个简单的解决方案是让每个服务器都成为多个编码组的成员，以防在线编码时某个特定编码组的某些成员过载。

  假设我们有 G 个不相交的编码组，并且相关故障率为 f %，则数据丢失的总概率为：1−(1−P[Group]·G) ( N· f r+1 ) 。 我们定义了不相交的编码组，其中这些组不共享任何副本集； 或者换句话说，它们的重叠不超过 r 个节点。

  Strawman：每个服务器多个编码组为了均衡负载，我们考虑一种方案，其中每个slab 在编码时与集群中负载最少的节点形成一个编码组。 我们假设在给定时间负载最小的节点是随机分布的，每个服务器的 slab 数量是 S。当 S · (r + k) << N 时，编码组很可能不相交 [28]，并且 组数等于： G = N · S / k + r 。

  我们将这种放置策略称为 EC-Cache 方案，因为它会产生一个随机编码组放置，供先前最先进的内存擦除编码系统 EC-Cache [76] 使用。 在这个方案中，即使每台服务器的 slab 数量不多，r +1 台机器的大量组合也将是一个副本集。 换句话说，即使集群中有少量节点同时发生故障，也会导致数据丢失。 当每台服务器的 slab 数量很高时，几乎所有集群中只有 r + 1 次故障的组合都会导致数据丢失。 因此，为了降低数据丢失的概率，我们需要尽量减少 copysets 的数量，同时实现足够的负载均衡。

  CodingSets：减少纠删码的副本集 为此，我们提出了 CodingSets，一种新颖的负载平衡方案，它减少了分布式纠删码的副本集数量。 在我们的方案中，不是像 EC-Cache 那样让每个节点参与多个编码组，而是每个服务器属于一个扩展的编码组。 在编码时，（k+r）个 slabs 仍然会被一起考虑，但是参与编码组的节点是从一组（k+r+l）个节点中选择的，其中 l 是负载平衡因子。 在扩展组中选择的节点是负载最少的节点。 在扩展编码组的同时增加了复制集的数量（而不是 C(k+r, r+1) 个复制集，现在每个扩展编码组创建 C(k+r+l, r+1) 个复制集，而组的数量为 G = C(N, k + r + l )，它仍然比让每个节点属于多个编码组具有更低的数据丢失概率。 Hydra 使用 CodingSets 作为其负载平衡和 slab 放置策略。 我们在第 7.2 节中对其进行评估。

  权衡 请注意，虽然 CodingSets 降低了数据丢失的可能性，但它并没有减少随着时间的推移丢失的预期数据量。 换句话说，它减少了数据丢失事件的数量，但这些事件中的每一个都会按比例增加数据丢失的幅度（即，更多的板将受到影响）[28]。 鉴于我们对 Hydra 的目标是高可用性，我们相信这是一个有利的权衡。 例如，供应商通常提供可用性 SLA，它由服务可用时间衡量（例如，服务在 99.9999% 的时间内可用）。 CodingSets 会针对这样的 SLA 进行优化，通过最小化不可用的频率，甚至

6 实现

  Resilience Manager 作为 Linux 内核 4.11 或更高版本的可加载内核模块实现。 内核级实现有助于将其部署为不同远程内存系统的底层块设备 [18、50、81]。 我们将 Hydra 与两个远程内存系统集成在一起：Infiniswap，一个分解的 VMM 和 Remote Regions，一个分解的 VFS。 所有 I/O 操作（例如，slab 映射、内存注册、RDMA 发布/轮询、擦除编码）都是跨线程独立的，并且在没有同步的情况下进行处理。 所有 RDMA 操作都使用 RC 和单边 RDMA verbs (RDMA WRITE/READ)。 每个 Resilience Manager 为每台活动的远程机器维护一个连接。 对于纠删码，我们使用 x86 AVX 指令和 ISA 库 [8]，在我们的评估平台中针对 (8+2) 配置实现了每核超过 4 GB/s 的编码吞吐量。

  Resource Monitor 是作为用户空间程序实现的。 它对所有控制消息使用 RDMA SEND/RECV