分布式云存储系统的负载均衡外文翻译资料

英语原文共 12 页，剩余内容已隐藏，支付完成后下载完整资料

分布式云存储系统的负载均衡

摘要 - 分布式文件系统是基于MapReduce编程的云计算应用程序的关键组成部分

范例。在这种文件系统中，节点同时提供计算和存储功能;一个文件被分割成多个

在不同节点中分配的块，使得MapReduce任务可以在节点上并行执行。但是，在云

计算环境，故障是规范，节点可以在系统中升级，替换和添加。文件也可以

动态创建，删除和附加。这导致分布式文件系统中的负载不平衡;也就是说，文件块不是

在节点之间尽可能均匀地分布。生产系统中新兴的分布式文件系统强烈依赖于a

中心节点进行块重新分配。这种依赖性在大规模，易发生故障的环境中显然是不足的，因为

中央负载均衡器被置于相当大的工作负载下，其与系统尺寸线性地缩放，并且可能因此成为

性能瓶颈和单点故障。在本文中，提出了一种完全分布的负载重新平衡算法来应对

与负载不平衡问题。我们的算法与生产系统和竞争中的集中方法进行比较

分布式解决方案。模拟结果表明我们的建议与现有的可比性

集中式方法，并且在负载不平衡因子，运动成本方面显着优于先前的分布式算法，

和算法开销。在Hadoop分布式文件系统中实现的建议的性能进一步研究

集群环境。

索引术语 - 负载平衡，分布式文件系统，云

1. 简介

云计算（简称云计算）是一个引人注目的技术。在云中，客户端可以动态分配他们的资源需求没有复杂的部署资源管理。关键使能技术云包括MapReduce编程范式[ 1 ]，分布式文件系统（例如，[ 2 ]，[ 3 ]），虚拟化（例如，[ 4 ]，[ 5 ] ]，等等。这些技术强调可扩展性，所以云（例如，[ 6 ]）可以大规模，包括实体可以任意失败和加入在保持系统可靠性的同时。分布式文件系统是云的关键构建块基于MapReduce编程计算中的应用范式.在这样的文件系统中，节点同时服务计算和存储功能；文件被分区在不同节点分配的若干块中MapReduce任务可以并行执行的节点。例如，考虑一个执行程序计算不同单词的数量和频率在一个大文件中的每个唯一单词。在这样的应用程序云将文件转换成大量的脱节和固定大小的块（或文件块），并分配给不同的云存储节点（即chunkservers）。每个存储节点（简称节点），然后计算通过扫描和分析的每一个独特的字的频率本地文件块。在这样的分布式文件系统中，节点的负载是通常与文件块的数目成比例拥有[ 3 ]。因为云中的文件可以任意创建，删除和附加，节点可以升级，替换和添加在文件系统[ 7 ]，文件块不尽可能均匀分布节点。存储节点之间的负载平衡是一个关键云函数。在负载平衡的云中，资源可以很好的利用和配置，最大限度地基于MapReduce的应用程序的性能。国家的最先进的分布式文件系统（如谷歌的GFS[ 2 ]和[ 3 ]）在Hadoop HDFS云依赖中心节点管理文件系统的元数据信息基于该元数据平衡存储节点的负载。集中式的方法简化了设计和实现分布式文件系统。然而，最近的经验（例如，[ 8 ]）的结论是，当数量存储节点，文件的数量和数量访问文件的线性增加，中央节点（例如，在谷歌的GFS Master）成为性能瓶颈，为他们无法容纳大量的文件由于客户和MapReduce应用程序访问。因此，取决于中心节点来解决负载不平衡问题加剧他们的重负荷。即使有最新的开发在分布式文件系统中，中心节点仍可能超载。例如，HDFS联合[9]建议具有多个命名的结构（即，管理元数据信息的节点）。其文件系统命名空间被静态和手动分区为anamenode数。但是，随着工作量的增加通过namenode可能随时间而改变和no自适应工作负载整合和/或迁移方案提供平衡负载在任何namenodesnamenode可能成为性能瓶颈。在本文中，我们有兴趣研究负载分布式文件系统中的重新平衡问题适用于大规模，动态和数据密集型云。 （术语“重新平衡”和“平衡”在此可以互换纸）。这样的大规模云有数百或数千的节点（并且将来可能达到数万）。我们的目标是统一分配文件的大块在节点之间尽可能地使得没有节点管理过多的块。此外，我们的目标减少网络流量（或移动成本）造成的尽可能重新平衡节点的负载最大化可用的网络带宽正常应用程序。此外，由于失败是规范，节点是新增加以维持整体系统性能[2][3]，导致节点的异质性。利用能提高系统性能的节点是，因此，要求。具体来说，在这项研究中，我们建议卸载负载通过拥有存储，将任务重新平衡到存储节点节点自发平衡其负载。这消除了对中心节点的依赖。存储节点结构化为基于分布式哈希表的网络（DHT），例如[10]，[11]，[12];发现文件块可以简单地参考DHT中的快速键查找，假设a唯一句柄（或标识符）被分配给每个文件块。DHT使节点能够自组织和修复在节点动态中不断提供查找功能，简化系统的提供和管理。

