CN108494585A - 选举控制方法及装置 - Google Patents

Abstract

本申请涉及数据通信技术领域，尤其涉及一种选举控制方法及装置、选举方法及装置，该方法应用于集群服务系统中部署有目标监控进程monitor的节点，该方法包括：监测部署有第一monitor的第一节点的运行环境；当监测到运行环境中存在异常情况后，将第一monitor关闭，以阻止第一monitor在多个monitor中参与领导者leader选举及向集群外客户端提供服务。这样，当monitor的运行状态和运行环境出现异常时，就不会不断地重复进入选举状态，也不会因此导致整个集群服务的中断，另外，也不会在有问题的状态下为客户端提供服务，从而节省了系统资源，提高了分布式存储集群中数据的可靠性。

Description

选举控制方法及装置

技术领域

本申请涉及数据通信技术领域，尤其涉及一种选举控制方法及装置。

背景技术

Ceph是一种为优秀的性能、可靠性和可扩展性而设计的统一的、分布式文件系统。在Ceph中，为了避免单端故障，通常由若干个监控进程(monitor)共同负责管理、维护和发布集群的状态信息；在若干个monitor中会选出一个领导者(leader)，这些monitor中的其它普通参与选举成员(peon)在该leader的领导下，生成集群图(cluster map)的最新版本，然后将该最新版本发送至Ceph中的全体对象存储设备(Object-based Storage Device,OSD)以及客户端(Client)。OSD使用cluster map进行数据的维护，而Client使用clustermap进行数据的寻址。

在进行leader选举时，先由有选举资格的monitor共同形成一个委员会(quorum)，然后委员会的成员在内部选出leader。每个monitor在初始化的时候都会被赋予一个排位(rank)值，当选举leader时，rank值最小的monitor胜出当选leader。每个monitor在启动并完成初始化后会向其它monitor发送探测报文，若根据回应报文中的quorum信息，确定已形成有quorum，则作为quorum的一员发起选举。这里，形成quorum的条件是可参与选举的monitor数量超过全部monitor数量的一半。某monitor当选为leader的条件为同意其成为leader的monitor数量超过全部monitor数量的一半。

在leader选举期间，Ceph是无法对外提供服务的，直到选举出leader，并在leader的带领下形成cluster map的master版本。在选举过程中，若monitor集群中任一monitor的网络存在震荡、延时等不稳定因素，会造成monitor反复退出和加入quorum，反复发起选举。如此，整个monitor集群会一直处于选举状态，浪费资源，并且无法对外提供服务。

发明内容

本申请实施例提供一种选举控制方法及装置，用以解决集群服务系统中出现异常情况时存在的反复选举的问题。

第一方面，提供一种选举控制方法，该方法应用于集群服务系统中部署有第一监控进程monitor的第一节点，该方法包括：

监测所述部署有第一monitor的第一节点的运行环境；

当监测到所述运行环境中存在异常情况后，将所述第一monitor关闭，以阻止所述第一monitor在多个monitor中参与领导者leader选举及向集群外客户端提供服务。

第二方面，还提供一种选举控制装置，该装置应用于集群服务系统中部署有第一监控进程monitor的第一节点，该装置包括：

异常监测模块，用于监测所述部署有第一monitor的第一节点的运行环境；

异常处理模块，用于当监测到所述运行环境中存在异常情况后，将所述第一monitor关闭，以阻止所述第一monitor在多个monitor中参与领导者leader选举及向集群外客户端提供服务。

本申请实施例上述方案中，通过监测集群服务系统中部署的monitor的节点的运行环境来检测异常情况，当存在异常情况时，通过将节点中的monitor关闭，来阻止目标monitor参与leader选举及向集群外客户端提供服务。这样，当monitor所在节点的运行环境出现异常时，该monitor就不会不断地重复进入选举状态，从而节省了系统资源。另外，由于避免了不必要的选举过程，从而防止了因选举过程所导致的整个集群服务的中断；进一步地，还阻止了出现异常的monitor向集群外客户端提供服务；因此，本申请实施例提高了分布式存储集群中数据的可靠性，保证了集群服务的可持续性和服务质量。

附图说明

为了更加清楚地说明本申请实施例或者现有技术中的技术方案，下面将对本申请实施例或者现有技术描述中所需要的附图做简单的介绍。显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。

图1为本申请实施例涉及的集群服务系统示意图；

图2为本申请实施例提供的选举控制方法流程图；

图3为本申请实施例提供的选举控制方法原理示意图；

图4为本申请另一实施例提供的选举控制方法流程图；

图5为本申请另外一种实施例提供的选举方法流程图；

图6为本申请又一实施例提供的选举方法流程图；

图7为本申请实施例提供的选举控制装置700结构示意图；

图8为本申请另一实施例提供的选举控制装置800结构示意图。

具体实施方式

如图1所示，为本申请实施例涉及的集群服务系统示意图，该集群服务系统是指为集群外客户端提供数据访问服务的、由多个部署有monitor的节点和多个提供数据存储服务的OSD组成的服务集群，比如可以是分布式文件系统Ceph。服务集群中的每个节点中分别部署有一个监控进程monitor；多个monitor会选举出一个leader，该leader根据各个monitor分别管理的数据存储信息(未被当选为leader的monitor称为peon)，生成clustermap的最新版本。OSD使用cluster map进行数据的维护，而Client使用cluster map进行数据的寻址。这里，cluster map中包括用于指示OSD中各个数据文件的存储位置的信息。

在实施本申请方案之前，一旦发生监控节点的网络反复中断等不稳定因素，都会造成monitor反复发起选举，一方面浪费了资源，另一方面，由于只有选举出leader，才能进一步进行cluster map版本的更新，因此在选举期间无法进行cluster map版本的更新，如此就会影响集群正常对外提供服务。基于此，本申请一种实施例中提出了一种基于异常检测机制来解决反复选举的问题，详见下述实施例。

如图2所示，为本申请实施例提供的选举控制方法流程图，应用于集群服务系统中部署有第一monitor的第一节点，具体地，执行下述步骤的可以是第一节点中独立于第一monitor外的软件模块，该方法包括以下步骤：

S201：监测部署有第一monitor的第一节点的运行环境。

