NCCloud:多云存储设备下存储修复的网络编码
Yuchong Hu, Henry C. H. Chen, Patrick P. C. Lee, Yang Tang
摘要：近年来的研究提出通过条带化地将数据存放在多个云存储设备上使云存储拥有容错能力。如果一个云存储设备发生永久性故障并且丢失了其存储的全部数据，我们需要利用剩余存活的云存储设备来修复失效的数据来保证存储数据的完备性。针对多云存储设备存储，我们提出一个称为NCCloud的基于代理的系统，旨在完成存储系统中单节点永久故障的高效恢复过程。NCCloud系统是基于一种被称为再生码的网络编码存储机制实现的。特别的是，我们设计实现了一种F-MSR再生码，它在维护和保证相同水平的数据冗余和传统擦除码存储要求的前提下，可以使用更少的资源。我们搭建了用于概念验证的NCCloud原型系统，并将其部署在本地和商业云上。通过实验证明F-MSR纠删码的存储效率要优于传统的RAID-6纠删码，且两种纠删码在完成一般云存储操作时有相近的响应时间表现。
1 介绍
云存储系统提供了一个基于需求的远程备份解决方案。然而，由于使用单一的云存储平台容易出现单点故障等问题，一个合理的解决方案是将数据分段地存放在不同的云存储设备上。虽然常用纠删码系统中的分段数据在一些云存储节点出现短期或可预见的永久性故障时仍可以保持良好的数据可用性，但实际中的使用情况表明，存储设备永久性故障的发生并不总是可预见的。
本文主要针对云存储设备中不可预见的故障进行研究。当一个云存储设备发生永久故障时，系统需要启动存储修复流程以维持数据冗余的水平。修复操作将会从剩余存活的云存储设备上读取数据，然后在一个新的云存储设备上重构恢复出丢失的数据。考虑到成本因素，在恢复数据和迁移数据时，需要尽可能地减少使用的数据量。
目前相关的研究基于分布式存储系统提出了再生码技术。再生码是建立在网络编码概念上一种编码技术。它们的主要原理是通过智能地混合现有存储节点上所存放的数据块，然后在一个新的存储节点再生恢复数据。有研究表明，在保证同样的容错能力下再生码相比于传统的纠删码会占用更少的数据修复流量。尽管有良好的性能，再生码在目前仍处于理论背景研究阶段。关于再生码的在真实应用环境中的众多实用性能仍存在不确定性，尤其是再生码编码产生的开销。
在本文中，我们为多云存储环境设计了一个基于代理的存储系统，即NCCloud存储系统。我们针对最小存储再生码（F-MSR）提出了第一个可实施的设计方案，尤为重要的是，我们解决了在现有的理论研究中关于存储节点编码操作过程的需要。我们的F-MSR编码在保证双容错能力的前提下，具有与传统RAID-6纠删码编码方案相同的存储代价，但在恢复单点故障时F-MSR编码会使用更少的修复开销。另一方面，不同于大多数纠删码编码是系统性的（原数据块会被保留），F-MSR编码是非系统的，它只线性地存储联合编码块。虽然如此，F-MSR仍然适合于读操作较少而且数据长期保存的归档系统。
实际部署测试中，F-MSR码在四云节点存储的环境下相较于RAID-6码节省了25%的数据修复开销，并且随着云节点数量的增加可上升到50%。另外，我们在本地云和商业云的设置上进行了大量的实验评估。实验结果表明我们的F-MSR实现过程只增加了一个较小的编码开销，这个开销与互联网中文件传输时间相比几乎可以忽略。因此，我们的工作验证了通过NCCloud实现的F-MSR编码的实际可用性，也会促进再生码在大规模部署中的更加深入的研究。
2 F-MSR的意义
当我们从客户端的角度来分析分布式多云的存储配置时，可以把它看作是我们条带化地将数据分段存放在多个云存储设备上。我们提出了一个基于代理的设计来内部互连多个云存储库，如图1（a）所示。代理服务器充当客户端应用程序和云存储设备之间的接口。如果云存储设备出现永久性故障，代理服务器将会启动恢复操作，如图(b)所示。在数据修复过程中，代理服务器从存活云存储设备上读取必要的数据块重构出新的数据块，并将新的数据块写到一个新的云存储设备上。值得注意的是，这个修复操作不会涉及到云存储设备之间的正常直接互动。
图 1：多云存储中基于代理的设计：(a)正常操作，(b)云节点1出错时的修复操作。
我们分析了基于最大距离可分（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）。然后，在新的节点上重建和存储丢失的块。当修复流量是M时，总的存储容量是2M。
现在我们考虑在基于代理的设置中实现双容错的F-MSR，如图2 所示。F-MSR将文件划分为四个原始块，并且通过原始块不同的线性组合形成P1到P8的八个不同编码块。作为原始块的每一个代码块具有相同的大小，即M/4。任意两个节点可以用来恢复初始的四个原始块。假设节点1故障。代理从每个幸存节点收集一个代码块，每次下载大小为M/4的三个代码块。则代理由三个代码块的不同线性组合重新生成两个代码块P1和P2。注意，P1和P2仍是原始块的线性组合。然后代理将P1和P2写到新节点。在F-MSR中，存储大小是2M，但是修复流量是0.75M，节省了25%的开销。
对F-MSR的n个存储节点进行概括，我们把大小为M的文件分配到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是可接受的长期存档应用，其读频率通常较低。另外，为了恢复备份，是很自然检索整个文件，而不是一个特定块。
本文考虑实现使用Reed-Solomon码的基线RAID-6编码。它的修复方法是重建整个文件，并普遍适用于所有纠删码。最近的研究表明数据读取开销可以通过使用异或纠删码来被最小化。例如，在RAID-6中，相比重建整个文件，数据读取被减少了25%。虽然这种方法不是很理想（在RAID-6中，F-MSR可以节省的50%的修复流量），但对异或纠删码的有效使用仍然具有重要的意义。
图 2：在RAID-6（n=4）和F-MSR（k=2）中数据修复实例
主要参考了 少年颜子 的译文：http://blog.csdn.net/guotianlaile/article/details/51397582
这里只进行了部分内容的翻译，少年颜子 的翻译博文相较来说更加完整。膜拜大神！！！