CN1893370A

CN1893370A - 用于服务器群集恢复和维护的方法和系统

Info

Publication number: CN1893370A
Application number: CN200610079870.8A
Authority: CN
Inventors: 苏迪赫·G.·劳; 布鲁斯·M.·杰克逊
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2005-06-29
Filing date: 2006-05-15
Publication date: 2007-01-10
Anticipated expiration: 2026-05-15
Also published as: CN1893370B; US8195976B2; TW200712910A; US20120166866A1; US20070006015A1; US8286026B2

Abstract

本发明公开一种群集恢复和维护系统、方法和计算机程序产品，用于在客户端－服务器计算架构中实现服务器层的、具有多个节点的服务器群集。第一组N个有效节点各自运行包括群集管理层和群集应用层的软件栈，其中群集应用层有效地代表运行在客户端上的客户端应用层中的一个或多个客户端应用提供服务。第二组M个备用节点各自运行包括群集管理层和群集应用层的软件栈，其中群集应用层不有效地代表客户端应用提供服务。响应于有效节点成员关系改变，确定群集中的第一和第二区域，其中有效节点成员关系改变涉及由于有效节点出故障或者变得不可及或者由于涉及有效节点的维护操作而一个或多个有效节点离开或者被添加到第一组。第一区域是故障容忍区域，其包括所有工作的有效节点。第二区域是故障容纳区域，其包括在成员关系改变涉及节点离开的范围内，参与成员关系改变的所有有效节点以及至少对应数目的备用节点。在群集恢复和维护期间，在故障容纳区域中实现快速恢复/维护和高应用可用性，同时在故障容忍区域中保持连续应用可用性。

Description

用于服务器群集恢复和维护的方法和系统

技术领域

本发明涉及计算机群集和用于群集应用恢复的方法。更具体地说，本发明涉及一种用于改善群集恢复处理期间的群集应用可用性的恢复技术。

背景技术

作为背景，被管理数据处理群集通常用来在客户端-服务器架构中实现服务器层。不是单个服务器向客户端提供应用服务，而是应用服务功能由在群集管理软件的控制之下协同操作的互连节点网络(服务器群集)共享。群集管理软件的职责通常包括群集组成员关系变化协调、故障监视和检测、以及向服务器节点应用层提供分布式同步点。这些群集支持功能允许服务器实现提供群集化服务的内聚(cohesive)群集应用层。群集化服务是有利的，这是因为多个节点可以共享应用工作负载，并且由此改善数据处理性能以及应用可用性。可以在服务器群集中运行的示例性应用包括网络文件系统、分布式数据库、万维网服务器、电子邮件服务器等等。

群集架构往往使用对称模型，其中每一个节点可以服务任何应用请求，或者它们使用非对称/分区模型，其中跨越群集对应用空间进行静态或动态分区。根据对称模型，每一个节点相对于群集所提供的应用服务是同构的，并且不存在应用空间的分区。每一个节点可以处理来自群集化应用的客户端的任何请求。根据分区模型，存在应用空间的静态或动态分区(有时被称为N路(N-way)逻辑分区)，其中每个节点服务针对其拥有的分区的请求。

不管群集是遵循对称模型还是遵循分区模型，群集节点的丢失通常将不停止其应用或应用分区，这是因为群集管理软件可以将丢失服务器的功能转移到另一个节点。但是，群集节点(或者节点之间的通信链接)的故障中断群集操作。当发生这样的故障时，启动被称作群集恢复的处理，以便恢复由于故障而丢失的应用功能性。除非群集架构是故障容忍的，否则群集恢复过程将几乎总是导致跨越从故障检测开始直至故障恢复和应用恢复完成的时间段的、整个群集化应用的临时中断。该应用处理停止不利地影响应用客户端，包括连接到群集的幸存节点的那些应用客户端。如此，日益增加地对基于群集架构的产品的恢复特性施加近连续或甚至连续应用可用性要求。

一般而言，群集恢复的总持续时间源于下面与恢复过程相关联的活动的一些或全部：

1)故障检测和验证；

2)通过同步群集成员关系视图更新的群集恢复；

3)防护(fencing)出故障节点(以停止应用I/O操作)；

4)应用分区故障恢复(failover)(仅仅针对逻辑分区架构)；

5)预写(write-ahead)日志恢复；以及

6)应用请求重新路由

前述恢复步骤导致整个群集恢复时期的群集应用中断是传统的群集管理系统和群集应用的工作方式的直接结果。具体地说，群集应用事务处理的完整性以群集管理软件保证群集和应用数据的完整性为前提。由于在群集恢复期间不能在整体上保证群集完整性，并且由于不能保证数据完整性直至防护、故障恢复和预写日志恢复之后，因此传统的群集化应用系统选择在整个恢复期间暂停所有事务活动。与该设计方案相一致，迄今为止的改进群集恢复的大部分努力集中于减少对总恢复时间作贡献的各个步骤的持续时间。

关于故障检测和验证，通过实现多个冗余监视拓扑结构以便为故障检测提供多个数据点，可以减少该时间段。例如，双重环形或三重环形、基于心跳的监视拓扑结构(例如，需要或采用双重网络)可以显著减少故障检测时间。然而，该方案对群集或应用恢复处理本身没有影响。该架构还提高了群集化应用的成本。

