CN103684941B - 基于仲裁服务器的集群裂脑预防方法和装置 - Google Patents

Abstract

本发明公开一种基于仲裁服务器的高可用集群裂脑预防的方法和装置，属于计算机集群技术领域的高可用集群裂脑预防技术。为解决在集群心跳网络中断时，无法准确判别其他节点及其运行服务的状态，而出现无法接管服务或服务在两个节点同时运行问题。本发明实施例提供的方案包括：在心跳网络中断时，未运行服务的集群节点只有通过仲裁服务器获得相应服务锁，才可以进行服务接管，从而避免裂脑问题；服务停止后，仲裁服务器回收服务锁并允许其他集群节点重新抢占它；在多个节点同时抢占服务锁的过程中，只有一个节点抢占成功并能启动服务，防止了裂脑的发生。

Description

基于仲裁服务器的集群裂脑预防方法和装置

技术领域

本发明属于计算机集群技术领域，适用于高可用性集群(High-availabilityCluster)，尤其涉及高可用集群裂脑预防技术领域。

背景技术

随着通信网络技术的飞速发展，电信、金融、电子政务等关键领域对服务器可用性的要求越来越高。高可用(High Availability，HA)集群技术可以有效减少业务***因软件、硬件故障造成的服务停止时间。

当前高可用集群***主要通过网络或串口线等链路作为集群节点间通信的私有心跳网络，负责交换同步节点间的信息，监测集群中各个节点的运行情况。当服务运行节点故障，备份节点不能在一定时间内收到服务运行节点的心跳信息，则认为服务运行节点发生了故障并进行服务接管。但是当所有心跳链路发生故障，可能会导致服务运行节点和备份节点同时启动业务，造成集群裂脑(Split-Brain)和数据损坏。

为了保障用户的业务可持续性及数据安全性，防止集群裂脑是必不可少的，目前通用的做法是将故障节点Fencing重启或将通过SCSI3保留技术对共享存储进行Fencing隔离。但发明人发现这些方法存在局限性，在实际环境中，经常不具备Fencing的硬件条件，而且备份节点上同样运行着其他重要的业务，客户不允许操作***重启或共享存储被隔离。另外，基于共享磁阵的磁盘锁技术虽然能在局域网、带有共享磁阵的场合部分解决集群裂脑问题，但同样存在诸多局限性，比如需要重新划分共享磁阵分区、不支持无磁阵环境、不支持虚拟机环境、不支持广域网异地集群等。

发明内容

本发明实例目的在于提供一种基于仲裁服务器的集群裂脑预防方法和装置，克服现有技术的不足，在不需要将服务器节点Fencing重启或共享存储Fencing隔离的情况下，仍然能够在集群心跳网络中断或异常时，防止集群裂脑发生和数据损坏。并且克服磁阵仲裁盘必须配置共享磁阵，必须对磁阵进行重新分区，只能用于局域网的局限性，不支持虚拟机环境等局限性，适用于无共享磁阵、不需要对磁阵重新分区、虚拟机集群、广域网异地集群等高可用集群环境。

本发明通过如下方法和装置实现：

当节点或心跳网络故障时，服务未运行子集群必须先向仲裁服务器申请并获得服务锁，才能进行服务的接管，如果因任何原因，服务未运行子集群不能获得服务锁，则不能执行服务启动动作。从而避免两个节点同时启动服务，防止集群裂脑的发生。

由于原服务运行节点心跳线中断到停止服务需要一个t_giveup时间，所以在这个时间内，尝试接管服务的子集群会持续发送申请服务锁请求，直到取得服务锁。

服务运行子集群定期发送服务锁刷新消息到仲裁服务器，仲裁服务器更新当前服务锁时间戳，维护服务锁状态不变。此时，非服务运行子集群的节点无法获得相应服务锁，不能接管服务。

如果因为网络故障等原因，在t_timeout时间内仲裁服务器不能收到任何服务锁刷新信息，则认为服务运行子集群已死机或变成孤立子集群，并把服务锁的状态置为unknown状态。此后，为保证原服务运行节点有充分的停止服务时间，仲裁服务器会等待t_giveup时间才把服务锁状态置为unlocked，确认服务已经停止，并允许其他节点抢占服务锁，避免备机接管服务时因为原节点服务未完全停止而造成的短暂裂脑问题。

