故障恢复的方法和装置与流程

本发明涉及计算机领域，并且更具体地，涉及故障恢复的方法和装置。

背景技术：

随着计算机技术的飞速发展，越来越多的行业利用计算机技术提高本行业的工作效率。

在计算机系统中，计算机主要依靠执行进程来实现其功能，当进程出现故障甚至失效时，可能影响程序乃至整个计算机系统的正常运行，因此，如何实现进程的故障恢复，成为急需解决的问题。

目前，已知一种故障恢复的方法，通过周期性备份记录有进程正常时的计算状态的恢复文件，在运行有该进程的节点出现故障而导致该进程出现故障时，在与该节点相对应的恢复节点，基于所保存的恢复文件对该进程进行恢复处理。

但是，当该节点所对应的恢复节点也出现故障时，将无法实现该进程的恢复，严重影响了故障恢复的可靠性。

技术实现要素：

本发明实施例提供一种故障恢复的方法和装置，能够提高故障恢复的可靠性。

第一方面，提供了一种故障恢复的方法，该方法包括：确定N个失效进程中每个失效进程所对应的恢复文件的大小，并确定M个恢复节点中每个恢复节点的运行状态，其中，N≥1，M≥2；根据每个失效进程所对应的恢复文件的大小以及每个恢复节点的运行状态确定每个失效进程所对应的恢复节点，其中，该运行状态包括资源使用状态；对每个失效进程所对应的恢复节点进行控制，以在每个失效进程所对应的恢复节点，对每个失效进程进行故障恢复。

结合第一方面，在第一方面的第一种实现方式中，该N个失效进程中的 第一失效进程所对应的恢复文件存储在至少两个存储节点中。

结合第一方面及其上述实现方式，在第一方面的第二种实现方式中，在各该存储节点中存储的该第一失效进程所对应的恢复文件相同。

结合第一方面及其上述实现方式，在第一方面的第三种实现方式中，该第一失效进程所对应的恢复文件包括至少两个子恢复文件，在各该存储节点中存储的子恢复文件不同。

结合第一方面及其上述实现方式，在第一方面的第四种实现方式中，当N≥2时，该根据每个失效进程所对应的恢复文件的大小以及每个恢复节点的运行状态确定每个失效进程所对应的恢复节点，包括：根据每个恢复节点的运行状态，基于每个失效进程所对应的恢复文件的大小，按照从大到小的顺序，依次确定每个失效进程所对应的恢复节点。

结合第一方面及其上述实现方式，在第一方面的第五种实现方式中，一个失效进程所对应的恢复节点与同一失效进程所对应的存储节点不同。

结合第一方面及其上述实现方式，在第一方面的第六种实现方式中，该根据每个失效进程所对应的恢复节点进行控制，包括：根据每个失效进程所对应的恢复节点的运行状态和每个失效进程所对应的恢复文件的大小，估计每个失效进程的恢复时间；根据每个失效进程的恢复时间，进行控制。

第二方面，提供了一种故障恢复的装置，该装置包括：确定单元，用于确定N个失效进程中每个失效进程所对应的恢复文件的大小，及M个恢复节点中每个恢复节点的运行状态，并根据每个失效进程所对应的恢复文件的大小和M个恢复节点的运行状态，确定每个失效进程所对应的恢复节点，其中，该运行状态包括资源使用状态，N≥1，M≥2；处理单元，用于对每个失效进程所对应的恢复节点进行控制，以在每个失效进程所对应的恢复节点，对每个失效进程进行故障恢复。

结合第二方面，在第二方面的第一种实现方式中，该N个失效进程中的第一失效进程所对应的恢复文件存储在至少两个存储节点中。

结合第二方面及其上述实现方式，在第二方面的第二种实现方式中，在各该存储节点中存储的该第一失效进程所对应的恢复文件相同。

结合第二方面及其上述实现方式，在第二方面的第三种实现方式中，该第一失效进程所对应的恢复文件包括至少两个子恢复文件，在各该存储节点中存储的子恢复文件不同。

结合第二方面及其上述实现方式，在第二方面的第四种实现方式中，当N≥2时，该确定单元具体用于根据每个恢复节点的运行状态，基于每个失效进程所对应的恢复文件的大小，按照从大到小的顺序，依次确定每个失效进程所对应的恢复节点。