关于群集成员关系视图更新(在群集恢复期间)，在群集管理架构典型地被设计成序列化群集恢复协议和群集内消息传递协议(前者与群集恢复有关；后者从应用活动中产生)的限度内，没有太多工作可做。结果，不能发生应用活动，直至高优先级群集恢复协议结束。根据定义，这强制群集范围的服务暂停或中断。

关于出故障节点防护和应用分区故障恢复，如果群集实现对称应用架构，则没有相关联的成本，这是因为可以简单地将客户端请求定向到另一个节点。然而，在分区模型中，存在应用空间的静态或动态分区，其中每个节点服务针对其拥有的分区的请求。在该架构中，应用恢复的成本将总是包括防护和分区故障恢复的成本，并且由此与对称模型相比，承担提高的应用恢复成本。同步日志记录(与异步预写日志相对)或者主动型缓冲缓存刷新可以用来帮助降低故障恢复成本，但是这两个解决方案都影响稳定状态性能。

关于基于日志的恢复和应用请求重新路由，很多群集系统使用日志化/日志架构(例如，数据库、文件系统)，其确定内在的、基于日志的恢复特性以及应用事务的连续性。典型地，静态或动态分区模型中的每个节点为由该节点服务的所有应用分区使用单个预写日志(WAL)。为了将分区从出故障节点故障恢复到有效节点，首先必须截除(truncate)有效节点上的预写日志，这要求刷新缓冲缓存以及将日志页写出到盘。使用将预写日志一一映射到应用的逻辑分区(与将它与群集中的节点进行一一映射相对)的日志架构将在不受影响的应用分区和受影响的分区之间提供更大的事务隔离。结果，在不受影响的分区上将存在更大的事务连续性，并且对于受影响的分区，存在更短的、基于日志的恢复时间。这里所使用的术语“不受影响的分区”是指在有效(无故障)节点上运行的任何分区。相反，“受影响的分区”是由(例如，由于故障、预定维护或者任何其它原因)变得不可及的节点服务的分区。将受影响的分区故障恢复到其不受影响的分区具有其自己的预写日志映射的有效节点将不影响这样的日志。将简单地为正被故障恢复到有效节点的分区创建新的预写日志。然而，实现这种日志架构将要求很多群集应用产品的较大重新编写，并且可能是不实际的。这样的架构的扩展性对于大量分区(按照所需存储空间)也不好。

存在使用硬件架构的存储工具(applicance)，其中硬件架构具有对存储器中的预写日志缓冲器和盘上的预写日志的内置冗余访问。通过使用节点对之间的同步日志复制方案，这些系统自然地遵循故障容忍原则，而非基于恢复的模型，以便实现高可用性。这允许兄弟节点从出故障节点停止处接管。然而，虽然同步日志复制在有效-有效高可用性解决方案中工作得非常好，但是难以将该模型推广到没有用于同步日志复制的配对节点的群集。这显著地增加了成本以及复杂度。

发明内容

通过一种新颖的群集恢复和维护系统、方法和计算机程序产品，解决了前述问题，并且获得了技术进步，其用于在客户端-服务器计算架构中实现服务器层的、具有多个节点的服务器群集。第一组N个有效节点各自运行包括群集管理层和群集应用层的软件栈，其中群集应用层有效地代表运行在客户端上的客户端应用层中的一个或多个客户端应用提供服务。第二组M个备用节点各自运行包括群集管理层和群集应用层的软件栈，其中群集应用层不有效地代表客户端应用提供服务。响应于涉及由于有效节点出故障或者变得不可及或者由于涉及有效节点的维护操作而一个或多个有效节点离开或者被添加到第一组的有效节点成员关系改变，确定群集中的第一和第二区域。第一区域是故障容忍区域(fault tolerant zone)，其包括所有工作的有效节点。第二区域是故障容纳区域(fault containment zone)，其包括在成员关系改变涉及节点离开的范围内，参与成员关系改变的所有有效节点以及至少对应数目的备用节点。在群集恢复和维护期间，在故障容纳区域中实现快速恢复/维护和高应用可用性，同时在故障容忍区域中保持连续应用可用性。

通过在故障容忍组和故障容纳组之间保持事务隔离，并且通过在故障容忍区域中保持事务连续性，实现前述方面。通过将由故障容纳组中的(一个或多个)不可及或被移除节点提供的客户端应用服务故障恢复到故障容纳组中对应数目的备用节点，实现事务隔离。由于备用节点在故障恢复之前不提供事务服务，因此不影响任何有效节点上的事务处理。对于新添加的节点，它们将变成新的备用节点，或者它们将变成新的有效节点。如果是后者，则向这些节点分配应用工作负载将不影响故障容忍区域中的事务处理。通过保证故障容忍区域中的群集成员关系完整性并且确保用于支持应用事务连续性的群集内消息的、应用驱动的恢复前通信会话的连续生存性，实现故障容忍区域中的事务连续性。通过监视故障容忍区域节点健康状况并且将发生低概率恢复时间故障的任何节点迁移到故障容纳区域，由此确保故障容忍区域中的连续可用性，从而保证故障容忍区域中的群集成员关系完整性。通过在恢复期间利用在群集范围进行的、正常的基于请求/响应的群集恢复通信协议，可以有利地执行故障容忍区域中的节点监视。一旦在故障容忍区域中不能接收节点响应，则可以通过将无响应节点标记为出故障来减少故障容忍区域中的组成员数目(group membership size)，从而确保恢复协议收敛。通过除非被标记为出故障的节点使用标准加入协议重新加入，否则拒绝这些节点的重新入组，可以防止协议变动。通过使用不随着组成员数目而改变的绝对节点标识符以及保留通信会话数据结构，可以确保恢复前通信会话的生存性。

