CN104516778A - 一种多任务环境下进程检查点的保存与恢复系统及方法 - Google Patents
一种多任务环境下进程检查点的保存与恢复系统及方法 Download PDFInfo
- Publication number
- CN104516778A CN104516778A CN201410816453.1A CN201410816453A CN104516778A CN 104516778 A CN104516778 A CN 104516778A CN 201410816453 A CN201410816453 A CN 201410816453A CN 104516778 A CN104516778 A CN 104516778A
- Authority
- CN
- China
- Prior art keywords
- checkpoint
- module
- territory
- coordinator
- task
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Landscapes
- Retry When Errors Occur (AREA)
Abstract
本发明公开了一种多任务环境下进程检查点的保存与恢复系统及方法,系统包括:任务进程单元、协调者进程模块、通信监测模块、阻塞域模块、检查点模块和恢复线模块,协调者进程模块与通信监测模块相连,通信监测模块与阻塞域模块相连,构成一个循环;协调者进程模块分别通过检查点模块和恢复线模块连接至任务进程单元,或协调者进程模块直接连接至任务进程单元,任务进程单元与通信监测模块相连,进行多任务环境下进程检查点的保存与恢复。方法包括:A、检查点的形成,B、故障时的恢复。本发明解决了多米诺效应,活锁等问题,为一种局部阻塞一致性协议,该方法优化了传统阻塞式协议,提高了做检查点的效率,减少了开销,同时保证各进程状态一致。
Description
技术领域
本发明属于计算机科学与技术领域,涉及进程级的检查点容错技术,具体说是一种在多任务通信环境下对任务进程完成协调检查点的保存与恢复的系统及方法,较传统方法在性能上有提升。
背景技术
如今的计算机性能较以前有了大幅提升,然而即使这样,一些复杂的计算问题仍然需要运行几天甚至更长的时间。当一个任务需要执行很长的时间时,它在执行过程中失败的几率就会增加。尤其是在分布式系统,集群系统中,一个子任务的失败往往会给整个任务的正常运行带来较大影响,由此造成的代价也是巨大的。应用纯软件级的容错技术,在不修改操作系统的前提下,通过提供库文件或高可用性运行环境来实现高可靠性是一种常用的容错方法,其中重要的措施就是检查点设置与回卷回复(checkpoint and rollback recovery,CRR)技术。
检查点即是进程执行在某一时刻整个状态的一个快照,它保存了重启一个进程的所有信息。这种基于时间冗余的容错方法,是在应用程序正常运行的适当时刻设置检查点,记录进程的运行时状态和运行时环境,当检测到进程运行故障时,通过回滚到故障前保存的状态来恢复程序。
在对一组通信进程做检查点时,通常会出现很多问题,比如一致性问题,多米诺效应,活锁问题等。为了解决这些问题,传统的全局阻塞协议可以简单实现,保证检查点状态的一致性,然而它会带来较大的开销。如果不对进程阻塞,那么由于各进程自由做检查点,可能引起多米诺效应,也可能会产生很多无用检查点。而且,为了回滚,每个进程必须保存多个检查点,但是保存的检查点数量不能无限增加,所以就需要额外的某种垃圾回收机制来消除那些再也不会用到的检查点,回收资源。最后,恢复线的计算复杂,要基于依赖关系和图论的推导。其他的基于通信的检查点记录协议需要在进程发送的消息中附加额外信息,这又会增加进程间的通信量。
发明内容
针对上述协议的不足,本发明的目的是提供一种能够在保证检查点对用户透明的前提下,提高做检查点的效率,减少开销,同时保证各进程状态一致,解决多米诺效应,活锁等问题的检查点记录协议,即局部阻塞一致性协议,多任务环境下进程检查点的保存与恢复系统与方法。
为了实现上述目的,本发明的思路是基于传统的协调检查点实现协议来开发新的协议,提供一种多任务环境下进程检查点的保存与恢复系统,系统包括:
任务进程单元,每个单独执行的任务进程在各自运行过程中彼此间进行通信;
协调者进程模块,用于对整个任务的运行情况和故障发生的概率进行分析,由此作出决策;同时管理子协调者进程,与其一起通过消息控制,使每个单独执行的任务进程完成对自己做检查点的工作;
通信监测模块,用于对某一时间段内每个单独执行的任务进程是否进行通信进行监测,以此为基准来划分阻塞域;同时完成在非阻塞时强制任务进程做临时检查点和发生不一致时回滚到临时检查点或永久检查点,最后完成记日志的功能;
阻塞域模块,用于通过其数据结构记录阻塞域的划分情况;
检查点模块,用于完成对进程做检查点的操作;
恢复线模块,用于在有进程发生故障时,决策出一种满足一致性的回复状态,即一组检查点,供进程恢复;
所述协调者进程模块与通信监测模块相连,通信监测模块与阻塞域模块相连,构成一个循环;所述协调者进程模块分别通过检查点模块和恢复线模块连接至任务进程单元,或协调者进程模块直接连接至任务进程单元,任务进程单元与通信监测模块相连,进行多任务环境下进程检查点的保存与恢复。
进一步地,属于同一个阻塞域的任务进程一段时间内它们之间是有通信的,不属于同一个阻塞域的任务进程一段时间内它们是无通信的。
相应地,本发明给出了一种多任务环境下进程检查点的保存与恢复方法,包括下述步骤:
A、检查点的形成:
1)协调者进程模块启动,接受用户提交的任务,同时该模块创建出相应的任务进程单元开始执行任务;
2)协调者进程模块创建总协调者进程和多个监控进程,监控任务进程的退出状态和系统调用;
3)协调者进程模块创建出的总协调者进程设置倒计时器为下次做检查点的时间间隔;
4)协调者进程模块创建出的多个监控进程形成通信监测模块,通信监测模块监视任务进程单元,查看其是sendto调用还是recvfrom调用;
5)通信监测模块处理sendto系统调用,将源进程和目的进程放入同一阻塞域,同时记录日志和检查任务进程是否有标记通知;
6)通信监测模块处理recvfrom系统调用,将源进程和目的进程放入同一阻塞域,同时查询日志信息;
7)倒计时器到时,检查点模块启动,协调者进程模块创建子协调者进程开始对相应阻塞域中的任务进程做检查点;
8)子协调者进程使用全局阻塞协议,调用检查点模块对阻塞域中进程做全局一致检查点;
9)总协调者进程重新设置倒计时器,准备进行下一次的检查点设置;
10)阻塞域模块清空阻塞域,通信监控模块根据进程通信情况重新进行阻塞域的划分;
11)各个模块重新恢复运行;
B、故障时的恢复:
1)某个进程退出,协调者进程模块判断其退出状态;
2)异常退出则转步骤3),正常退出则转步骤7);
3)协调者进程模块中的总协调者进程向阻塞域模块请求当前阻塞域的划分列表;
4)总协调者进程在阻塞域划分列表中找出故障进程所在的阻塞域;
5)总协调者进程调用恢复线模块找出一条可用的恢复线,强制该域中所有进程回滚到恢复线所指的检查点状态;
6)域中进程恢复之后,各个进程接着运行;
7)任务正常结束;
8)各模块正常退出。
进一步地,所述步骤A-4)中,通信监测模块监视任务进程单元,按照下述步骤进行:
4a)通信监测模块监视任务进程单元,获取被监视进程的pid号,调用ptrace监视其系统调用;
4b)通信监测模块监视任务进程单元,截获被监视进程的系统调用号,查看其是否是sendto调用和recvfrom调用;
4c)如果是sendto调用,进行步骤5)操作;
4d)如果是recvfrom调用,进行步骤6)操作。
进一步地,所述步骤A-5)中,通信监测模块处理sendto系统调用,按照下述步骤进行:
5a)通信监测模块获得sendto的全部参数,找出消息发送的源进程和目的进程;
5b)通信监测模块将源进程和目的进程告知阻塞域模块,阻塞域模块开始进行阻塞域的划分:将源进程和目的进程放入同一阻塞域中,如果它们已经属于某一阻塞域则直接加入该域,否则开辟一个新域;
5c)通信监测模块记录一条消息发送日志;
5d)通信监测模块检查被监视的任务进程是否有标记通知,如果有转至步骤5e),如果没有,转至步骤5g);
5e)通信监测模块强制任务进程做一个临时检查点;
5f)通信监测模块清除任务进程的标记通知;
5g)通信监测模块重新回到监视状态。
进一步地,所述步骤A-6)中,通信监测模块处理recvfrom系统调用,按照下述步骤进行:
6a)通信监测模块获得recvfrom的全部参数,找出消息发送的源进程和目的进程;
6b)通信监测模块将源进程和目的进程告知阻塞域模块,阻塞域模块开始进行阻塞域的划分:将源进程和目的进程放入同一阻塞域中,如果已经属于某一阻塞域则直接加入该域,否则开辟一个新域;
6c)通信监测模块检查日志消息判断该消息是否已经发送,如果没有,则转6d),否则转6g);
6d)通信监测模块负责向消息发送者的监视进程发送一个标记通知;
6e)通信监测模块强制任务进程回滚到临时检查点状态,如果没有临时检查点则回滚到永久检查点状态;
6f)任务进程接着运行;
6g)通信监测模块重新回到监视状态,任务接着运行。
进一步地,所述步骤A-7)中,协调者进程模块创建子协调者进程,对相应阻塞域中的任务进程做检查点,按照下述步骤进行:
7a)协调者进程模块创建出的总协调者进程根据阻塞域模块划分的阻塞域创建相应多的子协调者进程;
7b)总协调者进程向每一个子协调者进程发送请求消息,请求做检查点;
7c)子协调者进程调用检查点模块对该域中的进程做检查点,转步骤8);
7d)子协调者完成检查点设置后,正常退出,域中任务接着运行;
7e)总协调者进程回收子协调者进程资源。
进一步地,所述步骤A-8)中,子协调者进程调用检查点模块对阻塞域中进程做全局一致检查点,按照下述步骤进行:
8a)子协调者进程向所有进程发送request消息;
8b)每个进程收到request消息后,停止当前工作,将所有通信信道中的消息清空;
8c)每个进程通过检查点模块开始对自己做临时检查点;
8d)完成检查点后,向子协调者进程发送ack消息,并开始阻塞等待;
8e)子协调者进程在收到每个进程发来的ack消息后,向每个进程发送commit消息;
8f)进程收到commit消息后,移除原有的永久检查点,将临时检查点设为永久检查点,恢复运行。
本发明较之传统的检查点记录协议具有以下优点:
1)本发明完成了一种进程级的容错方案,它是对多进程做系统级的一致检查点,不用修改用户程序,对用户是透明的。
2)本发明优化了传统阻塞式协议,使之在执行时不会产生那么大的开销,在效率上有提升。
3)本发明在决策恢复线时,避免了非阻塞协议恢复时以图论为基础来找恢复线的复杂性,也不用向阻塞式协议那样全部回退,等于同时减小了做检查点开销和恢复开销。
4)本发明中涉及的各个模块相对独立,各单元提供单独的服务,协同一致完成整个功能,如果想增加新的功能只需增加相应的功能模块即可,有一定的可扩展性。
附图说明
图1是系统结构图
图2是阻塞式协议过程图;
图3是局部阻塞式协议过程图;
图4是进程恢复线图;
图5是检查点决策流程图。
具体实施方式
下面结合附图及实施例对本发明做进一步详细说明。
如图1所示,本发明的多任务环境下进程检查点的保存与恢复整个系统包括以下组成部分,任务进程,协调者进程,通信监测模块,阻塞域模块,检查点模块,恢复线模块。
任务进程:一个大任务通常需要多个进程并行执行,这里的任务进程是指每个单独执行的任务进程,它们在各自运行过程中还需要彼此间进行必要的通信。
协调者进程:此任务进程主要用来对整个任务的运行情况和故障发生的概率进行分析,由此作出决策,即在某一时刻是否应该做检查点,同时管理子协调者进程,与其一起通过消息控制,使各个单独执行的任务进程完成对自己做检查点的工作。
通信监测模块:该模块主要用来对某一时间段内各个单独执行的任务进程是否进行通信进行监测,以此为基准来划分阻塞域,同时完成在非阻塞时强制任务进程做临时检查点和发生不一致时回滚到临时检查点或永久检查点,最后还要完成记日志的功能。
阻塞域模块:该模块的数据结构记录了阻塞域的划分情况,属于同一个阻塞域的任务进程一段时间内它们之间是有通信的,不属于同一个阻塞域的任务进程一段时间内它们是无通信的。
检查点模块:此模块主要完成对进程做检查点的操作。
恢复线模块:此模块是在有进程发生故障时,决策出一种满足一致性的回复状态,即一组检查点,供进程恢复。
其中,协调者进程模块与通信监测模块相连,通信监测模块与阻塞域模块相连,构成一个循环;所述协调者进程模块分别通过检查点模块和恢复线模块连接至任务进程单元,或协调者进程模块直接连接至任务进程单元,任务进程单元与通信监测模块相连,进行多任务环境下进程检查点的保存与恢复。
本发明多任务环境下进程检查点的保存与恢复方法,包括下述两步:
一、检查点的形成:
参照图2和图3,本部分的具体实现如下:
1)协调者进程模块启动,接受用户提交的任务,同时该模块创建出相应的任务进程单元开始执行任务。
2)协调者进程模块创建一个总协调者进程和多个监控进程,总协调者进程负责做检查点时的协调工作,监控进程则监视任务进程的退出状态和系统调用,同时进行后面阻塞域的划分。每个阻塞域可以看成是一个无通信的进程,这样在做检查点时,各个无通信进程可以自由记录检查点,而属于同一阻塞域的进程使用阻塞式协议来做检查点,这样一来,为做检查点而产生的阻塞开销会大大减小,从而达到优化的目的。
3)协调者进程模块创建出的总协调者进程设置倒计时器为下次做检查点的时间间隔。
4)协调者进程模块创建出的多个监控进程形成通信监测模块,通信监测模块中的监控进程通过ptrace监视任务进程单元,查看其是sendto调用还是recvfrom调用;具体操作如下:
4a)通信监测模块监视任务进程单元,获取被监视进程的pid号,调用ptrace监视其系统调用;
4b)通信监测模块监视任务进程单元,截获被监视进程的系统调用号,查看其是否是sendto调用和recvfrom调用;
4c)如果是sendto调用,进行步骤5)操作;
4d)如果是recvfrom调用,进行步骤6)操作。
5)通信监测模块处理sendto系统调用,将源进程和目的进程放入同一阻塞域,同时记录日志和检查任务进程是否有标记通知;具体操作如下:
5a)通信监测模块获得sendto的全部参数,找出消息发送的源进程和目的进程;
5b)通信监测模块将源进程和目的进程告知阻塞域模块,阻塞域模块开始进行阻塞域的划分:将源进程和目的进程放入同一阻塞域中,如果它们已经属于某一阻塞域则直接加入该域,否则开辟一个新域;
5c)通信监测模块记录一条消息发送日志;
5d)通信监测模块检查被监视的任务进程是否有标记通知,如果有转至步骤5e),如果没有,转至步骤5g);
5e)通信监测模块强制任务进程做一个临时检查点;
5f)通信监测模块清除任务进程的标记通知;
5g)通信监测模块重新回到监视状态。
6)通信监测模块处理recvfrom系统调用,将源进程和目的进程放入同一阻塞域,同时查询日志信息;具体操作如下:
6a)通信监测模块获得recvfrom的全部参数,找出消息发送的源进程和目的进程;
6b)通信监测模块将源进程和目的进程告知阻塞域模块,阻塞域模块开始进行阻塞域的划分:将源进程和目的进程放入同一阻塞域中,如果已经属于某一阻塞域则直接加入该域,否则开辟一个新域;
6c)通信监测模块检查日志消息判断该消息是否已经发送,如果没有,则转6d),否则转6g);
6d)通信监测模块负责向消息发送者的监视进程发送一个标记通知;
6e)通信监测模块强制任务进程回滚到临时检查点状态,如果没有临时检查点则回滚到永久检查点状态;
6f)任务进程接着运行;
6g)通信监测模块重新回到监视状态,任务接着运行。
图3给出的是一个阻塞域的划分过程。图中列出了n个进程,短线箭头指示它们之间的通信情况,在某一时间段内通信的进程将会被划分到同一阻塞域中,如虚线框所示。比如,在最开始,P1进程向P2进程发送了一条消息,P3进程向P2进程发送了一条消息,那么这三个进程将被划分到一个阻塞域,在做检查点时,该阻塞域中的进程需要全部阻塞,而不在该阻塞域中的进程不受影响。在做完一次检查点之后,将根据之后的通信情况对阻塞域重新划分。如图3所示给出了三个阻塞域的形成过程。
步骤5)和6)中对于sendto调用和recvfrom调用的处理是为了解决非阻塞时的不一致问题和活锁问题。ptrace所监视的进程在收到一条消息后,首先检查日志看该条消息是否已经发送,如果没有,那么该进程的ptrace进程会首先向消息的发送进程的ptrace进程发送一个标记通知,然后该进程回滚到其临时检查点状态,如果此时没有临时检查点,那么回滚到永久检查点状态,之后接着运行。同时,每一个ptrace所监视的进程在发送一条消息后会写日志,然后检查自己是否有收到过标记通知,如果有,那么强制进程做一个临时检查点,如果没有则放弃。直到下一次再由协调者进程发起做检查点的请求,再按照局部阻塞协议完成永久检查点的保存。
7)倒计时器到时,检查点模块启动,协调者进程模块根据阻塞域的划分情况创建多个子协调者进程开始对相应阻塞域中的任务进程做检查点;具体操作如下:
7a)协调者进程模块创建出的总协调者进程根据阻塞域模块划分的阻塞域创建相应多的子协调者进程;
7b)总协调者进程向每一个子协调者进程发送请求消息,请求做检查点;
7c)子协调者进程调用检查点模块对该域中的进程做检查点,转步骤8);
7d)子协调者完成检查点设置后,正常退出,域中任务接着运行;
7e)总协调者进程回收子协调者进程资源。
8)子协调者进程使用全局阻塞协议,调用检查点模块对阻塞域中进程做全局一致检查点;具体操作如下:
8a)子协调者进程向所有进程发送request消息;
8b)每个进程收到request消息后,停止当前工作,将所有通信信道中的消息清空;
8c)每个进程通过检查点模块开始对自己做临时检查点;
8d)完成检查点后,向子协调者进程发送ack消息,并开始阻塞等待;
8e)子协调者进程在收到每个进程发来的ack消息后,向每个进程发送commit消息;
8f)进程收到commit消息后,移除原有的永久检查点,将临时检查点设为永久检查点,恢复运行。
图2显示这个过程。其中每一条横向箭头实现代表一个进程随时间往下运行,第一个是协调者进程,其他是任务进程。进程间的箭头短线指示出消息的传递,某两个进程间有一条线,代表这一时刻一个进程向另一个进程发送了一条消息,箭头所指为接受消息的进程。阻塞式协议是一个2阶段的协议,一个协调者进程先做检查点,然后广播一条检查点请求消息request给其他所有的进程,要求他们做检查点。当一个进程收到此消息时,它将停止自己当前工作的执行,将所有通信信道中的消息清空,然后对自己做检查点,并发送一条ACK消息给检查点协调进程,如图中虚线所示,然后陷入阻塞等待。在协调进程收到所有进程的ACK消息后,它在广播一条commit消息来完成这个两段检查点协议,如图中点虚线。各个进程在收到commit消息之后,就将检查点存储在稳定介质中,覆盖原来的检查点,然后可以恢复原来的执行并与其他进程进行自由的消息交互。
另外考虑两种极端情况。第一,当进程之间无通信时,那么局部阻塞式协议变为非阻塞协议,各个进程按需自由记录检查点,达到最佳效果。第二,如果所有进程间都有通信导致所有进程属于同一个阻塞域,那么局部阻塞式协议退化为阻塞式协议,处理情况跟阻塞式一样,此时没有达到优化效果。为了进一步改善性能,阻塞域的划分并不是一成不变的。在对一个阻塞域做了检查点之后,该域取消,该域中的所有进程将被释放,将重新进行阻塞域的划分,显然这种动态的阻塞域划分更能根据实际和实时情况来最大可能的减少阻塞,提高性能。
9)总协调者进程重新设置倒计时器,准备进行下一次的检查点设置。
10)阻塞域模块清空阻塞域,通信监控模块根据进程通信情况重新进行阻塞域的划分。
11)各个模块重新恢复运行。
二、恢复线的形成:
结合图4,本部分的具体实现如下:
1)某个进程退出,协调者进程模块判断其退出状态。
2)异常退出则转步骤3),正常退出则转步骤7)。
3)协调者进程模块中的总协调者进程向阻塞域模块请求当前阻塞域的划分列表。
4)总协调者进程在阻塞域划分列表中找出故障进程所在的阻塞域。
5)总协调者进程调用恢复线模块找出一条可用的恢复线,强制该域中所有进程回滚到恢复线所指的状态。
图4给出了一种在某一进程异常终止时整个任务的回滚状况。假设某一时刻进程P2异常终止,那么根据协议,需要找出一条可用恢复线。因为此前p2进程曾向p3进程发送了一条消息,所以它们这时候肯定被划分在了一个阻塞域中,所以回滚时p2和p3需要同时回滚到上一个检查点记录的状态,如图中椭圆虚线圈即是一条可用的恢复线。如果不这么做,即只要p2恢复到上一个状态,那么此时显然会出现p2和p3状态的不一致,因为p2进程的状态显示它还没有发送消息给p3,可是p3的状态显示他已经收到了该消息。因此以恢复线作为任务回滚状态是有效的。
6)进程恢复之后,各个进程接着运行。
7)任务正常结束。
8)各模块正常退出。
三、系统执行流程:
图5给出了整个系统的一个流程模型图,按照此图整个系统运行可分为以下几个步骤:
步骤C1,用户提交任务,虚拟机分配任务资源,协调者进程模块启动,创建总协调者进程和任务进程,任务开始执行,倒计时器也开始工作,同时通信监测模块启动,对任务的运行状况和进程的运行状态实时跟踪。
步骤C2,记录第一个检查点。第一个检查点的时间按照任务的预计估计执行时间和初始故障概率来计算的。在这里使用局部阻塞协议记录检查点,即通过阻塞域模块得知当前阻塞域的划分情况,然后创建子协调者进程使用全局阻塞协议对各个阻塞域做全局一致检查点。一个完整检查点的记录时延包括三部分:检查点记录的准备阶段,主要是对需要同时阻塞的进程实施阻塞的等待时间;记录检查点,这时是真正保存进程上下文,进程内存地址空间等与进程运行环境密切相关的信息数据,并将这些数据写入外存;检查点记录结束阶段,此时是将阻塞的进程恢复至就绪状态,等待重新调度运行。
步骤C3,使用动态非等间距检查点间隔模型重新计算检查点间隔,记下一次记录检查点的时间,并重新设置倒计时器。在实际应用中,检查点时间间隔设置的过大或过小都必然会影响系统性能。如果设置系统按照一定周期来进行检查点操作会额外增加系统负载,当系统故障率较小时,应用的完成时间会因执行过于频繁的检查点操作而降低。而故障率较大时,较少的检查点操作则有可能导致应用不能进行下去。所以这里的检查点间隔模型使用动态非等间距检查点间隔模型。
步骤C4,任务在记录完检查点之后继续正常运行。此时通信监测模块负责在非阻塞的情况下,保证一致性。如果监测到一个进程出现了不一致的情况,即它收到了一条还没有发送的消息,则向该消息的发送进程发送标记通知,然后强迫该进程回滚到临时检查点,如果没有则回滚到永久检查点。通信监测模块在监测到进程发送一条消息后,如果它有通知标记,则先强迫该进程做一个临时检查点,然后写日志,在接着运行。
步骤C5,通信监测模块负责对下一次记录时间的检查,如果到了下一次记录时间,则转至步骤C2,否则转至步骤C6。
步骤C6,通信监测模块判断任务是否还在运行,即是看是否有进程退出。如果没有,则转至步骤C4,否则转至步骤C7。
步骤C7,通信监测模块查看退出进程的退出状态,如果所有进程的退出状态都正常,表明此任务正常结束,转至步骤C9,否则说明有进程异常退出,任务并没有执行完,此时就需要状态回滚,转至步骤C8。
步骤C8,异常时的状态回滚。此时通信监测模块分析调用恢复线模块找出一条可用的恢复线,使异常进程和其他同阻塞域进程恢复到恢复线所指的检查点状态。恢复的过程包括在外存上查找相应进程的检查点文件,如果该文件存储在异地,则还需要将该文件拷贝至虚拟机硬盘中;从硬盘中的文件恢复进程,即是将硬盘中保存的进程运行时环境数据重新加载入新进程的现场,恢复到保存的状态。完成此步骤后,转至步骤C4,继续任务的运行。
步骤C9,任务结束,系统退出。
四、理论对比分析
设检查点设置时间C由两部分组成,即正常的检查点设置时间τ和由于阻塞引起的时间δ,一个进程的整个执行过程中由于做检查点带来的开销记为Tov,那么
如果一个任务由m个进程共同执行完成,使用全局阻塞协议来做检查点,那么总的检查点开销Tw-ov应该为
很明显Tw-ov是随着m的增大而增大的。如果是非阻塞协议,那么
如果用局部阻塞协议,设某一时间段内涉及通信的进程数量为K的概率为P(Y=K),那么
其期望值为
如果P(Y=K)是等概率时间,那么
其第二部分刚好是由于阻塞而引起的额外开销。如果E(Y)=0,那么
退化为非阻塞协议,如果E(Y)=m,那么
退化为全局阻塞协议。
由此新的局部阻塞协议介于非阻塞协议和全局阻塞协议之间,能够在性能上有一定的提升。
Claims (8)
1.一种多任务环境下进程检查点的保存与恢复系统,其特征在于,系统包括:
任务进程单元,每个单独执行的任务进程在各自运行过程中彼此间进行通信;
协调者进程模块,用于对整个任务的运行情况和故障发生的概率进行分析,由此作出决策;同时管理子协调者进程,与其一起通过消息控制,使每个单独执行的任务进程完成对自己做检查点的工作;
通信监测模块,用于对某一时间段内每个单独执行的任务进程是否进行通信进行监测,以此为基准来划分阻塞域;同时完成在非阻塞时强制任务进程做临时检查点和发生不一致时回滚到临时检查点或永久检查点,最后完成记日志的功能;
阻塞域模块,用于通过其数据结构记录阻塞域的划分情况;
检查点模块,用于完成对进程做检查点的操作;
恢复线模块,用于在有进程发生故障时,决策出一种满足一致性的回复状态,即一组检查点,供进程恢复;
所述协调者进程模块与通信监测模块相连,通信监测模块与阻塞域模块相连,构成一个循环;所述协调者进程模块分别通过检查点模块和恢复线模块连接至任务进程单元,或协调者进程模块直接连接至任务进程单元,任务进程单元与通信监测模块相连,进行多任务环境下进程检查点的保存与恢复。
2.根据权利要求1所述的多任务环境下进程检查点的保存与恢复系统,其特征在于,属于同一个阻塞域的任务进程一段时间内它们之间是有通信的,不属于同一个阻塞域的任务进程一段时间内它们是无通信的。
3.一种多任务环境下进程检查点的保存与恢复方法,其特征在于,该方法步骤:
A、检查点的形成:
1)协调者进程模块启动,接受用户提交的任务,同时该模块创建出相应的任务进程单元开始执行任务;
2)协调者进程模块创建总协调者进程和多个监控进程,监控任务进程的退出状态和系统调用;
3)协调者进程模块创建出的总协调者进程设置倒计时器为下次做检查点的时间间隔;
4)协调者进程模块创建出的多个监控进程形成通信监测模块,通信监测模块监视任务进程单元,查看任务进程的系统调用是sendto调用还是recvfrom调用;
5)通信监测模块处理sendto系统调用,将发送消息源进程和目的进程放入同一阻塞域,同时记录日志和检查任务进程是否有标记通知;
6)通信监测模块处理recvfrom系统调用,将接收消息的源进程和目的进程放入同一阻塞域,同时查询日志信息;
7)倒计时器到时,检查点模块启动,协调者进程模块创建子协调者进程开始对相应阻塞域中的任务进程做检查点;
8)子协调者进程使用全局阻塞协议,调用检查点模块对阻塞域中进程做全局一致检查点;
9)总协调者进程重新设置倒计时器,准备进行下一次的检查点设置;
10)阻塞域模块清空阻塞域,通信监控模块根据进程通信情况重新进行阻塞域的划分;
11)各个模块重新恢复运行;
B、故障时的恢复:
1)某个进程退出,协调者进程模块判断其退出状态;
2)异常退出则转步骤3),正常退出则转步骤7);
3)协调者进程模块中的总协调者进程向阻塞域模块请求当前阻塞域的划分列表;
4)总协调者进程在阻塞域划分列表中找出故障进程所在的阻塞域;
5)总协调者进程调用恢复线模块找出一条可用的恢复线,强制该域中所有进程回滚到恢复线所指的检查点状态;
6)域中进程恢复之后,各个进程接着运行;
7)任务正常结束;
8)各模块正常退出。
4.根据权利要求3所述的多任务环境下进程检查点的保存与恢复方法,其特征在于,所述步骤A-4)中,通信监测模块监视任务进程单元,按照下述步骤进行:
4a)通信监测模块监视任务进程单元,获取被监视进程的pid号,调用ptrace监视其系统调用;
4b)通信监测模块监视任务进程单元,截获被监视进程的系统调用号,查看其是否是sendto调用和recvfrom调用;
4c)如果是sendto调用,进行步骤5)操作;
4d)如果是recvfrom调用,进行步骤6)操作。
5.根据权利要求3所述的多任务环境下进程检查点的保存与恢复方法,其特征在于,所述步骤A-5)中,通信监测模块处理sendto系统调用,按照下述步骤进行:
5a)通信监测模块获得sendto的全部参数,找出消息发送的源进程和目的进程;
5b)通信监测模块将源进程和目的进程告知阻塞域模块,阻塞域模块开始进行阻塞域的划分:将源进程和目的进程放入同一阻塞域中,如果它们已经属于某一阻塞域则直接加入该域,否则开辟一个新域;
5c)通信监测模块记录一条消息发送日志;
5d)通信监测模块检查被监视的任务进程是否有标记通知,如果有转至步骤5e),如果没有,转至步骤5g);
5e)通信监测模块强制任务进程做一个临时检查点;
5f)通信监测模块清除任务进程的标记通知;
5g)通信监测模块重新回到监视状态。
6.根据权利要求3所述的多任务环境下进程检查点的保存与恢复方法,其特征在于,所述步骤A-6)中,通信监测模块处理recvfrom系统调用,按照下述步骤进行:
6a)通信监测模块获得recvfrom的全部参数,找出消息发送的源进程和目的进程;
6b)通信监测模块将源进程和目的进程告知阻塞域模块,阻塞域模块开始进行阻塞域的划分:将源进程和目的进程放入同一阻塞域中,如果已经属于某一阻塞域则直接加入该域,否则开辟一个新域;
6c)通信监测模块检查日志消息判断该消息是否已经发送,如果没有,则转6d),否则转6g);
6d)通信监测模块负责向消息发送者的监视进程发送一个标记通知;
6e)通信监测模块强制任务进程回滚到临时检查点状态,如果没有临时检查点则回滚到永久检查点状态;
6f)任务进程接着运行;
6g)通信监测模块重新回到监视状态,任务接着运行。
7.根据权利要求3所述的多任务环境下进程检查点的保存与恢复方法,其特征在于,所述步骤A-7)中,协调者进程模块创建子协调者进程,对相应阻塞域中的任务进程做检查点,按照下述步骤进行:
7a)协调者进程模块创建出的总协调者进程根据阻塞域模块划分的阻塞域创建相应多的子协调者进程;
7b)总协调者进程向每一个子协调者进程发送请求消息,请求做检查点;
7c)子协调者进程调用检查点模块对该域中的进程做检查点,转步骤8);
7d)子协调者完成检查点设置后,正常退出,域中任务接着运行;
7e)总协调者进程回收子协调者进程资源。
8.根据权利要求3所述的多任务环境下进程检查点的保存与恢复方法,其特征在于,所述步骤A-8)中,子协调者进程调用检查点模块对阻塞域中进程做全局一致检查点,按照下述步骤进行:
8a)子协调者进程向所有进程发送request消息;
8b)每个进程收到request消息后,停止当前工作,将所有通信信道中的消息清空;
8c)每个进程通过检查点模块开始对自己做临时检查点;
8d)完成检查点后,向子协调者进程发送ack消息,并开始阻塞等待;
8e)子协调者进程在收到每个进程发来的ack消息后,向每个进程发送commit消息;
8f)进程收到commit消息后,移除原有的永久检查点,将临时检查点设为永久检查点,恢复运行。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201410816453.1A CN104516778B (zh) | 2014-12-24 | 2014-12-24 | 一种多任务环境下进程检查点的保存与恢复系统及方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201410816453.1A CN104516778B (zh) | 2014-12-24 | 2014-12-24 | 一种多任务环境下进程检查点的保存与恢复系统及方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN104516778A true CN104516778A (zh) | 2015-04-15 |
CN104516778B CN104516778B (zh) | 2017-09-01 |
Family
ID=52792134
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201410816453.1A Active CN104516778B (zh) | 2014-12-24 | 2014-12-24 | 一种多任务环境下进程检查点的保存与恢复系统及方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN104516778B (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110045691A (zh) * | 2019-03-13 | 2019-07-23 | 东北大学 | 一种多源异构大数据的多任务处理故障监测方法 |
CN111158920A (zh) * | 2019-12-06 | 2020-05-15 | 中山市奥珀金属制品有限公司 | 一种移动系统的进程数据读写优化方法及系统 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101986602A (zh) * | 2010-08-11 | 2011-03-16 | 山东大学 | 基于报文数目检验无阻塞检查点设置和故障进程恢复方法 |
US8826070B1 (en) * | 2008-12-15 | 2014-09-02 | Open Invention Network, Llc | Method and system for providing storage checkpointing to a group of independent computer applications |
US8881171B1 (en) * | 2008-12-15 | 2014-11-04 | Open Invention Network, Llc | Method and computer readable medium for providing checkpointing to windows application groups |
-
2014
- 2014-12-24 CN CN201410816453.1A patent/CN104516778B/zh active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8826070B1 (en) * | 2008-12-15 | 2014-09-02 | Open Invention Network, Llc | Method and system for providing storage checkpointing to a group of independent computer applications |
US8881171B1 (en) * | 2008-12-15 | 2014-11-04 | Open Invention Network, Llc | Method and computer readable medium for providing checkpointing to windows application groups |
CN101986602A (zh) * | 2010-08-11 | 2011-03-16 | 山东大学 | 基于报文数目检验无阻塞检查点设置和故障进程恢复方法 |
Non-Patent Citations (1)
Title |
---|
刘国良: ""分布式系统中回卷恢复技术研究"", 《万方数据库》 * |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110045691A (zh) * | 2019-03-13 | 2019-07-23 | 东北大学 | 一种多源异构大数据的多任务处理故障监测方法 |
CN110045691B (zh) * | 2019-03-13 | 2021-03-16 | 东北大学 | 一种多源异构大数据的多任务处理故障监测方法 |
CN111158920A (zh) * | 2019-12-06 | 2020-05-15 | 中山市奥珀金属制品有限公司 | 一种移动系统的进程数据读写优化方法及系统 |
CN111158920B (zh) * | 2019-12-06 | 2023-10-27 | 张杰辉 | 一种移动系统的进程数据读写优化方法及系统 |
Also Published As
Publication number | Publication date |
---|---|
CN104516778B (zh) | 2017-09-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8904361B2 (en) | Non-intrusive method for logging of internal events within an application process, and system implementing this method | |
Sathya et al. | Survey of fault tolerant techniques for grid | |
US20080307258A1 (en) | Distributed Job Manager Recovery | |
US8539434B2 (en) | Method for the management, logging or replay of the execution of an application process | |
Kalaiselvi et al. | A survey of checkpointing algorithms for parallel and distributed computers | |
CN109656742B (zh) | 一种节点异常处理方法、装置及存储介质 | |
US7568131B2 (en) | Non-intrusive method for logging external events related to an application process, and a system implementing said method | |
JPH10214199A (ja) | プロセスリスタート方法およびプロセスリスタートを実現するためのシステム | |
CN104767643A (zh) | 一种基于虚拟机的容灾备份系统 | |
CN1342280A (zh) | 用于被复制的服务器的协议 | |
US7840940B2 (en) | Semantic management method for logging or replaying non-deterministic operations within the execution of an application process | |
van Dongen et al. | A performance analysis of fault recovery in stream processing frameworks | |
US20020083116A1 (en) | Buffered coscheduling for parallel programming and enhanced fault tolerance | |
CN105589756A (zh) | 批处理集群系统以及方法 | |
US20100085871A1 (en) | Resource leak recovery in a multi-node computer system | |
CN104516778A (zh) | 一种多任务环境下进程检查点的保存与恢复系统及方法 | |
EP0701209B1 (en) | Apparatus and method for software rejuvenation | |
CN110287159B (zh) | 一种文件处理方法及装置 | |
US8537662B2 (en) | Global detection of resource leaks in a multi-node computer system | |
Dongarra et al. | Revisiting the double checkpointing algorithm | |
CN115391106A (zh) | 一种备端资源池化的方法、系统及装置 | |
CN105988885A (zh) | 基于补偿回滚的操作系统故障自恢复方法 | |
CN112286727B (zh) | 一种基于增量快照的时空隔离域快速恢复方法和系统 | |
Dongarra et al. | Performance and reliability trade-offs for the double checkpointing algorithm | |
Rathore et al. | Comparative analysis of checkpointing |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |