CN112732674A - 云平台服务管理方法、装置、设备及可读存储介质 - Google Patents

Abstract

本发明提供一种云平台服务管理方法、装置、设备及可读存储介质。该方法包括：当各个控制节点请求向分布式存储写入本节点对应的唯一标识时，检测分布式存储中是否存在任一控制节点对应的唯一标识；若不存在，则将本节点对应的唯一标识写入所述分布式存储，并指定写入的唯一标识在分布式存储中的生存时长；以所述写入的唯一标识对应的控制节点作为主节点，并开启所述主节点上的主服务；在所述生存时长内持续更新所述生存时长。通过本发明，保证只会选出一个主节点，从而在选出的一个主节点上运行主服务，防止了主备服务脑裂的产生。

Description

云平台服务管理方法、装置、设备及可读存储介质

技术领域

本发明涉及云技术领域，尤其涉及一种云平台服务管理方法、装置、设备及可读存储介质。

背景技术

云计算是目前重要的技术之一，大部分厂商都是基于开源的云平台(如openstack)进行二次开发，但是现有技术中对于云平台可靠性管理方面比较缺乏，尤其是对云平台中主备服务的管理。如何为主备服务提供防脑裂的功能是亟待解决的问题。

发明内容

为保证主备服务不会发生脑裂，本发明提供一种云平台服务管理方法、装置、设备及可读存储介质。

第一方面，本发明提供一种云平台服务管理方法，所述云平台服务管理方法包括：

当各个控制节点请求向分布式存储写入本节点对应的唯一标识时，检测分布式存储中是否存在任一控制节点对应的唯一标识；

若不存在，则将本节点对应的唯一标识写入所述分布式存储，并指定写入的唯一标识在分布式存储中的生存时长；

以所述写入的唯一标识对应的控制节点作为主节点，并开启所述主节点上的主服务；

在所述生存时长内持续更新所述生存时长。

可选的，在所述检测分布式存储中是否存在任一控制节点对应的唯一标识的步骤之后，还包括：

若存在，且所述分布式存储中存在的唯一标识与本节点对应的唯一标识不一致，则以本节点为备节点，并关闭所述备节点上的主服务。

可选的，在所述以所述写入的唯一标识对应的控制节点作为主节点，并开启所述主节点上的主服务的步骤之后，还包括：

当在所述生存时长内未对所述生存时长进行更新时，在分布式存储中删除所述写入的唯一标识，并通知各个备节点重新选主。

可选的，在所述持续更新所述生存时长的步骤之后，还包括：

若所述主服务发生异常，且无法重启所述主服务时，在分布式存储中删除所述写入的唯一标识，通知各个备节点重新选主。

可选的，在所述持续更新所述生存时长的步骤之后，还包括：

当收到基于用户操作触发的主备切换指令时，在分布式存储中删除所述写入的唯一标识，将所述主备切换指令对应的控制节点的唯一标识写入分布式存储。

可选的，所述云平台服务管理方法还包括：

当分布式存储存在异常时，以所有控制节点均为备节点，并关闭每个备节点上的主服务。

可选的，在所述关闭每个备节点上的主服务的步骤之后，还包括：

发送异常通知至运维人员终端。

第二方面，本发明还提供一种云平台服务管理装置，所述云平台服务管理装置包括：

检测模块，用于当各个控制节点请求向分布式存储写入本节点对应的唯一标识时，检测分布式存储中是否存在任一控制节点对应的唯一标识；

写入模块，用于若不存在，则将本节点对应的唯一标识写入所述分布式存储，并指定写入的唯一标识在分布式存储中的生存时长；

开启模块，用于以所述写入的唯一标识对应的控制节点作为主节点，并开启所述主节点上的主服务；

更新模块，用于在所述生存时长内持续更新所述生存时长。

第三方面，本发明还提供一种云平台服务管理设备，所述云平台服务管理设备包括处理器、存储器、以及存储在所述存储器上并可被所述处理器执行的云平台服务管理程序，其中所述云平台服务管理程序被所述处理器执行时，实现如上所述的云平台服务管理方法的步骤。

第四方面，本发明还提供一种可读存储介质，所述可读存储介质上存储有云平台服务管理程序，其中所述云平台服务管理程序被处理器执行时，实现如上所述的云平台服务管理方法的步骤。