通过并发群集通信协议的适当范围界定(scoping)，可以进一步帮助故障容忍区域中的事务连续性。应用恢复协议限于故障容纳组的群集应用和群集管理层。正常的事务应用协议限于故障容忍组的群集应用和群集管理层。群集恢复协议在故障容忍组和故障容纳组两者的群集管理层中进行。

附图说明

根据下面对如附图所示的本发明示例性实施例的更具体描述，本发明的前述和其它特征和优点将会变得清楚，其中：

图1是示出客户端-服务器计算架构的功能方框图，其中服务器层通过被适配成根据本发明执行群集恢复的群集实现；

图2是示出实现分布式文件系统的存储区域网中的、图1的客户端-服务器计算架构的示例性实现的功能方框图；

图3是在故障之前、期间和之后的、图1的群集的示例性逻辑视图；

图4是示出在群集恢复之前的、图1的群集中的拓扑结构监视的示例性形式的功能方框图；

图5是示出在群集恢复期间的、图1的群集中的拓扑结构监视的示例性形式的功能方框图；

图6是示出在群集恢复之后，在图1的群集中如何保持事务隔离、通信连续性，并且因此保持事务连续性的功能方框图；

图7是示出根据本发明的示例性群集恢复步骤的流程图；以及

图8是可以用来存储计算机程序产品的存储介质的示意图，其中该计算机程序产品用于实现根据本发明的入侵检测功能。

具体实施方式

I.介绍

现在转到附图，其中在所有几个视图中，相同标号表示相同单元，图1示出了客户端-服务器计算架构2，其中由服务器群集4提供服务器层。仅仅为了说明起见，而不是作为限制，服务器群集4被实现成网络(未示出网络互连)，其包括由标号4₀、4₁、4₂、4₃、4₄、4₅、4₆和4₇指定的八个服务器节点。服务器节点4₀-4₇是计算机平台，其运行包括两层即群集应用层6和群集管理层8的软件栈。群集应用层6包括代表由标号10₀、10₁...10_n指定的、任意数目的客户端节点实现提供群集化服务的群集化服务器应用的软件。在客户端应用层12内，客户端10₀、10₁...10_n运行客户端应用软件。客户端节点10₀、10₁...10_n可以通过任何适当的通信接口与服务器节点4₀-4₇通信。例如，可以存在单个客户端-服务器网络(未示出)，其中所有客户端节点能够与所有服务器节点通信。可选地，可以存在若干客户端-服务器网络(未示出)，其中客户端节点的子集与服务器节点的子集通信。另一可选方案将是提供多个单独通信链接(未示出)，其中每个客户端节点与单个服务器节点通信。

由服务器节点4₀-4₇运行的群集应用层软件6可以包括对于单个服务器节点各自唯一的应用分区，从而提供N路逻辑分区架构。可选地，群集应用层软件6可以包括运行在多个服务器节点上的同构应用实例，以提供对称的群集架构。仅仅为了说明起见，而不是作为限制，图1示出了每个服务器节点4₀-4₇分别运行独特的群集应用分区的场景。这些软件实体分别被指定为App 0、App 1、App 2、App 3、App 4、App 5、App 6和App 7，其中应用分区号码对应于它运行在其上的服务器节点号码。虽然未示出，若干应用分区运行在单个服务器节点上也是可能的，在这种情况下，标记App 0等可以分别涉及不只是一个分区。

群集应用层软件6与服务器节点4₀-4₇上的群集管理层软件8交互，以便群集应用层中的应用分区可以表现为群集化服务。为此，传统地，群集管理层软件8向群集应用层软件6提供分布式同步点和其它服务。群集管理层8还负责执行群集维护和完整性功能，例如群集组成员关系改变的协调，以及故障监视和检测。此外，如下面结合图4等更详细地描述的那样，群集管理层软件8还实现根据本发明的恢复操作。

现在转到图2，示出了其中可以实现图1的客户端-服务器计算架构2的示例性环境。具体地说，图2示出了存储区域网(SAN)20，其中多个SAN文件系统客户端22₀、22₁...22_n通过SAN结构24互连到系统存储池，该系统存储池包括(仅仅作为示例)四个存储子系统26、28、30和32。服务器群集34(对应于图1的服务器群集4)用来支持SAN 20中的分布式文件系统操作。如在数据存储技术领域内所公知的那样，SAN环境中的分布式文件系统的目标是要提供诸如以下益处，即文件的全局名称空间而不管它们被存储在哪里，从任何文件系统客户端到任何存储装置的共享访问，以及集中式、基于策略的管理。提供了基于SAN的分布式文件系统的一种商业产品是IBMTotalStorageSAN文件系统。该产品实现带外(out-of-band)存储虚拟化，其中文件元数据(例如，文件名称、属性、权限等)被存储在与表示用户数据的文件块不同的位置。在图2中，服务器群集34包括八个元数据管理器34₀、34₁、34₂、34₃、34₄，34₅、34₆和34₇(对应于图1的服务器节点4₀-4₇)，其代表文件系统客户端22₀、22₁...22_n处理文件元数据。该元数据在图2中被示出为存储在位于存储子系统28上的两个元数据卷中。元数据管理器34₀-34₇使用TCP/IP分组通信等，通过网络36与文件系统客户端服务器22₀、22₁...22_n通信。

