论文阅读-CARD：一种针对复制元数据服务器集群的拥塞感知请求调度方案

论文名称：CARD: A Congestion-Aware Request Dispatching Scheme for Replicated Metadata Server Cluster

摘要

复制元数据服务器集群（RMSC）在分布式文件系统中非常高效，同时面对数据驱动的场景（例如，大规模分布式机器学习任务）。然而，考虑到成本效益和系统利用率，实践中通常会限制集群规模。在这种情况下，由于客户端对拥塞不知情的行为和非智能选择策略（即，集群中的服务器被间歇性地优先选择然后避开），集群中的服务器开始在更高的系统利用率下遭受负载波动。负载波动带来的后果在一定程度上降低了整个系统的总体性能。解决这个问题的一个方案是让客户端分担部分责任，并为了稳定性更明智地行事。因此，在本文中，我们提出了一种拥塞感知请求调度方案，CARD，主要在客户端执行，并由速率控制机制指导。通过广泛的实验，我们验证了CARD在解决RMSC中的负载波动方面高度有效。除此之外，我们的结果显示，与以前的实现相比，我们基于拥塞感知的优化使RMSC在面对目标工作负载时实现了更好的可扩展性，特别是在异构环境中。

CCS概念

• 计算机系统组织→特殊目的系统；实时操作系统；• 信息系统 → 分布式存储。

关键词

复制元数据服务器集群，拥塞感知，速率控制，负载均衡，分布式文件系统

1 引言和动机

系统设计者已经投入了巨大的努力来提高分布式文件系统的性能，这些系统被证明对许多应用程序的总体性能至关重要。一些研究（例如，[5, 42, 46, 49]）集中在元数据管理上。一般来说，分布式文件系统的客户端与元数据服务器（MDS）交互以执行元数据请求（例如，打开、创建或重命名），同时直接与数据节点（或对象存储设备）通信以执行文件I/O [48]。为了保持元数据的一致性和有效性，即使是最可扩展的系统（例如，HDFS [41]，Lustre [8]）也通常将文件元数据存储在单个专用的MDS上，这些系统能够在数千台机器上存储数百PB（或更多）的数据。因此，这个单一服务器在服务数据驱动应用程序时，尤其是像LDA* [54]和DIEN [56]这样的大规模分布式机器学习任务时，可能成为性能瓶颈。通常，这些应用程序使用数百到数千台机器，在参数服务器框架下，使用几个巨大的数据集对一个极大的模型进行训练 [26, 53]。如果由于MDS处的拥塞而延迟了文件元数据访问，整个训练过程可能会严重受到数据读取管道的限制 [10]。除此之外，由于计划内或计划外事件（例如，硬件故障和软件错误）引起的单点故障的风险，可能对整个系统的可用性构成巨大风险 [38]。

为了解决这些问题，几项研究 [23, 31, 42, 52] 已经指出了GFS/HDFS类文件系统可以采取的路径，以消除单一MDS作为性能瓶颈和可用性隐患。它们都分享了一个相同的想法，即在许多机器上复制所有文件元数据，并使用仲裁协议（例如，Paxos [25]或Raft [33]）管理它们。我们将这些机器概括为复制元数据服务器集群（RMSC），尽管具体目的的底层实现细节可能大不相同。为了减少复制开销，某些优化技术 [9, 13, 16, 17, 28, 55]，如批处理 [6]，对于特定实现是可选的。RMSC的架构示意图如图1所示。由于RMSC中的每个单独服务器都有所有元数据的完整副本，即使主MDS宕机，这个集群也在防止单点故障方面高度有效（由基于共识的故障转移机制确保）。此外，RMSC的一个显著优点是，所有并发的读元数据请求（例如，open、readdir和stat），通常占所有文件系统操作的80%到95% [46, 52]，可以在集群中的所有服务器之间平等（或启发式地）分配。这一特性完美地满足了产品环境中实际应用的可扩展性和性能要求，特别是对于一些数据驱动的应用程序。

