BPR：一种分布式存储系统中的纠删码批量并行修复方法

BPR： 分布式存储系统中的纠删码批处理并行修复方法

如今，纠删码是分布式系统中广泛使用的最重要的技术之一，因为它可以在低存储开销的情况下提高大量数据的可靠性。然而，当分布式系统遇到大量条带数据丢失，需要批量条带数据恢复时，目前的数据恢复方法要么重复单条带恢复方法，要么在恢复大规模条带时只优化部分条带恢复，这样会产生繁重的上传和下载修复流量和不平衡的负载，影响故障恢复的效率并浪费额外的资源。在本文中，我们提出了BPR，一种用于分布式存储系统的纠删码批量并行修复方法。BPR通过对条带进行分类，并通过正向和反向的并行数据恢复，减少跨架网络传输时间，提高恢复吞吐量。实验结果表明，对于大规模的条带恢复，与rPDL相比，BPR在某些情况下可以减少10%的跨架网络传输时间，并增加8%的恢复吞吐量。

1 引言

大规模的分布式集群，如Hadoop，通常由许多独立的低可靠性商业组件组成，组件的意外故障很常见。为了确保这种分布式存储系统中数据的高可靠性和可用性，常见的方法是使用三向复制冗余技术，该技术通过在不同节点上存储同一数据的多个副本来提供容错。当数据量小的时候，复制技术是简单而有效的。但在大型数据中心，三向复制技术需要两倍的存储开销，这是相当昂贵和不可接受的。

作为一种选择，纠删码可以提供接近复制技术的容错能力，而且存储开销较低。在多个纠删码系列中，ReedSolomon码[1]是使用最广泛的代码。一个RS(n, m)将n个数据块编码成m个奇偶校验块，这些n+m个独立的块组成一个条带。每个条纹的这些小块被存储在不同的机架上，称为该条纹的主机机架。通过对条带中剩余的任何n个可用块进行解码，小于或等于m的故障块可以被恢复。然而，使用纠删码来恢复条带中失败的块，需要在多个源机架中检索可用的块，这提供了通过跨机架传输来恢复块，并产生了高的恢复成本。虽然纠删码可以提高存储效率，但它们大大增加了磁盘I/O和网络带宽占用。纠删码已经在云存储系统中被广泛采用，如Azure[20]、Facebook[21]和分布式存储系统[9]、[17]、[20]。

在现代大型数据中心中，存储节点被划分到不同的机架上。存储节点通过交换机连接在同一个机架上。而且，多个机架再通过网络核心互连[2], [3]。在这种架构下，如果你想修复条纹数据，你需要在多个机架之间传输数据，而跨机架的带宽往往在各机架之间竞争。此外，每个节点的可用跨架带宽只有架内带宽的1/20到1/5[4]。因此，跨架带宽比架内带宽要稀缺得多[5]，过多的跨架带宽会减慢恢复过程。

为了减轻跨架数据修复的影响，现有的工作设计了新的修复调度方法，以尽量减少跨架修复流量[7]，[8]，[12]，[14]。然而，这些数据修复方法仍然面临着一个非同寻常的挑战。这个挑战是，在修复大量条带时，上传和下载的流量不能很好地平衡。一些工作开始考虑这样的现实，通过替代和交换修复方案来平衡上传和下载的流量，例如ClusterSR[12]。然而，当块集中存储在几个机架上时，这些工作将不会避免选择有故障节点的Rf作为目标机架。当它选择以故障节点为目标机架的Rf时，在恢复大规模条带时，Rf将遭受比其他更严重的跨机架流量。Xu等人[14]已经考虑了关于Rf的这个问题，但是这项工作重复了恢复单个条带的方法，因此在恢复大规模条带时，一些目的机架可能会遭受下载流量拥堵。

为了分散和平衡大量条带恢复过程中的上传和下载流量，在本文中，我们提出了BPR，一种用于分布式存储系统的纠删码批量并行修复方法。BPR的重点是对条带进行分类，将恢复操作分为一些小的部分对称操作，以获得全双工传输的好处。首先，BPR将条带的所有块分布到一些机架上，然后提供条带分类方案。最后，BPR根据分类结果构建多条带修复方案。通过正向和反向的并行传输，BPR可以大大减少跨机架的数据传输时间，提高擦写编码分布式存储系统的恢复吞吐量。