在SAN 20中的数据检索操作期间，元数据管理器34₀-34₇处理来自运行在调用元数据管理器服务器功能的文件系统客户端22₀、22₁...22_n上的客户端层应用的元数据请求。这样，当文件系统客户端22₀、22₁...22_n中的一个需要向或从保存用户数据的存储子系统26、30或32中的一个传输文件数据时，它向元数据管理器34₀-34₇中的一个查询，以确定文件位置以及其它控制信息。一旦将该信息返回到请求文件系统客户端22₁、22₂...22_n，并且它获得对该文件的适当锁定，文件系统客户端就可以执行所需的数据传输操作，而无需元数据管理器34₀-34₇的进一步介入。

在诸如IBMTotalStorageSAN文件系统的分布式文件系统产品中，每个元数据管理器34₀-34₇典型地执行与分布式文件系统名称空间的某个所分配部分有关的元数据操作。这样，可以将每个元数据管理器34₀-34₇视作运行单独的元数据群集应用分区，并且可以将这些应用分区类推到图1中的、被标注为App 0...App 7的群集应用分区。需要访问文件的任何文件系统客户端22₀、22₁...22_n将被定向到负责与指定文件名称相对应的文件系统名称空间子树部分的元数据管理器34₀-34₇。如此，IBMTotalStorageSAN文件系统实现N路逻辑分区架构。

IBMTotalStorageSAN文件系统的另一特征是将分配元数据管理器34₀-34₇中的一个以用作主元数据管理器。在图2中，这是元数据管理器34₀。其它元数据管理器34₁-34₇中的任何一个同样可以用作主元数据管理器(管理器34₀的指定是任意的)，或者如果元数据管理器34₀发生故障，则可以选择它们来替换元数据管理器34₀。主元数据管理器34₀是负责群集管理的群集领导者或协调者，该群集管理包括向其它元数据管理器34₁-34₇分配分布式文件系统名称空间职责、以及从出故障的元数据管理器到其对等者(peer)中的一个或多个的元数据服务器功能的故障恢复。主元数据管理器34₀还提供元数据管理管理性(administrative)接口，其可以通过图2的管理性控制台38来访问。

在图1和2的上下文中，如果群集服务器节点在群集操作期间由于故障或其它条件而变得不可及，或者如果为了维护而移除节点，或者如果添加新的节点，则应当以最小的对客户端应用的影响，执行群集恢复或维护。本发明有利地实现了该目标。它提供了一种可以在通用群集中实现的架构，用于通过在发生故障时或在预定维护期间确保大部分群集应用的连续可用性，同时最小化对应用的受影响部分的中断，从而赋予故障容忍性。关于应用可用性和恢复/维护，这允许从高(99.9％-99.99％)可用性到连续(99.995％-99.999％)可用性的范围内获得通用群集，其中直到现在，该范围被认为是故障容忍系统的领域。虽然这些优点在逻辑分区群集中是最明显的，但是对于对称群集，也提供相同的优点。为了便于参考，并且除非上下文特别要求，所有以后使用的术语“群集应用”将被理解成包括根据逻辑分区群集模型的群集应用分区、以及根据对称群集模型的同构群集应用实例。

使用基于N+M冗余群集模型的容纳(containment)技术来实现前述目标，该N+M冗余群集模型针对大小N的群集中的多达M个故障(N＞M)。这通过图3示出，图3示出了根据图1的八个节点群集4的软件视图。软件栈的最低级别是服务器节点实现的群集管理层8。在群集管理层8之上是服务器节点实现的群集应用层6。在群集应用层6之上是客户端节点实现的应用层12。群集管理层8之上的每个细垂直部分代表运行在单个服务器节点上的单个群集应用实例、以及运行在各个客户端节点上的对应客户端应用实例(在每个垂直部分中示出了三个)。如此组成的每个细垂直部分被称为应用井(silo)。

图3的最上部分是由故障之前的上述软件栈呈现的视图。根据假定的N+M冗余模型，存在第一组N个有效节点(n_0、n_1、n_2、n_3、n_4和n_5)，其中每个节点运行包括群集管理层8和群集应用层6的软件栈，其中群集应用层6代表运行在一个或多个客户端的客户端应用层12中的一个或多个客户端应用(应用井)，有效地提供服务。提供了第二组M个备用节点(m_0和m_1)，其中每个节点运行包括群集管理层8和群集应用层6的软件栈，其中群集应用层6不有效地代表客户端应用提供服务。备用节点m_0和m_1运行整个群集管理和群集应用软件栈，但是不被分配要服务的分区(在逻辑分区群集中)，并且不将应用请求转发到那些节点(在对称群集中)。如此，没有与m_0和m_1节点相关联的应用井。作为替代，没有客户端应用层的这些节点代表系统中的冗余或备用容量。虽然它们运行群集管理层和群集应用层软件，但是它们将没有实际的群集应用工作，直至发生故障恢复。