这里，第一节点的运行环境包括第一监控节点的网络状态。比如，部署有第一monitor的第一节点与集群内部署有其它monitor的节点之间的链路状态，以及第一节点的网卡状态等。

S202：当监测到运行环境中存在异常情况后，将第一monitor关闭，以阻止第一monitor在多个monitor中参与领导者leader选举及向集群外客户端提供服务。

这里，监测到第一节点的运行环境中存在异常情况，可以是指出现以下情况中的一种或多种：

Ⅰ、部署有第一monitor的第一节点与集群内部署有其它monitor的节点之间的链路状态出现异常；

Ⅱ、第一节点的网卡状态出现异常。

为便于后续描述，这里引入两个功能模块，异常监测模块和异常处理模块，如图3所示，异常监测模块负责监测并记录上述异常情况，比如监测并记录异常发生时间、异常来源等，并将记录的异常结果上报给异常处理模块；异常处理模块负责针对异常情况将第一monitor关闭，下面称这种在监测到环境中存在异常情况后将第一monitor关闭的机制为隔离机制。

下面以工作在Linux系统环境下的集群服务系统Ceph为例，对上述几种异常情况进行举例说明。

针对上述第Ⅰ种异常情况，第一节点可以通过监测第一节点与集群内部署有其他monitor的节点之间的心跳连接是否超时，来监测第一节点与集群内部署有其他monitor的节点之间的链路状态是否出现异常。

具体地，monitor之间通过租约(lease)机制来保活。在使用lease机制保活的时候，部署有第一monitor的第一节点会与集群内部署有其它monitor的节点建立心跳的传输控制协议(Transmission Control Protocol，TCP)链路。第一节点基于该TCP链路，周期性进行心跳检测。在进行心跳检测时，第一节点会向其它节点发起心跳包；如果预设时间内无法接收到对端节点反馈的心跳包，则此次心跳连接超时。

异常监测模块会记录与集群内各个节点之间的心跳连接连续超时的次数。若与集群中某节点之间的心跳连接连续超时的次数大于预设次数，也即，连续向其它节点发送多个心跳包，多个心跳包均超时，并且与第一节点之间的心跳连接超时的节点的数量大于预设数量，则认为第一节点的链路状态存在异常，并将异常结果上报给异常处理模块。

连续向其它节点发送多个心跳包存在如下两种可能的情形：

其一，在连续的多个周期内，每个周期都向其它节点发送一个心跳包。其中，连续的多个周期的数量与预设次数一致。

例如，集群内有4个部署有monitor的节点，分别为节点A、节点B、节点C和节点D；节点A作为第一节点，分别与节点B、节点C和节点D建立心跳的TCP链路，并基于分别和节点B、节点C和节点D建立的心跳的TCP链路，每隔2秒分别向集群内的节点B、节点C和节点D发送一次心跳包。

假设此时，预设时长为0.3秒，预设数量为2，预设次数为3。

第一节点会每隔2秒向节点B、节点C和节点D分别发送一次心跳包；如果连续的3个周期中，每个周期都无法在发出心跳包后的0.3秒内接收到节点B和节点D反馈的心跳包，则认为节点A与集群内节点B、节点C和节点D的链路状态出现异常。

其二，在一个周期内，连续向其它节点发送多个心跳包。

例如，集群内有4个部署有monitor的节点，分别为节点A、节点B、节点C和节点D；节点A作为第一节点，会与节点B、节点C和节点D分别建立心跳的TCP链路，并基于和节点B、节点C和节点D分别建立的心跳的TCP链路，每隔2秒向集群内的节点B、节点C和节点D分别发送一组心跳包，每组心跳包的数量有3个。

假设此时，预设时长为0.3秒，预设数量为2。

第一节点每隔2秒向节点B、节点C和节点D分别发送3个心跳包；如果节点A向节点B和节点C发出的每一个心跳包后的0.3秒内，都无法接收到节点B和节点C反馈的心跳包，则认为节点A与集群内节点B、节点C和节点D的链路状态出现异常。

针对上述第Ⅱ中情况，可以通过监测网卡的丢包率是否达到预设的丢包率阈值，来检测第一节点的网卡状态是否出现异常。

具体地，第一节点会周期性统计第一节点中的网卡的丢包率。若第一节点的网卡的丢包率超出预设的丢包率阈值，则确定网卡状态存在异常。

此处，网卡对数据包的处理结果有三种，分别为：传输成功、丢弃drop以及错误error，这里将drop以及error统称为丢包。异常监测模块会周期性统计网卡的丢包率。丢包率是指周期内处理结果为drop以及error的数据包的数量在该周期内网卡所处理数据包总数量中占据的百分比。如果该丢包率超出预设的丢包率阈值，则网卡状态存在异常。

例如，丢包率的检测周期为30秒，异常监测模块会统计30秒内网卡的丢包率。假设预设的丢包率阈值为5％；在这30秒内，网卡共处理100个数据包；如果这100个数据包中，处理结果为drop以及error的数据包的数量为10，则在该周期内网卡的丢包率为10％，超出了预设的丢包率阈值，此时确定网卡状态存在异常。

具体地，在对网卡的丢包率进行检测的时候，可能存在如下两种情况：

其一，第一节点上所安装的网卡有一个。当检测到该网卡的丢包率大于预设的丢包率阈值时，则确定第一节点的网卡状态存在异常。

其二，第一节点上安装的网卡包括主网卡和备用网卡。异常监测模块周期性统计主网卡的丢包率。如果主网卡的丢包率超出预设的丢包率阈值，则确定主网卡存在异常；此时第一节点会将主网卡停用，并启动备用网卡。在主网卡停用，且启动备用网卡后，异常监测模块周期性统计备用网卡的丢包率。如果备用网卡的丢包率超出预设的丢包率阈值，则备用网卡也存在异常，最终确定第一节点的网卡存在异常，并将异常结果上报给异常处理模块。

当异常处理模块接收到异常监测模块上报的异常结果后，将第一monitor关闭，以阻止第一monitor在多个monitor中参与领导者leader选举及向集群外客户端提供服务。

在具体实施中，在将第一monitor关闭后，第一节点无法再执行monitor的相关功能，因此不会向客户端提供服务，也不会参与到选举中；同时，第一节点即使接收到部署有monitor的其它节点发送的探测报文，也不会向发出探测报文的节点进行反馈，而是直接将探测报文丢弃。