本发明中，当各个控制节点请求向分布式存储写入本节点对应的唯一标识时，检测分布式存储中是否存在任一控制节点对应的唯一标识；若不存在，则将本节点对应的唯一标识写入所述分布式存储，并指定写入的唯一标识在分布式存储中的生存时长；以所述写入的唯一标识对应的控制节点作为主节点，并开启所述主节点上的主服务；在所述生存时长内持续更新所述生存时长。通过本发明，保证只会选出一个主节点，从而在选出的一个主节点上运行主服务，防止了主备服务脑裂的产生。

附图说明

图1为本发明实施例方案中涉及的云平台服务管理设备的硬件结构示意图；

图2为本发明云平台服务管理方法一实施例的流程示意图；

图3为一实施例中选主场景示意图；

图4为一实施例中控制节点上的消息处理示意图；

图5为一实施例中云平台的架构示意图；

图6为本发明云平台服务管理装置一实施例的功能模块示意图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

第一方面，本发明实施例提供一种云平台服务管理设备。

参照图1，图1为本发明实施例方案中涉及的云平台服务管理设备的硬件结构示意图。本发明实施例中，云平台服务管理设备可以包括处理器1001(例如中央处理器CentralProcessing Unit，CPU)，通信总线1002，用户接口1003，网络接口1004，存储器1005。其中，通信总线1002用于实现这些组件之间的连接通信；用户接口1003可以包括显示屏(Display)、输入单元比如键盘(Keyboard)；网络接口1004可选的可以包括标准的有线接口、无线接口(如无线保真WIreless-FIdelity，WI-FI接口)；存储器1005可以是高速随机存取存储器(random access memory，RAM)，也可以是稳定的存储器(non-volatile memory)，例如磁盘存储器，存储器1005可选的还可以是独立于前述处理器1001的存储装置。本领域技术人员可以理解，图1中示出的硬件结构并不构成对本发明的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

继续参照图1，图1中作为一种计算机存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及云平台服务管理程序。其中，处理器1001可以调用存储器1005中存储的云平台服务管理程序，并执行本发明实施例提供的云平台服务管理方法。

第二方面，本发明实施例提供了一种云平台服务管理方法。

参照图2，图2为本发明云平台服务管理方法一实施例的流程示意图。如图2所示，一实施例中，云平台服务管理方法包括：

步骤S10，当各个控制节点请求向分布式存储写入本节点对应的唯一标识时，检测分布式存储中是否存在任一控制节点对应的唯一标识；

本实施例中，当需要从多个控制节点中选择主节点以在主节点上运行主服务时，触发选主流程，选主流程触发后，各个控制节点请求向分布式存储写入本节点对应的唯一标识。其中，写入的规则为：只有当分布式存储中不存在任一控制节点的唯一标识时，才能执行写入步骤。因此，当各个控制节点请求向分布式存储写入本节点对应的唯一标识时，需要检测分布式存储中是否存在任一控制节点对应的唯一标识。

步骤S20，若不存在，则将本节点对应的唯一标识写入所述分布式存储，并指定写入的唯一标识在分布式存储中的生存时长；

本实施例中，若一控制节点在请求向分布式存储写入本节点对应的唯一标识时，检测到分布式存储中未存储任一控制节点对应的唯一标识，则将本节点对应的唯一标识写入分布式存储，并指定写入的唯一标识在分布式存储中的生存时长。

进一步地，一实施例中，在步骤S10之后，还包括：

若存在，且所述分布式存储中存在的唯一标识与本节点对应的唯一标识不一致，则以本节点为备节点，并关闭所述备节点上的主服务。

本实施例中，当一控制节点尝试将本节点的唯一标识写入分布式存储时，检测到分布式存储中存在任一控制节点对应的唯一标识，则读取分布式存储中已写入的唯一标识，然后将读取的唯一标识与本节点的唯一标识进行对比，若不一致，则以本节点为备节点，并关闭备节点上的主服务。

步骤S30，以所述写入的唯一标识对应的控制节点作为主节点，并开启所述主节点上的主服务；