总之，我们的贡献有三个方面：

1gt;. 通过利用DHTs，我们提出负载重新平衡算法用于均匀分布文件块并尽可能减少运动成本尽可能多。特别是，我们提出的算法以分布式方式操作节点独立地执行它们的负载均衡任务没有同步或全局信息关于系统。

2gt;. 基于DHT的负载均衡算法被广泛研究（例如，[13]，[14]，[15]，[16]

[17]，[18]，[19]，[20]，[21]，[22]）。但是，大多数现有解决方案的设计没有考虑

运动成本和节点异质性可能引入显着的维护网络交通到DHT。相反，我们的建议不是只利用物理网络位置重新分配文件块以减少移动成本，而且利用有能力的节点来改进整体系统性能。此外，我们的算法降低了算法开销到DHTs尽可能。

3gt;. 我们的建议是通过计算机模拟进行评估。仿真结果表明，虽然每个节点执行我们的负载重新平衡算法独立地没有获取全局信息，我们的建议与集中式可比性方法在Hadoop HDFS [3]和显着胜过竞争分布式算法在[14]中就负载不平衡因素，运动成本和算法开销。此外，我们的负载均衡算法展现出快速收敛率。我们推导出分析模型来验证效率和有效性。此外，我们实现了我们的负载均衡算法在HDFS中调查其性能集群环境。

本文的其余部分组织如下：负载重新平衡问题在第2节中正式规定。我们的负载平衡算法在第3节中给出通过计算机模拟评估我们的建议讨论第4节中的仿真结果。在第5节中，我们的建议的性能进一步调查在集群环境。我们的研究总结在第6节。由于空间限制，我们推迟了广泛的讨论的相关作品在附录中，可以在上找到计算机社会数字图书馆在

http：// doiieeecomputersociety.org/10.1109/TPDS.2012.196。

1. 负载重新平衡问题

我们考虑一个大规模分布式文件系统的一组chunkservers V在云中，其中的基数V是jV j = n。通常，n可以是1,000,10,000或更多。在系统中，有多个文件存储在n中chunkservers。首先，让我们将文件集表示为F.文件f 2 F被分割成多个不相连的固定大小由Cf表示的块。例如，每个块具有相同的大小，64 Mbytes，在Hadoop HDFS [3]。二， chunkserver的负载正比于数量由服务器托管的块[3]。第三，节点故障是这种分布式系统中的规范，以及chunkserver可以在系统中升级，替换和添加。最后，F中的文件可以任意创建，删除，并附加。净效果导致文件块不是均匀分布到块服务器。图。 1示出了负载重新平衡问题的示例假设chunkservers是同构的并具有相同的容量。我们目前的研究目标是设计一个负载重新平衡算法重新分配文件块，使得块可以均匀地分布到系统可能同时降低运动成本可能。这里，移动成本被定义为数字的块被迁移以平衡块服务器的负载。让A是任何的理想的块数chunkserver i 2 V需要在系统范围内管理负载平衡状态，即，

1. (b) (c) (d)

Fig.1. 示例说明了负载重新平衡问题，其中（a）六个文件f1，f2，f3，f4，f5和f6的块的初始分布在三个节点N1，N2和N3，（b）文件f2和f5被删除，（c）f6被附加，（d）节点N4连接。 （b），（c）和（d）中的节点处于负载不平衡状态。

然后，我们的负载重新平衡算法旨在最小化每个chunkserver i中的负载不平衡因子如下：

其中Li表示节点i的负载（即，文件的数目）由i）托管的块和||*||表示绝对值功能。注意“chunkservers”和“nodes”是在本文中可互换。

定理1.负载重新平衡问题是NP-hard。