II.群集恢复

响应于有效节点中(n_0-n_5)的一个或多个由于故障而变得不可及，群集领导者(例如，图2的主元数据管理器34₀)在群集中虚拟创建第一和第二区域(例如，通过逻辑定义区域)。第一区域是故障容忍区域，其包括所有保持工作的有效节点(故障容忍组)。第二区域是故障容纳区域，其包括不可及的节点(一个或多个)和至少对应数目的备用节点(故障容纳组)。图3的中间部分示出了这样的区域划分示例。这里，故障发生在节点n_4和n_5中。故障容忍区域包括幸存节点的核心组，即，n_0、n_1、n_2和n_3。故障容纳区域包括故障组n_4和n_5、以及包括m_0和m_1的备用节点组。注意，如果存在附加的备用节点，则可以将它们并入到故障容纳组中，或者可以不考虑它们。在前一情况下，故障容纳组被定义为所有不可及节点和所有备用节点的联合。在后一情况下，故障容纳组包括所有不可及节点和相等数目的备用节点。

在群集恢复期间，在故障容纳区域中实现快速恢复和高群集应用可用性，同时在故障容忍区域中保持连续群集应用可用性。与不可及节点相关联的应用井因此将很快地恢复在线，并且与其余有效节点相关联的应用井将毫不减弱地继续，并且完全不知道群集恢复正在进行中。

通过在故障容忍组和故障容纳组之间保持事务隔离，实现在故障容纳区域中实现快速恢复和高群集应用可用性的能力。如图3的底部部分所示，通过使用故障恢复模型来保持事务隔离，在故障恢复模型中，群集领导者使由故障容纳组中的不可及节点(一个或多个)n_4和n_5的群集应用提供的客户端应用服务故障恢复到该组中的备用节点m_0和m_1。因为备用节点在故障恢复之前不提供事务服务，所以不影响任何有效节点上的事务处理。相反，在现有技术的N路群集系统中，典型地将出故障节点的事务处理故障恢复到其它有效节点。这意味着停止、点查(check-point)和截除(truncate)这些节点上的所有关键性事务处理实体，例如缓冲器管理组件、预写日志、及其相关联的的数据结构和事务原语，其通常由运行在给定节点上的所有群集应用共享。然后，需要将不可及节点的事务卷并入到对应的故障恢复节点中。结果，现有技术群集系统中的群集恢复几乎总是导致事务服务暂停。根据本发明，没有可能影响故障容忍组中的任何有效应用井的、运行在备用节点m_0和m_1上的事务组件，从而保持事务隔离。这样，即使对于在节点上服务的许多群集应用，每节点可以使用仅仅一个预写日志，但是通过使用N+M冗余和故障恢复模型来最小化故障恢复的成本。相关地，在不需要执行前述同步的限度内，在故障容纳组中，故障恢复过程将非常快速地进展。唯一的要求是存在足够的备用容量，以将应用服务处理功能从不可及节点转移到备用节点。使用本发明的技术，1或多达M个节点中的故障将被包含在2m个节点内，其中0＜m＜M，并且是并发故障数。

保持事务隔离还帮助确保在故障容忍区域中保持连续群集应用可用性。具体地说，将故障恢复操作包含到故障容纳组意味着，故障容忍组中的事务处理可以继续而不考虑故障恢复过程。在故障容忍区域中保持连续应用可用性的另一方面是在群集恢复期间，在故障容忍区域中提供事务连续性。群集领导者通过监视故障容忍区域中的节点，并且保证故障容忍区域的群集成员关系完整性，以及确保恢复前通信会话的连续生存性，从而实现这一点。前者是重要的，这是因为由于这样的事实，群集系统在恢复期间不能正常地继续事务处理，即，当群集恢复协议正在进行中(由于群集节点变得不可及或有故障)时，不保证群集完整性。当不能保证群集完整性时，在群集恢复期间将缓冲来自客户端应用的事务消息，或者将请求客户端应用在恢复之后重新发送其消息。这样，事务连续性要求所有关键性客户端应用和群集内消息传递不受阻碍地继续。根据本发明，当群集发生故障时，故障容忍区域透明地参与群集恢复，但是不受阻碍地继续其用于客户端应用事务的群集内消息传递。

现在转到图4和5，典型地，借助于维护有效的群集成员关系视图以及基于心跳的环形监视拓扑结构，在稳定状态操作期间(即，在群集恢复之前)保证群集完整性，其中基于心跳的环形监视拓扑结构检测由于节点变得不可及的任何完整性丢失。当比方说如图4所示在节点n_4和n_5中发生一个或多个故障时，群集将包括三个不同的子集：幸存节点的核心组，包括n_0、n_1、n_2和n_3；故障组，包括节点n_4和n_5；以及备用节点组，包括节点m_0和m_1。在故障的时候并且在恢复期间，由群集领导者如此识别故障容忍组的群集成员。仅仅为了说明起见，假定图4和5中的群集领导者是节点n_0。只要故障容忍区域中的每个单独群集成员保持与群集领导者连接，并且不以任何方式改变其故障容忍区域(其是群集的子组)视图，群集成员将继续作为故障容忍组成员而透明地操作。相反，发生了故障或者作为备用节点的节点如此存在于故障容纳组中，并且等待群集领导者的指示。