另外，还可以通过如下情况中至少一种来确定第一节点的运行环境存在异常情况：

(1)第一monitor所使用的网卡在预设时长T1内发生重启的次数超过设定阈值L1；

(2)第一monitor所使用的网卡发生单通；这里，单通是指只能接收数据或者只能发送数据；

(3)第一节点资源(比如CPU资源、内存资源等)占用率高于一定阈值；

(4)第一节点在预设时长T2内发生重启的次数超过设定阈值L2；

这里的T1、T2可以相同，也可以不同，L1、L2可以相同，也可以不同。

为便于后续描述，这里也引入两个功能模块，异常监测模块和异常处理模块，异常监测模块负责监测并记录上述异常情况，比如监测并记录异常发生时间、异常来源等，并将记录的异常结果上报给异常处理模块；异常处理模块负责针对异常情况将第一monitor关闭。

下面以工作在Linux系统环境下的集群服务系统Ceph为例，对上述几种异常情况进行举例说明。

针对上述第(1)种异常情况，在Linux系统中，网卡启动/关闭(up/down)的信息可以在系统日志(syslog)或内核日志(kernel.log)中查询到。异常监测模块可以周期性读取这些日志，并分析是否存在异常情况。比如，每隔2分钟从日志的末尾处向前(也即按照时间由新到旧的顺序)搜索第一monitor对应网卡的启动日志，如果得到的网卡启动时间与当前系统时间之间的差值小于5分钟(也即T2)，则将累计的up次数加1，也即，搜索最近5分钟内网卡up次数，如果累计up次数超过3次(也即L2)则记录异常结果，并将异常结果上报给异常处理模块。比如记录的异常结果中包括：0-表示发生异常，异常发生时间：当前系统时间，异常信息：网卡反复up/down，异常来源：第一monitor对应的IP地址)。

针对上述第(2)种异常情况，在Linux系统中，可以通过报文统计命令:ifconfigem1查看报文收发统计信息，具体地，可以每隔一段时间(比如每隔两分钟)统计一次接收报文和发送报文的个数，并将当前统计的接收报文个数(可以指从第一monitor启动时间到当前系统时间之间的时间段内接收报文的个数)与上一次统计的接收报文个数(可以指从第一monitor启动时间到上一次统计时间之间的时间段内接收报文的个数)进行比较，如果两者的个数差小于一定阈值，则认为网卡入方向不通，相应地，将当前统计的发送报文个数(可以指从第一monitor启动时间到当前系统时间之间的时间段内发送报文的个数)与上一次统计的发送报文个数(可以指从第一monitor启动时间到上一次统计时间之间的时间段内发送报文的个数)进行比较，如果两者的个数差小于一定阈值，则认为网卡出方向不通。记录的异常结果中可以包括：0-表示发生异常，异常发生时间：当前系统时间，异常信息：网卡出方向或入方向不通，异常来源：第一monitor对应的IP地址。

针对上述第(3)种异常情况，实时监测第一节点的资源使用情况，比如CPU资源占用情况、内存资源占用情况等，一旦资源占用率高于一定阈值(比如98％)，说明第一monitor无法正常运行，此时及时上报异常结果：0-表示发生异常，异常发生时间：当前系统时间，异常信息：设备资源占用率过高，异常来源：第一monitor对应的IP地址。

上述第(4)种异常情况与第(1)种类似，详见上述针对第(1)种异常情况的说明，这里不再赘述。

在具体实施中，异常处理模块在接收到异常监测模块发送的异常结果后，将第一monitor关闭，以阻止第一monitor在多个monitor中参与领导者leader选举及向集群外客户端提供服务。

在将第一monitor关闭后，第一节点的运行环境有可能会恢复正常，基于此，在本申请几种实施方式下，给出了当监测到异常情况结束后的处理机制。

异常情况结束后的处理机制具体包括下述实施方式一和实施方式二；实施方式一见步骤S203；实施方式二见S204。

S203：当监测到运行环境中的异常情况结束后，重新启动第一monitor，以恢复第一monitor在多个monitor中参与leader选举及向集群外客户端提供服务的功能(实施方式一)。

这里，当监测到第一节点的运行环境中的异常情况结束后，重新启动第一monitor，恢复第一monitor的正常工作状态。

对应上述内容中介绍的Ⅰ和Ⅱ两种情况，异常情况结束可以指：第一节点与集群内部署有其他monitor的节点之间的链路状态恢复正常；第一节点的网卡状态由异常状态恢复为正常状态。

比如，如果之前异常状况是第一节点与集群内部署有其它monitor的节点之间的心跳连接超时，在将第一monitor关闭后，异常监测模块仍然会按照原来的心跳周期向集群内的其它节点发送心跳包。如果对心跳包的检测达到一定条件，例如当确定与第一节点之间的心跳连接超时的节点数量小于预设的阈值，并且第一节点与任一节点之间心跳连接连续超时的次数小于预设次数时，持续该状态10分钟后，则认为链路状态恢复正常。

对应上述内容中介绍的(1)-(4)的五种异常情况，异常情况结束可以指：第一monitor所使用的网卡在预设时长T6内未发生单通；第一节点资源占用率低于一定阈值(比如CPU占用率、内存占用率均低于80％)；第一节点在预设时长T7内稳定在up状态；上述T4、T5、T6、T7可以相同，也可以不同。

比如，如果之前异常情况是网卡反复up/down，则当监测到该网卡up状态持续稳定10分钟后，认为网卡异常结束。再比如，如果之前异常情况是节点资源占用率过高，则当监测到节点资源占用率降低到80％以下时，认为异常结束。当异常监测模块监测到异常情况结束后，将异常结束信息上报给异常处理模块。比如，异常结束信息包括：1-表示异常结束，结束时间：当前系统时间，之前异常信息：网卡反复up/down，当前状态：网卡稳定在up状态，之前异常来源：第一monitor对应的IP地址)。

在具体实施中，异常监测模块可以在将监测到的异常结果上报给异常处理模块后，直接进入监测异常情况是否结束的阶段。异常监测模块也可以在将监测到的异常结果上报给异常处理模块后，经过一定的时间长度(在这段时间内默认为一直异常)后，再进入监测异常是否结束的阶段。

