CN112416641B - 主从架构中被控端节点重启检测方法及主控端节点 - Google Patents

Abstract

本申请实施例提供一种主从架构中被控端节点重启检测方法及主控端节点，可用于云计算技术领域，方法包括：若调度执行到已解析的编排任务中的针对目标主从架构中的被控端节点重启请求，则将该被控端节点距离当前时间最近的重启时间作为历史重启时间；向被控端节点发送重启指令以使该被控端节点开始执行该重启指令；判断自身与被控端节点的当前连接状态是否正常，若是则再次将被控端节点距离当前时间最近的重启时间作为目标重启时间；根据目标重启时间和历史重启时间确定被控端节点当前是否已重启，若是则调度执行编排任务中的后续指令。本申请能够在主从架构下脚本编排调度涉及节点重启场景时，有效提高主动检测被控端节点的重启状态的准确性。

Description

主从架构中被控端节点重启检测方法及主控端节点

技术领域

本申请涉及数据处理技术领域，特别涉及云计算及运维自动化技术领域，具体涉及主从架构中被控端节点重启检测方法及主控端节点。

背景技术

在大型企业和数据中心运维场景下，海量服务器的配置或变更操作非常频繁，一次运维变更可能涉及多个运维操作(命令或脚本)进行编排，且操作间又可能存在依赖，必须依赖自动化运维工具来完成。但对于编排中前序依赖操作(命令或脚本)需要重启生效的情况，目前运维工具的编排机制往往不能很好的发挥效果。

业界开源或企业自主研发的自动化运维工具主要有无代理模式和有代理模式两类，其中无代理模式主要是运维相对简单，依赖安全外壳SSH协议，响应速度较慢，支持并发数较小，不支持目标执行节点的重启状态判断，通常只能依赖用户拆分任务来避免重启依赖，因此，需要应用有一定运维成本的代理模式来替代。代理模式基于私有协议或MQ消息队列，响应速度较快，支持大规模并发场景，但在节点重启期间，被控端节点与主控端节点断联导致编排任务执行状态未知，当前一般有两种方式解决：一种是在任务编排时增加指令执行结果的判断避免重复执行，然后通过多次重试执行任务编排直至成功或超时的方式规避；另一种是主控端节点端轮询检查等待被控端节点是否恢复连接，然后判断命令脚本执行成功后执行编排后续动作。前一种方式需要多次执行同一个编排任务，执行次数与编排中重启次数有关，且强依赖指令执行状态检查，不具备普适性，且执行效率不高；另一种则依赖经验等待时间设置来规避，并不能确保服务器是否真的已经重启，存在误调度的可能，且单纯从工具层面检测脚本命令在重启前执行是否成功也有难度。

因此，继续设计一直能够在编排调度流程中准确检测被控端所在节点重启状态的方法，以支撑运维编排流程中节点重启的需求场景。

发明内容

针对现有技术中的问题，本申请提供一种主从架构中被控端节点重启检测方法及主控端节点，能够在主从架构下脚本编排调度涉及节点重启场景时，有效提高主动检测被控端节点的重启状态的准确性，且能够有效提高被控端节点的重启状态的检测效率，进而能够有效保证主从架构在运维场景下的运行可靠性及高效性。

为解决上述技术问题，本申请提供以下技术方案：

第一方面，本申请提供一种主从架构中被控端节点重启检测方法，包括：

若调度执行到已解析的编排任务中的针对目标主从架构中的被控端节点重启请求，则将该被控端节点距离当前时间最近的重启时间作为历史重启时间；

向所述被控端节点发送重启指令以使该被控端节点开始执行该重启指令；

判断自身与所述被控端节点的当前连接状态是否正常，若是，则再次将被控端节点距离当前时间最近的重启时间作为目标重启时间；

根据所述目标重启时间和历史重启时间确定所述被控端节点当前是否已重启，若是，则调度执行所述编排任务中的后续指令。

进一步地，在所述若调度执行到已解析的编排任务中的针对目标主从架构中的被控端节点重启请求，则将该被控端节点距离当前时间最近的重启时间作为历史重启时间之前，还包括：

在预设的编排调度运维自动化工具的内置功能单元中获取节点重启公共原子操作指令，其中，所述节点重启公共原子操作指令的调用执行方式包括引用原子操作、API接口和脚本变量置换中的至少一项；

解析当前的编排任务，并调度执行该编排任务中的各个指令；

在调度执行到所述编排任务中的针对目标主从架构中的被控端节点重启请求之时或之后，启动所述节点重启公共原子操作指令。

该技术方案的有益效果在于：通过编排调度运维自动化工具的内置功能单元的预先设置，能够有效提高被控端节点重启及重启状态检测的自动化程度，进而能够有效保证主从架构在运维场景下的自动化程度，同时，通过所述节点重启公共原子操作指令的调用执行方式包括引用原子操作、API接口和脚本变量置换中的至少一项的设置，通过提供包括编排原子操作、API接口和脚本变量置换等多种形态封装的内置能力，实现开箱即用的效果，满多种运维编排场景的需求。

进一步地，所述若调度执行到已解析的编排任务中的针对目标主从架构中的被控端节点重启请求，则将该被控端节点距离当前时间最近的重启时间作为历史重启时间，包括：

若调度执行到已解析的编排任务中的针对目标主从架构中的被控端节点重启请求，则向该被控端节点发送最近重启时间查询指令；

接收所述被控端节点根据所述最近重启时间查询指令发送的距离当前时间最近的重启时间，并将该重启时间本地存储为所述被控端节点的历史重启时间。

该技术方案的有益效果在于：能够在主从架构下脚本编排调度涉及节点重启场景时，主动检测被控端节点的重启状态，进而能够进一步提高被控端节点的重启状态检测的效率。

进一步地，所述判断自身与所述被控端节点的当前连接状态是否正常，若是，则再次将被控端节点距离当前时间最近的重启时间作为目标重启时间，包括：

若在向所述被控端节点发送重启指令后已等待第一时间，则检测自身与所述被控端节点的当前连接状态是否正常，若是，则执行目标重启时间获取步骤；

所述目标重启时间获取步骤包括：再次向该被控端节点发送最近重启时间查询指令；接收所述被控端节点根据所述最近重启时间查询指令发送的距离当前时间最近的重启时间，并将该重启时间本地存储为所述被控端节点的目标重启时间。

该技术方案的有益效果在于：通过等待第一时间后检测连接状态以及目标重启时间获取步骤的设置，能够进一步提高获取目标重启时间的准确性及可靠性。

进一步地，根据所述目标重启时间和历史重启时间确定所述被控端节点当前是否已重启，若是，则调度执行所述编排任务中的后续指令，包括：

判断所述目标重启时间是否晚于所述历史重启时间；

若是，则确定所述被控端节点已重启，并调度执行所述编排任务中的后续指令。

该技术方案的有益效果在于：通过时间点的判断，能够有效简化被控端节点当前是否已重启的判断过程，进而能够有效节省检测成本并进一步提高被控端节点的重启状态检测的效率。

进一步地，还包括：

若经检测获知自身与所述被控端节点的当前连接状态非正常，则执行轮询步骤；

其中，所述轮询步骤包括：基于所述编排任务对应的轮询间隔，轮询自身与所述被控端节点的当前连接状态是否正常，直至检测到自身与所述被控端节点的当前连接状态正常或者轮询总耗时已达到预设的重启超时时间后，停止轮询；若经检测获知自身与所述被控端节点的当前连接状态正常，则执行所述目标重启时间获取步骤。

该技术方案的有益效果在于：通过经检测获知自身与所述被控端节点的当前连接状态非正常后执行轮询步骤的设置，能够有效提高被控端节点的重启状态检测的智能化程度及可靠性。

进一步地，还包括：

若经判断获知所述目标重启时间等于所述历史重启时间，则执行所述轮询步骤。

该技术方案的有益效果在于：通过经判断获知所述目标重启时间等于所述历史重启时间后执行轮询步骤的设置，能够进一步提高被控端节点的重启状态检测的智能化程度及可靠性。

第二方面，本申请提供一种主控端节点，包括：

历史时间获取模块，用于若调度执行到已解析的编排任务中的针对目标主从架构中的被控端节点重启请求，则将该被控端节点距离当前时间最近的重启时间作为历史重启时间；

重启指令发送模块，用于向所述被控端节点发送重启指令以使该被控端节点开始执行该重启指令；

目标时间获取模块，用于判断自身与所述被控端节点的当前连接状态是否正常，若是，则再次将被控端节点距离当前时间最近的重启时间作为目标重启时间；

重启判断模块，用于根据所述目标重启时间和历史重启时间确定所述被控端节点当前是否已重启，若是，则调度执行所述编排任务中的后续指令。

第三方面，本申请提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现所述的主从架构中被控端节点重启检测方法。

第四方面，本申请提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现所述的主从架构中被控端节点重启检测方法。

由上述技术方案可知，本申请提供的一种主从架构中被控端节点重启检测方法及主控端节点，方法通过若调度执行到已解析的编排任务中的针对目标主从架构中的被控端节点重启请求，则将该被控端节点距离当前时间最近的重启时间作为历史重启时间；向所述被控端节点发送重启指令以使该被控端节点开始执行该重启指令；判断自身与所述被控端节点的当前连接状态是否正常，若是，则再次将被控端节点距离当前时间最近的重启时间作为目标重启时间；根据所述目标重启时间和历史重启时间确定所述被控端节点当前是否已重启，若是，则调度执行所述编排任务中的后续指令的设置，能够在主从架构下脚本编排调度涉及节点重启场景时，有效提高主动检测被控端节点的重启状态的准确性，且能够有效提高被控端节点的重启状态的检测效率，有效提高被控端节点重启及重启状态检测的自动化程度，进而能够有效保证主从架构在运维场景下的运行可靠性、高效性及自动化程度。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例中的主从架构的结构示意图。

图2是本申请实施例中的主从架构中被控端节点重启检测方法的第一种流程示意图。

图3是本申请实施例中的主从架构中被控端节点重启检测方法中步骤010至步骤030的流程示意图。

图4是本申请实施例中的主从架构中被控端节点重启检测方法中步骤100的具体流程示意图。

图5是本申请实施例中的主从架构中被控端节点重启检测方法中步骤300的第一种流程示意图。

图6是本申请实施例中的主从架构中被控端节点重启检测方法中步骤400的第一种流程示意图。

图7是本申请实施例中的主从架构中被控端节点重启检测方法中步骤300的第二种流程示意图。

图8是本申请实施例中的主从架构中被控端节点重启检测方法中步骤400的第二种流程示意图。

图9是本申请应用实例中的主从架构中被控端节点重启检测方法的逻辑流程示意图。

图10是本申请实施例中的主控端节点的结构示意图。

图11是本申请实施例中的电子设备的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整的描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

需要说明的是，本申请公开的主从架构中被控端节点重启检测方法和装置可用于云计算及运维自动化技术领域，也可用于除云计算及运维自动化之外的任意领域，本申请公开的主从架构中被控端节点重启检测方法和装置的应用领域不做限定。

