NCCloud: Applying Network Coding for the Storage Repair in a Cloud-of-Clouds

多云平台下存储修复的网络编码技术

  摘要：为云存储提供容错，最近的研究提出分段数据跨多个云供应商。不管怎样，如果一个云平台遭受永久性故障并且失去了所有的数据，我们需要从其他幸存的云平台中修复丢失的数据来保证数据的完备性，我们为多云存储提出一个基于代理的系统称为NCCloud，目的在于高效益的修复一个永久的云错误的修复。NCCloud是建立在被称为再生码的基于网络编码的存储模式，特别的，我们建议设计实现F-MSR，它维护同样水平的数据冗余和传统擦除码的存储要求，并且使用了更少的资源。我们实现了一个概念验证NCCloud原型,并将其部署在本地和商业云。我们验证的成本效益FMSR存储修复在raid – 6，在正常的云存储操作下展示了两种模式有类似的响应时间性能。

1.介绍：

云存储提供了一个随需应变的远程备份解决方案。然而，使用，例如具有单点故障和厂商锁定插件的使用单一的云存储供应商引起了关注。建议一个合理的解决方案是将分段数据放在不同的云供应商。

一些云平台出现短期或可预见的永久性故障时虽然传统的擦除数据分段码表现良好，现实情况表明,永久性故障的发生并不总是可预见的。

这项工作集中在云意想不到的错误，当一个云永久出错，激活存储修复，以保持数据冗余的水平是很重要的。修复操作读取幸存的云平台现有数据并且在新的云平台重构丢失的数据。考虑到成本，由于数据迁移，需要减少修复分支。

最近的研究提出了分布式存储再生码，再生码是建立在网络编码的概念。他们的目标是智能地混合存储在现有存储节点的数据块，然后在一个新的存储节点再生数据。它表明，在同样的容错级别下再生代码减少数据修复流量优于传统的擦除码。尽管有良好的性能，再生码主要研究的是理论背景。它关于再生码的实用性能仍存在不确定性，特别是在再生码产生的编码开销。

在本文中，我们推荐使用网络编码云平台，基于代理的系统设计为多云存储。我们为最小的存储再生码提出第一个实施的设计功能，尤为重要的是，我们消除在现有的理论存储节点中进行编码需要的操作研究。我们的F-MSR是实现保持双容错并在具有相同的存储成本的基础上的RAID-6传统擦除编码方案，并且在恢复单云错误时时使用较少的修复分支。另一方面，与大多数系统的擦除编码模式不同。F-MSR是不系统的，只存储线性联合代码块。然而，F-MSR适合少读且长期的存档应用。

 我们表明，在实际的部署设置中，在四云环境的设置下，F-MSR与raid-6相比节省了维修成本的25%，并且随着云数量的增加可上升到50%。另外，我们在本地云和商业云的设置上进行了广泛的评估。

我们证明了我们的F-MSR实现只增加了一个小的编码开销，可以很容易的通过在因特网上的文件传输时间掩蔽。因此，我们的工作证实F-MSR通过NCCloud的实用性，激励实现再生码在大规模部署的进一步研究。

2.F-MSR的动机

   从客户的角度来看我们认可分布式多云存储设置，例如，我们分拆数据给多个云供应商。我们提出了一个基于代理的设计互连多种云资源库，如图A，代理充当客户端应用程序和云之间的接口。如果云遇到永久性故障，代理激活修复操作，如图(b)所示。也就是说，

图1：为多重云存储提供基于代理的设计：(a)正常操作，(b)云编码出错时的修复操作..在修复过程中，代理为新的云平台重新生成数据。代理从其他幸存的云中读取基本的数据块，重建新的数据片，并把他们写到新的云平台。值得注意的是，此修复操作不涉及云之间的直接互动。

我们认为，容错存储基于最大距离可分离（MDS）码.给定文件对象，在一个未编码系统中，我们将其分成大小相等的原始块，将被存储在k个云平台。原始块是通过线性组合形成的代码块进行编码。原始块和编码块被分布在n>k个云平台上。当使用MDS编码时，原始文件对象可以重建包含在n个云中任意k的块。因此，它容忍任何n- k的云出错。我们称之为MDS的性能特征。F-MSR的特殊特征是，重建单一的原始块或代码块可以通过从存活云层中读高达50％数据来实现，数据量少于重建整个文件。

本文考虑的多云的设置，是双容错（例如，RAID-6），在至多两个云故障时保证提供数据的可用性（例如，中断了几天）。也就是说，我们设k=n-2.我们希望在实践中达到这样的容错级别就足够了。

