CN105659562A - 利用簇中并行性进行容障处理 - Google Patents

Abstract

在说明性实施例中提供了一种利用簇中并行性进行容障处理的方法、系统、以及计算机程序产品。在服务于簇中应用的第一计算节点中检测故障。从动作集合选择动作的子集，动作集合被配置为将应用的服务从簇中第一计算节点转递于第二计算节点。为第一计算节点设置等待周期。在等待周期期间允许第一计算节点继续服务于应用。在等待周期期间，在第二计算节点处，与服务于应用的第一计算节点并行地执行动作的子集。在等待周期期间，响应于从第一计算节点接收活动信号，退出第二计算节点的并行操作。

Description

利用簇中并行性进行容障处理

技术领域

总体上讲，本发明涉及一种用于管理数据处理环境的方法、系统、以及计算机程序产品。更具体地讲，本发明涉及一种利用簇中并行性进行容障处理的方法、系统、以及计算机程序产品。

背景技术

可以把数据处理系统划分为若干逻辑分割部分(LPAR)。这样的数据处理系统也称为逻辑分割的数据处理系统。也把逻辑分割部分简单地称为“分割部分”。每一个分割部分作为独立于其它分割部分的单独的数据处理系统加以操作。通常情况下，分割管理固件部件连接各分割部分，并且在它们之间提供网络连接。管理器为这样的分割管理固件的实例。

工作负载分割为这样一种技术：其通过使用软件技术，而非形成单独的硬件分割部分，允许对用户与应用进行分隔。换句话说，可以把数据处理系统配置为允许一或多个虚拟的分割部分在数据处理系统的操作系统中操作。把这样虚拟的分割部分称为工作负载分割部分。

高可得性(HA)系统为这样一种数据处理系统：将其配置为在某一给定周期期间确保操作的连续性的阈值水平。可得性指的是用户与应用访问数据处理系统的能力，无论是提交新的工作、更新或者改变现存的工作，还是收集先前工作的结果。如果用户或者应用不能够访问所述系统，则认为所述系统为不可得。通常情况下，使用术语“故障时间”指的是系统不可得的周期。通常在公司机构中使用HA系统提交对生意至关重要的应用与服务。

可以使用一或多个物理或者逻辑的数据处理系统配置HA系统。例如，HA系统可以包括多个其配置旨在一致操作的独立的物理数据处理系统。又例如，可以配置多个诸如LPAR的一起操作的逻辑数据处理系统，以形成HA系统。

作为另一个实例，一或多个WPAR、LPAR、以及物理数据处理系统的组合也可以形成HA系统的一部分。也把这样的组合称为簇。HA系统或者其中的簇还可以包括其它的部件、系统、或者设备。例如，簇可以包括诸如存储区域网络(SAN)的数据存储设备的阵列。又例如，HA系统或者其中的簇还可以包括诸如交换机的网络连接设备。

发明内容

说明性的实施例提供了一种利用簇中并行性进行容障处理的方法、系统、以及计算机程序产品。实施例检测第一计算节点中的故障，第一计算节点服务于一簇计算节点中的应用。该实施例从动作集合中选择动作的子集，把所述动作集合配置为将应用的服务从簇中的第一计算节点转递于第二计算节点。所述实施例为第一计算节点设置等待周期。所述实施例允许第一计算节点在等待周期期间继续服务于簇中的应用。在等待周期期间，所述实施例与服务于应用的第一计算节点并行地执行第二计算节点处的动作的子集，所述实施例响应在等待周期期间从第一计算节点对活动的信号的接收，中止簇中第二计算节点的并行操作。

附图说明

所附权利要求中阐述了被视为本发明特征的新型特性。然而，当结合附图进行阅读时，参照以下对所述说明性实施例的详细描述，将能够很好地理解本发明本身与使用的优选模式、以及本发明的进一步的目的与优点，其中：

图1描述了其中可以实现所述说明性实施例的数据处理系统的网络的结构图；

图2描述了其中可以实现所述说明性实施例的数据处理系统的结构图；

图2A描述了根据说明性实施例的一般性分簇基础架构；

图3描述了可以使用说明性实施例修改的分簇数据库环境的时序图；

图4描述了根据说明性实施例的资源宽限周期内的操作的时序图；

图5描述了根据说明性实施例的资源宽限周期内的操作的时序图；

图6描述了根据说明性实施例的资源宽限周期内的操作的时序图；

图7描述了根据说明性实施例的资源宽限周期内的操作的时序图；

图8描述了根据说明性实施例的利用簇中并行性进行容障处理的工作负载节点和监视器节点的实例配置的结构图；

图9描述了根据说明性实施例的利用簇中并行性进行容障处理的实例配置；

图10描述了根据说明性实施例的利用簇中并行性进行容障处理的实例过程的流程图；

图11描述了根据说明性实施例的监视过程的流程图；以及

图12描述了根据说明性实施例的终止并行的实例过程的流程图。

具体实施方式

在分簇的环境中，把故障恢复方案配置为当对主计算节点中的故障进行检测时得以触发，其中，主计算节点正在提供服务，例如服务于应用。所述恢复方案通过把提供服务的责任转向另一个节点(接管节点)启动对服务的接管。

所述说明性实施例认识到：在分簇的环境中，恢复是一种大量消耗资源并且计算上开销很高的操作。所述说明性实施例还认识到：并非主节点中所检测到的所有故障均为致命的或者不可恢复的故障。可以把当前所检测到的某些故障视为伪故障。伪故障(或者错误检测的故障)为这样一种情况：似乎在表示相关联的计算节点不活跃，而其中该节点实际上是活跃的，只是没有根据某些参数加以执行。

例如，心跳为分簇的计算节点中周期性的消息处理系统。从节点向簇中其它节点发送的心跳表示：进行发送的(发送心跳的)节点为活的并且活跃。如果在指定的时间窗口(心跳超时宽限周期)内主节点未能够成功发送心跳，则接管节点可以断定主节点已经变为不活跃，并且开始恢复操作。然而，主节点可能为活的，但节点中的某种情况可能阻碍了发送心跳的线程获取处理器时间，或者网络中的某种情况可能延迟了心跳数据包向接管节点的到达。

心跳故障的实例并不是唯一的伪故障。在分簇数据库环境中，许多其它伪故障会类似地出现。所述说明性实施例认识到：在伪故障期间启动恢复操作是所不希望的。

另外，当前可得的恢复方法依赖于终止故障节点的所有操作、以及接管节点对故障节点的所有资源的接管。换句话说，当前，簇中的节点要么为“up”，要么为“down”。相应地，对于故障节点的过程的更适度的退出或者重新启动，簇中的节点要么正在进行操作，要么暂停，无处于中间状态的可能。

用于描述本发明的说明性实施例总体上涉及并且解决了以上所描述的分簇数据处理环境中与从故障中恢复相关的问题以及其它问题。所述说明性实施例提供了一种利用簇中并行性进行容障处理的方法、系统、以及计算机程序产品。

当前可得的故障恢复方案不对因节点不能够在高可得性参数范围内进行恢复的故障和因节点能够在高可得性参数范围内进行恢复的故障加以区分。故障节点仅具有宽限周期，例如，传输心跳的时间窗口，此后，在簇中，把故障节点宣布为“down”，而且接管动作开始于接管节点。无论是由于实际的致命故障还是由于伪检测的故障，当宽限周期的截止时，故障恢复都将导致接管节点执行大量的准备工作。接管服务变为强制性的。在本公开专利中，把这样的准备工作的执行称为预先准备。

所述说明性实施例增强了簇的簇基础架构，从而与当前正在操作的簇中的容忍度相比，使簇变得更能容忍临时停机，例如由于伪故障所导致的停机。所述说明性实施例允许出现故障的节点(故障节点)拥有恢复的机会，同时也允许前摄性地预先准备一或多个其它节点，以应对对故障节点的工作负载的可能的接管。所述说明性实施例描述了3种设计为能够在簇中一起工作的新的概念：多个宽限周期、一或多个监视节点、以及新的簇范围状态或者命令的集合。

在一个实施例中，引入了新的通信损失宽限周期(响应宽限周期)，其长于现存的、当前作为终止故障节点的故障自动切断交换机实现的硬超时(timeout)。一旦节点已经进入响应宽限周期，则簇中的一或多个节点开始准备接管的预先准备。

