利用联合局域性实现分布式存储中的宽条擦除编码（附代码）

利用联合局域性实现分布式存储中的宽条擦除编码（附带源码）

摘要：纠删码是分布式存储系统中一种低成本的冗余机制，通过存储条纹数据和奇偶校验块。宽条纹最近被提出来抑制奇偶校验块在条带中的比例，以达到极大的存储节省。然而，宽条纹加重了修复损失，而现有的纠删码方法不能有效地解决宽条纹问题。在本文中，我们提出了联合局部性，这是第一个通过奇偶局部性和拓扑局部性的结合来系统地解决宽条纹修复问题的机制。我们使用高效的编码和更新方案进一步增强组合局部性。在Amazon EC2上的实验表明，与基于局部性的最先进技术相比，基于组合局部将单块修复时间减少了90.5%，而冗余度仅为1.063倍。

1 引言

在现代分布式存储系统中，纠删码是一种低成本的冗余机制，用于保护数据存储免受故障的影响，特别是，ReedSolomon (RS)[61]码在当今的纠删码部署中被广泛采用 。在高层次上，对于一些可配置参数n和k(其中k < n)， RS码由n个块组成多个条带，包括k个原始未编码数据块和n - k个编码奇偶校验块，这样相同条带的n个块中的任何k都足以重建原始k个数据块(详细信息参见x2.1)。每条n块的条带分布在n个节点上，以容忍任何n−k个节点故障。RS码的最小冗余度为n kx(即，在允许任何n - k个节点故障的情况下，没有其他纠删码的冗余度比RS码低。相比之下，传统的复制需要(n−k+1)×的冗余来容忍相同数量的任意n−k个节点故障。例如，Facebook f4[47]使用(14;10)RS码来容忍任意四个节点的故障，冗余为1.4×，而复制需要5×的冗余来实现相同的四节点容错。适当参数化(n;k)，纠删码可以将冗余限制在最多1.5倍(见表1)。

传统观点认为，纠删码参数应在一个中等范围内配置。表1列出了参数(n;K)最先进的生产系统所使用的。我们看到可容忍的失败次数n - k是通常为3或4个，而条带大小n不超过20。选择适当的条带大小的一个主要原因是限制擦除编码的修复惩罚，其中修复任何单个丢失的块需要检索相同条带的多个可用块来解码丢失的块(例如，k块在(n;k) RS编码)。更大的条带大小n和更大的k来容忍相同的n - k节点故障，意味着更严重的带宽和I/O放大的修复，从而降低存储的可靠性。

虽然纠删码有效地减轻了存储冗余，但我们探索在纠删码下进一步减少冗余以实现最大的存储节省;例如，冗余减少14%(从1.5倍减少到1.33倍)可以转化为数百万美元的生产节约[52]。这促使我们探索宽条纹，其中n和k非常大，而在最先进的生产系统中，可容忍的故障数n - k仍然是3到4。

宽条纹在存储行业(例如，VAST[9])中进行了研究，并提供了一个以最大可能的存储节省实现接近最优冗余(即n k接近1)的机会。例如，VAST[9]考虑设置(n;K) =(154;150)，因此只产生1:027倍的冗余。我们认为，宽条纹的显著存储效率是有吸引力的冷和热分布式存储系统。纠删码传统上用于冷存储系统(如备份和归档应用程序)，其中数据需要持久存储，但很少被访问[2,10,12]。宽条纹允许冷库系统以极低的成本实现长期的数据耐久性。

热存储系统也采用纠删码内存中的键值存储(in memory key-value stores)，为面对故障和掉线者时频繁访问的键值对象提供数据可用性。宽条纹允许热存储系统显著减少昂贵的硬件占用(例如，用于内存中的键值存储的DRAM)。

虽然宽条纹实现了极大的存储节省，但它们进一步加剧了修复代价，因为修复带宽(即修复期间的数据传输量)随着k的增加而增加。许多现有的用于擦除编码存储的高效修复方法利用局域性来减少修复带宽。有两种类型的局域性:(i)奇偶局域性，它引入额外的本地奇偶块，以减少可用于修复丢失块的可用块的数量;(ii)拓扑局部性，它考虑到系统拓扑的分层性质，并执行局部修复操作以减轻跨机架(或跨集群)修复带宽。

然而，现有的基于位置的修复方法仍然主要集中在k较小的条纹上(例如，k = 12和k = 6)。随着k的增加(x2.3)，它们不可避免地会增加冗余或降低宽条纹的修复性能。原因是宽条纹近乎最优的冗余降低了奇偶locality或拓扑locality带来的好处(x3.5)。

本文提出了一种组合局域性修复机制，系统地结合了奇偶局域性和拓扑局域性来解决宽条擦除编码中的修复问题。组合局部性将本地奇偶校验块与一小部分数据块(即，奇偶校验局部性)相关联，并将修复操作定位在有限数量的机架中(即，拓扑局部性)，从而在冗余和修复性能之间提供比现有的基于局部性的最先进状态更好的权衡。此外，我们还回顾了组合局域下宽带擦除编码的经典编码和更新问题，并设计了相应的高效方案。我们的贡献包括：

• 我们是第一个系统地解决宽条纹修复问题。我们提出了组合局部性，减轻了超低存储冗余下的跨机架修复带宽。我们研究了不同基于位置的方案(x3)的冗余和跨机架修复带宽之间的权衡。

• 我们设计了ECWide，它实现了组合局域性来解决两种类型的修复:单块修复和全节点修复。我们还设计了(i)一个有效的编码方案，允许宽条纹的奇偶校验块在多个节点上并行编码，以及(ii)一个机架内部奇偶校验更新方案，允许奇偶校验块在机架内本地更新，以减少跨机架传输(x4)。

• 我们实现了两个ECWide原型，即ECWide- c和ECWide- h，以实现组合局部性。前者是为冷存储而设计的，而后者是基于memcached的内存键值存储[5,6]热存储(x5)。我们的原型的源代码现在可以在https://github.com/yuchonghu/ecwide上获得。

• 我们通过Amazon EC2实验将ECWide-C和ECWide-H与两种现有的基于位置的方案进行比较:(i)生产中采用的Azure的本地重建代码(Azure- lrc)，以及(ii)最近提出的基于拓扑位置的修复方法，该方法最大限度地减少了跨机架修复带宽，以实现快速修复。

  我们发现，结合局域性可以显著减少单块修复时间，分别比上述两种方案减少高达87.9%和90.5%，而产生的冗余仅为1:063×。我们还验证了编码和更新方案的效率(x6)。

2 研究背景和动机

我们提供了分布式存储(x2.1)的擦除编码的背景细节，并说明了部署宽条纹擦除编码(x2.2)的挑战。我们描述了现有的研究如何利用局部性来解决修复问题(x2.3)，并激发了我们组合局部性设计的想法(x2.4)。

2.1 分布式存储的纠删码

考虑一个分布式存储系统，它将数据组织成跨越多个存储节点的固定大小的块，这样擦除编码就以块为单位进行操作。根据存储工作负载的类型，用于擦除编码的块大小可能会有很大差异，从内存中的键值存储(即热存储)中的小到4KiB，到持久文件存储(即冷存储)中的大到256 MiB，用于较小的I/O寻道成本。Erasure编码可以有不同的构造形式，其中RS码是最流行的Erasure码，被广泛使用(x1)。

为了在分布式存储中部署RS码，我们配置了两个整数参数n和k(其中k < n)。k) RS码的工作原理是将k个固定大小(未编码)的数据块编码为n−k个相同大小的(编码)奇偶校验块。RS码是存储最优的(在编码理论术语中称为最大距离可分离(MDS))，这意味着n个块中的任何k都足以重建所有k个数据块(即，任何n - k个丢失的块都可以容忍数据可用性)，而冗余(即原始数据大小的n/k倍)是所有可能的擦除码结构中最小的。我们称n块的每一组为条带。分布式存储系统包含多个独立编码的分条，每个分条的n个数据块存储在n个不同的节点中，以提供任意n−k个节点故障的容错能力。

