A substrate management controller upgrade method, device and medium thereof

Abstract

The application discloses a substrate management controller upgrading method and device and a medium thereof, relates to the technical field of servers, and is used for realizing firmware upgrading of a substrate management controller, aiming at the problem of low upgrading efficiency, providing a substrate management controller upgrading method, deploying a new version of an image to a cloud first; the cloud listens to each file under a system directory of the cloud to determine a file that has an upgrading change, and generates a corresponding upgrading hot patch accordingly; the hot patch is sent to a local substrate management controller, so that the local substrate management controller is deployed and takes effect, and thus local firmware upgrading is completed. In the upgrading process, the cloud distinguishes the difference in version upgrading to generate the corresponding hot patch, realizes incremental updating, and is more efficient than a traditional upgrading mode; in addition, the upgrading mode realized by the hot patch does not require the substrate management controller to restart, can further shorten the time required by the upgrading process, and improves the flexibility of daily maintenance work of the server.

Description

Technical Field

[0001] This application relates to the field of server technology, and in particular to a method, apparatus and medium for upgrading a baseboard management controller. Background Technology

[0002] The baseboard management controller (BMC) is a management system independent of the server's operating system. It monitors and manages the server's status and is a crucial component of server applications. The BMC uses sensors to monitor the status of computers, network servers, and other hardware devices, and communicates with the system administrator via a separate connection to provide various functional services and assist in device management. Therefore, BMC firmware updates are particularly important for the use of servers and similar devices.

[0003] Currently, the mainstream BMC upgrade method involves several stages, including uploading the image, verifying the image, flashing the image, and restarting the BMC, before the image can be activated and the new version can take effect. This upgrade process is lengthy, and various services are unavailable during the upgrade, resulting in a poor user experience. Furthermore, this upgrade method requires a complete upgrade process even for minor changes, making this approach, which focuses on small modifications but has a long upgrade time, increasingly unable to meet the needs of users' actual applications.

[0004] Therefore, those skilled in the art urgently need a method for upgrading the baseboard management controller (BMC) to solve the problem of long upgrade times currently in the BMC process. Summary of the Invention

[0005] The purpose of this application is to provide a method, apparatus and medium for upgrading a baseboard management controller (BMC) to solve the problem of long upgrade time in the current BMC upgrade process.

[0006] To address the aforementioned technical problems, this application provides a method for upgrading a baseboard management controller, comprising:

[0007] Monitor the system directory of the cloud-based baseboard management controller for any file upgrades or modifications;

[0008] Generate corresponding hot patches based on the files that have been upgraded and modified;

[0009] Send the hot patch to the local baseboard management controller and deploy and activate the hot patch.

[0010] On the other hand, generating corresponding hot patches based on the files that have undergone upgrade changes includes:

[0011] Based on the system directory path of the files that have undergone upgrades and modifications, the corresponding hot patches are categorized into the corresponding directories, and corresponding compressed files are generated.

[0012] Accordingly, sending the hot patch to the local baseboard management controller includes:

[0013] Send the compressed file to the local baseboard management controller.

[0014] On the other hand, the deployment and activation of hot patches include:

[0015] Parse the compressed file and generate a corresponding upgrade list based on the name and directory of each hot patch;

[0016] Complete the deployment and activation of each hot patch on the local baseboard management controller according to the upgrade list.

[0017] On the other hand, before the deployment and activation of each hot patch on the local baseboard management controller are completed according to the upgrade list, the following steps are also included:

[0018] Obtain the service processes related to the upgrade list in the local baseboard management controller and generate the corresponding process mapping table;

[0019] Stop the corresponding service process in the local baseboard management controller according to the process mapping table;

[0020] Accordingly, after completing the deployment and activation of each hot patch on the local baseboard management controller according to the upgrade list, the process also includes:

[0021] Restore stopped service processes based on the process mapping table.

[0022] On the other hand, after generating the corresponding process mapping table, it also includes:

[0023] Perform deduplication on duplicate service processes in the process mapping table.

[0024] On the other hand, after generating the corresponding process mapping table, it also includes:

[0025] Determine the dependencies between service processes in the process mapping table;

[0026] The order in which service processes are stopped or started is determined based on dependencies, and the process mapping table is reorganized.

[0027] On the other hand, it also includes:

[0028] When an error occurs during the deployment of a hot patch on the local baseboard management controller, the corresponding error message is returned to the cloud baseboard management controller.

[0029] To address the aforementioned technical problems, this application also provides a substrate management controller upgrade device, comprising:

[0030] Upgrade the monitoring module to monitor whether there are any file upgrades or changes in the system directory of the cloud-based baseboard management controller;

[0031] The patch generation module is used to generate corresponding hot patches based on files that have undergone upgrade changes.

[0032] The patch deployment module is used to send hot patches to the local baseboard management controller and deploy and activate the hot patches.

[0033] On the other hand, the patch generation module mentioned above is specifically used to: classify the generated hot patches into the corresponding directories according to the system directory path of the files that have undergone upgrade changes, and generate the corresponding compressed package files.