考虑到现有的有代理模式的主从架构自动化运维编排工具在执行涉及被控端重启操作的任务时无法准确判断重启状态，导致任务调度失败的问题，本申请分别提供一种主从架构中被控端节点重启检测方法、主控端节点、电子设备和计算机可读存储介质的实施例，通过若调度执行到已解析的编排任务中的针对目标主从架构中的被控端节点重启请求，则将该被控端节点距离当前时间最近的重启时间作为历史重启时间；向所述被控端节点发送重启指令以使该被控端节点开始执行该重启指令；判断自身与所述被控端节点的当前连接状态是否正常，若是，则再次将被控端节点距离当前时间最近的重启时间作为目标重启时间；根据所述目标重启时间和历史重启时间确定所述被控端节点当前是否已重启，若是，则调度执行所述编排任务中的后续指令的设置，能够在主从架构下脚本编排调度涉及节点重启场景时，有效提高主动检测被控端节点的重启状态的准确性，且能够有效提高被控端节点的重启状态的检测效率，有效提高被控端节点重启及重启状态检测的自动化程度，进而能够有效保证主从架构在运维场景下的运行可靠性、高效性及自动化程度，也有效提高运维人员的用户体验。

基于上述内容，在本申请实施例中的主从架构中，包含有用于实现本申请一个或多个实施例中提供的主从架构中被控端节点重启检测方法的主控端节点Master，参见图1，该主控端节点Master与被控端节点Agent之间设有MQ消息队列。

可以理解的是，所述主控端节点Master和被控端节点Agent均可以为服务器。进行主从架构中被控端节点重启检测的部分可以在如上述内容所述的主控端节点Master所在服务器节点执行。

在另一实际应用情形中，进行主从架构中被控端节点重启检测的部分可以在如上述内容所述的主控端节点Master所在服务器节点执行，也可以所有的操作都在客户端设备中完成。具体可以根据所述客户端设备的处理能力，以及用户使用场景的限制等进行选择。本申请对此不作限定。若所有的操作都在所述客户端设备中完成，所述客户端设备还可以包括处理器，用于进行主从架构中被控端节点重启检测的具体处理。

可以理解的是，客户端设备可以包括智能手机、平板电子设备、网络机顶盒、便携式计算机、台式电脑、个人数字助理(PDA)、车载设备、智能穿戴设备等。其中，所述智能穿戴设备可以包括智能眼镜、智能手表、智能手环等。

上述的客户端设备可以具有通信模块(即通信单元)，可以与远程的服务器进行通信连接，实现与所述服务器的数据传输。通信单元还可以接收服务器返回的预测结果。所述服务器可以包括任务调度中心一侧的服务器，其他的实施场景中也可以包括中间系统的服务器，例如与任务调度中心服务器有通信链接的第三方服务器系统的服务器。所述的服务器可以包括单台计算机设备，也可以包括多个服务器组成的服务器集群，或者分布式装置的服务器结构。

上述服务器与所述客户端设备之间可以使用任何合适的网络协议进行通信，包括在本申请提交日尚未开发出的网络协议。所述网络协议例如可以包括TCP/IP协议、UDP/IP协议、HTTP协议、HTTPS协议等。当然，所述网络协议例如还可以包括在上述协议之上使用的RPC协议(Remote Procedure Call Protocol，远程过程调用协议)、REST协议(Representational State Transfer，表述性状态转移协议)等。

在本申请的一个或多个实施例中，本申请能够解决海量服务器自动化运维场景下，基于主从架构的脚本编排调度工具在被控端执行编排作业过程中需要重启影响任务执行连续性的问题，支持主从架构下脚本编排调度涉及节点重启场景时，被控端重启及Agent恢复状态的准确判断；基于准确的节点重启及Agent恢复连接状态判断，更新任务状态(成功、失败、超时等)并准确调度执行任务后续指令。

具体通过下述各个实施例及应用实例分别进行详细说明。

为了解决海量服务器自动化运维场景下，基于主从架构的脚本编排调度工具在被控端执行编排作业过程中需要重启影响任务执行连续性的问题，本申请提供一种主从架构中被控端节点重启检测方法的实施例，参见图2，所述主从架构中被控端节点重启检测方法具体包含有如下内容：

步骤100：若调度执行到已解析的编排任务中的针对目标主从架构中的被控端节点重启请求，则将该被控端节点距离当前时间最近的重启时间作为历史重启时间。

可以理解的是，所述编排任务为预先接收并解析后的编排作业，其中包含有多种运维任务，被控端节点重启请求为其中的一个运维任务，且在该被控端节点重启请求对应的任务之后，还需要调度执行其他的运维任务。

步骤200：向所述被控端节点发送重启指令以使该被控端节点开始执行该重启指令。

步骤300：判断自身与所述被控端节点的当前连接状态是否正常，若是，则再次将被控端节点距离当前时间最近的重启时间作为目标重启时间。

步骤400：根据所述目标重启时间和历史重启时间确定所述被控端节点当前是否已重启，若是，则调度执行所述编排任务中的后续指令。

从上述描述可知，本申请实施例提供的主从架构中被控端节点重启检测方法，能够在主从架构下脚本编排调度涉及节点重启场景时，有效提高主动检测被控端节点的重启状态的准确性，且能够有效提高被控端节点的重启状态的检测效率，有效提高被控端节点重启及重启状态检测的自动化程度，进而能够有效保证主从架构在运维场景下的运行可靠性、高效性及自动化程度。

为了满多种运维编排场景的需求，在本申请提供的主从架构中被控端节点重启检测方法的一个实施例中，参见图3，所述主从架构中被控端节点重启检测方法中的步骤100之前还具体包含有如下内容：

步骤010：在预设的编排调度运维自动化工具的内置功能单元中获取节点重启公共原子操作指令，其中，所述节点重启公共原子操作指令的调用执行方式包括引用原子操作、API接口和脚本变量置换中的至少一项。

步骤020：解析当前的编排任务，并调度执行该编排任务中的各个指令。

步骤030：在调度执行到所述编排任务中的针对目标主从架构中的被控端节点重启请求之时或之后，启动所述节点重启公共原子操作指令。