我们的贡献总结如下：

• 我们提出了BPR，一种纠删码批量并行修复方法。它可以分批恢复条带数据，并有效地减少跨架数据传输时间和总恢复时间，大大提高了在擦除编码分布式存储系统中发生条带故障时的恢复产量。
• 为了有效地分批恢复数据，我们还提出了一种条带分类方法，按照统一的分类方法将条带分为不同的批单，用于数据恢复。
• 我们进行了一组实验来评估BPR。结果显示，与rPDL相比，BPR减少了高达10%的跨架网络传输时间，并增加了高达8%的恢复产量。

本文的其余部分概括如下。第二节提供背景和一些初步工作。第三节介绍了最新的工作。第四节介绍了我们观察到的一些问题。第五节介绍了条纹分类方法和BPR设计。第六节对BPR进行了理论分析。第七节评估了BPR的性能。第八节对这项工作进行总结。

2 研究背景

在这一节中，我们简要回顾了纠删码的基本特性和部分解码的相关工作，这是我们恢复方法的基础。

A. 纠删码

本文重点讨论了一个著名的Reed-Solomon（RS）编码。与复制存储相比，擦除编码存储提供了类似的容错能力，但存储成本却大大降低。一个RS码通常有两个参数，n和m，表示一个RS码将n编码成m个奇偶校验块，这样n个数据块和m个奇偶校验块就构成了一个条纹。任何剩余的n个数据块都可以被解码以修复原始数据块，因此最多可以容忍m个数据块的故障。图1展示了RS(5, 3)码的矩阵编码过程的细节。这里，数据块和奇偶校验块被组织成固定大小的单位，称为块。

如果我们把每个条带的n个块放在n个不同的数据节点上，系统可以容忍节点级的故障。因为这样，如果一个机架被损坏，我们可以从其他存储数据的机架上找到n-m个块，参与数据恢复。

B.局部解码

在实际生产中，内架带宽是10Gb/s，但跨架带宽只有1Gb/s[9]，所以跨架带宽是极其稀缺的。然后，传统的数据恢复将条带中参与恢复的所有块转移到存储新修复块的目标机架上，这就产生了大量的跨机架交通堵塞，大大延长了总的恢复时间，并导致负载不平衡。为了解决这个问题，我们可以将解码和网络传输过程分配给其他机架，这些操作可以在一段时间内并行进行，从而减少数据传输时间。

另一方面，在编码/解码过程中，RS码采用了。GF(2^w)场有2^w个值，每个值都对应于一个度数小于w的多项式，这样，场上的四种运算就转化为多项式空间的运算。GF算法的一个重要属性是，加法是XOR。因此，RS码是通过数学线性组合进行编码/解码的。因此，我们可以提前对机架中参与恢复的块进行部分编码，生成一个中间编码块，其大小与数据块的大小相同。因此，在数据传输过程中，需要跨机架传输的块数将大大减少，跨机架传输的总流量也将减少，因此可以大大减少网络跨机架传输的时间。虽然会多出一些解码过程，但由于跨架带宽是架内带宽的10倍左右，所以总的修复时间会大大减少。

3 准备工作

随着 Hadoop3 逐渐占据主导地位，使用纠删码策略的解决方案越来越多。到目前为止，大量的研究都集中在纠删码的数据恢复问题上，其成果也广泛应用于Hadoop等分布式系统中。根据不同的研究动机，我们简要回顾一下纠删码存储系统的最新科研成果。

为了减少纠删码分布式系统中数据更新的数据传输，Hu等人[10]提出了一个基于蚁群优化的数据更新方案，ACOUS。他们采用了一个两阶段的会合数据更新程序来优化多个数据节点的更新。另一方面，为了提高纠删码存储系统的存储效率，Zhang和Hu[11]采用了E-MBR和Butterfly编码的新型扩展方法，并利用这两种编码的局部更新和特征来降低带宽成本。