[0034] Correspondingly, the above-mentioned patch deployment module's sending of hot patches to the local baseboard management controller specifically means: sending the compressed package file to the local baseboard management controller.

[0035] On the other hand, the deployment and activation of hot patches in the aforementioned patch deployment module specifically includes: parsing the compressed file, generating a corresponding upgrade list based on the name and directory of each hot patch, and completing the deployment and activation of each hot patch on the local baseboard management controller based on the upgrade list.

[0036] On the other hand, the aforementioned substrate management controller upgrade device also includes:

[0037] The process stop module is used to obtain the service processes related to the upgrade list in the local baseboard management controller and generate the corresponding process mapping table; and stop the corresponding service processes in the local baseboard management controller according to the process mapping table.

[0038] The process recovery module is used to recover stopped service processes based on the process mapping table.

[0039] On the other hand, the aforementioned substrate management controller upgrade device also includes:

[0040] The process deduplication module is used to remove duplicate service processes from the process mapping table.

[0041] On the other hand, the aforementioned substrate management controller upgrade device also includes:

[0042] The process management module is used to determine the dependencies between service processes in the process mapping table; based on the dependencies, it determines the order in which service processes should be stopped or started, and then reorganizes the process mapping table.

[0043] On the other hand, the aforementioned substrate management controller upgrade device also includes:

[0044] The anomaly alarm module is used to return corresponding error information to the cloud-based baseboard management controller when an anomaly occurs during the deployment of hot patches on the local baseboard management controller.

[0045] To address the aforementioned technical problems, this application also provides a substrate management controller upgrade device, comprising:

[0046] Memory, used to store computer programs;

[0047] The processor is used to execute computer programs to implement the steps of the baseboard management controller upgrade method described above.

[0048] To address the aforementioned technical problems, this application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the aforementioned baseboard management controller upgrade method.

[0049] This application provides a method for upgrading a baseboard management controller (BMC), which achieves unified firmware upgrade management of the local BMC through a BMC deployed on a cloud server. When a firmware upgrade of the BMC is required, the image of the new version is first deployed to the cloud. The cloud BMC monitors all files in its system directory to identify files that have been modified for the upgrade and generates corresponding hot patches accordingly. The obtained hot patches are then sent to the local BMC for deployment and activation, thereby completing the version upgrade of the local BMC. In the BMC upgrade process described above, the cloud distinguishes the differentiated parts in this version upgrade and generates hot patch files for the upgrade, achieving incremental updates. Compared with traditional upgrade methods, this method is more efficient and takes less time. Furthermore, this application uses hot patches to upgrade the BMC, eliminating the need for BMC restarts. This further shortens the BMC upgrade process time, improves the flexibility of daily server maintenance, and reduces operational costs.

[0050] The substrate management controller upgrade device and computer-readable storage medium provided in this application correspond to the above method and have the same effect. Attached Figure Description

[0051] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0052] Figure 1 A flowchart of a baseboard management controller upgrade method provided by the present invention;

[0053] Figure 2 An application architecture diagram of a baseboard management controller upgrade method provided by the present invention;

[0054] Figure 3 A module interaction diagram for a baseboard management controller upgrade method provided by the present invention;

[0055] Figure 4 A schematic diagram of the working principle of a packaging module provided by the present invention;

[0056] Figure 5 A flowchart of a deployment module provided by the present invention;

[0057] Figure 6 A structural diagram of a baseboard management controller upgrade device provided by the present invention;

[0058] Figure 7 This is a structural diagram of another baseboard management controller upgrade device provided by the present invention. Detailed Implementation

[0059] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0060] The core of this application is to provide a method, apparatus and medium for upgrading a baseboard management controller.

[0061] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0062] In current server applications, the baseboard management controller (BMC) typically monitors and manages the server's status and provides interfaces to users to meet specific operational needs. Correspondingly, as a management system independent of the server's operating system, the BMC's functionality requires firmware support. As application needs change, engineers release continuously updated BMC firmware versions, necessitating upgrades to the current BMC firmware.

[0063] The common BMC upgrade process generally consists of several stages: uploading the image, verifying the image, flashing the image, and restarting the BMC. Only after completing this entire upgrade process can the BMC activate the new version image and make the new firmware effective. This BMC upgrade process is time-consuming, and this comprehensive firmware upgrade renders all BMC functions unavailable during the process. Consequently, users cannot use the services provided by the BMC during the upgrade, which is increasingly unacceptable to users given the lengthy upgrade process, especially when the changes in the updated version content are minimal.

[0064] In routine server maintenance, common upgrade scenarios often involve upgrading only a few applications within the Base Management Console (BMC) or modifying certain configurations within the BMC, while leaving most other applications unchanged. Therefore, the traditional BMC upgrade method described above is more suitable for major version releases (i.e., significant changes between versions) than for routine maintenance upgrades.

[0065] Therefore, based on the above problems, this application provides a method for upgrading a baseboard management controller, taking into account the characteristics of routine maintenance and upgrades. Figure 1 As shown, it includes:

