CN102411520B - 一种基于数据单元的地震数据的灾难恢复方法 - Google Patents

Abstract

本发明公开了一种基于数据单元的地震数据的灾难恢复方法。本发明的方法在检查点回卷恢复技术的基础上，针对地震数据的特点，结合数据单元的概念，通过对作业处理过程中的数据单元信息进行记录，并保存在检查点中，如果某个计算节点突然失效，导致该计算节点上的作业执行失败，本发明的方法通过检查点中记录的作业处理的数据单元信息，从检查点将故障前状态快速恢复到另一节点上，并且精确到每一个数据单元。采用本发明的方法，使得地震数据处理平台无需每次都从头执行故障节点上的作业，只需要根据记录，在上次运行的基础上，从下一个待处理的数据单元开始，继续进行下面的处理。

Description

一种基于数据单元的地震数据的灾难恢复方法

技术领域

本发明属于网络安全技术领域，特别涉及一种地震数据的灾难恢复方法。

背景技术

石油勘探行业的地震数据处理具有数据量大、计算密集、业务流程复杂等特点。面对地震数据这类的海量数据，并行处理是更优的选择，毕竟由于数据量大，处理流程复杂，如果采用串行处理一般情况下都需要几个月的时间，这显然是无法接受的。另一方面，如果采用超级计算机进行并行处理，尽管能够有效地提高并行处理的速度，但费用昂贵，而且针对不同的处理模块都必须事先编写好各自并行算法，甚至针对不同的机器，或者不同的版本都必须对函数进行重新编写，这同样是难以接受的。在地震数据处理平台上采用基于集群系统的并行处理框架，无论是性价比、系统鲁棒性、还是可扩展性方面，都具备无可比拟的优势。在集群系统中，灾难恢复是很重要的一个内容，随着集群规模的不断扩大和计算节点数量的不断增加，在计算过程中出现故障的几率也呈指数增长，这就为集群系统的灾难恢复提出了更高的要求。

在基于集群系统的地震数据处理平台中，服务器和各个地震作业运行于不同的计算节点上。由于地震数据量大，处理流程复杂，一旦某个计算节点出现故障导致作业执行失败，都会导致系统效率的下降和时间的浪费，特别是当系统中存在运行时间很长的大作业时，更是会给用户带来较大的损失，而且由于绝大多数地震作业的数据量都比较大，执行时间都比较长，在发生计算节点故障导致系统运行失败后，如果总是从头开始重新执行该作业，无疑将造成大量的时间上和计算上的浪费，甚至可能无法完成该作业。

基于集群系统的地震数据处理平台中的灾难恢复策略，目前主要以检查点回卷恢复技术为主。检查点回卷恢复技术是一种基于时间冗余的后向恢复容错技术，广泛应用于并行系统。

容错技术按恢复取向可分为两类：前向恢复技术和后向恢复技术。前向恢复技术是在系统故障后，根据故障系统的某些故障特征，来推导出系统未来可能出现的某一正确状态，然后将系统的状态恢复为这一状态。这种技术适合恢复系统外设的故障，但实现复杂。而后向恢复技术则是保存系统过去某一时刻的正确状态，然后在系统故障时，将系统状态卷回到这一状态。该方法恢复率高，但不适合外设故障，因为外设是不可卷回的。检查点回卷恢复技术正是一种典型的后向恢复技术，具体可分为如下两个步骤：

1、检查点设置：在系统正常运行的过程中，由程序员或操作系统指定，每隔一定的时间间隔设置检查点，保存系统当前的一致性状态，并对各进程间的消息进行记录。

2、卷回恢复：当系统发生故障之后，将系统状态卷回到最后一次保存的检查点的一致性状态，并从这一状态继续运行，而不是从程序开始处重新执行。

检查点回卷恢复技术可分为两大类：基于检查点的和基于消息记录的。前者是单独依赖检查点，而后者不仅依赖检查点，也依赖消息记录。其中，基于检查点的回卷恢复协议分为三类：独立检查点协议，协同检查点协议，通信-诱导检查点协议；基于消息记录的回卷恢复协议分为三类：悲观记录协议，乐观记录协议，因果记录协议。