更重要的是，我们专注于减少数据恢复的数据传输。Shen[12]提出了ClusterSR，一种集群感知的分散式修复方法。他主要关注分散式修复场景，观察到由于对全双工传输的广泛支持，在实际生产中可以通过平衡集群上传和下载流量，以相同的传输速率独立发送和接收数据，以减少跨集群的修复流量。然而，为了最大限度地发挥部分解码的优势，节省跨机架的修复流量，数据块被集中存储在几个机架上。当单节点故障发生时，为了获得RS(n, m)的m节点容错，ClusterSR不会避免选择以故障节点为目标机架的Rf。当它选择以故障节点为目标机架的Rf时，Rf在恢复大规模条纹时将遭受比其他机架更重的跨机架流量。

Shi和Lu[13]提出了一套相干的网络内EC基元，命名为INEC，它可以被集成到五个EC方案中。并且，INEC可以显著降低延迟，加速吞吐量、写入和降级读取性能。Xu等人[14]提出了一种基于PDL数据布局的修复方法rPDL。rPDL针对PDL数据布局提出了两种修复方案R-w-PD和R-w/o-PD，目的是减少跨架流量。R-w-PD直接向存储新修复块的机架传输块，而R-w/o-PD使用部分解码来减少需要传输的块的数量。然后比较R-w-PD和R-w/o-PD在不同场景下所需的跨机架流量，并选择一个低流量的恢复方案。最后，以高并行度实现故障恢复，从而降低跨架恢复的时间成本。然而，这项工作是随机选择目标机架的，因此一些目标机架可能遭受严重的下载流量拥堵。Bai等人[15]提出了PPT和PPCT，利用特殊的带宽间隙来并行传输数据，以绕过低带宽链路。但这种方法会带来网络拥堵和竞争。Zhou等人提出SMFRepair[16]，一种单节点多级转发修复技术。SMFRepair仔细选择帮助节点，并利用闲置节点绕过低带宽链路。闲置的节点有足够的和未使用的网络带宽。它还对由闲置节点优化的修复链路进行管道化处理。然而，SMFRepair很少考虑到多条线路的修复，总的修复时间并不总是最少的时间。

4 研究问题

鉴于交叉带宽的稀缺性，我们有以下观察。简而言之，我们称第i条带为Si，第i架为Ri。为了介绍我们的观察结果，我们使用四个条带标记为{S1, S2, S3, S4}和六个机架标记为{R1, R2, R3, R4, R5, R6}作为一个存储系统实例，如图2（a）所示。这些机架是按位置编号的。对于S1来说，机架{R2、R3、R4、R5}存储了这个条带的所有块，我们把这四个机架称为S1的主机机架。机架{R1、R6}不存储S1的块，所以我们称这两个机架为S1的非主机机架。为了容忍RS(n, m)的单机架故障，我们最多只能把同一条纹的m个块放在同一个机架上。同时，机架{R2, R3, R4, R5}在RS(12, 4)中都正好存储了S1的四个块，所以这四个主机机架是S1的完整机架。否则，存储少于四块条带的主机机架被称为该条带的非满负荷机架。

根据图2(a)中的数据布局，我们假设四个RS(12,4)条带中的每个条带都有一个故障块，如图2(b)所示，系统需要恢复所有这些故障块。我们用Rf来表示存储条带中故障块的机架。存储条带的新修复块的机架被称为目标机架。

在现有的恢复方法中，如果所有的主机机架都满了，系统会随机选择一个非主机机架作为目标机架来存储新的修复的块。对于S1来说，这三个主机机架{R2、R3、R4}提供的块通过跨机架转移来恢复块，我们称这些机架为源机架。同时，为了避免Rf遭受比其他机架更严重的跨机架流量[16]，我们不选择Rf作为目的机架和源机架。

在常规修复策略中，有两个观察点：

观察1：如图3(a)所示，修复方案从{R2, R3, R4}的{S1, S3}中检索出12个幸存的块，并将两个新修复的块存储在同一个机架R1中。为了避免存储故障块的机架Rf遭受比其他机架更严重的跨机架流量，机架{R5, R6}将不参与条带{S1, S3}的重建。通过部分解码技术，一个条带只需要从机架{R2、R3、R4}汇总并传输三个块到R1进行修复。但如果两个条带同时恢复，R1需要一次性下载6个块，其下载流量的严重拥堵将大大增加网络传输的总时间。