[0066] S11: Monitor whether there are any file upgrades or changes in the system directory of the cloud-based baseboard management controller.

[0067] S12: Generates corresponding hot patches based on files that have undergone upgrade changes.

[0068] S13: Send the hot patch to the local baseboard management controller and perform the deployment and activation operation for the hot patch.

[0069] It should be noted that the upgrade method provided in this application is applied to BMCs deployed in the cloud and on-premises respectively, and its architecture is as follows: Figure 2 As shown, the cloud and local devices interact via wireless communication or other communication methods. Regarding BMC upgrades, this application primarily refers to upgrading the local BMC. This local BMC is not necessarily singular; it can be multiple BMCs, which can also be BMCs located in different geographical locations, all managed by this method using the same firmware upgrade mechanism.

[0070] Whenever a BMC firmware upgrade is required, the administrator uploads the new version of the BMC firmware image to the cloud BMC for upgrade. The cloud BMC upgrade process can utilize existing BMC upgrade procedures. After the cloud BMC upgrade is complete, according to step S11, the system monitors the cloud BMC file system to check for any file changes due to the upgrade. Specifically, one possible implementation of step S11 is as follows:

[0071] Monitor the specified path in the cloud-based BMC file system; the application to be upgraded, the lib (a computer file format) library, and the configuration command (config) file in the new version image can only be configured and made effective after they have been compiled and generated by the cloud code. Specifically, the newly compiled target upgrade file is deployed to the specified directory to overwrite the old version file so that the upgrade takes effect; therefore, monitoring whether there are any upgrade changes in the system directory in step S11 is to monitor whether the above-mentioned target upgrade file has been compiled and generated.

[0072] Once the cloud detects file upgrade changes in the file system, it generates a corresponding hot patch file based on these modified files, which is step S12. The hot patch in step S12 is generated for the modified parts of the BMC firmware. Consequently, when this hot patch file is sent to the local BMC for deployment, the firmware upgrade performed by the local BMC is an incremental upgrade, which is more efficient than traditional upgrade methods. Furthermore, this incremental update method using hot patches on the local BMC does not require a restart, further improving upgrade efficiency while allowing other un-upgraded service processes to maintain their original functionality, thus improving the user experience.

[0073] For step S13, after the hot patch file for incremental update is generated through the above steps, the cloud sends the hot patch file to the local BMC. The cloud also sends an upgrade command to the local BMC, so that the local BMC enters the upgrade process according to the received hot patch file.

[0074] It should also be noted that the hot patch files mentioned above for BMC firmware upgrades are intended to enable online updates without resetting or restarting. If there are other needs in actual applications, incremental updates of the local BMC can also be achieved through other means besides hot patches.

[0075] As described above, the BMC upgrade method implemented in this application is based on information interaction between the cloud and the local machine. The cloud is primarily responsible for generating hot patch files for incremental updates based on the differences before and after the version update. After sending the generated hot patch files to the local BMC and deploying them, incremental updates to the local BMC are achieved. Therefore, a communication connection is required between the cloud and the local machine. However, this embodiment does not limit the specific communication connection method used between the two and should be determined based on the actual deployment scenario.

[0076] Specifically, the cloud and local machines should interact based on the same communication protocol. Common communication protocols include 4G / 5G (4th generation mobile communication technology / 5th generation mobile communication technology), Wi-Fi, and Bluetooth. Furthermore, this embodiment also provides several specific implementation schemes for different communication protocols used in different server deployment scenarios, including:

[0077] 1. For scenarios involving centralized deployment of small-scale cluster servers;

[0078] In this scenario, the server deployment is relatively small and concentrated, and the maximum communication distance between servers (i.e., between the cloud and the local machine) is controllable. Generally, wireless communication within a range of 20-30 meters is sufficient to meet the communication requirements. Bluetooth protocol can be selected to achieve low-cost wireless communication.

[0079] 2. For scenarios involving centralized deployment of medium-sized cluster servers;

[0080] Similar to small-scale centralized deployment scenarios, the maximum communication distance between servers in medium-scale deployment scenarios is relatively larger than that in small-scale scenarios, generally within the range of 50-200 meters. In this case, choosing the Wi-Fi protocol can achieve wireless communication between the cloud and the local area.

[0081] 3. Edge server scenario;

[0082] Edge computing, broadly defined, is a form of distributed computing where primary processing and data storage are located at the edge nodes of a network. With the rapid development of the Internet of Things (IoT) and mobile internet, the number of front-end devices and the amount of data generated are growing exponentially. More and more data needs to be stored, analyzed, and processed at the network edge, posing a significant challenge to edge computing capabilities. Therefore, edge server solutions have emerged in the industry.

