CN101369241A - 一种机群容错***、装置及方法 - Google Patents

Abstract

本发明公开了一种机群容错***、装置及方法。该***包括远程检查点服务器，用于响应来自故障结点的远程检查点请求，执行检查点操作；结点故障检测模块，用于监测本地结点的操作***和指定进程的运行状态，触发远程检查点；通信***检查点模块，用于实现通信设备的检查点，并支持通信断点恢复功能。其为并行处理的机群提供局部化的快速故障恢复，具有较低的开销和良好的可扩展性，使得百万、千万亿次规模的机群***能够具有理想的可用性。

Description

一种机群容错***、装置及方法

技术领域

本发明涉及计算机并行处理容错技术领域，特别是涉及一种并行处理的机群容错***、装置及方法。

背景技术

以机群为代表的计算机并行处理技术在现代社会中的应用已经达到了相当可观的广度和深度。作为社会信息化基础设施的重要组成部分，机群***中的并行处理的可靠性问题已经对经济和社会产生影响。目前，随着机群***规模的不断扩展和复杂性的逐渐提高，其并行处理的可靠性呈现下降趋势的现象已经引起了学术界和工业界的广泛关注，机群并行处理的容错技术的理论研究及其工程应用的需求日益迫切。

机群是以网络互连并能协同工作的多个独立的计算机(称为机群的结点)构成的并行计算机***。

故障、错误和失效是容错计算领域最基本的概念，是理解容错技术的基础。简而言之，失效是指一个***偏离其正确服务这一事件，错误是指一个***的全部状态中可能导致其后续的失效的部分，故障则是一个错误的原因。故障可能来源于一个***的内部或者外部。如果一个故障已经导致了错误，就是处于激活(Active)状态，否则就是处于休眠(Dormant)状态。

错误可以通过报错消息或者报错信号而被检测出来，已经产生但尚未被检测到的错误称为潜伏(Latent)错误。一个错误可以通过计算过程而不断变化或者在***模块之间传播，这一过程称为错误迁移(Error Propagation)。

目前，对于计算机***中的软硬件故障主要有四种处理方法：

故障避免(Fault Prevention)：提前避免故障的出现；

故障容许(Fault Tolerance)：在故障出现之后避免其导致服务失效；

故障消除(Fault Removal)：减少故障的数量及其危害；

故障预报(Fault Forecasting)：预估故障的当前数量、未来的发生率以及后果。

广义的容错技术可以涵盖故障、错误和失效的各种处理方法。

故障容许一般是通过错误检测(Error Detection)和***恢复而实现，其中后者根据其处理对象可以划分为基于故障处理和基于错误处理这两种类型。

根据故障、错误和失效的相互关系，错误处理是避免服务失效的关键环节。现有的错误处理技术主要分为卷回(Rollback)、前滚(Rollforward)和补偿(Compensation)三种策略。卷回恢复是在无法确定和排除错误原因的情况下，将***状态恢复到一个预先保存的正确状态重新运行，以期错误不再发生。前滚恢复则通常基于N模冗余而实现，当通过定期的状态比较(N＝2)或者表决(N≥3)发现错误之后，所有冗余模块继续运行，只利用空闲单元重新运行上一周期的计算过程，并根据其结果判定并剔除错误的冗余模块的状态。卷回恢复主要是基于时间冗余，而前滚恢复则需要依赖于硬件冗余。在这两种策略中，前者的应用更为广泛。常见的进程检查点和卷回恢复就是一种典型的卷回错误处理技术。

故障可以在任何一个***层次被引入。相应地，不同的***层次就需要有与之对应的容错机制。同时，任何容错机制都对其所能处理的故障或者错误有一定的假设，比如故障类型、故障频率等因素，因此对于不同的故障类型，往往存在不同的容错方法。于是，一个实际的计算机***中的失效处理常常需要综合运用多种容错技术，并分为多个步骤或者层次进行处理。计算机的错误处理中常用的十个步骤，依次是故障抑制(Fault Containment)、故障检测(FaultDetection)、故障屏蔽(Fault Masking)、重试(Retry)、诊断(Diagnosis)、重配置(Reconfiguration)、恢复(Recovery)、重启动(Restart)、修复(Repair)和重新整合(Reintegration)。

经典的容错技术包括硬件方面的三模冗余(Triple Modular Redundancy，缩写TMR)和多模冗余(N-tuple Modular Redundancy，缩写为NMR)和软件方面的恢复块(Recovery Blocks)、多版本程序设计(N-Version Programming)、算法容错(Algorithm-Based Fault-Tolerance，ABFT)、软件自检等方法，以及软件老化和再生技术、面向恢复的计算(Recovery-Oriented Computing，ROC)，失效忽略计算(Failure-Oblivious Computing)等技术。

机群设计中传统的挑战是线性加速比问题。在计算粒度基本不变的情况下，当结点数增加到一定程度之后，机群的整体性能不但无法达到线性加速比，甚至会不升反降。将机群结点的可靠性问题考虑进去，并且假设每个机群结点的可靠性并不理想，那么，随着所用结点数量的增长，不得不担心的将不再是***性能是否可以保持线性增长，而是指定规模的一个计算任务能否无故障地顺利完成。

机群体系结构中内在的冗余性解决了一部分机群容错的问题。但是，机群容错面临更多的挑战。首先，当机群***的规模不断扩大的时候，按照统计规律，整个***的可靠性将不可避免地下降。第二，机群结点之间的并行性使得完整地获取和恢复应用的状态更加困难。进程间通信的存在使并行应用中各进程的状态之间存在着复杂的先后依赖关系，对任何单一故障的处理都需要考虑全局状态的可恢复性。

提高机群***的可用性有两种途径：一是继续提高单个结点的可靠性，从而使***整体的可靠性相应地提高。但鉴于机群***一般采用COTS部件，这一方法所受的限制较多。另一途径是，着眼于***整体的可用性，使***在单一结点出现的故障能够得到局部化(时间、空间)的恢复处理。在机群容错领域常用的定期全局检查点技术可以称为“时间局部化”机群容错技术。该技术将连续运行的机群***从时间上分割为较短的单元，即传统的检查点间隔(Checkpoint Interval)。通过在每个时间单元的开始时刻记录***状态，使得在每个时间单元之内发生的故障仅能破坏整个机群***在该时间单元内的计算结果。该技术已经被实践证明是极为有效的机群容错策略之一，但是该技术没有实现机群故障处理的空间局部性，其开销与***规模直接相关。可以说，在每个检查点间隔的结束时刻为一个机群并行应用中的所有进程都执行检查点操作有过度冗余(Aggressive Redundancy)的倾向。随着机群计算规模的不断扩大，全局检查点的弊端逐渐变得明显，机群容错机制亟待向轻量级的方向发展。

发明内容

本发明所要解决的问题在于提供一种机群容错***、装置及方法，其为并行处理的机群提供局部化的快速故障恢复，具有较低的开销和良好的可扩展性，使得百万、千万亿次规模的机群***能够具有理想的可用性。

为实现本发明目的而提供的一种机群容错***，包括如下功能模块：

远程检查点服务器，用于响应来自故障结点的远程检查点请求，执行检查点操作；

结点故障检测模块，用于监测本地结点的操作***和指定进程的运行状态，触发远程检查点；

通信***检查点模块，用于实现通信设备的检查点，并支持通信断点恢复功能。

所述的机群容错***，还包括下列功能模块：

并行应用进程管理器，用于为故障时检查点***提供被监测应用的进程信息，并管理进程恢复过程；

检查点文件服务器，用于存储检查点文件，并在故障时检查点的恢复过程中提供检查点文件访问支持。

一种机群容错处理方法，包括下列步骤：

步骤A1.应用注册；

步骤B1.远程检查点切取；

步骤C1.进程恢复。

所述的机群容错处理方法，所述步骤A1之后，步骤B1之前，还包括下列步骤：

步骤S1.结点监测；

步骤S2.故障报告；

一种远程检查点切取***，包括：

内核符号寻址模块，用于对目标进程所在结点的操作***的内核符号的寻址；

数据缓存模块，用于数据的缓存和预取；

指针模块，用于指针操作。

一种远程检查点切取方法，包括下列步骤：

步骤S10，加载目标结点的操作***符号表；

步骤S20，加载目标结点的操作***核心类型表；

步骤S30，根据目标进程号查找目标进程的进程控制块，并复制到本地缓冲区中；

步骤S40，创建远程检查点映像的文件头；

步骤S50，保存根目录和当前工作目录的完整路径；

步骤S60，保存目标进程的文件描述符表；

步骤S70，逐一保存目标进程已打开文件的基本信息；

步骤S80，为远程检查点映像文件加入末尾标记。

一种远程检查点恢复***，包括：

状态区分模块，用于区分目标进程的状态，以避免对RCX等寄存器的误用；

跳板模块，用于恢复完整的通用寄存器状态，使进程都以IRET指令退出核心态，从核心空间返回用户空间。

一种远程检查点恢复方法，包括如下步骤：

步骤S10′，检查点恢复工具创建一个子进程，并开始等待其执行完成或异常退出；

步骤S20′，根据检查点文件的头部信息判断其合法性；如果头部信息中标明的操作***不符合预期，则退出；否则，进入下一步骤；

步骤S30′，重新设置目标进程的基本属性；

步骤S40′，恢复目标进程核心栈中的CPU状态部分；

步骤S50′，恢复目标进程中信号处理的相关信息；

步骤S60′，解除宿主进程的所有虚拟存储区域的映射；

步骤S70′，加载目标进程的所有虚拟存储区域的映射；

步骤S80′，设置目标进程的虚拟地址空间描述信息；

步骤S90′，恢复目标进程的根目录和当前工作目录的路径；

步骤S100′，关闭宿主进程的各个文件；

步骤S110′，逐一恢复目标进程已打开文件的基本信息；

步骤S120′，设置目标进程的状态为可运行，使其退出远程检查点恢复过程之后可以被正常地调度执行。

一种通信***的检查点切取方法，包括下列步骤：

步骤S100，读取通信设备文件所指向的端口状态结构；

步骤S200，向目标端口所在的网卡发送冻结指定端口的命令；

步骤S300，如果已确认主机方的目标进程已经停止运行，保存用户进程能够写入的发送请求队列和各发送缓冲区，否则需要首先向目标进程发送暂停运行的远程中断；

步骤S400，在通信协处理器确认目标端口已冻结之后，保存用户空间的接收缓冲区和事件队列，以及网卡上的端口控制块和所有该端口正在使用中的发送句柄。

一种通信***的检查点恢复方法，包括下列步骤：

步骤S100′，端口的重建；

步骤S200′，端口的重定位。

一种通信的断点恢复方法，包括下列步骤：

步骤1.冻结本地通信端口的收发操作

步骤2.保存已冻结端口的状态

步骤3.向其它MCP广播。

一种单机故障时检查点切取方法，包括下列步骤：

步骤S1000，进程完整状态保存；

步骤S2000，结点故障的检测；

步骤S3000，远程检查点目标进程的状态检测。

一种远程中断中止的进程检测方法，包括下列步骤：

步骤N1，查找指定进程号对应的进程控制块；

步骤N2，填写远程中断请求结构；

