CN117170701A - 一种基板管理控制器升级方法、装置及其介质 - Google Patents

Abstract

本申请公开一种基板管理控制器升级方法、装置及其介质，涉及服务器技术领域，用于实现基板管理控制器的固件升级，针对目前升级效率低的问题，提供一种基板管理控制器升级方法，先将新版本的镜像部署到云端；云端监听自身系统目录下各文件以确定出现升级改动的文件，并据此产生对应的升级热补丁；将热补丁发送到本地基板管理控制器，以便于进行部署并使其生效，从而完成本地的固件升级。在上述升级流程中，由云端区分版本升级中的差异，以生成对应的热补丁，实现增量更新，相比于传统的升级方式效率更高；此外，本申请以热补丁实现的升级方式，无需基板管理控制器进行重启，可以进一步缩短升级流程所需时间，也提高了服务器日常维护工作的灵活性。

Description

一种基板管理控制器升级方法、装置及其介质

技术领域

本申请涉及服务器技术领域，特别是涉及一种基板管理控制器升级方法、装置及其介质。

背景技术

基板管理控制器(baseboard management controller，BMC)是独立于服务器操作系统的管理系统，负责对服务器的状态进行监控和管理，是服务器应用的重要组成部分。BMC利用传感器来监视计算机、网络服务器，或者是其他硬件驱动设备的状态，并且和通过独立的连接线路和系统管理员进行通信，以提供各种功能服务，辅助管理员进行设备管理。由此，BMC固件版本的更新对于服务器等设备的使用也尤为重要。

目前，主流的BMC升级方式要经过上传镜像、校验镜像、刷写镜像、重启BMC等阶段，才能激活镜像并使新版本生效，升级过程时间较长，且升级期间无法提供各类服务，导致用户体验不佳。此外，这种升级方式使得即使版本升级内容改动很小，也需要经历完整的升级过程，这种改动量小但升级时间冗长的实施方案越来越无法满足用户实际应用的需要。

所以，现在本领域的技术人员亟需要一种基板管理控制器升级方法，解决目前在BMC的升级过程中耗时较长的问题。

发明内容

本申请的目的是提供一种基板管理控制器升级方法、装置及其介质，以解决目前在BMC的升级过程中耗时较长的问题。

为解决上述技术问题，本申请提供一种基板管理控制器升级方法，包括：

监听云端基板管理控制器的系统目录中是否有文件出现升级改动；

根据出现升级改动的文件生成对应的热补丁；

将热补丁发送到本地基板管理控制器中，并对热补丁进行部署生效操作。

另一方面，根据出现升级改动的文件生成对应的热补丁包括：

根据出现升级改动的文件所属的系统目录路径，将对应生成的热补丁归类到对应的目录下，并生成对应的压缩包文件；

相应的，将热补丁发送到本地基板管理控制器中包括：

将压缩包文件发送到本地基板管理控制器中。

另一方面，对热补丁进行部署生效操作包括：

解析压缩包文件，根据各热补丁的名称和所属目录生成对应的升级列表；

根据升级列表完成各热补丁对本地基板管理控制器的部署生效操作。

另一方面，在根据升级列表完成各热补丁对本地基板管理控制器的部署生效操作之前，还包括：

获取本地基板管理控制器中与升级列表相关的服务进程，并生成对应的进程映射表；

根据进程映射表停止本地基板管理控制器中对应的服务进程；

相应的，在根据升级列表完成各热补丁对本地基板管理控制器的部署生效操作之后，还包括：

根据进程映射表恢复停止的服务进程。

另一方面，在生成对应的进程映射表之后，还包括：

对进程映射表中重复的服务进程进行去重操作。

另一方面，在生成对应的进程映射表之后，还包括：

确定进程映射表中各服务进程之间的依赖关系；

根据依赖关系确定各服务进程之间停止或启动的先后顺序，并重新整理进程映射表。

另一方面，还包括：

当本地基板管理控制器部署热补丁出现异常时，向云端基板管理控制器返回对应的错误信息。

为解决上述技术问题，本申请还提供一种基板管理控制器升级装置，包括：

升级监听模块，用于监听云端基板管理控制器的系统目录中是否有文件出现升级改动；

补丁生成模块，用于根据出现升级改动的文件生成对应的热补丁；

补丁部署模块，用于将热补丁发送到本地基板管理控制器中，并对热补丁进行部署生效操作。

另一方面，上述的补丁生成模块具体用于：根据出现升级改动的文件所属的系统目录路径，将对应生成的热补丁归类到对应的目录下，并生成对应的压缩包文件。

相应的，上述的补丁部署模块中的将热补丁发送到本地基板管理控制器中具体又为：将压缩包文件发送到本地基板管理控制器中。

另一方面，上述的补丁部署模块中的对热补丁进行部署生效操作具体又包括：解析压缩包文件，根据各热补丁的名称和所属目录生成对应的升级列表；根据升级列表完成各热补丁对本地基板管理控制器的部署生效操作。

