热补丁升级方法、系统、电子设备及存储介质

技术领域

本发明涉及通信技术领域，具体而言，涉及一种热补丁升级方法、系统、电子设备及存储介质。

背景技术

采用虚拟化技术将物理的分布式网络设备虚拟化为多个分布式网络虚拟设备，每个分布式网络虚拟设备中的主用主控卡、备用主控卡以及业务卡上也运行业务软件。对于当前版本的业务软件存在的缺陷，可以采用热补丁进行修复。

由于热补丁需要在不重启设备的情况下动态生效运行，意味着升级热补丁时所有分布式网络虚拟设备需要在线运行热补丁包来完成升级生效。而通常的热补丁升级方式是在每个分布式网络虚拟设备中存储一份相同的热补丁包，会造成大量的磁盘资源被浪费。

发明内容

为了克服现有技术的不足，本发明实施例提供了一种热补丁升级方法、装置、电子设备和计算机可读存储介质。

本发明实施例的技术方案可以这样实现：

第一方面，本发明实施例提供一种热补丁升级方法，应用于电子设备，所述电子设备上部署有管理设备和多个虚拟设备，所述方法包括：

所述管理设备的主用主控卡获取用户输入命令，所述用户输入命令包括需升级热补丁的虚拟设备的业务卡的地址信息；

所述管理设备的主用主控卡基于需升级热补丁的虚拟设备的业务卡的地址信息，发送热补丁包至需升级热补丁的虚拟设备的业务卡，以进行热补丁升级。

可选地，所述管理设备的主用主控卡基于需升级热补丁的虚拟设备的业务卡的地址信息，发送热补丁包至需升级热补丁的虚拟设备的业务卡的步骤包括：

若所述业务卡在位、且满足预设升级条件，则所述管理设备的主用主控卡按照所述地址信息，向所述业务卡发送升级准备指令，以使所述业务卡进行升级准备操作；

所述管理设备的主用主控卡接收所述业务卡返回的针对所述升级准备指令的响应消息；

若所述响应消息表征所述升级准备操作成功执行，则所述管理设备的主用主控卡按照所述业务卡的地址信息，向所述业务卡发送所述热补丁包。

可选地，所述方法还包括：

若所述管理设备的主用主控卡向每个所述虚拟设备的业务卡均发送了所述热补丁包，则在预设时间内按照每个所述虚拟设备的业务卡的地址信息，向每个所述虚拟设备的业务卡发送升级执行指令；

每个所述虚拟设备的业务卡基于所述升级执行指令，进行所述热补丁包的本地安装，并返回针对所述升级执行指令的响应消息给所述管理设备的主用主控卡。

可选地，所述方法还包括：

若每个所述虚拟设备返回的针对所述升级执行指令的响应消息均表征所述热补丁包的本地安装成功执行，则若所述管理设备的主用主控卡将所述热补丁包进行存储；

若所述管理设备的备用主控卡在位，则所述管理设备的主用主控卡将所述热补丁包备份至所述管理设备的备用主控卡。

可选地，所述方法还包括：

发生重启的虚拟设备的业务卡按照所述管理设备的主用主控卡的地址信息，向所述管理设备的主用主控卡发送热补丁查询请求，所述热补丁查询请求包括需重新升级的热补丁的信息；

所述管理设备的主用主控卡根据需重新升级的热补丁的信息，返回用于重新升级热补丁的热补丁包至发生重启的虚拟设备的业务卡，以重新进行热补丁升级。

可选地，所述管理设备的主用主控卡基于需升级热补丁的虚拟设备的业务卡的地址信息，发送热补丁包至需升级热补丁的虚拟设备的业务卡的步骤包括：

所述管理设备的主用主控卡根据所述业务卡的地址信息，确定所述业务卡的归属虚拟设备的主用主控卡的地址信息；

所述管理设备的主用主控卡按照所述归属虚拟设备的主用主控卡的地址信息，发送升级准备指令至所述归属虚拟设备的主用主控卡，所述升级准备指令携带有所述业务卡的地址信息；

若所述业务卡在位、且满足预设升级条件，则所述归属虚拟设备的主用主控卡按照所述业务卡的地址信息，将所述升级准备指令转发至所述业务卡，以使所述业务卡进行升级准备操作；

所述归属虚拟设备的主用主控卡将所述业务卡返回的针对所述升级准备指令的响应消息，转发至所述管理设备的主用主控卡；