数学上，每个奇偶校验块在一个(n;k) RS码由相同条带的k个数据块根据w位字(其中n≤2w)的伽罗瓦场GF(2w)算法线性组合而成[53]，其中D1、D2、···、Dk为条带的k个数据块，P1、P2、···、Pn−k为同一条带的n−k个校验块。每一个奇偶校验块Pi(1≤i≤n−k)可以表示为，其中aij表示某个编码系数。在这项工作中，我们专注于柯西RS码[15,55]，其中编码系数是基于柯西矩阵定义的，因此我们可以构建系统的RS码(即，k个数据块包含在条带中以供直接访问)。

2.2 宽条纠删码的挑战

我们探索了大n和大k的宽条纹擦除编码，从而实现了超低冗余n/k(即接近1)。然而，它带来了三个性能挑战。

**昂贵的维修：**众所周知，擦除编码会导致修复损失，对于宽条纹来说，这种损失甚至更严重。对于一个 (n;k) RS代码，修复单个丢失的块的传统方法是从其他非故障节点检索k个可用块，这意味着带宽和I/O成本被放大k倍。尽管新的擦除码结构可以减轻修复带宽和I/O成本(例如，再生代码或局部可修复代码)，但理论分析证明，随着k的增加，修复带宽和I/O放大仍然存在，并且变得更加突出。

宽条纹的高修复代价在冷存储和热存储工作负载中表现不同。对于大块的冷存储工作负载，修复带宽对于大k的影响更为显著，例如，如果我们配置k = 128的宽条带，块大小为256 MiB，则单块修复带宽为32 GiB。我们可以插值，(14,10)RS码的每日修复带宽为180 TiB，当k = 128时将增加到2.25 PiB。对于具有小块大小的热存储工作负载，尽管其单块修复带宽远小于冷存储，但在频繁访问下，大k会导致显著的尾部延迟，因为修复现在更有可能被k个非故障节点中的任何离散节点阻塞。

**昂贵的编码：**随着k的增加，擦除编码的(每条)编码开销变得更加突出(解码也是如此)。在一个(n;k) RS码，每个奇偶校验块是k个数据块(x2.1)的线性组合，因此计算开销随k线性增加。最重要的是，随着k的增加，编码过程将宽条的输入数据拟合到CPU缓存中变得更加困难，导致编码性能显著下降。图1显示了使用Intel ISA-L编码api时，三个Intel CPU系列与k的编码吞吐量对比。这里，我们将块大小固定为64 MiB, n - k = 4。我们看到，从k = 4到k = 16，编码吞吐量仍然很高，但从k = 32开始，随着k进一步增加，吞吐量急剧下降。例如，从k = 4到k = 128，吞吐量下降了43-70%。

**昂贵的更新：**擦除编码的(每条)更新开销是显著的，如果同一条的任何数据块被更新，所有n−k奇偶校验块都需要更新。宽条纹与中等大小的传统条纹一样，也面临着昂贵的更新问题。

2.3 纠删码修复中的局部性

宽条擦除编码的主要挑战是修复问题。现有的关于擦除编码修复问题的研究已经产生了大量的文献，其中许多文献都侧重于利用局部性来减少修复带宽，包括奇偶局部性和拓扑局部性。

**奇偶校验码：**回想一下一个(n;k)RS代码需要检索k个块来修复丢失的块。奇偶校验局域性增加了本地奇偶校验块，以减少修复丢失块的幸存块的数量(从而减少修复带宽和I/O)。其典型的纠删码结构是局部可修复码(lrc)。以Azure的Local Reconstruction Codes (Azure- lrc)为例。给定三个可配置参数n, k和r(其中r < k < n)， 一个(n;k;r) Azure-LRC将包含r个数据块的每个本地组(最后一个组除外，它的数据块可能少于r个)编码为一个本地奇偶校验块，因此修复丢失的块现在只访问r个幸存的块(r < k)。它还包含从所有数据块编码的全局奇偶校验块。Azure-LRC满足最大可收回属性，可以容忍任意节点故障。

图2(a)显示了(32;20;2)Azure-LRC[34]。它有20个数据块(用D1;D2,……，D20表示)。它有10个本地校验块，其中第个本地校验块是数据块Di,Di+1,……,Dj的线性组合。它还有两个全局奇偶校验块Q1[1-20]和Q2[1-20]，每个块都是所有20个数据块的线性组合。所有上述32个块都放置在32个节点中，以容忍任何三个节点的故障。因此，(32;20;2)AzureLRC的单块修复带宽为两个块(例如，修复D1需要访问D2和P1[1-2])，同时产生1.6倍的冗余。相比之下，(23;20)RS代码也有20个数据块，可以容忍任何三个节点的故障。其单块修复带宽为20块，冗余度仅为1.15倍。简而言之，奇偶定位减少了修复带宽，但产生了高冗余。

**拓扑局部性：**现有的擦除编码存储系统(包括Azure-LRC)将条带的每个块放在驻留在不同机架中的不同节点中。提供对相同数量的节点故障和机架故障的容忍度，但是修复需要大量的跨机架带宽，这通常比机架内带宽受限得多。