另一方面，上述的基板管理控制器升级装置还包括：

进程停止模块，用于获取本地基板管理控制器中与升级列表相关的服务进程，并生成对应的进程映射表；根据进程映射表停止本地基板管理控制器中对应的服务进程。

进程恢复模块，用于根据进程映射表恢复停止的服务进程。

另一方面，上述的基板管理控制器升级装置还包括：

进程去重模块，用于对进程映射表中重复的服务进程进行去重操作。

另一方面，上述的基板管理控制器升级装置还包括：

进程梳理模块，用于确定进程映射表中各服务进程之间的依赖关系；根据依赖关系确定各服务进程之间停止或启动的先后顺序，并重新整理进程映射表。。

另一方面，上述的基板管理控制器升级装置还包括：

异常告警模块，用于当本地基板管理控制器部署热补丁出现异常时，向云端基板管理控制器返回对应的错误信息。

为解决上述技术问题，本申请还提供一种基板管理控制器升级装置，包括：

存储器，用于存储计算机程序；

处理器，用于执行计算机程序时实现如上述的基板管理控制器升级方法的步骤。

为解决上述技术问题，本申请还提供一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时实现如上述的基板管理控制器升级方法的步骤。

本申请提供的一种基板管理控制器升级方法，通过部署在云端服务器的BMC实现对本地BMC的统一固件升级管理。当需要对BMC进行固件升级时，首先将新版本的镜像部署到云端；云端BMC监听自身系统目录下各文件以确定出现升级改动的文件，并据此产生对应的升级热补丁；将上述得到的热补丁发送到本地BMC中，以便于本地BMC部署上述热补丁并使其生效，从而完成本地BMC的版本升级。在上述的BMC升级过程中，由云端区分出本次版本升级中的差异化部分，从而生成对应用于升级的热补丁文件，实现增量更新，相比于传统的升级方式升级效率要更高，升级流程所需时间也更短；此外，本申请以热补丁实现BMC的升级，这种升级方式无需BMC进行重启等操作，在可以进一步的缩短BMC升级流程所需时间的同时，也提高了服务器日常维护工作的灵活性、降低了运维成本。

本申请提供的基板管理控制器升级装置、及计算机可读存储介质，与上述方法对应，效果同上。

附图说明

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

图1为本发明提供的一种基板管理控制器升级方法的流程图；

图2为本发明提供的一种基板管理控制器升级方法的应用架构图；

图3为本发明提供的一种基板管理控制器升级方法的模块交互图；

图4为本发明提供的一种打包模块的工作原理图；

图5为本发明提供的一种部署模块的工作流程图；

图6为本发明提供的一种基板管理控制器升级装置的结构图；

图7为本发明提供的另一种基板管理控制器升级装置的结构图。

具体实施方式

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

本申请的核心是提供一种基板管理控制器升级方法、装置及其介质。

为了使本技术领域的人员更好地理解本申请方案，下面结合附图和具体实施方式对本申请作进一步的详细说明。

在目前的服务器应用中，通常由基板管理控制器(baseboard managementcontroller，BMC)实现对服务器的状态进行监控和管理，并向用户提供接口以满足进行特定操作的需求。相应的，BMC作为独立于服务器操作系统的管理系统，其本身功能实现也需要一定的固件支持，随着应用需要的改变，技术人员会推出版本不断更新的BMC固件，也即需要对当前版本的BMC固件进行升级。

目前较为常见的BMC升级流程大致分为：上传镜像、校验镜像、刷写镜像、重启BMC等几个阶段，需要完整的执行上述升级流程之后，BMC才能够激活新版本的镜像以使新版本的固件生效。上述的BMC升级流程所需时间较长，并且这种BMC固件全面升级的方式使得BMC在升级过程中所有功能不可用。相应的，用户也就无法在BMC升级过程中使用其所提供的服务，这一点在BMC升级流程耗时长的前提下也就愈发的不能被用户所接受，并且在当更新前后版本升级内容改动很小的场景下尤为突出。

在服务器的日常维护场景中，常见的升级场景往往只是针对BMC中的个别应用进行升级，或者仅修改BMC中的某些配置，而其他绝大部分的应用保持不变。因此，上述的BMC传统升级方式更适用于大版本(即两版本之间改动较大)发布场景，而不适用于日常维护升级。

因此，基于上述问题，本申请针对日常维护升级的特点，提供一种基板管理控制器升级方法，如图1所示，包括：

S11：监听云端基板管理控制器的系统目录中是否有文件出现升级改动。

S12：根据出现升级改动的文件生成对应的热补丁。

S13：将热补丁发送到本地基板管理控制器中，并对热补丁进行部署生效操作。