此时，服务运行子集群与仲裁服务器失去连接并变成孤立子集群。为保证服务的运行持续性，分两种情况处理：(1)服务运行子集群节点数量大于原集群节点数量的1/2时，继续对外提供服务，避免因为仲裁服务器的链接故障影响到服务的可用性；(2)服务运行子集群的节点数量小于等于原集群节点数量的1/2时，执行停止服务操作并释放服务锁。此时服务运行子集群的备份节点不予接管服务，在t_giveup时间内服务不能正常停止时，服务运行节点要执行重启***动作，以方便其他子集群接管。当服务运行子集群节点数＞1/2时，非服务运行子集群肯定小于1/2，所以此时非服务运行子集群不会尝试申请服务锁并接管服务，不存在集群裂脑风险。

为提高服务可用性、最大化服务持续运行能力，也可以通过选项不执行1/2节点数的算法，此时非服务运行子集群不管是否＞1/2，只要节点状态变化或心跳故障，都会执行抢锁操作，并尝试接管服务。这种方式提高服务可持续性，但降低了数据安全性，增加集群裂脑风险。

当服务故障时，集群会首先执行服务停止操作，并向仲裁服务器主动释放服务锁。并必须在服务最大停止时间t_giveup内停止完成，t_giveup时间内服务未停止，则需要执行服务器立即重启操作，确保仲裁服务器将服务锁置为unlocked，备份节点接管服务前，服务已经停止完成。

本发明另一方面，提供一种基于仲裁服务器的裂脑预防装置，其特征包括：

集群服务器端代理模块。服务运行子集群选举通信节点定期向仲裁服务器发送刷新服务锁消息，刷新服务锁消息主要包含服务名称，刷新服务锁节点，刷新时间戳等；服务未运行子集群选举通信节点在尝试接管服务前，向仲裁服务器发送服务锁申请消息，申请服务锁消息内容包含服务名，抢锁节点名等。

仲裁服务器模块。当服务锁处于unlocked状态时，仲裁服务器将服务锁授予第一个进行抢锁申请的节点，然后把服务锁置为locked状态，更新占锁节点名称；当服务锁处于locked状态时，对特定服务锁进行持续时间戳刷新，对来自服务未运行子集群的备份节点的服务锁申请返回抢锁失败消息；仲裁服务器维护各个服务锁的信息，包括：服务锁名称、服务锁的状态、服务锁刷新时间戳、服务所在的节点。

本发明基于Client/Server网络架构实现了一种服务锁仲裁装置，基于服务锁占锁节点的唯一性，只有取得服务锁的节点才能启动服务，来避免服务在2个节点同时启动的风险，从而避免了集群裂脑的发生。和***重启Fencing或共享存储Fencing隔离技术相比，本发明基于服务锁的概念，能够支持主备服务器各自运行不同服务，提高服务器资源使用效率。本发明部署实施方便，不需要共享磁阵等设备，只要能够运行仲裁程序、集群各节点都可以连接访问的机器都可以配置成仲裁服务器。虚拟化环境、广域网的异地集群环境下，原来的Fencing技术和磁阵仲裁盘技术均不适用，而本发明在上述环境下均能起到较好仲裁作用，对虚拟机集群、异地集群提供服务一致性和数据安全保障。另外，本发明同时适用于双节点、多节点等高可用集群。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将用实施例或现有技术描述中所需要使用的附图作简单地介绍。

图1为本发明提供的服务锁结构图；

图2a为本发明提供的刷新服务锁内容；

图2b为本发明提供的申请服务锁内容；

图3为本发明非服务运行子集群申请服务锁流程图；

图4为本发明服务运行子集群刷新服务锁流程图；

图5为本发明仲裁服务器接收到申请服务锁消息的处理流程图；

图6为本发明仲裁服务器接收到刷新服务锁消息的流程图；

图7为本发明仲裁服务器定期检测服务锁刷新时间戳的流程图；

图8为本发明提供的基于仲裁服务器的集群裂脑预防装置示意图；

具体实施方式

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

为了解决在集群心跳网络中断时，因不能有效判断其他节点及其运行服务状态而容易做出错误的策略，进而产生裂脑，破坏数据一致性的问题。本发明实施例提供了一种基于仲裁服务器，在尽量不需要将***重启或存储隔离的情况下，仍然有效地预防裂脑的方法和装置。

