CN112764789A - 一种分布式软件升级方法及节点 - Google Patents

Abstract

本发明公开一种分布式软件升级方法及节点，该方法包括：在第一节点基于补丁和/或安装包对第一软件包的版本进行更新，得到更新后的第一软件包；其中，所述第一软件包为分布式软件中的第一部分软件；若所述第一节点更新后的第一软件包的运行依赖于第二节点，则所述第一节点对所述第二节点进行检测；所述第二节点为运行或安装所述分布式软件中的第二部分软件的节点；所述第一部分软件与所述第二部分软件相同或至少部分不同；若检测结果表征所述第二节点处于预设运行状态，当所述第一节点能够运行更新后的所述第一软件包时，确定所述分布式软件升级成功。

Description

一种分布式软件升级方法及节点

技术领域

本发明涉及边缘计算分布式云领域，尤其涉及一种分布式软件升级方法和节点。

背景技术

边缘计算可视为一种分布式的云计算。不同于一般云计算部署在集中式数据中心机房中，边缘计算的特点是节点极其多，在地理上分布极为分散。由于边缘计算的这些特殊性，一旦出现需要软件更新或需要修复现有缺陷，升级、更新将变得非常困难。

发明内容

有鉴于此，本发明的主要目的在于提供一种分布式软件升级方法和节点。

为达到上述目的，本发明的技术方案是这样实现的：

一种分布式软件升级方法，所述方法包括：在第一节点基于补丁和/或安装包对第一软件包的版本进行更新，得到更新后的第一软件包；其中，所述第一软件包为分布式软件中的第一部分软件；

若所述第一节点更新后的第一软件包的运行依赖于第二节点，则所述第一节点对所述第二节点进行检测；所述第二节点为运行或安装所述分布式软件中的第二部分软件的节点；所述第一部分软件与所述第二部分软件相同或至少部分不同；

若检测结果表征所述第二节点处于预设运行状态，则当所述第一节点能够运行更新后的所述第一软件包时，确定所述分布式软件升级成功。

上述方案中，所述方法还包括：所述第一节点接收主节点分发的至少用于更新第一软件包的所述补丁和/或安装包。

上述方案中，所述方法还包括：若所述第一节点更新后的第一软件包的运行不依赖于第二节点，则当所述第一节点能够运行更新后的所述第一软件包时确定所述分布式软件升级成功。

上述方案中，所述第一节点对所述第二节点进行检测，包括：所述第一节点根据预设的检测时间间隔，对所述第二节点安装的所述分布式软件中的第二部分软件的运行状态进行检测。

上述方案中，所述方法还包括：若所述第一节点对所述第二节点进行M次检测、且所述M次检测的检测结果均表征所述第二节点不处于所述预设运行状态，并且M次检测的总时长等于预设检测时长，则所述第一节点发送分布式软件升级失败的消息到所述主节点；其中，M为非0自然数。

上述方案中，所述方法还包括：若所述第一节点对所述第二节点连续进行N次检测、且所述N次检测的检测结果均表征所述第二节点不处于所述预设运行状态，则所述第一节点发送分布式软件升级失败消息到所述主节点；其中，N为预设的检测次数门限值，且为非0自然数。

上述方案中，所述方法还包括以下之一：

当所述第一节点分布式软件升级成功时，若所述第一节点接收到所述主节点发送的回退命令，则所述第一节点将更新后的第一软件包降级为原始版本；

当所述第一节点的所述第一软件包更新失败时，若所述第一节点接收到所述主节点发送的回退命令，则所述第一节点停止对所述第一软件包进行更新；

当所述第一节点的所述第一软件包更新成功、且不能运行所述更新后的第一软件包时，若所述第一节点接收到所述主节点发送的回退命令，则所述第一节点将更新后的第一软件包降级为原始版本。

一种分布式软件升级第一节点，所述第一节点包括：

版本更新模块，用于基于补丁和/或安装包对第一软件包的版本进行更新，得到更新后的第一软件包；其中，所述第一软件包为分布式软件中的第一部分软件；

状态检测模块，用于若更新后的第一软件包的运行依赖于第二节点，则对所述第二节点进行检测；所述第二节点为运行或安装所述分布式软件中的第二部分软件的节点；所述第一部分软件与所述第二部分软件相同或至少部分不同；

确定升级成功模块，用于若检测结果表征所述第二节点处于预设运行状态，则当能够运行更新后的所述第一软件包时，确定所述分布式软件升级成功。

上述方案中，所述第一节点还包括：接收模块；

所述接收模块，用于接收主节点分发的至少用于更新第一软件包的所述补丁和/或安装包。

上述方案中，所述确定升级成功模块，还用于若更新后的第一软件包的运行不依赖于第二节点，则当能够运行更新后的所述第一软件包时确定所述分布式软件升级成功。

上述方案中，所述状态检测模块，还用于根据预设的检测时间间隔，对所述第二节点安装的所述分布式软件中的第二部分软件的运行状态进行检测。

上述方案中，所述状态检测模块，还用于若对所述第二节点进行M次检测、且所述M次检测的检测结果均表征所述第二节点不处于所述预设运行状态，并且M次检测的总时长等于预设检测时长，则发送分布式软件升级失败的消息到主节点；其中，M为非0自然数。