尽管可以通过不断增加机器数量来提高RMSC的容量，但考虑到成本效益和系统利用率，集群规模不能无限制地增加。在这种情况下，RMSC中的服务器开始由于严重的负载不平衡和在更高系统利用率下的负载波动而遭受显著的性能下降 [21]。最终，为了抵消这种现象导致的可扩展性降低的影响，在实际生产环境中需要更多的服务器，并且需要激活它们，这是资源的浪费。

为了缓解这个问题，一些服务器端负载均衡技术，如Slicer [3]和Maglev [12]，已经被提出来减少类似分布式内存应用 [15, 29, 34, 45, 47] 的负载不平衡。大多数研究引入了一个集中式负载平衡器作为客户端和服务器之间的中间层代理。通常，额外的计算资源需要用于负载平衡服务和其他附加功能。同时，需要从服务器端持续收集监控数据。尽管这种策略在许多场景中被证明是有效的，但它重新引入了一个潜在的性能瓶颈和元数据服务层的可用性隐患，特别是在繁重的工作负载下。如果负载平衡器失败，所有请求将被阻塞或不均匀地分发。然后，超时请求将被重新调度，进一步增加负载平衡器和所有服务器的负载。

服务器端负载平衡策略的一个替代方案是让客户端分担部分责任，并启用客户端限流技术，这可能更具成本效益且不那么复杂。毕竟，负载不平衡和负载波动主要是由客户端对拥塞不知情的行为（即，即使服务器饱和，也继续向服务器施加大量请求）和非智能行为（例如，由启发式选择引起的群体行为 [30, 36]）在RMSC中引起的。此外，服务器上发生的一些不可预测事件，如日志压缩或垃圾收集，也会导致周期性性能下降 [7]。如果客户端能够更明智地行事，并始终选择负载较轻的服务器作为目标，整个集群可能能够实现更高的总体吞吐量。不幸的是，流行的启发式策略，即偏好响应时间移动平均值较低的服务器，或像轮询 [40] 这样的简单调度方案都不能满足要求，特别是当服务器的容量在变化或异构时。

在这项研究中，我们重新审视了客户端负载平衡技术。我们的目标是（1）为同质和异质（计划内或运行时意外出现的）RMSC设计一个通用的调度方案，以充分利用它们的容量，同时（2）防止过载和负载波动的发生。为此，我们提出了一种拥塞感知请求调度方案，CARD。它主要由速率控制机制指导，在客户端执行，以感知和缓解服务器处的拥塞。简而言之，每个客户端通过速率限制器限制其在小时间窗口内路由到每个服务器的请求数量，并且仅通过其视角的信息以分散的方式调整这个数量（即，限制）。如果所有的速率限制器达到了它们对应的限制，这个客户端将在一段时间内保留其进一步的请求在后台队列中，等待服务器处理。另一方面，如果客户端意识到一个服务器相对空闲，他们将逐渐增加他们的速率限制器的限制，以利用这个服务器的更多容量（详见第3节）。通过这种拥塞感知的速率控制机制，这是CARD的关键见解，我们在追求最大性能的同时，从源头上防止了过载情况的发生。

我们的贡献总结如下：

• 我们介绍了由客户端对拥塞不知情的行为引起的负载波动问题，在扩展时降低了整个系统的总体性能。

• 我们在客户端提出了一种拥塞感知请求调度方案，CARD，以感知和缓解服务器处的拥塞，同时最大化RMSC的效用。

• 我们进行了广泛的实验来验证CARD的效率。结果表明，CARD在解决RMSC中的负载波动方面非常有效。此外，结果还显示，与竞争实现相比，CARD使RMSC在面对目标工作负载时实现了更好的可扩展性，特别是在异构环境中。

本文的其余部分按以下方式组织。第二节展示了相关工作。第三节详细介绍了CARD的整体设计。第四节展示了实施和实验方法以及结果和分析。然后，第五节讨论了CARD的适用性和限制。最后，第六节总结了本文。

2.相关工作

元数据管理。如今，大多数分布式文件系统使用专用机器来存储所有元数据并提供元数据服务，例如GFS和HDFS[18, 22, 41]。因此，这些系统的整体性能基本上受到元数据管理层的限制。至于基于共享磁盘抽象[37, 50]的实现，如IBM的GPFS，它们允许多台机器通过分布式锁机制同时访问磁盘。然而，这些实现极度依赖低延迟网络构架来暴露统一的磁盘地址空间。除此之外，它们在一定程度上受到共享磁盘的限制。