证明：通过限制，一个决定版本的实例负载重新平衡问题是背包问题[23]。也就是说，考虑任何节点i 2 V。我试图存储a子集中的文件块在F中的个数由i托管的块不大于A，并且“值”的托管的块至少是？，这被定义为运动成本之和的倒数迁移的块。 。

为了简化讨论，我们首先假设均匀环境，其中迁移文件块任何两个节点之间需要一个单位移动成本和每个块服务器具有相同的存储容量。然而，我们稍后会处理实际考虑基于节点容量异质性和运动成本物理网络局部性的块迁移。

1. 方案
   1. 架构

我们的提案中的chunkserver被组织为DHT网络; 也就是说，每个chunkserver实现DHT协议如Chord [10]或Pastry [11]。 一个文件中系统被分割成多个固定大小的块，和“每个”块具有唯一的块句柄（或块）标识符）以全局已知的散列函数命名作为SHA1 [24]。 散列函数返回唯一标识符对于给定文件的路径名字符串和块索引。 对于例如，文件的第一和第三块的标识符“/user/tom/tmp/a.log”分别是SHA1（/user / tom / tmp / a.log，0）和SHA1（/ user / tom /tmp / a.log，2）。 每个chunkserver也有一个唯一的ID。我们在V中表示chunkserver的ID通过 ；简而言之，将n个chunkserver表示为1, 2, 3hellip;.n。 除非另有明确说明，我们表示chunkserver i的后继者作为chunkserver ithorn;1和chunkserver的后继n作为chunkserver 1.在一个典型的DHT，chunkserver i托管其句柄的文件块在(内，除了chunkserver n，它管理文件块(。

为了发现文件块，DHT查找操作执行。 在大多数DHT中，平均节点数访问查找是 [10]，[11]如果每个chunkserver i维护个邻居，即节点, k = 0; 1,2,hellip;., 。在个邻居中，一个是是i的继承者。 用l查找文件块，l查找。

在我们的建议中使用DHT的原因如下：

1gt;. chunkserver自我配置和自我修复在我们的提案，因为他们的到来，离开，和故障，简化系统配置和管理。具体来说，典型的DHTs保证如果一个节点离开，那么它的本地托管的块可靠地迁移到其继承人;如果节点加入，那么它立即分配其ID的块在加入节点之前从其后继到管理。我们的建议很大程度上取决于节点到达和离开操作迁移文件节点之间的块。感兴趣的读者参考至[10]，[11]关于自我管理的细节技术在DHTs。

2gt;.通过访问，查找需要适度的延迟节点在典型的DHT中，查找延迟可以减少因为发现的1个块文件可以并行执行。 另一方面，我们的建议独立于DHT协议。为了进一步减少查找延迟，我们可以采用最先进的DHT，如亚马逊的Dynamo [12]提供一跳查找延迟。

3gt;. DHT网络对元数据是透明的管理。 而DHT网络指定块的位置，我们的提议可以与现有的大规模分布式集成文件系统，例如Google GFS [2]和Hadoop HDFS [3]，其中集中了一个主节点管理文件系统的命名空间和将文件块映射到存储节点。 特别，以将我们的建议与主节点结合GFS，每个chunkserver周期性地搭载它本地托管的块信息给主机心跳消息[2]，使主人可以收集系统中块的位置。

4gt;.在DHT中，如果指定了节点和文件块具有统一的ID，节点的最大负载保证是的的平均值在概率下[14]，[16]，[25]，从而平衡节点的负载在一定程度上。 但是，我们的第3.2节中提出的建议执行得很好ID的均匀分布和不均匀分布节点和文件块由于任意文件创建/删除和节点到达/离开。

正如所讨论的，负载重新平衡问题定义在第2节是NP-hard（定理1），这是技术上具有挑战性，因此需要进行深入研究。 正交诸如元数据管理，文件一致性等问题模型和复制策略超出了我们的范围需要进行研究和独立研究。

• 1. 负载均衡算法
     1. 综述

大规模分布式文件系统处于负载平衡状态状态，如果每个chunkserver主机不超过A块。在我们提出的算法，每个chunkserver节点i估计它是否欠载（轻载）或过载（重）没有全局信息。节点是轻载如果它主机的块数小于阈值，（其中0le;Llt;1）。相比之下，过载节点管理大于的块的数量，（其中0le;lt;1）而且Delta;U是系统参数。在以下讨论，如果节点i离开并重新加入作为另一个节点j的后继，则我们将节点i表示为节点，节点j的原始后继

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[139232]，资料为PDF文档或Word文档，PDF文档可免费转换为Word