另外，由于leader异常相比普通monitor成员(peon)异常对集群的影响更大，因此也可以在重启第一monitor后，对第一monitor进行一定的限制，也即使得第一monitor具有为客户端提供服务的功能以及作为普通选举成员peon的功能，在一段观察期内，若第一monitor没有再发生异常，则再取消对第一monitor当选为leader的限制(实施方式二)。

S204(实施方式二)：当监测到第一节点的运行环境中的异常情况结束后，重新启动第一monitor，并对第一monitor发起的探测报文、第一monitor发起的选举请求、其它monitor针对第一monitor发起的探测报文反馈的回应报文、其它monitor针对第一monitor发起的选举请求反馈的响应报文进行拦截的操作，以阻止第一monitor当选为leader的机会；若在监测到异常情况结束后的第一设定时长内，未监测到新的异常情况，则取消对第一monitor发起的探测报文、第一monitor发起的选举请求、其它monitor针对第一monitor发起的探测报文反馈的回应报文、其它monitor针对第一monitor发起的选举请求反馈的响应报文进行拦截的操作，以恢复第一monitor当选为leader的机会。

具体地，在阻止第一monitor当选为leader的时候：

(1)对第一monitor发起的探测报文进行拦截，以便其它monitor接收不到该探测报文。

在具体实施中，在将第一monitor重新启动后，当第一monitor发起探测报文时，异常处理模块对该探测报文进行拦截，以阻止其发送出去，比如可以丢弃该探测报文，或者只是将其暂时存储起来而不发送。

(2)对集群服务系统中其它monitor针对第一monitor的探测报文反馈的回应报文进行拦截，以便重新启动后的第一monitor接收不到该回应报文。

在实际实施中，有可能在异常处理模块接收到异常结果时，第一monitor已经发送了探测报文，此时，若其它monitor反馈了回应报文，且第一monitor还未被关闭，异常处理模块对其它monitor反馈的回应报文进行拦截，以阻止其传输至第一monitor，比如可以丢弃该回应报文，或者只是将其暂时存储起来而不传输至第一monitor。

(3)对第一monitor发起的选举请求(即请求选举自己为leader)进行拦截，以便其它monitor接收不到该第一monitor的选举请求。

在具体实施中，在将第一monitor重新启动后，当第一monitor发起选举请求时，异常处理模块对该选举请求进行拦截，以阻止其发送出去，比如可以丢弃该选举请求对应的报文，或者只是将其暂时存储起来而不发送。

(4)对集群服务系统中其它monitor针对第一monitor的选举请求反馈的响应报文进行拦截，以便第一monitor接收不到该响应报文。

在实际实施中，有可能在异常处理模块接收到异常结果时，其它monitor已经接收到了第一monitor发送的选举请求，此时，若其它monitor反馈了响应报文，且第一monitor还未被关闭，异常处理模块对其它monitor反馈的响应报文进行拦截，以阻止其传输至第一monitor，比如可以丢弃该响应报文，或者只是将其暂时存储起来而不传输至第一monitor。

当监测到第一节点的运行环境的异常情况结束后，并且重新启动第一monitor的第一设定时长内，采用拦截情况中(1)-(4)，使得第一monitor在第一时长内具有向集群外客户端提供服务，并且作为普通选举成员peon的功能，而不能当选为leader。如果在第一设定时长内，第一节点的运行环境一直没有出现新的异常情况，则取消上述拦截情况中(1)-(4)，恢复第一monitor当选为leader的功能。

在具体实施中，考虑到发生过异常情况的monitor再次发生异常的概率会比较高，实施方式二提出一种降级处理的方式。也即，在异常情况结束时，第一monitor重启启动后先进入试用期(S204中的第一设定时长)，在试用期内，只能先作为普通选举成员peon加入集群，也即该重新启动的第一monitor没有资格被选举为leader，但可以参与其它monitor发起的选举，也可以基于最新的cluster map版本向集群外客户端提供服务。在试用期内，如果一直未发生新的异常情况，则在试用期结束后可以正常参与到集群的选举中，也即恢复当选为leader的机会；如果在试用期内发生了新的异常情况，则会被在此关闭。

本申请实施例还提出了一种监控节点之间的监督机制。每个监控节点还可以监测集群内其它monitor是否发生异常，如果发生异常，则对异常的monitor进行隔离。这种监督机制可以作为上述隔离机制(当监测到运行环境中存在异常后，将第一monitor关闭)的有效补充也可以单独实施。对于某些因自身异常而无法识别到自身的异常情况的节点，可以起到有效的监督作用。详见S205和S206的描述。

S205：当在第二设定时长内接收到第二节点发起的选举请求的次数超过设定阈值后，对第一monitor与第二monitor之间的交互报文进行拦截，并向其它节点发送异常情况报告，以阻止第二节点中部署的第二monitor参与leader选举；其它节点为部署除第一monitor和第二monitor外的其它monitor的节点，异常情况报告用于指示第二节点的运行环境中存在异常情况。

此处，需要注意的是，被拦截的报文为第一monitor与第二monitor之间的交互报文，不会拦截第一节点与第二节点之间的其它报文，如第一节点和第二节点之间的心跳包等，而是针对节点内monitor之间的交互报文进行拦截。

在具体实施中，第一节点的异常监测模块统计在第二设定时长内接收到的第二节点发起的选举请求的次数，若该次数超过设定阈值，则认为第二节点的运行环境中存在异常情况，此时对第一monitor与第二monitor之间的交互报文进行拦截，并向其它节点发送异常情况报告，以阻止第二monitor参与leader选举。

比如，第一节点的异常监测模块统计到在5分钟内接收到第二节点发起的选举请求的次数为4次，超过设定阈值3，则认为该第二节点的运行环境中存在异常情况，此时将异常结果上报给异常处理模块，异常结果记录为：0-表示发生异常，发生时间：当前系统时间，异常信息：第二节点反复发起选举请求，异常来源：第二节点对应的IP地址。异常处理模块将该异常结果对第一monitor与第二monitor之间的交互报文进行拦截，并向其它节点发送异常情况报告。

S206：当接收到针对第二节点的异常情况报告后，对第一monitor与第二monitor之间的交互报文进行拦截。