作为并行系统中有效的一种容错方式，检查点回卷恢复技术是集群系统中容错的一种有效手段，能极大的提高集群系统的可用性和可靠性。但针对地震数据处理平台来说，现有的检查点回卷恢复技术还存在着以下的不足：

现有的检查点回卷恢复技术没有针对地震数据本身的特点，来进行状态的保存与恢复。具体来说，在地震数据处理平台中，若采用现有的检查点回卷恢复技术，地震作业将会以处理模块为单位来进行回卷恢复，因此可在处理模块这个层面上实现地震作业的恢复。然而，对于处理模块内部来说，由于尚未有针对地震数据的状态保存方法，检查点中将无法包含处理模块本身的状态信息，从而无法实现处理模块内部的回卷恢复，因此，故障发生后尚未处理完的各个处理模块都需要从头开始执行。这样无疑将造成大量的时间上和计算上的浪费，与检查点回卷恢复技术的初衷是相违背的。

发明内容

本发明的目的是为了解决在地震数据处理平台中现有的检查点回卷恢复技术存在的问题，提出了一种基于数据单元的地震数据的灾难恢复方法。

本发明的技术方案是：一种基于数据单元的地震数据的灾难恢复方法，包括如下步骤：

S1.在每一个计算节点上进行检查点的保存，检查点保存计算节点上的所有作业运行信息，作业运行信息以数据单元为基本单位进行记录；

S2.服务器对每一个计算节点进行故障检测；

S3.服务器检测出发生故障的计算节点后，从共享存储中读取该计算节点的检查点，将故障计算节点上的作业卷回恢复到重新分配的空闲节点上，再结合作业的配置信息决定作业的恢复策略以继续进行该作业的处理，所述的恢复策略具体为：该作业是从头开始执行还是从检查点开始执行。

进一步的，所述数据单元具体为道、道集、坡面、或者三维数据体本身。

进一步的，所述的从检查点开始执行具体为：所述的重新分配的空闲节点按照检查点与作业的配置信息计算出下一个待处理的数据单元的位置，从该位置开始继续进行作业的处理。

更进一步的，所述的计算出下一个待处理的数据单元的位置的具体过程为：若配置信息记录的作业每次执行时所需要的数据单元的个数是N，检查点记录的下一个待处理的数据单元的位置是M，则该作业被重新调度后将会从kN+1个数据单元处进行作业的处理，其中，kN＜(M-1)≤(k+1)N，k为整数。

本发明的有益效果：本发明的方法在检查点回卷恢复技术的基础上，针对地震数据自身的特点，结合数据单元的概念，通过对作业处理过程中的数据单元信息进行记录，并保存在检查点中，实现了基于数据单元的地震数据的灾难恢复。如果某个计算节点突然失效，导致该计算节点上的作业执行失败，本发明的方法通过检查点中记录的作业处理的数据单元信息，从检查点将故障前状态快速恢复到另一节点上，并且精确到每一个数据单元。采用本发明的方法，使得地震数据处理平台无需每次都从头执行故障节点上的作业，只需要根据记录，在上次运行的基础上，从下一个待处理的数据单元开始，继续进行下面的处理。

附图说明

图1是地震数据处理平台的集群系统示意图。

图2是数据可分割作业的处理模块流程示意图。

图3是计算节点上地震作业的处理流程示意图。

图4是数据可分割作业的执行流程示意图。

图5是采用本发明方法的地震数据处理平台的服务器流程示意图。

图6是采用本发明方法的地震数据处理平台的计算节点流程示意图。

图7是采用本发明方法的地震数据处理平台的灾难恢复整体流程示意图。

具体实施方式

下面结合附图和具体的实施例对本发明的方法作进一步的阐述。

为了便于对本发明的理解，首先对数据单元、地震数据处理平台、地震作业处理流程进行说明：