最近的研究利用拓扑局部性，以降低机架级容错性为代价，通过在机架内定位修复操作来减少跨机架修复带宽。它们将条带的块存储在机架内的多个节点中，并将修复操作拆分为机架内和跨机架修复子操作。可以证明，在最小冗余条件下，跨机架修复带宽是最小的。一些类似的研究侧重于通过集群内修复子操作最小化跨集群修复带宽。我们定义一个拓扑局部性方案为(n;k;z) TL，其中(n;k) rs编码的块放置在z个机架(或集群)中。

图2(b)显示了(23;20;8)TL，它将20个数据块和3个rs编码的奇偶校验块放置在8个机架中的23个节点中，以便容忍任何3个节点故障和1个机架故障。(23;20;8) TL的最小冗余为1.15倍，但要传输7个跨机架块来修复丢失的块。例如，修复D1需要从其他机架检索Q1[1-20]和6个块，这些块是Q1[120]的线性部分，通过消去线性部分D2和D3，可以从Q1[1-20]求解D1。单块修复带宽高于(32;20;2)Azure-LRC(即两个块)。简而言之，拓扑局部性实现了最小的冗余，但产生了很高的跨机架修复带宽。

2.4 激励的例子

对于较大k的宽条纹，奇偶局部性(高冗余)和拓扑局部性(高修复惩罚)都不能有效地平衡冗余和修复惩罚之间的权衡。这促使我们将两种类型的局域结合起来，以获得更好的权衡，从而使宽条纹实际适用。

图2©显示了这个想法。我们通过(26;20;5)Azure-LRC将20个数据块编码为26个数据块。我们将数据块放置在9个机架上，并用(26;20;5;9)CL表示该方案(参见x3.1的定义)。在这种情况下，修复丢失的块D1可以通过从P1中消去D2、D3、D4、D5来解决。单块修复带宽仅为一个跨机架块，小于(32;20;2)Azure-LRC(2块)和(23;20;8)TL(7块)。同时，冗余为1.3倍，比(32;20;2)AzureLRC (1.6倍)更接近最小冗余。

3 局部结合

在本节中，我们提出了组合局部性，它利用奇偶局部性和拓扑局部性的结合来减少受冗余限制的跨机架修复带宽，用于宽条擦除编码。我们提供了定义并陈述了我们的设计目标(x3.1)，并展示了我们的组合局域化设计思想(x3.2)。我们分析并选择了适合组合局部性(x3.3)的LRC结构。我们介绍了组合局部性机制(x3.4)的细节，并分析了它在冗余和跨机架修复带宽(x3.5)之间的权衡。最后，我们给出了组合局部性(x3.6)的可靠性分析。表2总结了这些符号。

符号	描述
n	条带的块总数
k	分条的数据块个数
r	修复丢失的块所检索的块的数目
z	用于存储条带的机架数
c	机架中条带的块数
f	单个分条允许的节点故障个数
$ \gamma $	最大允许冗余

3.1 设计目标

我们将组合局部性机制定义为(n;k;r;z) CL，由(n;k;r) Azure-LRC和(n;k;z)跨z个机架的TL(注意，我们在x3.3中证明了选择Azure-LRC的合理性)组成。

组合局部性机制的主要目标是确定参数(n;k;r;z)，最大限度地减少跨机架修复带宽，取决于:(i)可容忍的节点故障数量(表示为f)和(ii)最大允许冗余(表示为g)。对于宽条擦除编码，我们考虑大k(例如，k = 128)对于表1所示的典型容错水平(例如，f = 4)。

在这里，我们确保驻留在每个机架上的条带的最大块数(用c表示)不能大于条带的可容忍节点故障数f;否则，机架故障可能导致数据丢失。因此，我们要求：$ c \leqslant f $

每个前z−1个机架存储一个条带的c个块，最后一个机架存储剩余的n−c(z−1)(≤c)个块

我们专注于优化两种类型的修复操作：单块修复和全节点修复(x4.1)。这两种修复操作都假设每个失效条恰好有一个失效块，就像大多数先前的研究一样，包括奇偶和拓扑。对于具有多个失败块的失败条纹，我们采用传统的修复方法，检索k个可用块以重建RS代码中的所有失败块。

3.2 设计理念

为了实现组合局域性的目标，我们从图2中观察到，组合局域性通过下载r−1个数据块加上一个本地奇偶校验块来修复一个数据块(即修复带宽为r块)。由于联合局部性将r个块中的一部分放在相同的机架中，因此可以对每个机架中的块进行局部修复，从而减少跨机架修复带宽。直观地说，如果c增加(即一个条带中的更多块可以驻留在一个机架中)，则本地修复可以包含更多块，从而进一步减少跨机架修复带宽。因此，我们的目标是找到最大可能的c。回想一下，c≤f(式(1))。如果c = f，则跨机架修复带宽可以最小化。

因此，(n;k;r;z)CL是为了保证c = f。然而，(n;k;r) LRCs的不同结构提供了不同级别的容错f，因此，我们的想法是选择具有最高容错性的适当LRC结构。

3.3 LRC的选择

我们考虑中讨论的四个代表性LRC：

• **Azure-LRC：**它以每个本地组r个数据块的线性组合计算一个本地奇偶校验块，并通过RS码计算全局奇偶校验块。注意，修复一个全局奇偶校验块需要检索k个块。
• **Xorbas：**它与Azure-LRC的不同之处在于，它允许每个全局奇偶校验块最多可被r个块修复，其中可能包括其他全局奇偶校验块和本地奇偶校验块。
• **Optimal-LRC：**它将所有数据块和全局校验块划分为大小为r的本地组，并为每个本地组添加一个本地校验，以允许最多r个块修复任何丢失的块。
• **Azure-LRC+1：**它建立在Azure-LRC的基础上，为所有全局奇偶校验块添加了一个新的本地奇偶校验块，允许本地修复任何丢失的全局奇偶校验块。

表3显示了实际设置(n;k;r) =(16;10;5)下可容忍的节点故障数f。注意，Xorbas和Optimal-LRC给出了f的上界，但事实上，某些参数的上界是不可达的，包括(n;K;r) =(16;10;5)。从表3可以看出，相同(n;k;r)下，Azure-LRC的f最大，因此对于组合局部性，可以选择合适的LRC。

Azure-LRC实现最高容错性的原因是它既没有引入线性依赖于全局奇偶校验块的额外本地奇偶校验块(例如，Optimal-LRC和Azure-LRC+1)，也没有使全局奇偶校验块线性依赖于本地奇偶校验块(例如，Xorbas)。事实上，对于给定的冗余级别，添加线性依赖并不能提高容错性。