上述方案中，所述状态检测模块，还用于若对所述第二节点连续进行N次检测、且所述N次检测的检测结果均表征所述第二节点不处于所述预设运行状态，则发送分布式软件升级失败消息到主节点；其中，N为预设的检测次数门限值，且为非0自然数。

上述方案中，所述版本更新模块，至少还用于以下之一：

当分布式软件升级成功时，若接收到所述主节点发送的回退命令，则将更新后的第一软件包降级为原始版本；

当所述第一软件包更新失败时，若接收到所述主节点发送的回退命令，则停止对所述第一软件包进行更新；

当所述第一节点的所述第一软件包更新成功、且不能运行所述更新后的第一软件包时，若接收到所述主节点发送的回退命令，则将更新后的第一软件包降级为原始版本。

本发明实施例所提供的一种分布式软件升级方法和节点，在第一节点更新后的第一软件包的运行依赖于第二节点的情况下，由第一节点检测第二节点的运行状态是否处于预设运行状态，若第二节点处于该预设运行状态，当第一节点能够运行更新后的所述第一软件包时，确定所述分布式软件升级成功。如此，通过使第一节点对其依赖的节点是否处于预设运行状态进行检测，避免了以往统一设置一个时间段等待该节点依赖的节点的运行状态满足预设运行状态，满足后该节点再执行其他操作，这样节约了等待时间，提高了使第一节点上更新后的第一软件包能够运行的效率，从而提高了分布式软件升级的效率。

附图说明

图1为本发明实施例提供的一种分布式软件升级方法实现流程示意图一；

图2为本发明实施例提供的一种分布式软件升级方法实现流程示意图二；

图3为本发明实施例提供的一种分布式软件升级环境架构示意图；

图4为本发明实施例提供的一种第一节点结构示意图；

图5为本发明实施例提供的一种第一节点结构示意图。

具体实施方式

以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。

相关技术关于分布式软件升级的方法主要有以下三种：

文献1.一种软件升级的方法

该发明提供一种软件升级的方法，该方法构建的升级平台，独立于软件、独立应用在不同产品或项目中，使用时平台客户端自动查找补丁服务器，并从补丁服务器获取补丁包，平台自动校验补丁有效性，支持断点续传，下载并验证完成后进而进行补丁升级操作。补丁在平台中采用根据定义任务自动下载、手动下载；根据定义任务自动升级和手动升级：该发明的优点是，使用描述语言描述、解析补丁包，补丁使用通用的压缩处理，传送迅速、安全可靠，可杜绝网络数据堵塞等情况的发生，而且能及时发现补丁下载、安装时出现的问题，解决了软件更新、不同客户端版本管理以及自动下载更新等问题，能够很好地满足不同平台下各种软件升级要求。

文献2.分布式软件补丁更新方法及***

该发明公开了一种分布式软件补丁更新方法及***。所述方法包括：补丁管理服务器向第一目标应用服务器发送第一程序补丁文件，并远程控制第一目标应用服务器执行第一程序补丁文件，对第一程序模块进行补丁更新；补丁管理服务器还向数据库服务器发送数据补丁文件，所述数据库服务器上安装了所述分布式软件的数据库***；数据库服务器根据数据补丁文件，对数据库***进行补丁更新。在分布式软件的补丁更新过程中，通过补丁管理服务器向目标应用服务器和数据库服务器主动推送分布式软件的程序补丁文件和数据补丁文件，可以统一实现目标应用服务器上的程序模块更新以及数据库服务器上的数据库***更新，从而实现分布式软件的升级和修补。

文献3.一种基于RPM包的分布式存储***软件升级方法

该发明实施例公开了一种基于RPM包的分布式存储***软件升级方法，包括：获取分布式存储***状态信息；判断状态信息是否正常；如果是则停止分布式存储***的关键服务，否则停止升级；对分布式存储***的文件进行备份，生成备份文件；将软件升级包以及升级脚本装包发送给其他节点；各节点分别运行软件升级包进行升级。该发明实施例中通过在主节点中运行升级脚本对整个分布式存储***的状态信息进行判断，当状态信息表示***状态正常时关闭***内的关键服务，从而停止相关业务的进行，对***的文件进行备份，通过主节点将升级脚本以及升级包发送给其他的节点，然后在各个节点上同时运行升级脚本和升级包而实现各节点同时升级，提高升级效率。

然而，文献1和2没有考虑到远端分布式集群服务之间存在相互依赖的情况，这种情况不能简单的进行升级，需要考虑到集群服务之间的依赖关系；文献3虽然提出先进行主节点升级再进行其他节点的升级，这在一定程度上解决了某些主、备服务升级，但是不全面，有很多分布式服务需要进行长时间的重启等待和特殊条件的判断来做集群同步。

针对上述问题，本发明实施例提供一种分布式软件升级方法，如图1所示，图1为本发明实施例提供的一种分布式软件升级方法实现流程示意图，具体的：

S101、在第一节点基于补丁和/或安装包对第一软件包的版本进行更新，得到更新后的第一软件包；其中，所述第一软件包为分布式软件中的第一部分软件。