本实施例中，当一控制节点成功将本节点的唯一标识写入分布式存储后，便以该控制节点作为主节点，并开启该主节点上的主服务。具体的，当一控制节点成功将本节点的唯一标识写入分布式存储后，会读取写入分布式存储的唯一标识，然后将读取的唯一标识与本节点的唯一标识进行对比，若一致，则以本节点作为主节点，并开启该主节点上的主服务。

步骤S40，在所述生存时长内持续更新所述生存时长。

本实施例中，为了保持一控制节点成为主节点后，能持续维持主节点角色，需要持续更新其唯一标识在分布式存储中的生存时长。例如，首次写入时，生存时长为t0～t1，第一次更新后，生存时长变为t2～t3，再次更新后，生存时长变为t4～t5，其中，t2、t4为更新时的时刻，以此类推。只要更新动作能持续进行，则被选为主节点的控制节点，能持续维持主节点角色。

本实施例中，当各个控制节点请求向分布式存储写入本节点对应的唯一标识时，检测分布式存储中是否存在任一控制节点对应的唯一标识；若不存在，则将本节点对应的唯一标识写入所述分布式存储，并指定写入的唯一标识在分布式存储中的生存时长；以所述写入的唯一标识对应的控制节点作为主节点，并开启所述主节点上的主服务；在所述生存时长内持续更新所述生存时长。通过本实施例，保证只会选出一个主节点，从而在选出的一个主节点上运行主服务，防止了主备服务脑裂的产生。

参照图3，图3为一实施例中选主场景示意图。如图3所示，在控制节点(如三个)上面均部署服务管理Agent(如图3中的Service-agent-keepalive)，这个程序主要负责对部署在控制节点上的主备服务进行控制选主和降备，降备即为将控制节点设置为备节点。主备服务zabbix-server为例。任一控制节点上的Service-agent-keepalive为zabbix-server启动一个线程或者进程，向分布式存储(如etcd，etcd是CoreOS团队于2013年6月发起的开源项目，它的目标是构建一个高可用的分布式键值key-value数据库)写入一个以本节点的唯一标识和zabbix-server字符串组成的key值，写入的key值会同时指定该key值的生存时长(比如5s，如果没有更新操作，该key在5s后会自动删除)。

三个控制节点上的Service-agent-keepalive服务都会尝试写入本节点对应的key值，如果一个控制节点上的Service-agent-keepalive服务写入时发现分布式存储中不存在key值，则将本节点的key值写入，写入成功后，会读取该key值，比较该key值包含的唯一标识与Service-agent-keepalive保存的本节点的唯一标识是否一致，若一致，则会选择本节点为主节点。

如果一控制节点上的Service-agent-keepalive服务尝试写入时，发现分布式存储中存在key值，且该key值包含的唯一标识与Service-agent-keepalive保存的本节点的唯一标识不一致，则该控制节点被选择为备节点。

比如控制节点1被选择为主节点，此时主节点的service-agent-keepalive会将zabbix-server拉起，备节点(控制节点2和3)上的service-agent-keepalive会将zabbix-server关闭。

控制节点1成为主节点后，会在key值的生存时长内不断的更新该key值的生存时长(如每隔3s更新生存时长为5s)，这样控制节点1就会一直保持着主节点的角色，zabbix-server一直在控制节点1上运行。

进一步地，一实施例中，在步骤S30之后，还包括：

当在所述生存时长内未对所述生存时长进行更新时，在分布式存储中删除所述写入的唯一标识，并通知各个备节点重新选主。

本实施例中，以控制节点1为主节点为例，当控制节点1正常时，会持续更新控制节点1的唯一标识在分布式存储中的生存时长。但是，当控制节点1异常，例如下电或网络故障时，会导致无法更新控制节点1的唯一标识在分布式存储中的生存时长，从而导致控制节点1的唯一标识在分布式存储中出现存储超时的情况，出现这种情况时，在分布式存储中删除控制节点1的唯一标识，并通知各个备节点重新选主。即除控制节点1外的其他各个控制节点尝试向分布式存储写入本节点的唯一标识，若控制节点x成功写入后，便以控制节点x作为主节点，并在主节点上运行主服务。以除控制节点x外的其他控制节点作为备节点。

