大型机群系统的集中控制方法

摘要

一种大型机群系统的集中控制方法，在机群系统中，使最先加入机群的候选控制节点成为主节点与辅助主节点，主节点搜集并维护机群系统内所有节点的全局状态信息；辅助主节点对主节点中的全局信息进行实时备份，并在主节点出现故障或关闭时接替主节点的工作。本发明通过基于集中式控制策略的机群系统控制模块的冗余设计模型，降低了机群控制算法的复杂度，解决了困扰集中式控制策略的单一故障点问题；同时，解决了冗余设计中的数据一致性问题，提高了系统的可靠性与运行性能。

说明书

技术领域：

本发明涉及一种大型机群系统的集中控制方法，尤其是一种基于集中式控制策略的机群系统控制模块的冗余控制方法，属于计算机及网络技术领域。

背景技术：

商务应用的发展，极大的推动了商务机群技术的进步。与科学计算应用相比，商务应用具有自身的一些显著特点：任务的粒度小，但请求服务的数量大；对系统处理能力的需求是不断增强的；商务应用往往是一些关键领域的关键应用，例如：银行业、电信业，需要机群系统能够提供高质量与高可靠性的服务。机群系统需具有的良好特性才能很好的满足商务应用要求，即：机群为实现全局系统内的高可用与负载均衡提供坚实的物质基础，同时机群还要具有良好的可扩展性。

要为用户提供高可用的服务，需要解决诸如资源的管理与监控、任务的调度、竞争的仲裁等关键问题，因此需要有专门的控制模块来完成以上工作。

机群系统是一种典型的分布式计算环境，在为其设计控制模块时，存在着两种不同类型的控制策略可供选择：集中式控制策略与分布式控制策略。

在分布式控制策略中，所有节点都参与全局的控制决策过程，各个节点都能访问决策支持信息，即：机群状态信息。为了避免单一故障点，分布式控制算法对状态信息进行全冗余，即各个节点保存一份状态信息的拷贝，以便提供本地访问；在每一次的状态更新中，对应当前机群中的节点数目N，产生N条消息，每条消息驱动一个节点执行一个更新操作。

由此可见，分布式控制策略的一个潜在的优势在于它的高可靠性，但是其设计与实现相对复杂；而且，对每一个节点状态信息的全冗余造成了主机资源的浪费；每一次状态信息更新至少需要产生N条消息(N是当前加入到机群中的节点数目)，特别是当初始构建一个机群时，状态信息的更新触发事件与节点数N成线性关系，整个机群所产生的网络消息数目的峰值与(N*N)大体成正比，占用了较多的网络资源。

集中式控制策略的优点主要是节点间消息传递简单且通信开销较小，而且，在任意时刻只需最少的节点参与全局的控制。但是，集中式控制策略容易在分布式系统内形成单一故障点，这也是它最大的缺点。

在传统的采用集中式控制策略的分布式系统实施案例中，为了避免单一故障点系统多采用主机后备的冗余机制。主机后备方法的基本思想是：在任一时刻都有一台主机作为主服务器，它完成所有的工作，若这个主服务器失效了，后备的服务器将承担其任务。在主机后备方法中客户只与主服务器进行交互，为了实现主服务器与备份服务器之间的数据一致性，通常由主服务器负责触发备份服务器中的数据更新操作。主服务器与备份服务器执行的是两套完全不同的算法流程。

参见图1，其为主机后备方法中的一个写操作协议的简单描述。客户的请求使主服务器修改内部的状态信息，在大型系统中这种修改操作可能是非常复杂的；随后主服务器执行第三步动作，触发备份服务器的更新操作，在第四步如果采用粗粒度的更新策略，即按信息类型进行大数据块的更新，势必造成网络资源的浪费；如果采用细粒度的更新策略，又将极大的增加通信协议以及更新操作的复杂度。问题的关键是：主机后备机制中的通信模型增加了系统控制模块设计实施的难度。同时，在主机后备机制中，主服务器高可用性的维护一般依赖于(主/备份)服务器自身来完成，客户机不参与维护，因此，系统的自适应性较差。

发明内容

本发明的主要目的是：针对现有技术的不足，提出一种通用的大型机群系统的集中控制方法，该方法基于集中式控制策略的机群系统控制模块的冗余设计模型，试图降低机群控制算法的复杂度，解决困扰集中式控制策略的单一故障点问题。

本发明的另一目的是：针对现有技术的不足，提出一种通用的大型机群系统的集中控制方法，试图解决冗余设计中的数据一致性问题，提高系统的可靠性与运行性能。

本发明的目的是这样实现的：

一种大型机群系统的集中控制方法，在机群系统中，使最先加入机群的候选控制节点成为主节点与辅助主节点，主节点搜集并维护机群系统内所有节点的全局状态信息；辅助主节点对主节点中的全局信息进行实时备份，并在主节点出现故障或关闭时接替主节点的工作。

所述的控制节点中设有用于维护全局状态信息一致性的控制模块，该控制节点由管理员通过配置控制模块而成为候选控制节点。

所述的机群系统中还设有普通节点，该普通节点不设控制模块，且该普通节点与主节点通信，驱动主节点对全局状态信息进行维护。该普通节点还与辅助主节点通信，驱动辅助主节点对主节点中的全局状态信息进行冗余备份。

主节点与辅助主节点同时运行，主节点与辅助主节点之间进行周期性或由事件驱动的数据同步传输，用于对主节点中的全局状态信息进行冗余备份。

上述的主节点和辅助主节点的产生具体包括：

步骤100：节点加入机群；

步骤101：测试控制节点状态，判断主节点或辅助主节点是否加入，若加入，执行步骤106；

步骤102：判断该节点是否为侯选控制节点，若不是，退出；

步骤103：获取控制权；

步骤104：判断是否获取成功，若不成功，等待一段时间后重新加入机群；

步骤105：启动机群控制部件，即启动主节点或辅助节点；

步骤106：进行以下的工作流程。

当机群系统只有一个候选控制节点加入时，主节点与辅助主节点运行在同一节点上；当机群系统中多于一个加入的候选控制节点时，则将辅助主节点迁移到主节点以外的候选控制节点上，即在新的候选控制节点上启动控制模块，并修改相应的辅助主节点运行位置信息；具体的操作如下：

步骤200：节点加入机群；

步骤201：判断主节点与辅助主节点是否在同一节点上；若没在同一节点上，结束；

步骤202：判断新节点是否为侯选节点，若不是，结束；

步骤203：设置新节点为辅助主节点；

步骤204：判断设置是否成功，若设置不成功，结束；

步骤205：主节点取消自己的辅助主节点设置角；

步骤206：结束。

普通节点与控制节点之间会进行通信，普通节点首先检测主节点与辅助主节点的存活状态，如果主节点或辅助主节点发生故障，则进行相应的故障处理。

当主节点出现故障时，故障发现节点通知辅助主节点，辅助主节点接替该故障主节点成为新的主节点；然后，新主节点选择当前系统中可用的候选控制节点，并使其成为新的辅助主节点；如果机群系统中没有可用的候选控制节点，则新主节点保留自己的辅助主节点角色。

当辅助主节点出现故障时，故障发现节点通知主节点，由主节点重新选择当前系统中可用的候选控制节点作为辅助主节点；如果系统中没有可用的候选控制节点，主节点使自己成为辅助主节点；且在该辅助主节点迁移完成前，主节点都不再继续接收新的数据更新任务。

如果主节点与辅助主节点同时出现故障，故障发现节点将自身设为主节点与辅助主节点，并重新构建机群全局状态信息。

上述的全局状态信息至少包括：节点状态信息、服务状态信息、节点资源负载信息；该全局状态信息通过普通节点的汇报驱动控制节点进行修改，或控制节点自主进行修改。普通节点通过模拟组播通信的方式将消息分别发送给主节点与辅助主节点，主节点与辅助主节点各自维护本地的全局状态信息

上述的普通节点与控制节点之间进行的通信至少包括：

步骤300：与主节点建立连接；与辅助主节点建立连接；

步骤301：向主节点发送数据，并接收主节点的应答；向辅助主节点发送数据，并接收辅助主节点的应答；

步骤302：将主节点的应答与辅助主节点的应答进行比较，如果发现主节点与辅助主节点所发送的应答数据不一致，则触发控制节点之间的数据同步操作；执行步骤304；

步骤303：向主节点发送数据；向辅助主节点发送数据；

步骤304：断开与主节点连接，断开与辅助主节点连接。

其中，步骤300具体包括：

步骤3001：主节点发送“主节点与辅助主节点是否相同”的应答；

步骤3002：普通节点接收该应答；

步骤3003：如果主节点与辅助主节点不是同一节点，执行步骤3005；

步骤3004：设置全局标志；

步骤3005：与辅助主节点建立连接。

上述的步骤3004之后还进一步包括：读取该全局标志，如果发现主节点与辅助主节点相同，则放弃与辅助主节点的操作。

本发明通过基于集中式控制策略的机群系统控制模块的冗余设计模型，降低了机群控制算法的复杂度，解决了困扰集中式控制策略的单一故障点问题；同时，解决了冗余设计中的数据一致性问题，提高了系统的可靠性与运行性能。

附图说明

图1为现有技术中写操作简单主备份协议示意图；

图2为本发明机群控制模型示意图；

图3为本发明机群系统中产生主节点和辅助主节点的流程图；

图4为本发明机群系统中主节点和辅助主节点分离的流程图；

图5为本发明控制节点故障检测与处理流程图；

图6为本发明外部事件通信模型之一；

图7为本发明外部事件通信模型之二

图8为本发明内部事件通信模型；

图9为本发明建立连接原语流程图。

具体实施方式：

以下参照具体实施例和附图对本技术方案进行详细说明。

在机群系统中，有的节点上安装有控制模块，且被管理员配置为候选控制节点，称为候选控制节点，有的节点没有安装控制模块，称为普通节点。使某两个候选控制节点成为主节点和辅助主节点，并且同时运行。主节点是真正的控制节点，在主节点上搜集了机群内所有节点的全局状态信息。但是，如果只有主节点保存这些信息，当其发生故障时，全局信息就会丢失，进而导致系统将无法正常运行，因此，辅助主节点对主节点中的全局信息进行实时的备份，并在主节点出现故障时能够接管主节点的工作。在图1中，数据传输路径①保证了主节点对全局状态信息的采集。辅助主节点备份主节点的全局信息的方法一般来说有两种，一种方法是：使所有节点在向主节点传输数据的同时也向辅助主节点传输数据，即通过图1中的数据传输路径②；另一种方法是：在主节点与辅助主节点之间进行数据同步传输，即通过图1中的数据传输路径③，这种同步传输可以是周期性的，也可以是由事件驱动的。

在机群系统中，普通节点不具有维护全局状态信息的能力，为了保证使系统中尽可能快的拥有控制节点，将使最先加入机群的候选控制节点成为主节点与辅助主节点，即尽快的启动控制模块，如果非候选控制节点首先启动并请求加入，则必须退出加入过程并等待重新加入。

主节点与辅助主节点应是最先加入机群的节点，由于在启动控制模块时可能会出现竞争的状态，即多个节点同时想成为主节点与辅助主节点，因此必须对启动控制模块的操作实现“互斥”，产生主节点和辅助主节点的流程图如图3：

步骤100：节点加入机群；

步骤101：测试控制节点状态；

步骤102：判断主节点和辅助主节点是否加入，若加入，执行步骤107；若没有加入，则转到步骤103；

步骤103：判断是否是侯选控制节点，若不是，退出；若是，执行步骤104；

步骤104：获取控制权；

步骤105：判断是否获取成功，若不成功，等待一段时间后重新加入机群；若成功，执行步骤106；

步骤106：启动机群控制部件，即启动主节点或辅助节点。

步骤107：进行以下的工作流程。

在节点开始加入时，主节点与辅助主节点运行在同一节点上，随着更多的候选控制节点加入机群，需要将辅助主节点迁移到其它候选控制节点上，所谓将辅助主节点迁移就是在新的候选控制节点上启动控制模块，并修改相关的辅助主节点运行位置信息，如图4。

步骤200：节点加入机群；

步骤201：判断主节点与辅助主节点是否在同一节点上；若在同一节点上，执行步骤202；若没在同一节点上，结束；

步骤203：判断新节点是否为侯选节点，若是，执行步骤204；或不是，结束；

步骤204：设置新节点为辅助主节点；

步骤205：判断设置是否成功，若成功，执行步骤206；若不成功，结束；

步骤206：取消自己的辅助主节点角色；

步骤207：结束。

在系统运行时，为保证尽可能快的发现控制节点的故障，并按照一定规则产生出新的控制节点来接管故障节点，本实施例采用“事件驱动”型故障检查机制，即：机群系统在运行过程中，普通节点与控制节点之间会进行频繁的通信，有些操作是周期性执行的，如节点负载信息的汇报；有些操作是突法性执行的，如故障节点的汇报等。在与控制节点的通信过程中，普通节点首先要做的就是检测主节点与辅助主节点的存活状态，因此，如果主节点或辅助主节点发生故障，系统将很快会发现并进行相应处理。

当主节点出现故障时，故障发现节点通知辅助主节点使其接管成为新的主节点。然后，新主节点选择当前系统中可用的候选控制节点使其成为新的辅助主结点。如果系统中没有可用的候选控制节点，则新主节点保留自己的辅助主节点角色；当辅助主节点出现故障时，故障发现节点通知主节点，由主节点重新选择其它的节点作为辅助主节点，如果系统中没有可用的候选控制节点，主节点使自己成为辅助主节点；如果主节点与辅助主节点同时出现故障，故障发现节点应试图将自身设为主节点与辅助主节点，并重新构建机群全局状态信息。

其流程如图5所示：

步骤300：检测主节点与辅助主节点的存活状态；

步骤301：若发生故障，则检测故障类型；

步骤302：若是辅助主节点故障，通知主节点，执行步骤3030；若是主节点故障，通知辅助主节点，执行步骤3040；若是主节点与辅助主节点均发生故障，执行步骤306；

步骤3030：选择侯选控制节点作辅助主节点；

步骤3031：判断是否成功，若成功，执行步骤306；若不成功，主节点接管辅助主节点角色。

步骤3040：辅助主节点将自己设为主节点；

步骤3041：选择候选取控制节点为辅助主节点；

步骤3042：判断是否成功，若成功，执行步骤3043；若不成功，执行步骤3044；

步骤3043：取消辅助主节点角色；

步骤3044：保留辅助主节点角色。

步骤305：故障发现节点将自身设为主节点与辅助主节点，执行步骤203；

步骤306：结束。

在本发明中，全局状态信息是众多信息的集合体，它包括：节点状态信息，服务状态信息、节点资源负载信息等。全局状态信息是一种动态信息，在集中式控制策略中，所有节点都将本地最新的全局状态信息向控制节点进行汇报，控制节点将信息进行汇总、整理，并以此作为仲裁决策的依据。因此，如何维护好全局状态信息是机群控制系统设计的最为关键的问题之一。

由于采用多控制节点的冗余结构，全局状态信息在控制节点间进行冗余备份，因此控制模块必须维护好冗余数据的一致性。在系统运行过程中，全局状态信息的变化可能来自于两个方面：普通节点的汇报驱动控制节点修改全局状态信息(外部事件)；控制节点自主的修改全局状态信息(内部事件)。对于不同类型的事件，系统应采用相应的策略来维护数据的一致性。

对于外部事件，通过模拟组播通信的方式，使普通节点将消息分别发送给主节点与辅助主节点。如图6，主节点1与辅助主节点2各自维护本地的全局状态信息，避免彼此之间的数据同步操作。为了实现多主节点的访问透明性，如图7，可以将数据通信操作封装为若干通信原语，以提供原子性操作。

通信原语功能描述(以TCP通信协议为例)：

<建立连接>：与主节点建立连接；与辅助主节点建立连接。

<发送并接收数据>：向主节点发送数据，并接收应答；向辅助主节点发送数据，并接收应答；将主节点应答与辅助主节点应答进行比较，此功能相当于实现了对数据不一致的检测。如果发现主节点1与辅助主节点2所发送的应答数据不一致，应触发控制节点之间的数据同步操作。

<发送数据>：向主节点发送数据；向辅助主节点发送数据。

<断开连接>：断开与主节点连接，断开与辅助主节点连接。

普通节点向主节点与辅助主节点分别通信，当同一个控制节点接收到两个相同(重复)的数据更新操作请求时，会先后引发两次相同的更新操作。如果操作是跌加型的，例如对某个全局变量的累加，显然就会出现数据错误，如果操作中互斥的申请共享了资源，还可能会造成控制节点的死锁，产生数据错误。因此，必须避免同一控制节点接收到重复的数据更新操作请求。

为此，需要对上面提到的通信原语加以修改：

建立连接的过程如图9所示：

步骤600：开始；

步骤601：主节点发送“主节点与辅助主节点是否相同”的应答；

步骤602：接收应答；

步骤603：判断主节点与辅助主节点是否是同一节点，若是，执行步骤604；若不是，执行步骤605；

步骤604：设置全局标志；

步骤605：与辅助主节点建立连接；

步骤606：结束。

其它原语：读取全局标志，如果发现主节点与辅助主节点相同，放弃相应与辅助主节点的操作。

保证数据一致性的最好的方法就是使所有异地数据更新操作步调一致。对于外部事件，步调一致的数据更新是容易保证的，因为异地数据更新操作具有同一个发源地。而内部事件是由控制模块自身的控制逻辑(通常由一些周期性的检查任务)所引发的，要保证这些不同节点间的数据更新操作步调一致就很困难了，因为多个控制节点之间并没有一个统一的全局时钟。

在本实施例中，对于内部事件，为了实现步调一致的数据更新操作，应在主节点与辅助主节点之间加入同步操作，如图8。我们之所以可以加入同步操作是因为：在相同的数据环境下，如果一个控制节点产生了某个内部事件，另一个控制节点也必然会产生相同的内部事件。

当辅助主节点迁移时，也有可能造成数据的不一致。因此，只要主节点(辅助主节点)已决定将要进行辅助主节点的迁移——不管该操作是立刻执行还是排队等待，直到迁移完成前，主节点都应不再继续接收新的数据更新任务。

除此之外，控制模块还应对不同节点的重复性消息加以判断。由于普通节点向控制节点报告状态信息具有自主性，所以可能会出现多个节点就同一故障问题(例如，辅助主节点故障)向控制节点进行汇报的情况。系统必须对消息是否重复进行判断，这与系统所采用的消息处理模式有关。在机群内部存在着明显的CLIENT/SERVER关系，消息报告者是CLIENT，消息处理者是SERVER。从程序架构分析，控制模块实质上是CLIENT/SERVER结构中的SERVER程序。为了提高消息的处理能力，控制模块通常采用并发服务器模型(多进程)，消息的处理缺乏相互协调。系统必须避免对相同消息的多次处理，因此应判断消息的有效性(是否已过时)，如果发现接收到重复消息，应该丢弃。

最后应说明的是：以上实施例仅用以说明本发明而非限制，尽管参照较佳实施例对本发明进行了详细说明，本领域的普通技术人员应当理解，可以对本发明进行修改或者等同替换，而不脱离本发明的精神和范围，其均应涵盖在本发明的权利要求范围当中。