观察结果2： 如图3(b)所示，修复方案从条带{R2,R3,R4}和条带{R4,R5,R6}中检索出12个幸存的块，并将修复后的块存储在不同的条带如条带{R3,R5}。

在这种情况下，块的下载流量被分散到机架{R3，R5}，但R4仍然要同时向考虑Observation1和Observation2的其他机架传输四个块。分组的上传流量仍然被阻断，网络传输的总时间也增加。

我们发现，一旦大多数条带需要同时恢复，多个条带可能会选择相同的非主机机架来存储新的修复块，同时选择相同的源机架一起传输数据，导致单个或多个机架的下载或上传流量拥堵。网络传输的总时间会大大增加。

从观察1和观察2中我们了解到，解决上传和下载的流量拥堵问题是减少网络传输总时间的关键，从而大大降低总修复时间成本。

5 BPR的设计

为了解决上述上传和下载流量拥堵的问题，我们提出了一种纠删码批量并行修复方法，即BPR。BPR的重点是对条纹进行分类，并将恢复操作分为一些小的部分对称操作，以利于全双工传输。BPR包括两个阶段的过程，即块的初始布局阶段和故障块的恢复阶段。在第一阶段，当数据最初存储在存储系统中时，BPR将所有条形块分布到各个机架上。在第二阶段，为了进行高效的批量恢复，BPR将大规模的条带分类到每个小批量，称为Batchs_single，其中的条带可以同时进行恢复，然后BPR根据不同Batche_single的特点实施不同的恢复方案，目的是分散和平衡跨机架的上传和下载流量。

A 大块条纹的分布

BPR被应用于RS(n,m)。在放置块的时候，为了获得m个节点的容错性，我们应该将最多m个相同条带的块放置在同一个机架上，并且任何两个相同条带的块都不分配到同一个节点上。然后，为了最大限度地发挥部分解码的优势，BPR将尽可能多的相同条带的块放置在同一机架上。对于块的均匀分布，任何两个机架上的同一条带的块的数量最多相差1。N(n,m) = ⌈ n+m/m ⌉是存储同一条纹的块的主机机架的数量。

例如图2(a)所示，在RS(12,4)放置的过程中，BPR将同一条带的所有16个小块放置在四个机架上，每个机架承载16个小块中的四个。另外，在实际生产中，每个条带的单次故障概率超过90%[6]，[17]，[19]。因此，BPR主要关注于单次故障的修复。BPR适用于单块故障和单节点故障。

B 条纹的分类

为了根据不同的条带分布来规范恢复，我们把要恢复的条带分成最小的批量恢复单位Batch_single，然后对每个Batch_single执行恢复方案。

算法1描述了如何为有非满负荷主机机架的条纹选择目的机架，并根据源机架和Rf将所有条纹划分到每个Batchsingle中。首先，如果有一个非满的主机机架被选为条带的目标机架，BPR不需要通过跨机架传输这个非满的主机机架的块，以减少跨机架流量。因此，如果一个条带有非满载的主机机架，BPR会随机选择一个非满载的主机机架作为目标机架来保存这个条带的新修复块。同时，BPR选择其他非满负荷的主机机架和满负荷的主机机架作为源机架来传输该条带的修复块。

我们观察到的情况是，对于全双工传输，当我们在图6(a)中同时恢复两个条纹时，R4向S1中的R3传输块，R3向S2中的R4传输块的过程是一个对称和平行的跨架传输过程。该传输过程很少引起上传和下载流量拥堵。这两个条带{S1, S2}具有相同的源机架和Rf。为了实现大规模条带恢复的这个过程，BPR首先将具有相同源机架和Rf的条带分成Batches_single。

接下来，我们观察到，当我们在图6(b)中恢复S1和S2时，图6(b)中的R5要比图6(a)中的所有源机架单独转移块。图6(a)中两个条纹的源机架数量是偶数，而图6(b)中源机架的数量是奇数。因此，我们需要实施不同的恢复方案来恢复图6(a)和图6(b)中的这两种类型的条纹。BPR其次将这些Batchessingle划分为Batcheven或Batchodd。