在分布式软件升级前，主节点将用户输入的全量软件升级包分发给第一节点，所述全量软件包至少包含了补丁和/或安装包，以及一个用yaml或xml编写的描述文件。第一节点收到该全量软件升级包后，针对该第一节点上原本就有的软件对应的补丁和/或安装包，对第一软件包进行版本更新。其中，当需要在第一节点上打补丁时，先在该节点上试运行打补丁操作，试运行成功后，再正式打补丁。

第一节点安装完该节点的补丁和/或安装包后，该节点上对应第一软件包的的版本得到更新，比如之前数据库的版本为v1.0，更新后的版本为v2.0；第一软件包是分布式软件中的第一部分软件。

S102、若所述第一节点更新后的第一软件包的运行依赖于第二节点，则所述第一节点对所述第二节点进行检测；所述第二节点为运行或安装所述分布式软件中的第二部分软件的节点；所述第一部分软件与所述第二部分软件相同或至少部分不同。

分布式云计算的节点众多，有一些节点之间有依赖关系，如集群中各节点，或者非集群中几个节点；针对非集群中的几个节点，可能存在每个节点上安装的软件各自完成部分功能，但是几个节点的部分功能合在一起又可以实现一个完整的功能。

对于上述情况，若所述第一节点更新后的第一软件包的运行依赖于第二节点，则所述第一节点根据所述第一节点接收到的全量升级包中的描述文件中的阻塞等待条件预设的预检测命令对所述第二节点的运行状态进行检测。

其中，第二节点上的第二部分软件与第一节点的第一部分软件相同或至少部分不同。

S103、若检测结果表征所述第二节点处于预设运行状态，则当所述第一节点能够运行更新后的所述第一软件包时，确定所述分布式软件升级成功。

当第二节点安装或运行的所述第二软件包的所述运行状态满足所述第一节点的所述阻塞等待条件中预设的检测结果时，第二节点即处于预设的运行状态；所述第一节点执行针对安装的所述第一软件包的关联操作，该关联操作可能是重启某个服务、打开防火墙或执行特殊操作等，在第一节点执行完关联操作后，可能第一节点上的软件模块和配置文件得到了修改，更新后的第一软件包能够运行。至此，第一节点的分布式软件升级成功完成。

本发明实施例所提供的一种分布式软件升级方法，在第一节点更新后的第一软件包的运行依赖于第二节点的情况下，由第一节点检测第二节点的运行状态是否处于预设运行状态，若第二节点处于该预设运行状态，当第一节点能够运行更新后的所述第一软件包时，确定所述分布式软件升级成功。如此，通过使第一节点对其依赖的节点是否处于预设运行状态进行检测，避免了以往统一设置一个时间段等待该节点依赖的节点的运行状态满足预设运行状态，满足后该节点再执行其他操作，这样节约了等待时间，提高了使第一节点上更新后的第一软件包能够运行的效率，从而提高了分布式软件升级的效率。

本发明实施例提供一种分布式软件升级方法，如图2所示，图2为本发明实施例提供的一种分布式软件升级方法实现流程示意图二。

S101、在第一节点基于补丁和/或安装包对第一软件包的版本进行更新，得到更新后的第一软件包；其中，所述第一软件包为分布式软件中的第一部分软件。

所述方法还包括：所述第一节点接收主节点分发的至少用于更新第一软件包的所述补丁和/或安装包。具体的：

运维升级人员在本地主节点的自动升级软件主程序中输入全量升级包，并输入升级执行人员用户名。该全量升级包可以是类似于zip的压缩格式，该全量升级包具体包括本次升级的所有子升级包和一个名称固定的描述文件，该描述文件可采用yaml或xml格式，用于说明这些子升级包的信息和针对这些子升级包采用的升级方法。

该描述文件具体包含下列信息：全量升级包的版本(version)，压缩包内除描述文件外的所有补丁、软件升级包的文件个数(file_count)，子软件升级包的升级信息，可包含多个patches。

每一个子软件升级包信息包含：

*软件包的文件名称(file_name)；

*软件包的文件类型，包含:补丁文件和安装包两种类型(file_type)，如果是补丁文件，应当包含当时生成补丁文件所在的代码库中的提交id(commit_id)以及其历史ID记录(commit_history)列表，其中commit_history是过去修复过的补丁版本记录，其记录了每个修复版本的描述以及相关代码的修改；一般常用代码库为svn或git，ID即代码库中的提交ID(commit id)；如果是软件包形式，应当包含软件包版本(version)；

*补丁文件或软件包的md5校验值(md5)；

*软件包的分类(package_type)，包含：kernel内核、驱动模块、普通软件、配置文件等；该分类表示此子软件包是针对其中至少一个分类进行的升级；

*升级方法(upgrade_approach)，包含打补丁(patch)或者安装包更新(update)两种方式；

*升级节点地址(upgrade_host)，该地址用于标识具体在哪个节点上升级该子软件包；

*关联操作(dependency_ops)：可以包含重启某个服务，重启关联服务，打开防火墙，执行特殊操作等用户自定义操作；执行完关联操作后，节点上更新的软件包才能够运行；