结合第二方面及其上述实现方式，在第二方面的第五种实现方式中，一个失效进程所对应的恢复节点与同一失效进程所对应的存储节点不同。

结合第二方面及其上述实现方式，在第二方面的第六种实现方式中，该处理单元具体用于根据每个失效进程所对应的恢复节点的运行状态和每个失效进程所对应的恢复文件的大小，估计每个失效进程的恢复时间，并根据每个失效进程的恢复时间，进行控制。

可见，根据本发明实施例的故障恢复的方法，根据失效进程所对应的恢复文件的大小和至少两个恢复节点的运行状态，从至少两个恢复节点中确定对该失效进程进行故障恢复的恢复节点，相比只有一个恢复节点可靠性更高，同时能够一定程度上确保所确定的恢复节点能够实现对失效进程的故障恢复，从而进一步提高故障恢复的可靠性。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例中所需要使用的附图作简单地介绍，显而易见地，下面所描述的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是根据本发明实施例的故障恢复的方法的示意性流程图。

图2是适用本发明实施例的故障恢复的方法的系统示意性架构图。

图3是根据本发明实施例的故障恢复的装置的示意性框图。

图4是根据本发明实施例的故障恢复的设备的示意性结构图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明实施例提供的故障恢复的方法和装置，可以应用于计算机上，该计算机包括硬件层、运行在硬件层之上的操作系统层，以及运行在操作系统层上的应用层。该硬件层包括CPU、存储器管理单元(MMU，Memory Management Unit)和内存(也称为存储器)等硬件。该操作系统可以是任意一种或多种通过进程实现业务处理的计算机操作系统，例如，Linux系统、Unix系统、Android系统、iOS系统或windows系统等。该应用层包含浏览器、通讯录、文字处理软件、即时通信软件等应用。应理解，以上列举的计算机设备仅为示例性说明，本发明并未特别限定。

图1是根据本发明实施例提供的故障恢复的方法100的示意性流程图，如图1所示，该方法100包括：

S110，确定N个失效进程中每个失效进程所对应的恢复文件的大小，并确定M个恢复节点中每个恢复节点的运行状态，其中，N≥1，M≥2；

需要说明的是，作为实例而非限定，在本发明实施例中，该失效进程指的是运行(或处理)的结果未能达到期望的进程，例如在运行的过程中就因故障被中止的进程，即该进程没有运行结果(也可以看做该进程的运行结果不符合预期)，又例如看似运行成功结束但运行结果却不符合期望的进程。

S120，根据每个失效进程所对应的恢复文件的大小以及每个恢复节点的运行状态确定每个失效进程所对应的恢复节点，其中，该运行状态包括资源使用状态；

需要说明的是，作为实例而非限定，该资源使用状态包括该恢复节点上的硬件利用率，例如CPU利用率和/或内存利用率。举例说明，若某一恢复节点的CPU利用率已经很高，即该恢复节点已经很繁忙，同时该失效进程对应的恢复文件又较大，即恢复该失效进程需要消耗较多资源，那么该恢复节点就不适合作为该失效进程的恢复节点。

可选的，在其他的实施例中，该运行状态还可以包括该恢复节点的通信状态，具体的，该通信状态指的是该恢复节点与其他节点的通信状态是可以通信还是不可以通信。举例说明，若某一恢复节点与存储失效进程A对应的恢复文件的存储节点不能通信，那么该恢复节点就不能作为该失效进程A的恢复节点。

S130，对每个失效进程所对应的恢复节点进行控制，以在每个失效进程所对应的恢复节点，对每个失效进程进行故障恢复。

图2示出了适用该方法100的计算机系统200的示意性架构图，如图2所示，计算机系统200包括管理节点210、多个存储节点220和多个恢复节点230和多个计算节点240，为了便于理解和说明，图2中仅示出一个计算节点240。

其中，各计算节点240运行有一个或多个进程。

并且，各计算节点240与一个或多个存储节点220通信连接，从而计算节点240能够将所运行的各进程的恢复文件传输至所连接的存储节点220进行备份。作为实例而非限定，在本发明实施例中，恢复文件可以是其进程在正常状态下运行时的数据。

另外，管理节点210与各计算节点240通信连接，从而管理节点210能够监控各计算节点240中所运行的各进程的运行状态。

此外，管理节点210与各恢复节点230通信连接，从而管理节点210能够监控各恢复节点230的运行状态，并向恢复节点230发送控制指令。