根据源机架和Rf是否相同，条形图分别被划分为相同的Batchsingle。例如，图4显示，S1有三个机架{R3、R4、R5}的块要参与跨机架传输，所以这三个机架是S1的源机架。对于S5的R2是一个非满负荷的主机机架，它被选为目标机架，为这个条带保存一个新的修复的块，所以S5有两个源机架{R3，R4}。条带的源机架{S1, S2}是同一个机架{R3, R4, R5}，Rf是同一个机架R2，所以{S1, S2}形成一个Batchsingle。而源机架的数量是3，是个奇数，所以这个Batchsingle属于Batchodd。

C 修复条带

在上面，我们对要修复的条纹进行了分类，并将其分为Batchessingle、然后我们将恢复这些Batchessingle，算法2阐述了恢复的详细程序。

算法2描述了如何选择目标机架和恢复Batchsingle的条纹。我们把拥有非满负荷主机机架的条纹称为非满负荷条纹，把源机架全部为满负荷主机机架的条纹称为满负荷条纹。非满载条纹已经选择了非满载主机机架作为目标机架，满载条纹将选择非主机机架作为目标机架。为了分散和平衡全球下载流量，BPR开始以特定的方式为每个Batchsingle的条带选择目标机架。BPR首先收集Batchsingle中非完整条带选择的所有目标机架的数量和ID。然后，BPR按照ID的升序对完整条纹和非主机机架进行编号。这个非主机机架对于Batchsingle中的所有完整条纹都是一样的。最后，完整条纹从非主机机架中选择机架，并以升序编号为目标机架。如果有非满负荷的条纹已经选择过一次这个机架，BPR就会跳过选择这个机架，而有序地选择下一个机架来保存这个新修复的块。

例如，如图4和图5所示，条纹{S5、S6、S7}形成了一个Batchsingle。S5是一个非满载条带，{S6, S7}是两个满载条带。S5已经选择了一个非满条的机架作为目标机架。BPR收集了这个非满条的目的机架的编号和ID的信息，即{ID: number}如{R2:1}，这意味着R2已经被选为目的机架，遭受了一次下载流量。为了减少R2的下载流量，我们将在这个Batchsingle中减少一次作为目标机架的机会。同时，条带{S6，S7}需要选择非主机机架作为目的机架。BPR将S6和S7从第1位编号到第2位，将{R1, R2, R6}从第1位编号到第3位。然后，我们开始选择非主机机架{R1, R2, R6}到{S6, S7}。按升序排列、我们首先选择非主机机架中的第1个为全条纹的第1个，选择非主机机架中的第2个为全条纹的第2个，这意味着我们首先选择R1到S6，R2到S7。然而，就{R2:1}而言，非全条纹的S5已经选择了一次R2作为目标机架。我们跳过选择R2，选择下一个非主机机架R6到S7。

然后，为了在数据传输过程中分散源机架和目的机架的上传和下载流量，我们对Batch_single中的条纹执行Batchodd修复方法或Batcheven修复方法。

错开两条带子的上传和下载流量很少会造成上传和下载流量的拥堵。为了实现这一效果，无论是Batcheven修复方法还是Batchodd修复方法，都采用了全双工传输的思路来减少数据传输时间。跨架数据传输分为两种平行数据传输方式：正向数据传输和反向数据传输。BPR让奇数条纹实现正向平行数据传输，偶数条纹实现反向平行数据传输。

所谓正向平行数据传输，就是将数据从编号较大的源机架平行传输到编号较小的机架，即图6(a)中R4将数据传输到R3，最后再将数据传输到目的机架R1。而反向并行数据传输则相反，即从数字较小的源机架并行传输数据到数字较大的机架，即图6(a)中R3将数据传输到R4，最后将数据传输到目的机架R6。

Batcheven修复方法和Batchodd修复方法之间有一点区别。首先，详细介绍Batcheven修复方法中前向并行数据传输的过程。前向并行数据传输开始时，按两两一组的顺序将条带的源机架从最小的数字到最大的数字分组。然后，同一组的两个机架中编号较大的机架中的块被聚合并传送到编号较小的机架上，然后与编号较小的机架中的块聚合。各机架继续成对重复上述分组和聚合过程，直到所有源机架的聚合块被传送到编号最小的源机架，然后聚合并传送到条纹的目的机架。进行解码操作，得到需要恢复的块。