需要说明的是，本申请所提供的升级方法应用于分别部署在云端和本地的BMC中，其架构如图2所示，云端与本地之间通过无线通信或其他通信方式进行消息交互。而对于BMC的升级，本申请主要指的是对本地BMC进行升级，这里的本地BMC不一定仅有一个，可以是多个BMC，且多个本地BMC也可以是分设在不同地理空间中的BMC，由本方法进行同一的固件升级管理。

每当需要进行BMC的固件升级时，管理员将新版本的BMC固件镜像上传至云端BMC中，对其进行升级，云端BMC的升级流程可套用已有的BMC升级流程。当云端BMC升级完成之后，根据步骤S11，监听云端BMC文件系统中是否出现文件出现升级改动。具体的，步骤S11的一种可能的实施方式如下：

监听云端BMC文件系统的指定路径；当新版本镜像中需要升级的应用、lib(一种电脑文件格式)库、配置命令(config)文件经过云端代码编译生成后，才可以进行配置使之生效，具体的也即将新编译生成后的目标升级文件部署至指定目录下覆盖老版本文件以使升级生效；所以步骤S11中的监听系统目录下是否有文件出现升级改动即是监听是否有上述的目标升级文件被编译生成。

当云端监听到文件系统中存在文件升级改动后，即可根据这部分升级改动后的文件生成与之对应的热补丁(patch)文件，也即步骤S12。步骤S12中的热补丁是针对于BMC固件中出现改动的部分所生成的，相应的，当这部分热补丁文件被发送到本地BMC中进行部署时，本地BMC所进行的固件升级也即是增量升级，效率比传统的升级方式要更高。同时，本地BMC这种通过热补丁实现的增量更新方式也无需进行重启，进一步提高升级效率的同时，也使得其他未升级的服务进程可以维持原有的功能实现，提高用户的使用体验。

对于步骤S13，当通过上述步骤生成用于进行增量更新的热补丁文件之后，云端将热补丁文件发送给本地BMC后，云端还用于向本地BMC发送升级指令，使得本地BMC根据接收到的热补丁文件进入升级流程。

还需要说明的是，上述用于实现BMC固件升级的热补丁文件，其目的是为了实现在不复位、重启情况下的在线更新，若实际应用中有其他需要，也可以通过除热补丁之外的其他形式实现本地BMC的增量更新。

由上述可知，本申请所实现的BMC升级方法基于云端和本地的信息交互实现，其中云端主要负责根据版本更新前后的差异，生成用于增量化更新的热补丁文件。将生成的热补丁文件发送到本地BMC并进行部署后，即实现了对本地BMC的增量更新。由此可见，云端与本地之间需要具有通信连接，但对于二者之间所采用的通信连接方式，本实施例对此不做限制，应根据实际部署场景确定。

具体的，云端和本地应基于相同的通信协议实现信息交互，目前常见的通信协议有4G/5G(第4代移动通信技术/第5代移动通信技术)、无线网络通信技术(Wi-Fi)、蓝牙等。进一步的，本实施例还提供几种应用在不同的服务器部署场景中，所采用不同通信协议的具体实施方案，包括：

1、针对小规模集群服务器集中部署的场景；

此场景下服务器部署规模较小且较为集中，服务器与服务器之间(也即云端与本地之间)的最大通信距离可控，一般保证在20-30米范围内的无线通信即可满足通信要求，可以选择蓝牙协议，以实现低成本的无线通信。

2、针对中等规模集群服务器集中部署的场景；

与小规模集中部署的场景类似，中等规模部署场景中服务器与服务器之间的最大通信距离相对小规模场景要更大，一般在50-200米范围内，此时选择Wi-Fi协议即可实现云端和本地的无线通信。

3、边缘服务器场景；

边缘计算，其宽泛定义为一种将主要处理和数据存储放在网络的边缘节点的分布式计算形式。随着物联网和移动互联网的飞速发展，前端设备数量和产生的数据量呈现指数级的增长，越来越多的数据需要在网络边缘进行存储、分析和处理，对边缘计算能力提出了极大挑战。因此业界出现了边缘服务器的产品方案。

边缘服务器即是在靠近端侧或网络边缘侧，融合网络、计算、存储、应用核心能力的分布式开放平台，就近提供边缘智能服务，满足各种行业数字化在敏捷联接、实时业务、数据优化、应用智能、安全与隐私保护等方面的关键需求。由于需要靠近端侧，边缘服务器往往部署在室外或者偏远环境场景，因此目前很多边缘服务器产品都会内置无线通信模块。基于4G/5G通信协议的基站信号具有覆盖广、距离远的特点，4G/5G通信协议与边缘服务器的契合度很高，可以极大扩展服务器的计算能力和部署场景。