若所述响应消息表征所述升级准备操作成功执行，则所述管理设备的主用主控卡按照所述归属虚拟设备的主用主控卡的地址信息，向所述归属的虚拟设备的主用主控卡发送所述热补丁包；

所述归属虚拟设备的主用主控卡按照所述业务卡的地址信息，将所述热补丁包转发至所述业务卡。

可选地，所述方法还包括：

发生重启的业务卡按照自身的归属虚拟设备的主用主控卡的地址信息，向所述归属虚拟设备的主用主控卡发送热补丁查询请求，所述热补丁查询请求包括需重新升级的热补丁的信息；

若所述归属虚拟设备为所述管理设备，则所述归属虚拟设备的主用主控卡根据需重新升级的热补丁的信息，返回用于重新升级热补丁的热补丁包至发生重启的业务卡；

若所述归属虚拟设备不为所述管理设备，所述归属虚拟设备的主用主控卡将所述热补丁查询请求转发至所述管理设备的主用主控卡；

所述归属虚拟设备的主用主控卡将所述管理设备的主用主控返回的用于重新升级热补丁的热补丁包转发至发生重启的业务卡，以重新进行热补丁升级。

第二方面，本发明实施例提供一种热补丁升级装置，应用于电子设备，所述电子设备上部署有管理设备和多个虚拟设备，所述热补丁升级装置包括所述管理设备的主用主控卡和每个所述虚拟设备的业务卡；

所述管理设备的主用主控卡，用于获取用户输入命令，所述用户输入命令包括需升级热补丁的虚拟设备的业务卡的地址信息；

所述管理设备的主用主控卡，还用于基于需升级热补丁的虚拟设备的业务卡的地址信息，发送热补丁包至需升级热补丁的虚拟设备的业务卡，以进行热补丁升级。

第三方面，本发明实施例提供一种电子设备，其包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现如前述第一方面所述的热补丁升级方法。

第四方面，本发明提供一种计算机可读存储介质，其存储有计算机程序，所述计算机程序被处理器执行时实现如前述第一方面所述的热补丁升级方法。

相较于现有技术，本发明实施例提供的一种热补丁升级方法、装置、电子设备及存储介质，首先，管理设备的主用主控卡获取用户输入命令，其中，用户输入命令包括需升级热补丁的虚拟设备的业务卡的地址信息；然后，管理设备的主用主控卡基于需升级热补丁的虚拟设备的业务卡的地址信息，发送热补丁包至需升级热补丁的虚拟设备的业务卡，以进行热补丁升级。由于本发明实施例管理设备的主用主控卡基于需升级热补丁的虚拟设备的业务卡的地址信息，发送热补丁包至需升级热补丁的虚拟设备的业务卡，无需在每个虚拟设备中均存储一份相同的热补丁包，从而避免了大量的磁盘资源被浪费。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本发明实施例提供的一种应用场景示意图；

图2为本发明实施例提供的一种热补丁升级方法的流程示意图一；

图3为本发明实施例提供的一种虚拟设备间通信通道的示例图一；

图4为本发明实施例提供的一种热补丁升级方法的流程示意图二；

图5为本发明实施例提供的一种热补丁升级过程的信令交互图一；

图6为本发明实施例提供的一种虚拟设备间通信通道的示例图二；

图7为本发明实施例提供的一种热补丁升级过程的信令交互图二；

图8为本发明实施例提供的一种热补丁升级装置的结构示意图；

图9为本发明实施例提供的一种电子设备的结构示意图。

图标：100-热补丁升级装置；101-管理设备的主用主控卡；102-虚拟设备的业务卡；103-管理设备的备用主控卡；104-虚拟设备的主用主控卡；200-电子设备；210-存储器；220-处理器。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。

因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

需要说明的是，在不冲突的情况下，本发明的实施例中的特征可以相互结合。

虚拟化技术(例如虚拟化技术、容器技术、多进程技术)是一种将底层物理设备与上层操作系统、应用程序进行分离去耦合的技术。虚拟化技术作为云计算平台的一种重要支撑技术，可极大的提高物理设备的资源使用效率。特别是分布式网络设备，随着设备中物理板卡、内存、CPU、磁盘等资源的不断增加、性能的不断提升，使用虚拟化技术可以将这些资源划分给不同的租户，以提高设备的整体利用率。