为了消除元数据管理层的存储瓶颈，一些分布式文件系统（例如Ceph[48]、Giga+[35]和BeeGFS[1]）正在探索元数据管理的分布式实现，如子树划分和哈希划分[46]。然而，这些实现在命名空间局部性和负载平衡之间存在权衡。尽管提出了一些基于迁移的技术[48]来解决这个问题，但迁移开销仍然过于昂贵而不能忽视。此外，这些基于迁移的技术基于客户端访问模式是倾斜但相对稳定的前提。因此，如果上层应用以非倾斜方式访问数百万文档且具有间歇性局部性，它们并非最佳选择。除此之外，大多数基于划分的实现并不能避免单点故障的问题，这意味着即使这些系统确实通过检查点机制和日志确保了容错能力，它们也可能在一段时间内部分不可用。

针对可用性问题和性能瓶颈，进行了几项关于复制基础实现的研究[23, 31, 42, 46, 52]，这些实现旨在扩展分布式文件系统的元数据管理层。然而，所有这些工作都没有在保持更高系统利用率的同时仔细考虑负载波动问题，因为它们假设集群规模可以不受限制地扩展，而不考虑整个系统的成本效益。因此，像Round-Robin[40]（或随机）这样的简单调度方案自然成为这些实现中的默认设置（例如，hopsfs[23]），在面对异构和变化的运行时环境下饱和的工作负载时，这可能成为潜在威胁。因此，我们有动机解决这个问题，并在这样的复制基础实现中实现长期成本效益和更高的系统性能。

拥塞控制。在元数据管理层，这个话题还没有得到充分探索，因为在“大数据”时代之前，大规模文件密集型应用还不够普遍。然而，在数据节点层和HPC领域考虑了类似的主题。例如，Dorier等人[11]提出了一种动态调度策略，它使客户端能够通过客户端间通信彼此沟通和协调运行时调度情况。然而，由此带来的通信成本在一定程度上减慢了整个系统。与这种基于交互的设计不同，Gainaru等人[14]提出了一种基于客户端过去行为、响应时间和系统特征的全局启发式策略。同样，AID[27]是一种基于阈值的分散实现，但分享了相同的理念（即，使用过去的数据进行未来的调度）。与全局方式相比，AID的非全局实现更为优雅，因为它没有潜在的全局性能瓶颈。然而，启发式目标选择容易导致羊群行为，这在重负载下是性能威胁。为了在数据节点层进行拥塞控制，LADS[24]采用了简单的Round-Robin调度方案和基于阈值的限流机制，以避免对I/O请求的拥塞服务器。简而言之，LADS记录了来自服务器的响应时间，并在时间窗口W内计算多个对象响应时间的平均值。如果W期间的平均响应时间大于预设的阈值（T），则将服务器标记为拥塞。然而，这种机制的阈值T从开始到结束都是确定的，这意味着LADS无法适应变化的工作负载，更不用说T的值很难精确确定了。但最重要的是，LADS不足以避免负载波动。

为了克服这些缺点，我们提出了一个自适应速率控制机制，该机制受到CUBIC[4, 19, 39, 44, 51]的启发，CUBIC是TCP协议的一个可扩展窗口增长算法，并使其成为CARD的支柱，以确保请求调度程序具有感知拥塞的特性。与以前的实现相比，CARD是一种分散且自适应的方法，同时不需要客户端间通信。

3.CARD的整体设计

CARD在感知拥塞和防止负载波动方面非常有效，这主要是通过客户端上的自适应速率控制机制实现的。在本节中，我们将详细展示CARD的设计。我们首先通过介绍几个涉及的模块以及流程路径来介绍CARD，这有助于理解CARD的全貌。然后我们描述了前述速率控制机制的具体细节。

3.1CARD概述