通过本实施例，保证了主节点异常时，能够重新选择主节点，保证主服务能正常运行。

进一步地，一实施例中，在步骤S40之后，还包括：

若所述主服务发生异常，且无法重启所述主服务时，在分布式存储中删除所述写入的唯一标识，通知各个备节点重新选主。

本实施例中，当主节点正常，但是主服务异常(进程异常或者僵死)时，首先对主服务进行重启，若无法重启，则说明主服务无法在当前的主节点上运行。这时，在分布式存储中删除当前主节点的唯一标识，并通知各个备节点重新选主。各个备节点重新选主的具体实施例在此不再赘述。

具体的，一实施例中，在控制节点(如三个)上面均部署服务管理Agent(如图3中的Service-agent-keepalive)，这个程序主要负责对部署在控制节点上的主备服务进行控制选主和降备，主备服务zabbix-server为例。若已选择控制节点1为主节点，在控制节点1正常的情况下，控制节点1上运行的zabbix-server本身出现异常(进程异常或者僵死)，则service-agent-keepalive进程会尝试拉起zabbix-server服务N次(可配置)，如果经过N次，还是无法拉起zabbix-server服务，则该控制节点1上的service-agent-keepalive主动释放分布式存储上的key值，这样会触发其他控制节点重新选主并启动zabbix-server服务，保证与zabbix-server服务相关的业务能够及时恢复。

进一步地，一实施例中，在步骤S40之后，还包括：

当收到基于用户操作触发的主备切换指令时，在分布式存储中删除所述写入的唯一标识，将所述主备切换指令对应的控制节点的唯一标识写入分布式存储。

本实施例中，提供对外API接口。当用户需要更换当前自动选择的主节点时，通过操作触发主备切换指令，基于该对外API接口，云平台服务管理方法的执行主体收到基于用户操作触发的主备切换指令，然后分布式存储中删除当前已写入的唯一标识，并将主备切换指令对应的控制节点的唯一标识写入分布式存储。后续，主备切换指令对应的控制节点检测到分布式存储中的唯一标识与本节点的唯一标识一致，则该控制节点成为主节点，并运行主服务。

通过本实施例，可基于用户意愿，以用户确定的控制节点作为主节点，使得能更好地对云平台上的主备服务进行维护。

进一步地，一实施例中，所述云平台服务管理方法还包括：

当分布式存储存在异常时，以所有控制节点均为备节点，并关闭每个备节点上的主服务。

本实施例中，当分布式存储存在异常时，例如分布式存储的读写功能出现异常，此时各个控制节点无法将本节点的唯一标识写入分布式存储，也无法从分布式存储读取已写入的唯一标识，会导致无法选出主节点，则以所有控制节点均为备节点，并关闭每个备节点上的主服务。

进一步地，一实施例中，在所述关闭每个备节点上的主服务的步骤之后，还包括：

发送异常通知至运维人员终端。

本实施例中，在无法选出主节点时，会导致主服务无法运行，为了保证与主服务相关的业务及时恢复，需要发送异常通知至运维人员终端，以供运维人员及时对问题进行修复。

进一步地，一实施例中，为了保证各个控制节点上各服务的可靠性，还需对控制节点上的消息处理流程做如下设计：

Service-api和Service-conductor在三个(此处仅为示意性说明，并不限制于三个)控制节点上均部署，组成一个可用的集群，三个节点上的Service-api和Service-conductor是无状态的，可以随时同时对外提供服务，在前端通过负载均衡代理软件(如haproxy，Nginx，Lvs等)，后者自己实现的软件来配置策略(如轮训,随机，哈希等)来减轻一个节点上压力，保证服务的可靠性。Service-api和Service-conductor之间通过rpc调用，如消息队列(rabbitmq等)，这样Service-api收到的消息也会被多个Service-conductor处理，减轻了后端的压力。同时消息可以在消息队列中缓存，因此保证了消息不会因为异常而丢失。Service-conductor也通过rpc调用Service-agent-keepalive和Service-agent-watchdog，一方面能够缓存消息处理，保证消息不会丢失，增加了消息处理的可靠性。对于Service-api和Service-conductor服务，可以通过Service-agent-watchdog监控来保证服务的可靠性，在这两个服务异常或者僵死的场景下，进行重启恢复。对于Service-agent-watchdog和Service-agent-keepalive的可靠性，可以通过周期性检测任务来实现，如在crontab中增加一个周期执行的任务，来检测这两个服务的状态，如果服务异常，则会将两个服务拉起。参照图4，图4为一实施例中控制节点上的消息处理示意图。