热补丁是一种快速、低成本修复设备软件版本缺陷的方式。相较于直接升级软件版本，热补丁的主要优势是不会使设备当前正在运行的业务中断，即在不重启设备的情况下，可以对设备当前软件版本的缺陷进行修复。

分布式网络设备虚拟化后，得到的每个分布式虚拟网络设备中的主用主控卡、备用主控卡以及业务卡也需要运行业务软件，对于当前版本的业务软件存在的缺陷，可以采用热补丁进行修复。由于热补丁需要在不重启设备的情况下动态生效运行，意味着升级热补丁时所有分布式网络虚拟设备需要在线运行热补丁包来完成升级生效。

当前实现方式是每个分布式虚拟网络设备内部自己完成热补丁包的升级功能，即在每个分布式虚拟网络设备内部，均存在同样的热补丁升级命令和操作流程。

如图1所示，一台物理的分布式网络设备虚拟出三套分布式虚拟网络设备(以下简称虚拟设备)，分别为虚拟设备0、虚拟设备1和虚拟设备2，其中，业务卡0被划分给虚拟设备0，业务卡1和业务卡2被划分给虚拟设备2，业务卡3被划分给虚拟设备2。

按照现有的方式，业务卡0的热补丁升级由虚拟设备0完成，业务卡1和业务卡2的热补丁升级由虚拟设备1完成，业务卡3的热补丁升级由虚拟设备2完成，即各虚拟设备通过各自的终端接口(虚拟串口、ssh等)操作完成热补丁的升级操作。

这种方式虽然能够达到完成升级热补丁的目的，但存在管理操作不便的问题，需要超级管理员登录到每个分布式虚拟网络设备中去完成热补丁的升级，同时还需要在每个分布式虚拟网络设备中存储一份热补丁包，造成了大量的磁盘资源浪费。

为了克服现有技术的不足，减少磁盘资源的浪费，本发明实施例提供了一种热补丁升级方法，下面将进行详细介绍。

请参照图2，该热补丁升级方法包括步骤S101和S102。

S101，管理设备的主用主控卡获取用户输入命令。

其中，用户输入命令包括需升级热补丁的虚拟设备的业务卡的地址信息。

在本发明实施例中，管理设备可以为物理的分布式网络设备虚拟出的任一虚拟设备，例如，管理设备可以为图1中的虚拟设备0。

物理的分布式网络设备系统启动后，用户可以通过命令客户端界面，例如SecureCRT，登录管理设备，在管理设备主主控卡上输入命令update hotpatch xxx(即用户输入命令)，命令参数“xxx”为需升级热补丁的虚拟设备的业务卡的地址信息。

作为一种可能的实现方式，地址信息可以为四维地址，其格式可以为<虚拟设备域号-堆叠设备号-业务板槽位号-芯片号>，其中，虚拟设备域号用于区分不同的虚拟设备，堆叠设备号用于区分不同的堆叠，业务板槽位号用于区分不同的业务卡，芯片号用于区分业务卡上不同的芯片组。

作为另一种可能的实现方式，地址信息还可以为unix域地址。

在本发明实施例中，用户还可以通过命令客户端界面，例如SecureCRT，登录管理设备，在管理设备主主控卡上输入命令delete hotpatch xxx，命令参数“xxx”为需删除热补丁的虚拟设备的业务卡的地址信息。

同样地，用户也可以通过命令客户端界面，例如SecureCRT，登录管理设备，在管理设备主主控卡上输入命令getinfo hotpatch xxx，命令参数“xxx”为需获取热补丁状态的虚拟设备的业务卡的地址信息。

S102，管理设备的主用主控卡基于需升级热补丁的虚拟设备的业务卡的地址信息，发送热补丁包至需升级热补丁的虚拟设备的业务卡，以进行热补丁升级。

如图3所示，管理设备的主用主控卡通过四维地址空间或unix域等方式，打通其与业务卡1、业务卡2及业务卡3之间的通信通道，热补丁包统一存储在管理设备的磁盘上，通过管理设备与业务卡1、业务卡2及业务卡3之间的通信通道，将热补丁包发送至业务卡1、业务卡2及业务卡3进行热补丁升级。

针对图3所示的情形，本发明实施例提供了一种步骤S102可能的实现方式。

在可能的实现方式中，步骤S102可以包括子步骤S102-10～S102-12。

S102-10，若业务卡在位、且满足预设升级条件，则管理设备的主用主控卡按照地址信息，向业务卡发送升级准备指令，以使业务卡进行升级准备操作。

