CN101207518B - 一种面向分布式资源节点的异步维护系统 - Google Patents

Abstract

本发明面向分布式资源节点的异步维护系统，该系统包括位于主服务器内的维护请求分析模块、维护任务决策模块和资源索引服务模块，位于分布式计算系统内的各自治域中的节点状态管理模块和维护序列服务模块，在每个自治域内均带有多个资源节点，在各资源节点内均设置有节点状态侦听模块。资源节点的维护过程是在保证其正确性前提下动态交错执行的。各个资源节点不会在同一时刻集中性地进行维护，既解决了网络拥塞及网络延时问题，同时也降低了因个别资源节点维护效率较低而造成的“木桶效应”。此外在本系统中，资源节点的维护是一个相对独立的过程。个别资源节点上出现的错误维护并不会对分布式计算系统的整体正常运行造成影响。当有新的资源节点加入到分布式计算系统中时，只需更新相应资源管理模块的信息即可，保证了扩展的便捷性。该系统保障了更高的维护效率、更强的容错性，并且更易于扩展。

Description

一种面向分布式资源节点的异步维护系统

技术领域

本发明属于分布式计算领域，具体涉及一种面向分布式资源节点的异步维护系统，该系统具有维护效率高和容错性强的特点。

背景技术

随着计算机网络技术的迅猛发展，越来越多的业务需要提供高质量并且不间断的服务。然而，在系统的运行过程中，系统的重配置工作及资源的维护与更新工作将是必不可少的。对于传统的服务来说，系统维护的过程将不可避免地引起服务质量的下降甚至于服务的中断。而当这个问题放到分布式系统环境之下，系统的异构性与网络延时等问题将使得这样的维护与更新工作更加难以实现高效的协调。另一方面，不正确的维护工作甚至有可能导致整个系统的不可用性。因此，如何在一个已经正常运行着的分布式系统上实现动态的管理维护机制，以最大限度地满足用户对于服务的需求，是分布式领域研究的重要内容。其中，如何通过改进现有的基础架构，提高架构自身的高可用性；再从系统结构的角度，保证关键应用能够尽快地完成对应服务请求是非常重要的。

在许多系统中比如加拿大平台公司的LSF集群管理软件或者美国SUN公司的Sun Grid Engine管理软件，都采用一种块同步的管理方式。在这种方式下，维护管理模块首先将更新组件的安装包和相关配置文件通过网络传送给各个远程资源节点，并发出系统维护命令。各个资源节点将在资源包下载完成之后进行组件更新工作。为了保证系统的正确性，只有当所有资源节点上的维护工作完成之后，整个系统才能恢复正常工作。此时，有些资源节点因其软硬件所限可能导致维护效率相对较低，而一旦如上所述等待所有的资源节点执行完所有的维护工作后再提供正常服务，应用系统对外的服务可用性将会受到很大影响。同时，网络的不稳定性和集中性的资源包下载所造成的网络拥塞也会增加系统的不确定性。

发明内容

本发明的目的在于针对上述分布式系统管理维护的特点及传统维护机制的缺陷，提供一种面向分布式资源节点的异步维护系统，该系统保障了更高的维护效率、更强的容错性，并且更易于扩展。

本发明面向分布式资源节点的异步维护系统，其特征在于：该系统包括位于主服务器内的维护请求分析模块、维护任务决策模块和资源索引服务模块，位于分布式计算系统内的各自治域中的节点状态管理模块和维护序列服务模块，在每个自治域内均带有多个资源节点，在各资源节点内均设置有节点状态侦听模块；

节点状态管理模块负责管理资源节点的状态信息，包括资源节点的当前状态和最终状态；

维护序列服务模块负责管理各资源节点的维护基本操作的有序集合，以队列的形式存储维护基本操作信息；

资源索引服务模块用于保存资源节点资源和服务资源的信息；

维护请求分析模块用于向资源索引服务模块发出查询请求，并根据查询所得到的目标资源节点所对应的维护序列，从维护序列服务模块中取出该维护序列，并分析用户请求以向维护序列中增加操作；

维护任务决策模块负责判断在待维护服务序列中是否存在当前被请求服务，如果该服务不在待维护服务序列中，维护任务决策模块将返回正常信号至节点状态侦听模块，如果该服务处于待维护序列中，则需要进行维护操作，将每个维护操作的基本参数封装成对象，并传递给执行线程完成在资源节点上的维护操作；

节点状态侦听模块用于对客户端请求进行监听，从监听到的请求中获取上下文信息，并根据信息中包含的目标服务名分析出请求的类型；如果该请求是对资源的维护请求，将该请求转发到维护请求分析模块进行处理，如果通过判断该请求是普通的服务请求，那么将该请求的信息转发到维护任务决策模块进行处理。

本发明中的异步维护系统提供了一种异步维护策略，以对分布式系统进行维护管理。通过节点状态管理模块、维护序列服务模块、节点状态侦听模块、维护请求分析模块、维护任务决策模块及资源索引服务模块之间的相互协调工作，本系统实现了对分布式系统的高效维护。与传统的同步维护方法不同的是，维护任务的决策与维护任务的实际实施并不是连续的过程。维护任务一旦被确定，将被记录于对应资源节点的维护序列服务模块上，同时节点状态管理模块上所储存的相应资源节点最终状态将递增，而当前状态并不发生变化。一旦有普通维护请求到来，同时被请求服务又处于待维护队列中，那么用户当前请求将被挂起，而服务的维护过程将立即启动。维护任务决策模块将根据维护序列服务模块上的信息，将资源节点从当前状态升级到被请求服务最后一次更新的状态。具体而言，本发明具有以下技术效果：

(1)维护的高效性：在本发明所采用的异步维护系统中，资源节点的维护过程是在保证其正确性前提下动态交错执行的。各个资源节点不会在同一时刻集中性地进行维护，既解决了网络拥塞及网络延时问题，同时也降低了因个别资源节点维护效率较低而造成的“木桶效应”。由于服务资源只有在被实际访问时才会启动维护过程，因此本发明的异步维护系统还可以有效解决服务资源很少被客户端访问却反复进行升级更新的问题，进一步保证了维护的高效性。

(2)良好的容错性：在本系统中，资源节点的维护是一个相对独立的过程。只要整个分布式计算系统上存在已经完成维护工作的资源节点，计算系统的正常工作便得以保证。也就是说，个别资源节点上出现的错误维护并不会对分布式计算系统的整体正常运行造成影响。

(3)易于扩展：当有新的资源节点加入到分布式计算系统中时，只需更新相应自治域内节点状态管理模块、维护序列服务模块和主服务器上的资源索引服务模块的信息即可，保证了扩展的便捷性。

附图说明

图1为本发明系统的总体结构示意图；

图2为节点状态管理模块及维护序列服务模块示意图；

图3为维护请求分析模块处理流程示意图；

图4为节点状态侦听模块处理流程示意图；

图5为维护任务决策模块处理流程示意图；

图6为资源状态回滚操作流程示意图。

具体实施方式

分布式资源节点是通过自身所包含的软件组件来对外提供一定应用功能的分布式对象，它是本发明提出的异步维护系统所维护的目标。如图1所示，本发明异步维护系统包括位于主服务器1的维护请求分析模块1.1、维护任务决策模块1.2和资源索引服务模块1.3，位于分布式计算系统内的各自治域2.1、2.2、...、2.n中的节点状态管理模块3.1、3.2、...、3.n和维护序列服务模块4.1、4.2、...、4.n，在每个自治域内均带有多个资源节点2.1.1、2.1.2、...、2.1.j，2.2.1、2.2.2、...、2.2.k，...，2.n.1、2.n.2、...、2.n.m，在各资源节点内均设置有节点状态侦听模块5，分别表示为节点状态侦听模块5.1.1、5.1.2、...、5.1.j，5.2.1、5.2.2、...、5.2.k，...，5.n.1、5.n.2、...、5.n.m。

为表述方便，下文中将资源节点2.1.1、2.1.2、...、2.1.j，2.2.1、2.2.2、...、2.2.k，...，2.n.1、2.n.2、...、2.n.m统称为资源节点2，将节点状态管理模块3.1、3.2、...、3.n统称为节点状态管理模块3，将维护序列服务模块4.1、4.2、...、4.n统称为维护序列服务模块4，将节点状态侦听模块5.1.1、5.1.2、...、5.1.j，5.2.1、5.2.2、...、5.2.k，...，5.n.1、5.n.2、...、5.n.m统称为节点状态侦听模块5。

本发明系统通过维护请求分析模块1.1、维护任务决策模块1.2、资源索引服务模块1.3、节点状态管理模块3、维护序列服务模块4以及节点状态侦听模块5协调工作实现对分布式资源节点的异步维护。整个分布式计算系统是由多个资源节点2共同组成并协调工作的，每个资源节点上都有各自的当前状态和最终状态。

存在于各自治域内的节点状态管理模块3和维护序列服务模块4用于对该自治域内所有资源节点的当前状态和最终状态进行管理，并记录资源节点维护的相关信息。

节点状态管理模块3负责管理资源节点的状态信息，包括资源节点的当前状态、最终状态。资源节点的当前状态和最终状态都对应着资源节点维护序列中的某一序列位置。

维护序列服务模块4负责管理资源节点的维护序列，即各资源节点的维护基本操作的有序集合，它以队列的形式存储维护基本操作信息。每一个分布式计算系统中的资源节点2都对应着一个维护序列。

如图2所示，整个序列上的操作由底至上包括已完成操作，当前执行操作和待执行操作三类。维护序列按照操作提交的时间顺序存储着相应资源节点上的维护操作，以保证实际的维护过程严格按照序列中的顺序执行。当前状态指的是当前已完成维护操作所对应的资源节点状态，而最终状态代表的是所有待执行操作均已完成之后的状态。如表1所示，每执行完维护序列中的一个操作，资源节点的当前状态值便会递增。而每向维护序列中增加一个操作，则资源节点的最终状态值递增。

系统事件	资源节点当前状态变化	资源节点最终状态变化
			一个维护请求提交	不变	向前递增一个状态
一个维护操作执行	向前递增一个状态	不变

表1

资源索引服务模块1.3保存着资源节点资源的相关信息和服务资源的相关信息，其具体内容如表2所示。

资源对象	资源索引服务模块1.3保存的资源信息
		资源节点资源	资源节点ID、资源节点IP地址、端口号、对应维护序列
服务资源	服务ID、服务名称、服务对应包名、服务对应类名、服务当前版本

表2

维护请求分析模块1.1用于接收和处理用户发出的维护请求。由于采用了异步方式来进行资源节点的维护与管理，因此资源节点并不会因为当前维护请求而进行实时升级，而是将维护任务加入到对应的维护序列中。

如图3所示，维护请求分析模块1.1的处理流程为：用户通过维护请求提交接口完成维护任务的提交。一个维护任务是一组维护信息的集合，它包括：目标资源节点ID、待维护的目标服务ID以及操作类型。其中目标资源节点ID、待维护的目标服务ID分别是目标资源节点和目标服务的唯一标识符，而操作类型包括部署、反部署、重部署和备份等。系统中的维护请求分析模块1.1在接收一组维护请求信息后，将向资源索引服务模块1.3发出查询请求，以获得目标服务和目标资源节点的具体内容。如表2所示，目标服务的信息包括服务ID、服务名称、服务对应包名、服务对应类名以及服务当前版本，而目标资源节点的信息包括资源节点ID、资源节点IP地址、端口号和对应维护序列。