通过在群集恢复期间利用(leveraging)在群集范围执行的正常请求/响应通信技术，可以保证故障容忍区域中的群集成员关系完整性。该高度可靠的群集恢复协议技术涉及作为跨越包括两个区域的整个群集的分布式提交(commit)协议的成员关系视图更新。使用多播、广播或串行单播方法，群集领导者将消息发送到群集的其它节点，以便停顿事务活动，重组群集，并且执行成员关系更新，然后恢复事务活动。群集领导者的消息对应于“请求”(或发送)，并且群集成员的响应对应于“响应”(或接收)。如图5的星形监视拓扑结构所示，群集领导者跟踪响应于发送到群集成员的请求消息而接收的确认。虽然传统地用于现有的群集管理系统，但是本发明有利地利用该协议来监视故障容忍区域中的幸存节点，而不引入任何新的协议。在故障容忍区域中不需要新的群集恢复消息传递。作为替代，群集领导者被编程为将(在指定超时期间内)没有来自故障容忍区域的幸存节点的响应确认解释成节点故障。这将促使群集领导者将无响应节点指定为离线。因此，当群集恢复进行时，可以由群集领导者连续地监视故障容忍区域中的节点成员关系。有利地，在群集成员的群集管理层内实现请求/响应群集恢复通信协议，并且该协议透明地并且与故障容忍组中的群集应用层功能并发地进行，以便在群集恢复期间后者决不被中断。

故障容忍组中的事务完整性取决于故障容忍组完整性。如果群集领导者发生故障，则根据定义，不能存在故障容忍组，这是因为群集领导者的群集管理功能丢失。但是只要群集领导者工作，就可以总是保证故障容忍组完整性，即使故障容忍组的组成可能发生改变，也是如此。在群集恢复期间、在故障容忍区域中发生节点的并发故障这一不太可能的情况下，在相同协议期间或通过后续的群集恢复协议，群集领导者将出故障节点迁移到故障容纳区域。例如，假定在恢复协议期间的晚期，图5中的节点n_2发生故障，并且节点n_0、n_1、n_2和n_3的完整性临时丢失。群集领导者(n_0)可以在将故障容忍组减少一个节点之后重新启动群集恢复协议，使得故障容忍组的组成变成n_0、n_1和n_3。此后，群集领导者将基于新的范围而保持故障容忍组完整性。作为另一示例，假定在恢复协议中的初期，图5中的节点n_3丢失。在这种情况下，群集领导者(n_0)可以在相同恢复协议内从故障容忍区域中去除n_3。使用前述技术，只要向幸存成员提供故障容忍，故障容忍组的组成就可以浮动(按照离开该组的成员)。这保证了恢复协议收敛(convergence)，因为只能重新启动群集恢复协议最多N-1次(最大故障容忍组的大小减1)。

通过除非被标记为出故障的节点使用标准加入协议重新加入，否则拒绝这些节点的重新入组，可以防止故障容忍区域中的协议变动。在上面的示例中，当节点n_2在先前的协议迭代中已经被确定为出故障时，在群集恢复期间不允许节点n_2隐式加入群集。

通过使用不随着组成员数目而改变的绝对节点标识符，以及通过保留所有通信会话数据结构和上下文，可以确保在故障容忍区域中的节点之间的恢复前通信会话的生存性。所有消息传递会话典型地绑定到不仅通过节点IP地址端口来确定而且还可通过节点id寻址的会话端点。在群集重组或恢复之后，许多群集系统重新发布节点标识符。相反，本发明实现绝对且唯一的节点标识符，以便确保节点之间的通信会话独立于群集成员关系变化和群集恢复协议。为了实现前述内容，可以使用32位(或其它适当大小)的持久性计数器，其将支持适当数目(例如，直至4G)的唯一节点标识符的生成(直至发生绕回)。

通过群集领导者安排并发协议范围界定来进一步帮助故障容忍区域中的事务连续性。应用恢复协议限于故障容纳组的群集应用和群集管理层。从事务应用协议中产生的有效群集消息传递协议限于故障容忍组的群集应用和群集管理层。群集恢复协议限于故障容忍组和故障容纳组两者的群集管理层。如前所述，本发明还利用正常请求/响应群集恢复通信协议来监视故障容忍区域中的节点而不引入任何新的协议，使得在故障容忍区域中不发生新的群集恢复消息传递。该区域中的唯一附加消息传递是应用协议影响的群集内消息传递，其在传统系统中的群集恢复期间通常将被暂停。

图6示出了在故障容忍和故障容纳区域中的群集恢复期间的前述并发协议范围界定。被标注为“故障容纳组中的应用恢复”的协议流示出了应用恢复协议。这些协议被示出为故障容纳组的群集应用层中的虚拟消息，并且被封装为故障容纳组的群集管理层中的真实消息。被标注为“故障容忍组中的事务/应用连续性”的协议流示出了事务应用协议和对应的有效群集内消息传递协议。这些协议被示出为故障容忍组的群集应用层中的虚拟消息，并且被封装为故障容忍组的群集管理层中的真实消息。被标注为“整个群集中的群集恢复”协议流示出了群集恢复协议。该协议由故障容忍组和故障容纳组两者中的群集管理层实现。