*阻塞等待条件(wait_for)：对于某些操作，可能需要在执行该操作前，检查其他节点是否已具备相关的前置条件，比如数据库集群升级重启，要求从节点(slave)需要等待主节点(master)重启成功后才能进行重启并进行同步协调，此时的操作为关联操作。其中，阻塞等待条件参数包含：是否开启阻塞等待(wait_for)，目标检测节点列表(wait_for_hosts)，阻塞等待的预检测命令(pre_check)，阻塞等待的结果比较方法(check_op)，阻塞等待的结果检测内容(check_value)，阻塞检测的间隔时间(wait_for_interval)，阻塞检测时长(wait_for_timeout)；

全量升级包内包含update目录，该目录包含所有子软件包补丁文件或子软件升级安装包。

具体参见以下全量升级软件包内的upgrade.yaml代码示例一：

上述upgrade.yaml代码示例一中，patchs字段下的每一个大括号内均为一个子软件升级包，该子软件升级包可以为补丁(patch)或安装包(update)，各节点根据子软件包中的upgrade_host字段确定该子软件包是否为针对自己升级的子软件包。

图3提供了一种分布式软件升级环境架构示意图，在运维升级人员在自动升级软件主程序中输入全量升级包后，自动升级软件主程序将全量升级包通过互联网复制到各边缘计算节点的代理升级软件。其中，边缘计算节点上有升级软件的客户端即代理升级软件程序；代码版本信息数据库，该数据块用于维护、保持升级状态等；软件备份，用于备份旧版本的子软件包。

图3中，升级软件服务端即自动升级软件主程序和各代理升级软件程序之间通过基于可靠传输协议TCP的API协议进行通信，且通过SSL对API连接进行加密。

可将第一节点看作为任一边缘节点，该第一节点的代理升级软件程序接收主节点自动升级软件主程序发来的全量升级包，并对压缩包进行解压，并从中根据upgrade_host字段确定出适合自己的补丁和/或安装包，用以更新第一节点上的旧的第一软件包。

具体步骤以第一节点为例，可如图2所示：

S201、运行代理升级软件。

S202、第一节点读取描述文件中子软件包个数字段(file_count)，并检查patches字段内软件列表成员总数是否等于该个数字段(file_count)对应的个数，若不相等，则该代理升级软件报错至主节点的自动升级软件主程序，并结束软件升级流程，具体可参见全量升级软件包内的upgrade.yaml代码示例一；若相等则执行步骤S203。

S203、读取patches列表，检查其中的所有文件名(file_name)是否均存在于update目录中，若不存在，则该代理升级软件报错至主节点的自动升级软件主程序，并结束软件升级流程；若存在则执行步骤S204。

S204、读取md5字段，如upgrade.yaml代码示例一所示，计算并检查该文件的校验值是否正确，若不正确，则该代理升级软件报错至主节点的自动升级软件主程序，并结束软件升级流程；若正确则执行步骤S205。

S205、如果子软件包类型(file_type)为补丁patch，那么先读取本地代码版本数据库进行版本信息检查，若有问题，则该代理升级软件报错至主节点的自动升级软件主程序，并结束软件升级流程；否则，执行S2051；如果软件包类型(file_type)为安装包(以RPM软件包为例)，执行S2052。

S2051、在第一节点模拟一个真实环境，进行试运行打补丁操作(dry run)，如果运行正确，则进入S206。

S2052、先检查本地同名安装包是否已安装，如果已安装的安装包版本大于需要升级的安装包版本，那么该代理升级软件报错并结束软件升级流程。如果版本正确，则进入S206。

S206、当子软件包类型为补丁时，进行正式打补丁操作；打完补丁后，升级软件自动把提交ID(commit id)、升级执行人员用户名、操作时间以及补丁相关信息更新至代码版本信息数据库，并备份补丁到该第一节点的特定目录；当子软件包类型为安装包时，升级软件自动运行该子软件包，并把更新的子软件包版本(version)、升级执行人员用户名、操作时间、以及更新子软件包的其他相关信息更新至代码版本数据库，这样能有效检测升级历史，遇到问题时也能进行问题追查和责任追查；并备份旧版本子软件包到第一节点的特定目录。

S207、当子软件包中的补丁和/或安装包安装完成后，按照描述文件中的顺序执行关联操作，即：

当所述关联操作至少为两个时，所述至少两个关联操作有对应的执行顺序；所述第一节点根据所述至少两个关联操作对应的执行顺序，依次执行每一个所述关联操作。

S208、根据第一节点接收的全量升级包中描述文件中的阻塞等待条件执行关联操作，当该第一节点的分布式软件升级成功或失败，更新代码版本数据库，记录此时第一节点升级成功以及升级成功对应的软件包的版本信息等；当分布式软件升级中所有类似于第一节点的边缘节点全部升级成功时，整个分布式软件升级成功。

当该第一节点升级没有完成，则该节点通过代理升级软件程序通知主节点的自动升级软件程序该节点升级失败。此时，主节点发出回退消息至所有边缘节点，针对正在升级的边缘节点，停止升级，运维升级人员获取旧的补丁和/或安装包，在各节点上运行旧补丁和/或安装包，使该节点上补丁和/或安装包的版本回退为原来的版本；针对已经升级成功的节点，运维升级人员同样获取旧的补丁和/或安装包，在节点上运行旧补丁和/或安装包，对节点上补丁和/或安装包进行降级操作。