步骤N3，若该进程所在的CPU标识等于执行远程中断服务程序的CPU标识，则直接设置被中断进程的标志；否则，向该进程所在的CPU发送处理器间中断；

随后，该进程所在的CPU在进程调度模块中响应远程中断请求结构中注册的请求，并在完成该请求之后更新其中的请求状态标志。

本发明的有益效果是：本发明的一种机群容错***、装置及方法，其是一种针对并行应用的机群故障时检查点机制，旨在为并行应用提供局部化的快速故障恢复。对于全局检查点***，并行应用中所有进程的状态需要在其正常运行的过程中周期性地写入非易失性存储设备并保持进程间通信状态的一致性，而机群故障时检查点机制的核心思想则是在并行应用正常运行时仅保存CPU状态等在结点故障时无法获取的状态。当发现故障时，对故障结点上的进程远程执行检查点，保存其通信***的状态，并通过机群通信协议保证通信中断后的正确恢复；

本发明还提出了基于远程直接内存访问技术的远程检查点方法机制。该技术利用远程直接内存访问的通信过程无需目标结点的CPU和操作***参与的特点和机群高速通信***的优异性能，在目标结点的操作***拒绝服务等故障条件下能高效地切取应用状态。该技术使应用程序与操作***的依赖关系变得松散，操作***的故障不会威胁到被服务进程的继续运行。

本发明还实现了用户级机群通信***的检查点和恢复方法机制。该机制利用机群通信***中的应答、重发和消息缓冲等通信可靠性保障方法机制，降低了并行检查点过程对维护通信***全局一致性状态的要求，减少了进程的检查点和恢复过程的开销。

本发明还在用户级机群通信***的检查点和恢复机制的基础上，探索了机群通信协议如何对并行应用的故障时检查点和恢复操作提供支持，提出了针对并行应用中单个进程的检查点的通信断点恢复的方法机制。

本发明还实现了支持故障时检查点的结点级容错方法机制，包括基于协处理器的结点故障检测技术和基于进程运行上下文切换的CPU寄存器状态保存技术，能够实现结点故障的快速检测并确保目标进程的状态在结点故障发生之后的完整性。

本发明还实现了一个轻量级的并行程序故障时检查点和恢复***(Crash-Time ChecKpoint and Restart system，CTCKR)。该***仅当一个并行应用因其所在的一结点的操作***崩溃而无法继续运行时才触发检查点和恢复操作，避免了定期地频繁执行检查点所带来的时间开销，并且该***仅仅针对故障结点中的相关进程进行检查点和恢复，而无需执行全局检查点，因而存储开销也显著降低。

通过利用NPB(NAS Parallel Benchmarks)、LINPACK等基准测试程序的评测实验表明，本发明的机群容错***、装置及方法在各项性能测试和基于故障注入的正确性测试中都很好地达到了设计目标，这充分表明了本发明的机群容错***、装置及方法是一种可行的轻量级机群容错技术。

附图说明

图1为进程信息项结构示意图；

图2为本发明的机群容错***工作过程示意图；

图3为远程检查点切取方法的操作对象示意图；

图4为用户空间虚拟地址的转换示意图；

图5为分布式***的一致性状态示意图；

图6为环形接收缓冲区的检查点切取优化示意图；

图7为MX通信协议中的断点恢复支持方法示意图；、

图8为二叉树广播方法示意图；

图9为MX检查点开销测试结果图；

图10为核心堆棧顶部示意图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明的一种机群容错***、装置和方法进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

机群容错***追求如下目标：1)对应用程序广泛的适应性。机群容错应该尽可能地独立于应用程序、并行应用中间件，甚至不依赖于结点操作***，方便应用开发人员和***管理人员，即容错机制应尽量保持对应用的透明性。2)在***无故障运行的条件下的低开销。容错机制对***性能造成的损失应该力求最小，对存储等资源的占用也应力求最少。3)低恢复开销。降低卷回恢复的层次，从而减少恢复开销。

本发明的机群容错***，基于以下技术：1)当一个机群结点出现操作***拒绝服务，甚至崩溃等故障之后，基于协处理器的故障检测机制使得该结点的状态得以为外界所知晓；2)远程检查点技术使得该结点上任一进程的检查点能够被远程切取；3)而机群通信***的检查点机制又使并行应用的通信过程可以被随时中止和恢复。

本发明的机群容错***，包括如下功能模块：

远程检查点服务器，用于响应来自故障结点的远程检查点请求，执行检查点操作；

结点故障检测模块，用于监测本地结点的操作***和指定进程的运行状态，触发远程检查点；

并行应用进程管理器，用于为故障时检查点***提供被监测应用的进程信息，并管理进程恢复过程；

作为一种可实施的方式，本发明的机群容错***，选择MPI应用作为测试对象，因此该并行应用进程管理器实现于MPI进程管理器的功能扩展之中。

检查点文件服务器，用于存储检查点文件，并在故障时检查点的恢复过程中提供检查点文件访问支持。

通信***检查点模块，用于实现通信设备的检查点，并支持通信断点恢复功能。作为本发明实施例的一种可实施方式，该通信***检查点模块实现于MX通信***的扩展之中。

下面进一步说明本发明的远程检查点服务器。

远程检查点服务器响应来自故障结点的远程检查点请求，执行检查点操作，其工作流程如下：

1、加载目标平台中各结点的操作***内核符号表和数据结构类型表。

2、循环等待应用程序的故障时检查点注册消息或者来自故障结点的求救消息：

(A)对于应用程序的注册消息：

A1)向该应用中各进程所在的结点广播应用拓扑信息。各结点的通信协处理器在收到该消息之后启动本地状态监测。

A2)开始能够处理该应用中各结点发送的求救消息。

(B)对于故障结点的求救消息：

B1)应答求救消息。在配置多个远程检查点服务器的***中，最先返回求救应答消息的服务器才能继续执行此次检查点过程。

B2)继续执行远程检查点。

B3)通知MPI控制程序被切取进程的rank、检查点的完整路径。

C)对于恢复进程的注册消息：

向恢复进程返回其所在并行应用的应用拓扑信息，以使其可以发起通信断点恢复过程。

下面进一步说明本发明的结点故障检测模块。

本发明的机群容错***中的结点故障检测模块的功能是监测本地结点的操作***和指定进程的运行状态，触发远程检查点过程。

其利用的是基于协处理器的结点状态监测方法。

远程中断机制，即一种通过机群通信***中的消息向目标结点的操作***传递控制命令的机制。其中，远程中断功能主要用于控制尚未崩溃的远程结点中某个进程的运行状态。

下面进一步说明本发明的并行应用进程管理器

尽管故障时检查点***所依赖的通信***检查点机制可以支持位于机群通信***之上的各种并行应用中间件，如MPI、PVM等，但是不同的并行应用中间件需要不同的并行进程管理机制。鉴于MPI目前是机群并行计算中间件事实上的标准，本发明实施例选择MPI应用作为故障时检查点***的测试对象。

MPI标准目前有多种实现版本，本发明实施例选择的是支持MX通信***的MPICH 1.2.5版。MPICH默认的进程管理器是MPIRUN，其原有流程为：

1、解析命令行输入，设置本次应用运行的控制参数。

2、根据备选结点列表生成目标结点数组。

3、建立用于接收子进程基本信息的监听端口。

4、按照MPI进程序号(RANK)逐一创建执行远程命令(RSH/SSH)的子进程。这些MPIRUN的子进程进而在对应的目标结点中创建MPI并行应用的子进程。

5、在监听端口中接收所有子进程返回的进程号、网***、端口号等基本信息。

6、在收集完毕所有子进程的基本信息之后，向所有子进程广播该并行应用中所有子进程的基本信息。当各个子进程收到该广播之后，MPI初始化过程结束。

7、在上述监听端口中等待接收子进程调用MPI\_Abort()发送的消息。若收到一个这种消息，向其余子进程广播进程终止命令。

在本发明的机群容错***中，并行应用进程管理器不但要为MPI应用提供进程加载服务，而且要为远程检查点服务器提供目标应用的拓扑信息，并管理进程恢复过程。为此，本发明对MPIRUN的流程进行了扩充：

1)在向所有子进程广播收集到的子进程基本信息之后，MPIRUN向远程检查点服务器注册该应用的进程信息，其中每个条目的格式如图1所示。每个条目中包含有进行的信息RANK、PID、NIC_ID、PORT_ID、STATUS。

远程检查点服务器会根据应用的注册信息，进一步通知所有相关结点的结点故障检测模块开始监控本地结点的运行状态。

2)当远程检查点服务器成功地切取了某个进程的故障时检查点之后，会通知MPIRUN，由其负责后续的进程恢复过程。

MPIRUN创建一个新的子进程，并由后者向指定的备用结点发送进程恢复命令。随后，MPIRUN更新其子进程与MPI进程序号的映射表，以使该MPI应用的退出过程正常进行。

经过扩充的MPIRUN从命令行参数中获取远程检查点服务器的地址，并支持备用结点列表文件、命令行输入等多种提供备用结点的方法。

下面进一步说明本发明的检查点文件服务器。

本发明的检查点文件服务器实现了一个基于MX通信***的虚拟文件***MXFS，用于访问故障时检查点的映像文件。其通过Linux操作***中的procfs虚拟文件***提供了标准的open()、read()、lseek()、write()等文件操作接口。当用户程序打开如“/proc/mxfs/NODE/FILENAME”的文件名时，MXFS的客户端核心模块会自动地向结点“NODE”中运行的MXFS服务器发送建立链接，以访问“FILENAME”文件的请求。MXFS服务器在该请求的应答消息中向客户端发送指定的本地文件打开命令的返回值。在该文件的***建立之后，MXFS客户端就可以通过正常的读写命令访问该文件。当MXFS服务器所选的本地文件***为RAMFS时，MXFS的读性能可以达到97MB/s。这一性能仅达到MX通信***的峰值性能的42％，这主要是由于MXFS服务器和procfs的实现效率较低的原因。

在故障时检查点***的实现中，MXFS服务器与远程检查点服务器运行于同一个结点，甚至在同一个程序中实现，以使MXFS服务器可以直接访问远程检查点服务器所保存的检查点文件。

下面详细描述本发明的一种机群容错处理方法的工作流程。

本发明实施例以一个N进程MPI应用中的一个结点发生操作***故障为背景，详细地描述本发明的机群容错方法的故障时检查点的工作流程。

步 S1.应用注册。

当MPI进程管理器加载一个MPI应用时，在收集到所有子进程的基本信息之后，向远程检查点服务器发送应用注册请求。远程检查点服务器在接收该请求之后，根据其中包含的进程信息，向所有相关结点的结点故障检测模块发送结点监控请求。该请求中包含被监测应用的注册号及其所有进程的基本信息、可用的远程检查点服务器地址(列表)和结点监控策略码。结点监控策略码用于配置结点监控模块对本地的***状态做何种监测，包括监测时间间隔、监测内容等。

步 S2.结点监测。

在被监测应用的运行过程中，结点故障检测模块定期地主动监测本结点的操作***的故障，同时也能被动地接收和处理主机方发送的结点故障恢复请求。

步 S3.故障报告。