分簇数据库中的事务记录重放是预先准备的实例。事务记录重放包括根据磁盘上的事务记录重新构造若干张表。依据自由事务记录项目的数量，记录重放可以在数据库的非适度终止之后几分钟到几小时的任何时间进行。保证根据本技术的记录重放能够占不可忽视的时间量。

实施例检测到主节点出现故障，而且当检测到心跳超时(也就是说从主节点丢失的心跳)时，启动预先准备动作。另一个实施例检测到主节点出现故障，而且当监视节点告知簇主节点仅部分地响应并且不能够与其它分簇的节点进行通信时，启动一或多个接管节点的预先准备。

当一或多个节点已经完成了预先准备动作时，实施例通过一条簇范围的命令通知监视节点。响应这一命令，监视节点通过暂停所述节点或者通过剥夺故障节点对数据采取动作的能力，例如，通过切断故障节点的输入/输出，接管DOWN的故障节点。在一个实施例中，配置了按长于当前所使用的时间长度操作的硬超时(例如，故障自动切断交换机(deadmanswitch))。如果不能够通过其它手段对故障节点的切断进行有效处理，则作为一种安全机构，采用硬超时，并且暂停故障节点而不管被预先准备的节点的状态，如在现有技术中。

就缩短簇中的接管时间而言，所述说明性实施例的增强的簇基础架构也是有效的。实质上，在用于资源管理的簇中，实施例的增强的簇基础架构能够提高接管性能，因为对于任何恢复动作序列，能够将它们重新排序，以首先执行那些能够被安全执行的动作，同时另一个节点仍旧能够操作将被接管的资源。

例如，为了准备好服务，应用可能要花费大量时间进行初始化、加载静态数据以及建立客户连接。实施例允许预先准备过程首先执行接管现场中的这些动作。所述实施例把将中断故障节点上的(可能的)静止操作应用的任何接管动作的执行向后推迟，例如，直至等待周期过去。在硬超时故障自动切断交换机截止之后，在监视节点已经暂停故障节点或者故障节点已经暂停其本身之后，所述实施例启动中断的动作。

对于资源恢复过程中的那些安全的动作，所述实施例的增强的簇基础架构能够启动将与故障节点中资源的可能仍活跃的实例并行执行的阶段。于是，利用实施例的这一基础架构的簇恢复动作包括安全并行阶段。所述安全并行阶段(其中，故障节点继续服务于应用，而且接管节点开始与故障节点的操作并行地预先准备)缩减了伪检测的故障的开销，从而允许更好地调谐故障检测率，以实现分簇数据处理环境中的较理想的故障结束时间。

仅作为实例、针对某些伪故障描述了所述说明性实施例。这样的实例故障不旨在对本发明加以限制。

另外，也可以针对任何类型的数据、数据源、或者对数据网络上数据源的访问，实现所述说明性实施例。在本发明的范围内，任何类型的数据存储设备可以在数据处理系统处本地地或者在数据网络上向本发明的实施例提供数据。

仅作为实例、使用具体的代码、设计、体系结构、协议、布设、示意图、以及工具描述了所述说明性实施例，而且不对所述说明性实施例加以限制。另外，为了描述的清晰，仅作为实例、使用具体的软件、工具、以及数据处理环境，按某些取例描述了所述说明性实施例。可以与其它可比的或者类似目的的结构、系统、应用、或者体系结构相结合地使用所述说明性实施例。可以按硬件、软件、或者它们的组合实现说明性实施例。

使用这一公开专利中的所述实例，仅仅是为了描述的清晰，不旨在对所述说明性实施例加以限制。将可根据这一公开专利想象出更多的数据、操作、动作、任务、活动、以及控制，可以在所述说明性实施例的范围内考虑所述更多的数据、操作、动作、任务、活动、以及控制。

此处所列举的任何优点仅为实例，并且不旨在对所述说明性实施例加以限制。可以通过具体的说明性实施例实现更多的或者不同的优点。另外，具体的说明性实施例具有以上所列举的某些、全部优点、或者不具有以上所列举的优点。

参照附图，特别是参照图1和图2，这些图为其中可以实现说明性实施例的数据处理环境的实例图。图1和图2仅为实例，并且不旨在对其中可以实现不同实施例的环境主张或者施加任何限制。具体的实现可以根据以下的描述对所描述的环境进行诸多修改。

参照图1，该图描述了其中可以实现所述说明性实施例的数据处理系统的结构图。数据处理系统100可以为对称多处理器(SMP)系统，包括连接于系统总线106的多个处理器101、102、103、以及104。例如，数据处理系统100可以为作为网络中的服务器加以实现的IBMPower(PowerSystem为InternationalBusinessMachinesCorporation(IBM公司)在美国及其它国家中的产品和注册商标)。作为选择，也可以使用单处理器系统，而且处理器101、102、103、以及104可以为单处理器芯片中的核心。作为选择，数据处理系统100也可以包括处理器和内核的任何组合中的处理器101、102、103、以及104。

也连接于系统总线106的是存储器控制器/高速缓冲存储器108，其向多个本地存储器160～163提供了接口。I/O总线桥110连接于系统总线106，并且向I/O总线112提供了接口。可以把存储器控制器/高速缓冲存储器108和I/O总线桥110加以集成，如所描述的。

数据处理系统100为逻辑上分割的数据处理系统。因此，数据处理系统100可以具有同时运行的多个不同种类的操作系统(或者单操作系统的多个取例)。所述多个操作系统中的每一个操作系统可以具有其中正在执行的任何数目的软件程序。对数据处理系统100进行逻辑分割，从而可以把不同的PCII/O适配器120～121、128～129、以及136，图形适配器148、以及硬盘适配器149赋予不同的逻辑分割部分。在这一情况下，图形适配器148连接于显示设备(未示出)，而硬盘适配器149连接于硬盘150，并且控制硬盘150。

于是，例如，假设把数据处理系统100划分成3个逻辑分割部分P1、P2、以及P3。把PCII/O适配器120～121、128～129、136中的每一个、图形适配器148、硬盘适配器149，宿主处理器101～104中的每一个、以及来自本地存储器160～163的存储器赋予这3个分割部分之一。在这些实例中，存储器160～163可以呈双列直插存储器模块(DIMM)的形式。通常，不以DIMM为单位向分割部分赋予DIMM。取而代之，分割部分将得到该平台所能看到的整个存储器的一部分。例如，可以把处理器101、来自本地存储器160～163的存储器的某一部分与PCII/O适配器120、128、以及129赋予逻辑分割部分P1；可以把处理器102～103、来自本地存储器160～163的存储器的某一部分与PCII/O适配器121和136赋予分割部分P2；以及可以把处理器104、来自本地存储器160～163的存储器的某一部分、图形适配器148以及硬盘适配器149赋予逻辑分割部分P3。

把在数据处理系统100中执行的每一个操作系统赋予不同的逻辑分割部分。于是，在数据处理系统100中执行的每一个操作系统仅可以访问那些处于其逻辑分割部分中的I/O单元。因此，例如，AdvancedInteractiveExecutive操作系统的取例可能正在分割部分P1中执行，AIX操作系统的第二取例(映像)可能正在分割部分P2中执行，而Linux或者操作系统可能正操作于逻辑分割部分P3中。(AIX和IBM-i为IBM公司在美国及其它国家中的注册商标，Linux为LinuxTorvalds公司在美国及其它国家中的注册商标)。

连接于I/O总线112的外部部件互连(PCI)宿主桥114向PCI本地总线115提供接口。多个PCI输入/输出适配器120～121通过PCI至PCI桥116、PCI总线118、PCI总线119、I/O插槽170、以及I/O插槽171连接于PCI本地总线115。PCI至PCI桥116向PCI总线118和PCI总线119提供接口。把PCII/O适配器120和121分别放置于I/O插槽170和171中。典型的PCI总线实现支持4～8个适配器(即，针对内插式连接器的扩展槽)。每一个PCII/O适配器120～121在数据处理系统100和诸如为客户机的其它网络计算机的输入/输出设备等之间提供至数据处理系统100的接口。

附加PCI宿主桥122提供了针对附加PCI本地总线123的接口。PCI本地总线123连接于多个PCII/O适配器128～129。PCII/O适配器128～129通过PCI至PCI桥124、PCI总线126、PCI总线127、I/O插槽172、以及I/O插槽173连接于PCI本地总线123。PCI至PCI桥124向PCI总线126和PCI总线127提供了接口。把PCII/O适配器128和129分别放置于I/O插槽172和173中。按照这一方式，可以通过PCII/O适配器128～129中的每一个适配器支持附加的I/O设备，例如调制解调器或者网络适配器等。于是，数据处理系统100允许向多个网络计算机的连接。