可以理解的是，上述重启reboot公共原子操作(指令)可封装为编排调度运维自动化工具的多种内置能力供用户使用，主要包括：

1.原子操作(指令)：两个运维操作(或脚本)之间涉及重启的场景，可在编排流程中直接引用重启reboot原子操作，运维操作(或脚本)自身不应包含重启被控端的命令；

2.API接口：针对单个运维操作涉及多节点有序重启等复杂场景(通常为编写程序实现)，编排流程不便于拆分时，可以调用API完成控制端重启的动作；

3.脚本变量置换：针对单个运维操作涉及多节点有序重启等复杂场景(通常为脚本实现)，编排流程不便于拆分时，可以通过引用内置变量(即内置指令)的方式替代系统侧的命令完成重启操作，例如：

$#{重启reboot:ip,first_wait_time,loop_interval,time_out}。

从上述描述可知，本申请实施例提供的主从架构中被控端节点重启检测方法，通过编排调度运维自动化工具的内置功能单元的预先设置，能够有效提高被控端节点重启及重启状态检测的自动化程度，进而能够有效保证主从架构在运维场景下的自动化程度，同时，通过所述节点重启公共原子操作指令的调用执行方式包括引用原子操作、API接口和脚本变量置换中的至少一项的设置，通过提供包括编排原子操作、API接口和脚本变量置换等多种形态封装的内置能力，实现开箱即用的效果，满多种运维编排场景的需求。

为了进一步提高被控端节点的重启状态检测的效率，在本申请提供的主从架构中被控端节点重启检测方法的一个实施例中，参见图4，在所述主从架构中被控端节点重启检测方法中的步骤100具体包含有如下内容：

步骤110：若调度执行到已解析的编排任务中的针对目标主从架构中的被控端节点重启请求，则向该被控端节点发送最近重启时间查询指令；

步骤120：接收所述被控端节点根据所述最近重启时间查询指令发送的距离当前时间最近的重启时间，并将该重启时间本地存储为所述被控端节点的历史重启时间。

从上述描述可知，本申请实施例提供的主从架构中被控端节点重启检测方法，能够在主从架构下脚本编排调度涉及节点重启场景时，主动检测被控端节点的重启状态，进而能够进一步提高被控端节点的重启状态检测的效率。

为了进一步提高被控端节点的重启状态检测的效率，在本申请提供的主从架构中被控端节点重启检测方法的一个实施例中，参见图5，在所述主从架构中被控端节点重启检测方法中的步骤300具体包含有如下内容：

步骤310：若在向所述被控端节点发送重启指令后已等待第一时间，则检测自身与所述被控端节点的当前连接状态是否正常，若是，则执行目标重启时间获取步骤。

其中，所述目标重启时间获取步骤包括：

步骤320：再次向该被控端节点发送最近重启时间查询指令。

步骤330：接收所述被控端节点根据所述最近重启时间查询指令发送的距离当前时间最近的重启时间，并将该重启时间本地存储为所述被控端节点的目标重启时间。

从上述描述可知，本申请实施例提供的主从架构中被控端节点重启检测方法，通过等待第一时间后检测连接状态以及目标重启时间获取步骤的设置，能够进一步提高获取目标重启时间的准确性及可靠性。

为了进一步提高被控端节点的重启状态检测的效率，在本申请提供的主从架构中被控端节点重启检测方法的一个实施例中，参见图6，在所述主从架构中被控端节点重启检测方法中的步骤400具体包含有如下内容：

步骤410：判断所述目标重启时间是否晚于所述历史重启时间；若是，则执行步骤420；

步骤420：确定所述被控端节点已重启，并调度执行所述编排任务中的后续指令；

从上述描述可知，本申请实施例提供的主从架构中被控端节点重启检测方法，通过时间点的判断，能够有效简化被控端节点当前是否已重启的判断过程，进而能够有效节省检测成本并进一步提高被控端节点的重启状态检测的效率。

为了提高被控端节点的重启状态检测的智能化程度及可靠性，在本申请提供的主从架构中被控端节点重启检测方法的一个实施例中，参见图7，在所述主从架构中被控端节点重启检测方法中的步骤310之后还具体包含有如下内容：

若经步骤310判断获知自身与所述被控端节点的当前连接状态非正常，则执行轮询步骤；

其中的轮询步骤包括：

步骤340：基于所述编排任务对应的轮询间隔，轮询自身与所述被控端节点的当前连接状态是否正常，若是，即经检测获知自身与所述被控端节点的当前连接状态正常，则执行所述目标重启时间获取步骤：步骤320和步骤330。若否，则执行该步骤340，直至检测到自身与所述被控端节点的当前连接状态正常或者轮询总耗时已达到预设的重启超时时间后，停止轮询。

从上述描述可知，本申请实施例提供的主从架构中被控端节点重启检测方法，通过经检测获知自身与所述被控端节点的当前连接状态非正常后执行轮询步骤的设置，能够有效提高被控端节点的重启状态检测的智能化程度及可靠性。

为了进一步提高被控端节点的重启状态检测的智能化程度及可靠性，在本申请提供的主从架构中被控端节点重启检测方法的一个实施例中，参见图8，在所述主从架构中被控端节点重启检测方法中的步骤410之后还具体包含有如下内容：

若经步骤410判断获知所述目标重启时间等于所述历史重启时间，即所述目标重启时间不晚于所述历史重启时间，则执行所述轮询步骤：步骤340。

从上述描述可知，本申请实施例提供的主从架构中被控端节点重启检测方法，通过经判断获知所述目标重启时间等于所述历史重启时间后执行轮询步骤的设置，能够进一步提高被控端节点的重启状态检测的智能化程度及可靠性。