当结点故障检测模块探测到故障或者收到故障恢复请求时：

首先，冻结本地所有被监测的进程打开的通信端口；

然后，向预设的远程检查点服务器发送故障报告，请求后者对指定的本地进程实施远程检查点；

最后，通过远程中断广播通知被监测应用中其它进程的MCP指定进程的检查点正在启动，如图2(2)所示。

步 S4.远程检查点切取。

当一个远程检查点服务器收到有效的故障报告之后，就启动远程检查点过程，如图2(3)所示。在该过程成功结束之后，远程检查点服务器将所得到的检查点映像文件的位置和对应进程的RANK等信息发送给MPI进程管理器，由其负责后续的进程恢复过程。

步 S5.进程恢复。

MPI进程管理器首先需要确定进程恢复所用的结点，例如从预设的空闲结点列表中选择新的结点，或者等待故障结点的重启动。

然后，MPI进程管理器向目标结点发送恢复进程的命令，如图2(4)所示。在该命令中，检查点文件的位置以其在MXFS文件***中的地址的形式给出。在目标进程的恢复过程中，其通信端口在恢复之后，会广播通知其它进程继续通信，如图2(5)所示。如果在该进程的检查点和恢复过程中没有其它结点故障，则被监测应用继续运行。

较佳地，在上述过程的最后一步，MPI进程管理器可以通过远程电源管理软件重启动故障结点。目前，已经有较为成熟的远程电源管理的解决方案，如CPS公司推出的多种基于以太网、RS-232等连接的远程电源管理设备。在本发明实施例中，采用Linux***在panic()函数中提供的超时重启机制。通过设置Linux操作***的启动选项panic，使操作***在进入panic状态指定时间之后自动重启动。

为了进一步说明本发明的机群容错***和处理方法，本发明实施例以开发平台为：硬件配置为两路AMD Opteron处理器的NUMA服务器；网卡为Myricom PCIXD-2，其通信协处理器为LanaiX版。开发平台的操作***核心为Linux-2.6.12版本；并行计算中间件MPICH的版本为1.2.6；底层的通信***为Myricom MX 1.1.0版。说明本发明的机群容错***和方法，其将按照操作***、底层通信***、远程检查点服务器等三个层次分别介绍该***和方法的实现细节。

1、操作***层

11)进程状态保存

Linux操作***核心代码中的arch/x86\_64/kernel/entry.S文件的内容是Opteron CPU通过***调用、中断、异常等方式进出核心态的汇编程序。为了使用户进程上下文中的CPU寄存器、FPU寄存器的状态在CPU每次进入核心态的时侯得到保存，本发明对该文件进行了修改。在从每个CPU的x8664\_pda结构中取出核心堆栈的指针之后，将完整地保存上述状态。对于***调用入口的主要修改片断如下：

...

SAVE_REST

pushq ％rax

pushq ％rdx

call ctckr_save_fpu

popq ％rdx

popq ％rax

call*sys_call_table(，％rax，8)

movq ％rax，RAX(％rsp)

RESTORE_REST

...

其中，SAVE\_REST/RESTORE\_REST是对RBX、RBP、R12～sR15寄存器进行保存和恢复。

所述代码中保存FPU的函数接口设置为：

void ctckr_save_fpu(void)

{

          struct task_struct*tsk＝current；

          if(！used_math())

                    return；

          if((tsk)->thread_info->status & TS_USEDFPU){

                    asm volatile(＂rex64；fxsave ％0＂

                    :＂＝m＂(tsk->thread.i387.fxsave))；

           }

           return；

}

其中，FXSAVE为Opteron CPU保存XMM、MMX和x87寄存器状态的指令。

鉴于FPU状态的保存是本发明机群容错***和方法的进程状态保存中最耗时的操作，从上述代码可以看出，对于不使用FPU的非科学计算程序，本发明机群容错***和方法所带来的无故障运行时的性能开销将可以忽略不计。

12)操作***故障检测

为了支持基于操作***故障计数的机群容错的故障检测机制，本发明设置一整数类型的ctckr_danger_level[]数组，每个CPU按其序号分别对应于该数组中的一个元素。为了使协处理器可以通过一次DMA读操作得到该数组的内容和当前的时钟中断计数，本发明修改了生成操作***核心映像的链接器脚本，即arch/x86_64/kernel/vmlinux.lds.S文件，以使该数组与时钟中断计数变量的地址相邻。在通信网卡的核心模块加载过程中，所述地址将被注册到通信协处理器中，以便后者定期对主机方的故障状态进行检测。

2、底层通信***

机群容错***和方法所需的对通信***的扩充包括远程中断、RDMA读、MX端口冻结、MX端口恢复等功能。上述功能的实现都涉及对MX通信***的MCP、用户库两个部分的修改，其中MCP由于属于通信网卡中的嵌入式软件，其开发和调试的难度都比主机方程序高。本发明将以RDMA读的实现为例说明上述功能的实现方式。

在用户库中，添加新的请求类型MX＿REQUEST_TYPE_RMA_GET，并在用户请求数据结构union mx_request中添加对应的子类型struct rma_get。

struct{

     struct mx＿basic_request basic；

     mx_segment_t*segments；

     uint32_t count；

     mx_segment_t segment；

     uint64_t remote_addr；

     mx＿endpoint_addr_t dest_address；

     uint16_t lib_seqnum；

     uint16_t pad；

     uint32_t remote_len；

     uint16_t msg_seq；

     uint8_t unexpected；

     uint8_t pad2；

     struct mx＿partner*partner；

  }rma_get；

用户库在处理所述用户请求之后，继而向MCP发出请求，因此，本发明添加设置MCP层的用户请求类型MX_MCP_UREQ_RMA_GET，及对应的MCP请求结构mcp_ureq_rma_get_t。

typedef struct

     {

          uint16_t target_peer_index；

          uint8_t target_endpt；

          uint8_t is_reply；

          uint32_t target_session；

          uint32_t timeout；

          uint16_t lib_seqnum；

          uint32_t remote_addr_high；

          uint32_t remote_addr_low；

          uint32_t remote_len；

          uint16_t lib_cookie；

          uint8_t pad1；

          uint8_t type；

       }mcp_ureq_rma_get_t；

MCP层在处理该请求之后，将按新设置的MX数据包类型PKT_TYPE_RMA_GET，发送如下格式的数据包：

typedef struct{

          pkt_data_common_t common；

          uint32_t remote_len；

          uint32_t remote_addr_high；

          uint32_t remote_addr_low；

          uint8_t is_reply；

          uint8_t pad；

          uint16_t return_peer_index；

          uint32_t src_mac_low32；

      }pkt_data_rma_get_t；

接收方的MCP在收到该消息之后，启动指定的DMA读操作，并返回新定义的PKT_TYPE_RMA_GET_REPLY类型的数据包。发送方的MCP在收到该消息时，先启动接收数据的DMA，再向主机方的用户库DMA类型为MX_MCP_UEVT_RECV_RMA_GET的事件。

在MX端口恢复的实现中，本发明在进程恢复模块中首先创建一个新的MX核心端口，再将其状态按照进程检查点的内容进行修改，以达到对用户进程完全透明的目的。

3、远程检查点服务器

远程检查点服务器被实现为一个后台服务进程方法。鉴于一般的机群***中各结点的操作***版本相同，该方法支持在启动时配置默认的结点操作***的版本。作为一种可实施的方式，该方法的用户界面为：

Usage:rmac[options]

 -m，--map<System.map>        System.map file

 -k，--kerntypes<Kerntypes> Kerntypes file

 -s，--server                     Daemon mode

 -g，--debug LEVEL                 Debug level

 -h，--help                        Display this help

在本发明的机群容错***和方法的故障时检查点的恢复过程中，恢复进程要向远程检查点服务器注册，以获得其所在并行应用的应用拓扑信息。这是因为远程检查点服务器具有已注册应用的最新的进程状态信息(包括尚在远程检查点过程中的进程的信息)，同时MPIRUN只是一个Perl脚本程序，除了可以设置进程恢复命令中的参数之外，无法与被恢复进程进行方便的通信。MPIRUN在进程恢复命令中会将远程检查点服务器的地址通知被恢复进程，该命令的形式如下：

rsh NEW_NODE″cd CTCKR_IMG_PATH；\

ctck_restart -r CTCKR_SERV_MAC:CTCKR_SERV_PORTctckr.TARGET_PID＂

应当说明的是，本发明实施例选择了Myrinet/MX通信***作为本发明机群容错***和方法的实现平台，但是本发明同样也可以实现于其它的通信***之上，例如QsNet、InfiniBand等。

下面详细说明本发明的远程检查工作的过程，其包括一种远程检查点切取***和方法，以及一种远程检查点恢复***和方法。

检查点技术是一种广泛用于卷回和前滚错误恢复的容错技术，其设计思想简单明了。该机制可以在处理器、物理存储器、虚拟存储器等级别实现，而在基于COTS部件的机群***中，该技术常实现于操作***、应用程序等软件层次之中。检查点技术的主要功能是减少单次故障所造成的时间损失。在具有进程副本(Process/Task Duplication)的容错方案中，例如DMR-F(Double ModularRedundancy with Forward Recovery)、TMR-F(Triple Modular Redundancy withForward Recovery)和RFCS(Roll-Forward Checkpointing Scheme)等，检查点的比较还是极为方便和准确的故障检测方法。除了用于所述容错目的之外，该技术还被用于负载均衡、作业调度和***维护等场合。在工程实践中，IBM公司在20世纪60年代末推出的OS/360操作***就已经对应用程序提供了检查点和恢复机制的支持。随着用户对可靠性和可用性的需求不断提高，该技术已经开始在高端的科学和工程计算平台中得到普及。

在本发明中，进程检查点和恢复技术是指在某一时刻保存一个目标进程的运行状态，并在随后的某一时刻以此状态为起点重建该进程，使其继续运行。在该过程中，被保存的进程状态叫做该进程的检查点，保存检查点的操作称为切取(Checkpointing)，而利用检查点重建进程，使其能够继续运行的操作称为恢复(Recovery或Restart)。对于在应用的运行过程中周期性执行的检查点操作，相邻两次操作之间的时间跨度称为检查点间隔(Checkpoint Interval)。

进程检查点的内容不但包括基本的进程属性，用户地址空间中的数据段、堆栈段、堆等存储区域的当前内容，而且包括用于进程间通信和I/O的各种***资源的当前状态，例如已创建的套接字、信号量、共享内存、消息队列和已打开的各种文件等等。

尽管进程检查点和恢复技术的思想简单明了，但是其实现的复杂程度却往往较高。以机群计算领域常用的Linux操作***平台为例，到目前为止仍然没有一个检查点和恢复***可以实现任意进程在任意时刻的检查点和恢复。该技术的实现难度主要源于以下两方面的原因：一，操作***的设计日趋复杂，在对进程的运行和管理提供更多支持的同时，也使进程检查点的内容不断增加；二，对于和外界存在通信、文件I/O和交互式操作等行为的进程，其检查点和恢复过程需要特别考虑对外界，包括其它进程、存储***、用户等，的影响。

根据检查点的不同层次，检查点可以分为***级检查点、用户级检查点，其中用户级检查点主要是文件检查点。