把存储器映像的图形适配器148插入I/O插槽174，并且通过PCI总线144、PCI至PCI桥142、PCI本地总线141、以及PCI宿主桥140连接于I/O总线112。可以把硬盘适配器149放置在连接于PCI总线145的I/O插槽175中。接下来，PCI总线145连接于PCI至PCI桥142，PCI至PCI桥142通过PCI本地总线141连接于PCI宿主桥140。

PCI宿主桥130为PCI本地总线131提供了连接于I/O总线112的接口。PCII/O适配器136连接于I/O插槽176，I/O插槽176通过PCI总线133连接于PCI至PCI桥132。PCI至PCI桥132连接于PCI本地总线131。PCI本地总线131也把PCI宿主桥130连接于服务处理器邮箱接口和ISA总线访问传递逻辑194以及PCI至PCI桥132。

服务处理器邮箱接口和ISA总线访问传递逻辑194转发目标为PCI/ISA桥193的PCI访问。NVRAM存储器192连接于ISA总线196。服务处理器135通过其本地PCI总线195连接于服务处理器邮箱接口和ISA总线访问传递逻辑194。服务处理器135还经由多条JTAG/I2C总线134连接于处理器101～104。JTAG/I2C总线134为JTAG/扫描总线(参见IEEE1149.1)和PhillipsI2C总线的组合。

然而，作为选择，也可以仅使用PhillipsI2C总线或者仅使用JTAG/扫描总线取代JTAG/I2C总线134。把宿主处理器101、102、103、以及104的所有SP-ATTN信号一并连接于服务处理器135的中断输入信号。服务处理器135具有其自己的本地存储器191，并且可以访问OP-面板190。

当向数据处理系统100初始加电时，服务处理器135使用JTAG/I2C总线134询问系统(宿主)处理器101～104、存储器控制器/高速缓冲存储器108、以及I/O总线桥110。当这一阶段完成时，服务处理器135也可以对通过询问宿主处理器101～104、存储器控制器/高速缓冲存储器108、以及I/O总线桥110所发现的所有元件执行内置自测试(BIST)、基本保证测试(BAT)、以及存储器测试。服务处理器135收集和报告BIST、BAT、以及存储器测试期间所检测到的故障的任何错误信息。

在BIST、BAT、以及存储器测试期间，如果在去除发现有故障的元件之后，系统资源的有意义的/有效的配置依然可能，则允许数据处理系统100继续向本地(宿主)存储器160～163中加载可执行的代码。然后，服务处理器135释放处理器101～104，以执行加载于本地存储器160～163中的代码。当宿主处理器101～104正在执行来自数据处理系统100中各操作系统的代码时，服务处理器135进入监视和报告错误模式。服务处理器135监视如下类型的项目：例如，包括冷却风扇的速度与操作、热传感器、电源调节器、以及处理器101～104、本地存储器160～163、以及I/O总线桥110所报告的可恢复和不可恢复的错误。

服务处理器135保留和报告与数据处理系统100中所有所监视的项目相关的错误信息。服务处理器135还根据错误的类型和所定义的阈值采取动作。例如，服务处理器135可以关注处理器的高速缓冲存储器上诸多可恢复错误，并且判断其是否为可预测的硬故障。根据这一判断，服务处理器135可以在当前运行会话和未来初始程序加载(IPL)期间标记将解除配置的资源。有时也把IPL称为“引导”或者“引导程序”。

可以使用各种市场上买得到的计算机系统实现数据处理系统100。例如，可以使用可得于IBM公司的IBMPowerSystem系统实现数据处理系统100。这样的系统可以支持使用AIX操作系统的逻辑分割，AIX也可从IBM公司获得。

诸如存储器191、NVRAM192、本地存储器160、161、162、以及163、或者闪存(未示出)的存储器为计算机可用存储设备的一些实例。硬盘150、CD-ROM(未示出)、以及其它类似的可用设备为包括计算机可用存储介质的计算机可用存储设备的一些实例。

本领域技术人员将会意识到，图1中所描述的硬件可以不同。例如，除了或者取代所描述的硬件，也可以使用诸如光盘设备等的其它外部设备。又例如，可以把诸如适配器的某些物理资源虚拟化为相应的虚拟资源(未示出)，然后可以把虚拟资源分配于不同的分割部分。作为另一个实例，可以把图1中所描述的硬件配置为使用一或多个虚拟I/O服务器(VIOS)(未示出)。VIOS允许在所支持的逻辑分割部分之间共享诸如适配器、磁盘、控制器、处理器、存储器等的物理资源。就其它功能而言，在分割部分之间，共享的VIOS有助于减小对大量电缆布设的需求，并且有助于进行有效的移植。所描述的实例不旨在对所述说明性实施例施加体系结构限制。

参照图2，该图描述了其中可以实现所述说明性实施例的逻辑上分割的平台的实例的结构图。例如，可以按图1中数据处理系统100中所描述的相应的部件实现逻辑上分割的平台200中的硬件。

逻辑上分割的平台200包括分割的硬件230、操作系统202、204、206、208、以及平台固件210。也把诸如平台固件210的平台固件称为分割管理固件。操作系统202、204、206、以及208可以为某一单一操作系统的多个拷贝或者多个同时运行在逻辑上分割的平台200上的不同种类的操作系统。可以使用其设计旨在与诸如管理器的分割管理固件接口的IBM-i实现这些操作系统。在这些说明性实施例中，仅把IBM-i用作实例。当然，也可以使用诸如AIX和Linux的其它类型的操作系统，取决于具体的实现。把操作系统202、204、206、以及208分别设置在分割部分203、205、207、以及209中。

管理器软件为可以用于实现分割管理固件210的软件的实例，并且可得于IBM公司。固件为存储在存储器芯片中的软件，其在没有电能的情况下保持其内容，例如，所述存储器芯片为只读存储器(CD-ROM)、可编程ROM(PROM)、可擦除可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)、以及非易失随机存取存储器(非易失RAM)。

另外，分割部分203、205、207、以及209还分别包括分割固件211、213、215、以及217。可以使用初始引导程序代码、IEEE-PCI1275StandardOpenFirmware、以及可得于IBM公司的运行时间提取软件(RTAS)实现分割固件211、213、215、以及217。当对分割部分203、205、207、以及209实例化时，平台固件210把引导程序代码的拷贝加载于分割部分203、205、207、以及209。此后，把控制转交于引导程序代码，接下来引导程序代码加载打开的固件和RTAS。然后把与分割部分相关联的或者赋予分割部分的处理器分派于分割部分的存储器，以执行分割固件。

分割部分203包括应用203-A。分割部分203执行服务于应用203-A的工作负载。分割部分205包括监视应用205-A。监视应用205-A也称为监视器应用，包括此处所描述的用于监视分割部分203的状态、把这样的状态传递给分割部分203和205参与其中的簇、以及响应所述监视或者根据来自所述簇的诸如分割部分207的另一个成员的指令采取与分割部分203相关的动作的实施例。例如，在一个实施例中，分割部分203作为主节点进行操作，其经历了这样一种情况：致使分割部分207错误地检测到分割部分203中的故障。在所述实施例中，分割部分205为与分割部分203相关联的监视部分，其监视分割部分203的响应度，并且将其传递给分割部分207。分割部分207中的接管应用207-A开始从分割部分203接管服务于应用203-A的责任的并行预先准备。分割部分207中的接管应用207-A把分割部分203和205的并行状态告知簇基础架构(包括分割部分205)。分割部分207中的接管应用207-A指示分割部分205暂停或者修改分割部分203的操作，分割部分205根据此处所描述的实施例执行相应的操作。簇不局限于按单一架构的分割，图2的描述仅为典型簇的一部分的非限制性实例。簇也可以包括(通常情况下包括)其它架构上的其它分割节点。所述架构上针对节点203的接管节点，仅把节点207描述为非限制性实例。在所述说明性实施例的范围内，接管节点可以驻留在与主节点不同的架构上。

分割的硬件230包括多个处理器232～238、多个系统存储器单元240～246、多个输入/输出(I/O)适配器248～262、以及存储单元270。可以把处理器232～238、存储器单元240～246、NVRAM存储器298、以及I/O适配器248～262中的每一个赋予逻辑上分割的平台200中的分割部分203、205、207、以及209之一，分割部分203、205、207、以及209中的每一个对应于操作系统202、204、206、以及208之一。也可以在使用或者顺序访问CPU、存储器或者NVRAM的分割部分之间共享CPU、存储器或者NVRAM。可以把I/O适配器248～262赋予虚拟I/O服务器，以实现分割部分之间对I/O带宽的共享。