进一步地，一实施例中，对于非主备服务，由Service-agent-watchdog来保证其可靠性，主要步骤如下：

首先Service-agent-watchdog会对需要监控的服务(如nova-api)启动一个监控线程或者进程，该监控线程会周期性执行检测。通过调用系统命令(如systemctl等)来查看该服务(如nova-api)的状态，会检测进程是否是正常的，如果进程正常，则会检测进程内部是否发生僵死，如果二者存在其一，则将进入恢复进程的流程。具体为：对服务进行重启恢复，重启之前发送进程异常告警，告知用户此时服务已经异常，然后调用系统命令(如systemctl等)重启服务，如果重启一次后没有恢复，则继续重启恢复，最多重启N(N>＝1，可以配置)次，如果重启N次还未恢复，则根据配置的策略(如重启节点)进行恢复，如果服务已经恢复，则清理之前的告警。

上述实施例中的控制节点为云平台的一部分，参照图5，图5为一实施例中云平台的架构示意图。如图5所示：

Service-api：对外提供API服务，查询服务的状态，启动，停止，重启，主备服务切换等，尤其是主动的主备服务切换，可以主动将主服务切换到其他节点，来维护当前的节点。

Service-conductor：提供数据层服务，数据库的读写和周期性任务的执行，提供对主备服务的异常场景(无主等)的告警机制呈现给用户。让用户及时了解系统的状态。

Service-agent-keeplive：对主备服务提供高可靠机制，主备切换，并能够对服务进行僵死检，通过检测服务的心跳文件或者调用服务的查询接口(如获取版本号)来检测服务是否僵死并恢复。

Service-agent-watchdog：对非主备的服务提供高可靠机制，并进行僵死检测。上报所有服务的状态给Service-conductor写入到数据库中，呈现给用户。

组件之间采用解耦的RPC调用，如rabbitmq，grpc等，上报心跳和服务的状态，其中心跳可以检测agent的异常从而保证上报的服务状态是可信的。

主备服务采用共享存储设备，可以是自行实现的，也可以是开源的软件如(etcd，zookeeper等)，通过写入一个该节点的唯一标识来保证主备服务不会出现多主，避免了脑裂的产生。

第三方面，本发明实施例还提供一种云平台服务管理装置。

参照图6，图6为本发明云平台服务管理装置一实施例的功能模块示意图。如图6所示，云平台服务管理装置包括：

检测模块10，用于当各个控制节点请求向分布式存储写入本节点对应的唯一标识时，检测分布式存储中是否存在任一控制节点对应的唯一标识；

写入模块20，用于若不存在，则将本节点对应的唯一标识写入所述分布式存储，并指定写入的唯一标识在分布式存储中的生存时长；

开启模块30，用于以所述写入的唯一标识对应的控制节点作为主节点，并开启所述主节点上的主服务；

更新模块40，用于在所述生存时长内持续更新所述生存时长。

进一步地，一实施例中，云平台服务管理装置还包括关闭模块，用于：

若存在，且所述分布式存储中存在的唯一标识与本节点对应的唯一标识不一致，则以本节点为备节点，并关闭所述备节点上的主服务。

进一步地，一实施例中，云平台服务管理装置还包括通知模块，用于：

当在所述生存时长内未对所述生存时长进行更新时，在分布式存储中删除所述写入的唯一标识，并通知各个备节点重新选主。

进一步地，一实施例中，通知模块，用于：

若所述主服务发生异常，且无法重启所述主服务时，在分布式存储中删除所述写入的唯一标识，通知各个备节点重新选主。

进一步地，一实施例中，云平台服务管理装置还包括主动写入模块，用于：

当收到基于用户操作触发的主备切换指令时，在分布式存储中删除所述写入的唯一标识，将所述主备切换指令对应的控制节点的唯一标识写入分布式存储。