***级检查点通过修改操作***或者加载核心扩展模块的方式，在核心层实现进程状态的保存和恢复。

用户级检查点技术在目标进程的用户态上下文中对其状态进行保存和恢复。

文件检查点的主要目的就是以尽可能小的开销，尽可能对应用透明的方式使一个文件在两个相邻检查点之间的状态变化能够得到卷回。

随着机群文件***的发展，本发明的检查点***和方法，利用WAFL等日志结构文件***(Log-Structured File System)中的快照功能(Snapshot)来代替文件检查点。该方法充分利用特定文件***中的现有功能，实现方便且效率较高，尤其能够避免在检查点间隔较长的情况下，文件检查点的开销趋于显著的问题。对于较大规模的机群应用，如果其多个进程通过网络存储***在一个共享的文件***中进行文件I/O，则该方法的效率更佳。

本发明的远程检查点切取***和方法，是基于远程直接内存访问(RemoteDirect Memory Access，RDMA)的远程检查点切取***和方法，是一种无需目标进程所在结点的CPU和操作***参与的检查点***和方法。

远程存储访问(Remote Memory Access，RMA)是一种通过共享内存、通信协处理器、DMA控制器或者硬件实现的远程Put/Get操作等硬件机制实现的数据传递方式，能够使一个结点直接读取或者写入另一结点的一段存储区域。

本发明实施例所述的远程检查点切取***和方法，利用RDMA无需目的结点的CPU和操作***参与通信过程的特点。在本发明实施例中，作为一种可实施的方式，RDMA基于Myrinet网络中的LANai通信协处理器，对MX通信***进行的RDMA读功能的扩展。该RDMA可以实现对目标结点中指定物理地址的内存空间的读取。

一个进程的完整的状态信息可能分布于CPU中的通用寄存器、浮点寄存器和数据高速缓存，以及内存和磁盘中。本发明实施例借助于硬件实现的高速缓存一致性协议(Cache Coherence Protocol，CCP)来实现RDMA操作对高速缓存内容的读取。

CCP协议是一种现有技术，本领域技术人员根据本发明的描述，可以重现其过程，因此，在本发明实施例中，不再一一详细描述。

本发明的远程检查点切取***，可以视为一种特殊的核心级检查点机制。在远程检查点过程中，检查点工具程序远程访问的进程状态信息与BLCR等核心级检查点***所访问的进程状态信息基本相同。本发明远程检查点***在检查点映像的格式上与BLCR保持一致。

本发明的远程检查点切取***与核心级检查点主要区别于如下三个方面，对目标进程所在结点的操作***的内核符号的寻址，数据的缓存和预取，以及指针操作，上述三个方面也构成了远程检查点设计和实现中的三个模块。

本发明的远程检查点切取***包括内核符号寻址模块，用于对目标进程所在结点的操作***的内核符号的寻址；数据缓存模块，用于数据的缓存和预取；以及指针模块，用于指针操作。

下面详细描述内核符号寻址模块。

为了提取目标进程的状态信息，远程检查点***需要访问管理目标进程的操作***内核的各种变量和数据结构。在本发明实施例的平台上，作为一种可实施方式，本发明远程检查点***利用Linux操作***内核的编译过程中生成的System.map和Kerntypes两个文件。

其中，前者是Linux操作***的所有内核符号，包括所有的核心变量和函数，与其虚拟地址的映射表；

后者则包含Linux内核中所有的数据结构的类型描述信息。结合以上两个文件的内容，可以计算出每一个内核变量，及其数据结构中的任意一个成员，的虚拟地址和长度。

同时，Linux操作***内核所采用的虚拟地址与RDMA操作所用的物理地址之间的映射关系固定，因此，本发明远程检查点***就能够实现对目标操作***中的各种内核符号的访问。

本发明实施例中，远程检查点切取***需要访问的Linux内核中的数据结构可以按存储位置分为两类：一类位于静态分配的内核数据段和BSS段，另一类在内核动态分配的存储单元中。前一类数据结构对应于已初始化或者未初始化的全局变量，其标识符和地址可以在System.map中被直接查到；后一类数据结构的地址则需要通过已知的全局变量间接地查找。例如，在查找一进程号P对应的进程控制块(task_struct结构)时，首先读取Linux内核中task_struct类型的全局变量init_task，然后根据task_struct结构中list_head类型的tasks域，依次访问进程控制块链表中的下一个单元，直到找出进程号等于P的进程。当得到一个目标进程的进程控制块之后，可以根据其中包含的各个指针，逐个访问赋予该进程的各种***资源，如图3所示。

对于目标进程的用户地址空间，远程检查点***需要按照目标结点中CPU的虚拟地址转换机制进行访问。为了提高检查点性能，本发明***以页面为单位读取目标进程的用户空间。在本发明实施例的平台中，作为一种可实施方式，Opteron CPU采用基于四级页表的页式存储管理，如图4所示。本发明的远程检查点***首先根据存储管理结构mm_struct所包含的页表目录基址PGD(Page Global Directory)，读取PGD表所在的物理页面，然后按图4中所示步骤通过虚拟地址中的PGD索引、PUD(Page Upper Directory)索引、PMD(Page Middle Directory)索引和PTE(Page Table Entry)索引依次查询对应的页表，直到查出一个用户空间虚拟地址所在的物理页面。

下面详细说明本发明的数据缓存模块.

通过RDMA访存方式访问远程结点内存的性能远远低于结点内访存性能。为了解决这一问题，在本发明的远程检查点***中，采用缓存机制和数据预取机制来缓解RDMA访存方式对检查点性能所带来的影响。

远程检查点过程中的访存操作存在较高的数据局部性。针对大量存在的目的地址和长度都相同的重复RDMA读操作，仅通过缓存读取内容以供后续查找的方法就可以将RDMA操作的数量降低到原来的25％。针对呈现的大量目的地址相邻的RDMA读操作，通过设定RDMA最小读取长度的方法就能够极大地减少远程检查点过程所需的RDMA读操作的数量。

下面详细说明指针模块。

本发明实施例所述的远程检查点切取***在本质上属于核心级检查点，并且具有管理目标进程的操作***核心与检查点***分别位于独立的上下文的特点。由于一个指针的有效性仅局限于其所针对的地址空间，当通过远程读取方式将管理目标进程的操作***核心中的指针变量复制到远程检查点服务器中的时候，应当采取措施避免因远程指针变量的不当引用而造成程序故障。

在指针的比较运算方面，有可能出现缓存于远程检查点服务器中的一个数据结构的地址(即缓存地址)和一个直接读取自目标结点内存中的指针变量的赋值(即原始地址)的比较。前者的取值属于远程检查点服务器进程的用户地址空间中的虚拟地址，而后者的取值属于目标结点的操作***的核心地址空间中的虚拟地址。显然，这两者之间的比较没有任何实际意义。为此，本发明远程检查点***中维护了所有涉及地址比较操作的数据结构的原始地址和缓存地址的对应关系。

在目标结点中数据结构的地址进行比较之前，要先查询维护上述的地址对应关系的哈希表，将缓存地址全部转换为目标结点中的原始地址再进行比较。

在指针的算术运算方面，对一个复杂数据结构或者数组中的某个元素的寻址经常涉及指针的运算，如果远程读取和本地缓存操作使数据之间原有的相对位置发生了变化，就有可能导致数据错误，甚至指针越界。因此，本发明远程检查点***对于涉及指针运算的数据结构都完整地予以复制，以保持其内部元素之间的相对位置关系。

下面详细说明本发明的远程检查点切取方法

远程检查点切取的基本流程如下：

步骤S10，加载目标结点的操作***符号表System.map。

步骤S20，加载目标结点的操作***核心类型表Kerntypes。

步骤S30，根据目标进程号查找目标进程的进程控制块，并复制到本地缓冲区中。

步骤S40，创建远程检查点映像的文件头；

步骤S41，保存目标进程的PID，UID，EUID，GID，EGID和名称(comm[])等基本属性。

步骤S42，保存CPU的状态信息，包括通用寄存器、调试寄存器和协处理器的状态。

步骤S43，保存信号(Signal)处理信息。

步骤S44，根据mm_struct结构保存进程的虚拟地址空间。

i)首先，保存代码段、数据段、堆空间、堆栈段和环境变量区的起止地址；

ii)然后，保存各个vma_area_struct对应的虚拟内存区域(VirtualMemory Area，VMA)。数据段、堆空间和堆栈段内的物理页面全部会被远程读取，所含数据并非全零的页面都将被保存到检查点映像中。

步骤S50，保存root，altroot和当前工作目录的完整路径。

步骤S60，保存目标进程的文件描述符表。

步骤S70，逐一保存目标进程已打开文件的基本信息。

步骤S71，对于普通文件，本发明实施例中，记录文件名、访问模式、长度、偏移等信息。较佳地，所述普通文件为只读文件和通过内存映射方式打开的读/写文件。

步骤S72，对于字符设备，按照不同的主、从设备号，分别调用对应的设备冻结函数。本发明实施例中，例如，对Myrinet通信端口等字符设备的检查点在此处被调用。

步骤S80，为远程检查点映像文件加入末尾标记。

相应地，本发明还提供一种远程检查点恢复***和方法。

检查点恢复***和方法，利用检查点文件中保存的进程状态信息，重建目标进程，使其能够正确地继续运行。

检查点恢复***和方法一般需要与其对应的检查点切取***和方法实现于机群***中的同一层次，即核心级和用户级的检查点切取过程应该分别对应于核心级和用户级的恢复过程，这是由于在计算机***中的不同层次，进程的状态信息有不同的位置、格式以及与之相对应的访问方式。但是，对于本发明的远程检查点切取***和方法而言，由于其检查点文件的格式与核心级检查点***BLCR的检查点文件的格式兼容，作为一种可实施方式，远程检查点的恢复***和方法也采用了与BLCR基本相同的恢复流程。

远程检查点切取***和方法所处理的目标进程可能通过中断和***调用两种方式进入操作***。目标进程在被切取检查点时的状态不会影响其远程检查点切取过程，但是可能会造成其恢复过程的初始化阶段的差异。

例如，对于Opteron CPU，通过中断或者***调用的方式进入核心态的时候，一些寄存器的功能会有区别。为了降低CPU在***调用过程中进出核心态的开销，X86_64处理器为平坦段内存模式(Flat-Segment Memory Model)提供了SYSCALL和SYSRET两个指令。在64位长模式(Long Mode)下，SYSCALL指令会将指向下一条指令的RIP保存到RCX，并从LSTAR寄存器的低64位加载新的RIP值。LSTAR属于型号特定寄存器(Model-SpecificRegister，MSR)。在Linux***初始化时，该寄存器被写入了***调用的入口地址。当通过SYSRET返回用户空间时，CPU又要从RCX中获得RIP值。如果CPU是通过中断方式进入核心态，并通过IRET指令返回用户态，RCX寄存器不会被用到。

因此，对于通过中断方式进入核心态的进程，在恢复时应当从被中断指令的下一条指令开始执行。对于通过***调用进入核心态的进程，在恢复时应当重新开始执行被故障所中断的***调用。