[0083] Edge servers are distributed open platforms that integrate core capabilities of networking, computing, storage, and applications, located close to the edge of the device or network. They provide edge intelligence services locally, meeting the critical needs of various industries in areas such as agile connectivity, real-time business operations, data optimization, application intelligence, and security and privacy protection. Because they need to be close to the edge, edge servers are often deployed outdoors or in remote environments; therefore, many edge server products now incorporate built-in wireless communication modules. Base station signals based on 4G / 5G communication protocols have the characteristics of wide coverage and long distance. The 4G / 5G communication protocols are highly compatible with edge servers, which can greatly expand the server's computing power and deployment scenarios.

[0084] This application scenario is somewhat unique compared to the previous two. Server deployment is no longer centralized, and the physical distance between servers far exceeds that of the aforementioned scenarios. However, thanks to the excellent signal coverage of current 4G / 5G base stations, the communication needs of server edge deployment scenarios can be well met. Furthermore, since the BMC upgrade method provided in this application is an incremental update scheme implemented through hot patch files, the generated incremental upgrade packages are very small, and current 4G / 5G uplink and downlink speeds can achieve processing within seconds. Therefore, the BMC upgrade scheme provided in this application has significant advantages over traditional upgrade schemes currently used in edge deployment scenarios in terms of performance, versatility, and user experience.

[0085] The aforementioned communication connections can be deployed in the form of communication modules in both the cloud-based BMC and the local BMC. The corresponding communication protocol can be selected based on the server deployment scenario to maintain a stable communication connection between the cloud and the local machine, thereby meeting the communication requirements for BMC upgrades and realizing the aforementioned lightweight incremental upgrade mode, which is better suited to the daily maintenance needs of the server.

[0086] This application provides a baseboard management controller (BMC) upgrade method that utilizes a cloud-based BMC to perform differential analysis of firmware updates, extracting the modified upgrade components and generating corresponding hot patch files. These hot patch files are then sent to the local BMC for a lightweight incremental update. Firstly, the hot patches generated by this upgrade method only address the differences between the version before and after the update, making it more efficient than traditional full updates. Secondly, the incremental update approach using hot patches eliminates the need for a restart during the upgrade process, enabling online firmware upgrades. Thirdly, BMC applications and service processes not covered in the incremental update remain unaffected, continuing to provide services and a better user experience. Furthermore, the BMC incremental upgrade solution provided by this application better suits daily server maintenance scenarios, solves the problem of difficult edge server maintenance, significantly improves upgrade efficiency, and ensures virtually uninterrupted user experience during BMC upgrades, representing a significant improvement over traditional BMC management server models.

[0087] On the other hand, regarding the specific implementation method of generating corresponding hot patches based on files with upgrade modifications in the file system directory in the cloud-based BMC and sending the hot patches to the local BMC for incremental upgrades, this embodiment provides a possible implementation scheme. The above-mentioned step S12: generating corresponding hot patches based on files with upgrade modifications specifically includes:

[0088] Based on the system directory path of the files that have undergone upgrades and modifications, the corresponding hot patches are categorized into the corresponding directories, and corresponding compressed files are generated.

[0089] Accordingly, sending the hot patch to the local baseboard management controller in step S13 specifically involves:

[0090] Send the compressed file to the local baseboard management controller.

[0091] The implementation method provided in this embodiment is based on the fact that when the cloud-based BMC monitors for file updates, it considers that each file in the BMC file system also has its own directory and other storage paths. Since the firmware version of the cloud-based BMC should be consistent with that of the local BMC before an upgrade, its system directory and the files within that directory should also be consistent. Therefore, when a file upgrade occurs in the cloud-based BMC system directory, determining the filename and directory path of the target upgrade file clarifies the file to be updated and its storage path in the file system when the BMC needs to be upgraded.

[0092] Therefore, in order to further improve the upgrade efficiency of the local BMC, this embodiment classifies and summarizes the files that have undergone upgrade changes as determined by the cloud BMC according to their system directory paths, and generates corresponding compressed files according to the same directory storage logic. The compressed files may contain the same directory structure as the BMC system directory, and store the corresponding hot patch files in the corresponding directories (the compressed files only contain the directories of the files that have undergone upgrade changes and their corresponding hot patch files).

[0093] Thus, when the local BMC receives the compressed file sent by the cloud BMC, it can parse the compressed file to obtain the hot patch file required for subsequent upgrades. Furthermore, the storage directory of the hot patch file in the compressed file is the same as the system directory path of the target upgrade file corresponding to the hot patch in the local BMC. The local BMC can conveniently and quickly deploy the hot patch file.

[0094] Correspondingly, this embodiment also provides a possible implementation scheme for the deployment of hot patches on the local BMC side. The specific deployment and activation of hot patches on the local BMC includes:

[0095] S131: Parse the compressed file and generate a corresponding upgrade list based on the name and directory of each hot patch.

[0096] In one possible implementation, the upgrade list described above can be stored in JavaScript Object Notation (JSON) format, as shown in the following example:

[0097] 1. Filename (“name”): “bmcweb”;

[0098] Directory type ("type"): "bin".

[0099] 2. Filename (“name”): “libgpio”;

[0100] Directory type ("type"): "lib".

[0101] 3. Filename (“name”): “netconfig”;