分布式网络设备进行虚拟化后，针对虚拟出的每个业务卡，若该业务卡被确定了归属的虚拟设备，则意味着该业务卡“在位”，若该业务卡没有被确定归属的虚拟设备，则意味着该业务卡“不在位”。

预设升级条件是指业务卡上当前的热补丁版本不为最新版本，且业务卡的剩余磁盘空间大于升级热补丁所需的磁盘空间。

由于虚拟设备的业务卡的配置管理均由用户通过命令客户端界面，例如SecureCRT，登录管理设备，在管理设备主主控卡上输入命令来实现，所以管理设备的主用主控卡根据自身存储的关于业务卡的配置管理记录，可以获知业务卡是否在位，以及是否满足预设升级条件。

管理设备的主用主控卡发送给业务卡的升级准备指令携带有管理设备的主用主控卡的地址信息、热补丁包文件名、热补丁包大小等信息。

业务卡在接收到管理设备的主用主控卡发送的升级准备指令后，进行的升级准备操作可以包括判断本地内存资源是否充足，创建热补丁包接收文件等。

S102-11，管理设备的主用主控卡接收业务卡返回的针对升级准备指令的响应消息。

S102-12，若响应消息表征升级准备操作成功执行，则管理设备的主用主控卡按照业务卡的地址信息，向业务卡发送热补丁包。

根据热补丁包的大小，其传送过程可能持续往返多次，直到热补丁包传送完成。

可以理解地，当响应消息表征升级准备操作未成功执行时，管理设备的主用主控卡则不向业务卡发送热补丁包，并返回表征热补丁升级失败的指示内容至命令客户端界面，以告知用户。

为了对上述方法作进一步介绍，本发明实施例以图3所示的业务卡1作为需级热补丁的虚拟设备的业务卡进行以下举例说明。

请参照图4，按照本发明实施例提供的上述方法对业务卡1进行热补丁升级的过程如下：

步骤S1：管理设备的主用主控卡获取用户通过命令客户端界面输入的用户输入命令；

步骤S2：管理设备的主用主控卡判断业务卡1是否在位、且满足预设升级条件；

步骤S3：管理设备的主用主控卡在判断到业务卡1在位、且满足预设升级条件，基于用户输入命令中携带的业务卡1的地址信息，向业务卡1发送升级准备指令；

步骤S4：业务卡1在接收到升级准备指令后，进行升级准备操作；

步骤S5：业务卡1在执行完升级准备操作后，根据升级准备指令中携带的管理设备的主用主控卡的地址信息，返回用于表征升级准备操作是否成功执行的响应消息至管理设备的主用主控卡。

步骤S6：管理设备的主用主控卡判断响应消息是否表征升级准备操作成功执行；

步骤S7：管理设备的主用主控卡在判断到响应消息表征升级准备操作成功执行后，向业务卡1发送用于升级的热补丁的热补丁包。

为了保证每个虚拟设备的业务卡上热补丁版本的一致性，每个虚拟设备的业务卡需同时运行相同的热补丁包来完成升级生效。也就是说，每个虚拟设备的业务卡接收到管理设备的主用主控卡传送的热补丁包的时间有先后，但运行热补丁包的时间是相同的。

对此，基于图3所示的情形，请参照图5，该热补丁升级方法还包括步骤S201～S204。

S201，若管理设备的主用主控卡向每个虚拟设备的业务卡均发送了热补丁包，则在预设时间内按照每个虚拟设备的业务卡的地址信息，向每个虚拟设备的业务卡发送升级执行指令。

示例性地，假设图3中的管理设备的主用主控卡先后向业务卡0、业务卡1、业务卡2以及业务卡3发送了热补丁包A，在预设时间23:00，同时向业务卡0、业务卡1、业务卡2以及业务卡3发送升级执行指令。

S202，每个虚拟设备的业务卡基于升级执行指令，进行热补丁包的本地安装，并返回针对升级执行指令的响应消息给管理设备的主用主控卡。

可以理解地，任意一个业务卡须在接收到管理设备的主用主控卡发送的升级执行指令后，才会运行之前接收到的热补丁包，进行本地安装，从而升级热补丁。

需要注意地是，每个业务卡在进行热补丁包的本地安装前，还需对热补丁包进行检测，例如热补丁包的大小正确性检测、检验码正确性检测等。

请再次参照图5，该热补丁升级方法还包括步骤S105～S106。