可选地，在本发明实施例中，各恢复节点230与各存储节点220可以通信连接，从而，恢复节点230在对进程进行恢复时，能够从存储节点220中获取恢复文件。

应理解，以上列举的各恢复节点230与各存储节点220的连接关系仅为实例性说明，例如，也可以使管理节点210与各存储节点220通信连接，并使恢复节点230通过管理节点210从存储节点220中获取恢复文件。

另外，在计算机系统200中，可以设置有与个节点通信连接的总线系统250，从而，能够通过总线系统250实现上述各节点之间的通信连接。

在本发明实施例中，一个节点可以是一台独立配置的计算机实体，或者，也可以多个节点配置在同一计算机实体，或者，也可以由多个计算机实体构成一个节点，本发明并未特别限定。

在本发明实施例中，该方法100可以由管理节点210执行，该管理节点210可以独立于计算机系统中的各节点(包括发生故障的计算节点240、用于存储失效进程的恢复文件的存储节点220和用于对失效进行故障恢复的恢复节点230)。并且，该管理节点与各节点通信连接，以传输控制指令或数据等信息；或者，该方法100也可以由该计算机系统200中集成有该管理节点的功能的一个或多个其他节点执行。

并且，本发明实施了的方法100应用于包括至少两个恢复节点的计算机 系统中，各恢复节点能够提供计算资源(例如，中央处理器和存储器等)，从而能够对失效进程进行恢复。

此外，管理节点可以指示恢复节点进行针对失效进程的恢复。

以下，为了便于理解和说明，以管理节点作为该方法100的执行主体，对该方法100的处理过程进行详细说明。

具体地说，在本发明实施了中，为了防止进程失效而影响业务服务，可以周期性的存储进程的恢复文件，例如，执行状态或计算状态，进程失效时，回滚到之前保存的某个状态处重新开始执行。

本发明实施例中的恢复文件用来记录进程在正常状态下运行时的数据，以便于根据该恢复文件记录的内容对每个失效进程进行故障恢复。在一些实施例中，该恢复文件可以是检查点文件，该检查点文件是基于检查点技术生成的；在另一些实施例中，该恢复文件可以是日志文件，该日志文件是基于日志技术生成的。需要说明的是，检查点文件或日志文件的生成可以由现有技术实现，不属于本发明涵盖的内容，因此在此不做详述。

应理解，以上列举的恢复文件的形式和所记录的内容仅为示例性说明，本发明并不限定于此，其他能够实现本发明实施例的恢复文件的功能的具体实施例均落入本发明的保护范围内。

在本发明实施了中，失效进程的数量可以为一个，也可以为多个，本发明并未特别限定，并且，当失效进程的数量为多个时，针对各失效进程的处理类似，以下为了便于理解和说明，以针对失效进程#A的处理为例，对本发明实施了的方法100的处理过程进行详细说明。

可选地，该N个失效进程中的第一失效进程所对应的恢复文件存储在至少两个存储节点中。

具体地说，在本发明实施了中，针对失效进程#A(即，第一失效进程的一例)，其所对应的恢复文件可以存储在该失效进程#A所对应的两个或两个以上的存储节点中。

这里，当存在多个失效进程时，任意两个失效进程的恢复文件所存储于的存储节点可以相同，也可以不同，本发明并未特别限定。

另外，上述“相同”可以包括：完全相同，例如，失效进程#A的恢复文件可以存储于存储节点#α和存储节点#β，失效进程#B的恢复文件可以存储于存储节点#α和存储节点#β；或者，部分相同，例如，失效进程#C的恢复 文件可以存储于存储节点#η和存储节点#θ，失效进程#D的恢复文件可以存储于存储节点#θ和存储节点#λ)。

类似地，上述“不同”可以包括：完全不同，例如，失效进程#A的恢复文件可以存储于存储节点#α和存储节点#β，失效进程#B的恢复文件可以存储于存储节点#γ和存储节点#δ；或者，部分不同，例如，失效进程#C的恢复文件可以存储于存储节点#η和存储节点#θ，失效进程#D的恢复文件可以存储于存储节点#θ和存储节点#λ)。

并且，以上列举的一个失效进程的恢复文件所存储于的存储节点的数量仅为示例性说明，本发明并未限定于此，例如，一个失效进程的恢复文件也可以只存储在一个存储节点。并且，当存在多个失效进程时，各失效进程的恢复文件所存储于的存储节点的数量可以相同，也可以不同，本发明并未特别限定。