分割管理固件210执行针对分割部分203、205、207、以及209的多种功能与服务，以创建和实施对逻辑上分割的平台200的分割。分割管理固件210为与基础硬件一样的固件实现的虚拟机。因此，分割管理固件210通过对逻辑上分割的平台200的至少某些硬件资源进行虚拟化，允许独立的OS映像202、204、206、以及208的同时执行。

可以使用服务处理器290提供各种服务，例如，分割部分中平台错误的处理。这些服务也可以用作向供应商(例如，IBM公司)回报错误的服务代理。可以通过硬件管理控制台，例如通过硬件管理控制台280控制分割部分203、205、207、以及209的操作。硬件管理控制台280为单独的数据处理系统，系统管理员可以通过其执行各种功能，包括向不同分割部分重新分配资源。

图1～2中的硬件随实现的不同而不同。除了或者取代图1～2中所描述的某些硬件，也可以使用诸如闪存、等效的非易失存储器、或者光盘驱动器等的其它内部硬件或者外部设备。在不背离本发明的范围的情况下，所述说明性实施例的实现也可以使用用于管理分割部分的可选的体系结构。

参照图2A，该图描述了根据说明性实施例的一般性分簇基础架构。NODE-A为图2中分割部分203的实例实现，NODE-M为图2中分割部分205的实例实现，以及NODE-B为图2中分割部分207的实例实现。NODE-A包括资源管理器部件20101、可靠消息处理部件20103、以及成员关系部件20106。NODE-M包括监视应用部件20201、可靠消息处理部件20303、以及成员关系部件20206。NODE-B包括资源管理器部件20301、可靠消息处理部件20303、以及成员关系部件20306。

簇节点中的成员关系部件，例如NODE-A、NODE-M、以及NODE-B中的部件20106、20306、以及20506，分别通过与其它簇节点交换心跳，判断簇节点的状态。如果知道至少一个节点从簇节点接收心跳，则该簇节点处于状态UP，否则处于状态DOWN。NODE-M是监视节点，其具有至NODE-A的可靠的和可信的连接20500，NODE-M可以使用其查询NODE-A的状态。与NODE-A或者NODE-B的相应的部件20103和20106的簇服务相比，NODE-M的可靠消息处理部件20203以及成员关系部件20206，分别可以实现簇服务的最小的子集。部件20206中的簇服务的所述最小的集合足以满足簇域的功能需求。例如，NODE-M的可靠消息处理部件20203可能不需要参与可靠消息处理部件20103或者20303所实现的障栅(barrier)同步。NODE-M也可以不保持对所有簇节点的状态的追踪，而仅根据请求按可靠的方式与节点的子集进行通信。NODE-M也可能不从NODE-A发送和接收心跳，而根据NODE-B的指令查询NODE-A的状态，或者执行动作，例如暂停NODE-A。

实施例对簇中的节点进行分类，即根据它们受到下述情况影响的可能性对他们进行分类：可能引发伪故障的情况，例如线程调度失常。在线程调度失常的情况下，在影响操作系统或者节点中其它部件的功能的一段时间，不对一或多个线程进行调度。

所述说明性实施例认为线程调度失常更可能出现在那些需要页面调度、执行大量处理器间同步、展现封锁竞争、使用ActiveMemorySharing(活跃存储器共享)等的操作系统上。ActiveMemorySharing为IBMPowerVM先进的存储器虚拟化技术，其允许多个分割部分共享公共存储器池(ActiveMemory和PowerVM为IBM公司在美国及其它国家中所拥有的注册商标)。这些或者其它事件的组合序列更可能导致其中在宽限周期内不调度心跳线程的状态。

具有许多线程、复杂线程同步、变化的用户工作负载以及状态之间的变化的应用，例如查询处理、后援、垃圾收集等，更可能广泛使用针对过程同步与存储器管理的操作系统基础架构。于是，所述说明性实施例认为宿主应用的簇节点比非宿主应用的、以及具有更均匀工作负载的簇节点(例如，虚拟I/O服务器(VIOS))更可能出现线程调度失常。

仅仅是为了所述实施例的描述的简单，而非对它们施加任何限制，实施例假设了两种类型的节点：受线程调度失常或者导致某种情况的其它伪故障影响而具有阈值或者较高可能性的节点、以及受线程调度失常或者导致某种情况的其它伪故障影响而具有较低阈值可能性的节点。通常，簇基础架构提供了故障自动切断交换机。如果在所配置的心跳宽限周期簇节点尚不能够发送心跳，例如由于线程调度失常，则故障自动切断交换机将执行指定的动作。通常，如果在所配置的心跳宽限周期节点尚不能够发送心跳，则此后故障自动切断交换机将暂停此节点。在管理资源的簇中，簇节点可以接管在所配置的心跳宽限周期尚不能够从其发送心跳的节点的工作负载。当另一个节点接管工作负载时，尚不能够从其接收心跳的节点可能依然是正在操作的，并且其工作负载访问存储器也是正在操作的。如果节点在所配置的心跳宽限周期尚不能够发送心跳则暂停该节点，这样做，在另一个节点对未接收到心跳做出响应而采集工作负载的情况下，可以防止对工作负载数据不协调的访问。所述说明性实施例认为系统挂起和故障自动切断交换机截止主要出现在载有复杂工作负载(例如数据库)的节点上。此处把这类节点称为工作负载节点或者被监视的节点。在载有均匀工作负载或者均匀类型工作负载的节点中很少看到系统挂起和故障自动切断交换机截止的现象。此处把这一实例类型的节点称为监视器节点或者监视节点。

在不对其施加限制的情况下，在管理诸如VIOS的虚拟资源的同一个架构上具体化的分割部分为通常将适合作为监视器节点的节点的实例。作为监视器节点操作的实例候选是同一架构上相邻的、可信的分割部分，将其指定为按监视器节点身份动作。监视节点的实例候选是管理簇中硬件资源的可信簇中的本地或者远程的实体或者部件。管理同一平台上的分割部分的管理器也是监视节点的候选。如果候选工作负载节点邻近将加以监视的工作负载节点，则该工作负载节点也是候选监视节点。

根据实施例的监视器节点具有与被监视的工作负载节点进行通信的可靠通信通道。监视器节点执行一组动作，以查询或者影响被监视的工作负载节点的状态。通常，可靠通信通道通常为簇中节点之间、簇中节点和簇基础架构或者它们的组合之间冗余的专用消息处理通道。可靠通信指的是出现在可靠通信通道上的通信。工作负载节点和监视器节点之间的可靠通信通道的实例为所述平台固件所提供的协议。

把监视器节点配置为与工作负载节点可靠地进行通信、查询工作负载节点的状态以及当簇域指示时暂停或者操作该工作负载节点。根据实施例的监视器节点还包括把有关相关联工作负载节点的状态的信息告知其它簇节点的功能。监视器节点能够检测监视器节点所监视的簇节点的下列状态：SYS_UP--工作负载节点上的操作系统为活跃的，不包括处于引导或者被暂停期间的初始化状态；SYS_DOWN--工作负载节点未处于状态SYS_UP，并且可能是不活跃的、被暂停的、或者出现系统性故障的，如由平台基础架构加以检测的。监视器节点还可以检测外部化于平台基础架构的工作负载节点的更多的状态，包括系统引导、转储、以及被暂停期间的多种状态。监视器节点的可靠消息处理和成员关系部件可以实现工作负载节点中这些部件所提供的全部功能集合，因此能够区分工作负载节点是仅处于SYS_UP状态还是处于SYS_UP状态并且能够发送心跳。

状态DOMAIN_RESPONSE_DOWN表示在宽限周期处于状态SYS_UP并且尚未发送心跳的节点的状态。如果监视节点已经获知从心跳导出的NODE_A的状态，则监视节点可以判断NODE_A是否处于状态DOMAIN_RESPONSE_DOWN。否则，将通过把监视节点(NODE_M)所提供的状态信息与NODE_B以及可能更多节点所获知的状态信息加以组合，在分布决策(表决)过程中达到状态DOMAIN_RESPONSE_DOWN。