地震数据有一个重要的特点，即其数据本身是非耦合的，数据之间的独立性很强，可将其细化为由各类相似的数据单元作为基本单元的非耦合数据。对于不同的地震数据来说，数据单元是存在差异的，可以是道，也可以是道集，或者坡面，甚至三维数据体本身。这里先对道及道集的概念进行一点说明：道是地震数据的基本单位，一道地震数据的大小与采样时间长度及采样间隔有关，其容量一般从几KB到几十KB不等；而道集是指具有某一共同属性的道的集合，这些属性包括共炮点、共中心点、共接收点等，通常情况下，一个道集包含了几十道到几千道数据不等。

数据单元：地震数据的基本数据单元。对于各类地震数据来说，数据单元是存在差异的，可以是道，也可以是道集，或者坡面，甚至三维数据体本身。

子作业：具体特指数据可分割作业的一个处理模块。一个数据可分割作业可看作由多个子作业组合而成的。一个作业是否需要划分为若干个子作业，具体如何进行划分，应由用户事先确定声明，并在用户创建作业的过程中赋予相关参数信息。

这里，地震数据处理平台采用基于集群系统的并行处理框架，具体采用了客户端-服务器模型，该处理平台的系统总体框架图如图1所示，包括客户端、服务器、计算节点与共享存储，各部分实现的功能如下：

1.客户端(Client Node)：与用户的交互；地震作业的创建、编辑与提交；监控作业运行状态，计算节点状态等。

2.服务器(Server Node)：统一组织与管理集群中的各类对象实体，例如作业、队列、节点、用户信息等；接收并处理客户端发送的请求；收集并统计各计算节点的可用资源信息；根据用户选择的作业调度策略，进行作业调度。

3.计算节点(Compute Node)：接收并执行服务器调度至当前节点的作业；收集计算节点当前可用资源状态信息，如CPU利用率、内存信息、可用磁盘空间等，供服务器和客户端查看；定时备份计算节点的执行信息；定时向服务器发送心跳包。

4.共享存储(Shared Storage)：共享文件系统，存储服务器与计算节点的数据和执行信息。本集群系统的硬件设备采用了基于NFS协议的磁盘阵列文件系统，所有计算节点均可透明高速地对磁盘阵列上的数据文件进行访问。

地震作业处理流程：用户通过客户端向地震数据处理平台提交作业，请求服务。这里，在基于集群系统的地震数据处理平台中，用户提交的地震作业可分为两大类，普通作业和数据可分割作业。在作业提交前，用户将对这两类作业提交方式进行选择。

数据可分割作业是由一组存在依赖关系的功能模块组成的，各模块共同来完成一个特定的处理任务，其中每个功能模块中都包含着完成该模块功能所需要的参数信息。用户在创建数据可分割作业的过程中，给出作业内部各处理模块的拓扑关系，也就是业务处理流程逻辑，并赋予相关参数信息。

图2是数据可分割作业的处理模块流程图的一个示例，说明数据可分割作业的业务处理流程逻辑。

各处理模块之间的数据依赖关系可分为三种情况：线性、分支并发、分支聚合。线性连接的模块根据数据流线性驱动，如模块1、模块3与模块8之间的线性连接。分支并发连接的模块并发驱动分支关联的模块(这些关联模块所需的输入数据相同，彼此不相关，可进行并行处理)，如模块1的输出可并发驱动模块2-4，模块2-4具有相同的输入，并行处理，当模块1尚未执行完毕时，模块2-4都处于等待状态，无法进一步执行后面的流程。而分支聚合连接的模块只有等到分支的数据流都完成时才会驱动聚合的模块进行处理，如只有当模块5-7都执行完毕后，模块8才会进行后面的处理。

服务器接受到来自客户端的作业，加入作业队列，等待作业调度进程的调度。作业调度进程把作业分配到计算节点，节点首先对这些作业进行语义解析。图3是计算节点上作业的处理流程图。对于普通作业，计算节点对数据进行分析，按普通作业类型调用执行函数启动作业执行进程。对于数据可分割作业，先进行消息解析，根据该作业的参数信息，构建数据工作流，建立业务处理流程逻辑。节点将作业的每一个处理模块都看作是一个普通作业，或者说子作业，整个作业的处理流程可看作由这些子作业组合而成的。对于分配到各子计算节点的子作业，将按普通作业类型调用执行函数启动作业执行进程。