当执行了回退操作后，仍然需要更新代码版本数据库中相应的补丁和/或安装包的版本信息，若整个分布式软件升级成功，此时记录升级成功，若失败，则做相应的失败记录。同时记录执行人员、操作时间等信息，以方便日后查看升级历史信息或进行问题、责任追查，此后结束升级流程。

针对上述步骤S207，该执行关联操作过程具体如图1中所示的工作流程图S102和S103记载。

S102、若所述第一节点更新后的第一软件包的运行依赖于第二节点，则所述第一节点对所述第二节点进行检测；所述第二节点为运行或安装所述分布式软件中的第二部分软件的节点；所述第一部分软件与所述第二部分软件相同或至少部分不同。

S103、若检测结果表征所述第二节点处于预设运行状态，则当所述第一节点能够运行更新后的所述第一软件包时，确定所述分布式软件升级成功。

分布式云计算的节点众多，有一些节点之间有依赖关系，如集群中各节点，或者非集群中几个节点；针对非集群中的几个节点，可能存在每个节点上安装的软件各自完成部分功能，但是几个节点的部分功能合在一起又可以实现一个完整的功能。

对于上述情况，可参见全量升级包中描述文件upgrade.yaml代码示例一。

当第一节点接收的描述文件中关联操作(dependency_ops)下阻塞等待条件(wait_for)为True时，表示需要判断第二节点的运行状态是否满足第一节点执行关联操作的前置条件，此时，第二节点即为目标检查节点列表(wait_for_hosts)中列出的节点，当第二节点的个数大于等于2时，每一个节点的运行状态均需要满足前置条件。

具体判断第二节点的运行状态是否满足第一节点执行关联操作前置条件的方式如upgrade.yaml代码示例一中记载，可先通过ping通该第二节点，并针对该第二节点执行预检测命令(pre_check)，示例为systemctl status http，检测此时第二节点的运行状态，由于此时返回的第二节点的运行状态为一串字符串，此时的预设运行状态由阻塞等待的结果比较方法(check_op)和阻塞等待的结果检查内容(check_value)共同决定。

示例性的如第一节点在该yaml代码中预设阻塞等待的结果比较方法(check_op)为include，阻塞等待的结果检查内容(check_value)为running，可以理解为：当返回的第二节点的运行状态中包含即include了running这个字符串时，视为此时第二节点上补丁和/或安装包的运行状态满足第一节点执行关联操作的前置条件，即满足阻塞等待条件中预设的运行状态。

同样的，也可以设置预设阻塞等待的结果比较方法(check_op)为exclude，阻塞等待的结果检查内容(check_value)为error，可以理解为：当返回的第二节点的运行状态中不包含即exclude了error字符串时，视为此时第二节点上补丁和/或安装包的运行状态满足第一节点执行关联操作的前置条件，即满足阻塞等待条件中预设的运行状态。

若所述第一节点对所述第二节点进行M次检测、且所述M次检测的检测结果均表征所述第二节点不处于所述预设运行状态，并且M+1次检测的总时长等于预设检测时长，则所述第一节点发送分布式软件升级失败的消息到所述主节点；其中，M为非0自然数。

可以理解的是，第二节点的运行状态可能一开始并不满足第一节点执行关联操作时的前置条件，此时第一节点需要等待第二节点满足其前置条件，故对第二节点的运行状态进行多次检测，当检测到第M次时，前面累计检测的总时长等于预设的检测时长时，则所述第一节点发送分布式软件升级失败的消息到主节点。

特例性的，第一节点对第二节点进行M次检测，每次检测的时间间隔都相等，即：

所述第一节点根据预设的检测时间间隔，对所述第二节点安装的所述分布式软件中的第二部分软件的运行状态进行检测。

示例性的如上述upgrade.yaml文件中设置的阻塞检测的间隔时间(wait_for_interval)，这意味着，第一节点可以按照这个时间间隔，每隔10秒或10毫秒，周期性地对第二节点上补丁和/或安装包的运行状态进行检测：当第一次检测不满足第一节点执行关联操作的前置条件时，在10秒或10毫秒后重新对第二节点执行预检测命令pre_check，只要花费的检测总时长没有达到阻塞检测时长(wait_for_timeout)，如上述代码示例中的100秒或100毫秒，则可一直执行针对第二节点的检测。

当第一节点对第二节点进行第10次检测时，若此时第二节点的运行状态还是没有处于预设的运行状态，但总共耗时为100秒或100毫秒，此时花费的时间与预设的总时长相等，则第一节点发送分布式软件升级失败的消息到所述主节点。

值得说明的是，当第二节点的个数为两个以上时，需要在同一次检测时，所有第二节点的运行状态均处于预设的运行状态，才能确定第二节点的检测结果处于预设运行状态；但凡在一次检测时，第二节点中任一个的检测结果不处于预设的运行状态，则可确定第二节点的检测结果不处于预设运行状态。

若所述第一节点更新后的第一软件包的运行不依赖于第二节点，则当所述第一节点能够运行更新后的所述第一软件包时确定所述分布式软件升级成功。

当所述第一节点接收的描述文件中关联操作(dependency_ops)下不存在阻塞等待条件(wait_for)时，表示第一节点执行关联操作时不需要判断第二节点的运行状态是否处于预设的运行状态，此时第一节点直接执行关联操作，当成功执行该关联操作后，第一节点上更新的第一软件包能够运行，此时也能确定第一节点上的分布式软件升级成功。