更详细地讲，假设NODE_M本身不知道NODE_A是否处于状态UP，但告知NODE_B：NODE_A处于状态SYS_UP。NODE_B和可能的进一步的簇节点可能知道NODE_A的状态为DOWN，因为未接收到心跳。具有来自监视节点NODE_M的“NODE_A处于状态SYS_UP”的信息，NODE_B和进一步的节点将通过分布决策把NODE_A的状态从DOWN改变至DOMAIN_RESPONSE_DOWN。某些簇状态是互斥的，例如，UP和DOWN、或者SYS_UP和SYS_DOWN是互斥的。另外，也可以通过逻辑AND组合定义进一步的状态。例如，如果一个节点处于状态DOWN与SYS_UP，则其处于状态DOMAIN_RESPONSE_DOWN。依据监视节点能够检测的进一步的状态，簇所维持的状态集合可以包括进一步的状态。如果监视器节点能够检测工作负载节点是否正在执行I/O，则其能够辨出状态ALL_RESPONSE_DOWN：即处于状态SYS_UP的工作负载节点尚未执行I/O，工作负载节点很可能处于被挂起状态。如果监视节点能够检测到节点正在引导的状态，例如通过查询引导或者转储期间该节点所发送的代码，簇层所维持的更多的状态可能是BOOT或者DUMP。

可以在诸如图2中的、在簇中节点中执行的监视应用205A的监视应用中实现针对监视器节点所描述的特性。可以在诸如图2中的、在簇中节点中执行的接管应用207A的接管应用中实现针对接管节点所描述的特性。监视器节点可以监视任何数目的工作负载节点。架构上的任何数目的节点均可以作为监视器节点操作，如果另一个监视器节点发生故障，则它们变为监视器节点，接管另一个监视器节点的责任，或者其组合。例如，在一个实施例中，给定配置中的主VIOS充当给定工作负载节点中的监视器节点。如果主VIOS发生故障，则次VIOS接管针对该工作负载节点的监视功能。

参照图3，该图描述了可以使用所述说明性实施例修改的分簇数据库环境的时序图。主节点302，标记为“NODE_A”，为工作负载节点的实施例，并且可以使用图2中的分割部分203加以实现。簇基础架构304为用于管理NODE_A参与其中的簇的操作的硬件和软件基础架构。在一个实施例中，簇基础架构304包括监视器节点(统称为监视设施304)，其可以为图2中分割部分205的实施例。节点306，标记为“NODE_B”，为图2中分割部分207的实施例，并且作为针对NODE_A的接管节点加以操作。

为了描述的清晰，而非对它们加以限制，时序图300中事件之间的次序与间隔为近似的、夸张的、或者是可选的。时序图300假设节点302未被暂停，并且在所描述的过程开始时可以操作。

使用所述簇基础架构，如果节点之一变为DOWN，簇中活跃的节点合作计算和修正各节点的等待周期(操作310)。当节点306检测到节点302中的故障时，实施例的过程开始(操作312)。例如，在心跳宽限周期内NODE-B可能未从NODE_A接收到心跳。在具有节点302的可靠通信通道上，监视设施304检测诸如正在进行的I/O的某些活动是否在节点302上继续(操作314)。

依据某些活动是否在节点302正在进行，监视设施304告知节点306：节点302处于DOMAIN_RESPONSE_DOWN状况或者ALL_RESPONSE_DOWN状况(操作316)。监视设施304为节点302设置等待周期，也称为资源宽限周期(操作318)。例如，在一个实施例中，簇中的所有活动节点，包括监视设施304，合作确定等待周期。针对节点302的等待周期开始于心跳超时宽限周期的截止，由簇基础架构加以启动。

通常情况下，除了已经存在于簇实现中的心跳超时宽限周期之外，实施例使用了3个宽限周期。资源宽限周期，或者等待周期，是心跳超时宽限周期终止之后开始的附加的宽限周期。在一个实施例中，通过障栅同步协议把资源宽限周期的开始和截止传递给所有簇节点，并且使用它们协调安全并行动作。在资源宽限周期持续期间，NODE_B执行安全并行预先准备动作(primingaction)。在所述宽限周期期间，NODE_B不进行除安全并行预先准备动作之外的动作。如果NODE_A没有重新开始心跳并且重新加入簇域，则在资源宽限周期截止之后通过故障自动切断交换机暂停NODE_A。于是，针对工作负载节点NODE_A的故障自动切断交换机超时为心跳超时宽限周期和资源宽限周期的值的和。周期性地确定资源宽限周期的修正的值，以在从NODE_A的故障恢复期间启动针对安全并行动作的时间窗口，并且将其传递给所有簇节点。在NODE_A发生故障的情况下，所有簇节点使用资源宽限周期的最后成功传递的值。NODE_A将考虑这一值，以更新其针对故障自动切断交换机超时的值。在一个实施例中，NODE_B通过近似NODE_B所期望的时间设置资源宽限周期，以完成预先准备动作。

在一个实施例中，在资源宽限周期已经结束并且可用作故障自动切断交换机超时的下限之后，网络和响应宽限周期的值结束。考虑到有关网络硬件的信息，网络宽限周期对多长时间不能够从节点接收到心跳进行制模。在一个实施例中，网络宽限周期可以近似于网络设备的重新引导或者初始化时间，例如循环交换机或者路由器的时间。当与NODE_A相关联的监视器节点不存在时，在把NODE_A断定为DOWN之前，NODE_B将容忍从心跳超时的节点(NODE_A)接收心跳的失败，从而断定NODE_A正在执行某一动作，否则把NODE_A的状态设置为DOMAIN_RESPONSE_DOWN。在一个实施例中，在度过安全并行阶段之前，网络宽限周期对簇基础架构将按超过把NODE_A的状态设置为DOWN时的时刻的最小量而等待其的超时的扩展进行制模。换句话说，把网络宽限周期用作设置故障自动切断交换机超时的下限。

考虑到节点经历线程调度失常的可能性，针对该节点设置的响应宽限周期对多长时间不能够从该节点接收到心跳进行制模。在一个实施例中，响应宽限周期为可以期望NODE_A从导致心跳线程不被调度的事件恢复所花费的时间的近似。响应宽限周期至少具有心跳超时的时间长度，并且是用于设置故障自动切断交换机超时的下限。

返回至时序图300，节点306为节点302设置操作318中的等待周期320。节点306告知簇基础设施304：节点306正在与节点302一起安全并行地操作(操作322)。节点306预先准备对节点302的接管，并且与节点302并行地操作(操作324)。在等待周期320截止之前和之后，根据各种实施例，某些可选的操作可能出现(操作框326)。

参照图4，该图描述了根据说明性实施例的资源宽限周期内的操作的时序图。时序图400为从使用与图3中所设置和所描述的相同的实体302、304、以及306的图3中的时序图300的可选的继续。

等待周期320继续，如时序图400中所示。节点306完成了预先准备，并且准备好接管节点302的责任(操作412)。监视设施304检测节点302是否正在执行任何活动(操作414)。依据节点302处的某一活动，例如正在进行I/O，监视设施304向包括节点304的簇报告：节点302处于DOMAIN_RESPONSE_DOWN状况或者ALL_RESPONSE_DOWN状况(操作416)。

根据图4中所描述的实施例，节点306指示监视设施304暂停节点302(操作418)。监视设施304可以暂停节点302或者挂起节点302’的I/O操作，以致能够把分配于节点302的资源重新赋予节点306(操作420)。因此，节点302暂停或者失去了对节点302的资源的I/O访问权(操作422)。

节点306终止并行，并且完成接管(操作424)。节点306开始操作，以服务于节点302正在服务的应用(操作426)。

注意，把等待周期320描述为结束，如仅作为实例所示出的。例如，如果簇基础架构低估了完成预先准备动作的时间，则等待周期320可以先于操作412结束。或者，当预先准备了节点306并且准备好接管节点302时，则等待周期320可以在操作412之后任何时刻结束。

参照图5，该图描述了根据说明性实施例的资源宽限周期内的操作的时序图。时序图500为从使用与图3中所设置和所描述的相同的实体302、304、以及306的图3中的时序图300的另一个可选的继续。

等待周期320继续，如时序图500中所示。节点306完成了预先准备，并且准备好接管节点302的责任(操作512)。簇基础设施304检测节点302是否为活跃的，例如是否正在传输心跳(操作514)。

假设在等待时间320内节点302已经恢复，如实施例所构想的。簇基础设施304向包括节点306的簇报告：节点302处于UP状况(操作516)。