进一步地，一实施例中，关闭模块，用于：

当分布式存储存在异常时，以所有控制节点均为备节点，并关闭每个备节点上的主服务。

进一步地，一实施例中，通知模块，用于：

发送异常通知至运维人员终端。

其中，上述云平台服务管理装置中各个模块的功能实现与上述云平台服务管理方法实施例中各步骤相对应，其功能和实现过程在此处不再一一赘述。

第四方面，本发明实施例还提供一种可读存储介质。

本发明可读存储介质上存储有云平台服务管理程序，其中所述云平台服务管理程序被处理器执行时，实现如上述的云平台服务管理方法的步骤。

其中，云平台服务管理程序被执行时所实现的方法可参照本发明云平台服务管理方法的各个实施例，此处不再赘述。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者系统中还存在另外的相同要素。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在如上所述的一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备执行本发明各个实施例所述的方法。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (10)

1.一种云平台服务管理方法，其特征在于，所述云平台服务管理方法包括：

当各个控制节点请求向分布式存储写入本节点对应的唯一标识时，检测分布式存储中是否存在任一控制节点对应的唯一标识；

若不存在，则将本节点对应的唯一标识写入所述分布式存储，并指定写入的唯一标识在分布式存储中的生存时长；

以所述写入的唯一标识对应的控制节点作为主节点，并开启所述主节点上的主服务；

在所述生存时长内持续更新所述生存时长。

2.如权利要求1所述的云平台服务管理方法，其特征在于，在所述检测分布式存储中是否存在任一控制节点对应的唯一标识的步骤之后，还包括：

若存在，且所述分布式存储中存在的唯一标识与本节点对应的唯一标识不一致，则以本节点为备节点，并关闭所述备节点上的主服务。

3.如权利要求2所述的云平台服务管理方法，其特征在于，在所述以所述写入的唯一标识对应的控制节点作为主节点，并开启所述主节点上的主服务的步骤之后，还包括：

当在所述生存时长内未对所述生存时长进行更新时，在分布式存储中删除所述写入的唯一标识，并通知各个备节点重新选主。

4.如权利要求2所述的云平台服务管理方法，其特征在于，在所述持续更新所述生存时长的步骤之后，还包括：

若所述主服务发生异常，且无法重启所述主服务时，在分布式存储中删除所述写入的唯一标识，通知各个备节点重新选主。

5.如权利要求1所述的云平台服务管理方法，其特征在于，在所述持续更新所述生存时长的步骤之后，还包括：

当收到基于用户操作触发的主备切换指令时，在分布式存储中删除所述写入的唯一标识，将所述主备切换指令对应的控制节点的唯一标识写入分布式存储。

6.如权利要求1-5中任一项所述的云平台服务管理方法，其特征在于，所述云平台服务管理方法还包括：

当分布式存储存在异常时，以所有控制节点均为备节点，并关闭每个备节点上的主服务。

7.如权利要求6所述的云平台服务管理方法，其特征在于，在所述关闭每个备节点上的主服务的步骤之后，还包括：

发送异常通知至运维人员终端。

8.一种云平台服务管理装置，其特征在于，所述云平台服务管理装置包括：

检测模块，用于当各个控制节点请求向分布式存储写入本节点对应的唯一标识时，检测分布式存储中是否存在任一控制节点对应的唯一标识；

写入模块，用于若不存在，则将本节点对应的唯一标识写入所述分布式存储，并指定写入的唯一标识在分布式存储中的生存时长；

开启模块，用于以所述写入的唯一标识对应的控制节点作为主节点，并开启所述主节点上的主服务；

更新模块，用于在所述生存时长内持续更新所述生存时长。

9.一种云平台服务管理设备，其特征在于，所述云平台服务管理设备包括处理器、存储器、以及存储在所述存储器上并可被所述处理器执行的云平台服务管理程序，其中所述云平台服务管理程序被所述处理器执行时，实现如权利要求1至7中任一项所述的云平台服务管理方法的步骤。

10.一种可读存储介质，其特征在于，所述可读存储介质上存储有云平台服务管理程序，其中所述云平台服务管理程序被处理器执行时，实现如权利要求1至7中任一项所述的云平台服务管理方法的步骤。

Images