Batchodd修复方法和Batcheven修复方法之间有一点区别。在数据传输过程中，有一个单源机架不能参与Batchodd的并行传输。而单源机架的块在恢复之初就被直接聚合，并传输到目的机架上。如图6(b)所示，R5是一个被挑出来的单源机架。当正向/反向数据传输开始时，数据块被直接聚合并传输到R1和R6的目的机架上。

6 BPR的效果分析

在本节中，我们将从两个方面分析BPR的效果：数据恢复过程中的跨架数据传输时间和恢复吞吐量。数据传输时间主要分析不同情况下跨架传输块到等待参与数据恢复的目的架的时间，恢复吞吐量主要分析BPR占用的网络负荷。

因为RS(6,3)和RS(12,4)在一些最新的研究中[14] [16] [18]作为经典的例子。接下来，我们以图6(a)和图6(b)中的上述RS(6,3)和RS(12,4)多条线修复为例，分析BPR在许多不同场景下恢复数据的跨架数据传输时间和恢复吞吐量的差异。

数据恢复的过程由网络数据传输和解码组成，但在实际恢复中，解码时间远小于数据传输时间，所以我们在此近似计算中不考虑解码时间。数据传输需要先进行架内聚合，再进行跨架传输，其时间分别为Tinner和Tcross，通常Tcross≈Tinner∗10。综上所述，跨架传输是数据恢复的关键，所以我们重点研究跨架数据传输的时间。

由于网络接口卡（NIC）和网线的广泛支持，全双工传输可以在相同的传输速率下独立发送（上传）和接收（下载），跨机架数据传输的时间可以用上传块Tupload和下载块Tdownload的时间来表示，这意味着

由于采用了部分解码技术，我们可以将机架中的块聚合成一个与正常块大小相同的块进行传输，我们可以将一次跨机架传输的时间设定为Toncecross（n是跨机架数据传输的数量）。

因此，上传/下载一个块的时间T被设定为跨架数据传输的单位时间。按场景讨论恢复数据时的跨架数据传输时间。

案例1：图6（a）中的RS（6,3）。

当我们采用BPR时，恢复时间图为图7。

从图7中，我们可以看到，在BPR中，跨架数据传输的时间Tcross=2T。不存在上传和下载的交通堵塞。

对于RS(n, m)，k= ⌈ n+m/m ⌉。如果目的机架是一个非主机架，在Batcheven修复方法中，2条恢复的跨架传输时间为

如果目的地机架是非满载机架，因为目的地机架不参与通过交叉机架传输块、在Batcheven修复方法中，2条带子恢复的跨架传输时间是：

案例2：图6（b）中的RS（12,4）。

当我们采用BPR时，恢复时间图为图8。

从图8中，我们可以看到BPR中跨机架数据传输的时间Tcross=3T。当R5将数据块传输到不同机架时，会有一点上传流量堵塞。

对于RS(n, m)，k= ⌈ n+m/m ⌉，在Batchodd修复方法中，2条恢复的跨架传输时间为

另外，如果目标机架为非主机机架，在Batcheven修复方法中，2条恢复的跨机架传输时间为

我们还评估了减少上传和下载流量堵塞对恢复吞吐量的好处。恢复吞吐量被定义为每秒钟恢复的数据量。

7 性能评估

在本节中，我们提出了广泛的实验结果，以评估恢复算法BPR的性能。

系统配置：我们在一个由七个虚拟机组成的集群上进行了实验。在这一部分，每个虚拟机都是基于Ubuntu 16.04.1创建的，具有8核CPU，5GB内存和40GB SCSI。我们用一台虚拟机作为控制终端，用六台虚拟机来模拟六个机架。每个虚拟机有四个进程来模拟四个节点。交换机的带宽为1Gbps。

我们专注于单次故障情况，其中假设PDL布局中的编码条纹中的一个随机数据块发生故障。在我们的实验中，每个块被配置为128MB。在这一部分，我们从两个方面来比较修复性能，即跨架传输时间和恢复吞吐量。

因为RS(6,3)和RS(12,4)参与了PDL的布局，而且RS(6,3)、RS(12,4)适用于Batcheven我们首先对RS(6,3)和RS(12,4)分别进行了三次控制试验，以分析不同条带数量下的跨架传输时间。这些条带都是等待修复的受损条带。