根据图5中所描述的实施例，节点306结束安全并行，并且遗弃预先准备的用于接管的数据、允许节点302以主节点角色继续(操作518)。在另一个实施例(未示出)中，如果簇基础架构断定节点306是用作主节点的较好的选择，则即使当节点302返回至UP状况时，节点306也能够继续接管工作，例如，当节点302的性能低于性能的阈值水平以及节点306的性能处于所述阈值或者高于所述阈值时。

参照图6，该图描述了根据说明性实施例的资源宽限周期内的操作的时序图。时序图600为从使用与图3中所设置和所描述的相同的实体302、304、以及306的图3中的时序图300的另一个可选的继续。

等待周期320继续，如时序图600中所示。假设在等待周期320内节点302已经恢复，如实施例所构想的。当节点306检测到(例如，通过簇中的心跳)节点302处于UP状况时，节点306继续工作，以完成预先准备(操作614)。

节点306结束所述并行(操作616)，告知簇基础架构：与节点302的并行已经结束(操作618)，并且放弃预先准备过程(操作620)。等待周期320可能已过不仅如图中所示，而且可以发生于图6中操作614之后的任何时刻。如图5中所示，在另一个实施例(未示出)中，如果簇基础架构断定节点306是用作主节点的较好的选择，甚至当节点302返回至UP状况时，节点306也能够继续接管工作，例如，当节点302的性能低于性能的阈值水平以及节点306的性能处于所述阈值或者高于所述阈值时。

参照图7，该图描述了根据说明性实施例的资源宽限周期内的操作的时序图。时序图700为从使用与图3中所设置和所描述的相同的实体302、304、以及306的图3中的时序图300的另一个可选的继续。

等待周期320继续，如时序图700中所示。假设在等待周期320内节点302尚未恢复，如实施例所构想的，并且等待周期320过去，如图中所示，而且故障自动切断交换机超时周期截止，暂停NODE_A(操作714)。簇基础架构报告：NODE_A处于状态HALT(暂停)(操作716)。在被告知NODE_A的HALT之后某一时刻，NODE_B完成了预先准备(操作718)。在预先准备完成之后，NODE_B可以立即继续执行进一步的接管步骤，因为此时暂停了NODE_A。

参照图8，该图描述了根据说明性实施例的利用簇中并行性进行容障处理的工作负载节点和监视器节点的实例配置的结构图。节点802为图3中节点302的实例，并且将其相应地标记为“NODE_A”。节点806为图3中节点306的实例，并且相应地标记为“NODE_B”。任何数目的通向一或多个可用于分簇节点802和806的网络的路径、任何数目的通过簇中所使用的部件(例如，通向存储设备)的路径、或者它们的任何组合形成了云808。

实例通信通道810、812、814、816、818、820、822、824、826、828、以及其它这样的通信通道允许节点802、节点806、监视器节点830、监视器节点832、监视器节点834、监视器节点836、以及监视器节点838之间的可靠的通信。例如，通信通道810和812形成了节点802和监视器节点830之间的可靠通信通道。相类似，通信通道814和816形成了节点802和监视器节点832之间的冗余的可靠通信通道，其中，监视器节点830和832本身为冗余的，或者互相接管配置。把其它通信通道和监视器节点相类似地连接于节点806。

总体上讲，在本公开中，在“工作负载和监视节点之间的连接”的上下文中，术语“可靠的”用于描述：假设集成的物理介质或者硬件体系结构的完整部分的连接未发生故障。例如，可以把操作在连接各部件的系统总线(例如，图1中的系统总线106、I/O总线112、PCI总线195、ISA总线196等任何之一)上的固件视为可靠的通信通道，因为假设所述总线无故障。如果固件或者总线发生故障，则无任何系统存活的保证。在作为软件栈的部件的固件之上的层上执行的操作系统不尝试第二推测状态、固件提供的信息和服务。所述固件具有内置的可靠性功能。例如，所述固件可以考虑总线故障的可能性，并且通过第二总线重新路由其协议。

为了实现监视节点和工作负载节点之间的可靠连接，实施例向固件添加了相应的功能，即，通过利用已经存在的基础架构或者通过以固件编程方式针对可靠性重新设计遵循既定范例的功能。于是，图8中的通信通道810和812、以及其它如此描述的通道形成了可靠通信通道，不仅由于冗余，而且还因为按以上所描述的实例方式提供了通向所述基础架构的不同的路径。不限于所描述的两个实例通道，在所述说明性实施例的范围内，可以把任何数目和类型的通道类似地配置为作为可靠通信通道加以操作。

仅作为实例，把监视器节点830、832、836、以及838描述为VIOS。作另一个实例，把监视器节点834描述为配置了实施例的各个方面的管理器(hypervisor)，例如，具有图2中的监视应用205-A的某些或者全部特性，以作为监视器节点加以操作。

类似于把管理I/O资源的分割部分用作服务于故障节点对数据的访问的监视节点，可以扩展宿主簇域中节点的管理器，以在需要的情况下使其能够暂停故障节点。各实现可以包括作为簇域中监视器节点主动参与的管理器、或者通过可信的、良好定义的API支持“切断节点”接口的管理器。于是，在监视器节点的角色中，实施例向管理器分派任务，以支持从簇的操作域强行去除节点。

图8中描述的可靠通信通道并未穷举。节点802和节点806使用类似的可靠通信通道(未示出)执行实质的簇功能，例如，与不同监视器节点以及簇中其它节点互相发布心跳消息。与节点802或者806中的簇服务相比，每一个监视器节点分别至少执行簇服务的最小子集。监视节点中的所述簇服务的最小子集足以满足簇域的功能需求。

监视器节点，例如监视器节点830，具有暂停同一架构上诸如节点802的工作负载节点的能力。如果监视器节点为VIOS(其为监视器节点830的实例)，则监视器节点可以挂起相关联的工作负载节点的I/O活动。根据实施例，可以通过簇范围协议指示监视器节点根据活跃簇域的指令执行多个簇动作任何之一。所述说明性实施例提供了簇中当前不可得的若干新的指令，可以与现存的指令相结合地使用这些指令。

例如，节点806可以通过NODE_HALT指令指示监视器节点830暂停节点802。如果监视器节点830为VIOS，则节点806可以通过NODE_IO_SUSPEND指令指示监视器节点830挂起节点802上的I/O。相反，如果监视器节点830为VIOS，则节点806也可以通过NODE_IO_RESUME指示监视器节点830重新开始节点802上的I/O。这些实例指令的提供仅仅是为了描述的清晰，不构成对所述说明性实施例的限制。因此，响应节点功能的劣化或者频繁出现在复杂分簇数据处理环境中的故障，通过使用用于监视、暂停节点或者挂起和重新开始节点处的I/O的平台部件或者VIOS，实施例实现了对动作的较广泛的选择。

参照图9，该图描述了根据说明性实施例的利用簇中并行性进行容障处理的实例配置。可以把节点902作为图8中的节点802加以实现，并且将其相应地标记为“NODE_A”。可以把监视器节点930作为图8中的监视器节点830加以实现。

作为实例，使用成员关系部件904、可靠消息处理部件906、以及资源管理器908配置作为簇中工作负载节点的节点902。成员关系部件904通过跨越多个冗余网络连接在簇成员之间发送心跳，维持簇中的各节点的状态。可靠消息处理部件906提供了针对分布式系统的实质功能，例如，簇中的可靠消息处理和障栅同步。资源管理器908使用较低层的服务实现了节点902中的分布式资源管理。

然而，可以根据实施例、按十分简洁的方式配置监视器节点930。例如，监视器节点930实现了参与簇的成员关系部件932。然而，监视器节点930仅实现了某些簇原语934，而不是整个可靠信息处理栈，如在节点902中。可能需要资源管理器(未示出)，取决于监视器节点930中所实现的功能。在一个实例实施例中，监视器节点930实现了允许监视器节点930作为簇中的VIOS加以操作的节点功能936。监视应用938允许节点930也作为监视器节点加以操作。

在一个实施例中，当宿主应用(例如，图2中的应用203-A)的节点902存在于架构上时，在该架构上动态地创建监视器节点930。例如，当资源组移至参与簇的架构上的节点902时，实施例在该架构上创建了一或多个类似于监视器节点930的监视器节点。由于执行上的原因，在不具有VIOS的平台体系结构上，或者在其中未使用VIOS的情况下，监视器节点的动态创建特别重要。为了嵌入簇范围协议以采集节点902上的应用，可以并行地创建监视器节点或分割部分930。当监视器节点930可操作并且集成于簇中时，实施例激活针对节点902的网络宽限周期和响应宽限周期。