本发明的远程检查点恢复***，包括状态区分模块，用于区分目标进程的状态，以避免对RCX等寄存器的误用。

如，Opteron CPU在通过中断方式进入核心态的时候会将一个中断向量写入RAX寄存器，而通过***调用进入核心态时会将***调用的编号写入RAX寄存器，因此RAX寄存器就成为区别目标进程状态的标志。

在本发明远程检查恢复***中，还包括跳板模块，用于恢复完整的通用寄存器状态，使进程都以IRET指令退出核心态，从核心空间返回用户空间。

下面详细说明本发明的远程检查点恢复方法，其是所述的远程检查点切取方法的逆过程，包括如下步骤：

步骤S10′，检查点恢复工具rmac_restart创建一个子进程，并开始等待其执行完成或异常退出。

该子进程将首先创建与被恢复进程相同数量的线程，然后通过***调用的方式进入操作***核心。在以下步骤中，该***调用将顺序读取检查点文件的内容，以rmac_restart子进程(或称宿主进程)中的各线程为基础，重建被恢复进程。

步骤S20′，根据检查点文件的头部信息判断其合法性；如果头部信息中标明的操作***内核、检查点工具等版本不符合预期，则退出；否则，进入下一步骤。

步骤S30′，重新设置目标进程的PID，UID，EUID，GID，EGID和进程名称等基本属性。

步骤S40′，恢复目标进程核心栈中的CPU状态部分，包括通用寄存器、调试寄存器。

步骤S41′，如果检查点中的进程状态标记表明目标进程是在一***调用失败之后被切取，则设置目标进程的RIP和RAX使目标进程恢复运行之后，重新执行该***调用。

步骤S42′，否则，目标进程是通过中断、异常进入核心态之后被切取，直接设置辅助目标进程返回用户态的跳板程序的地址。

步骤S50′，恢复目标进程中信号处理的相关信息。

步骤S60′，解除宿主进程的所有虚拟存储区域的映射。

步骤S70′，加载目标进程的所有虚拟存储区域的映射。

对于数据段、堆空间和堆栈段内的数据，检查点恢复工具将以页面为单位从检查点文件中读取，并拷贝到为对应的虚拟地址所分配的物理页面中。

步骤S80′，设置目标进程的虚拟地址空间描述信息，如mm_struct结构中的代码段、数据段、堆空间、堆栈段和环境变量区的起止地址等。

步骤S90′，恢复目标进程的root，altroot和当前工作目录的路径。

步骤S100′，关闭宿主进程的close_on_exec文件描述符组(fd_set)中的各个文件。

步骤S110′，逐一恢复目标进程已打开文件的基本信息。

步骤S111′，对于普通文件，恢复访问模式、长度、偏移等属性。

步骤S112′，对于字符设备，按照不同的主、从设备号，调用对应的设备恢复函数。如对Myrinet通信端口的检查点恢复在此处被调用。

步骤S120′，设置目标进程的状态为可运行，使其退出远程检查点恢复过程之后可以被正常地调度执行。

下面详细说明本发明的一种通信***的检查点切取和恢复***和方法，以及通信协议的断点恢复方法，其相应于本发明的机群容错***和方法中的通信***的故障报告和恢复的过程。

一般地，故障时检查点***无法促使目标进程的通信***在检查点操作之前进入指定的状态，这就产生了两个问题。首先，如何获取目标进程的通信***的完整状态？第二，如何确保因目标进程的检查点和恢复操作而中断的进程间通信？针对这两个问题，本发明探讨了机群通信***对故障时检查点和恢复机制的支持，主要包括用户级机群通信***中的通信设备检查点切取和恢复***和方法，以及支持并行应用中的单个进程进行检查点切取和恢复操作的通信协议的断点恢复方法。

通信***的分布式***检查点技术的基础是分布式***的全局一致性。在本发明实施例中，对通信***的分布式***及其检查点技术中，作为一种可实施方式，基于以下***模型：

1、一个并行应用是由N(N≥2)个执行目标程序(Target Program)的进程P_i(0≤i<N)组成的集合，其中运行进程P_i的处理器表示为p_i。

2、消息传递(Message Passing)是进程间通信的唯一方式，不存在理想的全局时钟和共享的存储器。

3、进程间通信的可靠性得到保证，不存在消息错误、丢失或重复接收的情况。在本发明中，称并行应用的进程间通信所产生的消息为计算消息，为了检查点等目的而产生的消息属于控制消息。

4、进程间通信的每一条链路符合先入先出(First-In-First-Out，FIFO)，即对进程P_i经由一条链路发往P_j的两个消息，若消息M₁先于M₂发送，则必有M₁先于M₂被接收。

5、进程的失效模型是Fail-Stop，即在失效状态下，进程停止计算和通信。

6、进程P_i的第j个检查点表示为C_i，j。

在一个分布式***中运行的并行应用的状态，不仅包括其各个进程的状态，还包括进程间通信所产生的消息的状态。如图5所示，表示由P₀、P₁和P₂三个进程组成的一个并行应用。c₀、c₁、c₂等三条线表示该并行应用的三个状态截面(Cut)。一个并行应用的全局检查点可以认为是其各个进程与某一状态截面相交叉的时刻的检查点的集合。在获取并行应用的全局检查点时，总是希望所选的状态截面像c₀一样不与任何一个消息相交，但是像M1和M2这样的消息如果不采取专门的措施，实际上很难避免。本发明中，将M1称为中途消息(In-Transit Message)，M2称为孤儿消息(Orphan Message)。

在一个并行应用的第k个全局检查点中，对于由Pi发给Pj的消息M，如果在检查点Ci，k中M尚未发出，而在Cj，k中M已经接收，则M称为孤儿消息。

在一个并行应用的第k个全局检查点中，对于由Pi发给Pj的消息M，如果在检查点Ci，k中M已经发出，而在Cj，k中M尚未接收，则M称为中途消息，又称丢失消息。

分布式***中全局一致性状态的涵义就是没有孤儿消息。

在通信***的并行检查点***的实现中，对通信***状态的处理大致分为两种策略，一种是黑箱策略。在该策略中，检查点协议的实现位于通信***层之上，检查点***的设计和实现者无需关心底层的通信***的内部实现。这种策略使得检查点协议能够独立于底层通信***，具有可移植性强的优势。例如，对于阻塞式协同检查点协议，通信***的状态在检查点过程之初就被清空(Quiesce)，从而使进程检查点中不必记录通信***的状态。对于非阻塞式的C&L协议，通信***的状态未在全局范围内被清空，而是根据检查点协议中的标记信息，在进程检查点中顺序地保存指定时间范围内收到的消息。

本发明实施例中，描述的是另一种策略，该策略将检查点***与通信***相结合，旨在降低检查点和恢复过程的开销，并提高其灵活性。该策略可以使检查点过程能够利用通信***中的各种内部状态，从而使进程间通信的状态，包括进程所用的通信设备的状态、进程发送和接收的部分消息的状态，成为进程检查点的一部分。在本发明实施例中，将介绍在机群***中应用更为普遍的用户级通信***的检查点和恢复支持。

在本发明实施例的用户级通信***检查点切取和恢复中，作为一种可实施方式，以Myrinet网络上的MX通信***作为平台进行说明，但是，应当说明的是，其不是对本发明的限定，本发明同样可以应用于其他通信***。

Myrinet是美国Myricom公司(Myricom，Inc.)于1994年推出的一种机群高速通信网络。

本发明中，MX通信***的检查点支持分为两部分，即通信设备的检查点切取和恢复，以及通信协议中的断点恢复，其中前者是后者的基础。本发明实施例中，将首先探讨前者，也就是MX端口的检查点切取和恢复。对于一个进程来说，一个MX端口只是其打开的一个特殊的字符型设备，因此，MX端口的检查点切取是故障时进程检查点过程中的步骤之一。

MX端口的检查点切取首先需要明确MX端口状态所包含的内容。每个MX端口都有且仅有一个发送请求队列、短消息发送缓冲区、中消息发送缓冲区、接收请求队列、接收缓冲区、事件队列和位于Myrinet网卡上的端口控制结构以及发送句柄链表。在没有通过检查点协议清空信道的情况下，在任意时刻都有可能存在一个消息，其完整的控制信息和数据位于以上的一个或者多个结构之中。因此，在MX端口的检查点过程中，所述结构都要予以完整地保存。

本发明实施例中，将对MX通信***中的发送请求队列、短消息发送缓冲区、中消息发送缓冲区、接收请求队列、接收缓冲区、事件队列、端口控制结构和发送句柄列表及其对应的检查点切取逐一进行介绍，并侧重于如何确保所保存内容的完整性。

(一)发送请求队列

发送请求队列位于映射到用户地址空间的网卡存储器中。该队列在逻辑上组织为环形，由用户进程填写，MCP轮询和读取。用户进程填写一个发送请求的最后一个步骤是填写发送请求结构末端的发送请求类型，MCP就是根据该域是否为空(UREQ_NONE)来判断是否有新的发送请求。MCP在处理一个发送请求时，按照发送请求的内容创建一个发送句柄之后，一般就会将其发送请求类型域置为空。

在该结构的检查点切取过程中，不会出现错误。首先，当MCP保存该结构的时候，用户进程已经停止运行，不会出现MCP已保存的状态因用户进程的继续写入而变得过时的问题，这也就确保了发送请求不会丢失。其次，MCP根据一个发送请求结构创建发送句柄和将该发送请求置空这两个操作位于同一个MCP子程序模块，其连续性不会被一个检查点过程中断，因此不会出现重复处理的发送请求。

(二)短消息发送缓冲区

短消息发送缓冲区与上述的发送请求队列都位于映射到用户地址空间的网卡存储器中，长度约为14KB。在处理一个短消息发送请求时，MX通信库首先将用户数据拷贝到短消息发送缓冲区中的可用空间，然后才会填写对应的发送请求。MCP在处理一个短消息发送请求时，根据该缓冲区在网卡存储器中的基址和用户数据的偏移值计算出用户数据的地址。MCP不修改该缓冲区的任何内容，也无需维护用于访问该缓冲区的任何指针。因此，在MX检查点中只需要完整地保存该缓冲区的内容。

(三)中消息发送缓冲区

MX中的中消息发送缓冲区是4MB的主机内存，由用户进程写入，MCP读取。在一个进程的地址空间中，该结构与接收缓冲区和事件队列都分别占用一个独立的虚拟内存块(Virtual Memory Area，VMA)。本发明实施例通过在VMA结构中添加标记信息使这三个结构可以在进程检查点过程中被识别出来。该缓冲区的分配和使用是以页面为单位。由于无法确保发送到不同目的地的长消息发送请求的完成顺序，该缓冲区没有采用环形的逻辑结构。在处理一个长消息发送请求时，MX通信库先将用户数据拷贝到中消息发送缓冲区中的可用页面，然后才填写对应的发送请求。MCP在处理一个长消息发送请求时，根据用户数据所在页面的物理地址启动主机方DMA来读取用户数据。MCP不修改该缓冲区的任何内容，因此MX检查点中只需完整地保存该缓冲区的内容。

在MX端口的恢复过程中，该缓冲区的虚拟地址可以保持不变，但是其物理地址必然会发生变化，因而需要在MCP中重新注册该缓冲区中各页面的物理地址。此外，接收缓冲区和事件缓冲区在恢复过程中也都需要同样的处理。

