一种分布式纠删码存储系统的数据修复方法与流程

本发明属于云存储技术领域及计算机信息技术存储领域，尤其是涉及一种分布式纠删码存储系统的数据修复方法。

背景技术：

大数据时代的来临使得云存储系统的规模日益增长。云存储系统是包含数量庞大的服务器(称为节点)、存储介质(主要是机械硬盘和固态硬盘)以及网络互连设备的分布式存储系统。庞大的规模导致系统中出现节点或硬盘故障成为常态。为了在数据可靠性、存储设备开销和系统性能之间做出权衡，越来越多的分布式存储系统(例如HDFS、GFS-II、Ceph、Azure)倾向于使用纠删码策略来替代三副本策略存放占用空间巨大而访问频度不高的数据。这些数据大多具有WORM(Write-Once-Read-Many，单写多读，不可更改)特性。

纠删码(Erasure Coding，简称EC)是一种将数据耦合编码以保证低空间占用和高容错的存储策略。如图1所示，原始数据被分成k个原始数据块(简称原始块)，编码(encode)得到n个编码数据块(简称编码块)，组成一个条带。每个条带包含k个原始块，m个校验数据块(简称校验块)，n＝k+m。这种纠删码记为EC(k,m)。当这个条带中有数据块丢失时，可以通过任意k个块解码(decode)得到原始数据。能同时容忍m个块丢失，容错能力为m，如图2所示。

当数据块丢失时，系统先解码得到k个原始块，再编码得到整个条带，最后将丢失的块重新写入到系统中，这个过程被称为数据修复。设数据块丢失的个数为f(f≤m)，则数据修复的开销为k+f块。这个开销k+f倍于数据拷贝，因此被称为纠删码的修复风暴。若丢失的是原始块，且该原始块被客户端访问，则系统需要获取k个块解码得到原始块以提供给客户端，这个过程被称为降级读。k倍的开销也直接影响系统的性能。

使用纠删码策略的分布式系统可称为分布式纠删码存储系统。它将多个条带分布于集群中，一个条带内的块必须分布在不同的容错区间(一般为节点或机架)，如图3所示，图中举出4个条带，1D表示条带1的原始块，1P表示条带1的校验块，依次类推，一个条带的多个块分布在不同的节点，同一块硬盘存储多个条带的原始数据和校验数据。节点离线、硬盘损坏或网络断开将使一部分条带丢失原始块或校验块。目前，业界在数据修复流程中并没有对原始块和数据块做区分，这使得存储系统要承担修复风暴对资源的开销。因此，有必要对现有的修复方法进行优化。

技术实现要素：

本发明的目的就是为了克服上述现有技术存在的缺陷而提供一种减少降级读次数、降低资源开销的分布式纠删码存储系统的数据修复方法。

本发明的目的可以通过以下技术方案来实现：

一种分布式纠删码存储系统的数据修复方法，包括以下步骤：

1)获得更新后的条带修复队列，所述条带修复队列包括与各条带对应的条带记录，所述条带保留原始数据，且条带中校验块个数大于等于3；

2)判断所述条带修复队列是否为空，若是，则执行步骤5)，若否，则执行步骤3)；

3)取出所述条带修复队列的第一个条带，根据与该条带对应的条带记录获取该条带的数据丢失状态；

4)根据所述数据丢失状态对条带进行相应修复处理，返回步骤1)；

5)所有条带修复完成，退出。

所述步骤1)中，在集群拓扑结构变动时进行条带修复队列的更新。

所述步骤3)中，所述数据丢失状态包括数据丢失时刻和丢失的数据块集合。

所述步骤4)中，根据所述数据丢失状态对条带进行相应修复处理具体为：

401)根据数据丢失状态判断是否为多数据块丢失，若是，则执行步骤405)，若否，则执行步骤402)；

402)根据数据丢失状态判断是否为单个校验块丢失，若是，则执行步骤403)，若否，则执行步骤405)；

403)根据数据丢失状态判断数据丢失时长是否大于延迟等待阈值，若是，则执行步骤405)，若否，则执行步骤404)；

404)不进行条带修复，将当前获取的条带加入到所述条带修复队列的队尾，返回步骤1)；

405)对当前获取的条带进行修复处理，处理完成后返回步骤1)。

所述延迟等待阈值的最优取值为从数据修复开始直到所有丢失原始块的条带修复完成的时长。

所述延迟等待阈值的取值为60分钟。

与现有技术相比，本发明具有以下优点：

(1)本发明在进行数据修复时对各条带的数据丢失状态进行分类，不同状态采用不同修复方式，达到保证数据可靠性的同时提高修复效率。

(2)本发明的修复过程延迟修复校验数据以优先修复原始数据，原始数据的修复任务排在校验数据的修复任务之前，减少降级读的次数，最终效果是减小数据修复对系统性能的负面影响。下面进行估算：分布式存储系统达到一定规模后可认为数据分布均匀。对EC(k,m)而言，在一块硬盘离线丢失的数据中，是原始数据，是校验数据。延迟校验数据的修复使得修复过程的后段不再有原始数据丢失，因此降级读次数减少以k＝6，m＝3为例，则降级读次数大约减少33％。