[0102] Directory type ("type"): "config".

[0103] It is easy to understand that storing the upgrade list in JSON format as described above is only one possible implementation. This embodiment is not limited to using only this one storage method in actual applications of upgrade list storage. Similarly, the upgrade list is not limited to including only the filenames of the hot patch files and their directory types (i.e., the system directory path indicating the corresponding target upgrade file).

[0104] S132: Based on the upgrade list, complete the deployment and activation of each hot patch on the local baseboard management controller.

[0105] It should be noted that, based on the aforementioned upgrade list, the corresponding files requiring upgrades can be found in the local BMC's system directory, and then the hot patches can be deployed to achieve the upgrade. This embodiment does not limit the order of the hot patch files in the upgrade list, nor the deployment order during local deployment, but provides a possible implementation. Before step S132: executing the deployment and activation operation of each hot patch on the local baseboard management controller according to the upgrade list, the above method further includes:

[0106] S133: Obtain the service processes related to the upgrade list in the local baseboard management controller and generate the corresponding process mapping table.

[0107] S134: Stop the corresponding service process in the local baseboard management controller according to the process mapping table.

[0108] Accordingly, after step S132: completing the deployment and activation of each hot patch to the local baseboard management controller according to the upgrade list, the process also includes:

[0109] S135: Resume the stopped service process according to the process mapping table.

[0110] In other words, in real-world BMC management scenarios, the functionalities may be implemented by multiple service processes to support the corresponding services. Therefore, if parsing a compressed file package determines that an application needs a hot patch update, that application must be paused, and its related service processes should also be stopped to prevent errors in other service processes due to the current application update.

[0111] Therefore, this embodiment retrieves the service processes related to the applications corresponding to the hot patches stored in the upgrade list from the local BMC before officially deploying the hot patches, and organizes them into a relevant process mapping table. This embodiment does not limit how or in what form the process mapping table is organized. For example, after determining the correspondence between the hot patch and the application to be upgraded, a corresponding process mapping table can be generated for each application. Then, when upgrading that application, the relevant service processes are shut down according to the process mapping table, and these service processes are restored after deployment takes effect. Alternatively, a unified process mapping table can be generated for all applications identified from the upgrade list after determining their related service processes. Considering that the BMC upgrade method described above implements firmware upgrades through incremental updates, and that each version change is relatively small in daily maintenance scenarios with a short upgrade time, all upgrade-related service processes can be shut down uniformly, all hot patch files can be deployed to make them effective, and then the work of these service processes can be restored. This makes the boundaries between the stages of the entire deployment process clearer, and similar or related tasks can be performed in a concentrated manner (i.e., uniformly shutting down related service processes, deploying hot patches, and restoring related processes), which is beneficial to improving deployment efficiency.

[0112] Furthermore, this embodiment uses OpenBMC (an open-source framework for building complete Linux images for BMC) as an example to illustrate how to obtain the service processes related to the application to be upgraded: based on the hot patch file name in the upgrade list, locate the image / lib / system / system path of the corresponding code package, and save the service processes related to the application therein.

[0113] Regarding how to shut down related service processes, let's take OpenBMC as an example again: OpenBMC uses the system daemon (systemd) to manage processes. Systemd analyzes the dependencies between processes and handles the stopping and starting of service processes concurrently. Similarly, BMC uses initd (a daemon provided by the Linux system) to manage processes, handling the stopping and starting of service processes sequentially.

[0114] Furthermore, when a deployment scheme is adopted that uniformly shuts down and restores all related service processes of various applications, duplicate processes may exist among the related service processes of different applications, and duplicate dependencies may also exist. To address this, this embodiment also provides a possible implementation scheme: after generating the corresponding process mapping table in step S133, the above method further includes:

[0115] S136: Perform deduplication on duplicate service processes in the process mapping table.

[0116] As described above, the deduplication operation in step S136 targets duplicate service processes in the process mapping table, and further includes the dependencies between duplicate processes (also largely caused by duplicate service processes). There are already several mature technical solutions for deduplication given that the deduplication target and scope are determined, so this embodiment will not elaborate further. The deduplication scheme provided in this embodiment can effectively reduce redundant data in the process mapping table and avoid duplicate and invalid operations during the stop and resume operations of service processes, thereby further improving deployment efficiency.

[0117] As mentioned above, there are dependencies between the service processes of BMC, meaning that a certain service process depends on the normal operation of one or more other service processes to function. Therefore, to avoid errors in the current service process due to the shutdown of a dependent service process, the stopping of related service processes in step S134 can be performed in a specific order. Specifically, this embodiment provides a possible implementation scheme: after generating the corresponding process mapping table in step S133, the method further includes:

[0118] S137: Determine the dependencies between service processes in the process mapping table.

[0119] S138: Determine the order in which service processes are stopped or started based on dependencies, and reorganize the process mapping table.