S203，若每个虚拟设备返回的针对升级执行指令的响应消息均表征热补丁包的本地安装成功执行，则若管理设备的主用主控卡将热补丁包进行存储。

在本发明实施例中，管理设备的主用主控卡将热补丁包存储在本地磁盘中，以在后续任何业务卡发生重启后，能重新发送相应的热补丁包，使其重新进行热补丁升级。

S204，若管理设备的备用主控卡在位，则管理设备的主用主控卡将热补丁包备份至管理设备的备用主控卡。

其中，“管理设备的备用主控卡在位”是指分布式网络设备进行虚拟化后，针对虚拟出的所有备用主控卡中，存在归属于管理设备的备用主控卡。

在本发明实施例中，为了应对管理设备的主用主控卡发生异常时，热补丁升级操作依然能顺利进行，管理设备的主用主控卡将存在在其本地磁盘中的热补丁包备份在备用主控卡的本地磁盘上。

由于任一已经安装了热补丁包的业务卡发生重启，在重启后已经安装的热补丁包是需要重新安装、运行、生效的，且需要在业务卡的基础业务软件启动的早期阶段就需要完成热补丁包的重新安装，从而在运行生效过程中对尽可能多的业务软件的缺陷进行修复。

基于图3所示的情形，对业务卡重启后热补丁包进行重新安装的实现过程可以如下：

首先，发生重启的虚拟设备的业务卡按照管理设备的主用主控卡的地址信息，向管理设备的主用主控卡发送热补丁查询请求.

其中，热补丁查询请求包括需重新升级的热补丁的信息，热补丁的信息包括热补丁版本等；

然后，管理设备的主用主控卡根据需重新升级的热补丁的信息，返回用于重新升级热补丁的热补丁包至发生重启的虚拟设备的业务卡，以重新进行热补丁升级。

在本发明实施例中，管理设备的主用主控卡返回用于重新升级热补丁的热补丁包至发生重启的虚拟设备的业务卡的实现过程与步骤S102-10～S102-12展示的实现过程相同，在此不再进行赘述。

由于每个虚拟设备的主用主控卡上也运行业务软件，如图3所示，管理设备的主用主控卡也可以通过四维地址空间或unix域等方式，打通其与虚拟设备1的主用主控卡和虚拟设备2的主用主控卡之间的通信通道，通过管理设备与虚拟设备1的主用主控卡和虚拟设备2的主用主控卡之间的通信通道，将热补丁包发送至虚拟设备1的主用主控卡和虚拟设备2的主用主控卡进行热补丁升级。

同样地，当任意虚拟设备中存在备用主控卡、且备用主控卡也运行有业务软件时，也可以通过四维地址空间或unix域等方式，打通管理设备的主用主控卡与该虚拟设备的备用主控卡之间的通信通道，通过管理设备与该虚拟设备的备用主控卡之间的通信通道，将热补丁包发送至该虚拟设备的备用主控卡之间进行热补丁升级。

对于虚拟设备的主用主控卡和备用主控卡进行热补丁升级的实现原理与上述方法实施例相同，在此不再进行赘述。

如图6所示，管理设备的主用主控卡通过四维地址空间或unix域等方式，打通其与虚拟设备1的主用主控卡和虚拟设备2的主用主控卡之间的通信通道，虚拟设备1的主用主控卡与业务卡1和业务卡2之间的通信通道，以及虚拟设备2的主用主控卡与业务卡3之间的通信通道。

热补丁包统一存储在管理设备的磁盘上，通过管理设备的主用主控卡与虚拟设备1的主用主控卡、虚拟设备2的主用主控卡之间的通信通道，将热补丁包发送至虚拟设备1的主用主控卡和虚拟设备2的主用主控卡，再通过虚拟设备1的主用主控卡与业务卡1和业务卡2之间的通信通道将热补丁包发送至业务卡1和业务卡2，虚拟设备2的主用主控卡与业务卡3之间的通信通道将热补丁包发送至业务卡3，进行热补丁升级。

针对图6所示的情形，本发明实施例提供了另一种步骤S102可能的实现方式。

在可能的实现方式中，步骤S102可以包括子步骤S102-20～S102-25。

S102-20，管理设备的主用主控卡根据业务卡的地址信息，确定业务卡的归属虚拟设备的主用主控卡的地址信息。

示例性地，如图6所示，业务卡1的归属虚拟设备为虚拟设备1，管理设备的主用主控卡根据业务卡1的地址信息，可以确定虚拟设备1的主用主控卡的地址信息。

