[发明专利]主从架构中被控端节点重启检测方法及主控端节点

说明书

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

技术领域

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

背景技术

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

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

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

发明内容

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

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

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

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

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

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

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

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