双节点配置仲裁服务器的集群为具有代表性的高可用的集群***，***有两台节点，服务器节点A和节点B，业务通过公有网络对外提供服务，节点间通过私有网络进行交换节点信息，监控节点上服务的运行状态。为保证心跳的稳健性，心跳网络一般由两条或以上的直连网线或串口线组成。仲裁服务器把服务锁分配给节点A，节点A启动服务成功后，节点A、B之间的心跳正常，集群处于正常状态，节点A、B都发送集群状态正常消息到仲裁服务器，仲裁服务器维护服务锁状况不变。

当在一个时间常量t_heartbeat后，节点A、B都没有收到对方的节点，则各自都认为心跳已中断，集群***成两个子集群，每个子集群只有一个节点。那么，服务运行节点A定期发送刷新服务锁消息到仲裁服务器刷新服务锁；节点B没有抢占到服务锁，也会定期发送申请服务锁消息到仲裁服务器，仲裁服务器接收到节点A、B的消息作出仲裁处理。仲裁服务器对集群中的每一个服务都维护着对应的一个服务锁。节点在启动服务前先抢占服务锁，节点在停止服务后释放此服务锁。

在多节点高可用配置仲裁服务器的集群***中，与双节点***类似。集群心跳网络正常时，各个节点发送刷新服务锁消息到仲裁服务器，仲裁服务器维持服务锁状况不变。当集群心跳网络不正常时，集群可能***成两个或以上的子集群，服务所在的子集群叫做服务运行子集群，服务不在其中的子集群叫做服务未运行子集群。服务运行子集群的节点都定期发送刷新服务锁消息到仲裁服务器，服务未运行子集群的节点也定期发送申请服务锁消息到仲裁服务器，仲裁服务器接收到各节点的消息作出相应的仲裁处理。当服务锁处于unlocked状态时，各个节点都可以抢占服务锁，只有唯一一个节点能抢占成功，抢占成功的节点可以启动服务，该节点变成服务运行节点，其所在的子集群变成了服务运行子集群。

如图1所示，为仲裁服务器维护的服务锁的结构图，内容包括服务锁名称、服务锁的状态、服务锁刷新时间戳、服务所在的节点、服务运行子集群的成员节点等。

如图2a，2b所示，分别为刷新服务锁消息、申请服务锁消息的内容。

以下的描述的实施例内容中，同时涵盖了双节点和多节点的高可用集群***。

如图3所示，本发明实施例包括集群端服务未运行子集群向仲裁服务器申请服务锁的方法：

步骤301，当心跳网络中断时，集群端代理模块检测出集群节点状态发生了变化，并且该节点处于服务未运行子集群，于是在步骤302，该子集群向仲裁服务器发送申请服务锁消息，并等待仲裁服务器的仲裁结果。

在步骤303中，服务未运行子集群接收到仲裁服务器返回的仲裁结果。

如果抢锁成功，则在步骤304中启动服务锁对应的服务，该节点变成了服务运行节点，其所在子集群变成了服务运行子集群。同时，服务运行子集群的其他成员节点的集群端代理模块也检测出其已经处于服务运行子集群中，已经变成了服务运行子集群的备份节点，此后，服务运行子集群的备份节点不再向仲裁服务器发送申请服务锁消息，改为发送刷新服务锁消息，并把刷新服务锁成功消息的时间发送给服务运行节点，以用作服务运行节点的刷新服务锁成功时间。

在步骤303中，节点接收到仲裁服务器返回的抢占服务锁失败消息后，在t_giveup时间内会持续向仲裁服务器发送申请服务锁消息。如果t_giveup时间内接收到抢占服务锁成功消息则启动接管服务，如果一直未收到服务锁抢占成功消息就证明服务仍然在其他子集群运行，或者被其他子集群启动，该节点不会接管服务，避免裂脑发生。

在本实施例中，如果采用通过公有网络PING心跳断开节点的IP来判断节点的状态，在***不允许PING(即***不会回应icmp请求包)、交换机端口损坏、网络风暴等等情况下，都不能有效地判断节点的状态，更不能有效地判断服务的状态，存在着很大的安全风险。发明人通过仲裁服务器接收刷新服务锁消息和抢占服务锁消息可以更准确地检测节点的状态，而且也能准确地检测服务的状态。

如图4所示，是本发明的服务运行子集群刷新服务锁流程图，包括：

步骤401，服务运行节点就向仲裁服务器发送刷新服务锁消息。仲裁服务器接收到该节点的刷新服务锁消息，它会根据刷新服务锁消息的内容更新服务锁信息，给该节点返回刷新服务锁成功消息。