S102-21，管理设备的主用主控卡按照归属虚拟设备的主用主控卡的地址信息，发送升级准备指令至归属虚拟设备的主用主控卡。

其中，升级准备指令携带有业务卡的地址信息。

S102-22，若业务卡在位、且满足预设升级条件，则归属虚拟设备的主用主控卡按照业务卡的地址信息，将升级准备指令转发至业务卡，以使业务卡进行升级准备操作。

其中，转发给业务卡的升级准备指令携带有归属虚拟设备的主用主控卡的地址信息。

业务卡在执行完判断本地内存资源是否充足，创建热补丁包接收文件等升级准备操作后，按照归属虚拟设备的主用主控卡的地址信息，返回用于表征升级准备操作是否成功执行的响应消息至归属虚拟设备的主用主控卡。

S102-23，归属虚拟设备的主用主控卡将业务卡返回的针对升级准备指令的响应消息，转发至管理设备的主用主控卡。

S102-24，若响应消息表征升级准备操作成功执行，则管理设备的主用主控卡按照归属虚拟设备的主用主控卡的地址信息，向归属的虚拟设备的主用主控卡发送热补丁包。

S102-25，归属虚拟设备的主用主控卡按照业务卡的地址信息，将热补丁包转发至业务卡。

为了对上述方法作进一步介绍，本发明实施例以图3所示的业务卡1作为需级热补丁的虚拟设备的业务卡进行以下举例说明。

请参照图7，按照本发明实施例提供的上述方法对业务卡1进行热补丁升级的过程如下：

步骤S1：管理设备的主用主控卡获取用户通过命令客户端界面输入的用户输入命令；

步骤S2：管理设备的主用主控卡基于用户输入命令中携带的业务卡1的地址信息，确定业务卡1的归属虚拟设备(虚拟设备1)的主用主控卡的地址信息，并按照那个虚拟设备1的主用主控卡的地址信息，向虚拟设备1的主用主控卡发送升级准备指令；

步骤S3：虚拟设备1的主用主控卡判断业务卡1是否在位、且满足预设升级条件；

步骤S4：虚拟设备1的主用主控卡在判断到业务卡1在位、且满足预设升级条件，按照升级准备指令中携带的业务卡1的地址信息，向业务卡1转发升级准备指令；

步骤S5：业务卡1在接收到升级准备指令后，进行升级准备操作；

步骤S6：业务卡1在执行完升级准备操作后，根据升级准备指令中携带的虚拟设备1的主用主控卡的地址信息，返回用于表征升级准备操作是否成功执行的响应消息至虚拟设备1的主用主控卡；

步骤S7：虚拟设备1的主用主控卡再将响应消息转发给管理设备的主用主控卡；

步骤S8：管理设备的主用主控卡判断响应消息是否表征升级准备操作成功执行；

步骤S9：管理设备的主用主控卡在判断到响应消息表征升级准备操作成功执行后，向虚拟设备1的主用主控卡发送用于升级的热补丁的热补丁包；

步骤S10：虚拟设备1的主用主控卡再将热补丁包转发给业务卡1。

需要注意地是，为了保证每个虚拟设备的业务卡上热补丁版本的一致性，管理设备的主用主控卡统一向每个虚拟设备的主用主控卡发送升级执行指令，每个虚拟设备的主用主控卡再将升级执行指令转发给各自的业务卡。

基于图6所示的情形，对业务卡重启后热补丁包进行重新安装的实现过程可以如下：

首先，发生重启的业务卡按照自身的归属虚拟设备的主用主控卡的地址信息，向归属虚拟设备的主用主控卡发送热补丁查询请求。

其中，热补丁查询请求包括需重新升级的热补丁的信息；

此时存在以下两种情况：

情况一、若归属虚拟设备为管理设备，则归属虚拟设备的主用主控卡根据需重新升级的热补丁的信息，返回用于重新升级热补丁的热补丁包至发生重启的业务卡；

情况二、若归属虚拟设备不为管理设备，归属虚拟设备的主用主控卡将热补丁查询请求转发至管理设备的主用主控卡；

归属虚拟设备的主用主控卡将管理设备的主用主控返回的用于重新升级热补丁的热补丁包转发至发生重启的业务卡，以重新进行热补丁升级。