为了进一步说明本方案，本申请还提供一种主从架构中被控端节点重启检测方法的具体应用实例，参见图9，主从架构中被控端节点重启检测方法是一种主从架构下脚本编排调度涉及节点重启场景时保证任务连续性的方法，提供重启被控端的公共指令供编排引用，避免脚本中重启后执行结果无法感知的问题，实现被控端重启后Agent恢复状态的准确判断，从而保证编排任务状态的准确获取和任务正常调度。

实现本应用实例的基本系统由主控节点Master、被控端节点Agent以及配套的数据库组成，对于大规模服务器的管控场景，通常还需配套部署MQ集群，用于管理主控端节点Master和被控端节点Agent之间的加密消息通信。基于上述架构，将在被控端执行的简单重启reboot命令，扩展为主控端调度的重启reboot复合指令集，并且封装为公共原子操作(指令)供编排引用，方便用户使用。

为了实现前述目标，扩展封装后的重启reboot公共原子操作(指令)主要实现流程如下：

1.工具解析编排任务后开始调度，执行到重启reboot请求后，主控端节点Master先给被控端节点Agent下发查询系统上次重启reboot时间的指令；

2.被控端节点Agent查询系统上次重启reboot时间，后将结果返回给主控端节点Master；

3.主控端节点Master记录反馈的查询结果后，下发重启reboot指令给被控端节点Agent执行，被控端节点Agent收到后开始执行；

4.主控端节点Master等待若干时间后(可配置，与服务器重启速度有关，避免无效的轮询，默认30s)，根据编排作业指定的轮询间隔(可配置，默认5s)检查Agent和Master连接状态是否正常(或恢复)，如果正常则再次给被控端节点Agent下发查询系统上次重启reboot时间指令；

5.被控端节点Agent再次查询系统上次重启reboot时间，后将结果返回给主控端节点Master；

6.主控端节点Master收到后将本次查询得到的上次重启reboot时间与任务初始记录的重启reboot时间进行比较，如相同说明还没有重启，等待下一个轮询(可配置，默认5s)继续检查Agent和Master连接状态；如果晚于初始记录值则认为被控端重启后已恢复，可以调度编排作业中后续指令；

7.如果轮询检查Agent和Master连接异常，则等待下一个轮询间隔继续检查，最长不超过任务指定的重启超时时间(可配置，默认5min)。

上述重启reboot公共原子操作(指令)可封装为编排调度运维自动化工具的多种内置能力供用户使用，主要包括：

1.原子操作(指令)：两个运维操作(或脚本)之间涉及重启的场景，可在编排流程中直接引用重启reboot原子操作，运维操作(或脚本)自身不应包含重启被控端的命令；

2.API接口：针对单个运维操作涉及多节点有序重启等复杂场景(通常为编写程序实现)，编排流程不便于拆分时，可以调用API完成控制端重启的动作；

3.脚本变量置换：针对单个运维操作涉及多节点有序重启等复杂场景(通常为脚本实现)，编排流程不便于拆分时，可以通过引用内置变量(即内置指令)的方式替代系统侧的命令完成重启操作，例如：

$#{重启reboot:ip,first_wait_time,loop_interval,time_out}。

从上述描述可知，本申请应用实例提供的主从架构中被控端节点重启检测方法，主要解决了有代理模式的主从架构自动化运维编排工具在执行涉及被控端重启操作的任务时无法准确判断重启状态，导致任务调度失败的问题，具备如下优点：

1.能够准确判断被控端重启恢复状态，避免被控端在某些情况下执行重启reboot指令到真正开始重启的间隔较长却被误判为已经重启完成的问题，此场景在Windows系统中较为场景，高负载的Linux也可能触发；

2.基于准确的重启状态判断，能否正确反应编排任务实际状态，并保证被控端重启场景的任务连续性；

3.提供包括编排原子操作、API接口和脚本变量置换等多种形态封装的内置能力，实现开箱即用的效果，满多种运维编排场景的需求。

从软件层面来说，为了解决海量服务器自动化运维场景下，基于主从架构的脚本编排调度工具在被控端执行编排作业过程中需要重启影响任务执行连续性的问题，本申请提供一种用于执行所述主从架构中被控端节点重启检测方法中全部或部分内容的主控端节点的实施例，参见图10，所述主控端节点具体包含有如下内容：

历史时间获取模块10，用于若调度执行到已解析的编排任务中的针对目标主从架构中的被控端节点重启请求，则将该被控端节点距离当前时间最近的重启时间作为历史重启时间；

重启指令发送模块20，用于向所述被控端节点发送重启指令以使该被控端节点开始执行该重启指令；

目标时间获取模块30，用于判断自身与所述被控端节点的当前连接状态是否正常，若是，则再次将被控端节点距离当前时间最近的重启时间作为目标重启时间；

重启判断模块40，用于根据所述目标重启时间和历史重启时间确定所述被控端节点当前是否已重启，若是，则调度执行所述编排任务中的后续指令。

本申请提供的主控端节点的实施例具体可以用于执行上述实施例中的主从架构中被控端节点重启检测方法的实施例的处理流程，其功能在此不再赘述，可以参照上述方法实施例的详细描述。

从上述描述可知，本申请实施例提供的主控端节点，能够在主从架构下脚本编排调度涉及节点重启场景时，有效提高主动检测被控端节点的重启状态的准确性，且能够有效提高被控端节点的重启状态的检测效率，有效提高被控端节点重启及重启状态检测的自动化程度，进而能够有效保证主从架构在运维场景下的运行可靠性、高效性及自动化程度。

为了满多种运维编排场景的需求，在本申请提供的主控端节点的一个实施例中，所述主控端节点还具体包含有如下内容：

编排任务获取模块，用于执行下述内容：

步骤010：在预设的编排调度运维自动化工具的内置功能单元中获取节点重启公共原子操作指令，其中，所述节点重启公共原子操作指令的调用执行方式包括引用原子操作、API接口和脚本变量置换中的至少一项。