本文介绍的拥塞感知请求调度方案CARD的概述如图2所示。如图所示，客户端需要实现几个模块。第一个模块是选择器，它基于Round-Robin调度的调度器。第二个模块是速率限制器。它负责限制在小时间窗口内路由到相应服务器的请求数量。请注意，每个客户端一旦服务器被配置并注册为可用，就会自动启动一个一对一映射的速率限制器线程。在反馈模块的帮助下，每个客户端根据相应服务器的拥塞情况动态调整限制。如果所有的速率限制器都达到了它们对应的限制，这个客户端将会暂时保留它的进一步请求在后备队列中，等待服务器再次健康。最后一个是反馈模块。顾名思义，它负责接收来自服务器的反馈，并将重新处理的信息分发给相关模块以进一步利用。这三个模块共同确保了CARD的速率控制机制。

3.2拥塞感知速率控制机制

目前，由于很少或根本没有利用已知信息，RMSC中的客户端对拥塞一无所知，这意味着它们可能会继续根据Round-Robin调度方案向服务器发送大量请求，即使服务器已经饱和。这可能导致服务器出现过载情况。为了克服数据传输中的同一问题，LADS[24]在客户端采用了基于阈值的限流机制以及Round-Robin调度方案[20, 40]，以基于响应时间的移动平均值避免拥塞服务器。然而，通过第四节中的广泛实验，我们观察到这种技术不足以支持即将到来的数据驱动应用在元数据服务层的日益增长的需求。此外，这种技术的阈值是预先确定和固定的，这意味着LADS不灵活且不自适应。除此之外，没有具体的指导或信息关于这个值的确定，这意味着阈值是根据经验确定的。不同于LADS，CARD采用了自适应速率控制机制来解决RMSC中的拥塞控制问题，而不会导致负载波动。简而言之，每个客户端只关注从其角度利用已知信息。毕竟，对客户端来说，从头到尾了解RMSC中所有服务器的全貌几乎是不可能的，也太昂贵了。

为了实现这种速率控制机制，如图2所示，每个客户端在请求处理单元为每个服务器维护若干个速率限制器。每个属于客户端i的速率限制器限制在δ ms的指定时间窗口内发送到相应服务器的请求数量。我们将这个数字定义为Lij。然后我们推导出发送速率Lij /δ，表示为Sij。例如，Sij代表在这个时间窗口内客户端i到服务器j的发送速率。此外，客户端i到服务器j在这个时间窗口内已经发送的请求数量表示为Nij。我们确保Nij始终不大于Lij，以指导调度程序以控制速率为目的。为了自适应地修改客户端i到服务器j的发送速率，Lij的值由Sij · δ + l′ij动态确定，其中l′ij是上一个时间窗口的未使用配额。同时，客户端i还跟踪Cij，即在δ ms间隔内从服务器j收到的响应数量。同样，我们可以将Rij看作是这个时间窗口内的接收速率，即Cij /δ。为了平滑Rij的值，引入了一个权重参数ϕ。最终，我们得出接收速率的计算函数如下：

其中R′ij是上一个时间窗口的接收速率。我们的速率控制机制的目标是在感知到Rij的值的帮助下动态调整Sij。

为了仅从客户端i的角度等价地确定拥塞事件，我们定义了如下的条件表达式：

其中T_nowij是服务器j回复未解决请求并向客户端i提供反馈的时刻，T_incij是Sij最后一次增加的时刻。参数λ代表自上次增加速率事件以来的滞后期，以便允许客户端i有足够的时间更新Rij（即，从其角度看服务器j的最新容量）。如果这个条件表达式的值为TRUE，那么我们认为服务器j发生了拥塞事件。因为它表明当前服务器j的处理效率无法及时处理客户端i发送的所有请求，即使客户端i已经等待了λ时间。

每当服务器j发生拥塞事件时，客户端i将当前的Sij注册为饱和发送速率Mij。同时，客户端i通过一个预定的常数β对Sij进行乘法减少。在客户端i进入拥塞避免模式后，它开始根据立方函数从Mij · (1 − β)缓慢增加发送速率，直到发送速率变为Mij。这个立方增长函数如下所示：