在本发明实施了中，该失效进程#A所对应的恢复文件可以按以下方式存储在多个(至少两个)存储节点中。

方式1

可选地，在各该存储节点中存储的该第一失效进程所对应的恢复文件相同。

具体地说，在本发明实施了中，多个存储节点中可以存储有失效进程#A所对应的完整的恢复文件(以下，为了便于理解和区分，记做：恢复文件#A)。另外，“完整的恢复文件”是指，通过存储在一个存储节点中的恢复文件#A便能够对失效进程#A的故障处理。

根据本发明实施了的故障处理的方法，通过使在各该存储节点中存储的该第一失效进程所对应的恢复文件相同(即，各存储节点存储有一致的、完整的恢复文件)，在一个或多个存储节点发生故障时仍能够从其他的未发生故障的存储节点获取恢复文件，从而进一步提高故障处理的可靠性。

方式2

可选地，该第一失效进程所对应的恢复文件包括至少两个子恢复文件，在各该存储节点中存储的子恢复文件不同。。

具体地说，在本发明实施了中，可以将在恢复文件#A分割为多个子恢复文件(为了便于理解和区分，记做：子恢复文件#A₁～子恢复文件#A_X)。并将该子恢复文件#A₁～子恢复文件#A_X分别存储在多个存储节点中，其中，一 个子恢复文件可以存储在一个存储节点中，也可以(重复或分割地)存储在多个存储节点中，本发明并未特别限定，并且，任意两个子恢复文件所存储于的存储节点不同，或者说，各存储节点所存储的子恢复文件不同，这里，“不同”可以是完全不同，例如，对于子恢复文件#A₁和子恢复文件#A₂，子恢复文件#A₁可以存储于存储节点#1和存储节点#2，子恢复文件#A₂可以存储于存储节点#3和存储节点#4；或者，“不同”也可以部分不同，例如，对于子恢复文件#A₃和子恢复文件#A₄，子恢复文件#A₃可以存储于存储节点#5和存储节点#6，子恢复文件#A₄可以存储于存储节点#6和存储节点#7。

根据本发明实施例提供的故障处理的方法，通过将失效进程所对应的恢复文件分割为多个子恢复文件，并将各子恢复文件存储于相异的存储节点，能够在进行故障处理时同时从多个存储节点获取子恢复文件，从而能够减小传输恢复文件所需要的时间，提高故障处理的效率。

可选的，在一些实施例中，该“失效进程”的恢复文件的存储是在该进程有效(或者说，正常运行时)时周期性地进行的，即，在本发明实施了中，在计算机系统中运行的各进程，在该进程有效(或者说，正常运行)时，均周期性的存储其恢复文件。

在另一些实施例中，恢复文件也可以是在失效进程失效前存储在失效进行所运行的计算节点中，并在失效前上传至存储节点，即，恢复文件的备份也可以是周期性地进行的。

以上列举的恢复文件的存储方式仅为示例性说明，本发明并未限定于此，例如，各进程的恢复文件还可以统一的存储于一个存储节点。

本发明实施了的故障处理的方法可以在管理节点确定进程失效时执行，作为确定进程失效的方法，例如，在计算机系统中的各节点运行的进程可以周期性向管理节点发送心跳消息，如果管理节点在规定时间内未接收到某个进程的心跳消息，则可以认为该进程失效。应理解，以上列举的确定进程失效的方法仅为示例性说明，本发明并不限定于此，现有技术中能够确定进程失效的方法均落入本发明的保护范围内。

从而，在如上所述确定进程失效后，在S110，管理节点可以确定各失效节点所对应的恢复文件的大小，例如，针对失效进程#A(即，失效进程的一例)，管理节点可以从失效进程#A所对应的(一个或多个)存储设备获取用于指示恢复文件#A(或者，子恢复文件#A₁～子恢复文件#A_X)的大小的信息， 并根据该信息，确定失效进程#A所对应的恢复文件的大小。

再例如，各进程在生成恢复文件时可以确定该恢复文件的大小，并将用于指示恢复文件大小的信息发送给管理节点，管理节点可以根据进程的标识存储该信息，即，可以基于进程的标识与指示来自该进程的恢复文件的大小的信息之间的映射关系，对所获得的指示各恢复文件的大小的信息进行存储和索引，从而，当管理节点发现该进程失效时，可以基于该进程的标识查找到指示该进程所对应的恢复文件的大小的信息。