在一个实施例中，监视节点930可以是不具有成员关系层全部功能的非常原始的监视节点。因此，监视节点930可能不能够维持具有以上多于一个节点的可靠通信链路。在这一情况下，它将不能区分它自己的状态。在这一情况下，将由两个节点，即由监视节点930和能够接收和发送心跳的簇中的另一个节点确定监视节点930的状态。

参照图10，该图描述了根据说明性实施例的利用簇中并行性进行容障处理的实例过程的流程图。例如，可以按图2中的接管应用207-A的形式在接管节点中实现过程1000。

接管应用开始于检测工作负载节点(例如，图9中的节点902)中的故障(步骤1002)。接管应用为故障节点设置等待周期，期望故障节点在等待周期内从所检测的故障恢复(步骤1004)。

接管应用从能够与保持操作的故障节点并行地执行的接管操作开始这些动作，例如，开始于执行接管节点上的并行预先准备动作(步骤1006)。接管应用向簇传播有关故障节点和接管节点的并行的信息(步骤1008)。

接管应用考虑故障节点的状态和接管节点的状态(步骤1010)。在一个实施例中，如果故障节点已经恢复，例如，如果故障节点变得再次可以响应，而且接管节点处的预先准备尚未完成(步骤1010的“A”路径)，则接管应用通过放弃预先准备操作放弃接管操作，并且允许先前发生故障的节点重新开始操作(步骤1012)。

在一个实施例中，如果故障节点变得再次可以响应，而且接管节点处的预先准备操作已经完成(步骤1010的“B”路径)，则在步骤1012处接管应用放弃预先准备，并且允许先前发生故障的节点重新开始操作。在另一个实施例中，如果故障节点变得再次可以响应，而且预先准备操作已经完成(步骤1010的“B”路径)，则接管应用继续从先前发生故障的节点接管(步骤1014)。在一个实施例中，如果故障节点在预先准备已经完成时仍不响应(步骤1010的“C”路径)，则在步骤1014处接管应用继续从发生故障的节点接管。此后，接管应用结束过程1000。

是放弃接管节点上的预先准备操作还是从故障节点接管，是接管应用通过考虑任何数目的面向实现的因素的组合所进行的判断，例如，所述因素包括但不局限于前故障节点和接管节点的可比的性能。本领域技术人员将会想象到更多的判断是从前一个故障节点接管还是放弃接管的因素，而且这些想象处于所述说明性实施例的范围。

参照图11，该图描述了根据说明性实施例的监视过程的流程图。可以在诸如图9中监视器应用938的监视器应用中实现过程1100。

监视器应用监视相关联的节点，例如，图9中的节点902(步骤1102)。监视器应用可以检测相关联的节点处的不同的情况。

例如，在一个实施例中，监视器应用检测到：相关联的节点在簇活动中发生故障，例如当所述节点不能够传输心跳时，但相关联的节点继续执行其它活动，例如I/O(步骤1104)。因此，监视器节点把表示相关联的节点部分地有响应的相关联的节点的状况传输给簇(步骤1106)。

在另一个实施例中，监视器应用检测到相关联的节点在簇活动中发生故障，并且还检测到相关联的节点未执行任何其它活动，例如I/O(步骤1108)。因此，监视器节点把表示相关联的节点无响应的相关联的节点的状况传输给簇(步骤1110)。

如果相关联的节点正在执行簇活动，或者簇活动与其它活动，则监视器应用向所述簇传输：相关联的节点为UP(未示出)。相类似，如果监视器节点检测到相关联的节点已经暂停，即瘫痪，则监视器应用向所述簇传输：相关联的节点为DOWN，即暂停(未示出)。

为了连续监视相关联的节点，可以无限次数地重复这些步骤，否则此后监视器应用可以结束过程1100。另外，也可以根据来自簇节点的请求(未示出)启动这些步骤。

参照图12，该图描述了根据说明性实施例的终止并行的实例过程的流程图。可以在簇基础架构中，例如在图3中的簇基础架构304中，实现过程1200。

簇基础架构决定暂停节点(步骤1202)。在一个实施例中，簇基础架构指示监视器应用暂停、切断、或者终止节点(步骤1204)，并且此后结束过程1200。在另一个实施例中，簇基础架构指示监视器应用仅终止节点对某些资源的访问，例如通过仅终止节点对数据存储器的I/O访问(步骤1206)，并且此后结束过程1200。

各图中的流程图和结构图说明了根据本发明各实施例的系统、方法、以及计算机程序产品的可能的实现的体系结构、功能、以及操作。就此而言，流程图或者结构图中的每一个框可以代表一个模块、段、或者代码部分，其包含用于实现具体逻辑功能的一或多条可执行的指令。还应该加以注意的是，在某些可选的实现中，所述框中所提到的功能可以不按图中所提到的次序出现。例如，实际上，可以完全并行地执行相继描述的两个框，有时也可以按相反的次序执行各框，取决于所涉及的功能。还应该加以注意的是，可以通过执行具体功能或者动作的、基于专用硬件的系统或者专用硬件与计算机指令的组合，实现结构图与/或流程图说明中的每一个框、以及结构图与/或流程图说明的框的组合。

因此，在利用簇中并行性进行容障处理的所述说明性实施例中提供了一种计算机实现的方法、系统、以及计算机程序产品。实施例为故障节点提供了在长于针对心跳消息的宽限周期的周期上，但在故障自动切断交换机超时截止之前从故障恢复的可调的或者可改变的投机性机会。在所述投机性机会周期期间，在预先准备操作中，接管节点执行那些来自接管操作的、能够在簇中与故障节点的连续操作并行执行的动作。如果在所述投机性机会周期内节点从故障恢复，则实施例允许故障节点在不进行接管的情况下重新开始正常的操作。如果故障节点在所述投机性机会周期内不能够从故障恢复，或者不能够按所希望的性能水平恢复，则实施例通过进一步地继续进行预先准备，接管故障节点的角色。

在一个实施例中，可以根据某些情况针对工作负载节点创建监视节点。例如，可以把新的或者现存的工作负载节点配置为超出阈值规定，例如，配置为使用多于阈值数目的CPU、存储器、或者线程。所述实施例判断：对于新的或者修改的工作负载节点，相应的监视节点是否存在。如果无一存在，则簇基础架构按此处所描述的方式动态地创建监视节点，并且与新的或者修改的工作负载节点相关联。

本领域技术人员将会意识到，可以把本发明的各个方面具体化为一种系统、方法、或者计算机程序产品。因此，本发明的各个方面可以呈完全硬件实施例、完全软件实施例(包括固件、驻留软件、微代码等)或者组合了软件与硬件方面的实施例的形式，通常可它们统称为“电路”、“模块”或者“系统”。另外，本发明的各个方面还可以呈计算机程序产品的形式，所述计算机程序产品包含在其上具有计算机可读程序代码的一或多个计算机可读存储设备或者计算机可读介质中。

可以使用一或多个计算机可读存储设备或者计算机可读介质的任何组合。计算机可读介质可以为计算机可读信号介质或者计算机可读存储介质。例如，计算机可读存储设备可以为，但不局限于电、磁、光、电磁、红外、或者半导体系统、装置、或者设备、或者它们的任何适当的组合。计算机可读存储设备的更多的具体实例(非穷举的列表)将包括如下：具有一或多条导线的电连接、便携式计算机软盘、硬磁盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或者闪存)、光纤、便携式紧致盘只读存储器(CD-ROM)、光存储设备、磁存储设备、或者它们的任何适当的组合。在这一文档的上下文中，计算机可读存储设备可以为能够包含或者存储指令执行系统、装置、或者设备所使用的或者处于与它们的连接中的程序的任何可触知的设备或者介质。

可以使用任何合适的介质传输包含在计算机可读存储设备或者计算机可读介质上的程序代码，所述合适的介质包括但不局限于无线线路、有线线路、光缆、RF等、或者它们的任何适当的组合。

可以按一或多种程序设计语言的任何组合编写用于执行本发明各方面的操作的计算机程序代码，所述一或多种程序设计语言包括诸如Java、Smalltalk、C++等的面向对象的程序设计语言，以及诸如“C”程序设计语言或者类似程序设计语言的传统的过程程序设计语言。程序代码可以作为独立软件程序包完全运行在用户的计算机上、部分地运行在用户的计算机上，部分地运行在用户的计算机上和部分地运行在远程计算机上，或者完全运行在远程计算机或者服务器上。在后面的情况下，可以通过任何类型的网络把远程计算机连接于运行用户的计算机，所述网络包括局域网(LAN)或者广域网(WAN)，也可以连接于外部计算机(例如，通过使用Internet服务提供商的Internet)。