其中α代表一个缩放因子，可以调整以导出平台区域的适当持续时间，∆t是自上次拥塞发生以来的经过时间。如上所述，Mij是上次发生拥塞时的饱和发送速率，也是这个立方函数的平台值。如果在拥塞避免期间再次发生拥塞事件，则Mij将再次被当前的Sij替换，客户端i将再次从Mij · (1−β)调整Sij。然而，如果Sij达到Mij且服务器j仍然没有拥塞事件的迹象，客户端i将继续谨慎增长发送速率，以寻找附近的新最大值。在慢速增长一段时间后，如果不发生拥塞，那么客户端i猜测新的最大值更远，并切换到更快的增长模式。

这个立方增长函数的曲线如图3所示，可以分为三个部分：

• 凹陷区域：当当前的Sij低于Mij时，Sij的增长速度逐渐放缓。

• 平台区域：当发送率Sij接近服务器j感知的饱和值Mij时，客户端i稳定其发送率，并谨慎地增加它。

• 凸出区域：如果客户端i在平台区域停留足够长的时间，它将逐渐增加Sij的增长速度，以利用服务器j的更多容量。

无论Sij处于哪个区域，如果客户端i感知到其发送率Sij超过了Rij（即从其角度看服务器j的当前容量）并且条件表达式为真，它将更新对该服务器饱和值（即Mij）的看法，并将其发送率降低到Mij · (1 − β)。请注意，这种速率控制机制在每个客户端的处理单元中以相同的方式工作，我们仅以Sij的速率控制程序为例进行演示。

算法1展示了CARD请求调度函数的伪代码。首先，这个调度函数根据轮询调度获取可访问的服务器。之后，它将逐个检查服务器，直到客户端i在当前时间窗口内发送给服务器j的请求数量Nij位于限制Lij内。如果从其角度看所有服务器都不可用，这个请求将被保留在积压队列中，直到下一个时间窗口开始。

一旦请求被目标服务器处理，将有响应发送给客户端。算法2展示了客户端在收到服务器响应后的速率适应程序。请注意，每一步的增量在参数γ内受到限制，以考虑稳定性问题。

3.3 参数设置

在本节中，我们展示了上述参数α、β、δ、λ、γ和ϕ的设置标准。它们针对不同的目标实现和稳定性需求高度定制。 我们首先讨论α和β，这是与第3.2节提到的立方增长曲线相关的缩放因子。简而言之，α决定了平台区域的长度，而β决定了截距。如图4所示，α越小，平台区域就越长。同时，β在拥塞事件发生时，借助动态变量Mij确定初始速率。 考虑到系统利用率，我们建议β的范围是0.1到0.3。毕竟，配置一个大的β对于充分利用每个服务器的容量来说过于悲观，而一个极小的β通常会导致频繁的拥塞事件。 至于δ和λ，这些参数与时间窗口的概念相关。与许多研究一样，CARD要求时间窗口间隔δ足够小，以反映实时系统情况。因此，像5ms或10ms这样的值在大多数条件下是足够的。而滞后持续时间参数λ可以相应地设置为时间窗口间隔δ的两倍或三倍。然而，如果δ太小，无法捕获足够的信息进行分析，所呈现的算法CARD将不会起作用。因此，不建议时间窗口间隔小于1ms。 最后，我们讨论γ和ϕ。在大多数场景中，最大增量步长γ不是一个必须配置的关键参数。它更像是我们所提出算法的额外稳定性保证。我们所要做的就是根据每个服务器的最大容量估计一个相对适中的值。至于权重参数ϕ，它是指数加权移动平均（EWMA）的一个众所周知的参数，EWMA是一阶无限脉冲响应滤波器。通常，ϕ被设置为广泛采用的默认值，即0.90。

参数调优过程中α和β的说明。(a)显示为参数α的影响，而β被设置为0.2。而(b)表示，当α设置为0.00004时，参数β对第3.2节中上述三次生长函数的影响。在(a)和(b)中，我们将Mij配置为20Kops/秒作为解释示例。

请注意，这些参数直接影响正在进行的速率适应程序，但所有可行的参数选择最终都会导致近似的拥塞感知特性。为了获得最佳实践，可以按照上述设置标准在几次迭代内进行微调实验，针对特定实现。一旦参数设置完成，服务运营商就不需要重新调整这些参数，因为速率适应程序已足够健壮和自适应。