步骤020：解析当前的编排任务，并调度执行该编排任务中的各个指令。

步骤030：在调度执行到所述编排任务中的针对目标主从架构中的被控端节点重启请求之时或之后，启动所述节点重启公共原子操作指令。

可以理解的是，上述重启reboot公共原子操作(指令)可封装为编排调度运维自动化工具的多种内置能力供用户使用，主要包括：

1.原子操作(指令)：两个运维操作(或脚本)之间涉及重启的场景，可在编排流程中直接引用重启reboot原子操作，运维操作(或脚本)自身不应包含重启被控端的命令；

2.API接口：针对单个运维操作涉及多节点有序重启等复杂场景(通常为编写程序实现)，编排流程不便于拆分时，可以调用API完成控制端重启的动作；

3.脚本变量置换：针对单个运维操作涉及多节点有序重启等复杂场景(通常为脚本实现)，编排流程不便于拆分时，可以通过引用内置变量(即内置指令)的方式替代系统侧的命令完成重启操作，例如：

$#{重启reboot:ip,first_wait_time,loop_interval,time_out}。

从上述描述可知，本申请实施例提供的主控端节点，通过编排调度运维自动化工具的内置功能单元的预先设置，能够有效提高被控端节点重启及重启状态检测的自动化程度，进而能够有效保证主从架构在运维场景下的自动化程度，同时，通过所述节点重启公共原子操作指令的调用执行方式包括引用原子操作、API接口和脚本变量置换中的至少一项的设置，通过提供包括编排原子操作、API接口和脚本变量置换等多种形态封装的内置能力，实现开箱即用的效果，满多种运维编排场景的需求。

为了进一步提高被控端节点的重启状态检测的效率，在本申请提供的主控端节点的一个实施例中，在所述主控端节点中的历史时间获取模块10具体用于执行下述内容：

步骤110：若调度执行到已解析的编排任务中的针对目标主从架构中的被控端节点重启请求，则向该被控端节点发送最近重启时间查询指令；

步骤120：接收所述被控端节点根据所述最近重启时间查询指令发送的距离当前时间最近的重启时间，并将该重启时间本地存储为所述被控端节点的历史重启时间。

从上述描述可知，本申请实施例提供的主控端节点，能够在主从架构下脚本编排调度涉及节点重启场景时，主动检测被控端节点的重启状态，进而能够进一步提高被控端节点的重启状态检测的效率。

为了进一步提高被控端节点的重启状态检测的效率，在本申请提供的主控端节点的一个实施例中，在所述主控端节点中的目标时间获取模块30具体用于执行下述内容：

步骤310：若在向所述被控端节点发送重启指令后已等待第一时间，则检测自身与所述被控端节点的当前连接状态是否正常，若是，则执行目标重启时间获取步骤。

其中，所述目标重启时间获取步骤包括：

步骤320：再次向该被控端节点发送最近重启时间查询指令。

步骤330：接收所述被控端节点根据所述最近重启时间查询指令发送的距离当前时间最近的重启时间，并将该重启时间本地存储为所述被控端节点的目标重启时间。

从上述描述可知，本申请实施例提供的主控端节点，通过等待第一时间后检测连接状态以及目标重启时间获取步骤的设置，能够进一步提高获取目标重启时间的准确性及可靠性。

为了进一步提高被控端节点的重启状态检测的效率，在本申请提供的主控端节点的一个实施例中，在所述主控端节点中的重启判断模块40具体用于执行下述内容：

步骤410：判断所述目标重启时间是否晚于所述历史重启时间；若是，则执行步骤420；

步骤420：确定所述被控端节点已重启，并调度执行所述编排任务中的后续指令。

从上述描述可知，本申请实施例提供的主控端节点，通过时间点的判断，能够有效简化被控端节点当前是否已重启的判断过程，进而能够有效节省检测成本并进一步提高被控端节点的重启状态检测的效率。

为了提高被控端节点的重启状态检测的智能化程度及可靠性，在本申请提供的主控端节点的一个实施例中，所述主控端节点中的目标时间获取模块30还具体用于执行下述内容：

若经步骤310判断获知自身与所述被控端节点的当前连接状态非正常，则执行轮询步骤；

其中的轮询步骤包括：

步骤340：基于所述编排任务对应的轮询间隔，轮询自身与所述被控端节点的当前连接状态是否正常，若是，即经检测获知自身与所述被控端节点的当前连接状态正常，则执行所述目标重启时间获取步骤：步骤320和步骤330。若否，则执行该步骤340，直至检测到自身与所述被控端节点的当前连接状态正常或者轮询总耗时已达到预设的重启超时时间后，停止轮询。

从上述描述可知，本申请实施例提供的主控端节点，通过经检测获知自身与所述被控端节点的当前连接状态非正常后执行轮询步骤的设置，能够有效提高被控端节点的重启状态检测的智能化程度及可靠性。

为了进一步提高被控端节点的重启状态检测的智能化程度及可靠性，在本申请提供的主控端节点的一个实施例中，所述主控端节点中的重启判断模块40还具体用于执行下述内容：

若经步骤410判断获知所述目标重启时间等于所述历史重启时间，即所述目标重启时间不晚于所述历史重启时间，则执行所述轮询步骤：步骤340。

从上述描述可知，本申请实施例提供的主控端节点，通过经判断获知所述目标重启时间等于所述历史重启时间后执行轮询步骤的设置，能够进一步提高被控端节点的重启状态检测的智能化程度及可靠性。

从硬件层面来说，为了解决海量服务器自动化运维场景下，基于主从架构的脚本编排调度工具在被控端执行编排作业过程中需要重启影响任务执行连续性的问题，本申请提供一种用于实现所述主从架构中被控端节点重启检测方法中的全部或部分内容的电子设备的实施例，所述电子设备具体包含有如下内容：