若所述第一节点对所述第二节点连续进行N次检测，所述第二节点不处于所述预设运行状态，则所述第一节点发送分布式软件升级失败消息到主节点；其中，N为非0自然数。

可以理解的是，将阻塞等待条件中的阻塞检测时长(wait_for_timeout)，改为阻塞检测次数门限(wait_for_check_counts)，即当第一节点根据描述文件中预设的预检测命令对第二节点的运行状态进行检测，当连续检测N次以后第二节点的运行状态仍旧不处于预设的运行状态，则此时所述第一节点发送分布式软件升级失败消息到所述主节点。

所述分布式软件升级方法还包括以下之一：

当所述第一节点分布式软件升级成功时，若所述第一节点接收到所述主节点发送的回退命令，则所述第一节点将更新后的第一软件包降级为原始版本；

当所述第一节点的所述第一软件包更新失败时，若所述第一节点接收到所述主节点发送的回退命令，则所述第一节点停止对所述第一软件包进行更新；

当所述第一节点的所述第一软件包更新成功、且不能运行所述更新后的第一软件包时，若所述第一节点接收到所述主节点发送的回退命令，则所述第一节点将更新后的第一软件包降级为原始版本。

由于分布式软件升级中节点众多，当任何一个节点升级失败或升级过程中发送断电等异常情况时，主节点的自动升级软件都会收到分布式软件升级失败的消息，并对此发出回退命令，提醒各边缘节点，此处可理解为第一节点处的运维升级人员进行回退操作。这样能及时、快速的结束整个升级过程，可避免其他节点由于不知道已经存在节点升级失败而继续升级，造成浪费时间的问题，从而节约资源。具体操作为：

收到回退命令的第一节点，若分布式软件升级成功，则所述第一节点将更新后的第一软件包降级为原始版本；如将数据库版本从v2.0降到v1.0。

当所述第一节点的所述第一软件包更新失败，即此时数据库版本仍旧处于v1.0的版本状态，所述第一节点接收到所述主节点发送的回退命令时，所述第一节点不再从新安装新版本的数据库，使其维持在v1.0。

当所述第一节点的所述第一软件包成功从v1.0更新到v2.0、但此时第一节点又不能运行所述更新后的数据库，所述第一节点接收到所述主节点发送的回退命令时，所述第一节点停止使所述第一软件包能够运行的操作，如停止安装OpenStack等关联操作，并重新在第一节点上运行更新前的第一软件包，所述第一节点将更新后的第一软件包降级为原始版本v1.0。

本发明实施例所提供的一种分布式软件升级方法，在第一节点更新后的第一软件包的运行依赖于第二节点的情况下，由第一节点检测第二节点的运行状态是否处于预设运行状态，若第二节点处于该预设运行状态，当第一节点能够运行更新后的所述第一软件包时，确定所述分布式软件升级成功。如此，通过使第一节点对其依赖的节点是否处于预设运行状态进行检测，避免了以往统一设置一个时间段等待该节点依赖的节点的运行状态满足预设运行状态，满足后该节点再执行其他操作，这样节约了等待时间，提高了使第一节点上更新后的第一软件包能够运行的效率，从而提高了分布式软件升级的效率。

本发明实施例提供一种分布式软件升级第一节点，如图4为该第一节点的结构示意图，具体的：

一种第一节点10，所述第一节点包括：

版本更新模块11，用于基于补丁和/或安装包对第一软件包的版本进行更新，得到更新后的第一软件包；其中，所述第一软件包为分布式软件中的第一部分软件。

在分布式软件升级前，主节点将用户输入的全量软件升级包分发给第一节点，所述全量软件包至少包含了补丁和/或安装包以及一个用yaml或xml编写的描述文件。第一节点收到该全量软件升级包后，针对该第一节点上原本就有的软件对应的补丁和/或安装包，利用版本更新模块11对第一软件包进行版本更新。其中，当需要在第一节点上打补丁时，先在该节点上试运行打补丁操作，试运行成功后，再正式打补丁。

第一节点安装完该节点的补丁和/或安装包后，该节点上对应第一软件包的的版本得到更新，比如之前数据库的版本为v1.0，更新后的版本为v2.0；第一软件包是分布式软件中的第一部分软件。

状态检测模块12，用于若更新后的第一软件包的运行依赖于第二节点，则对所述第二节点进行检测；所述第二节点为运行或安装所述分布式软件中的第二部分软件的节点；所述第一部分软件与所述第二部分软件相同或至少部分不同。

分布式云计算的节点众多，有一些节点之间有依赖关系，如集群中各节点，或者非集群中几个节点；针对非集群中的几个节点，可能存在每个节点上安装的软件各自完成部分功能，但是几个节点的部分功能合在一起又可以实现一个完整的功能。

对于上述情况，若所述第一节点更新后的第一软件包的运行依赖于第二节点，则所述第一节点根据所述第一节点接收到的全量升级包中的描述文件中的阻塞等待条件预设的预检测命令，利用状态检测模块12对所述第二节点的运行状态进行检测。

确定升级成功模块13，用于若检测结果表征所述第二节点处于预设运行状态，则当能够运行更新后的所述第一软件包时，确定所述分布式软件升级成功。