在步骤402，服务运行节点判断刷新服务锁操作是否成功。如成功则操作结束，如不成功则通过步骤403判断当前时间与最后一次刷新服务锁时间之差是否超过了t_timeout。如超过t_timeout则服务运行节点认为该服务运行子集群已经与仲裁服务器断开连接了，服务运行子集群变成孤立子集群。服务运行子集群失去仲裁服务器的仲裁功能。

服务运行集群变成孤立子集群后，为了保持服务的连续性、可靠性，步骤404分开两种情况处理：(1)服务运行子集群的节点数量大于或等于原集群的节点数量的1/2时，服务运行节点无需停止服务，保持对外服务；(2)服务运行子集群的节点数量小于原集群的节点数量的1/2时，服务运行节点执行服务停止操作，在t_giveup时间内服务不能正常停止时，服务运行节点要执行服务器重启***动作把服务最终停止下来。

服务运行节点维护着的刷新服务锁成功时间其实是服务运行子集群各个节点最新的刷新服务锁成功时间，服务运行子集群各个节点都定期向仲裁服务器发送刷新服务锁消息，仲裁服务器返回刷新服务锁成功消息。服务运行子集群的备份节点接收到自己的刷新服务锁成功消息后把该时间通知服务运行节点，服务运行节点把该时间与原刷新服务锁成功时间作比较，得出最新时间作为服务运行节点刷新服务锁时间。

在本实施例中，对双节点集群而言，服务A在节点1上运行，则认为节点1是服务A的服务运行节点，相应地，另外一个节点2就是备份节点。如果节点2上运行服务B，则节点2是服务B服务运行节点，节点1是备份节点。对于多节点集群也如此，一个节点可以为一个服务的服务运行节点，也可以为另外一个服务的备份节点。

如图5所示，本发明实施例仲裁服务器端服务锁管理程序，包括：

在本实施例中，当集群心跳正常时，集群不会***成两个或多个子集群，这时的集群可以看作最大的服务运行子集群，它包括了所有的节点。因此，集群的所有节点都向仲裁服务器发送刷新服务锁消息，仲裁服务器维持相应的服务锁状态，并不断更新服务锁的刷新时间戳。

在本实施例中，当集群心跳网络中断时，仲裁服务器判别服务是否已经停止是至关重要的。在步骤501，当仲裁服务器接收到申请服务锁消息时，它就已经知道集群心跳网络中断，集群***成至少两个子集群。

在步骤502，如果服务锁处于unlocked的状态，则实施抢占服务锁操作，将服务锁状态置为locked状态，服务锁运行节点置为抢锁节点，并返回抢锁成功消息。步骤503如果服务锁处于locked的状态，仲裁服务器给申请服务锁节点返回抢锁失败消息；如果服务锁处于unknown状态，步骤504检测到服务锁未刷新时间大于t_giveup时，仲裁服务器实施占锁操作，将服务锁状态置为locked状态，服务锁运行节点置为抢锁节点，并返回抢锁成功消息。

如图6所示，本发明提供仲裁服务器接收到刷新服务锁消息处理流程，包括：

对应于每个服务，仲裁服务器维护着一个服务锁，服务锁是有一个t_timeout有效期。在步骤601，如果当仲裁服务器接收到刷新服务锁消息时，在步骤602，它会根据刷新服务锁消息的内容更新服务锁的信息。如果服务运行节点变换了，或节点成员变化了，仲裁服务器都能从每个刷新服务锁消息中得知这些信息，并不断的更新服务锁信息。当接收到刷新服务锁消息时，必须更新的服务锁的成员项就是服务锁的刷新时间戳，仲裁服务器每接收到一个刷新服务锁消息，都要更新服务锁的刷新时间戳，以维护服务锁最新的刷新时间。

如图7所示，本发明提供仲裁服务器定期检测服务锁刷新时间戳的流程的方法，包括：

仲裁服务器定期地检查服务锁的刷新时间戳。在步骤701，如果仲裁服务器检测出当前时间与服务锁的刷新时间戳之差超过了t_timeout，仲裁服务器认为服务运行子集群变成了孤立子集群。由于仲裁服务器不能确定服务的状态，因此，在步骤702，仲裁服务器把服务锁状态置为unknown状状态。