图11为本申请实施例的电子设备9600的系统构成的示意框图。如图11所示，该电子设备9600可以包括中央处理器9100和存储器9140；存储器9140耦合到中央处理器9100。值得注意的是，该图11是示例性的；还可以使用其他类型的结构，来补充或代替该结构，以实现电信功能或其他功能。

在一实施例中，主从架构中被控端节点重启检测功能可以被集成到中央处理器中。其中，中央处理器可以被配置为进行如下控制：

步骤100：若调度执行到已解析的编排任务中的针对目标主从架构中的被控端节点重启请求，则将该被控端节点距离当前时间最近的重启时间作为历史重启时间。

可以理解的是，所述编排任务为预先接收并解析后的编排作业，其中包含有多种运维任务，被控端节点重启请求为其中的一个运维任务，且在该被控端节点重启请求对应的任务之后，还需要调度执行其他的运维任务。

步骤200：向所述被控端节点发送重启指令以使该被控端节点开始执行该重启指令。

步骤300：判断自身与所述被控端节点的当前连接状态是否正常，若是，则再次将被控端节点距离当前时间最近的重启时间作为目标重启时间。

步骤400：根据所述目标重启时间和历史重启时间确定所述被控端节点当前是否已重启，若是，则调度执行所述编排任务中的后续指令。

从上述描述可知，本申请实施例提供的电子设备，能够在主从架构下脚本编排调度涉及节点重启场景时，有效提高主动检测被控端节点的重启状态的准确性，且能够有效提高被控端节点的重启状态的检测效率，有效提高被控端节点重启及重启状态检测的自动化程度，进而能够有效保证主从架构在运维场景下的运行可靠性、高效性及自动化程度。

在另一个实施方式中，主控端节点可以与中央处理器9100分开配置，例如可以将主控端节点配置为与中央处理器9100连接的芯片，通过中央处理器的控制来实现主从架构中被控端节点重启检测功能。

如图11所示，该电子设备9600还可以包括：通信模块9110、输入单元9120、音频处理器9130、显示器9160、电源9170。值得注意的是，电子设备9600也并不是必须要包括图11中所示的所有部件；此外，电子设备9600还可以包括图11中没有示出的部件，可以参考现有技术。

如图11所示，中央处理器9100有时也称为控制器或操作控件，可以包括微处理器或其他处理器装置和/或逻辑装置，该中央处理器9100接收输入并控制电子设备9600的各个部件的操作。

其中，存储器9140，例如可以是缓存器、闪存、硬驱、可移动介质、易失性存储器、非易失性存储器或其它合适装置中的一种或更多种。可储存上述与失败有关的信息，此外还可存储执行有关信息的程序。并且中央处理器9100可执行该存储器9140存储的该程序，以实现信息存储或处理等。

输入单元9120向中央处理器9100提供输入。该输入单元9120例如为按键或触摸输入装置。电源9170用于向电子设备9600提供电力。显示器9160用于进行图像和文字等显示对象的显示。该显示器例如可为LCD显示器，但并不限于此。

该存储器9140可以是固态存储器，例如，只读存储器(ROM)、随机存取存储器(RAM)、SIM卡等。还可以是这样的存储器，其即使在断电时也保存信息，可被选择性地擦除且设有更多数据，该存储器的示例有时被称为EPROM等。存储器9140还可以是某种其它类型的装置。存储器9140包括缓冲存储器9141(有时被称为缓冲器)。存储器9140可以包括应用/功能存储部9142，该应用/功能存储部9142用于存储应用程序和功能程序或用于通过中央处理器9100执行电子设备9600的操作的流程。

存储器9140还可以包括数据存储部9143，该数据存储部9143用于存储数据，例如联系人、数字数据、图片、声音和/或任何其他由电子设备使用的数据。存储器9140的驱动程序存储部9144可以包括电子设备的用于通信功能和/或用于执行电子设备的其他功能(如消息传送应用、通讯录应用等)的各种驱动程序。

通信模块9110即为经由天线9111发送和接收信号的发送机/接收机9110。通信模块(发送机/接收机)9110耦合到中央处理器9100，以提供输入信号和接收输出信号，这可以和常规移动通信终端的情况相同。

基于不同的通信技术，在同一电子设备中，可以设置有多个通信模块9110，如蜂窝网络模块、蓝牙模块和/或无线局域网模块等。通信模块(发送机/接收机)9110还经由音频处理器9130耦合到扬声器9131和麦克风9132，以经由扬声器9131提供音频输出，并接收来自麦克风9132的音频输入，从而实现通常的电信功能。音频处理器9130可以包括任何合适的缓冲器、解码器、放大器等。另外，音频处理器9130还耦合到中央处理器9100，从而使得可以通过麦克风9132能够在本机上录音，且使得可以通过扬声器9131来播放本机上存储的声音。

本申请的实施例还提供能够实现上述实施例中的主从架构中被控端节点重启检测方法中全部步骤的一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述实施例中的执行主体为服务器或客户端的主从架构中被控端节点重启检测方法的全部步骤，例如，所述处理器执行所述计算机程序时实现下述步骤：

步骤100：若调度执行到已解析的编排任务中的针对目标主从架构中的被控端节点重启请求，则将该被控端节点距离当前时间最近的重启时间作为历史重启时间。

可以理解的是，所述编排任务为预先接收并解析后的编排作业，其中包含有多种运维任务，被控端节点重启请求为其中的一个运维任务，且在该被控端节点重启请求对应的任务之后，还需要调度执行其他的运维任务。

步骤200：向所述被控端节点发送重启指令以使该被控端节点开始执行该重启指令。

步骤300：判断自身与所述被控端节点的当前连接状态是否正常，若是，则再次将被控端节点距离当前时间最近的重启时间作为目标重启时间。