本应用场景相对上两个应用场景而言较为特殊，服务器部署不再集中，且服务器与服务器之间的物理距离远远超出上述两种部署场景。但有仗于当前的4G/5G基站的信号覆盖非常完善，可以很好地满足服务器边缘部署场景下的通信需要。同时，由于本申请所提供的一种BMC升级方法是通过热补丁文件实现的增量更新方案，其产生的增量升级包很小，以目前的4G/5G的上行和下行速率完全可以做到秒级处理。因此本申请所提供的一种BMC升级方案对于边缘部署这一场景中，无论从性能、泛用性、用户体验等方面，相对于目前所使用的传统升级方案都具有更为明显的优势。

上述的通信连接可以以通信模块的形式部署在云端BMC和本地BMC中，基于服务器部署场景选择相对应的通信协议，使得云端和本地之间保持稳定的通信连接，从而满足BMC升级所需的通信需求，实现上述的轻量级增量升级模式，更好地适应于服务器的日常维护需要。

本申请所提供的一种基板管理控制器升级方法，通过部署在云端的BMC实现对固件更新的差异化分析，提取出其中的改动升级部分并产生与之对应的热补丁文件；进而通过将热补丁文件发送至本地BMC中，使之进行轻量级的增量式更新。一方面上述升级方法所产生的热补丁仅是由版本更迭前后的差异化部分所产生的，相对于传统升级方式中的全量更新的方式而言其效率更高；并且采取增量更新的形式并通过热补丁实现，可以使得本地BMC在升级过程中无需进行重启，实现BMC固件的在线升级；对于增量更新中所未涉及到的BMC应用以及服务进程，其运行不会受到影响，仍然可以为用户提供一定的服务，给用户带来更好地使用体验。此外，由本申请所提供的BMC增量升级方案更好地契合了服务器的日常维护场景，还解决了边缘服务器维护困难的问题，大幅提高了升级效率，使得在BMC的升级过程中用户体验几乎不中断，是对传统BMC管理服务器模式的重要改进。

另一方面，对于云端BMC根据文件系统目录中出现升级改动的文件对应产生相应的热补丁，并将热补丁发送至本地BMC中以进行增量升级的具体实施方式，本实施例提供一种可能的实施方案，上述的步骤S12：根据出现升级改动的文件生成对应的热补丁具体又包括：

根据出现升级改动的文件所属的系统目录路径，将对应生成的热补丁归类到对应的目录下，并生成对应的压缩包文件；

相应的，步骤S13中的将热补丁发送到本地基板管理控制器中又具体为：

将压缩包文件发送到本地基板管理控制器中。

对于本实施例所提供的实施方式，是出于云端BMC在监听是否有文件更新升级时，考虑到在BMC文件系统中，各文件也是存在文件目录等存放路径，而云端BMC在进行升级前与本地BMC的固件版本应保持一致，故其系统目录以及目录下的文件也应该保持一致。所以当云端BMC系统目录下出现文件升级改动时，确定目标升级文件的文件名以及目录路径即可明确当BMC需要进行升级时，所针对进行更新的文件及其在文件系统中的存储路径。

所以为进一步提高本地BMC的升级效率，本实施例将云端BMC确定出的出现升级改动的文件按照其所属的系统目录路径进行分类汇总，按照相同的目录存放逻辑生成对应的压缩包文件，可以是压缩包中包含与BMC系统目录相同的目录结构，并在相应目录下存储有对应的热补丁文件(压缩包中仅包含出现升级改动的文件目录及其对应的热补丁文件)。

如此，当本地BMC接收到云端BMC发送的压缩包文件后，可以通过解析压缩包文件一方面获取后续进行升级所需的热补丁文件，另一方面该热补丁文件在压缩包中的存储目录与本地BMC中与该热补丁对应的目标升级文件的系统目录路径相同，本地BMC可以方便、快捷地进行热补丁文件的部署。

相应的，对于本地BMC这一侧的热补丁具体的部署方案，本实施例同样提供一种可能的实施方案，本地BMC对热补丁进行部署生效操作具体又包括：

S131：解析压缩包文件，根据各热补丁的名称和所属目录生成对应的升级列表。

在一种可能的实施方式中，上述的升级列表可以按照JS对象简谱(JavaScriptObject Notation，JSON)的格式进行存储，具体的示例如下：

1、文件名(“name”)：“bmcweb”；

目录类型(“type”)：“bin”。

2、文件名(“name”)：“libgpio”；

目录类型(“type”)：“lib”。

3、文件名(“name”)：“netconfig”；

目录类型(“type”)：“config”。

容易理解的是，上述按照JSON的格式存储升级列表仅为一种可能的实施方案，本实施例并不限制于在升级列表存储的实际应用中仅能采用上述的这一种存储方式。同样的，升级列表中也不局限于仅包括热补丁文件所对应的文件名及其所属目录类型(也即指示对应的目标升级文件的系统目录路径)。

S132：根据升级列表完成各热补丁对本地基板管理控制器的部署生效操作。