这样，故障和恢复和故障恢复的影响包含在群集中的故障容纳组的2M个节点内，即，M个出故障节点和对应的M个备用或冗余节点。群集恢复协议影响所有N+M个节点的群集管理层，但是影响仅仅2M+1(+1针对群集领导者)节点的群集应用层，其中该2M+1节点参与将客户端服务分区从M个出故障节点故障恢复到M个备用节点。

现在转到图7，阐述了重述上面已经描述的群集恢复的各个阶段的示例性方法步骤。步骤S1示出了由于通过稳定状态心跳监视协议检测到不可及节点，由群集领导者检测到故障。在步骤S2，群集领导者基于不可及节点(一个或多个)的识别，确定故障容忍区域和故障容纳区域。步骤S3表示在故障容忍区域中发生的处理。如上所述，该处理要求群集领导者代表群集应用及其客户端保持通信和事务连续性，并且利用群集恢复协议来监视故障容忍区域节点。步骤S3还要求故障容忍区域中的每个节点的群集管理层参与正常的群集范围恢复协议。步骤S4表示在故障容纳区域中发生的处理。如上所述，该处理要求故障容纳区域中的每个节点的群集管理层参与正常的群集范围恢复协议。这样的节点的群集应用层参与应用故障恢复和恢复。

III.群集维护

在修复和重启了M个出故障节点之后，它们可以重新加入群集，以形成未被分配任何群集应用分区或工作负载的、新的M个备用或冗余节点。在该重新加入协议期间，本发明再次确保仅仅群集管理层受到群集成员关系视图更新的影响。群集应用层不受影响，并且不影响应用事务。当节点为了计划的维护而离开群集时，或者当新的节点被引入到群集中时，为了关于前者的连续应用可用性和后者中的快的维护，本发明确保再次将群集分成适当的故障容忍和故障容纳组(有/无备用节点)，以便实现前者上的连续应用可用性和后者中的快速维护。对于离开的节点，可以以类似于上述恢复场景的方式，将其应用井功能迁移到备用节点。对于进入的节点，它可以变成新的备用节点，或者它可以变成分配有应用工作负载的新有效节点。在两种情况下，通过这些操作，在故障容忍区域中，事务处理将不受影响。此外，注意，在只有当现有节点离开群集时才需要备用节点的限度内，在故障容纳区域中不要求备用节点。修复节点重新加入和节点离开/增加场景组成了本发明如何为大部分群集的应用服务提供连续可用性的附加示例。

因此，公开了一种群集分区恢复/维护技术，其实现了这样的目标，即在发生故障时或在预定维护期间，确保大部分群集应用的连续可用性，同时最小化对应用的受影响部分的中断。应当理解，本发明概念可以以各种方式在数据处理系统、机器实现方法以及计算机程序产品中的任一个中实施，其中在计算机程序产品中，程序化装置被记录在一个或多个数据存储介质中，以便用于控制数据处理系统(例如，群集领导者)执行所需功能。用于存储这样的程序化装置的示例性数据存储介质在图8中以标号100示出。介质100被示出为传统地用于商业软件销售的类型的便携式光存储盘。这样的介质可以单独地或者与并入所需功能性的操作系统或其它软件产品相结合地，存储本发明的程序化装置。程序化装置还可以被存储在便携式磁介质(例如，软盘、快闪存储棒等)，或者并入到计算机平台中的、与驱动系统(例如，盘驱动器)相组合的磁介质上。更广泛地，介质可以包括任何电子、磁、光、电磁、红外线、半导体系统、设备或装置、或者传播介质。

虽然描述了本发明的各个实施例，但是应当清楚，根据本发明，可以实现很多变体和可选实施例。因此，应当理解，除了根据所附权利要求及其等价物的精神之外，本发明不受到任何方式的限制。

Claims

1.一种在具有多个节点的服务器群集中的群集恢复和维护方法，包括：

响应于有效节点成员关系改变，确定所述群集中的第一和第二区域，其中所述有效节点成员关系改变涉及由于有效节点出故障或者变得不可及或者由于涉及有效节点的维护操作而一个或多个有效节点离开或者被添加到所述群集；

所述第一区域是故障容忍区域，其包括所有工作的有效节点；

所述第二区域是故障容纳区域，其包括在所述成员关系改变涉及节点离开的情况下，参与所述成员关系改变的所有有效节点以及某一数目的备用节点；

在群集恢复或维护期间，在所述故障容纳区域中实现快速恢复/维护和高群集应用可用性；以及

在群集恢复或维护期间，在所述故障容忍区域中保持连续应用群集可用性。

2.根据权利要求1所述的方法，其中通过将由所述故障容纳组中的任何离开节点提供的客户端应用服务故障恢复到所述故障容纳组中对应数目的所述备用节点，在所述故障容忍组和所述故障容纳组之间保持事务隔离。

3.根据权利要求1所述的方法，其中通过由于采用基于请求/响应的群集恢复通信协议来监视所述故障容忍区域中的节点成员关系完整性，并且从所述故障容忍区域中移除不能根据所述基于请求/响应的通信协议而提供节点响应的节点，保证所述故障容忍区域中的群集成员关系完整性，从而在所述故障容忍区域中保持事务连续性。