在云数据迁移时，考虑到一个永久性故障不频繁但又是可能出现的，我们的主要目的是为永久单云故障减少存储维修的成本。

我们定义修复流量为出站的数据量在单云故障恢复中正在被其他幸存的云读。我们的目标是为了有效的成本修复尽量减少维修流量。在这里（数据被写入云时），我们不考虑入站流量。因为在许多云计算供应商中它是免费的（第五部分表一）。

 现在我们通过一个例子来展示F-MSR是如何保存修复流量的。假设我们在四个云上存储大小为M的文件，每一个被视为逻辑存储节点。我们首先考虑双容错raid – 6。

我们认为RAID-6的实施基于Reed-Solomon码，如图2所示。我们把文件分成大小为M /2的两个原始块（即A和B）。我们增加了通过原始块的线性组合形成的两个代码块。现在假设节点1停机

则代理必须下载相同数目的块从其他两个节点作为原始文件（如B何A+B的节点2和3）。然后，在新的节点上重建和存储丢失的块。当修复流量是1 M时，总存储容量是2M。

     现在我们考虑在基于代理的设置中实现双容错的F-MSR，如图2 所示。F-MSR将文件划分为四个原始块，并且通过原始块不同的线性组合形成八个不同的编码块P1，···，P8。作为原始块的每一个代码块具有相同的大小（M/ 4）。任意两个节点可以用来恢复初始的四个原始块。假设节点1故障。

代理从每个幸存节点收集一个代码块，每次下载大小为M/4的三个代码块。则代理由三个代码块的不同线性组合重新生成两个代码块P1和P2。注意，P1和P2仍是原始块的线性组合。然后代理将P1和P2写到新节点。在F-MSR中，存储大小是2 M，但是修复流量是0.75M，节省了25%。

对F-MSR的n个存储节点进行概括，我们把大小为1M的文件分配到2（N- 2）个原生块中，并生成4（n-2）个代码块。然后每个节点将存储两个大小为M/[2（n-2）]代码块。所以，总的存储大小为

Mn/(n-2). 要修复出现故障的节点，我们从N-1个结点中的每一个下载一个块，所以修复流量是M（n-1）/[2（n-2）]。相比之下，对于RAID-6来说，总的存储大小也是Mn/(n-2)，然而他的修复流量是M。当N足够大时，F-MSR可以节省的修复流量接近50%。

需要注意的是F-MSR只保留代码块，而不是原始块。要访问某文件的单个块，我们需要为特定块下载和解码整个文件。然而，F-MSR是可接受的长期存档应用，其读频率通常较低。另外，为了恢复备份，是很自然检索整个文件，而不是一个特定块。

   本文认为实现基线的RAID-6使用了Reed-Solomon码。它的修复方法是重建整个文件，并普遍适用于所有纠删码。最近的研究表明读数据可以通过基于异或的纠错码专门被最小化。例如，在RAID-6中，

相比重建整个文件，数据读取被减少了25％。虽然这种方法是不理想的（前面，在RAID-6中，F-MSR可以节省的50％的修复流量），异或操作的有效使用有很大的意义。

图2：在RAID-6（n=4）he F-MSR（k=2）中修复操作的例子

  3. F-MSR的实现

   在这一部分，我们提出了实现F-MSR的系统方法。我们在特定的文件对象上指定F-MSR的三个操作：（1）文件上传；（2）文件下载；（3）文件修复。与我们先前的理论研究实现的一个关键区别是我们不要求存储节点具有编码能力。所以我们的实现可以与今天的云存储兼容。设计问题的另一个关键是，

不是通过简单地随机线性组合生成代码块，即使经过反复修复，我们还要保证生成的线性组合总能满足MDS性能，以确保数据的可用性。在此，我们实现F-MSR作为MDS的代码一般记作(n,k)。我们假设每个云库都有对应的逻辑存储节点。

3.1文件上传

  上传一个文件F，首先我们把它分为K（N -  k）个大小相等的原始块，记为(Pi)i=1,2,···,n(n−k).。每个Pi由k (k×n)个原始块的线性组合形成。特别的，我们让EM = [αi,j]作为n(n−k)×k(n−k)编码矩阵的系数aij(i = 1, .. . , n(n−k) andj = 1, . . . , k(n−k)), 在伽罗瓦域GF. 我们称EM的行向量为编码系数向量（ECV），其中包含K（N - k）个元素。我们让ECVi表示EM的第i行向量。我们通过ECVi的标量积和原始块矢量（Fi）i.e.,Pi= Pk j=1 (n−k) αijFj fori = 1, 2, · ·· , n(n − k),计算Pi，其中，在GF（28）中执行所有算术运算。代码块均匀地存储在n个节点，每个节点具有（n-  k）个代码块。我们存储整个EM的元数据对象随后被复制到所有存储节点（第四部分）。构建EM有多种方式，只要它满足MDS属性和修复MDS属性（3.3）。需要注意的在伽罗瓦域算术运算的执行细节中进行了广泛的讨论。