图9和图10显示了结果，我们可以得出以下结论： 首先，在少数条带恢复（20/30条带）中，使用BPR的跨架传输时间与使用rPDL的时间相似，甚至恢复时间还稍长一些。因为在少数条带的块恢复过程中，I/O和聚合时间在部分解码技术中占很大比例。而且由少数条带恢复引起的上传和下载流量堵塞并不多。

然后，我们发现，随着条纹数量的增加，BPR的改进效果越来越好，比rPDL好。当恢复很多条带（100/90条带）时，与rPDL相比，BPR可以分别减少7%-10%的跨架传输时间。接下来，我们在BPRodd和BPReven中测量90和100条带的恢复吞吐量。发现BPR与rPDL相比，在图11中增加了7-8%的恢复吞吐量，这与跨架传输时间相似，原因是当k不多时，BPR的总数据量与rPDL类似，恢复吞吐量与总传输时间之间存在负相关关系。

8 结论

在本文中，我们重点讨论了在分批恢复数据块时的跨架数据传输问题，即上传和下载流量堵塞的问题。我们提出了BPR，一种用于分布式存储系统的擦除编码修复方法。BPR提供了一个条带分类方案，然后根据分类结果构建多条带修复方案。通过正向和反向并行传输，BPR分散和平衡了上传和下载的流量。实验结果表明，与rPDL相比，BPR显著减少了跨架传输时间达10%，恢复吞吐量增加达8%。

参考文献

[1] I. S. Reed and G. Solomon, ‘‘Polynomial codes over certain finite fields,’’
J. Soc. Ind. Appl. Math., vol. 8, no. 2, pp. 300–304, Jun. 1960.
[2] M. Chowdhury, S. Kandula, and I. Stoica, ‘‘Leveraging endpoint flexibility
in data-intensive clusters,’’ in Proc. ACM SIGCOMM Conf. SIGCOMM,
Aug. 2013, pp. 231–242.
[3] Y. Hu, X. Li, M. Zhang, P. C. Lee, X. Zhang, P. Zhou, and D. Feng,
‘‘Optimal repair layering for erasure-coded data centers: From theory to
practice,’’ ACM Trans. Storage, vol. 13, no. 4, p. 33, 2017.
[4] T. Benson, A. Akella, and D. A. Maltz, ‘‘Network traffic characteristics of
data centers in the wild,’’ in Proc. 10th ACM SIGCOMM Conf. Internet
Meas., Nov. 2010, pp. 267–280.
[5] R. Li, Y. Hu, and P. P. C. Lee, ‘‘Enabling efficient and reliable transition
from replication to erasure coding for clustered file systems,’’ IEEE Trans.
Parallel Distrib. Syst., vol. 28, no. 9, pp. 2500–2513, Sep. 2017.
[6] Z. Shen, J. Shu, and P. P. C. Lee, ‘‘Reconsidering single failure recovery
in clustered file systems,’’ in Proc. 46th Annu. IEEE/IFIP Int. Conf.
Dependable Syst. Netw. (DSN), Jun. 2016, pp. 323–334.
[7] M. Chowdhury, Z. Liu, A. Ghodsi, and I. Stoica, ‘‘HUG: Multiresource
fairness for correlated and elastic demands,’’ in Proc. 13th USENIX Conf.
Netw. Syst. Des. Implement., 2016, pp. 407–424.
[8] H. Liu, M. K. Mukerjee, C. Li, N. Feltman, G. Papen, S. Savage,
S. Seshan, G. M. Voelker, D. G. Andersen, M. Kaminsky, G. Porter,
and A. C. Snoeren, ‘‘Scheduling techniques for hybrid circuit/packet networks,’’ in Proc. 11th ACM Conf. Emerg. Netw. Exp. Technol., Dec. 2015,
p. 41.
[9] M. Sathiamoorthy, M. Asteris, D. Papailiopoulos, A. G. Dimakis,
R. Vadali, S. Chen, and D. Borthakur, ‘‘XORing elephants: Novel erasure
codes for big data,’’ Very Large Data Based Endowment, vol. 6, no. 5,
pp. 325–336, Mar. 2013.