维护请求分析模块1.1根据查询资源索引服务模块1.3所得到的目标资源节点对应维护序列，从维护序列服务模块4中取出该维护序列，并分析用户请求以向维护序列中增加操作。如图3所示，维护请求分析模块1.1并非简单地将用户请求加入队列中，而是根据服务依赖性和拓扑排序等相关因素将用户请求分解成基本操作，再将其加入维护序列。如果不存在服务依赖关系，那么该维护操作即为基本操作。若存在服务依赖关系，那么所有被依赖的服务都需要进行维护，即它们都是基本操作。在基本操作被加入到维护序列之后，并不会被立即执行，也就是所说的异步执行。维护任务决策模块1.2将决定何时触发维护操作。

节点状态侦听模块5被布置在各个资源节点上，用于对客户端请求进行监听。如图4所示，节点状态侦听模块5的处理流程为：当请求到来时，节点状态侦听模块5获取请求的上下文信息，并根据信息中包含的目标服务名分析出请求的类型。如果该请求是对资源的维护请求，那么请求被转发到维护请求分析模块1.1进行处理。而如果通过判断其是普通的服务请求，那么该请求的信息被转发到维护任务决策模块1.2进行处理。

维护任务决策模块1.2负责判断是否应当触发资源的维护过程，在需要触发时，将每个维护操作的基本参数封装成对象，并传递给执行线程完成在资源节点上的维护操作。其具体过程如下：

由节点状态侦听模块5转发给维护任务决策模块1.2的内容包括被访问的资源节点ID和被请求的服务ID。如图5所示，维护任务决策模块1.2首先通过服务ID和资源节点ID匹配资源索引服务模块1.3中的服务资源和资源节点资源的对应信息，获得资源对应的维护序列，再访问维护序列服务模块4取出该序列。接下来，维护任务决策模块1.2从节点状态管理模块3中获得资源节点的当前状态和最终状态。通过将维护序列和资源节点状态信息进行对比，维护任务决策模块1.2得到待维护服务的序列。

维护任务决策模块1.2从首个待维护服务开始，逐个与被请求的服务进行比对，判断在待维护服务序列中是否存在当前被请求服务。如果该服务并不在待维护服务序列中，那么维护任务决策模块1.2将返回正常信号至节点状态侦听模块5。而如果该服务处于待维护序列中，则意味着当前被访问的服务在该资源节点上并非最新版本，需要进行维护操作。此时，维护任务决策模块1.2返回挂起信号至节点状态侦听模块5，将当前服务请求挂起并触发服务的维护过程，同时修改当前资源状态为不可用。

在资源维护的过程中，所有访问该资源的客户端请求都将被加入到挂起队列以等待维护的完成。维护任务决策模块1.2将每个维护操作的基本参数，包括待维护资源节点ID、待维护资源节点IP地址、待维护资源节点端口号、操作类型和服务资源包URL封装成对象。这些参数均通过之前对资源索引服务模块1.3的访问获得。维护任务决策模块1.2将封装的维护参数传递给执行线程完成在资源节点上的维护操作。整个维护过程从资源节点当前状态开始进行，一直到当前所请求服务被最后一次更新的状态为止，以保证当前请求所访问的一定是服务的最新版本。每完成一个维护操作，资源节点的当前状态将递增，同时维护过程会严格按照维护序列所定义的顺序进行。

在所有维护操作执行完成后，维护任务决策模块1.2返回挂起解除信号至节点状态侦听模块5，以解除对所有维护期请求的挂起，同时将资源状态修改为可用。随后到来访问该资源的请求将继续受到节点状态侦听模块5的监听。