并且，在S110，管理节点可以确定各恢复节点的运行状态。

在一些实施例中，该运行状态可以包括恢复节点的资源使用状态，具体地说，恢复节点可以根据管理节点的指示或周期性的向管理节点上报该恢复节点的中央处理器(CPU，Central Processing Unit)使用率或内存使用率等负载信息，从而，管理节点可以根据来自恢复节点的负载信息，确定其资源使用状态。

在另一些实施例中，该运行状态可以包括恢复节点的通信状态，具体地说，恢复节点可以向管理节点上报指示该恢复节点与计算机系统中的其他节点的通信状态(例如，该状态可以包括正常通信、无法通信或通信时延等)的通信状态信息，从而，管理节点可以根据来自恢复节点的该通信状态信息，确定其通信状态。

需要说明的是，在本发明实施了中，各存储节点可以组成存储网络(或者说，存储网格)，该存储网络通过统一的对外接口向计算机系统中的各恢复节点提供数据(例如，恢复文件)，并且，各恢复节点与该存储网络之间可以通过消息队列等方式进行通信，从而各恢复节点无需获知存储有其需要的恢复文件的存储节点的具体地址，例如，网际协议(IP，Internet Protocol)地址或媒体访问控制地址(MAC，Media Access Control)地址等。

例如，恢复节点仅需将作为故障处理的对象的失效进程#A的标识发送至存储网络，存储网络的接口设备可以根据预先存储的各进程的标识与其恢复文件所存储于的存储节点的映射关系，查找到与所接收到的失效进程#A的标识相对应的存储节点，进而能过获得与该失效进程#A相对应的恢复文件#A。

因此，该通信状态可以是恢复节点与该存储网络的接口设备之间的通信状态。