[10] Y. Hu, Q. Li, W. Xie, and Z. Ye, ‘‘An ant colony optimization based data update scheme for distributed erasure-coded storage systems,’’ IEEE Access, vol. 8, pp. 118696–118706, 2020, doi:
10.1109/ACCESS.2020.3004577.
[11] X. Y. Zhang and Y. C. Hu, ‘‘Efficient storage scaling for MBR
and MSR codes,’’ IEEE Access, vol. 8, pp. 78992–79002, 2020, doi:
10.1109/ACCESS.2020.2989822.
[12] Z. Shen, S. Lin, J. Shu, C. Xie, Z. Huang, and Y. Fu, ‘‘Clusteraware scattered repair in erasure-coded storage: Design and
analysis,’’ IEEE Trans. Comput., vol. 70, no. 11, pp. 1861–1874,
Nov. 2021.
[13] H. Shi and X. Lu, ‘‘INEC: Fast and coherent in-network erasure coding,’’
in Proc. SC20, Int. Conf. High Perform. Comput., Netw., Storage Anal.,
Nov. 2020, pp. 1–17, doi: 10.1109/SC41405.2020.00070.
[14] L. Xu, M. Lyu, Z. Li, C. Li, and Y. Xu, ‘‘A data layout and fast
failure recovery scheme for distributed storage systems with mixed
erasure codes,’’ IEEE Trans. Comput., vol. 71, no. 8, pp. 1740–1754,
Aug. 2021.
[15] Y. Bai, Z. Xu, H. Wang, and D. Wang, ‘‘Fast recovery techniques for
erasure-coded clusters in non-uniform traffic network,’’ in Proc. 48th Int.
Conf. Parallel Process., Aug. 2019, pp. 1–10.
[16] H. Zhou, D. Feng, and Y. Hu, ‘‘Bandwidth-aware scheduling repair
techniques in erasure-coded clusters: Design and analysis,’’ IEEE Trans.
Parallel Distrib. Syst., vol. 33, no. 12, pp. 3333–3348, Dec. 2022, doi:
10.1109/TPDS.2022.3153061.
[17] D. Ford, F. Labelle, F. I. Popovici, M. Stokely, V.-A. Truong, L. Barroso,
C. Grimes, and S. Quinlan, ‘‘Availability in globally distributed storage
systems,’’ in Proc. 9th USENIX Conf. Operating Syst. Design Implement.
(USA), 2010, pp. 61–74.
[18] T. Liu, S. Alibhai, and X. He, ‘‘A rack-aware pipeline repair scheme
for erasure-coded distributed storage systems,’’ in Proc. 49th Int. Conf.
Parallel Process. (ICPP), Aug. 2020, pp. 1–11.
[19] K. V. Rashmi, P. Nakkiran, J. Wang, N. B. Shah, and K. Ramchandran,
‘‘Having your cake and eating it too: Jointly optimal erasure codes for
i/o, storage, and network-bandwidth,’’ in Proc. 13th USENIX Conf. File
Storage Technol., 2015, pp. 81–94.
[20] C. Huang, H. Simitci, Y. Xu, A. Ogus, B. Calder, P. Gopalan, J. Li,
and S. Yekhanin, ‘‘Erasure coding in windows azure storage,’’ in Proc.
USENIX Annu. Tech. Conf. (ATC), 2012, pp. 15–26.
[21] S. Muralidhar, W. Lloyd, S. Roy, C. Hill, E. Lin, W. Liu, S. Pan, S. Shankar,
V. Sivakumar, L. Tang, and S. Kumar, ‘‘f4: Facebook’s warm BLOB
storage system,’’ in Proc. USENIX Symp. Oper. Syst. Design Implement.,
USENIX Annu. Tech. Conf. (ATC), 2012, pp. 15–26.
[21] S. Muralidhar, W. Lloyd, S. Roy, C. Hill, E. Lin, W. Liu, S. Pan, S. Shankar,
V. Sivakumar, L. Tang, and S. Kumar, ‘‘f4: Facebook’s warm BLOB
storage system,’’ in Proc. USENIX Symp. Oper. Syst. Design Implement.,
2014, pp. 383–398.