在具体实施中，监控节点之间的监督是相互的，第一节点可能会自己监测到第二节点的异常情况，也可能会接收到其它监控节点针对该第二节点的异常情况报告，如果接收到其它监控节点针对第二节点的异常情况报告，也会对该第二节点进行第二隔离，也即不向该第二节点发送选举请求，也不响应该第二节点发起的选举请求，具体采用的手段就是对第一monitor与第二monitor之间的交互报文进行拦截。

在上面内容中已说明，监控节点之间的监督机制可以作为上述隔离机制的补充，也可以单独实施。下面为上述监督机制单独实施时的实施例。

如图4所示，为本申请另一实施例提供的选举控制方法流程图，应用于集群服务系统中部署有第一monitor的节点(也即上述第一节点)，包括以下步骤：

S401：监测第二monitor在第二设定时长内发起选举请求的次数。

S402：判断第二monitor在第二设定时长内发起选举请求的次数是否超过设定阈值，若超过，则进入S403a和S403b，否则返回S401。

S403a：对第一节点中部署的第一monitor与第二节点中部署的第二monitor之间的交互报文进行拦截。

S403b：向其它节点发送异常情况报告；其中，其它节点为部署除第一monitor和第二monitor外的其它monitor的节点，异常情况报告用于指示第二节点的运行环境中存在异常情况。

S404：若接收到针对第二节点的异常情况报告，则进入上述S403a。

在S403a和S403b中，当第一节点(具体可以由上述异常监测模块执行)监测到第二节点在第二设定时长内发起选举请求的次数超过设定阈值后，认为第二节点的运行状态和运行环境中存在异常情况。此时，一方面，第一节点(具体可以由上述异常处理模块执行)对第二节点中部署的第二monitor进行隔离，也即对第一monitor与第二monitor之间的交互报文进行拦截。另一方面，第一节点(具体可以由上述异常处理模块执行)向其它节点发送异常情况报告，以便其它节点也对第二monitor进行隔离，以阻止第二monitor参与leader选举。

相应地，如果第一节点接收到其它节点针对第二monitor的异常情况报告，也会对第一monitor与第二monitor之间的交互报文进行拦截，也即S404→S403a。

上面的实施例是通过监测monitor运行中的异常情况来解决反复选举的问题。本申请实施例另外提供了一种通过简化选举机制来解决上述反复选举的问题。详见下述实施例的描述。

在进行leader选举时，是基于rank值来选举的，rank值是基于monitor对应的IP地址得到的，在选举时会选举出rank值最小的monitor为leader。如果monitor A在发起探测报文后，收到集群中超过半数的monitor的回应，则monitor A会发起选举请求，如果收到选举请求的monitor B对应的rank值小于monitor A对应的rank值，monitor B不认可monitorA作为leader，又会发起新的选举请求(即请求选举自己为leader)。如此反复，直到选举出集群中的monitor都认可的leader。可见，在现有的选举机制中，每一轮选举都需要经过反复多次触发选举的过程，而且，在每一轮选举过程中，如果存在monitor的增删，又会触发新一轮的选举，如此反复，各个monitor一直处于选举状态，不仅造成资源的浪费，而且monitor在选举过程中无法对外提供服务。

由于rank值只是基于IP地址得到的一个没有实质物理意义的参数，本申请下述实施例提出了一种简化的选举机制，也即monitor在探测阶段，如果发现已经存在quorum和leader，则不再进行rank值的比较，也即不再发起选举请求，而直接作为除leader外的普通选举成员peon加入集群。

如图5所示，为本申请另外一种实施例提供的选举方法，该方法应用于集群服务系统中部署有第一monitor的第一节点，包括以下步骤：

S501：在第一monitor启动并完成初始化后，向其它monitor发起探测报文。

这里，第一monitor开始创建并启用后，或者，因所在节点或自身原因发生重启后，会向集群内的其它monitor发送探测报文，以接收其它monitor反馈的回应报文，回应报文中会携带quorum信息。

S502：根据接收到的回应报文中的quorum信息，确定是否已存在leader。

这里，其它monitor反馈的quorum信息用于指示集群中是否已经存在quorum和leader。这里，quorum是在具备选举条件(某一monitor发起探测报文后，收到回应的数量超过集群中monitor数量的一半)时形成的，在形成quorum后，就会选举出leader。下面具体说明下quorum的初始形成及leader的选举条件，以便于后续方案的理解。

任一monitor在初始化后会向其它monitor发送探测报文，收到探测报文的monitor在确定任一monitor的rank值比自己的rank值小、也比本轮选举中之前其它发起探测报文的monitor的rank值小、且集群当前没有进入正式选举过程(没有收到选举请求)时，向任一monitor反馈回应报文。若该任一monitor根据回应报文中的quorum信息，确定集群中还没有quorum和leader，则先建立临时quorum集合(outside_quorum)，任一monitor每收到一个回应报文，将outside_quorum中的monitor成员数量加1，直到outside_quorum中的monitor成员数量达到集群中monitor总数的一半，则认为满足选举条件，此时形成正式的quorum，发起选举请求。其它monitor在收到选举请求后，将任一monitor的rank值与自己的rank值进行比较，如果任一monitor的rank值小，则响应任一monitor，也即认可任一monitor作为leader，否则，不响应任一monitor，并且发起自己的选举请求。如此重复，直到选举出一个集群中的每一个monitor都认可的leader。

上面内容描述的是在集群中还没有quorum和leader，也即集群首次进行leader选举的过程。本申请实施例主要对集群中已经存在quorum和leader之后的选举机制进行了简化处理。

S503：若确定存在leader，则不发起选举请求。

这里，由于leader是在quorum成立后选举出的，集群中已存在leader，也会存在quorum。在本申请实施例中，如果第一monitor探测到集群中已存在quorum和leader，则不会再发起选举请求，而是直接作为peon加入集群，如此便极大地简化了选举过程，节省了资源，并且保证了集群对外服务的可持续性。

S504：若确定不存在leader，则在满足选举条件时发起选举请求。

这里，如果集群中不存在leader，此时集群中一般不存在quorum，但也不排除集群中存在quorum，且此时正在进行leader选举的可能。如果集群中存在quorum，且正在进行leader选举，第一monitor在发起探测报文后，将无法收到回应报文，也就不会满足选举条件，因此这种情况下就不会发起选举请求。