(四)接收缓冲区

MX中的接收缓冲区是8MB的主机内存，由MCP写入，用户进程读取。该缓冲区的使用是以页面为单位，其逻辑结构为环形。MCP在处理一个网络接收事件时，只要接收到的用户数据长于RECV_INLINE_SIZE(默认为43字节)，就会顺序地从该缓冲区分配一个页面。在对应的用户级接收事件中，MCP通过该页面在接收缓冲区中的编号告知用户数据的位置。MX通信库在处理短消息和长消息的接收事件时，会将用户数据再次拷贝到由用户提供的接收缓冲区中。

当MX通信库将用户数据从接收缓冲区中的某个页面读取完毕之后，出于性能考虑，并不会清空该页面。对于通信***的故障时检查点切取过程，用户地址空间中未清零的页面就会被保存到检查点文件中。这就意味着接收缓冲区中大量已经处理过的内容都会被保存。为了避免这一现象，以减少检查点保存开销，本发明实施例采取了如下措施，如图6所示，MCP在填写接收缓冲区之后，递增recvq_vpage_index。MX通信库在读取一个接收缓冲区页面之后，递增recvq_offset。该变量的物理地址被注册到MCP，以使MCP在检查点过程中可以读取其当前值。于是，在MX检查点中只需要保存图6中的斜线部分即可。

(五)事件缓冲区

MX中的事件缓冲区是128KB的主机内存，由MCP负责填写，用户进程读取。该缓冲区的分配单位是64字节，即一个事件结构的长度。MCP所填写的事件类型包括发送完成事件、短消息和长消息的接收完成事件、连接请求及其应答等。MX通信库顺序处理事件缓冲区中新到达的事件，以清空每个事件结构中的类型域作为处理完毕的标志。由于该缓冲区与接收缓冲区同为较大的环形缓冲区，因此本发明也采取了上述的减少检查点保存长度的优化措施。

(六)RDMA窗口

MX采用RDMA方式传递大于100KB的消息，而RDMA消息的发送缓冲区和接收缓冲区需要分别被注册为一个RDMA窗口。每个RDMA窗口的详细注册信息位于主机方内存中，包括RDMA窗口号、注册顺序号、窗口基址、窗口长度以及每个页面的物理地址等数据。向MCP中注册的RDMA窗口信息仅包括RDMA窗口号、注册顺序号、窗口长度和主机方注册页表的基址。在上述的RDMA消息的发送或者接收过程中，MCP每次仅读取8个或者32个页面的物理地址。

MX端口的检查点切取过程需要对RDMA端口进行特殊处理，以避免被检查点过程中断的RDMA通信在恢复过程中导致通信故障。

首先，在MX端口检查点过程中处于打开状态的RDMA窗口在MX端口恢复过程中需要重新注册。

其次，在MX端口的恢复过程中，如果发现有尚未完成的RDMA请求，就从读取主机方的窗口注册信息开始重新进行RDMA通信。

(七)MCP中的相关数据结构

位于网卡存储器中的端口控制块是记录一个MX端口当前状态的最重要结构，其内容包括发送请求队列地址、短消息发送缓冲区地址、中消息发送缓冲区、接收缓冲区和事件队列的注册信息以及后两者当前的写指针、发送句柄链表的头指针等。发送句柄用于记录一个发送请求的处理状态，同属于一个MX端口的发送句柄都在一个单向链表中。在一个MX端口的检查点过程中，当该端口的收发操作均被冻结之后，上述端口信息就会被(远程)读取并写入进程检查点映像中。

下面详细说明本发明的通信***的检查点切取方法，其以MX通信为例说明进行设备检查点切取过程。

MX通信***将Myrinet网卡以字符设备文件的形式提供给用户程序使用。于是，如果在进程检查点过程中发现目标进程打开了MX设备，就可以开始执行MX通信设备的检查点过程。在本发明实施例中，MX端口的检查点切取操作包括以下步骤：

步骤S100，读取MX设备文件的private_data域所指向的MX端口状态结构。

该结构位于核心地址空间，包含端口号、网***，以及接收缓冲区和事件队列等结构的基址和当前的读取指针等信息。

步骤S200，向目标端口所在的Myrinet网卡发送冻结指定端口的命令。

步骤S300，如果已确认主机方的目标进程已经停止运行，保存用户进程能够写入的发送请求队列和各发送缓冲区，否则需要首先向目标进程发送暂停运行的远程中断。

步骤S400，在通信协处理器确认目标端口已冻结之后，保存用户空间的接收缓冲区和事件队列，以及网卡上的端口控制块和所有该端口正在使用中的发送句柄。

MX中的接收缓冲区和事件队列均由MCP通过DMA方式来填充，而MCP的运行完全独立于主机方的进程，即使主机方的进程由于正常的进程调度或者***崩溃而停止运行之后，MCP仍会接收新的消息并填充主机方的相关队列。为防止接收数据的丢失和保持数据完整性，应确保在保存通信协处理器可写的各个主机方结构之前，通信协处理器已经停止了对应端口的接收操作。

下面说明本发明的通信***的检查点恢复过程。

MX端口的检查点恢复过程的内容包括MX端口的重新创建、MX端口的重定位和消息的重新发送，其中消息的重新发送是对MX端口的检查点中保存的所有发送句柄的按序重新执行。

(A)MX端口的重建

在重新创建MX端口时，需要将原MX端口在检查点中保存的内容分别填入新创建的MX端口中的对应位置，包括MCP中的端口控制块、发送请求队列、小消息发送缓冲区和操作***核心中的端口状态结构。对于在用户地址空间中的中消息发送缓冲区、接收缓冲区和事件缓冲区，其恢复方法与用户地址空间中的其它区域无异。

(B)MX端口的重定位

在MX端口检查点的恢复过程中，MX端口的重定位关系到端口恢复之后的通信过程是否可能继续进行。该问题涉及到MX通信***中的多个组成部分。在通信固件层，每一个Myrinet网卡都有一个以00:60:DD开头的MAC地址，这是其唯一标识。当一个Myrinet网卡接入Myrinet网络之后，还可以由其在网络中的位置而被唯一地定位。Myrinet映射器在探测到网络的拓扑之后，计算出任意两个网卡之间的路由信息，并填充到通信固件层的指定位置。在通信过程中，一个MX端口与其它每个端口之间的链接状态都分别维护于一个Partner结构之中，这是实现端到端的可靠通信的重要数据结构。该结构中主要包括发送消息序号、接收消息序号、当前链接的会话序号和目标MAC地址等。于是，在MX通信***中，用户可见的目的地址由三部分组成：目的端口号、目的网卡在本地MCP中的路由索引号和该目的地址对应的Partner结构的指针。

在MX端口的恢复过程中，原有通信端口的端口号和所在网卡的地址都有可能发生变化，因此，端口重定位的目的就是消除上述变化对后续通信过程的影响。

下面详细说明本发明的通信协议的检查点的断点恢复方法，其以MX通信断点恢复方法为例而进行说明。

通信协议的断点恢复方法用于支持因进程检查点等原因而导致的通信过程中断。该方法的思路是首先获取相互通信的一组底层通信***的全局检查点，随后再进行恢复。在本发明实施例所采用的MX通信***中，该方法的实现基于对原有的消息应答机制的扩展。

在采用消息应答机制的通信***中，发送方通过接收应答消息来确认每个消息的成功送达。对于未在指定时间内得到应答的消息，发送方一般需要重新发送。这就意味着发送方记录着任何一个尚未得到应答的消息。从通信***的角度来看，已经发出，但尚未得到应答的消息就可以认为是中途消息，而传统意义上的检查点过程中的中途消息则是指发送方的进程已经发送，但是尚未被接收方的进程接收的消息。本文以下所指的中途消息都是相对于通信***而言的中途消息。在获取通信***全局检查点过程中，发送方主动地保存本地的中途消息比接收方被动地等待所有接收信道中的驱赶消息要更快捷和灵活，并且其开销不会随着***规模增大而呈指数增长，比较适合于大规模机群应用的检查点过程。本文所采用的通信***全局检查点的获取方法的特点就是每个通信***在检查点过程中只记录本地通信***的状态，避免全局协同；在恢复过程中重发中途消息，并过滤可能的重复消息。

在本发明的断点恢复方法中，令发起通信断点的MCP主动地通知其它MCP停止向其发送消息，并在断点恢复过程中主动地通知其它MCP恢复通信。为了减少通信断点对并行应用的影响，在通信断点恢复之前，可以使不涉及通信断点发起者的通信继续进行。设发起通信断点的MCP为MCPi，断点恢复方法的包括如下步骤：

MCPi：

1.冻结本地通信端口的收发操作

2.保存已冻结端口的状态

3.向其它MCP广播M(CKPT，i)

——进程恢复过程——

1.向其它MCP广播M(WAKE，i)

正常结点的MCP：

如果收到M(CKPT，i)：

1.设～MCP.state＝PRECKPT

2.启动对发送请求目的地和接收缓冲区剩余空间的检查，即如果下一个消息的发送目的地为MCPi或者接收缓冲区剩余空间少于预定值：

(1).冻结本地通信端口的收发操作

(2).通过中断中止该进程的执行

(3).设本地MCP.state＝CKPT。在该状态下对后续收到的每个消息，都会应答消息M(NACK\_CKPT，i)

如果收到～M(NACK\_CKPT，i)：

1.冻结本地通信端口的收发操作

2.通过中断中止该进程的执行

3.设本地MCP.state＝CKPT

如果收到M(WAKE，i)：

1.如果MCP.state＝PRECKPT：

(1).若未曾收到M(CKPT，j)，(j≠i)，则设MCP.state＝RUNNING

2.如果MCP.state＝CKPT：

(1).继续处理因M(CKPT，i)而受阻的发送请求

(2).若未曾收到M(CKPT，j)，(j≠i)，则：

(a)设MCP.state＝RUNNING

(b)唤醒主机进程

在该方法的实现中，检查点控制消息采用可靠传输模式，即每个消息需要接收方返回应答消息。如图7所示，是该方法的一个四进程示意图。当MCP1、MCP2等收到M(CKPT，0)之后，进入PRECKPT状态，它们之间的通信仍可继续进行，例如消息M1。MCP1在消息M2的第一次发送过程中发现其接收方MCP0正处于检查点状态，因而进入端口冻结状态(MCP.state＝CKPT)。随后，当MCP1收到消息M3时，返回应答消息M(NACK_CKPT，0)，从而使MCP3也进入端口冻结状态。当MCP1接收到M(WAKE，0)，进入正常运行状态时，它将继续发送M2。

如果发起断点的MCP能够持续运行，较佳地，那么还可以利用该MCP维护网络状态的一致性，以减少一次广播操作，即发起断点的MCPi不通过广播M(CKPT，i)的方式主动通知其它的MCP停止向其发送消息，而是在应答已经收到的消息时，通知该消息的发送方停止向其发送。进一步，可以通过记录每个MCP所发送的M(CKPT，i)或者M(NACK_CKPT，i)的目的地的方式，避免M(WAKE，i)消息的广播，但这会增大断点恢复过程的开销。