此处参照根据本发明实施例的方法、装置(系统)以及计算机程序产品的流程图说明与/或结构图，描述了本发明的各个方面。应该意识到，可以通过计算机程序指令实现流程图说明与/或结构图的每一个框、以及流程图说明与/或结构图中各框的组合。可以把这些计算机程序指令提供于一或多个通用计算机、专用计算机、或者其它可编程数据处理装置的一或多个处理器，以产生机器，从而能够使经由计算机或者其它可编程数据处理装置的一或多个处理器执行的指令创建用于实现流程图与/或结构图框中所指出的功能/动作的机制。

也可以把这些计算机程序指令存储在一或多个计算机可读存储设备或者计算机可读介质中，这些计算机可读存储设备或者计算机可读介质可以指挥一和多个计算机、一或多个其它可编程数据处理装置、或者一和多个其它设备按特定的方式运作，从而使存储在一和多个计算机可读存储设备或者计算机可读介质中的指令产生制造产品，所述指令包括实现流程图与/或结构图框中所指出的功能/动作的指令。

也可以把这些计算机程序指令加载于一或多个计算机、一或多个其它可编程数据处理装置、或者一或多个其它设备，以导致在一或多个计算机、一或多个其它可编程数据处理装置、或者一或多个其它设备上执行的一系列操作步骤，以产生计算机实现的过程，从而能够使在一或多个计算机、一或多个其它可编程数据处理装置、或者一或多个其它设备上执行的指令提供用于执行流程图与/或结构图框中所指出的功能/动作。

此处所使用的术语仅旨在描述具体的实施例，并不旨在对本发明加以限制。如此处所使用的，单数形式的“一个(英文的a或者an)”以及“该或者所述(英文的the)”也旨在包括复数形式，除非上下文明确加以表示。还应该意识到，当用于本说明书时，术语“包含(英文的comprises与/或comprising)”指出所陈述的特性、整体、步骤、操作、元件、与/或部件的存在，但不排除一或多个其它特性、整体、步骤、操作、元件、部件、与/或它们成组的存在或者添加。

以下权利要求中的所有机制或者步骤以及功能元件的相应的结构、材料、动作、以及等同物旨在包括用于与其它提出权利要求的元件(如特别提出权利要求的)相组合地执行所述功能的任何结构、材料、或者动作。已经对本发明进行了描述，这一描述出于说明与描述的目的，而非旨在以所公开的形式穷举或者限制本发明。本领域技术人员将会明显意识到，可以在不背离本发明的范围与宗旨的情况下对本发明进行诸多的修改与变动。实施例的选择与描述旨在最好地解释本发明的原理和实际的应用，并且使本领域的其他技术人员能够理解本发明，因为不同的实施例具有适合于所考虑的具体应用的不同的修改。

Claims (21)

1.一种利用分簇数据处理环境中并行性进行容障处理的方法，所述方法包含：

检测第一计算节点中的故障，第一计算节点服务于一簇计算节点中的应用；

从动作集合中选择动作的子集，把所述动作集合配置为将应用的服务从簇中的第一计算节点转递于第二计算节点；

为第一计算节点设置等待周期；

允许第一计算节点在等待周期期间继续服务于簇中的应用；

在等待周期期间，与服务于应用的第一计算节点并行地执行第二计算节点处的动作的子集；以及

响应于在等待周期期间从第一计算节点接收活动的信号，退出簇中第二计算节点的并行操作。

2.根据权利要求1所述的方法，其中，执行动作的子集包含：完成接管的准备任务。

3.根据权利要求1所述的方法，还包含：对动作的集合重新排序，从而能够在动作集合中第二动作子集之前执行动作的子集。

4.根据权利要求3所述的方法，其中，动作的第二子集的执行结束了第一计算节点和第二计算节点的并行操作。

5.根据权利要求4所述的方法，其中，动作的第二子集终止了来自第一计算节点的应用的服务。

6.根据权利要求1所述的方法，还包含：

监视第一计算节点，其中，所述监视包含：检测第一计算节点是否正在执行簇活动和第二活动；以及

响应检测到第二活动以及未检测到簇活动，向簇通知：第一计算节点部分地可操作。

7.根据权利要求6所述的方法，还包含：

在从第一计算节点向第二计算节点转递应用的服务期间，接收指示暂停第一计算节点的指令；以及

响应所述指令，终止第一计算节点的输入/输出操作而不是暂停第一计算节点。

8.根据权利要求6所述的方法，还包含：为第一计算节点设置响应宽限周期，其中响应宽限周期是对其中期望第一计算节点从故障恢复的时间估计。

9.根据权利要求1所述的方法，还包含：

监视第一计算节点，其中所述监视包含：检测第一计算节点是否正在执行簇活动和第二活动；以及

响应未检测到第二活动以及未检测到簇活动，向簇通知：第一计算节点为不响应。

10.根据权利要求9所述的方法，还包含：为第一计算节点设置网络宽限周期，其中，网络宽限周期是对其中期望用于与第一计算节点通信的网络部件变为可操作的时间估计。

11.根据权利要求9所述的方法，其中，检测簇活动包含：检测第一计算节点是否发送心跳消息。

12.根据权利要求9所述的方法，其中，检测第二活动包含：检测第一计算节点是否执行输入/输出操作。

13.一种计算机可用程序产品，其包含计算机可用存储设备，所述计算机可用存储设备包括利用分簇数据处理环境中并行性进行容障处理的计算机可用代码，所述计算机可用代码包含：

用于检测第一计算节点中的故障的计算机可用代码，第一计算节点服务于一簇计算节点中的应用；

用于从动作集合中选择动作的子集的计算机可用代码，把所述动作集合配置为将应用的服务从簇中的第一计算节点转递于第二计算节点；

用于为第一计算节点设置等待周期的计算机可用代码；

允许第一计算节点在等待周期期间继续服务于簇中的应用的计算机可用代码；

在等待周期期间，与服务于应用的第一计算节点并行地执行第二计算节点处的动作的子集的计算机可用代码；以及

响应于在等待周期期间从第一计算节点接收活动的信号，退出簇中第二计算节点的并行操作的计算机可用代码。

14.根据权利要求13所述的计算机可用程序产品，其中，执行动作的子集的计算机可用代码包含：用于完成接管的准备任务的计算机可用代码。

15.根据权利要求13所述的计算机可用程序产品，还包含：用于对动作的集合重新排序，从而能够在动作集合中第二动作子集之前执行动作的子集的计算机可用代码。

16.根据权利要求15所述的计算机可用程序产品，其中用于执行动作的第二子集的计算机可用代码结束第一计算节点和第二计算节点的并行操作。

17.根据权利要求16所述的计算机可用程序产品，其中，动作的第二子集终止来自第一计算节点的应用的服务。

18.根据权利要求13所述的计算机可用程序产品，其中，把计算机可用代码存储在数据处理系统中的计算机可读存储介质中，而且其中，从远程数据处理系统通过网络传送计算机可用代码。

19.根据权利要求13所述的计算机可用程序产品，其中，把计算机可用代码存储在服务器数据处理系统中的计算机可读存储介质中，而且其中，通过网络把计算机可用代码下载于远程数据处理系统，以用于与远程数据处理系统相关联的计算机可读存储介质。

20.一种利用分簇数据处理环境中并行性进行容障处理的数据处理系统，所述数据处理系统包含：

包括存储介质的存储设备，其中，存储设备存储计算机可用程序代码；以及

处理器，其中，处理器执行计算机可用程序代码，而且其中，计算机程序代码包含：

用于检测第一计算节点中的故障的计算机可用代码，第一计算节点服务于一簇计算节点中的应用；

用于从动作集合中选择动作的子集的计算机可用代码，把所述动作集合配置为将应用的服务从簇中的第一计算节点转递于第二计算节点；

用于为第一计算节点设置等待周期的计算机可用代码；

允许第一计算节点在等待周期期间继续服务于簇中的应用的计算机可用代码；

在等待周期期间，与服务于应用的第一计算节点并行地执行第二计算节点处的动作的子集的计算机可用代码；以及

响应于在等待周期期间从第一计算节点接收活动的信号，退出簇中第二计算节点的并行操作的计算机可用代码。

21.一种系统，包含用于实现任何权利要求1～12的方法步骤的装置。