需要说明的是，基于上述的升级列表可以从本地BMC的系统目录中找到对应需要进行升级的文件，进而将热补丁进行部署以实现升级。对于升级列表中各热补丁文件的排列顺序，以及在进行本地部署时的部署顺序，本实施例不做限制，但提供一种可能的实施方案，在步骤S132：根据升级列表完成各热补丁对本地基板管理控制器的部署生效操作执行之前，上述方法还包括：

S133：获取本地基板管理控制器中与升级列表相关的服务进程，并生成对应的进程映射表。

S134：根据进程映射表停止本地基板管理控制器中对应的服务进程。

相应的，在步骤S132：根据升级列表完成各热补丁对本地基板管理控制器的部署生效操作之后，还包括：

S135：根据进程映射表恢复停止的服务进程。

也即，对于实际应用场景中的BMC管理中，其功能应用可能由多个服务进程共同实现以支持提供对应的服务。因此，若经由压缩文件包的解析确定某一应用存在新版本热补丁需要更新，则该应用需暂停服务，相应的其相关服务进程也应停止，避免因为当前应用的更新导致其他服务进程出现错误。

因此，本实施例通过在正式部署热补丁之前，先从本地BMC中获取与升级列表中存储的热补丁所对应应用相关的服务进程，将其整理为相关的进程映射表。对于进程映射表如何进行整理以及整理成什么形式，本实施例对此不做限制。例如，可以在确定热补丁与待升级应用的对应关系后，为每一个应用生成一个对应的进程映射表，进而在执行该应用的升级时，按照进程映射表关闭相关的服务进程并在部署生效后恢复这部分服务进程。又或者，可以为根据升级列表确定出的所有待升级应用，在确定出其相关的服务进程后，生成统一的一个进程映射表，考虑到上述BMC升级方法是以增量更新的方式实现固件升级，在日常维护场景中每次版本改动量较小，一次版本改动的升级耗时很短，可以统一将所有与升级相关的服务进程进行关闭，再部署所有热补丁文件以使之生效，接着再恢复这部分服务进程的工作，使整个部署流程阶段之间界限更加分明，相同或相近的工作集中实现(即统一关闭相关服务进程、部署热补丁以及恢复相关进程)，有利于部署效率的提升。

此外，对于如何获取与待升级应用相关的服务进程，本实施例以实际应用中的OpenBMC(一种为BMC构建的完整的Linux镜像的开源框架)为例进行说明：根据升级列表中的热补丁文件名称，定位到对应代码包的image/lib/system/system路径，于其中保存与该应用相关的服务进程。

而对于如何关闭相关的服务进程，同样以在OpenBMC中的应用为例：OpenBMC中使用系统守护进程(systemd)管理进程，systemd会分析进程之间的依赖关系，并发的处理服务进程的停止和启动。同理，在BMC使用Linux系统提供的initd(一种守护进程)管理进程，串行的处理服务进程的停止和启动。

进一步的，当采取各应用的所有相关服务进程统一进行关闭与恢复的部署方案时，就可能出现不同应用之间其相关服务进程中有重复的进程存在，同时，也可能存在重复的依赖关系。对此，本实施例还提供一种可能的实施方案，在步骤S133：生成对应的进程映射表之后，上述的方法还包括：

S136：对进程映射表中重复的服务进程进行去重操作。

由上述可知，步骤S136中的去重操作所针对的对象是进程映射表中重复的服务进程，以及进一步的还包括重复的进程之间的依赖关系(也多由重复的服务进程所带来)，具体如何在去重目标和范围确定的前提下进行去重，目前已有多种成熟的技术方案，故本实施例在此不再赘述。本实施例所提供的去重方案可以有效地降低进程映射表中的冗余数据，并在执行服务进程的停止和恢复操作中避免重复、无效操作的出现，以进一步提高部署效率。

又由上述可知，在BMC的服务进程之间，还存在依赖关系，也即某一服务进程需要依赖于另一或另一些服务进程的正常工作才得以进行。如此，为避免因为某一依赖的服务进程被关闭导致当前服务进程报错，在上述步骤S134中的停止相关服务进程时可以按照一定的顺序进行。具体的，本实施例提供一种可能的实施方案，在步骤S133：生成对应的进程映射表之后，上述方法还包括：

S137：确定进程映射表中各服务进程之间的依赖关系。

S138：根据依赖关系确定各服务进程之间停止或启动的先后顺序，并重新整理进程映射表。

也即，在经步骤S137和S138重新整理后的进程映射表，不但包含所有与待升级应用相关的服务进程，还包含各服务进程之间根据依赖关系所确定的关闭、恢复顺序，从而实现服务进程之间的有序关闭、恢复，避免因存在依赖关系的其它服务进程被关闭导致当前服务进程报错的问题出现，提高了在进行固件升级时BMC的稳定性。

另一方面的，上述实施例提供了本地BMC在接收到由云端BMC发送的压缩包文件(补丁包)之后的具体部署流程，进一步的，本实施例还提供一种优选的实施方案，上述方法还包括：