请注意，Azure-LRC需要下载k个块来修复一个全局奇偶校验块，这在修复存储多个全局奇偶校验块的故障节点时可能效率低下。然而，我们认为全局奇偶校验块的数量只占大k宽条纹的一小部分。例如，在包含三个全局校验块的(128;120;24)Azure-LRC中，每个节点存储的块中只有3/128 = 2.34%是全局校验块。此外，通过拓扑局部性可以显著降低单个全局奇偶校验块的跨机架修复带宽。在我们接下来的讨论中，除非另有说明，我们将重点关注数据块或本地奇偶校验块的单块修复。

3.4组合的(n;k; r; z) CL

我们提供(n;k;r;z) CL如下。这里，我们关注的是一个条带，它有k个数据块，具有固定数量的可容忍节点故障f，服从最大允许冗余。构造包括两个步骤:(i)找到(n;k;r) Azure-LRC的参数，(ii)将所有n个块放置在z个机架上进行本地修复操作。

步骤一：

考虑到(n;k;r) Azure-LRC，表3表明:

由于，我们有

我们可以得到满足式(3)的r的最小值，用rmin表示。r表示单块修复带宽(x3.2)， rmin表示最小单块修复带宽。

步骤二：

在此基础上，我们进一步减小了交叉修复带宽。首先，我们可以从式(2)和rmin得到n的值。接下来，我们将这n个块放置在驻留在z个机架中的n个节点上，如下所示。对于每个本地组，我们将r +1个块(注意这里的r = rmin)，包括r个数据块和相应的本地奇偶校验块，放入(r +1)=c个不同的机架中(为了讨论的简单性，我们假设r +1可以被c整除，以便在机架之间具有块的对称分布)。因此，对于机架中任何丢失的块，我们可以在(r +1)/c个机架上执行局部修复，使得跨机架修复带宽为(r +1)/c−1个，其中(r +1)/c−1表示从其他(r +1)/c−1个机架收集的块。通过设置c = f使跨机架修复带宽最小(x3.2)，则最小跨机架修复带宽为(r +1)/f−1块。

图2©显示了k = 20, f = 3时的(26;20;5;9)CL。每个包含r +1 = 6个块的本地组(其中r = rmin = 5)存储在(r +1)/ f = 2个机架中。跨机架修复带宽仅为一个块(即(r +1)/f−1 = 1)。

3.5 权衡分析

组合局部性的每一组参数(n;k;r;z)根据x3.4的结果产生相应的冗余和跨机架修复带宽值集合。我们还可以用k和f推导出Azure-LRC和拓扑局域性的值。对于Azure-LRC，我们通过公式(2)获得其冗余，并且跨机架修复带宽为r块(假设每个块存储在不同的机架中)。对于拓扑局部性，我们得到其冗余服从f = n−k和跨机架修复带宽为机架数减1(以块为单位)(即)(图2(b))。表4列出了Azure-LRC、拓扑局部性和组合局部性的冗余和跨机架修复带宽，分别表示为(n;k;r) Azure-LRC、(n;k;z) TL和(n;k;r;z) CL。

图3绘制了k = 128和f = 2;3;4在最大允许冗余的情况下表4的结果。对于宽条纹，我们将k设置为足够大的值，并将f设置为最先进的值(表1)。我们将设置为接近1，以便在宽条纹下实现最大的存储节省。

图3中的每个点都代表了一组特定参数的冗余和跨机架修复带宽之间的权衡。注意，拓扑局部性有三个点代表f各自的的三个值;相比之下，Azure-LRC和组合局域性对于f的三个各自的值有三条曲线，因为它们有一个额外的参数r，使得对于不同的r值，每条曲线上都有不同的点。对于最小的交叉机架修复带宽，我们只绘制满足r = rmin的点。

通过奇偶性和拓扑局部性的结合，在冗余和跨机架修复带宽之间的权衡方面，组合局部性优于Azure-LRC和拓扑局部性。以f = 4为例。对于拓扑局部性，(132;128;33)TL的最小冗余为1:03 . 31×，但其跨机架修复带宽达到32块，即使许多机架执行本地修复操作。(140;128;15) Azure-LRC通过奇偶性极大地减少了跨机架修复带宽到r = 15块，但其冗余(1:09 . 94×)并没有接近最小值。原因是Azure-LRC的冗余度∝(1/r)，而它的跨机架修复带宽∝r(表4)，所以对于较小的跨机架修复带宽，r应该较小，代价是产生更高的冗余度。相比之下，对于组合局域性，(136;128;27;34)CL不仅具有更接近最小冗余(即1:06 . 63×)，而且还进一步显着降低了跨机架修复带宽，最多为(r +1)= f−1 = 6块(我们在x3.6中展示了更精确的计算)，与Azure-LRC相比减少了60%。原因是组合局部性的跨机架修复带宽∝(r= f)(表4)，因此在有限冗余下具有较低的跨机架修复带宽。

3.6 可靠性分析

我们像之前的研究一样，通过马尔可夫建模来分析平均数据丢失时间(MTTDL)指标[19,26,32,34,63,67]。我们用f = 4比较了6种不同的编码:(i) (16;12) RS， (ii) (16;12;6) Azure-LRC， (iii) (132;128) RS， (iv) (132;128;33) TL， (v) (140;128;15) Azure-LRC和(vi) (136;128;27;34) CL。前两种码为中条纹码，后四种码为宽条纹码。

图4显示了(136;128;27;34)CL;其他代码的建模也类似。每个状态表示一个分条的可用节点数。例如，状态136表示所有节点都正常，而状态131表示数据丢失。为了简化分析，我们做了两个假设。首先，我们假设只要存在5个故障节点就会发生数据丢失，但实际上5个故障节点的某些组合仍然是可修复的(例如，5个本地奇偶校验块的丢失)。因此，(136;128;27;34)CL的信度被低估了；我们在模拟Azure-LRC时也做了类似的处理。其次，我们只关注独立节点的故障，而没有考虑多个节点同时故障的机架故障(例如停电[19])。我们的理由是节点故障比机架故障更常见。我们计划在今后的工作中放宽这些假设。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-HVwdb3Py-1686295601234)(C:\Users\hp\AppData\Roaming\Typora\typora-user-images\image-20230605100128510.png)]