当第二节点安装或运行的所述第二软件包的所述运行状态满足所述第一节点的所述阻塞等待条件中预设的检测结果时，第二节点即处于预设的运行状态；所述第一节点执行针对安装的所述第一软件包的关联操作，该关联操作可能是重启某个服务、打开防火墙或执行特殊操作等，在第一节点执行完关联操作后，可能节点上的软件模块和配置文件得到了修改，使得更新后的第一软件包能够运行。至此，第一节点的分布式软件升级成功完成。

该第一节点还包括：接收模块14；所述接收模块，用于接收主节点分发的至少用于更新第一软件包的所述补丁和/或安装包。

具体的，如图5，主节点上的自动升级软件程序将运维升级人员输入的软件升级包分发给各边缘节点，本发明中第一节点也为边缘节点，由该第一节点通过接收模块14接收主节点分发的补丁和/或安装包。

所述确定升级成功模块13，还用于若更新后的第一软件包的运行不依赖于第二节点，则当能够运行更新后的所述第一软件包时确定所述分布式软件升级成功。

此时，可理解为，第一节点不考虑阻塞等待条件直接执行关联操作。

所述状态检测模块12，还用于根据预设的检测时间间隔，对所述第二节点安装的所述分布式软件中的第二部分软件的运行状态进行检测。

也就是说，第一节点通过状态检测模块12按照阻塞等待条件中预设的检测时间间隔，周期性地对第二节点的运行状态进行检测。

所述状态检测模块12，还用于若对所述第二节点进行M次检测、且所述M次检测的检测结果均表征所述第二节点不处于所述预设运行状态，并且M次检测的总时长等于预设检测时长，则发送分布式软件升级失败的消息到主节点；其中，M为非0自然数。

第二节点的运行状态可能一开始并不满足第一节点执行关联操作时的前置条件，此时第一节点需要等待第二节点满足其前置条件，故对第二节点的运行状态进行多次检测，当检测到第M次时，检测的总时长等于预设的检测时长时，则所述第一节点发送分布式软件升级失败的消息到所述主节点。

特例性的，第一节点对第二节点进行M次检测，每次检测的时间间隔都相等。

所述状态检测模块12，还用于若对所述第二节点连续进行N次检测、且所述N次检测的检测结果均表征所述第二节点不处于所述预设运行状态，则发送分布式软件升级失败消息到主节点；其中，N为预设的检测次数门限值，且为非0自然数。

可以理解的是，将阻塞等待条件中的阻塞检测时长(wait_for_timeout)，改为阻塞检测次数门限(wait_for_check_counts)，即当第一节点根据描述文件中预设的预检测命令对第二节点的运行状态进行检测，当连续检测N次以后第二节点的运行状态仍旧不处于预设的运行状态，则此时所述第一节点发送分布式软件升级失败消息到所述主节点。

所述版本更新模块11，至少还用于以下之一：

当分布式软件升级成功时，若接收到所述主节点发送的回退命令，则将更新后的第一软件包降级为原始版本；

当所述第一软件包更新失败时，若接收到所述主节点发送的回退命令，则停止对所述第一软件包进行更新；

当所述第一软件包更新成功、且不能运行所述更新后的第一软件包时，若接收到所述主节点发送的回退命令，则将更新后的第一软件包降级为原始版本。

由于分布式软件升级中节点众多，当任何一个节点升级失败或升级过程中发送断电等异常情况时，主节点的自动升级软件都会收到分布式软件升级失败的消息，并对此发出回退命令，提醒各边缘节点，此处可理解为第一节点处的运维升级人员进行回退操作。这样能及时、快速的结束整个升级过程，可避免其他节点由于不知道已经存在节点升级失败而继续升级，导致浪费时间的问题，从而节约资源。具体操作为：

收到回退命令的第一节点，若分布式软件升级成功，则所述第一节点将更新后的第一软件包降级为原始版本；如将数据库版本从v2.0降到v1.0。

当所述第一节点的所述第一软件包更新失败，即此时数据库版本仍旧处于v1.0的版本状态，所述第一节点接收到所述主节点发送的回退命令时，所述第一节点不再从新安装新版本的数据库，使其维持在v1.0。

当所述第一节点的所述第一软件包成功从v1.0更新到v2.0、但此时第一节点又不能运行所述更新后的数据库，所述第一节点接收到所述主节点发送的回退命令时，所述第一节点停止使所述第一软件包能够运行的操作，如停止安装OpenStack等关联操作，并重新在第一节点上运行更新前的第一软件包，所述第一节点将更新后的第一软件包降级为原始版本v1.0。

本发明实施例所提供的一种第一节点，在第一节点更新后的第一软件包的运行依赖于第二节点的情况下，由第一节点检测第二节点的运行状态是否处于预设运行状态，若第二节点处于该预设运行状态，当第一节点能够运行更新后的所述第一软件包时，确定所述分布式软件升级成功。如此，通过使第一节点对其依赖的节点是否处于预设运行状态进行检测，避免了以往统一设置一个时间段等待该节点依赖的节点的运行状态满足预设运行状态，满足后该节点再执行其他操作，这样节约了等待时间，提高了使第一节点上更新后的第一软件包能够运行的效率，从而提高了分布式软件升级的效率。

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