步骤400：根据所述目标重启时间和历史重启时间确定所述被控端节点当前是否已重启，若是，则调度执行所述编排任务中的后续指令。

从上述描述可知，本申请实施例提供的计算机可读存储介质，能够在主从架构下脚本编排调度涉及节点重启场景时，有效提高主动检测被控端节点的重启状态的准确性，且能够有效提高被控端节点的重启状态的检测效率，有效提高被控端节点重启及重启状态检测的自动化程度，进而能够有效保证主从架构在运维场景下的运行可靠性、高效性及自动化程度。

本领域内的技术人员应明白，本发明的实施例可提供为方法、装置、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(装置)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

本发明中应用了具体实施例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (8)

1.一种主从架构中被控端节点重启检测方法，其特征在于，包括：

若调度执行到已解析的编排任务中的针对目标主从架构中的被控端节点重启请求，则将该被控端节点距离当前时间最近的重启时间作为历史重启时间；

向所述被控端节点发送重启指令以使该被控端节点开始执行该重启指令；

判断自身与所述被控端节点的当前连接状态是否正常，若是，则再次将被控端节点距离当前时间最近的重启时间作为目标重启时间；

根据所述目标重启时间和历史重启时间确定所述被控端节点当前是否已重启，若是，则调度执行所述编排任务中的后续指令；

所述判断自身与所述被控端节点的当前连接状态是否正常，若是，则再次将被控端节点距离当前时间最近的重启时间作为目标重启时间，包括：

若在向所述被控端节点发送重启指令后已等待第一时间，则检测自身与所述被控端节点的当前连接状态是否正常，若是，则执行目标重启时间获取步骤；

所述目标重启时间获取步骤包括：再次向该被控端节点发送最近重启时间查询指令；接收所述被控端节点根据所述最近重启时间查询指令发送的距离当前时间最近的重启时间，并将该重启时间本地存储为所述被控端节点的目标重启时间；

所述根据所述目标重启时间和历史重启时间确定所述被控端节点当前是否已重启，若是，则调度执行所述编排任务中的后续指令，包括：

判断所述目标重启时间是否晚于所述历史重启时间；

若是，则确定所述被控端节点已重启，并调度执行所述编排任务中的后续指令。

2.根据权利要求1所述的主从架构中被控端节点重启检测方法，其特征在于，在所述若调度执行到已解析的编排任务中的针对目标主从架构中的被控端节点重启请求，则将该被控端节点距离当前时间最近的重启时间作为历史重启时间之前，还包括：

在预设的编排调度运维自动化工具的内置功能单元中获取节点重启公共原子操作指令，其中，所述节点重启公共原子操作指令的调用执行方式包括引用原子操作、API接口和脚本变量置换中的至少一项；

解析当前的编排任务，并调度执行该编排任务中的各个指令；

在调度执行到所述编排任务中的针对目标主从架构中的被控端节点重启请求之时或之后，启动所述节点重启公共原子操作指令。

3.根据权利要求1所述的主从架构中被控端节点重启检测方法，其特征在于，所述若调度执行到已解析的编排任务中的针对目标主从架构中的被控端节点重启请求，则将该被控端节点距离当前时间最近的重启时间作为历史重启时间，包括：

若调度执行到已解析的编排任务中的针对目标主从架构中的被控端节点重启请求，则向该被控端节点发送最近重启时间查询指令；

接收所述被控端节点根据所述最近重启时间查询指令发送的距离当前时间最近的重启时间，并将该重启时间本地存储为所述被控端节点的历史重启时间。

4.根据权利要求1所述的主从架构中被控端节点重启检测方法，其特征在于，还包括：

若经检测获知自身与所述被控端节点的当前连接状态非正常，则执行轮询步骤；

其中，所述轮询步骤包括：基于所述编排任务对应的轮询间隔，轮询自身与所述被控端节点的当前连接状态是否正常，直至检测到自身与所述被控端节点的当前连接状态正常或者轮询总耗时已达到预设的重启超时时间后，停止轮询；若经检测获知自身与所述被控端节点的当前连接状态正常，则执行所述目标重启时间获取步骤。

5.根据权利要求4所述的主从架构中被控端节点重启检测方法，其特征在于，还包括：

若经判断获知所述目标重启时间等于所述历史重启时间，则执行所述轮询步骤。

6.一种主控端节点，其特征在于，包括：

历史时间获取模块，用于若调度执行到已解析的编排任务中的针对目标主从架构中的被控端节点重启请求，则将该被控端节点距离当前时间最近的重启时间作为历史重启时间；

重启指令发送模块，用于向所述被控端节点发送重启指令以使该被控端节点开始执行该重启指令；

目标时间获取模块，用于判断自身与所述被控端节点的当前连接状态是否正常，若是，则再次将被控端节点距离当前时间最近的重启时间作为目标重启时间；

重启判断模块，用于根据所述目标重启时间和历史重启时间确定所述被控端节点当前是否已重启，若是，则调度执行所述编排任务中的后续指令；

所述目标时间获取模块具体用于：

若在向所述被控端节点发送重启指令后已等待第一时间，则检测自身与所述被控端节点的当前连接状态是否正常，若是，则执行目标重启时间获取步骤；

所述目标重启时间获取步骤包括：再次向该被控端节点发送最近重启时间查询指令；接收所述被控端节点根据所述最近重启时间查询指令发送的距离当前时间最近的重启时间，并将该重启时间本地存储为所述被控端节点的目标重启时间；

所述重启判断模块具体用于：

判断所述目标重启时间是否晚于所述历史重启时间；

若是，则确定所述被控端节点已重启，并调度执行所述编排任务中的后续指令。

7.一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求1至5任一项所述的主从架构中被控端节点重启检测方法。

8.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现权利要求1至5任一项所述的主从架构中被控端节点重启检测方法。