S139：当本地基板管理控制器部署热补丁出现异常时，向云端基板管理控制器返回对应的错误信息。

也即，步骤S139用于监控步骤S131至步骤S138的执行过程中是否出现异常或错误，若出现则向云端BMC进行报警，以及时告知相关管理人员解决异常问题，恢复本地BMC的正常升级流程。

为更清楚地说明本申请所提供的一种基板管理控制器升级方法，基于上述实施例所提供的实施方案，并结合实际应用场景，对本方法做出进一步说明：

如图3，用于实现上述BMC升级方法的模块及其信息交互的示意图如图3所示，上述升级方案由以下模块实现：

1、通信模块；

通信模块用于实现本地与云端之间的数据交互，包括云端到本地的热补丁压缩包传输、升级指令发送，以及本地到云端的升级指令响应等等。对于通信模块的部署应在本地和云端都进行设置，本地和云端的通信模块都遵循同一套通信协议，可通过无线通信接口，完成上述的信息交互工作。

对于当前通信模块所基于的通信协议，如上述实施例所述有4G/5G、Wi-Fi、蓝牙等选择。根据服务器的不同部署场景，通信协议可以灵活选择，如小规模集中部署场景适应于选择蓝牙通信、中等规模集中部署场景适应于选择Wi-Fi通信、边缘服务器部署场景则适应于选择4G/5G通信。对于每一部署场景及其相应选择的通信协议的原理及优势都于上述实施例中进行详细的说明，故本实施例在此不再赘述。

2、打包模块；

打包模块用于监听云端BMC文件系统中的指定路径，以对出现升级改动的文件对应产生热补丁，并将得到的热补丁根据所属系统目录进行归类，生成与系统目录拥有相同目录结构的压缩包文件，也即打包模块主要对应于实现上述实施例的步骤S12，部署于云端BMC。

示例性的，云端和本地BMC都采用Linux文件管理系统，相应的其系统目录就包括bin、sbin、lib、config等目录，将不同的升级目标文件归类到对应目录中，如图4所示，将对应的热补丁压缩成压缩包的形式，发送给本地BMC。另外，打包模块还负责向本地BMC发送升级指令，具体即发送给设置在本地BMC中的部署模块，指示本地BMC进行热补丁部署实现固件升级。

3、部署模块；

部署模块设置在本地BMC中，用于通过通信模块接收来自云端的打包模块发送的升级指令，并从云端中下载补丁包(压缩包文件)，进行部署工作并回复云端相应的部署结果。也即，部署模块用于实现上述实施例中的步骤S131-S139。

部署模块在接受到升级指令后的大致流程包括：从云端下载补丁包，并对其进行解析；解析的目的是扫描补丁包中包含的目录以及目录下对应的升级文件(热补丁)，以生成相应的升级列表；再根据升级列表中各升级文件的名称定位本地代码包的系统目录，获取与该升级文件对应应用相关的服务进程，生成与之对应的进程映射表；在正式部署热补丁之前，先对进程映射表进行去重，并梳理各进程之间的依赖关系，按照一定顺序暂停服务进程；然后根据升级列表部署热补丁完成本地BMC的固件升级；待所有升级完成后再重新根据进程映射表恢复上述暂停的相关服务进程，至此完成所有的部署操作。但部署模块还有额外的职能，即在上述的部署过程中，当任意步骤出现异常时，即向云端上报错误信息，若部署顺利完成，则向云端返回升级成功的结果。部署模块的工作流程如图5所示。

关于上述通信模块、打包模块和部署模块更详细的原理以及实施方式皆于上述实施例中做出了说明，可参见上述实施例部分，本实施例在此不做赘述。

在上述实施例中，对于一种基板管理控制器升级方法进行了详细描述，本申请还提供一种基板管理控制器升级装置对应的实施例。需要说明的是，本申请从两个角度对装置部分的实施例进行描述，一种是基于功能模块的角度，另一种是基于硬件的角度。

基于功能模块的角度，如图6所示，本实施例提供一种基板管理控制器升级装置，包括：

升级监听模块21，用于监听云端基板管理控制器的系统目录中是否有文件出现升级改动；

补丁生成模块22，用于根据出现升级改动的文件生成对应的热补丁；

补丁部署模块23，用于将热补丁发送到本地基板管理控制器中，并对热补丁进行部署生效操作。

另一方面，上述的补丁生成模块具体用于：根据出现升级改动的文件所属的系统目录路径，将对应生成的热补丁归类到对应的目录下，并生成对应的压缩包文件。

相应的，上述的补丁部署模块中的将热补丁发送到本地基板管理控制器中具体又为：将压缩包文件发送到本地基板管理控制器中。