另外，在本发明实施了中，存在多个进程(例如，该多个进程包括上述失效进程#A和进程#B)之间需要进行通信以实现业务功能的情况，此情况下，用于对失效进程#A进行恢复的恢复节点需要与运行有进程#B的节点(即，该恢复节点的关联节点)进行通信。

因此，该通信状态还可以是恢复节点与关联节点的通信状态。

在如上所述，确定恢复文件的大小以及各恢复节点的运行状态后，S120，根据每个失效进程所对应的恢复文件的大小以及每个恢复节点的运行状态确定每个失效进程所对应的恢复节点。

例如，当N＝1时，需要恢复的进程只有一个(例如，上述失效进程#A)，此情况下，可以选择当前的运行状态能够满足该失效进程#A所需要的运行条件的节点作为该失效进程#A所对应的恢复节点。

作为运行条件，例如，可以列举：

A.计算资源或存储资源能够满足失效进程#A的处理要求，即，节点的空闲资源能够确保该失效进程#A的运行，例如，恢复节点的内存、CPU、存储等资源满足进程#A的运行要求。

B.通信状态能够满足失效进程#A的处理要求，即，恢复节点能够与失效进程#A的关联节点进行通信，或者，恢复节点能够与失效进程#A的存储节点进行通信以获得失效进程#A的恢复文件。

应理解，以上列举的根据恢复节点的运行状态和恢复文件的大小确定失效进程所对应的恢复节点的方法和过程仅为示例性说明，本发明并不限定于此。

再例如，当N≥2时，管理节点可以根据各恢复文件的大小，确定针对各失效进程的恢复顺序，即

可选地，当N≥2时，该根据每个失效进程所对应的恢复文件的大小以及每个恢复节点的运行状态确定每个失效进程所对应的恢复节点，包括：

根据每个恢复节点的运行状态，基于每个失效进程所对应的恢复文件的大小，按照从大到小的顺序，依次确定每个失效进程所对应的恢复节点。

具体地说，在存在多个失效进程时，需要为该多个失效进程寻找合适的恢复节点，并确保该多个失效进程的恢复时间之和最短。

在本发明实施例中，可以根据恢复文件的大小，按照从大到小的顺序，依次确定各失效进程所对应的恢复节点，优先确定恢复文件最大的失效进程 所对应的恢复节点。

下面对N≥2时，各失效进程所对应的恢复节点的具体确定过程进行说明。

步骤1，管理节点可以基于恢复文件大小，按照从大到小的顺序，确定失效进程集合(包括失效进程#1～失效进程#K)，其中，P₁≥P₂≥…≥P_K，其中，P表示恢复文件大小，K为待恢复的失效进程的数量，并令计数变量i＝1；

步骤2，管理节点可以获取能够提供恢复处理的节点(或者说，运行有能够放置待恢复的失效进行的虚拟机)，设这些节点的集合为N，已被分配的集合Nu＝0；

步骤3，若i＞K，则执行步骤6，否则，执行步骤4；

步骤4，针对失效进程#i，假如集合Nu中节点的排列顺序(例如，可以按放入集合的时间顺序排列，也可以按剩余的可用资源大小排列，本发明并未特别限定)为N₁，N₂…N_j，则先依次尝试集合Nu中节点是否能够满足失效进程#i的运行条件，如果不存，则从集合N进行选择，并将能够满足的节点(例如，集合N中能够满足失效进程#i的运行条件的下标最小的节点)放入结合Nu中，作为N_j+1。并且，管理节点可以进行更新处理，令i＝i+1，转到Step3。

应理解，以上列举的确定各失效进程所对应的恢复节点的方法仅为示例性说明，本发明并未限定于此，还可以使用例如，首次适应、最佳适应、降序首次适应及降序最佳适应算法等启发式算法确定各失效进程所对应的恢复节点。

在如上所述确定了各失效进程所对应的恢复节点之后，在S130，管理节点可以根据各失效进程所对应的恢复节点，对各失效进行恢复处理。

例如，管理节点可以直接指示恢复节点从存储节点获取失效进程的恢复文件，并基于该恢复文件进行恢复。这里，恢复节点基于恢复文件对进行进行恢复处理的方法和过程可以与现有技术相似，这里，为了避免赘述，省略其详细说明。

再例如，管理节点可以根据各失效进程所对应的恢复节点，估计恢复时间，并根据恢复时间，确定恢复策略，即：

可选地，该根据每个失效进程所对应的恢复节点，对每个失效进程进行故障恢复处理，包括：

根据每个失效进程所对应的恢复节点的运行状态和每个失效进程所对应的恢复文件的大小，估计每个失效进程的恢复时间；

根据每个失效进程的恢复时间，对每个失效进程进行故障恢复处理。

具体地说，管理节点可以采样以下方式估计失效进程的恢复时间。

管理节点可以采用(例如，预先设置的)多种方案对失效进程和恢复节点进行匹配，或者说，管理节点可以采用(例如，预先设置的)多种方案将失效进程模拟地放置与某个恢复节点，并计算该方案下的恢复时间。

其中，各方案需要满足以下条件：

条件1

失效进程#K所匹配的恢复节点需要满足失效进程#K的故障恢复对CPU处理能力的要求，即，上述条件1可以表示为以下式(1)

式(1)

其中，表示失效进程#K的故障恢复对CPU处理能力的要求；a_Ki∈[0,1]，即，如果失效进程#K放置在恢复节点i，则a_Ki＝1，否则a_Ki＝0；表示恢复节点#i的CPU的处理能力(例如，所能够提供的虚拟CPU的数量)。

条件2

失效进程#K所匹配的恢复节点需要满足失效进程#K的故障恢复对内存的要求，即，上述条件2可以表示为以下式(2)

式(2)

其中，表示失效进程#K的故障恢复对内存的要求；a_Ki∈[0,1]，即，如果失效进程K放置在恢复节点i，则a_Ki＝1，否则a_Ki＝0；表示恢复节点#i能够提供的内存。

并且，上述可以根据以下式(3)确定：

式(3)

其中，m_K表示失效进程#K申请内存的大小(或者说，失效进程#K的恢复文件的大小)，μ、ε为预设系数，由实验测定，v表示失效进行的数量。

条件3

一个失效进程的故障恢复只在一个恢复节点中进行，例如，用于进行针对失效进程#1的故障恢复的恢复节点的CPU处理能力(例如，所能够提供的虚拟CPU的数量)需要满足失效进程#1的故障恢复对CPU处理能力的要求，且用于进行针对失效进程#1的故障恢复的恢复节点能够提供的内存需要 满足失效进程#1的故障恢复对内存的要求。

恢复节点#i上的失效进程恢复时间T(n_i)与失效进程#K的恢复文件的大小m_K之间的量化关系可以由以下式(4)表达：

式(4)

其中，a、β为系数，由实验测定。

第j种放置方案的失效节点恢复时间取所有节点上失效进程集合恢复时间的最大值R_j可以由以下式(5)表达：

R_j＝max(T_j(n_j)),i＝1,2,...s 式(5)

从而，基于上述条件1～条件3能够确定使恢复时间开销量化模型的目标函数min(R_j)达到最小的匹配方案，以及该方案下各失效进程的恢复时间。。

在如上所述确定了各失效进程的恢复时间之后，管理节点可以判定各失效进程的估计的恢复时间是否满足该进程对恢复时间的要求，并根据判定结果执行恢复处理，例如，如果所估计的恢复时间小于或等于该进程所要求的恢复时间的最大值，则管理节点可以指示恢复节点对该失效进程进行恢复。再例如，如果所估计的恢复时间大于该进程所要求的恢复时间的最大值，则管理节点可以在运行有该失效进程的原节点进行故障排除处理等。

可选地，一个失效进程所对应的恢复节点与同一失效进程所对应的存储节点相异。

具体地说，在本发明实施了中失效进程#A所对应的存储节点，与该失效进程#A所对应的恢复节点相异，即，在本发明实施例的计算机系统中，可以使用于存储恢复文件的存储节点与用于执行恢复处理的恢复节点独立，从而能够便于维护，并减小各节点的负担。

应理解，以上列举的存储节点与恢复节点的关系仅为示例性说明，一个失效进程所对应的存储节点与恢复节点也可以为同一节点，本发明并未特别限定。

根据本发明实施例的故障恢复的方法，根据失效进程所对应的恢复文件的大小和至少两个恢复节点的运行状态，从至少两个恢复节点中确定对该失效进程进行故障恢复的恢复节点，相比只有一个恢复节点可靠性更高，同时能够一定程度上确保所确定的恢复节点能够实现对失效进程的故障恢复，从而进一步提高故障恢复的可靠性。

以上，结合图1和图2详细说明了本发明实施了的故障恢复的方法，下面结合图3，详细说明发明的故障恢复的装置。

图3示出了根据本发明实施例的故障恢复的装置300的示意性框图。如图3所示，该装置300包括：

确定单元310，用于确定N个失效进程中每个失效进程所对应的恢复文件的大小，及M个恢复节点中每个恢复节点的运行状态，并根据每个失效进程所对应的恢复文件的大小和M个恢复节点的运行状态，确定每个失效进程所对应的恢复节点，其中，该运行状态包括资源使用状态或通信状态，N≥1，M≥2；

处理单元320，用于根据每个失效进程所对应的恢复节点进行控制，以在每个失效进程所对应的恢复节点，对每个失效进程进行故障恢复。

可选地，该N个失效进程中的第一失效进程所对应的恢复文件存储在至少两个存储节点中。

可选地，在各该存储节点中存储的该第一失效进程所对应的恢复文件相同。

可选地，该第一失效进程所对应的恢复文件包括至少两个子恢复文件，在各该存储节点中存储的子恢复文件不同。

可选地，当N≥2时，该确定单元具体用于根据每个恢复节点的运行状态，基于每个失效进程所对应的恢复文件的大小，按照从大到小的顺序，依次确定每个失效进程所对应的恢复节点。

可选地，一个失效进程所对应的恢复节点与同一失效进程所对应的存储节点不同。

可选地，该处理单元具体用于根据每个失效进程所对应的恢复节点的运行状态和每个失效进程所对应的恢复文件的大小，估计每个失效进程的恢复时间，并根据每个失效进程的恢复时间，对每个失效进程进行故障恢复处理。

根据本发明实施例的故障处理的装置300可对应于本发明实施例的方法中的执行主体，例如，管理节点，并且，该故障处理的装置300中的各单元即模块和上述其他操作和/或功能分别为了实现图1中的方法100的相应流程，为了简洁，在此不再赘述。

根据本发明实施例的故障恢复的装置，根据失效进程所对应的恢复文件的大小和至少两个恢复节点的运行状态，从至少两个恢复节点中确定对该失 效进程进行故障恢复的恢复节点，相比只有一个恢复节点可靠性更高，同时能够一定程度上确保所确定的恢复节点能够实现对失效进程的故障恢复，从而进一步提高故障恢复的可靠性。

以上，结合图1和图2详细说明了本发明实施了的故障恢复的方法，下面结合图4，详细说明发明的故障恢复的设备。

图4示出了根据本发明实施例的故障恢复的设备400的示意性框图。如图4所示，该设备400包括：

总线系统410；

与该总线系统410相连的处理器420；

与该总线系统410相连的存储器430；

其中，该处理器通过该总线，调用该存储器中存储的程序，以用于确定N个失效进程中每个失效进程所对应的恢复文件的大小，并确定M个恢复节点中每个恢复节点的运行状态，其中，N≥1，M≥2；

用于根据每个失效进程所对应的恢复文件的大小以及每个恢复节点的运行状态确定每个失效进程所对应的恢复节点，其中，该运行状态包括资源使用状态或通信状态；

用于根据每个失效进程所对应的恢复节点进行控制，以在每个失效进程所对应的恢复节点，对每个失效进程进行故障恢复。

可选地，该N个失效进程中的第一失效进程所对应的恢复文件存储在该第一失效进程所对应的至少两个存储节点中。

可选地，在各该存储节点中存储的该第一失效进程所对应的恢复文件相同。

可选地，该第一失效进程所对应的恢复文件包括至少两个子恢复文件，在各该存储节点中存储的子恢复文件不同。

可选地，当N≥2时，该处理器具体用于根据每个恢复节点的运行状态，基于每个失效进程所对应的恢复文件的大小，按照从大到小的顺序，依次确定每个失效进程所对应的恢复节点。

可选地，一个失效进程所对应的恢复节点与同一失效进程所对应的存储节点不同。

可选地，可选地，该处理器具体用于根据每个失效进程所对应的恢复节点的运行状态和每个失效进程所对应的恢复文件的大小，估计每个失效进程 的恢复时间；

用于根据每个失效进程的恢复时间，对每个失效进程进行故障恢复处理。

处理器还可以称为CPU。存储器可以包括只读存储器和随机存取存储器，并向处理器提供指令和数据。存储器的一部分还可以包括非易失随机访问存储器(Non-Volatile Random Access Memory,NVRAM)。具体的应用中，设备400可以嵌入或者本身可以就是计算机设备，其中，总线除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚明起见，在图中将各种总线都标为总线系统410。具体的不同产品中解码器可能与处理单元集成为一体。

处理器可以实现或者执行本发明方法实施例中的公开的各步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器，解码器等。结合本发明实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用解码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。

应理解，在本发明实施例中，该处理器420可以是中央处理单元(Central Processing Unit，简称为“CPU”)，该处理器420还可以是其他通用处理器、数字信号处理器(digital signal processor,DSP)、应用专用集成电路(Application Specific Integrated Circuit,ASIC)、现场可编程门阵列(Field－Programmable Gate Array,FPGA)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

该存储器430可以包括只读存储器和随机存取存储器，并向处理器420提供指令和数据。存储器430的一部分还可以包括非易失性随机存取存储器。例如，存储器430还可以存储设备类型的信息。

该总线系统410除包括数据总线之外，还可以包括电源总线、控制总线和状态信号总线等。但是为了清楚说明起见，在图中将各种总线都标为总线系统410。需要说明的是，本发明实施例中“与总线系统410相连”既可以包括直接相连，也可以包括间接相连。

在实现过程中，上述方法的各步骤可以通过处理器420中的硬件的集成逻辑电路或者软件形式的指令完成。结合本发明实施例所公开的方法的步骤 可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器430，处理器420读取存储器430中的信息，结合其硬件完成上述方法的步骤。为避免重复，这里不再详细描述。

根据本发明实施例的故障恢复的设备400可对应于本发明实施例的方法中的执行主体(例如，管理节点)，并且，故障恢复的设备400中的各单元即模块和上述其他操作和/或功能分别为了实现图1中的方法100的相应流程，为了简洁，在此不再赘述。

根据本发明实施例的故障恢复的设备，根据失效进程所对应的恢复文件的大小和至少两个恢复节点的运行状态，从至少两个恢复节点中确定对该失效进程进行故障恢复的恢复节点，相比只有一个恢复节点可靠性更高，同时能够一定程度上确保所确定的恢复节点能够实现对失效进程的故障恢复，从而进一步提高故障恢复的可靠性。

需要说明的是，本发明实施例中提到的A和/或B代表的含义包括A，B以及A和B。

应理解，在本发明的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个 系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。