(3)避免短时间内硬盘陆续离线导致的重复修复，最终效果是数据修复占用的资源开销得以减小。以先后有2个硬盘离线为例进行说明。对EC(k,m)而言，先后分两次，每次修复1个块的总开销为2(k+1)个块，而一次性修复2个块的开销为k+2个块。设延迟等待阈值内发生2个硬盘离线的概率为f，则资源开销减小比例为假设k＝6，资源开销减小比例为43％*f。

附图说明

图1为纠删码的编码示意图；

图2为纠删码的解码示意图；

图3为纠删码条带在分布式系统中的分布图；

图4为本发明条带修复队列的示意图；

图5为本发明延迟校验块修复流程图。

具体实施方式

下面结合附图和具体实施例对本发明进行详细说明。本实施例以本发明技术方案为前提进行实施，给出了详细的实施方式和具体的操作过程，但本发明的保护范围不限于下述的实施例。

本发明提供一种分布式纠删码存储系统的数据修复方法，该方法对原始数据和校验数据的丢失情况进行区分，延迟修复校验数据以优先修复原始数据，同时出于数据可靠性的考虑，在达到一定条件时取消这种延迟。实际上，丢失的校验块从性能的角度来看，它们并不会被客户端直接访问，不会触发降级读，所以不影响性能；从资源消耗的角度来看，过早地修复它们并不划算。从数据可靠性的角度来看，纠删码策略可以容忍多个块丢失。

运用上述方法需要满足以下限制性条件：

A、条带直接保留原始数据。

说明：纠删码种类繁多，其中一种分类方法将纠删码分为系统码(systematic code)和非系统码(non-systematic code)。系统码直接保留原始数据，也是业界最常用的一类；非系统码不保留原始数据，它的条带中全部都是校验块。本发明区分原始块和校验块的修复，因此适用于系统码。

B、条带中的校验块个数m≥3。

说明：校验块的个数与条带的容错能力呈正相关。m为条带允许丢失的数据块上限。由于本发明延迟修复校验块，因此适用的纠删码必须保证有足够的容错能力。m≥3不仅在单块丢失的条件下仍有至少2的容错能力，也是目前业界绝大多数纠删码策略的取值范围。

上述方法遵循以下规则延迟修复校验块：

A、不延迟修复丢失块数量超过延迟容错阈值的条带。

说明：虽然纠删码策略容忍多个块丢失，但当第2个块丢失时存储系统已经处于脆弱状态。若继续延迟修复将降低数据可靠性。因此，本发明的延迟容错阈值为2，不可更改。当条带丢失第2个块时，不论丢失的是原始块还是校验块，都启动修复。

B、不延迟修复丢失单个原始块的条带。

说明：丢失的原始块被客户端直接访问，会触发降级读影响性能。

C、不延迟修复丢失单个校验块超过延迟等待阈值的条带。

说明：延迟修复校验块的用意是在第一时间让出更多资源来修复原始块。设置延迟等待阈值的用意是保证条带不能长时间处于数据丢失的状态。延迟等待阈值是一个经验值，最优的取值为从数据修复开始直到所有丢失原始块的条带修复完成的时长。大多数分布式存储系统能够花费大约一小时修复一个硬盘损坏导致的数据丢失，因此本发明将延迟等待阈值的默认值设定为60分钟。可以根据具体场景选取不同的取值。

以上规则确定的延迟修复作用范围：只对丢失单个校验块时长不超过延迟等待阈值的条带，实施延迟修复。

如图5所示，本实施例的分布式纠删码存储系统的数据修复方法，包括以下步骤：

1)获得更新后的条带修复队列，条带修复队列包括与各条带对应的条带记录，条带保留原始数据，且条带中校验块个数大于等于3。

存储系统感知到有数据丢失，将所有数据不完整的条带组成一个条带修复队列(简称修复队列)。修复队列中每个条带记录丢失数据的时刻与丢失的数据块集合。修复队列的形式如图4所示，图中，S_i表示条带i，T_i表示条带i的数据丢失时刻，D_i表示丢失第i个原始块，P_i表示丢失第i个校验块。图中的5个条带中，条带3、4各丢失1个校验块，可能被延迟修复。

当存储系统的拓扑结构变动时，数据的丢失状况会发生改变，需要对修复队列进行更新。例如，节点或硬盘离线将使得一部分单块丢失的条带降级为多块丢失，另有一些原本完整的条带降级为单块丢失。相反地，当原本离线的节点或硬盘重新上线，则条带丢失的数据块数目将减少。于是，记录数据丢失状态的修复队列随之更新，修复任务的调度也做出调整。

2)判断条带修复队列是否为空，若是，则执行步骤5)，若否，则执行步骤3)。

3)取出条带修复队列的第一个条带，根据与该条带对应的条带记录获取该条带的数据丢失状态。

4)根据数据丢失状态对条带进行相应修复处理，返回步骤1)，具体为：

401)根据数据丢失状态判断是否为多数据块丢失，若是，则执行步骤405)，若否，则执行步骤402)；

402)根据数据丢失状态判断是否为单个校验块丢失，若是，则执行步骤403)，若否，则执行步骤405)；

403)根据数据丢失状态判断数据丢失时长是否大于延迟等待阈值，若是，则执行步骤405)，若否，则执行步骤404)；

404)不进行条带修复，将当前获取的条带加入到条带修复队列的队尾，返回步骤1)；

405)对当前获取的条带进行修复处理，处理完成后返回步骤1)。

5)所有条带修复完成，退出。