在基于集群系统的地震数据处理平台中，数据可分割作业将以主从节点的形式进行处理。如图4所示，计算节点上数据可分割作业的执行流程大致如下：

1.作业调度进程把数据可分割作业发送给主计算节点，同时也把所有空闲的计算节点IP都发送给主计算节点。

2.主计算节点启动主执行控制进程，对数据进行分析，按照作业中描述的分割策略，计算子作业数和每个子作业计算的数据范围，并对作业文件进行分割。

3.主计算节点从作业调度进程发送的空闲节点中选择一些节点用于运行子执行控制系统，并把选中的节点发送给作业调度服务器。

4.子计算节点接收请求后，启动子执行控制进程，从主计算节点读取数据，并把计算结果发回主计算节点。

5.主计算节点把收到的子计算节点的数据进行合并，并向服务器反馈任务运行完成状态。

本发明的基于数据单元的地震数据的灾难恢复方法，具体包括如下步骤：

S1.在每一个计算节点上进行检查点的保存，检查点保存计算节点上的所有作业运行信息，作业运行信息以数据单元为基本单位进行记录；

S2.服务器对每一个计算节点进行故障检测；

S3.服务器检测出发生故障的计算节点后，从共享存储中读取该计算节点的检查点，将故障计算节点上的作业卷回恢复到重新分配的空闲节点上，再结合作业的配置信息决定作业的恢复策略以继续进行该作业的处理，所述的恢复策略具体为：该作业是从头开始执行还是从检查点开始执行。

这里的计算节点可以是主计算节点，也可以是子计算节点。主计算节点对应的是作业，而子计算节点对应的是子作业。

如上述所述，这里数据单元具体为道、道集、坡面、或者三维数据体本身。

这里的从检查点开始执行具体为：所述的重新分配的空闲节点按照检查点与作业的配置信息计算出下一个待处理的数据单元的位置，从该位置开始继续进行作业的处理。

更进一步的，所述的计算的具体过程为：若配置信息记录的作业每次执行时所需要的数据单元的个数是N，检查点记录的下一个待处理的数据单元的位置是M，则该作业被重新调度后将会从kN+1个数据单元处进行作业的处理，其中，kN＜(M-1)≤(k+1)N，k为整数。

下面进行具体阐述。

对于地震作业来说，系统的容错机制是非常重要的，是作业能否有效地成功执行的关键。当某个计算节点发生故障，节点上的作业运行失败时，不仅需对当前失效节点上的任务进行恢复，而且还需要在上次运行的基础上，继续执行后面的工作，而不是从头开始执行。为了实现这个目的，设置检查点，保存与恢复进程的状态显得尤其重要。

图5与图6给出了采用本发明方法的地震数据处理平台的服务器与计算节点的处理流程图。图7为采用本发明方法的地震数据处理平台的灾难恢复整体流程示意图。

本发明的方法为地震作业保存自身状态以防止计算节点故障提供了便利，如果一个计算节点突然失效，它可以从检查点将故障前状态快速恢复到另一节点上，并且精确到每一个数据单元，从而有效提高了系统的鲁棒性与可用性，提高系统的效率，减少了不必要的时间和资源上的浪费。

在地震数据处理平台的灾备策略中引入了数据单元的概念，在检查点的保存与卷回恢复过程中以数据单元为核心进行灾难恢复。

以主从节点的形式对地震作业进行处理，并根据不同的策略对地震作业进行分割，将分割后的功能模块作为子作业进行处理。即对主计算节点上的可分割作业进行分割，使得一个作业变成若干个子作业，并将各个子作业分配到各个子计算节点。

通过设置不同的作业灾备策略，灵活适应不同的灾备需求，实现了一般灾难恢复与基于数据单元的灾难恢复间的并存。

基于卷回恢复的需要，检查点中记录了如下参数：作业灾备策略、运算数据的数据单元类型、下一个待处理的数据单元序号等。在故障恢复的过程中，当作业或子作业被重新调度到某新的节点上开始执行时，通过事先写好的一个函数接口，生成配置信息，该配置信息中维护的信息包括了该作业或子作业是否需要从头开始执行，运算数据的数据单元类型，每次执行时所需的数据单元的个数等。