4 性能评估

在本节中，我们在同质和异质环境中进行了广泛的实验，以全面评估CARD在RMSC中的性能。首先，我们评估CARD的拥塞感知速率控制机制的正确性。然后，我们将CARD与LADS和其他广泛采用的调度方案进行比较，以展示CARD在解决负载振荡方面的效率。

4.1 实验设置

CARD旨在防止过载情况并解决RMSC中的负载振荡，以实现更高的系统利用率。因此，在这项研究中，我们选择了明确强调元数据子系统极限的实验，这些也是实际产品环境中的目标工作负载，以评估CARD的有效性。 实现细节、参数设置和基准测试如下所述。

实现。我们的实验对象是一个包含一个主服务器和最多七个副本的8服务器集群。每台服务器配备了一个4核Intel Xeon E3-1220处理器，时钟频率为3.00 GHz，主内存为15717 MB。它们都运行64位的CentOS 7.4.1708，搭载3.10.0 Linux内核，并通过10 Gb/s以太网交换机连接。在软件层面，我们基于Berkeley DB Java Edition 7.1.9 [42]为模拟目的实现了一个RMSC原型。Java SE运行时环境版本为1.7.0_45。请注意，这个原型是元数据管理层的重构版本，通常在分布式文件系统中独立功能。为了研究CARD在异质环境中的性能，当我们进行相关实验时，我们限制了副本的并发线程限制。具体的设置细节将在相应的小节中提及。此外，我们部署了另外10台机器作为客户端，对RMSC的服务器施加压力。这些机器也运行64位的CentOS 7.4.1708，搭载3.10.0 Linux内核。它们每台都有4 GB的主内存。我们通过两个10 Gb/s路由器将这些机器与服务器集群连接起来。为了将CARD与LADS等其他技术进行比较，我们还在源代码中实现了这些调度方案。

参数设置。鉴于所有参数都与第3.3节中解释的现实世界测量相关，它们可以在大多数情况下根据经验确定，这里由于空间有限省略了这些参数的微调实验。在这项研究中，乘法减少参数β设置为0.20，时间窗口δ设置为5 ms。同时，滞后持续时间参数λ等于时间窗口间隔δ的两倍，即10 ms。最大增量步长γ配置为30 K ops/sec，权重参数ϕ在这项研究中设置为0.90。通过实验，我们将α配置为0.00004，以便我们可以拥有一个50 ms长的平台区域。至于LADS的阈值，在这项研究中也设置为50 ms。请注意，如果这些高度可定制的参数在推荐范围内，CARD的拥塞感知属性并不敏感。如前所述，这些参数决定了速率适应程序，但所有可行的参数选择最终都会导致近似的拥塞感知特性。

基准测试。为了研究CARD在极重负载下的性能，我们使用Mimesis命名空间生成器和MimesisBench [2]生成命名空间和工作负载。MimesisBench是一个适用于大数据工作负载的元数据密集型存储基准测试。它由一个工作负载生成软件和来自Yahoo大数据集群的工作负载组成。与NNbench [32]不同，MimesisBench基于一个新颖的模型，允许它生成类型感知的工作负载。在这项研究中，我们专注于只读工作负载，这对许多数据驱动的应用程序（如大规模分布式机器学习训练）而言是典型的。此外，MimesisBench的到达间隔缩放因子设置为1，以重现来自目标应用程序的真实泊松到达。所有实验都在冷缓存条件下进行。此外，我们根据Yahoo研究人员发布的HDFS性能测量结果，将我们的性能基线配置为126.10 K ops/sec。所有读文件操作执行单个块位置查找，以评估元数据管理层的纯性能。

4.2 结果与分析

速率控制和速率适应。我们使用4台服务器进行了一系列实验，以评估CARD的性能。我们记录了每个客户端到每个服务器的发送速率和接收速率，以验证CARD的拥塞感知速率控制机制的正确性。工作负载量设置为1,048,576（即2^20），以便我们能够观察到足够长时间的速率变化。图5给出了三种速率适应过程的示例。请注意，这些示例是随机选择的，并且在图中标注了客户端-服务器对的信息。由于有不止一个客户端向每个服务器发送请求，我们可以轻松观察到图5中客户端的接收速率随着时间的推移而变化。然而，每个发送速率曲线都紧密地跟随接收速率曲线，无论接收速率曲线走向何方。这意味着客户端能够迅速而准确地对服务器拥塞状况的变化做出反应，尤其是当它察觉到自己的发送速率超过了服务器的接收速率时。