当集群中不存在quorum和leader时，参考上面S502之后的描述内容，第一monitor在累计收到的回应报文的数量达到集群中monitor数量的一半时，发起选举请求。第一monitor开始发起选举请求时是请求选举自己为leader，如果存在其它monitor的rank值比第一monitor的rank值小，其它monitor会重新发起选举请求，最后选举出的leader为rank值最小的monitor。

为了进一步增加集群服务的可靠性，本申请又一实施例提供一种针对leader的主备切换策略。详见下述实施例的描述。

如图6所示，为本申请又一实施例提供的选举方法，该方法应用于集群服务系统中部署有第一monitor的第一节点，该方法包括：

S601：在第一monitor启动并完成初始化后，向其它monitor发起探测报文。

S602：根据接收到的回应报文中的quorum信息，确定是否已存在主leader和副leader；副leader用于在主leader异常时，切换为主leader。

这里，quorum信息中指示了集群中是否存在quorum、主leader和副leader。

S603：若确定存在主leader和副leader，则不发起选举请求。

这里，如果集群中已经存在quorum、主leader和副leader，则第一monitor不会再发起选举请求，而是直接作为peon加入集群，如此便极大地简化了选举过程，节省了资源，并且保证了集群对外服务的可持续性。

S604：若确定存在主leader，但不存在副leader，则参与副leader的选举。

这里，如果集群中已经存在quorum和主leader，但不存在副leader，一般地，此时集群中正在进行副leader的选举，若第一monitor接收到了其它monitor发起的选举副leader的请求，可以将自己的rank值与其它monitor的rank值进行比较，若自己的rank值大，则响应其它monitor发起的选举副leader的请求，若自己的rank值小，则不响应，并再次发起选举副leader的请求。

S605：若确定不存在主leader和副leader，则在满足选举条件时发起选举主leader的请求，并在选举出主leader之后，在quorum中选举副leader。

这里，如果集群中不存在主leader和副leader，此时集群中一般不存在quorum，但也不排除集群中存在quorum，且此时正在进行主leader选举的可能。如果集群中存在quorum，且正在进行主leader选举，第一monitor在发起探测报文后，将无法收到回应报文，也就不会满足选举条件，因此这种情况下就不会发起选举请求。

当集群中不存在quorum、主leader和副leader时，第一monitor在累计收到的回应报文的数量达到集群中monitor数量的一半时，发起选举主leader的请求。第一monitor开始发起请求时是请求选举自己为主leader，如果存在其它monitor的rank值比第一monitor的rank值小，其它monitor会重新发起选举主leader的请求，最后选举出的主leader为rank值最小的monitor。在选举出主leader之后，集群中的其它monitor采用同样的方式选举副leader，主leader此时只需响应其它monitor发起的请求。

另外，由于本申请实施例采用了主备快速切换的机制，主leader出现异常情况后，副leader会迅速切换为主leader，因此在上述步骤中不考虑集群中存在副leader、不存在主leader的情况，详见下述内容的描述。特殊地，如果某一monitor在需要针对第一monitor的探测报文反馈回应报文时，正好遇到主leader异常的情况，可以在副leader切换为主leader之后，再反馈回应报文。

上述实施例除了简化选举机制外，还增加了主备切换的方案，副leader在主leader发生异常情况后，迅速切换到主leader。在具体实施中，主leader和副leader都会发送自己的租约(lease)报文，除主leader外的其它monitor如果在规定的时间内没有接收到主leader的lease报文，则会判定主leader异常，此时会通知副leader切换为主leader，副leader在收到超过一半数量的monitor(可以包括副leader自己)指示进行角色切换后，会切换为主leader。在副leader切换为主leader之后，集群中没有了副leader，其它monitor因收不到副leader的lease报文，在满足选举条件时发起选举副leader的请求。也即，其它任一monitor确认在一定时间长度内没有收到副leader的lease报文后，发起探测报文，在收到集群中超过一半的monitor的回应报文后，发起选举副leader的请求，也即请求选举自己为副leader。

上述过程中，副leader切换为主leader的时间可以忽略不计，主leader出现异常情况后，副leader会迅速切换为主leader，此时集群中就有了主leader，而没有副leader，因此，集群中如果存在副leader，也会存在主leader，但如果存在主leader，不一定存在副leader。

在上述S604中，如果集群中存在主leader，不存在副leader，此时一般正在进行副leader的选举，此时第一monitor可以响应其它monitor发起的选举副leader的请求(在比较rank值之后确认该monitor可以为副leader)，也可以在发起选举请求的其它monitor的rank值比自己的rank值大的情况下，不进行响应，而是自己重新发起选举副leader的请求(请求选举自己为副leader)。

在上述S605中，若确定不存在主leader和副leader，则在第一monitor收到集群中超过半数的monitor的回应报文时，发起选举主leader的请求，若得到集群内全部monitor的响应，则第一monitor被选举为主leader，或者，其它monitor不响应，并再次发起选举主leader的请求，选举结果为其它monitor被选举为主leader。因此，S605中，在满足选举条件时发起选举主leader的请求，这里的选举条件就是指第一monitor收到集群中超过半数的monitor的回应报文；另外，S605中，在选举出主leader之后，在quorum中选举副leader，这里，第一monitor发起选举主leader的请求，但最后被选举为主leader的可能是第一monitor，也可能是其它monitor。不管第一monitor是否被选举为主leader，第一monitor都可以参与后续副leader的选举，只是如果第一monitor已经是主leader，只需响应其它monitor发起的选举副leader的请求(回复确认ACK报文)。

这里，副leader的选举需要等到主leader选举完成之后进行，一方面，主leader的地位和作用更加重要，只有主leader维持正常，才能确保集群服务的稳定性，另一方面，本申请实施例采用了主备切换的机制，如果只有副leader，没有主leader，副leader还需要切换到主leader。

在选举出主leader之后，除主leader外的其它monitor确认集群中没有副leader，发起探测报文，在收到集群中过半数的monitor的回应(主leader直接回应)后，发起选举副leader的请求，最后，如果集群中的所有monitor都同意发起选举请求的monitor为副leader，该monitor当选副leader成功。