我们的可靠性建模遵循了先前的工作。设$\lambda$为每个节点的故障率。因此，从状态i到状态i−1(其中132≤i≤136)的状态转移率为i$\lambda$，因为状态i中的i个节点中的任何一个都独立失效。为了对修复进行建模，设$\mu$为故障节点从状态135到状态136的修复率，${\mu }^{\prime }$为每个节点从状态i到状态i+1的修复率(其中132≤i≤134)。我们假设单节点故障的修复时间与修复流量成正比。设N为存储系统中节点的总数，S为每个节点的容量，B为每个节点的网络带宽，$\epsilon$为每个节点由于速率限制而可用于修复的网络带宽占比。当单个节点故障时，修复负载均匀分布在剩余的N−1个节点上，可用修复网络带宽为$\epsilon$(N−1)B。因此，我们有$\mu$=$\epsilon$(N−1)B/(CS)，其中C是单节点修复成本(推导如下)。如果有多个节点故障，我们设${\mu }^{\prime }$= 1/T，其中T表示检测到多个节点故障并触发多节点修复的时间，假设多节点修复优先于单节点修复。

(n,k,r,z)CL

我们计算C为平均跨机架修复带宽。以(136;128;27;34)CL为例。存在$\lceil \frac{k}{r}\rceil$= 5个本地组，其中前4个本地组(各为r+1 = 28个块)跨越7个机架(即跨机架修复带宽为6个块)，而最后一个本地组(有21个块)跨越6个机架(即，跨机架修复带宽为5个块)。对于剩余的n−k−$\lceil \frac{k}{r}\rceil$ = 3个全局奇偶校验块(驻留在一个机架中)，我们通过访问其他z−1 = 33个机架来修复它们中的每一个，每个机架发送一个从拓扑局部性的机架内部修复子操作计算的跨机架块。因此，我们有C = (6×112+5×21+33×3)/136 = 6.44块。

我们按如下方式配置默认参数。我们设置N = 400, S = 16 TB, $\epsilon$= 0.1, T = 30分钟。我们还设置了平均故障间隔时间1/$\lambda$= 4年，B =1Gb/s。我们显示了变化$\lambda$(表5)和变化B(表6)的MTTDL结果。

我们看到(136;128;27;34)CL具有比(16;12)RS和(16;12;6)Azure-LRC更低的MTTDL，但对于宽条纹，通过最小化单节点修复的交叉修复带宽，实现了比其他基于位置的方案更高的MTTDL。例如，当B = 1 Gb/s, 1/$\lambda$= 4时，(136;128;27;34)CL的MTTDL增益为(132;128;33)TL的10.90倍， (132;128;33) TL的2.92倍， (140;128;15) Azure-LRC的1.94倍。

通常，当1/$\lambda$增加或B减少时，组合局部性可以获得更高的MTTDL增益。前者意味着多节点故障的可能性更小，而后者意味着跨机架带宽更受约束。在任何一种情况下，最小化单节点修复的跨机架修复带宽对于获得高MTTDL增益至关重要。

4 设计

设计了一种实现组合局域化的宽条擦除编码存储系统ECWide。ECWide解决了在宽条纹擦除编码(x2.2)中实现高效修复、编码和更新的挑战，其目标如下：

• 最小跨机架修复带宽：ECWide通过组合局部性最小化跨机架修复带宽(x4.1)。
• 高效的编码：ECWide应用多节点编码，支持宽条纹(x4.2)的高效编码。
• 高效的编码：ECWide应用机架内部奇偶校验更新，允许全局和本地奇偶校验块主要在本地机架内更新(x4.3)。

4.1 修复

ECWide实现了单块修复和全节点修复两种修复操作的联合局部性。

**单块修复：**ECWide在修复中实现了两个步骤的组合局部化(x3.4)。考虑一个存储系统，它将给定k, f和$\gamma$的数据组织为固定大小的块。在步骤1中，ECWide通过公式(2)和(3)确定参数n和r。然后将k个数据块编码为n−k个本地/全局奇偶校验块。在步骤2中，ECWide为每个本地组选择(r +1)= f个机架，并将每个本地组的所有r +1个块均匀地放置在这些机架上的r +1个不同节点中(即每个机架f个块)。由于上述两个步骤确保了单块修复的跨机架修复带宽最小化为(r +1)/f−1块(x3.4)，因此ECWide只需要为修复操作提供以下详细信息。

图5描述了对机架R1中丢失的块D1的修复。具体来说，ECWide在R1中选择一个节点N1(称为请求者)来负责重建丢失的块。它还选择机架R2中的一个节点N4(称为本地修复器)来执行本地修复。然后N4收集R2内所有块D5和P1[1-5]，计算一个编码块P1[1-5]−D4−D5(为了简单起见，假设P1[1-5]是D1;D2……D5的xor和)，并将编码后的块发送给请求者N1。最后，N1收集R1内的数据块D2和D3，并通过从接收到的编码块P1[1-5]−D4−D5中消去D2和D3来求解D1。

全节点修复：

一个全节点修复可以看作是多个条带的多个单块修复(即，每个条带丢失一个块)，可以并行化。然而，每个单块修复涉及一个请求者和多个本地修复者，因此多个单块修复可能选择相同的节点作为请求者或本地修复者，从而使所选节点过载并降低整体全节点修复性能。因此，我们的目标是选择尽可能多的不同的节点作为请求者和本地修复者，以有效地并行处理多个单块修复。

为此，ECWide设计了一种最近最少选择的方法来选择节点作为请求者或本地修复者，并通过双链表和哈希映射实现。双链列表保存所有节点ID，以跟踪最近选择的节点或其他节点，而hashmap保存列表的节点ID和节点地址。然后，我们可以通过简单地选择列表的底部节点并在O(1)时间内通过hashmap更新列表，从而获得最近最少选择的节点作为请求者或本地修复者。

4.2 编码

回顾x2.2，宽条纹的单节点编码导致大k的显著性能下降。我们观察到，当前的编码实现(例如，Intel ISA-L[4]和QFS[49])经常将大尺寸的数据块(例如，64 MiB)分割成较小尺寸的数据片，并在硬件加速(例如，Intel ISA-L)或并行性(例如，QFS)下执行基于片的编码。为了编码一组k个数据片，这些数据片是k个数据块的一部分，编码节点的CPU缓存从k个数据块中的每个数据块中预取连续的片。如果k很大，CPU缓存可能无法容纳所有预取的片，从而降低后续片的编码性能。