系统稳定性和负载平衡。为了与之前的工作进行比较，我们也在RMSC中实现并评估了其他调度方案，包括广泛采用的轮询调度方案、LADS以及一种倾向于选择响应时间移动平均值较低的服务器的常规启发式调度方案（记为MART）。所有结果显示在表1和表2中，其中我们使用调度经过时间与总经过时间之间的差距来量化和表示服务器的过载情况作为参考。换句话说，这个差距越小，服务器的过载情况就越轻。毕竟，这个差距表明服务器当前的处理能力不能及时处理所有客户端发送的请求，直到客户端等待了很长时间。

从表1中，我们可以轻松观察到CARD在同质RMSC中的性能优于MART和LADS。与这两种策略相比，调度经过时间与总经过时间之间的差距分别减少了96.30%和82.92%。然而，与轮询调度方案相比，CARD在一开始确实牺牲了RMSC的一部分利用率。由于轮询调度方案对集群环境不敏感，因此在同质RMSC中每个服务器的总到达率被省略，由于空间限制未显示。但结果与异质RMSC中的大致相同，如图6(d)所示。从图6(a)中，我们可以观察到使用MART的RMSC遭受负载振荡，因为集群中的服务器首先被优先选择，然后间歇性地被回避。这种情况的另一个原因是，由于滞后效应，MART的值不能很好地代表服务器的拥塞状况。这种现象也发生在使用LADS的RMSC中。毕竟，LADS的基于阈值的节流机制也是基于响应时间的移动平均值。当工作负载开始时，LADS的性能相当于轮询。当响应时间的移动平均值超过阈值后，LADS在某种程度上相当于MART，这可以从图6(b)中观察到。

在不同调度方案的同构和异构RMSC中，每个服务器的总体到达率。(a)-(c)分别显示了具有MART、LADS和CARD的同质RMSC中每个服务器的总体到达率。对于(d)-(f)，它们分别显示了具有Round-Robin、LADS和CARD的异构RMSC中每个服务器的总体到达率。

至于CARD，它在解决同质RMSC中的负载振荡方面表现出极高的性能，如图6(c)所示。然而，由于速率适应过程有一个50毫秒的平台区域，并且所有客户端都从一开始就谨慎地增加他们的发送速率，CARD无法在一开始就充分利用服务器的容量。为了缓解这个缺陷，将平台区域改为更短的时间是一个可选项，但这样做可能会损害拥塞感知特性，这意味着这里需要考虑一个权衡。尽管如此，这个缺点可以通过配置合理的初始速率来抵消，或者在实际生产环境中的持续工作负载下被淡化。

异质RMSC中的实验结果显示在表2中。请注意，服务器1的容量设置为90%。对于服务器2和服务器3，它们分别是80%和70%。因此，这个异质RMSC的容量上限应该是单个满容量服务器的3.4倍，即428.74 K ops/sec。如表2所示，CARD明显优于其他调度方案。与轮询、MART和LADS相比，使用CARD的总经过时间分别减少了约13.34%、21.60%和8.46%。并且，与轮询、MART和LADS相比，CARD的差距减少了98.64%、98.94%和98.36%。这主要是因为轮询和MART是不知道拥塞的调度方案，而LADS对服务器的容量和拥塞状况不适应或不敏感。在图6(d)中，结果暗示轮询没有能力意识到拥塞和异质配置。因此，它只是将负载平均分配给所有服务器。至于LADS，我们可以在图6(e)中观察到一个有趣的现象。服务器3是第一个被标记为拥塞的服务器。所有本应发送到服务器3的请求根据轮询调度被分配到服务器0。然后服务器2和服务器0随后饱和，请求大多数转向服务器1。最终，服务器的负载转移进入一个循环，这被描述为负载振荡。如图6(f)所示，CARD在异质集群中防止负载振荡和拥塞感知方面表现出高效能。每个服务器的总到达率仅略微围绕其容量波动。尽管CARD在同质RMSC中因为一开始的速率控制而没有超过轮询调度方案，但它确实证明了在环境异质或可变时的优越性。