作为上述步骤S601～S605的补充，若第一monitor启动时，集群中已有主leader和副leader，或者第一monitor在参与选举过程中没有被选举为主leader和副leader，则第一monitor作为普通选举成员peon，在确定主leader异常后，指示副leader切换为主leader；若在选举过程中第一monitor被选举为副leader，则当第一monitor收到超过一半数量的monitor(包括自己)指示进行角色切换后，切换为主leader。

另外，本申请实施例中，为了进一步提升主备切换效率，若第一monitor为副leader，则副leader在切换为主leader之前，从其它monitor处收集集群的数据存储信息；在切换为主leader之后，基于收集的数据存储信息，维护cluster map的版本更新。

这里，副leader在主leader没有发生异常时，与主leader一起，也进行集群的数据存储信息的收集，只是不会主动进行cluster map版本的更新，这里的数据存储信息包括数据在OSD中的存储位置等。在主leader异常时，副leader的master map版本相比主leader的master map版本是相同的或落后的。副leader可以查看最新收集的数据存储信息的更新时间，是否晚于本地存储的master map版本的更新时间，若晚于，说明master map版本需要更新，此时副leader可以基于收集的数据存储信息进行map版本的更新。

本申请实施例中，只让主leader扩散更新的master map版本，是为了保证集群中的唯一权威性。另外，由于只有完成最新master map版本的更新，副leader才能算是切换到了主leader，因此主leader和副leader都进行数据存储信息的收集，可以提高主副切换的速度，进一步提高集群服务的高可靠性。

本申请实施例通过主备切换的方式，在主leader出现异常时，可以由副leader切换到主leader，提高了集群的高可靠性，进一步地，通过副leader与主leader一起收集集群服务系统中的数据存储信息，使得副leader切换到主leader后，能够迅速恢复主leader的正常工作，进一步提高了集群服务的质量和效率。

基于同一发明构思，本申请实施例中还提供了与上述选举控制方法、对应的装置，由于本申请实施例中的装置解决问题的原理与上述方法相似，因此装置的实施可以参见方法的实施，重复之处不再赘述。

如图7所示，为本申请实施例提供的选举控制装置700结构示意图，该选举控制装置700对应上述第一节点，比如可以是第一节点，也可以是第一节点控制下的设备。该选举控制装置700包括：

异常监测模块701，用于监测部署有第一monitor的第一节点的运行环境；

异常处理模块702，用于当监测到运行环境中存在异常情况后，将第一monitor关闭，以阻止第一monitor在多个monitor中参与领导者leader选举及向集群外客户端提供服务。

可选地，集群服务系统中包含多个monitor和多个对象存储设备OSD；

其中，多个monitor中的leader根据各个monitor分别管理的数据存储信息，生成集群图cluster map，所述cluster map中包含有OSD中数据的存储位置信息，集群外客户端使用cluster map进行数据的寻址。

可选地，异常监测模块701具体用于：监测部署有第一monitor的第一节点与集群内部署有其它monitor的节点之间的链路状态，以及监测第一节点的网卡状态。

可选地，异常监测模块701具体用于通过下述步骤监测部署有第一monitor的第一节点与集群内部署有其它monitor的节点之间的链路状态：

监测第一节点与集群内部署有其它monitor的节点之间的心跳连接是否超时；其中，心跳连接超时是指当发起心跳包后，在预设时长内未收到反馈的心跳包；

若根据监测结果，确定与第一节点之间的心跳连接超时的节点的数量达到预设数量、且与任一节点之间心跳连接连续超时的次数达到预设次数，则认为链路状态存在异常。

可选地，异常监测模块701具体用于通过下述步骤监测部署有第一monitor的第一节点的网卡状态：

周期性统计部署有第一monitor的第一节点中网卡的丢包率；

若部署有第一monitor的第一节点的网卡的丢包率超出预设的丢包率阈值，则确定网卡状态存在异常。

可选地，第一节点中设置有主网卡和备用网卡；异常监测模块701，具体用于：

周期性统计主网卡的丢包率；

若主网卡的丢包率超出预设的丢包率阈值，则确定主网卡存在异常，在主网卡停用，启用备用网卡后，周期性统计备用网卡的丢包率；

若备用网卡的丢包率超出预设的丢包率阈值，则确定网卡状态存在异常。

可选地，异常处理模块702，还用于：当监测到运行环境中的异常情况结束后，重新启动第一monitor，以恢复第一monitor参与leader选举及向集群外客户端提供服务的功能。

上述实施例通过监测集群服务系统中部署的monitor的节点的运行环境来检测异常情况，当存在异常情况时，通过将节点中的monitor关闭，来阻止目标monitor参与leader选举及向集群外客户端提供服务。这样，当monitor所在节点的运行环境出现异常时，该monitor就不会不断地重复进入选举状态，从而节省了系统资源。另外，由于避免了不必要的选举过程，从而防止了因选举过程所导致的整个集群服务的中断；进一步地，还阻止了出现异常的monitor向集群外客户端提供服务；因此，本申请实施例提高了分布式存储集群中数据的可靠性，保证了集群服务的可持续性和服务质量。

如图8所示，为本申请实施例提供的选举控制装置800结构示意图，该选举控制装置800对应上述第一监控节点，比如可以是第一监控节点，也可以是第一监控节点控制下的设备。该选举控制装置800包括处理器81、存储器82和总线83，处理器81和存储器82之间通过总线83连接；存储器82中存储有执行指令，处理器81运行执行指令，以实现下述方法：

监测部署有第一monitor的第一节点的运行环境；

当监测到运行环境中存在异常情况后，将第一monitor关闭，以阻止第一monitor在多个monitor中参与领导者leader选举及向集群外客户端提供服务。

可选地，集群服务系统中包含多个monitor和多个对象存储设备OSD；

其中，多个monitor中的leader根据各个monitor分别管理的数据存储信息，生成集群图cluster map，所述cluster map中包含有OSD中数据的存储位置信息，集群外客户端使用cluster map进行数据的寻址。

可选地，处理器81具体用于：监测部署有第一monitor的第一节点与集群内部署有其它monitor的节点之间的链路状态，以及监测第一节点的网卡状态。

可选地，处理器81具体用于通过下述步骤监测部署有第一monitor的第一节点与集群内部署有其它monitor的节点之间的链路状态：