[0120] That is, the process mapping table after being reorganized in steps S137 and S138 not only includes all service processes related to the application to be upgraded, but also includes the shutdown and recovery order determined by the dependency relationship between each service process, thereby realizing the orderly shutdown and recovery between service processes, avoiding the problem of the current service process reporting an error due to the shutdown of other service processes with dependencies, and improving the stability of BMC when performing firmware upgrades.

[0121] On the other hand, the above embodiments provide a specific deployment process after the local BMC receives the compressed package file (patch package) sent by the cloud BMC. Furthermore, this embodiment also provides a preferred implementation scheme, in which the above method further includes:

[0122] S139: When an error occurs during the deployment of a hot patch on the local baseboard management controller, the corresponding error information is returned to the cloud baseboard management controller.

[0123] That is, step S139 is used to monitor whether any abnormalities or errors occur during the execution of steps S131 to S138. If any occur, an alarm is sent to the cloud BMC to promptly inform the relevant management personnel to resolve the abnormality and restore the normal upgrade process of the local BMC.

[0124] To more clearly illustrate the baseboard management controller upgrade method provided in this application, based on the implementation scheme provided in the above embodiments and in combination with actual application scenarios, the method is further explained as follows:

[0125] like Figure 3 A schematic diagram of the modules used to implement the above BMC upgrade method and their information interaction is shown below. Figure 3 As shown, the above upgrade scheme is implemented by the following modules:

[0126] 1. Communication module;

[0127] The communication module is used to enable data interaction between the local machine and the cloud, including the transmission of hot patch compressed packages from the cloud to the local machine, the sending of upgrade commands, and the response to upgrade commands from the local machine to the cloud. The communication module should be configured on both the local machine and the cloud, and both the local and cloud communication modules should adhere to the same communication protocol, enabling the aforementioned information exchange through a wireless communication interface.

[0128] Regarding the communication protocols upon which the current communication module is based, as described in the above embodiments, options include 4G / 5G, Wi-Fi, and Bluetooth. Depending on the different deployment scenarios of the server, the communication protocol can be flexibly selected. For example, Bluetooth communication is suitable for small-scale centralized deployment scenarios, Wi-Fi communication is suitable for medium-scale centralized deployment scenarios, and 4G / 5G communication is suitable for edge server deployment scenarios. The principles and advantages of each deployment scenario and its corresponding selected communication protocol have been explained in detail in the above embodiments, and therefore will not be repeated here.

[0129] 2. Packaging module;

[0130] The packaging module is used to monitor a specified path in the cloud BMC file system to generate hot patches for files that have been upgraded or modified. The obtained hot patches are then categorized according to their respective system directories and a compressed package file with the same directory structure as the system directory is generated. In other words, the packaging module mainly corresponds to step S12 of the above embodiment and is deployed on the cloud BMC.

[0131] For example, both the cloud-based and local BMCs use the Linux file management system, and their corresponding system directories include bin, sbin, lib, config, etc., categorizing different upgrade target files into the corresponding directories, such as... Figure 4 As shown, the corresponding hot patch is compressed into a compressed package and sent to the local BMC. Additionally, the packaging module is also responsible for sending upgrade commands to the local BMC, specifically to the deployment module configured within the local BMC, instructing the local BMC to deploy the hot patch to achieve the firmware upgrade.

[0132] 3. Deployment module;

[0133] The deployment module is located in the local BMC and is used to receive upgrade instructions sent from the packaging module in the cloud via the communication module, download patch packages (compressed files) from the cloud, perform deployment, and reply to the cloud with the corresponding deployment results. That is, the deployment module is used to implement steps S131-S139 in the above embodiments.

[0134] The general process of the deployment module after receiving an upgrade instruction includes: downloading the patch package from the cloud and parsing it; the purpose of parsing is to scan the directories contained in the patch package and the corresponding upgrade files (hot patches) in the directories to generate a corresponding upgrade list; then, based on the names of each upgrade file in the upgrade list, locating the system directory of the local code package, obtaining the service processes related to the application corresponding to the upgrade file, and generating a corresponding process mapping table; before officially deploying the hot patch, deduplicating the process mapping table, sorting out the dependencies between processes, and pausing service processes in a certain order; then, deploying the hot patch according to the upgrade list to complete the firmware upgrade of the local BMC; after all upgrades are completed, resuming the suspended relevant service processes according to the process mapping table, thus completing all deployment operations. However, the deployment module also has an additional function: if any step in the above deployment process encounters an exception, it reports an error message to the cloud; if the deployment is successfully completed, it returns a successful upgrade result to the cloud. The workflow of the deployment module is as follows: Figure 5 As shown.

[0135] The more detailed principles and implementation methods of the above communication module, packaging module and deployment module are explained in the above embodiments, and can be found in the above embodiments section. This embodiment will not repeat them here.

[0136] The above embodiments have described in detail a method for upgrading a baseboard management controller. This application also provides an embodiment corresponding to a baseboard management controller upgrading device. It should be noted that this application describes the device embodiment from two perspectives: one based on functional modules and the other based on hardware.

[0137] From the perspective of functional modules, such as Figure 6 As shown, this embodiment provides a baseboard management controller upgrade device, including:

[0138] Upgrade the monitoring module 21 to monitor whether there are any upgraded or modified files in the system directory of the cloud baseboard management controller;

[0139] Patch generation module 22 is used to generate corresponding hot patches based on files that have undergone upgrade changes;

[0140] The patch deployment module 23 is used to send hot patches to the local baseboard management controller and perform deployment and activation operations on the hot patches.

[0141] On the other hand, the patch generation module mentioned above is specifically used to: classify the generated hot patches into the corresponding directories according to the system directory path of the files that have undergone upgrade changes, and generate the corresponding compressed package files.

[0142] Correspondingly, the above-mentioned patch deployment module's sending of hot patches to the local baseboard management controller specifically means: sending the compressed package file to the local baseboard management controller.

[0143] On the other hand, the deployment and activation of hot patches in the aforementioned patch deployment module specifically includes: parsing the compressed file, generating a corresponding upgrade list based on the name and directory of each hot patch, and completing the deployment and activation of each hot patch on the local baseboard management controller based on the upgrade list.

[0144] On the other hand, the aforementioned substrate management controller upgrade device also includes:

[0145] The process stop module is used to obtain the service processes related to the upgrade list in the local baseboard management controller and generate the corresponding process mapping table; and stop the corresponding service processes in the local baseboard management controller according to the process mapping table.

[0146] The process recovery module is used to recover stopped service processes based on the process mapping table.

[0147] On the other hand, the aforementioned substrate management controller upgrade device also includes:

[0148] The process deduplication module is used to remove duplicate service processes from the process mapping table.

[0149] On the other hand, the aforementioned substrate management controller upgrade device also includes:

[0150] The process management module is used to determine the dependencies between service processes in the process mapping table; based on the dependencies, it determines the order in which service processes should be stopped or started, and then reorganizes the process mapping table.

[0151] On the other hand, the aforementioned substrate management controller upgrade device also includes:

[0152] The anomaly alarm module is used to return corresponding error information to the cloud-based baseboard management controller when an anomaly occurs during the deployment of hot patches on the local baseboard management controller.

[0153] Since the embodiments of the apparatus and the embodiments of the method correspond to each other, please refer to the description of the embodiments of the method for the embodiments of the apparatus, which will not be repeated here.

[0154] This embodiment provides a baseboard management controller (BMC) upgrade method. Through a review and monitoring module, it performs differential analysis on firmware updates, extracts the modified upgrade parts, and generates corresponding hot patch files using a patch generation module. Then, the patch deployment module sends the hot patch files to the local BMC for a lightweight incremental update. The upgrade process implemented by this device generates hot patches only from the differences between the version before and after the update, making it more efficient than traditional full updates. Furthermore, by using incremental updates and hot patches, the local BMC can be upgraded online without restarting. BMC applications and service processes not involved in the incremental update remain unaffected, still providing services and a better user experience. In addition, the BMC incremental upgrade solution provided in this embodiment better suits daily server maintenance scenarios, solves the problem of difficult edge server maintenance, significantly improves upgrade efficiency, and ensures almost uninterrupted user experience during BMC upgrades, representing a significant improvement over traditional BMC management server models.

[0155] Figure 7 A structural diagram of a baseboard management controller upgrade device provided in another embodiment of this application is shown below. Figure 7 As shown, a baseboard management controller upgrade device includes: a memory 30 for storing computer programs;

[0156] The processor 31 is used to execute a computer program to implement the steps of a baseboard management controller upgrade method as described in the above embodiment.

[0157] The baseboard management controller upgrade device provided in this embodiment may include, but is not limited to, baseboard management controllers, servers, and computers.