3.2文件下载

下载一个文件，我们先下载一个包含ECVs的相应的元数据对象。然后我们选择n个存储节点中的任意k个，并从K个节点下载K(K-N)个代码块。在ECVs的K(N-K)的代码块能形成AK(N-K)×K(N-K)方阵。如果MDS属性保持不变，则顾名思义正方形矩阵的逆矩阵必须存在。因此，乘以方阵的代码块的倒数，并获得原始K（N -  k）的原生块. 想法是我们把F-MSR作为标准Reed-Solomon码，已经在本教程中介绍了我们创造的技术，就是用逆矩阵对原始数据进行解码。

3.3迭代的修复

我们现在考虑为一个文件F使用F-MSR进行永久性的单节点故障修复，考虑到F-MSR在每次修复中要重新生成不同的块，挑战之一是确保即使在反复修复后MDS性能仍然成立。相对于在RAID-6中确定丢失块的再生，保证了存储块的不变性。在此，我们提出一个探索式的两阶段检查如下。假设第（r- 1）次修复成功，我们现在考虑如何操作R次来修复单节点的永久故障（其中ř≥1）。在R次修复后我们首先在所有的存储节点检查满足MDS属性的新数据块。另外，我们还检查在（R +1）次修复后在所有存储节点中是否有满足MDS属性的另外的新块，另外一个永久性的节点发生故障时（我们称之为修复MDS属性），我们现在描述r次维修如下。

第一步：从幸存节点下载编码矩阵。编码矩阵EM规定了ECVS通过本地块的线性组合构建的所有代码块。我们为两阶段检查启发式使用ecvs。因为我们在被复制的元数据对象中嵌入EM，简单地我们可以从幸存的一个节点下载元数据对象。

第二步：从n- 1个幸存的节点中随机选择一个ECV。值得注意的是，在EM的每个 ECV和一个代码块相对应。我们从上述个n- 1存留节点中随机挑选一个ECV。我们将这些ECVS记为ECVi1,ECVi2, · · ·,ECVin−1。

第三步：生成一个修复矩阵。我们构建一个(n −k)×(n−1)维的修复矩阵RM = [γi,j],，每一个元素γi,j

（i = 1, .. . , n−k and j = 1, .. . , n−1）是随机的从GF(28)选取的。需要注意的是为随机矩阵产生一致的可靠性存储。

第四步：为新的代码块计算ECVS，并生成一个新的编码矩阵。我们使用在第二步中得到的ECVs计算RM构建新的n-k歌ECVS，记为ECV0 i = Pn j=1 −1 γi,jECVij fori = 1, 2, · ·· , n − k.。然后产生新的编码矩阵，记作EM，由EM的行向量i^TH  ={ECVi，i为幸存节点；ECVi，i是新节点}。

第五步；根据EM，检查MDS和修复MDS性能是否都令人满意。直观地，我们通过列举所有的K个节点的子集（N，K）验证MDS属性，来看是否其每个相应的编码矩阵都能形成全秩。为了修复MDS属性，我们检查所有失败的节点（从n个节点中），我们可以从其他n-1个存活的节点中收集任意n-k个数据块，并且重建新节点的数据块，通过这样来修复MDS属性。执行修复MDS属性的数量至多是

n(n-k)^n-1(n,k).如果n 很小，那么枚举MDS和维修MDS属性的复杂性是可控的。如果任何一个阶段失败

然后我们返回第二步重新执行。我们强调在步骤1到5只处理ECVS，所以它们的开销不依赖于块大小。

第六步：下载实际的数据块，然后重新生成新的数据块。如果两阶段检测在第五步成功了，然后我们要从网络编码云中n-1个幸存的存储节点中下载，在步骤2ECVS中选中的n-1个数据块。并且在步骤四中使用新计算的ECVs，我们重新生成新的数据块，并将其上传到NCCloud生成新节点。