另一方面，上述的补丁部署模块中的对热补丁进行部署生效操作具体又包括：解析压缩包文件，根据各热补丁的名称和所属目录生成对应的升级列表；根据升级列表完成各热补丁对本地基板管理控制器的部署生效操作。

另一方面，上述的基板管理控制器升级装置还包括：

进程停止模块，用于获取本地基板管理控制器中与升级列表相关的服务进程，并生成对应的进程映射表；根据进程映射表停止本地基板管理控制器中对应的服务进程。

进程恢复模块，用于根据进程映射表恢复停止的服务进程。

另一方面，上述的基板管理控制器升级装置还包括：

进程去重模块，用于对进程映射表中重复的服务进程进行去重操作。

另一方面，上述的基板管理控制器升级装置还包括：

进程梳理模块，用于确定进程映射表中各服务进程之间的依赖关系；根据依赖关系确定各服务进程之间停止或启动的先后顺序，并重新整理进程映射表。。

另一方面，上述的基板管理控制器升级装置还包括：

异常告警模块，用于当本地基板管理控制器部署热补丁出现异常时，向云端基板管理控制器返回对应的错误信息。

由于装置部分的实施例与方法部分的实施例相互对应，因此装置部分的实施例请参见方法部分的实施例的描述，这里暂不赘述。

本实施例所提供的一种基板管理控制器升级方法，通过审监庭模块实现对固件更新的差异化分析，提取出其中的改动升级部分并由补丁生成模块产生与之对应的热补丁文件；进而通过补丁部署模块将热补丁文件发送至本地BMC中，使之进行轻量级的增量式更新。由本装置实现的升级流程一方面其所产生的热补丁仅是由版本更迭前后的差异化部分所生成，相对于传统升级方式中的全量更新的方式而言其效率更高；并且采取增量更新的形式并通过热补丁实现，可以使得本地BMC在升级过程中无需进行重启，实现BMC固件的在线升级；对于增量更新中所未涉及到的BMC应用以及服务进程，其运行不会受到影响，仍然可以为用户提供一定的服务，给用户带来更好地使用体验。此外，由本实施例所提供的BMC增量升级方案更好地契合了服务器的日常维护场景，还解决了边缘服务器维护困难的问题，大幅提高了升级效率，使得在BMC的升级过程中用户体验几乎不中断，是对传统BMC管理服务器模式的重要改进。

图7为本申请另一实施例提供的一种基板管理控制器升级装置的结构图，如图7所示，一种基板管理控制器升级装置包括：存储器30，用于存储计算机程序；

处理器31，用于执行计算机程序时实现如上述实施例一种基板管理控制器升级方法的步骤。

本实施例提供的一种基板管理控制器升级装置可以包括但不限于基板管理控制器、服务器、以及计算机等。

其中，处理器31可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器31可以采用数字信号处理器(Digital Signal Processor，DSP)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)、可编程逻辑阵列(Programmable LogicArray，PLA)中的至少一种硬件形式来实现。处理器31也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称中央处理器(CentralProcessing Unit，CPU)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器31可以集成有图像处理器(Graphics Processing Unit，GPU)，GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器31还可以包括人工智能(Artificial Intelligence，AI)处理器，该AI处理器用于处理有关机器学习的计算操作。

存储器30可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是非暂态的。存储器30还可包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。本实施例中，存储器30至少用于存储以下计算机程序301，其中，该计算机程序被处理器31加载并执行之后，能够实现前述任一实施例公开的一种基板管理控制器升级方法的相关步骤。另外，存储器30所存储的资源还可以包括操作系统302和数据303等，存储方式可以是短暂存储或者永久存储。其中，操作系统302可以包括Windows、Unix、Linux等。数据303可以包括但不限于一种基板管理控制器升级方法等。

在一些实施例中，一种基板管理控制器升级装置还可包括有显示屏32、输入输出接口33、通信接口34、电源35以及通信总线36。

本领域技术人员可以理解，图7中示出的结构并不构成对一种基板管理控制器升级装置的限定，可以包括比图示更多或更少的组件。

本申请实施例提供的一种基板管理控制器升级装置，包括存储器和处理器，处理器在执行存储器存储的程序时，能够实现如下方法：一种基板管理控制器升级方法。

本实施例所提供的一种基板管理控制器升级装置，通过处理器执行保存在存储器中的计算机程序，以通过部署在云端的BMC实现对固件更新的差异化分析，提取出其中的改动升级部分并产生与之对应的热补丁文件；进而通过将热补丁文件发送至本地BMC中，使之进行轻量级的增量式更新。一方面上述升级流程中所产生的热补丁仅是由版本更迭前后的差异化部分所产生的，相对于传统升级方式中的全量更新的方式而言其效率更高；并且采取增量更新的形式并通过热补丁实现，可以使得本地BMC在升级过程中无需进行重启，实现BMC固件的在线升级；对于增量更新中所未涉及到的BMC应用以及服务进程，其运行不会受到影响，仍然可以为用户提供一定的服务，给用户带来更好地使用体验。此外，由本实施例所提供的BMC增量升级方案更好地契合了服务器的日常维护场景，还解决了边缘服务器维护困难的问题，大幅提高了升级效率，使得在BMC的升级过程中用户体验几乎不中断，是对传统BMC管理服务器模式的重要改进。