为了克服单节点编码的局限性，我们考虑了一种多节点编码方案，旨在实现宽条纹的高编码吞吐量。其思想是将k大的单节点编码操作划分为多个k小的跨不同节点的编码子操作。这是由三个观察结果驱动的:(i)具有较小k(例如，k = 16)的条纹的编码性能很快(x2.2中的图1);(ii)奇偶校验块是数据块的线性组合(x2.1)，因此一个奇偶校验块可以由k个数据块的不同子集的多个部分编码块组合而成;(iii)同一机架内节点之间的带宽往往是充裕的。

图6描述了k = 64的多节点编码方案，假设要生成两个全局奇偶校验块Q1[1-64]和Q2[1-64]。ECWide首先将所有64个数据块均匀分布在同一机架的N1、N2、N3和N4四个节点上。它允许每个节点(例如N1)将其16个本地数据块(例如D1;D2,……,D16)编码为两个部分编码的块(例如Q1[1-16]和Q2[1-16])。第一个节点N1向下一个节点N2发送Q1[1-16]和Q2[1-16]。N2结合了两个接收到的部分编码块与其本地部分编码块Q1[17-32]和Q2[17-32]组成两个新的部分编码块Q1[1-32]和Q2[1-32]，发送给下一个节点N3。在N3和N4中执行类似操作。最后，N4生成最终的全局奇偶校验块Q1[1-64]和Q2[1-64]。请注意，部分编码的块是并行编码的，并通过快速的机架内链路从N1转发到N4，以便有效地计算宽条纹的全局奇偶校验块。

ECWide需要在联合局部性下生成本地奇偶校验块，但由于r通常比k小得多，因此单个节点中每个本地组的r个数据块可以更有效地编码本地奇偶校验块。此外，ECWide需要将所有数据块、本地奇偶校验块和全局奇偶校验块分发到不同的机架上。这种分布导致跨机架数据传输;最大限度地减少宽条纹编码的跨机架数据传输是我们未来的工作。

4.3 更新

为了减轻宽条纹(x2.2)中昂贵的奇偶更新开销，我们提出了一种宽条纹的机架内奇偶更新方案。它的思想是在同一个机架内尽可能地限制全局和本地奇偶更新，从而减少跨机架的数据传输。

图7(a)描述了如何对两个全局奇偶校验块Q1[1-20]和Q2[1-20]执行机架内奇偶校验更新(也显示在图2©中)。ECWide将所有全局奇偶校验块Q1[1-20]和Q2[1-20]放在同一个机架中，考虑到c = f且全局奇偶校验块的数量通常不超过f，这在不违反机架级容忍度的情况下总是可行的。在这种情况下，当数据块D1更新到D1‘时，ECWide首先在机架上为全局块Q1[1-20] (x2.1)传输增量块D1’−D1。对Q1[1-20]进行更新，增加$\alpha (D{1}^{\prime }-D1)$，其中$\alpha$为Q1[1-20]中D1的编码系数。ECWide仅通过机架内部数据传输增量块来更新其他全局奇偶校验块Q2[1-20]。请注意，ECWide只会导致一个跨机架传输块来更新所有全局奇偶校验块。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0XRzOtgp-1686295601235)(C:\Users\hp\AppData\Roaming\Typora\typora-user-images\image-20230605154523866.png)]

图7(b)描述了如何对本地奇偶校验块P1执行机架内部奇偶校验更新[1-5]。对于每个条带，ECWide首先记录每个机架的数据块的更新频率，并为每个本地组找到更新最密集的机架。如果P1[1-5]不在其组中更新最密集的机架中，则ECWide将P1[1-5]交换为更新最密集的机架中的随机数据块(例如D3)。通过这种方式，P1[1-5]被移动到更新最密集的机架上，这样本地奇偶校验更新就可以在机架内完成，而不会产生跨机架的数据传输。

当数据块被更新时，必须确保同一条带的所有全局奇偶校验块和本地奇偶校验块都被同步更新。ECWide可以以最先进的方式处理一致的奇偶更新，例如，通过利用一种piggybacking方法将经典的两阶段提交改进为一阶段提交。

5 实验

我们在三个主要模块中实现ECWide (x4):一个基于组合局部性执行修复操作的修复模块，一个执行多节点编码的编码模块，以及一个执行机架内奇偶校验更新的更新模块。我们分别为冷热存储系统实现了两个ECWide原型，即ECWide- c和ECWide- h，如图8所示。

ECWide-C.

ECWide-C主要在Java中实现，大约1500 SLoC，编码模块则是基于Intel ISA-L的c++语言实现，大约300 SLoC。它有一个存储元数据并使用Scheduler守护进程组织修复和编码操作的MasterNode，以及多个存储数据并执行修复和多节点编码操作的datanode。请注意，ECWide-C没有考虑更新模块，假设更新在冷库中很少见。

对于修复操作，Scheduler触发每个DataNode的修复模块，该模块充当本地修复程序。这些DataNode(充当本地修复者)将部分修复的结果发送给充当请求者的DataNode，后者最终重建丢失的块。对于编码操作，Scheduler选择一个机架并触发机架中涉及的每个DataNode的编码模块。涉及的DataNode执行多节点编码，作为目标节点的DataNode生成所有全局奇偶校验块。

**ECWide-H.**ECWide-H基于Memcached内存中的键值存储(v1.4)[6]和libMemcached (v1.0.18)[5]的热存储。它是用C语言实现的，大约有3000个SLoC。它遵循客户机-服务器体系结构。它包含存储键值项的memcachedserver，以及执行修复和奇偶更新操作的memcachedclient。它还包括用于管理元数据的协调器。协调程序包括协调修复和奇偶更新操作的Scheduler守护进程和分析更新频率状态的Updater守护进程。请注意，ECWide-H不像ECWide-C那样包含编码模块，因为内存中擦除编码的键值存储中的块大小通常很小(例如，4 KiB[18,73,74])，而单节点CPU缓存足够大，可以预取宽条带的所有数据块，以获得高编码性能(x4.2)。

对于修复操作，ECWide-H的执行方式与ECWide-C相同，只是它使用MemcachedClients作为本地修复程序。对于全局奇偶校验块的更新，Scheduler定位全局奇偶校验块所在的机架，并触发MemcachedClients的更新模块执行机架内部奇偶校验更新。对于本地奇偶校验块的更新，Updater首先触发交换，其中涉及的两个memcachedclient交换相应的块。本地奇偶校验块的机架内部奇偶校验更新可以稍后执行。请注意，一些现有的内存系统(例如，Cocytus[74])也在单个物理节点中部署多个Memcached实例，并具有适合拓扑局部性的分层拓扑形式。

6 评估