Claims (14)

1.一种分布式软件升级方法，其特征在于，所述方法包括：

在第一节点基于补丁和/或安装包对第一软件包的版本进行更新，得到更新后的第一软件包；其中，所述第一软件包为分布式软件中的第一部分软件；

若所述第一节点更新后的第一软件包的运行依赖于第二节点，则所述第一节点对所述第二节点进行检测；所述第二节点为运行或安装所述分布式软件中的第二部分软件的节点；所述第一部分软件与所述第二部分软件相同或至少部分不同；

若检测结果表征所述第二节点处于预设运行状态，则当所述第一节点能够运行更新后的所述第一软件包时，确定所述分布式软件升级成功。

2.根据权利要求1中所述的方法，其特征在于，所述方法还包括：

所述第一节点接收主节点分发的至少用于更新第一软件包的所述补丁和/或安装包。

3.根据权利要求1中所述的方法，其特征在于，所述方法还包括：

若所述第一节点更新后的第一软件包的运行不依赖于第二节点，则当所述第一节点能够运行更新后的所述第一软件包时确定所述分布式软件升级成功。

4.根据权利要求1中所述的方法，其特征在于，所述第一节点对所述第二节点进行检测，包括：

所述第一节点根据预设的检测时间间隔，对所述第二节点安装的所述分布式软件中的第二部分软件的运行状态进行检测。

5.根据权利要求1中所述的方法，其特征在于，所述方法还包括：

若所述第一节点对所述第二节点进行M次检测、且所述M次检测的检测结果均表征所述第二节点不处于所述预设运行状态，并且M次检测的总时长等于预设检测时长，则所述第一节点发送分布式软件升级失败的消息到主节点；其中，M为非0自然数。

6.根据权利要求1中所述的方法，其特征在于，所述方法还包括：

若所述第一节点对所述第二节点连续进行N次检测、且所述N次检测的检测结果均表征所述第二节点不处于所述预设运行状态，则所述第一节点发送分布式软件升级失败消息到主节点；其中，N为预设的检测次数门限值，且为非0自然数。

7.根据权利要求5或6中所述的方法，其特征在于，所述方法还包括以下之一：

当所述第一节点分布式软件升级成功时，若所述第一节点接收到所述主节点发送的回退命令，则所述第一节点将更新后的第一软件包降级为原始版本；

当所述第一节点的所述第一软件包更新失败时，若所述第一节点接收到所述主节点发送的回退命令，则所述第一节点停止对所述第一软件包进行更新；

当所述第一节点的所述第一软件包更新成功、且不能运行所述更新后的第一软件包时，若所述第一节点接收到所述主节点发送的回退命令，则所述第一节点将更新后的第一软件包降级为原始版本。

8.一种第一节点，其特征在于，所述第一节点包括：

版本更新模块，用于基于补丁和/或安装包对第一软件包的版本进行更新，得到更新后的第一软件包；其中，所述第一软件包为分布式软件中的第一部分软件；

状态检测模块，用于若更新后的第一软件包的运行依赖于第二节点，则对所述第二节点进行检测；所述第二节点为运行或安装所述分布式软件中的第二部分软件的节点；所述第一部分软件与所述第二部分软件相同或至少部分不同；

确定升级成功模块，用于若检测结果表征所述第二节点处于预设运行状态，则当能够运行更新后的所述第一软件包时，确定所述分布式软件升级成功。

9.根据权利要求8中所述的第一节点，其特征在于，所述第一节点还包括：接收模块；

所述接收模块，用于接收主节点分发的至少用于更新第一软件包的所述补丁和/或安装包。

10.根据权利要求8中所述的第一节点，其特征在于，

所述确定升级成功模块，还用于若更新后的第一软件包的运行不依赖于第二节点，则当能够运行更新后的所述第一软件包时确定所述分布式软件升级成功。

11.根据权利要求8中所述的第一节点，其特征在于，

所述状态检测模块，还用于根据预设的检测时间间隔，对所述第二节点安装的所述分布式软件中的第二部分软件的运行状态进行检测。

12.根据权利要求8中所述的第一节点，其特征在于，

所述状态检测模块，还用于若对所述第二节点进行M次检测、且所述M次检测的检测结果均表征所述第二节点不处于所述预设运行状态，并且M次检测的总时长等于预设检测时长，则发送分布式软件升级失败的消息到主节点；其中，M为非0自然数。

13.根据权利要求8中所述的第一节点，其特征在于，

所述状态检测模块，还用于若对所述第二节点连续进行N次检测、且所述N次检测的检测结果均表征所述第二节点不处于所述预设运行状态，则发送分布式软件升级失败消息到主节点；其中，N为预设的检测次数门限值，且为非0自然数。

14.根据权利要求12或13中所述的第一节点，其特征在于，所述版本更新模块，至少还用于以下之一：

当分布式软件升级成功时，若接收到所述主节点发送的回退命令，则将更新后的第一软件包降级为原始版本；

当所述第一软件包更新失败时，若接收到所述主节点发送的回退命令，则停止对所述第一软件包进行更新；

当所述第一软件包更新成功、且不能运行所述更新后的第一软件包时，若接收到所述主节点发送的回退命令，则将更新后的第一软件包降级为原始版本。

Images