监测第一节点与集群内部署有其它monitor的节点之间的心跳连接是否超时；其中，心跳连接超时是指当发起心跳包后，在预设时长内未收到反馈的心跳包；

若根据监测结果，确定与第一节点之间的心跳连接超时的节点的数量达到预设数量、且与任一节点之间心跳连接连续超时的次数达到预设次数，则认为链路状态存在异常。

可选地，处理器81具体用于通过下述步骤监测部署有第一monitor的第一节点的网卡状态：

周期性统计部署有第一monitor的第一节点中网卡的丢包率；

若部署有第一monitor的第一节点的网卡的丢包率超出预设的丢包率阈值，则确定网卡状态存在异常。

可选地，处第一节点中设置有主网卡和备用网卡；处理器81具体用于：

周期性统计主网卡的丢包率；

若主网卡的丢包率超出预设的丢包率阈值，则确定主网卡存在异常，在主网卡停用，启用备用网卡后，周期性统计备用网卡的丢包率；

若备用网卡的丢包率超出预设的丢包率阈值，则确定网卡状态存在异常。

可选地，处理器81还用于当监测到运行环境中的异常情况结束后，重新启动第一monitor，以恢复第一monitor参与leader选举及向集群外客户端提供服务的功能。

对应于上述选举控制方法及装置，本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述选举控制方法的步骤。

本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应所述以权利要求的保护范围为准。

Claims (12)

1.一种选举控制方法，其特征在于，该方法应用于集群服务系统中部署有第一监控进程monitor的第一节点，该方法包括：

监测所述部署有第一monitor的第一节点的运行环境；

当监测到所述运行环境中存在异常情况后，将所述第一monitor关闭，以阻止所述第一monitor在多个monitor中参与领导者leader选举及向集群外客户端提供服务。

2.根据权利要求1所述的方法，其特征在于，所述集群服务系统中包含多个monitor和多个对象存储设备OSD；

其中，所述多个monitor中的leader根据各个monitor分别管理的数据存储信息，生成集群图cluster map，所述cluster map中包含有OSD中数据的存储位置信息，所述集群外客户端使用cluster map进行数据的寻址。

3.根据权利要求1所述的方法，其特征在于，所述监测所述部署有第一monitor的第一节点的运行环境，具体包括：

监测所述部署有第一monitor的第一节点与集群内部署有其它monitor的节点之间的链路状态，以及监测所述第一节点的网卡状态。

4.根据权利要求3所述的方法，其特征在于，监测所述部署有第一monitor的第一节点与集群内部署有其它monitor的节点之间的链路状态，包括：

监测所述第一节点与集群内部署有其它monitor的节点之间的心跳连接是否超时；其中，心跳连接超时是指当发起心跳包后，在预设时长内未收到反馈的心跳包；

若根据监测结果，确定与所述第一节点之间的心跳连接超时的节点的数量达到预设数量、且与任一节点之间心跳连接连续超时的次数达到预设次数，则认为所述链路状态存在异常。

5.根据权利要求3所述的方法，其特征在于，所述监测所述部署有第一monitor的第一节点的网卡状态，包括：

周期性统计所述部署有第一monitor的第一节点中网卡的丢包率；

若所述部署有第一monitor的第一节点的网卡的丢包率超出预设的丢包率阈值，则确定所述网卡状态存在异常。

6.根据权利要求5所述的方法，其特征在于，所述第一节点中设置有主网卡和备用网卡；若所述部署有第一monitor的第一节点的网卡的丢包率超出预设的丢包率阈值，则确定所述网卡状态存在异常，包括：

周期性统计所述主网卡的丢包率；

若所述主网卡的丢包率超出预设的丢包率阈值，则确定所述主网卡存在异常，在所述主网卡停用，启用备用网卡后，周期性统计所述备用网卡的丢包率；

若所述备用网卡的丢包率超出预设的丢包率阈值，则确定所述网卡状态存在异常。

7.根据权利要求1-6任意一项所述的方法，其特征在于，所述方法还包括：

当监测到运行环境中的异常情况结束后，重新启动所述第一monitor，以恢复所述第一monitor参与leader选举及向集群外客户端提供服务的功能。

8.一种选举控制装置，其特征在于，该装置应用于集群服务系统中部署有第一监控进程monitor的第一节点，该装置包括：

异常监测模块，用于监测所述部署有第一monitor的第一节点的运行环境；

异常处理模块，用于当监测到所述运行环境中存在异常情况后，将所述第一monitor关闭，以阻止所述第一monitor在多个monitor中参与领导者leader选举及向集群外客户端提供服务。

9.根据权利要求8所述的装置，其特征在于，所述异常监测模块具体用于：监测所述部署有第一monitor的第一节点与集群内部署有其它monitor的节点之间的链路状态，以及监测所述第一节点的网卡状态。

10.根据权利要求9所述的装置，其特征在于，所述异常监测模块具体用于通过下述步骤监测所述部署有第一monitor的第一节点与集群内部署有其它monitor的节点之间的链路状态：

监测所述第一节点与集群内部署有其它monitor的节点之间的心跳连接是否超时；其中，心跳连接超时是指当发起心跳包后，在预设时长内未收到反馈的心跳包；

若根据监测结果，确定与所述第一节点之间的心跳连接超时的节点的数量达到预设数量、且与任一节点之间心跳连接连续超时的次数达到预设次数，则认为所述链路状态存在异常。

11.根据权利要求9所述的装置，其特征在于，所述异常监测模块具体用于通过下述步骤监测所述部署有第一monitor的第一节点的网卡状态：

周期性统计所述部署有第一monitor的第一节点中网卡的丢包率；

若所述部署有第一monitor的第一节点的网卡的丢包率超出预设的丢包率阈值，则确定所述网卡状态存在异常。

12.根据权利要求11所述的装置，其特征在于，所述第一节点中设置有主网卡和备用网卡；所述异常监测模块，具体用于：

周期性统计所述主网卡的丢包率；

若所述主网卡的丢包率超出预设的丢包率阈值，则确定所述主网卡存在异常，在所述主网卡停用，启用备用网卡后，周期性统计所述备用网卡的丢包率；

若所述备用网卡的丢包率超出预设的丢包率阈值，则确定所述网卡状态存在异常。