较佳地，本发明采用了以下的二叉树广播算法，以加速上述方法中的广播过程。

1、对于发起广播的MCPi

如果(i>0)，向MCPi-1发送M(CKPT，i)；

如果(i<(N-1))，向MCPi+1发送M(CKPT，i)；

2、对于收到M(CKPT，i)的MCPj：

如果(0≤(2*j-i)<N)，向MCP2j-i发送M(CKPT，i)；

如果(j<i)且((2*j-i-1)≥0)，向MCP2j-i-1发送M(CKPT，i)；

如果(j>i)且((2*j-i+1)<N)，向MCP2j-i+1发送M(CKPT，i)；

3、每个MCP只有等到其发送的所有M(CKPT，i)都被应答之后，才能完成。

为了支持多个结点同时出现故障的情况，如果一个MCP通过CKPT消息的接收或者发送超时发现其发送目标MCPk已经出现了故障，它就主动代替MCPk发送上述算法所要求的两个广播消息，如图8所示。显然，这是一个递归处理过程。

本发明实施例在如下的测试平台上进行了MX设备检查点的性能测试：结点的硬件平台为2路1.6GHz AMD Opteron处理器，2GB内存；网卡为MyricomPCIXD-2，其通信协处理器和存储器的主频均为225MHz。结点操作***核心为Linux-2.6.12；MPICH的版本为1.2.6；通信***检查点的实现基于MX1.1.0版本。该测试所选的程序是在结点间进行不间断的密集消息传递的乒乓测试。在一个MX端口的检查点过程中，端口冻结和端口唤醒过程的开销分别约为16.0微秒和8.6微秒，将网卡上的端口状态保存在检查点映像中的开销约为54微秒，如图9所示。

下面详细说明本发明的结点监测，即一种单机检查点切取方法，也可以称为单机故障时检查点切取方法。

单机故障时检查点切取是机群故障时检查点切取的基础，其实现依赖于进程状态的保存、结点故障的检测等结点级支撑技术和基于远程内存访问的远程检查点机制，不涉及对进程间通信状态的保存和恢复。

步骤S1000，进程完整状态保存

一个进程的完整状态可能包括位于CPU、内存和磁盘等不同部件中的多个部分。针对故障时检查点的特点，需要根据以上各个部件的特点分别采取对应的方法获取其中所含的进程状态。对于内存中的状态，即使目标结点的操作***陷入崩溃状态，依然可以通过RDMA方式进行访问。对于CPU内部的通用寄存器、浮点寄存器，由于无法在***故障时通过指令来读取，因此，本发明采取在进程正常运行时主动地予以保存的策略。

步骤S1001，CPU通用寄存器的保存

当CPU改变运行级别的时候会因上下文的切换而保存各种寄存器的当前值。以Linux2.6的X86\_64实现代码为例，当CPU要进入核心态时，将各个通用寄存器、状态寄存器都保存在当前进程的核心堆栈的顶部，如图10所示。

步骤S1002，浮点寄存器的保存

在科学计算应用中频使用的浮点处理器(Floating-Point Processor，FPU)中的状态往往较多。在本发明实施例的平台中，Opteron处理器的FPU状态包括16个128位的XMM寄存器(XMM0～XMM15)、8个128位的浮点寄存器和数个FPU的控制寄存器，共计512字节。为了避免在每次进程上下文切换时都要保存FPU的状态，X86/X86_64系列处理器都内建了专门的优化机制，一般称为Lazy Context-Switching。该机制是基于操作***中的大部分进程都不用或者不常用FPU，将FPU的状态保存推迟到另一个进程需要使用FPU的时刻。当CR0寄存器的TS(Task Switch)位为1时，CPU如果试图执行X87指令或者媒体指令就会触发#NM(Device-Not-Available)异常，操作***在该异常的处理中会先将FPU的内容保存至其对应进程的指定空间，然后再加载当前进程的FPU内容。

步骤S1003，CPU高速缓存的保存

故障时检查点不依赖目标结点的CPU在故障时执行任何特定的操作，这意味着CPU高速缓存中的内容不能在检查点切取之前及时地写入内存。基于X86多处理器体系结构中通过总线监听(Bus Snoopying)协议实现的缓存一致性，可以在检查点切取过程中得到指定内存地址的最新数据内容。在结点故障出现之后，如果CPU收到RESET信号，那么其所有寄存器的状态将被重置，内部高速缓存中的数据也会立刻全部失效，而不会被写回内存。

步骤S2000，结点故障的检测

准确而高效的结点故障检测是实现***故障的预防和快速恢复的前提。从实现级别的角度，结点故障检测一般可以在操作***和应用程序(进程)两个层次分别实现。对于操作***故障检测***的设计，最主要的问题可以归结为检测手段和检测对象这两个方面。本发明实现了基于协处理器并从多个角度检测操作***状态的方法。

步骤S2100，基于协处理器的结点故障检测方法。

以往的结点故障检测***一般依赖主机方CPU进行操作***的状态自检，例如基于软件或者硬件看门狗计数器(Watchdog Timer)的方法。这些方法对于主机方CPU的依赖使其无法处理CPU关中断或者相应的控制结构已被破坏等情形。为了避免以上问题，同时避免采购专用的结点状态监测硬件所带来的成本，本发明实施例可以采取利用通信协处理器监测主机状态的方法。目前，通信协处理器在机群高速通信***中日益普及，其性能也得到了较快的提升。

本发明实施例中，基于协处理器的结点状态监测方法是首先将给定的主机状态监测变量的物理地址向协处理器注册，随后每隔一定时间由协处理器自动读取各监测变量，并与预设的阈值相比较，以判断结点状态是否正常。

在该监测功能的实现中，本发明实施例利用了LanaiX通信协处理器中的时钟中断机制。LanaiX的内部计时器IT2会按2MHz的频率递减其赋值，一旦变为0的时侯就触发其对应的时钟中断。在该中断中，LanaiX发起读取主机方指定内存地址的DMA操作以读取本文所选的各个监测变量的当前值。

步骤S2200，操作***故障的检测方法。

步骤S2210，时钟中断计数

对于常见的Unix、Linux等通用操作***而言，进程调度、***资源监控、***时间的维护都依赖于时钟中断。可以说，时钟中断的故障不但是操作***出现死等严重故障的重要原因，也是操作***陷入严重故障的重要表现之一。在Linux操作***中，时钟中断的频率一般设为每秒钟100到1000次。在每一次时钟中断中递增的jiffies/jiffies_64变量维护着操作***已处理的时钟中断的计数。本发明实施例以该变量在每个监测周期中是否发生与监测周期相符的变化作为判断主机操作***是否正常的基本标志。

时钟中断计数方法需要着重考虑协处理器监测周期的精度问题，以避免由于监测周期长度的浮动而造成的故障误报。

LanaiX处理器中有一个频率为2MHz的实时时钟寄存器(Real-Time Clock，RTC)，可以根据其读数，精确地记录每个监测周期的时间长度。在本发明中，设每个监测周期的主机方时钟中断计数上下浮动的差值小于5为正常，否则即认为主机方操作***出现了严重的拒绝服务故障。

该方法的优势是不需要修改操作***，同时能够精确检测严重的操作***核心拒绝服务故障。

步骤S2220，操作***故障计数

作为一种可实施方式，该监测变量基于对Linux操作***的故障处理方法的扩展。这些扩展包括对关键的核心函数接口和***调用接口的返回值的检测和记录。

在Linux操作***的核心代码中存在很多对于用户进程或者其它核心模块的正常运行至关重要的函数接口，例如各种***调用接口，以及kmalloc()、kmem_cache_alloc()等核心存储管理接口。这些函数接口的失败返回往往会导致调用模块的故障，甚至失效。在原有的Linux核心代码中，对于这些函数接口的失败返回的处理一般较为简单，例如向更上一级返回错误代码，或者不做任何判断继续执行。

为了支持对操作***故障更细粒度、更及时的检测，本文提供了对关键性的核心接口函数的返回值的检测功能。本发明设置unlucky()宏用于检测函数返回值。

#define unlucky(condition，level)

do{

         if(unlikely((condition)！＝0)){

                   inc_danger_level(level)；

         }

}while(0)

当unluck()的第一个参数中“返回值为NULL”等条件成立时，其第二个参数就会被增加到本文定义的操作***故障计数变量中。该变量的地址被注册到了监测操作***状态的协处理器中，并由其定时读取。

unlucky()宏被添加到了存储管理、进程调度管理等多个核心功能模块的代码之中，其能够及时地反映***故障的数量。

与监测时钟中断计数的方法相比，该方法能够支持更高的监测频率，但是需要对操作***的代码做少量的修改。同时，该方法也完全可以用于对用户进程的故障计数，例如在Glibc中嵌入故障计数功能。将位于用户空间的故障计数变量的物理地址注册到监控***状态的协处理器中。

步骤S2230，操作***严重故障代码检测方法。

前述的两种用于监测操作***状态的变量都位于主机方内存中，由协处理器通过DMA方式定时读取，本发明还提供了第三种向协处理器报告结点故障状态的方法。在该方法中，主机方操作***会主动地将一个故障代码通过PIO方式写入协处理器的存储器中。由于对该故障代码的访问不必读取主机方的内存，协处理器就能够以更高的频率监测结点状态。这一方法主要用于操作***的故障可以得到确认的场合。目前，该方法主要用于扩展Linux操作***中原有的处理严重故障的BUG()、panic()等函数接口。

步骤S3000，远程检查点目标进程的状态检测

核心级检查点***可以方便地利用信号、***调用等机制控制和影响目标进程的运行，使其在检查点过程开始之前到达指定的状态。远程检查点***则无法方便地控制目标进程的运行，因此，在远程检查点过程开始之前，目标进程的状态存在多种可能性。远程检查点可以包括以下两种状态的目标进程检测：

(一)故障结点中的进程检测：

对于仅能通过操作***故障计数机制检测出的故障结点，由于目标进程仍可能处于运行状态，因此需要利用上述的远程中断机制中止其运行。对于通过操作***时钟中断计数和严重故障代码而检测出的故障结点，故障时检查点***已经不能再利用远程中断机制控制其任何一个进程的状态。尽管无法确认远程检查点的目标进程的具体状态，但是根据上述故障的特点，可以确认目标进程已经通过***调用、中断或者异常进入了核心态。只要目标进程不在用户上下文中运行，远程检查点就可以对其执行检查点操作。

(二)远程中断中止的进程检测方法

为了使远程检查点可以用于机群管理等目的，可以在目标进程正常运行的情况下，通过远程中断功能中止其运行。远程中断是借助通信设备在接收到带有特定标志的消息之后触发主机方中断而实现。

为了避免在中断处理程序中进行进程调度，为每个CPU都建立了远程中断请求结构。该结构由远程中断服务程序填写；当每个CPU进入调度模块时会检查该结构，以判断是否需要立即中止或者继续某个进程的运行。如果要使目标进程在最短的时间内中止运行就是要令其所在的CPU尽快进入进程调度模块。作为一种可实施方式，在支持抢占式调度的Linux 2.6操作***内核中，CPU从各种中断服务程序中退出就是一个进入进程调度模块的时机。