我们在Amazon EC2[1]上使用了许多m5进行实验。通过10gb /s网络连接的xlarge实例。一个实例代表ECWideC的主节点或ECWide-H (x5)的协调器，而其他实例代表ECWide-C的数据节点或ECWide-H的MemcachedClients/MemcachedServers。为了模拟机架内和机架间的异构带宽，我们将节点划分为逻辑机架，并在每个机架中分配一个专用实例作为网关。同一逻辑机架中的实例可以直接通过10gb /s网络进行通信，而不同机架中的实例则通过网关进行通信。我们使用Linux流量控制命令tc[7]来限制每个网关的出站带宽，使跨机架带宽受到约束。在我们的实验中，我们改变网关带宽从500 Mb/s到10 Gb/s。

我们将ECWide-C的块大小设置为64 MiB, ECWide-H (x2.2)的块大小设置为4 KiB。我们绘制了十次实验的平均结果。我们还绘制了10次运行中最小和最大结果的误差条。请注意，由于方差较小，误差条在某些图中可能不可见。

我们介绍了ECWide-C和ECWide-H的组合局域性(CL)的实验结果，并与代表最先进的基于局域性方案的AzureLRC (LRC)和拓扑局域性(TL)进行了比较。

我们证明CL在单块修复和全节点修复方面都优于LRC和TL。我们还展示了我们的多节点编码和内机架奇偶校验更新方案的效率。

6.1 ECWide-C性能

**实验A.1(修复)：**我们使用ECWide-C评估LRC、TL和CL的修复性能。这里我们让32≤k≤64,2≤f≤4，配置不同的网关带宽设置。为(n;k;r;z) CL，我们部署n + 1个实例，其中n个实例作为datanode，一个实例作为MasterNode。对于每一组r不同的f和k，我们选择了两种LRC和两种CL，并根据表4计算了每种方案对应的冗余度。已知k, f和r，我们可以计算和，因此，在接下来的讨论中，我们只显示k, f和r的值。

图9(a)-9(e)显示了在网关带宽为1 Gb/s和500 Mb/s时，不同k和f值下LRC、TL和CL的平均单块修复时间。在相同的k、f和网关带宽下，CL总是优于LRC和TL，而具有最小冗余的TL通常性能最差。例如，在图9©中，当网关带宽为1 Gb/s时，r = 7的CL的单块修复时间为0.8 s，而r = 7的LRC和TL的单块修复时间分别为3.9 s和9.0 s;同样，CL将LRC和TL的单块修复时间分别减少了79.5%和91.1%。

在较小的网关带宽下，CL比LRC显示出更高的增益。例如，在图9©中，当网关带宽为500 Mb/s时，CL优于LRC的增益为82.1%，高于网关带宽为1 Gb/s时的79.5%。原因是CL使跨机架修复带宽最小化，因此当网关带宽受到更大约束时，其性能增益更为明显。

同样，当只有r增加时，CL的单块修复时间增加(见图9©中的r = 7和r = 11)，当只有k变化时，CL的单块修复时间保持稳定(见图9(a)-9©)。实验结果与表4的理论结果一致，单块跨机架修复带宽= (r +1)/f−1。

图9(f)显示了不同f值下LRC、TL和CL的平均全节点修复率;我们还比较了使用和不使用最近最少选择（least-recently-selected）(LRS)方法的CL (x4.1)。我们固定k = 64, r = 11，网关带宽为1gb /s。为了模拟单个节点故障，我们在一个节点中从64个条带中擦除64个块(即每个条带一个块)。然后我们同时修复所有被擦除的数据块。请注意，实际的存储系统通常在每个节点上存储更多的块，但是故障节点的每个块都独立地与一个条带相关联。因此，我们期望使用64块足以提供稳定的性能。从图中可以看出，CL的全节点修复率高于TL和LRC。它的全节点修复率随着f的增加而增加，因为单块交叉帧修复带宽等于(r + 1)/f−1，当f = 4时，有LRS的CL比没有LRS的CL全节点修复率提高了14.1%，从而证明了LRS方法的有效性。

最后，图10显示了平均单块修复时间和平均全节点修复率随网关带宽(从1 Gb/s到10 Gb/s)的变化情况。这里，我们固定k = 64和f = 4。从图10(a)中可以看出，在所有网关带宽设置下，CL在单块修复方面仍然优于LRC和TL，尽管随着网关带宽的增加，差异会变小。例如，当网关带宽为10gb /s时，r = 7的CL的单块修复时间(0.34 s)比r = 7的LRC (0.49s)和TL (1.11s)的单块修复时间分别减少了30.6%和69.4%。此外，从图10(b)中可以看出，CL在全节点修复中保持了相对于LRC和TL的性能提升，LRS带来了进一步的改进。

我们当前实现的一个限制是全节点修复性能没有完全优化。我们可以通过最先进的修复并行化技术进一步提高吞吐量，例如奇偶分簇[30]、PPR[46]和修复流水线[41]。然而，所有的编码方案在相同的实验设置下被公平地评估。如果我们对所有编码方案使用并行化技术，我们预计CL应该通过减少跨机架修复带宽和I/O来保持其性能增益。我们把这个问题作为未来的工作。

**实验A.2(编码)：**我们测量了CL每条的平均编码时间。这里固定k = 64, f = 4，令11≤r≤19。图11(a)显示了单节点编码和多节点编码的结果。我们看到，多节点编码的编码时间明显低于单节点编码。例如，当r = 11时，多节点编码比单节点编码减少84%的编码时间。我们进一步测量平均编码吞吐量。这里，我们固定4≤k≤64,f = 4。图11(b)显示了单节点编码和多节点编码的结果。当k较大时，多节点编码可以获得非常高的编码吞吐量，因为同一机架上的多个节点可以共享它们的计算资源，从而加快编码操作。另一方面，当k较大时，单节点编码的吞吐量较低，这与我们在图1所示。请注意，图1显示的吞吐量高于图11(b)，因为前者只考虑编码操作的计算部分，而后者除了编码计算外，还包括读取编码块的磁盘I/O。

6.2 ECWide-H 性能

**实验B.1(修复)：**我们使用ECWide-H评估LRC、TL和CL的修复性能。为(n;k;z) TL和(n;k;r;z) CL，我们部署n + 8z + 1个实例，包括n个作为MemcachedServers的实例，8z个作为memcachedclient的实例(每个z个机架中有8个实例)，以及一个作为Coordinator的实例。