最后，本申请还提供一种计算机可读存储介质对应的实施例。计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时实现如上述方法实施例(可以是云端BMC侧对应的方法、也可以是本地BMC侧对应的方法，还可以是云端BMC侧和本地BMC侧对应的方法)中记载的步骤。

可以理解的是，如果上述实施例中的方法以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

本实施例所提供的一种计算机可读取存储介质，当其中存储的计算机程序被执行时，可以通过部署在云端的BMC实现对固件更新的差异化分析，提取出其中的改动升级部分并产生与之对应的热补丁文件；进而通过将热补丁文件发送至本地BMC中，使之进行轻量级的增量式更新。一方面上述升级流程中所产生的热补丁仅是由版本更迭前后的差异化部分所产生的，相对于传统升级方式中的全量更新的方式而言其效率更高；并且采取增量更新的形式并通过热补丁实现，可以使得本地BMC在升级过程中无需进行重启，实现BMC固件的在线升级；对于增量更新中所未涉及到的BMC应用以及服务进程，其运行不会受到影响，仍然可以为用户提供一定的服务，给用户带来更好地使用体验。此外，由本实施例所提供的BMC增量升级方案更好地契合了服务器的日常维护场景，还解决了边缘服务器维护困难的问题，大幅提高了升级效率，使得在BMC的升级过程中用户体验几乎不中断，是对传统BMC管理服务器模式的重要改进。

以上对本申请所提供的一种基板管理控制器升级方法、装置及其介质进行了详细介绍。说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以对本申请进行若干改进和修饰，这些改进和修饰也落入本申请权利要求的保护范围内。

还需要说明的是，在本说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

Claims (10)

1.一种基板管理控制器升级方法，其特征在于，包括：

监听云端基板管理控制器的系统目录中是否有文件出现升级改动；

根据出现升级改动的文件生成对应的热补丁；

将所述热补丁发送到本地基板管理控制器中，并对所述热补丁进行部署生效操作。

2.根据权利要求1所述的基板管理控制器升级方法，其特征在于，所述根据出现升级改动的文件生成对应的热补丁包括：

根据出现升级改动的文件所属的系统目录路径，将对应生成的所述热补丁归类到对应的目录下，并生成对应的压缩包文件；

相应的，将所述热补丁发送到本地基板管理控制器中包括：

将所述压缩包文件发送到本地基板管理控制器中。

3.根据权利要求2所述的基板管理控制器升级方法，其特征在于，对所述热补丁进行部署生效操作包括：

解析所述压缩包文件，根据各所述热补丁的名称和所属目录生成对应的升级列表；

根据所述升级列表完成各所述热补丁对所述本地基板管理控制器的部署生效操作。

4.根据权利要求3所述的基板管理控制器升级方法，其特征在于，在根据所述升级列表完成各所述热补丁对所述本地基板管理控制器的部署生效操作之前，还包括：

获取所述本地基板管理控制器中与所述升级列表相关的服务进程，并生成对应的进程映射表；

根据所述进程映射表停止所述本地基板管理控制器中对应的所述服务进程；

相应的，在根据所述升级列表完成各所述热补丁对所述本地基板管理控制器的部署生效操作之后，还包括：

根据所述进程映射表恢复停止的所述服务进程。

5.根据权利要求4所述的基板管理控制器升级方法，其特征在于，在生成对应的进程映射表之后，还包括：

对所述进程映射表中重复的所述服务进程进行去重操作。

6.根据权利要求4所述的基板管理控制器升级方法，其特征在于，在生成对应的进程映射表之后，还包括：

确定所述进程映射表中各所述服务进程之间的依赖关系；

根据所述依赖关系确定各所述服务进程之间停止或启动的先后顺序，并重新整理所述进程映射表。

7.根据权利要求1至6任意一项所述的基板管理控制器升级方法，其特征在于，还包括：

当所述本地基板管理控制器部署所述热补丁出现异常时，向所述云端基板管理控制器返回对应的错误信息。

8.一种基板管理控制器升级装置，其特征在于，包括：

升级监听模块，用于监听云端基板管理控制器的系统目录中是否有文件出现升级改动；

补丁生成模块，用于根据出现升级改动的文件生成对应的热补丁；

补丁部署模块，用于将所述热补丁发送到本地基板管理控制器中，并对所述热补丁进行部署生效操作。

9.一种基板管理控制器升级装置，其特征在于，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现如权利要求1至7任意一项所述的基板管理控制器升级方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至7任意一项所述的基板管理控制器升级方法的步骤。