4.根据权利要求1所述的方法，其中通过独立于群集大小的绝对节点标识符以及保留故障容忍区域中的恢复/维护前通信会话，保证所述故障容忍区域中的通信连续性，从而在所述故障容忍区域中保持事务连续性。

5.根据权利要求1所述的方法，其中通过并发协议范围界定，在所述故障容忍区域中保持事务连续性，其中应用故障恢复和恢复协议限于所述故障容纳组的群集应用和群集管理层，并且正常的事务应用协议限于所述故障容忍组的群集应用和群集管理层。

6.根据权利要求1所述的方法，还包括将修复或维护之后的一个或多个离开节点重新加入到所述群集中作为备用节点。

7.一种具有多个节点的服务器群集，被适配成向访问所述群集的客户端提供群集应用服务，包括：

被适配成响应于有效节点成员关系改变，确定所述群集中的第一和第二区域的程序逻辑，其中所述有效节点成员关系改变涉及由于有效节点出故障或者变得不可及或者由于涉及有效节点的维护操作而一个或多个有效节点离开或者被添加到所述群集；

被适配成在群集恢复或维护期间，在所述故障容纳区域中实现快速恢复/维护和高群集应用可用性的程序逻辑；以及

被适配成在群集恢复或维护期间，在所述故障容忍区域中保持连续应用群集可用性的程序逻辑。

8.根据权利要求7所述的系统，其中通过被适配成将由所述故障容纳组中的任何离开节点提供的客户端应用服务故障恢复到所述故障容纳组中对应数目的所述备用节点的程序逻辑，在所述故障容忍组和所述故障容纳组之间保持事务隔离。

9.根据权利要求7所述的系统，其中通过被适配成由于采用基于请求/响应的群集恢复通信协议来监视所述故障容忍区域中的节点成员关系完整性，并且从所述故障容忍区域中移除不能根据所述基于请求/响应的通信协议而提供节点响应的节点，保证所述故障容忍区域中的群集成员关系完整性的程序逻辑，在所述故障容忍区域中保持事务连续性。

10.根据权利要求7所述的系统，其中通过被适配成通过独立于群集大小的绝对节点标识符以及保留故障容忍区域中的恢复/维护前通信会话，保证所述故障容忍区域中的通信连续性的程序逻辑，在所述故障容忍区域中保持事务连续性。

11.根据权利要求7所述的系统，其中通过被适配成实现并发协议范围界定的程序逻辑，在所述故障容忍区域中保持事务连续性，其中应用故障恢复和恢复协议限于所述故障容纳组的群集应用和群集管理层，并且正常的事务应用协议限于所述故障容忍组的群集应用和群集管理层。

12.根据权利要求7所述的系统，还包括被适配成将修复或维护之后的一个或多个离开节点重新加入到所述群集中作为备用节点的程序逻辑。

13.根据权利要求7所述的系统，其中所述程序逻辑在所述服务器群集的群集领导节点中实施。

14.一种用于具有多个节点的服务器群集中的计算机程序产品，包括：

一个或多个数据存储介质；

记录在所述数据存储介质上的、用于对数据处理平台进行编程以通过执行权利要求1-6的任一项中的步骤而工作的单元。

15.一种用于具有多个节点的服务器群集中的计算机程序产品，所述服务器群集在客户端-服务器计算架构中实现服务器层，以提供群集恢复，所述计算机程序产品包括：

一个或多个数据存储介质；

记录在所述数据存储介质上的、用于对数据处理平台进行编程以通过以下操作而工作的单元：

确定第一组N个有效节点，其各自运行包括群集管理层和群集应用层的软件栈，其中所述群集应用层有效地代表运行在所述客户端上的客户端应用层中的一个或多个客户端应用提供服务；

确定第二组M个备用节点，其各自运行包括群集管理层和群集应用层的软件栈，其中所述群集应用层不有效地代表客户端应用提供服务；

响应于有效节点成员关系改变，确定所述群集中的第一和第二区域，其中所述有效节点成员关系改变涉及由于有效节点出故障或者变得不可及或者由于涉及有效节点的维护操作而一个或多个有效节点离开或者被添加到所述第一组；

所述第二区域是故障容纳区域，其包括在所述成员关系改变涉及节点离开的情况下，参与所述成员关系改变的所有有效节点以及至多对应数目的所述备用节点；

在群集恢复或维护期间，通过以下操作在所述故障容纳区域中实现快速恢复/维护和高群集应用可用性：

将由所述故障容纳组中的任何离开节点提供的客户端应用服务故

障恢复到所述故障容纳组中至多对应数目的所述备用节点，以便在

所述故障容忍组和所述故障容纳组之间保持事务隔离；以及

在群集恢复或维护期间，通过以下操作在所述故障容忍区域中保持连续应用群集可用性：

利用基于请求/响应的群集恢复通信协议来监视所述故障容忍区

域中的节点成员关系完整性，并且移除不能提供节点响应的节点，

从而保证群集成员关系完整性；

通过独立于群集大小的绝对节点标识符以及保留故障容忍区域中的恢复前通信会话，保证所述故障容忍区域中的通信连续性；以及

实现并发协议范围界定，以将应用故障恢复和恢复协议限于所述故障容纳组的群集应用和群集管理层，并且将正常的事务应用协议限于所述故障容忍组的群集应用和群集管理层。