[0158] The processor 31 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 31 may be implemented using at least one of the following hardware forms: Digital Signal Processor (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 31 may also include a main processor and a coprocessor. The main processor, also known as the Central Processing Unit (CPU), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 31 may integrate a Graphics Processing Unit (GPU), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 31 may also include an Artificial Intelligence (AI) processor, which is used to handle computational operations related to machine learning.

[0159] The memory 30 may include one or more computer-readable storage media, which may be non-transitory. The memory 30 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In this embodiment, the memory 30 is used to store at least the following computer program 301, which, after being loaded and executed by the processor 31, is capable of implementing the relevant steps of a baseboard management controller upgrade method disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 30 may also include an operating system 302 and data 303, and the storage method may be temporary or permanent storage. The operating system 302 may include Windows, Unix, Linux, etc. The data 303 may include, but is not limited to, a baseboard management controller upgrade method.

[0160] In some embodiments, a baseboard management controller upgrade device may further include a display screen 32, an input / output interface 33, a communication interface 34, a power supply 35, and a communication bus 36.

[0161] Those skilled in the art will understand that Figure 7 The structure shown does not constitute a limitation on a single substrate management controller upgrade device and may include more or fewer components than shown.

[0162] This application provides a substrate management controller upgrade device, which includes a memory and a processor. When the processor executes a program stored in the memory, it can implement the following method: a substrate management controller upgrade method.

[0163] This embodiment provides a baseboard management controller (BMC) upgrade device that uses a processor to execute a computer program stored in memory. This program performs differential analysis of firmware updates via a cloud-based BMC, extracting the modified upgrade components and generating corresponding hot patch files. The hot patch files are then sent to the local BMC for a lightweight incremental update. Firstly, the hot patches generated in this upgrade process only address the differences between the version before and after the update, making it more efficient than traditional full updates. Secondly, the incremental update approach using hot patches eliminates the need for a restart during the upgrade process, enabling online firmware upgrades. Thirdly, BMC applications and service processes not covered in the incremental update remain unaffected, continuing to provide services and a better user experience. Furthermore, the BMC incremental upgrade solution provided in this embodiment better suits daily server maintenance scenarios, solves the problem of difficult edge server maintenance, significantly improves upgrade efficiency, and ensures a virtually uninterrupted user experience during BMC upgrades. This represents a significant improvement over traditional BMC management server models.

[0164] Finally, this application also provides an embodiment corresponding to a computer-readable storage medium. The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps described in the above method embodiments (which may be a method corresponding to the cloud-based BMC side, a method corresponding to the local BMC side, or a method corresponding to both the cloud-based BMC side and the local BMC side).

[0165] It is understood that if the methods in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and executes all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0166] This embodiment provides a computer-readable storage medium. When the computer program stored therein is executed, it can perform differential analysis of firmware updates through a cloud-deployed BMC, extracting the modified and upgraded parts and generating corresponding hot patch files. These hot patch files are then sent to the local BMC for lightweight incremental updates. Firstly, the hot patches generated in this upgrade process only address the differences between the version before and after the update, making it more efficient than traditional full updates. Secondly, the incremental update method using hot patches eliminates the need for a restart of the local BMC during the upgrade process, enabling online firmware upgrades. Thirdly, BMC applications and service processes not involved in the incremental update remain unaffected, continuing to provide services and a better user experience. Furthermore, the BMC incremental upgrade solution provided in this embodiment better suits daily server maintenance scenarios, solves the problem of difficult edge server maintenance, significantly improves upgrade efficiency, and ensures almost uninterrupted user experience during BMC upgrades, representing a significant improvement over traditional BMC management server models.

[0167] The foregoing provides a detailed description of a baseboard management controller upgrade method, apparatus, and medium provided in this application. The various embodiments in the specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section. It should be noted that those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of the claims of this application.

[0168] It should also be noted that, in this specification, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Claims

1. A method for upgrading a baseboard management controller, characterized in that, include: Monitor the system directory of the cloud-based baseboard management controller for any file upgrades or modifications; Based on the system directory path of the files that have undergone upgrades and modifications, the corresponding hot patches are categorized into the corresponding directories, and corresponding compressed files are generated. The compressed file is sent to the local baseboard management controller, the compressed file is parsed, and a corresponding upgrade list is generated according to the name and directory of each hot patch; According to the upgrade list, complete the deployment and activation of each hot patch on the local baseboard management controller.

2. The baseboard management controller upgrade method according to claim 1, characterized in that, Before the deployment and activation of each hot patch on the local baseboard management controller according to the upgrade list, the process also includes: Obtain the service processes related to the upgrade list in the local baseboard management controller, and generate the corresponding process mapping table; Stop the corresponding service process in the local baseboard management controller according to the process mapping table; Accordingly, after completing the deployment and activation of each hot patch for the local baseboard management controller according to the upgrade list, the process further includes: Restore the stopped service process according to the process mapping table.

3. The baseboard management controller upgrade method according to claim 2, characterized in that, After generating the corresponding process mapping table, the following is also included: Perform a deduplication operation on the duplicate service processes in the process mapping table.

4. The baseboard management controller upgrade method according to claim 2, characterized in that, After generating the corresponding process mapping table, the following is also included: Determine the dependencies between the service processes in the process mapping table; The order in which the service processes are stopped or started is determined based on the dependencies, and the process mapping table is reorganized.

5. The baseboard management controller upgrade method according to any one of claims 1 to 4, characterized in that, Also includes: When the deployment of the hot patch by the local baseboard management controller fails, the corresponding error information is returned to the cloud baseboard management controller.

6. A baseboard management controller upgrade device, characterized in that, include: Upgrade the monitoring module to monitor whether there are any file upgrades or changes in the system directory of the cloud-based baseboard management controller; The patch generation module is used to classify the generated hot patches into the corresponding directories based on the system directory path of the files that have undergone upgrade changes, and generate the corresponding compressed package files. The patch deployment module is used to send the compressed package file to the local baseboard management controller, parse the compressed package file, and generate a corresponding upgrade list based on the name and directory of each hot patch; According to the upgrade list, complete the deployment and activation of each hot patch on the local baseboard management controller.

7. A baseboard management controller upgrade device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the baseboard management controller upgrade method as described in any one of claims 1 to 5 when executing the computer program.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the baseboard management controller upgrade method as described in any one of claims 1 to 5.

Images