在超过t_timeout时间内，仲裁服务器都没有接收到节点刷新服务锁消息或申请服务锁消息，或者仲裁服务器因故障重启***之后，仲裁服务器就认为它与集群的所有节点都断开连接了。此时，仲裁服务器是不能确定服务的状态的，有可能是集群心跳没有中断，整个集群没有发生***，服务正常运行；也有可能是集群刚刚***；也有可能是服务早已停止了。这种情况下，仲裁服务器把服务锁都置为unknown状态。当仲裁服务器重新与集群节点连接时起，仲裁服务器如果接收到节点刷新服务锁消息，就把服务锁状态置为locked状态，并根据刷新服务锁消息的内容更新服务锁的信息。如果仲裁服务器重新与集群节点连接并接收到申请服务锁消息，申请服务锁消息中的成员节点数量大于原集群的节点数量的1/2时，仲裁服务器在t_giveup时间之后把服务锁的状态置为unlocked状态。

在本实施例中，值得注意的本发明中的仲裁服务器维护的服务锁是不会出现“死锁”现象的，所谓的“死锁”现象是抢占服务锁的服务运行节点因故障或节点死亡而无法释放，其他节点无法成功抢占服务锁。本发明中仲裁服务器引入了服务锁的“有效期”性质，抢占服务锁的服务运行子集群必须周期地在“有效期(t_timeout)内向仲裁服务器刷新服务锁时间戳。仲裁服务器在“有效期”内没有收到服务运行子集群的刷新服务锁消息，并且接收到的申请服务锁消息中的成员节点数量大于原集群的节点数量的1/2时就会把服务锁回收，置为unlocked状态，再重新抢占；同样，服务运行子集群在“有效期”(t_timeout)没有接收到刷新服务锁成功消息，并且其子集群节点数量小于原集群节点数量的1/2时，就要停止服务。

本发明实施例提供一种基于仲裁服务器的高可用集群裂脑预防的方法，在心跳网络中断，集群***成多个子集群后，各个节点仍然可以持续监控各个服务锁的状态，继续可以接管、启动服务对外提供服务，最大程度实现服务的不间断性。本发明实施例提供的技术方案解决了目前尽可能不需要***重启或共享存储隔离的情况下，在集群心跳网络中断后，集群仍然继续可靠地、最大程度不间断地对外提供服务。

如图8所示，本发明提供一种基于仲裁服务器的高可用集群裂脑预防的装置，包括：

集群端代理模块801，用于检测本节点所在的子集群有那些其他节点成员，以及检测服务是否在其所在子集群运行。

本实施例中，集群端代理模块801是集群中的一个模块。它能够实时接收集群节点成员变化事件信息。当节点成员变化或心跳线中断时，集群端代理模块判断服务是否在该子集群中的某个节点运行。如果服务在该子集群中的某个节点运行，则继续刷新服务锁信息，如果服务没有在该子集群中运行，则需要发送申请服务锁消息，尝试接管服务。

仲裁服务器端服务锁模块802，用于处理服务未运行子集群节点查询、抢占服务锁消息，处理服务运行子集群节点刷新服务锁消息，分配服务锁给获胜节点，维护、更新服务锁信息。

在本实施例中，服务锁维护模块是仲裁服务程序的主要模块，它处理仲裁服务器端接收的消息，作出仲裁结果。当集群心跳网络中断时，服务锁维护模块判别服务是否已经停止是至关重要的，它可能处理刷新服务锁消息或申请服务锁消息。

在本实施例中，当处理申请服务锁消息时，服务锁维护模块检查服务锁的状态，如果服务锁处于locked的状态，它就给申请服务锁节点返回抢锁失败消息；如果服务锁处于unknown状态，申请服务锁消息中的成员节点数量大于原集群的节点数量的1/2时，仲裁服务器在t_giveup时间之后把服务锁的状态置为locked状态，并更新占锁节点名及占锁时间戳，宣布抢锁成功。

当处理刷新服务锁消息时，服务锁维护模块根据刷新服务锁消息的内容更新服务锁的信息。服务锁维护模块每处理一个刷新服务锁消息，都要处理对应的服务锁的刷新时间戳，以维护服务锁最新的刷新时间戳。服务锁维护模块定期地检查服务锁的刷新时间戳，如果当前时间与服务锁的刷新时间戳之差超过了t_timeout，则它认为服务运行子集群已变成了孤立子集群，仲裁服务器不能确定服务的状态，把服务锁状态置为unknown状态。