由于图6所示的情形中，管理设备的主用主控卡与虚拟设备1的主用主控卡和虚拟设备2的主用主控卡之间通信通道已打通，因此，管理设备的主用主控卡可以直接通过其与虚拟设备1的主用主控卡和虚拟设备2的主用主控卡之间通信通道，将热补丁包发送至对虚拟设备1的主用主控卡和虚拟设备2的主用主控卡进行热补丁升级。

同样地，当任意虚拟设备中存在备用主控卡、且备用主控卡也运行有业务软件时，也可以通过四维地址空间或unix域等方式，打通管理设备的主用主控卡与该虚拟设备的备用主控卡之间的通信通道，通过管理设备与该虚拟设备的备用主控卡之间的通信通道，将热补丁包发送至该虚拟设备的备用主控卡之间进行热补丁升级。

对于虚拟设备的主用主控卡和备用主控卡进行热补丁升级的实现原理与上述方法实施例相同，在此不再进行赘述。

需要注意地是，上述方法实施例不仅适用于单台物理的分布式网络设备虚拟后的热补丁升级，同样也适用于堆叠环境的主设备和从设备虚拟化后的热补丁升级，以及集中式网络设备虚拟后的热补丁升级，在此不再进行赘述。

相较于现有技术，本发明实施例具备以下技术效果：

(1)由管理设备的主用主控卡存储用于升级热补丁的热补丁包，在接收到用户输入命令后，基于需升级的虚拟设备的业务卡的地址信息，将热补丁包发送至需升级的虚拟设备的业务卡，从而无需在每个虚拟设备中均存储一份相同的热补丁包，避免了大量的磁盘资源被浪费。

(2)管理设备的主用主控卡通过四维地址空间或unix域等方式，打通其与各虚拟设备的业务卡之间的通信通道，或打通其与各虚拟设备的主用主控卡之间的通信通道，以及各虚拟设备的主用主控卡与对应的业务卡之间的通信通道，从而使用户只需通过命令客户端界面，登录管理设备，在管理设备主主控卡上输入相应命令来管理各虚拟设备的业务卡的热补丁升级，无需超级管理员登录到每个虚拟设备中去完成热补丁升级，简化操作流程，降低操作出错概率。

为了执行上述方法实施例及各个可能的实施方式中的相应步骤，下面给出一种热补丁升级装置100的实现方式。

请参照图8，该热补丁升级装置包括管理设备的主用主控卡101、多个虚拟设备的业务卡102、管理设备的备用主控卡103以及多个虚拟设备的主用主控卡104。

管理设备的主用主控卡101，用于获取用户输入命令，用户输入命令包括需升级热补丁的虚拟设备的业务卡102的地址信息。

管理设备的主用主控卡101，还用于基于需升级热补丁的虚拟设备的业务卡102的地址信息，发送热补丁包至需升级热补丁的虚拟设备的业务卡102，以进行热补丁升级。

可选地，管理设备的主用主控卡101具体用于若需升级热补丁的虚拟设备的业务卡102在位、且满足预设升级条件，则按照需升级热补丁的虚拟设备的业务卡102的地址信息，向需升级热补丁的虚拟设备的业务卡102发送升级准备指令，以使需升级热补丁的虚拟设备的业务卡102进行升级准备操作；接收需升级热补丁的虚拟设备的业务卡102返回的针对升级准备指令的响应消息；若响应消息表征升级准备操作成功执行，则按照需升级热补丁的虚拟设备的业务卡102的地址信息，向需升级热补丁的虚拟设备的业务卡102发送所述热补丁包。

可选地，管理设备的主用主控卡101还用于若向每个虚拟设备的业务卡102均发送了热补丁包，则在预设时间内按照每个虚拟设备的业务卡102的地址信息，向每个虚拟设备的业务卡102发送升级执行指令。

每个虚拟设备的业务卡102用于基于升级执行指令，进行热补丁包的本地安装，并返回针对升级执行指令的响应消息给管理设备的主用主控卡101。

可选地，管理设备的主用主控卡101还用于若每个虚拟设备的业务卡102返回的针对升级执行指令的响应消息均表征热补丁包的本地安装成功执行，则将热补丁包进行存储；若管理设备的备用主控卡103在位，则将热补丁包备份至管理设备的备用主控卡103。

可选地，发生重启的虚拟设备的业务卡102用于按照管理设备的主用主控卡101的地址信息，向管理设备的主用主控卡101发送热补丁查询请求，热补丁查询请求包括需重新升级的热补丁的信息。