一旦因网络故障、资源节点故障等软硬件故障导致维护失败，系统管理员可以调用回滚接口将资源恢复到故障前状态。管理员通过维护任务决策模块1.2提供的接口发出回滚指令。接收到回滚指令后，维护任务决策模块1.2访问维护序列服务模块4，获取维护序列信息，以及当前发生错误的维护操作的开始位置和结束位置。如图6所示，资源状态回滚是按照资源维护序列反向进行逆操作，即从故障状态开始，依次向前进行。其中部署对应的逆操作为反部署，反部署对应的逆操作为部署，重部署对应的逆操作为旧版本部署，备份对应的逆操作为删除备份。维护任务决策模块1.2按照逆序发出各操作的逆维护操作执行指令。回滚操作结束之后，资源节点恢复到维护任务开始之前的状态，恢复系统的正常运行。

Claims (3)

1.一种面向分布式资源节点的异步维护系统，其特征在于：该系统包括位于主服务器(1)内的维护请求分析模块(1.1)、维护任务决策模块(1.2)和资源索引服务模块(1.3)，位于分布式计算系统内的各自治域中的节点状态管理模块(3)和维护序列服务模块(4)，在每个自治域内均带有多个资源节点(2)，在各资源节点内均设置有节点状态侦听模块(5)；

节点状态管理模块(3)负责管理资源节点的状态信息，包括资源节点的当前状态和最终状态；

维护序列服务模块(4)负责管理各资源节点的维护基本操作的有序集合，以队列的形式存储维护基本操作信息；

资源索引服务模块(1.3)用于保存资源节点资源和服务资源的信息；

维护请求分析模块(1.1)用于向资源索引服务模块(1.3)发出查询请求，并根据查询所得到的目标资源节点所对应的维护序列，从维护序列服务模块(4)中取出该维护序列，并分析用户请求以向维护序列中增加操作；

维护任务决策模块(1.2)负责判断在待维护服务序列中是否存在当前被请求服务，如果该服务不在待维护服务序列中，维护任务决策模块(1.2)将返回正常信号至节点状态侦听模块(5)，如果该服务处于待维护序列中，则需要进行维护操作，将每个维护操作的基本参数封装成对象，并传递给执行线程完成在资源节点上的维护操作；

节点状态侦听模块(5)用于对客户端请求进行监听，从监听到的请求中获取上下文信息，并根据信息中包含的目标服务名分析出请求的类型；如果该请求是对资源的维护请求，将该请求转发到维护请求分析模块(1.1)进行处理，如果通过判断该请求是普通的服务请求，那么将该请求的信息转发到维护任务决策模块(1.2)进行处理。

2.根据权利要求1所述的异步维护系统，其特征在于：维护任务决策模块(1.2)按照下述过程进行处理：

①接收节点状态侦听模块(5)转发的请求信息，包括被访问的资源节点ID和被请求的服务ID；

②将上述请求信息与资源索引服务模块(1.3)中的资源信息进行匹配，得到维护序列的标识符，从维护序列服务模块(4)取出所对应的序列；从节点状态管理模块(3)中获得该访问的资源节点的当前状态和最终状态，通过将维护序列和资源节点状态信息进行对比，得到待维护服务的序列；

③判断在待维护服务序列中是否存在当前被请求服务；如果存在，返回挂起信号至节点状态侦听模块(5)，将当前服务请求挂起并触发服务的维护过程，同时修改当前资源状态为不可用，进入步骤④；否则，返回正常信号至节点状态侦听模块(5)，转入步骤⑦；

④将包括待维护资源节点ID、待维护资源节点IP地址、待维护资源节点端口号、操作类型和服务资源包URL在内的维护操作的基本参数封装成对象；

⑤将封装的维护参数传递给执行线程，完成在资源节点上的维护操作；

⑥返回挂起解除信号至节点状态侦听模块(5)，同时将资源状态修改为可用；

⑦结束。

3.根据权利要求1或2所述的异步维护系统，其特征在于：维护任务决策模块(1.2)具有维护操作回滚的功能，当维护失败时，维护任务决策模块(1.2)根据管理员发出的回滚指令访问维护序列服务模块(4)，获取维护序列信息，以及当前发生错误的维护操作的开始位置和结束位置，并按照资源维护序列反向进行逆操作。

Images