所述远程中断的服务程序的基本流程如下：

1、查找指定进程号对应的进程控制块。

本发明实施例记该进程所在的CPU为CPUTarget，而执行远程中断服务程序的CPU为CPUIntr。

2、填写远程中断请求结构。

3、若CPUTarget＝CPUIntr，则直接设置被中断进程的NEED_RESCHED标志；否则，向CPUTarget发送中断向量为RESCHEDULE_VECTOR的处理器间中断。

随后，CPUTarget在进程调度模块中响应远程中断请求结构中注册的请求，并在完成该请求之后更新其中的请求状态标志。

本发明的一种机群容错***、装置及方法，其是一种针对并行应用的机群故障时检查点机制，旨在为并行应用提供局部化的快速故障恢复。对于全局检查点***，并行应用中所有进程的状态需要在其正常运行的过程中周期性地写入非易失性存储设备并保持进程间通信状态的一致性，而机群故障时检查点机制的核心思想则是在并行应用正常运行时仅保存CPU状态等在结点故障时无法获取的状态。当发现故障时，对故障结点上的进程远程执行检查点，保存其通信***的状态，并通过机群通信协议保证通信中断后的正确恢复；

本发明还提出了基于远程直接内存访问技术的远程检查点方法机制。该技术利用远程直接内存访问的通信过程无需目标结点的CPU和操作***参与的特点和机群高速通信***的优异性能，在目标结点的操作***拒绝服务等故障条件下能高效地切取应用状态。该技术使应用程序与操作***的依赖关系变得松散，操作***的故障不会威胁到被服务进程的继续运行。

本发明还实现了用户级机群通信***的检查点和恢复方法机制。该机制利用机群通信***中的应答、重发和消息缓冲等通信可靠性保障方法机制，降低了并行检查点过程对维护通信***全局一致性状态的要求，减少了进程的检查点和恢复过程的开销。

本发明还在用户级机群通信***的检查点和恢复机制的基础上，探索了机群通信协议如何对并行应用的故障时检查点和恢复操作提供支持，提出了针对并行应用中单个进程的检查点的通信断点恢复的方法机制。

本发明还实现了支持故障时检查点的结点级容错方法机制，包括基于协处理器的结点故障检测技术和基于进程运行上下文切换的CPU寄存器状态保存技术，能够实现结点故障的快速检测并确保目标进程的状态在结点故障发生之后的完整性。

本发明还实现了一个轻量级的并行程序故障时检查点和恢复***(Crash-Time ChecKpoint and Restart system，CTCKR)。该***仅当一个并行应用因其所在的一结点的操作***崩溃而无法继续运行时才触发检查点和恢复操作，避免了定期地频繁执行检查点所带来的时间开销，并且该***仅仅针对故障结点中的相关进程进行检查点和恢复，而无需执行全局检查点，因而存储开销也显著降低。

通过利用NPB(NAS Parallel Benchmarks)、LINPACK等基准测试程序的评测实验表明，本发明的机群容错***、装置及方法在各项性能测试和基于故障注入的正确性测试中都很好地达到了设计目标，这充分表明了本发明的机群容错***、装置及方法是一种可行的轻量级机群容错技术。

通过结合附图对本发明具体实施例的描述，本发明的其它方面及特征对本领域的技术人员而言是显而易见的。

以上对本发明的具体实施例进行了描述和说明，这些实施例应被认为其只是示例性的，并不用于对本发明进行限制，本发明应根据所附的权利要求进行解释。

Claims (17)

1、一种机群容错***，其特征在于，包括如下功能模块：

远程检查点服务器，用于响应来自故障结点的远程检查点请求，执行检查点操作；

结点故障检测模块，用于监测本地结点的操作***和指定进程的运行状态，触发远程检查点；

通信***检查点模块，用于实现通信设备的检查点，并支持通信断点恢复功能。

2、根据权利要求1所述的机群容错***，其特征在于，还包括下列功能模块：

并行应用进程管理器，用于为故障时检查点***提供被监测应用的进程信息，并管理进程恢复过程；

检查点文件服务器，用于存储检查点文件，并在故障时检查点的恢复过程中提供检查点文件访问支持。

3、一种机群容错处理方法，其特征在于，包括下列步骤：

步骤A1.并向进程管理器在收集到所有子进程的基本信息之后，向远程检查点服务器发送应用注册请求，所述远程检查点服务器在接收该请求之后，根据所述注册请求中包含的进程信息，向所有相关结点的结点故障检测模块发送结点监控请求；

步骤B1.所述远程检查点服务器收到有效的故障报告之后，启动远程检查点过程，在所述远程检查点过程成功结束之后，所述远程检查点服务器将所得到的检查点映像文件的位置和对应进程信息发送给所述并行进程管理器；

步骤C1.所述并行进程管理器确定进程恢复所用的结点，并向目标结点发送恢复进程的命令。

4、根据权利要求3所述的机群容错处理方法，其特征在于，所述步骤A1之后，步骤B1之前，还包括下列步骤：

步骤S1.在被监测应用的运行过程中，结点故障检测模块定期主动监测所属结点的操作***的故障，同时接收和处理结点故障恢复请求；

步骤S2.当所述结点故障检测模块探测到故障或者收到故障恢复请求时，冻结所属结点的所有被监测的进程打开的通信端口，向预设的远程检查点服务器发送故障报告，请求所述远程检查点服务器对指定的进程实施远程检查点。

5、一种远程检查点切取***，其特征在于，包括：

内核符号寻址模块，用于对目标进程所在结点的操作***的内核符号的寻址；

数据缓存模块，用于数据的缓存和预取；

指针模块，用于指针操作，在目标结点中数据结构的地址进行比较之前，查询维护原地址和缓存地址对应关系的哈希表，将缓存地址全部转换为目标结点中的原始地址后再进行比较。

6、一种远程检查点切取方法，其特征在于，包括下列步骤：

步骤S10，加载目标结点的操作***符号表；

步骤S20，加载目标结点的操作***核心类型表；

步骤S30，根据目标进程号查找目标进程的进程控制块，并复制到本地缓冲区中；

步骤S40，创建远程检查点映像的文件头；

步骤S50，保存根目录和当前工作目录的完整路径；

步骤S60，保存目标进程的文件描述符表；

步骤S70，逐一保存目标进程已打开文件的基本信息；

步骤S80，为远程检查点映像文件加入末尾标记。

7、根据权利要求6所述的远程检查点切取方法，其特征在于，所述步骤40进一步包括：

步骤S41，保存目标进程的基本属性；

步骤S42，保存CPU的状态信息，包括通用寄存器、调试寄存器和协处理器的状态；

步骤S43，保存信号处理信息；

步骤S44，保存进程的虚拟地址空间。

8、一种远程检查点恢复***，其特征在于，包括：

状态区分模块，用于区分目标进程的状态，以避免对寄存器的误用；

跳板模块，用于恢复完整的通用寄存器状态，使进程都以IRET指令退出核心态，从核心空间返回用户空间。

9、一种远程检查点恢复方法，其特征在于，包括如下步骤：

步骤S10′，检查点恢复工具创建一个子进程，并开始等待其执行完成或异常退出；

步骤S20′，根据检查点文件的头部信息判断其合法性；如果头部信息中标明的操作***不符合预期，则退出；否则，进入下一步骤；

步骤S30′，重新设置目标进程的基本属性；

步骤S40′，恢复目标进程核心栈中的CPU状态部分；

步骤S50′，恢复目标进程中信号处理的相关信息；

步骤S60′，解除宿主进程的所有虚拟存储区域的映射；

步骤S70′，加载目标进程的所有虚拟存储区域的映射；

步骤S80′，设置目标进程的虚拟地址空间描述信息；

步骤S90′，恢复目标进程的根目录和当前工作目录的路径；

步骤S100′，关闭宿主进程的各个文件；

步骤S110′，逐一恢复目标进程已打开文件的基本信息；

步骤S120′，设置目标进程的状态为可运行，使其退出远程检查点恢复过程之后可以被正常地调度执行。

10、根据权利要求9所述的远程检查点恢复方法，其特征在于，所述步骤步骤S40′进一步包括：

步骤S41′，如果检查点中的进程状态标记表明目标进程是在一***调用失败之后被切取，则设置目标进程的RIP和RAX使目标进程恢复运行之后，重新执行该***调用，否则，执行步骤S42′；

步骤S42′，目标进程是通过中断、异常进入核心态之后被切取，直接设置辅助目标进程返回用户态的跳板程序的地址。

11、一种通信***的检查点切取方法，其特征在于，包括下列步骤：

步骤S100，读取通信设备文件所指向的端口状态结构；

步骤S200，向目标端口所在的网卡发送冻结指定端口的命令；

步骤S300，如果已确认主机方的目标进程已经停止运行，保存用户进程能够写入的发送请求队列和各发送缓冲区，否则需要首先向目标进程发送暂停运行的远程中断；

步骤S400，在通信协处理器确认目标端口已冻结之后，保存用户空间的接收缓冲区和事件队列，以及网卡上的端口控制块和所有该端口正在使用中的发送句柄。

12、一种通信***的检查点恢复方法，其特征在于，包括下列步骤：

步骤S100′，端口的重建，将原端口在检查点保存的内容分别填入创建的端口的对应位置；

步骤S200′，端口的重定位。

13、一种通信的断点恢复方法，其特征在于，包括下列步骤：

步骤1.冻结本地通信端口的收发操作；

步骤2.保存已冻结端口的状态；

步骤3.向其它MCP广播。

14、一种单机故障时检查点切取方法，其特征在于，包括下列步骤：

步骤S1000，进程完整状态保存；

步骤S2000，结点故障的检测；

步骤S3000，远程检查点目标进程的状态检测。

15、如权利要求14所述的单机故障时检查点切取方法，其特征在于，所述步骤S1000进一步包括：

步骤S1001，当CPU改变运行级别时，保存各种寄存器的当前值；

步骤S1002，当一个进程需要使用浮点寄存器时，保存所述浮点寄存器的状态；

步骤S1003，保存CPU高速缓存。

16、如权利要求14所述的单机故障时检查点切取方法，其特征在于，所述步骤S2000进一步包括：

步骤S2100，将给定的主机状态监测变量的物理地址向协处理器注册，每隔一定时间由所述协处理器自动读取各监测变量，并与预设的阈值相比较，以判断结点状态是否正常；

步骤S2210，对时钟中断计数，通过判断用于维护操作***已处理的时钟中断的计数的变量在每个监测周期中是否发生与监测周期相符的变化来确定操作***是否正常；

步骤S2220，操作***故障计数；

步骤S2230，检测操作***严重故障代码。

17、一种远程中断中止的进程检测方法，其特征在于，包括下列步骤：

步骤N1，查找指定进程号对应的进程控制块；

步骤N2，填写远程中断请求结构；

步骤N3，若该进程所在的CPU标识等于执行远程中断服务程序的CPU标识，则直接设置被中断进程的标志；否则，向该进程所在的CPU发送处理器间中断；

随后，该进程所在的CPU在进程调度模块中响应远程中断请求结构中注册的请求，并在完成该请求之后更新其中的请求状态标志。

Images