在步骤S1中，每一个计算节点，周期性地提取当前节点的运行进程映像，并将其保存到共享存储中形成检查点文件。共享存储对各个计算节点的检查点文件进行维护。一旦某个计算节点发生故障，服务器将从共享存储中读取检查点，并将之卷回恢复到另一节点上。

检查点保存的进程状态信息中主要包含有以下参数：执行进程名、作业ID、作业文件名、作业文件路径、作业类型、分割策略、分割后的数据单元起止序号列表、子作业节点个数、子作业节点IP、Port列表、数据分割参数(子作业序号、运算数据的数据单元起止序号、主计算节点IP、主计算节点Port)、读模块的输入数据文件路径、写模块的输出数据文件路径等。另外，基于数据单元的灾难恢复，还需要记录如下参数：作业灾备策略、运算数据的数据单元类型、下一个待处理的数据单元序号等。

地震数据的一个重要特点就是非耦合性，数据之间的独立性很强。地震数据以数据单元作为基本单元，对于灾难恢复来说，记录当前处理的作业中已经处理的数据单元的序号具有重要的意义。一旦某个地震作业或者子作业运行失败，无需从头执行该作业，只需要根据记录，在上次运行的基础上，从下一个待处理的数据单元开始，继续进行下面的处理。这就避免了工作时间的浪费，提升了大规模地震作业处理的效率。

对于不同的地震作业，数据单元是不一样的。绝大多数地震作业都是以道，或者道集作为基本单位的，节点处理完每一道或道集后，在将计算结果写入输出文件和与主计算节点进行通信的同时，还将保存新的检查点，以便保证节点状态与灾备信息的同步。对于以坡面为基本单位的地震作业，也采取类似的处理。但对于以三维数据体本身为单位的地震作业，由于粒度很大，若采用基于数据单元的检查点策略，将带来极大的资源的浪费。在实际应用中，这类作业发生故障后从头开始执行的效率其实也是差不多的，故对于这种情况将单独进行处理。

对于不同的处理模块来说，由于其对地震数据进行的处理各不相同，故各模块中的数据单元的大小可能会有差异。但在同一个处理模块之中，数据单元的大小是一致的。

在步骤S2中，具体采用心跳机制来进行计算节点的故障检测。系统通过计算节点周期性地向服务器发送心跳包，来检测计算节点的工作状态。

服务器维护着一个节点列表，该列表中主要包含了以下信息：计算节点ID、计算节点IP、计算节点端口号、计算节点状态、计算节点最后心跳包时间等。其中，计算节点状态为可用或不可用，计算节点最后心跳包时间为服务器最后一次收到来自该计算节点的心跳包的时间。

服务器中有一个心跳监控进程，负责接收来自各个计算节点的心跳包。服务器启动后，心跳监控进程开始运行，同时，服务器读取共享存储上的计算节点配置文件进行节点列表的初始化，其中，节点状态设置为不可用，节点最后心跳包时间设置为空。

计算节点启动后，将向服务器发送心跳包，以在服务器上进行节点注册。服务器收到来自节点的心跳包后，对节点列表中的相应表项进行更新。同时，向未注册节点发送注册确认消息。计算节点上设置有心跳时间间隔，节点初始化之后，将每隔一个心跳间隔向服务器发送心跳包。服务器收到心跳包后，更新该节点的节点最后心跳包时间。此处为了减少服务器的负荷，采用了节点主动发送心跳包，而不是服务器主动发送的形式。

服务器上设置有心跳超时值。服务器会定时对节点列表进行检测，若检测到某个节点的最后心跳包时间已超过心跳超时值，则报告心跳超时，服务器将主动向该节点发送请求，并等待回复，以便确认节点是否已经真的死掉。若超过事先设定的最大等待时间，服务器仍未收到来自该节点的消息，则认为该节点已经死掉。服务器更新节点列表，将节点列表中的该节点状态设置为不可用，节点最后心跳包时间设置为空。

在步骤S3中，服务器检测出发生故障的节点后，将从共享存储中快速读取该节点的检查点，将故障节点状态卷回恢复到重新分配的空闲节点上。