注意：我们断言，除了检查MDS属性，在迭代修复中检查修复MDS属性也是必不可少的。我们模拟检测MDS修复属性可以进行可持续的迭代修复。在模拟中，对于永久的节点故障在多层循环中对应不同的n值。特别的，在每一层循环，我们随机选择一个永久故障的节点，并触发修复它。如果是重复了10次步骤2到步骤5的循环就说明无法修复。我们观察到，如果没有检查修复MDS属性，我们看到了一个糟糕但速度非常快的修复，对于n=8和n=2分别不超过7层和2层循环，另一方面，检测修复MDS属性对不同的n值，使得迭代修复可持续数百次循环，并且我们还没有在广泛的模拟下发现任何修复不好的。

4 网络编码云的设计与实现

我们实施NCCloud作为桥接用户应用程序和多个云平台的代理。，它是通过三层来设计实现的，

在文件系统层NCCloud作为安装驱动器，因此它可以很容易地与普通用户的应用程序连接。编码层处理编码和解码的功能。存储层处理不同云的读/写请求交易。

每个文件与元数据对象相关联，它被复制到每个库。元数据对象包含文件详细信息和编码信息。（例如：F-MSR的编码表）。

NCCloud主要用Python实现，然而存储模式如果用C实现更高效。文件系统主要建立在FUSE（用户空间文件系统）。在RAID-6 和F-MSR中实现编码层， RAID-6建立在zfec上（zfec是一种前向纠删码,用于给原始数据增加冗余信息,以提高数据的安全性。zfec提供了诸如c、python等语言的接口。），并且我们的F-MSR在zfec上做一个公平比较的实现模拟优化。

F-MSR生成多个数据块被存储在同一个存储库。为了节省请求开销（见表一），上传前多个块去往同一仓库聚集。因此，F-MSR的每个文件对象在每个云中只有一个块被保存，如RAID-6。要检索特定块，我们计算合并块内的偏移，并发出了一系列GET请求。

5 评估

    我们使用NCCloud原型来评价基于Reed-Solomon的编码以及基于多云存储的F-MSR编码。在这里我们设置n=4，k=2.我们假设n=4 个云盘时能满足实际配置需求。在此背景下，当不超过两块云盘损坏时，我们进行数据恢复。

    我们的实验的目的是探讨使用F-MSR在多个云存储的实用性。我们的评估包括两个部分。首先比较使用raid-6和F-MSR在当前云供应商的价格成本，我们也经验评估NCCloud原型在本地云及商业云上的响应时间性能。

5.1成本分析

    表1列出了三大主流供应商在2011年9月的价格/月。对于Amazon S3,我们从第一个收费层（如storage）使用在1 tb /月;传输数据超过1 gb /月但不到10 tb /月)。

    从第二部分的分析,当n = 4时，我们可以节省25%的下载流量在存储修复。在raid - 6和F-MSR(假设总块F-MSR如第四节所述)条件下，每个文件对象生成的块的存储大小及数量都是相同的。然而,在分析中,我们忽略了两个实际问题:元数据的大小(第四节)以及恢复期间发出的请求数。我们现在讨论,他们可以忽略不计,而且仅基于文件大小的简化计算满足实际的应用程序。

    元数据大小:目前我们的实现使F-MSR元数据大小在160 b,不管文件大小。NCCloud旨在长期备份(见第二节),并且可以与其他备份应用程序集成。现有的备份应用程序(如[27],[11])通常将很多小文件合并成一个较大的数据块，为了节省处理开销。例如,积云[27]默认设置创建块4 mb左右的。因此元数据大小是通常可以忽略不计。

    请求数:从表1,我们可以看到,一些云供应商现在对请求数的收费政策。raid - 6和F-MSR在数据恢复期间，检索数据的请求数是不同的。假设我们存储文件大小4 mb且n = 4 k = 2。在修复期间,raid - 6和F-MSR分别检索2和3块(参见图2)。由于GET请求raid - 6最多0.427%,F-MSR最多是0.854%,所以总成本仅仅增长0.427%.

5.2响应时间分析

    我们在真实的环境中部署NCCloud原型。然后在两个场景下评估不同的操作的响应时间性能。第一部分详细分析不同NCCloud操作的时间,而且是在本地云存储上进行，为了减少网络波动的影响。第二部分评估NCCloud在商业云中的实际表现如何。所有的结果平均超过40分。