本发明实施例提供一种基于仲裁服务器的高可用集群裂脑预防的装置，在心跳网络中断的情况下，仲裁服务器接收到各个节点发给它的消息，根据这些消息，仲裁服务器准确维护服务锁的信息。如果服务锁的状态是unlocked的，仲裁服务器充许节点参与抢占服务锁，获胜节点将会启动服务对外提供服务；如果服务锁的状态是locked的，说明服务已经在某个节点上启动并对外提供服务，节点不接管服务，避免了裂脑产生。本发明实施例提供的技术方案解决了目前尽量不需要将***重启或共享存储隔离的情况下，在集群心跳网络中断后，集群仍然继续可靠地、最大程度不间断地对外提供服务。

本发明实施例提供一种基于仲裁服务器的高可用集群裂脑预防的方法和装置，都可以直接应用在高可用性的集群中。

结合本文所公开的实施描述的方法或算法步骤可以直接应用于硬件、外理器执行的软件模块，或者二者综合来实施。

以上所述，仅为本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，因此，本说明书内容不应理解为对本发明的限制。

Claims (2)

1.基于仲裁服务器的高可用集群裂脑预防方法，其特征在于：

集群内服务器节点启动服务前必须向仲裁服务器申请服务锁，未获得服务锁的集群节点不得启动服务；当节点死或心跳线故障时，未运行服务的子集群通过定期向仲裁服务器申请服务锁来决定是否接管服务；申请到服务锁则接管服务，未申请到服务锁则不予接管；从而避免服务在多个子集群内同时运行；

其中：裂脑状态是集群***成数个子集群，彼此失去联系并认为其他节点已死，并尝试从″已死节点″接管资源；从而导致服务在多个节点同时运行、共享存储数据损坏一系列严重问题；

启动服务前需要取得服务锁，

服务未运行节点在尝试接管服务开始，在t_giveup时间内定期向仲裁服务器申请服务锁，当仲裁服务器的相应服务锁处于unlocked状态时，服务未运行节点将抢占服务锁，并进行服务接管；

服务运行节点定期刷新服务锁，

所述服务运行节点所在子集群选出一个通信节点和仲裁服务器通信，定期发送刷新服务锁消息到仲裁服务器，进行服务锁时间戳的刷新；

服务故障会停止服务并释放服务锁，

当服务在运行节点因故障而停止，服务将服务锁释放回仲裁服务器；该子集群内部会选择一个备份节点尝试申请服务锁并接管服务，该备份节点向仲裁服务器申请服务锁成功后，将进行服务接管，并成为新的服务运行节点；若备份节点启动服务失败，将停止服务并再次释放服务锁；

当服务运行子集群中的所有备份节点连续申请服务锁及接管服务失败，除非有新的节点状态变化事件，否则该子集群将不再尝试申请服务锁及接管该服务；

集群与仲裁服务器中断联系的处理，

服务运行子集群会选出一个节点作为仲裁服务器通信节点；当服务运行子集群通信节点检测出当前时间与刷新服务锁成功时间之差超过预定的t_timeout时间，则认为与仲裁服务器断开连接，服务运行子集群会尝试选举其他节点和仲裁服务器进行通信，当所有节点均无法和仲裁服务器通信，服务运行子集群变成孤立子集群，失去仲裁服务器的仲裁功能；

所述的服务运行子集群变成孤立子集群，如果该子集群节点数量小于等于原集群节点数量的1/2，服务运行节点必须停止服务；在t_giveup时间内服务不能正常停止时，服务运行节点要执行重启***动作，并且服务运行子集群中备份节点不能接管服务，亦不再发送刷新服务锁消息到仲裁服务器；

所述的服务运行子集群变成孤立子集群，如果服务运行子集群的节点数量大于原集群的节点数量的1/2，服务运行节点无需停止服务，继续保持对外服务；

仲裁服务器端的服务锁处理，

所述的仲裁服务器检测当前时间与服务锁刷新时间戳之差超过预定的时间t_timeout，则仲裁服务器认为服务运行子集群已断开连接，把服务锁的状态置为unknown状态；

仲裁服务器在把服务锁的状态置为unknown状态后的t_giveup时间把服务锁的状态置为unlocked状态；

仲裁服务器在把服务锁的状态置为unlocked后，如果收到新的服务锁申请，则将服务锁分配给该节点。

2.根据权利要求1所述的方法还包括仲裁服务器的高可用冗余机制，其特征在于：

为避免仲裁服务器成为单点故障源，集群内设置奇数台仲裁服务器，在服务锁抢锁时，按照抢得服务锁＞1/2仲裁服务器节点数者胜出原则，进行服务接管。