本发明的方法还对不同的地震作业设置了不同的作业灾备策略。在实际的处理中，并非所有的作业都支持基于数据单元的灾难恢复，部分作业在执行失败后，需要从头开始执行，而无法在上次运行的基础上继续后面的处理，比如以三维数据体为单位的地震作业。为了对各类不同的情况进行分别的处理，当作业被分配到某一计算节点上执行时，这里可以通过事先写好的函数接口，首先生成一个配置文件，即配置信息，包含有作业灾备策略、运算数据的数据单元类型等基本信息，计算节点将结合配置信息中的信息进行相应的处理。

基于卷回恢复的需要，检查点中记录了如下参数：作业灾备策略、运算数据的数据单元类型、下一个待处理的数据单元序号等。

配置信息与检查点中记录的节点运行状态信息共同决定了灾难恢复的策略。假如配置信息中维护的信息显示该作业或子作业需要从头开始执行，则不管之前这个作业或子作业已经执行了多少数据，在重新调度到新的节点上后都将会从头开始执行，而不会在上次运行的基础上继续进行下面的处理。否则，新节点都将按照检查点，严格的卷回恢复故障节点的状态，从而保证在新的节点上，这些作业或子作业依然会在上次运行的基础上，从下一个待处理的数据单元开始，继续进行下面的处理。

配置信息还包括了该作业或子作业每次执行时所需的数据单元的个数。若配置信息记录的作业每次执行时所需要的数据单元的个数是N，检查点记录的下一个待处理的数据单元的位置是M，则该作业被重新调度后将会从kN+1个数据单元处进行作业的处理，其中，kN＜(M-1)≤(k+1)N，k为整数。而对于kN与M之间的那些数据，即使上次运行的时候已经执行过了，仍将会重新执行。

通过配置信息可以适应不同的情况的需要，避免出现无论什么情况都重新执行整个作业或子作业的情形，可以尽可能高效地利用之前的节点的工作成果，提高资源的利用率和作业的整体执行效率。

可以看出，本发明的方法针对地震数据自身的特点，结合数据单元的概念，通过对作业处理中的数据单元信息进行记录，并保存在检查点中，在检查点回卷恢复技术的基础上，实现了基于数据单元的地震数据的灾难恢复。在检查点中对作业处理的数据单元信息进行记录，那么一旦某个计算节点发生故障，导致该计算节点上的作业执行失败后，无需每次都从头执行该作业，只需要根据记录，在上次运行的基础上，从下一个待处理的数据单元开始，继续进行下面的处理。如果一个计算节点突然失效，本发明的方法可以从检查点将故障前状态快速恢复到另一节点上，并且精确到每一个数据单元，从而有效提高了系统的鲁棒性与可用性，极大地提高了系统的效率，减少了不必要的时间和资源上的浪费，具有良好的可用性和可扩展性。

Claims (2)

1.一种基于数据单元的地震数据的灾难恢复方法，其特征在于，包括如下步骤：

S1.在每一个计算节点上进行检查点的保存，检查点保存计算节点上的所有作业运行信息，作业运行信息以数据单元为基本单位进行记录；

S2.服务器对每一个计算节点进行故障检测；

S3.服务器检测出发生故障的计算节点后，从共享存储中读取该计算节点的检查点，将故障计算节点上的作业卷回恢复到重新分配的空闲节点上，再结合作业的配置信息决定作业的恢复策略以继续进行该作业的处理，所述的恢复策略具体为：该作业是从头开始执行还是从检查点开始执行；

所述的从检查点开始执行具体为：所述的重新分配的空闲节点按照检查点与作业的配置信息计算出下一个待处理的数据单元的位置，从该位置开始继续进行作业的处理；

所述的计算出下一个待处理的数据单元的位置的具体过程为：若配置信息记录的作业每次执行时所需要的数据单元的个数是N，检查点记录的下一个待处理的数据单元的位置是M，则该作业被重新调度后将会从kN+1个数据单元处进行作业的处理，其中，kN<(M-1)≤(k+1)N，k为整数。

2.根据权利要求1所述的灾难恢复方法，其特征在于，步骤S1所述的数据单元具体为道、道集、坡面、或者三维数据体本身。

Images