5.2.1 本地云存储

    在本地云的实验是在基于OpenStack Swift1.4.2[21]的面向对象的存储平台进行。NCCloud被安装在一台配置为Intel Xeon E5620和16 gb的RAM的机器上。这台机器连接到一个OpenStack Swift平台，平台连接着多个存储服务器,每个服务器配置为英特尔酷睿i5 - 2400和8 gb RAM。我们在swift平台上创建(n + 1)= 5的容器,所以每个容器类似于云存储库(其中一个是备用节点用于修复)。

    在这个实验中,我们测试NCCloud在三个基本操作下的响应时间:(一)文件上传;(b)文件下载;(c)修复。我们使用8个随机生成的文件作为数据集，每个文件大小从1 mb到500 mb不等。我们选择存储库的一个不存在的位置路径来模拟一个节点故障修复。注意,raid- 6的修复有两种类型,取决于失败节点包含一个本地块或者一个代码块。

    图3显示了所有三个操作的响应时间(95%置信区间绘制),图4显示了在处理500 mb的文件五个关键成分的响应时间。图3显示了raid - 6在文件上传和下载时具有更少的响应时间。在图4的帮助下,我们发现F-MSR的时间开销远大于 raid - 6。由于拥有相同的MDS性能、raid - 6和F-MSR上传/下载期间表现出类似的数据传输时间。然而,FMSR比raid - 6有一个明显多的编码/解码的开销。当上传500 mb的文件,raid - 6花了 1.490s去编码而F-MSR需要5.365s;当下载一个500 mb的文件,raid - 6的本地块不需要解码,但F-MSR解码需要2.594秒。

    另一方面,F-MSR在维修期间的响应时间略低。F-MSR的主要优势是,在修复期间，它只需要下载少量的数据。修复一个500 mb的文件,F-MSR下载时间花3.887秒,而raid - 6在本地块修复花4.832秒。

    尽管在本地云环境中，raid - 6相比F-MSR通常响应时间更短,但我们预计F-MSR的编码/解码开销可以很容易地掩饰了网络在互联网上的波动,下边就对此进行了说明。

5.2.2 商业云

    以下实验是在Intel Xeon E5530和16 gb的RAM的64位Ubuntu 9.10操作系统上进行的。我们在Windows Azure存储上随机生成4个从1 mb到10 mb的文件，重复5.2.1节中的三个操作。在Azure,我们创建(n + 1)= 5容器来模拟不同的云存储库。对raid - 6和F-MSR交错运行的相同的操作可以减少网络波动在一天的不同时间的影响。图5显示了不同文件大小在95%置信区间的结果。注意,尽管在这个实验中我们只使用Azure,实际使用的NCCloud应该根据在不同的供应商和位置处理条纹数据，以更好的可用性保证。

    从图5中,我们没有看到raid - 6和F-MSR操作有明显的响应时间差异。此外,在同一台机器上,对于一个10 mb文件，F-MSR需要约0.150s来编码，0.064s解码(数据未显示)。这些构成了大约3%的总上传和下载时间(分别为4.962s和2.240s)。在95%的置信区间上，上传和下载时间分别为0.550秒和0.438秒,网络波动对响应时间影响很大。总的来说,我们证明F-MSR相比raid - 6，没有显著超过我们的性能开销底线。

6 相关工作

    有几个文章都提出了多云存储。冰雹[5]提供了存储数据的完整性和可用性保证。DEPSKY[4]强调Byzantine容错，结合存储数据的加密和纠删码。拉克斯[1]使用擦除编码以减少切换云供应商时造成的锁定。它从云中获取即将失败的数据,并将数据转移到新的云。不像拉克斯,NCCloud排除了云修复失败。上面所有的系统都是基于纠删码,而NCCloud强调再生码的存储修复。

    再生码(见调查[9])利用最优存储成本和修复路线之间的权衡。现有的研究主要集中在理论分析。几项研究(如10、13、19)经验评估随机线性编码点对点存储。然而,他们的评估主要是基于模拟。NCFS[17]实现再生码,但不考虑MSR编码是基于线性组合。在这里,我们考虑了在多个云存储上F-MSR的实现，并进行了实验。

7 总结

    我们目前的NCCloud是一个多云存储文件系统，实际强调了今天的云存储的可靠性。NCCloud不仅实现容错存储,也允许云永久失败时有效低成本的修复。NCCloud实现了一个最低存储再生码(F-MSR)的实用版本,它能够在修复达到所需的数据冗余度时再生新的块。在成本和响应时间方面，我们的NCCloud原型显示FMSR访问数据的有效性。NCCloud的源代码可以在http://ansrlab.cse.cuhk.edu.hk/software/nccloud找到。

8 致谢

    我们要感谢我们的指导者,James Plank,以及匿名评论者的宝贵意见。这个工作是由香港大学的拨款委员会AoE/E-02/08资助。