整体吞吐量和可扩展性。我们进行了一系列实验，使用多达8台服务器（包括一个主MDS和7个副本）来研究使用不同调度方案时的系统可扩展性。工作负载量设置为2^32，以连续压力测试服务器较长时间。为了减少随机性的影响，我们每个实验运行5次。所有结果是5次运行的平均值，如图7和图8所示。

在同质集群中，轮询和CARD管理帮助系统实现接近理想的性能扩展，当集群中所有服务器都可用时，如图7所示。与轮询相比，CARD为了更高的系统稳定性牺牲了一小部分性能。除此之外，与MART和LADS相比，CARD分别增加了系统整体吞吐量37.17%和2.93%。这主要是因为这些较低响应时间导向的技术针对未饱和工作负载，当系统相对饱和时，它们会遭受性能下降。

对于异质集群中的实验，副本的容量部分受限。为简单起见，服务器1的容量设置为90%。对于服务器2和服务器3，它们分别是80%和70%。最终，服务器7的容量设置为30%。因此，8台服务器集群的容量上限应该是单个满容量服务器的5.2倍。如图所示，CARD在异质RMSC中优于其他调度方案。与轮询、MART和LADS相比，这个8服务器集群使用CARD的整体系统吞吐量分别增加了94.39%、77.56%和43.74%。由于轮询和MART是不知道拥塞的调度方案，而LADS对异质配置和服务器的拥塞状况不适应或不敏感，它们无法充分利用整个系统的容量。此外，图8的结果还暗示，在异质配置下，当服务器数量为8时，使用轮询的系统遭受严重性能下降。对于轮询调度方案，它只是将负载平均分配给所有服务器，容量较高的服务器空闲，而容量较低的服务器严重过载。而且，当集群规模增长时，这种现象更加严重。因此，当服务器数量从4增加到8时，整个系统的吞吐量反而减少。与上述调度方案不同，CARD帮助系统在环境异质时实现更好的可扩展性，这得益于其适应性和拥塞感知特性。

5.讨论

在本节中，我们简要讨论了 CARD 的适用性和限制。我们提出的基于拷贝的拥塞感知负载均衡技术仅适用于拷贝实现。它建立在每个请求可以由集群中任何服务器处理的前提之上。因此，基于分区（如子树分区或哈希分区）的实现可能涉及键重新分布或键迁移而非键复制，不在本研究的范围之内。我们认为，在这种情况下，服务器端的负载均衡技术将更为合适。

理想情况下，CARD 将在客户端以去中心化的方式将请求从过载的服务器重定向到负载较轻的服务器，这是一种简单而有效的方法。然而，由于速率自适应程序在进入较快的增加模式之前开始离散运行，因此在启动阶段可能会有一些整体性能损失。为了减轻这个缺陷，为特定应用程序配置合理的初始速率是可选的。

CARD 的另一个局限性是，它无法在轻量级工作负载下改善服务质量（QoS）。CARD 专注于重负载的情况。如果整体负载很轻，那么没有任何一个服务器会过载，CARD 会退化为简单的轮询策略。对于这种轻负载的情况，我们认为一种启发式策略，即更倾向于具有更好 QoS 的服务器，可能比 CARD 更适合作为客户端解决方案。

6.结论

在本文中，我们介绍了复制元数据服务器集群中的负载震荡问题，在重负载下会降低系统的整体性能。然后，我们提出了一种名为拥塞感知请求分发（CARD）的方案，来解决这个问题。CARD 主要由一个速率控制机制驱动，该机制实现在客户端。CARD 的关键洞察是将请求从过载的服务器重定向到负载较轻的服务器，以最大限度地利用资源。通过全面的实验，我们证明了在针对性工作负载下，使用 CARD 的 RMSC 相比之前的实现具有更好的稳定性和可扩展性，特别是在异构环境中。

代码007普通

打赏 收藏 海报 链接