我们考虑了ECWide-H在不同负载下的两种部署场景。为了模拟后台流量，除了ECWide-H中现有的MemcachedClients之外，我们还在后台添加了额外的Memcached客户端(称为后台客户端)，这些客户端不断向MemcachedServers发出读请求。具体来说，我们考虑一种情况，即每个MemcachedServer服务20个后台客户端，以及一个情况，即每个MemcachedServer服务80个后台客户端。

图12(a)-12(e)显示了轻、重背景交通负载下不同k和f下LRC、TL和CL的平均单块修复时间。这里，我们令64≤k≤128,2≤f≤4。与实验A.1 (x6.1)一样，我们对每一组r不同的k和f选择了两种LRC和两种CL，并根据表4计算了每种方案对应的冗余度。与实验A.1类似，我们看到CL在热存储工作负载中仍然表现最好。例如，在图12©中，在大流量背景下，r = 27的CL的单块修复时间为10.3 ms, r = 27的LRC和TL的单块修复时间分别为85.5 ms和108.4 ms;CL将LRC和TL的单块修复次数分别减少了87.9%和90.5%。同样，r = 27的CL只产生1.06陪的冗余，接近TL的最小冗余(1.031倍)。

此外，CL在高背景流量下的性能增益比低背景流量下的性能增益更高，类似于实验a .1，将网关带宽为500 Mb/s与1 Gb/s进行比较。这是因为在大的后台流量下，单块修复性能更容易受到有限的可用带宽的瓶颈，在这种情况下CL的性能增益更加突出。

图12(f)显示了不同f值下的平均全节点修复率。在这里，我们固定k = 64和r = 7，并将重点放在浅色背景交通上。从图中可以看出，CL的全节点修复率高于LRC和TL，当f = 4时，有LRS的CL比没有LRS的CL的全节点修复率提高了29.7%。同样的原因，CL的全节点修复率也随着f的增加而增加，与图9(f)的结果一致(见x6.1中的实验A.1)。

**实验B.2(更新)：**我们使用(136,128,27,34)CL (x4.3)计算了全局和本地奇偶校验块在有和没有机架内奇偶校验更新时的更新时间;如果没有机架内部奇偶校验更新，我们假设每个奇偶校验块由相应的增量块直接更新。我们使用Yahoo!云服务基准(YCSB)[21]具有两种读取更新比率，即读取大部分(95%:5%)和更新密集(50%:50%)

图13显示了不同更新方案的平均更新时间。与没有内部机架奇偶校验更新相比，全局奇偶校验块的内机架奇偶校验更新将更新时间减少了33.2%，本地奇偶校验块的内机架奇偶校验更新将更新时间减少了14.4%，本地和全局奇偶校验块的内机架奇偶校验更新将更新时间减少了47.6%。

7 相关工作

宽条擦除编码。宽条纹已经在商业上被采用(例如，VAST[9])，但对其设计细节知之甚少，并且在实际部署中对宽条纹擦除编码的基本特性没有严格的分析。文献中的一些研究从不同的角度解决了这一问题。Li等[42]使用本地擦除编码解决了硬盘中的读-重试问题，其中n = 1024, n−k≤20。Haddock等[28]采用通用gpu提高编解码效率，其中n = 24, k = 20。一些研究考虑使用低密度奇偶校验(LDPC)码[54]或无速率码[44]进行分布式存储，其中k和n−k都很大，但他们考虑的最小冗余(例如1.167×[44]和1.5×[54])仍然高于我们的宽条问题。我们的工作是第一个系统地研究了宽条擦除编码的性能问题，包括修复、编码和更新。

**分布式存储中的擦除编码：**擦除编码在分布式存储中得到了广泛的研究(参见调查[11,52])。由于擦除编码比复制具有更高的性能开销，因此它通常用于冷存储中，冷存储将数据持久性视为头等公民，而不是访问性能[10,12]。为了保证数据的可靠性，快速修复是冷存储中擦除编码的关键。大多数研究通过提出最小化修复带宽的新擦除码来解决修复问题[23,34,50,58,60,63,71]，或者设计有效的修复技术来缩短修复时间[41,46]。在对数据访问性能要求较高的热存储中，也考虑了Erasure编码。一个值得注意的例子是内存键值存储中的擦除编码，现有的研究主要涉及缓存[57]、数据管理[43,73,74]和一致性哈希[18,70]。现有的关于擦除编码的研究主要集中在小k和m上，而我们的研究主要集中在宽条纹在冷热存储中的应用。

**擦除编码中的局部性：**许多研究利用奇偶局部性或拓扑局部性来提高擦除编码的性能。在奇偶校验局域性方面，局部可修复码[27,33,34,51,63]通过将本地奇偶校验块与少于k个数据块的不同组关联来减少修复带宽和I/O成本。产品代码[24,29,40]将本地校验与水平和垂直数据块组相关联，以获得高容错性。一些研究利用分层奇偶locality将本地奇偶块与不同级别的数据块组关联起来，以处理多次故障[38,62]。在拓扑局部性方面，现有研究利用机架级局部性来减少修复或更新操作中的跨机架数据传输。一些研究提出了修复优化的擦除码结构[31,32,56]，以最大限度地减少跨机架修复带宽，而其他研究则设计了有效修复的新技术[65,66]或更新[64]。我们的工作结合了奇偶局部性和拓扑局部性来解决宽条纹问题，特别是在减少宽条纹的修复带宽方面。

8 结论

宽条纹是擦除编码分布式存储的一个新概念，以实现极大的存储节省。我们提出了一种结合宇称局域性和拓扑局域性的修复机制，以有效地解决宽条纹的修复问题。设计了一个实现组合局部化的原型系统ECWide。我们进一步设计了多节点编码和机架内奇偶校验更新，分别提高了编码和更新性能。我们在冷存储系统和热存储系统上都实现了ECWide，我们的Amazon EC2实验证明了ECWide在修复、编码和更新方面的效率。
2,56]，以最大限度地减少跨机架修复带宽，而其他研究则设计了有效修复的新技术[65,66]或更新[64]。我们的工作结合了奇偶局部性和拓扑局部性来解决宽条纹问题，特别是在减少宽条纹的修复带宽方面。

8 结论

宽条纹是擦除编码分布式存储的一个新概念，以实现极大的存储节省。我们提出了一种结合宇称局域性和拓扑局域性的修复机制，以有效地解决宽条纹的修复问题。设计了一个实现组合局部化的原型系统ECWide。我们进一步设计了多节点编码和机架内奇偶校验更新，分别提高了编码和更新性能。我们在冷存储系统和热存储系统上都实现了ECWide，我们的Amazon EC2实验证明了ECWide在修复、编码和更新方面的效率。