管理设备的主用主控卡101还用于根据需重新升级的热补丁的信息，返回用于重新升级热补丁的热补丁包至发生重启的虚拟设备的业务卡102，以重新进行热补丁升级。

可选地，管理设备的主用主控卡101还具体用于根据需升级热补丁的虚拟设备的业务卡102的地址信息，确定需升级热补丁的虚拟设备的业务卡102的归属虚拟设备的主用主控卡104的地址信息；按照归属虚拟设备的主用主控卡104的地址信息，发送升级准备指令至归属虚拟设备的主用主控卡104，升级准备指令携带有需升级热补丁的虚拟设备的业务卡102的地址信息。

归属虚拟设备的主用主控卡104用于若需升级热补丁的虚拟设备的业务卡102在位、且满足预设升级条件，则按照需升级热补丁的虚拟设备的业务卡102的地址信息，将升级准备指令转发至需升级热补丁的虚拟设备的业务卡102，以使需升级热补丁的虚拟设备的业务卡102进行升级准备操作；将需升级热补丁的虚拟设备的业务卡102返回的针对升级准备指令的响应消息，转发至管理设备的主用主控卡101。

管理设备的主用主控卡还用于若响应消息表征升级准备操作成功执行，则按照归属虚拟设备的主用主控卡104的地址信息，向归属的虚拟设备的主用主控卡104发送热补丁包。

归属虚拟设备的主用主控卡104还用于按照需升级热补丁的虚拟设备的业务卡102的地址信息，将热补丁包转发至需升级热补丁的虚拟设备的业务卡102。

可选地，发生重启虚拟设备的业务卡102还用于按照自身的归属虚拟设备的主用主控卡104的地址信息，向归属虚拟设备的主用主控卡104发送热补丁查询请求，热补丁查询请求包括需重新升级的热补丁的信息。

归属虚拟设备的主用主控卡104还用于若归属虚拟设备为管理设备，则根据需重新升级的热补丁的信息，返回用于重新升级热补丁的热补丁包至发生重启的虚拟设备的业务卡102；

归属虚拟设备的主用主控卡104还用于若归属虚拟设备不为管理设备，则将热补丁查询请求转发至管理设备的主用主控卡101；将管理设备的主用主控返回的用于重新升级热补丁的热补丁包转发至发生重启的虚拟设备的业务卡102，以重新进行热补丁升级。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的热补丁升级装置100的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

进一步地，本发明实施例还提供了一种电子设备200，请参照图9，电子设备200可以包括存储器210和处理器220。

其中，处理器220可以是一个通用的中央处理器(Central Processing Unit，CPU)，微处理器，特定应用集成电路(Application-Specific Integrated Circuit，ASIC)，或一个或多个用于控制上述方法实施例提供的热补丁升级方法的程序执行的集成电路。

存储器210可以是ROM或可存储静态信息和指令的其它类型的静态存储设备，RAM或者可存储信息和指令的其它类型的动态存储设备，也可以是电可擦可编程只读存储器(Electrically Erasable Programmabler-Only MEMory，EEPROM)、只读光盘(CompactdiscRead-Only MEMory，CD-ROM)或其它光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其它磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其它介质，但不限于此。存储器210可以是独立存在，通过通信总线与处理器220相连接。存储器210也可以和处理器220集成在一起。其中，存储器210用于存储执行本申请方案的机器可执行指令。处理器220用于执行存储器210中存储的机器可执行指令，以实现上述的方法实施例。

本发明实施例还提供一种包含计算机程序的计算机可读存储介质，计算机程序在被执行时可以用于执行上述的方法实施例提供的热补丁升级方法中的相关操作。

综上，本发明实施例提供的一种热补丁升级方法、装置、电子设备及存储介质，首先，管理设备的主用主控卡获取用户输入命令，其中，用户输入命令包括需升级热补丁的虚拟设备的业务卡的地址信息；然后，管理设备的主用主控卡基于需升级热补丁的虚拟设备的业务卡的地址信息，发送热补丁包至需升级热补丁的虚拟设备的业务卡，以进行热补丁升级。由于本发明实施例管理设备的主用主控卡基于需升级热补丁的虚拟设备的业务卡的地址信息，发送热补丁包至需升级热补丁的虚拟设备的业务卡，无需在每个虚拟设备中均存储一份相同的热补丁包，从而避免了大量的磁盘资源被浪费。

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