Hot update method and device for embedded management module, equipment and medium

Abstract

The invention discloses a hot updating method and device of an embedded management module, equipment and a medium, and relates to the field of computers, the hot updating method comprises the following steps: executing decompression on an upgrading file subjected to security verification to obtain a to-be-upgraded embedded management module and an upgrading sequence of each embedded management module; reading a mirror image file of the current embedded management module from the upgrading file according to the upgrading sequence, and creating a new container instance of the current embedded management module based on the mirror image file; sending a health query request to the new container instance to trigger a verification process of the new container instance, and switching a service running in the old container instance to the new container instance after a verification result representing health of the new container instance is received; and skipping to the step of reading the mirror image file of the current embedded management module until all the embedded management modules finish hot updating. When the single embedded management module is updated, the whole system does not need to be restarted, and the problem that restarting must be interrupted is solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, in particular to a hot updating method and device of embedded management module, equipment and medium. BACKGROUND

[0002] In modern data center and cloud computing infrastructure, the stable operation of server hardware resources is crucial. As the core component of server out-of-band management, the embedded management module, such as baseboard management controller (BMC), is responsible for providing hardware state monitoring, firmware updating and other functions, and its own availability and reliability directly affect the maintainability of the entire server.

[0003] At present, the upgrade of embedded management module firmware generally adopts the updating method of writing the whole firmware image and restarting the embedded management module system. This traditional method has significant inherent defects: during the updating process, the embedded management module must interrupt all ongoing remote management sessions, performance monitoring and log collection services and perform restart, resulting in a period of unavailable service blackout. This not only prevents operation and maintenance personnel from managing the server during this period, but also causes the interruption and loss of monitoring data, seriously affecting the continuity of business and the reliability of the system. Although there are some efforts in the industry to reduce the interruption time, such as setting up asynchronous updates, this does not fundamentally solve the core problem of "restarting must interrupt". Therefore, the above technical problems need to be solved by technical personnel in the field. SUMMARY

[0004] Therefore, the purpose of the present application is to provide a hot updating method, device, equipment and medium of embedded management module, which does not need to perform restart operation on the whole system when updating a single embedded management module, solves the problem of "restarting must interrupt", and the specific scheme is as follows:

[0005] In a first aspect, the present application discloses a hot updating method of embedded management module, comprising:

[0006] Performing decompression operation on the upgrade file that has passed the preset security check to obtain all embedded management modules to be upgraded and the upgrade order of each embedded management module;

[0007] Reading the image file of the current embedded management module from the upgrade file according to the upgrade order, and creating a new container instance of the current embedded management module based on the image file;

[0008] sending a health query request to the new container instance to trigger a verification procedure of the new container instance, and switching the service running on the old container instance to the new container instance after receiving a verification result representing the health of the new container instance, so as to realize the hot update of the current embedded management module;

[0009] jumping to the step of reading the image file of the current embedded management module from the upgrade file according to the upgrade sequence until all the embedded management modules complete the hot update.

[0010] Optionally, until all the embedded management modules complete the hot update, the method further comprises:

[0011] sending a self-check command to all the embedded management modules, so that each embedded management module starts an internal self-check procedure based on the self-check command and generates a state identifier and self-check data after completing the self-check procedure; wherein the self-check command comprises a module identifier field and a to-be-checked item field, the module identifier field is used to uniquely identify the embedded management module, and the to-be-checked item field is used to explicitly indicate the detection task to be performed by the embedded management module;

[0012] obtaining the state identifier and the self-check data returned by each embedded management module;

[0013] if the state identifier represents that the current running state of the embedded management module meets the preset requirement and the self-check data meets the preset range, it is determined that the self-check passes, and a cleaning procedure of the old container instance is started and a corresponding hot update completion event information is recorded;

[0014] if the state identifier represents that the current running state of the embedded management module does not meet the preset requirement or the self-check data does not meet the preset range, it is determined that the self-check does not pass, and a reverse recovery operation of the old container instance is performed according to the upgrade sequence, and then a cleaning procedure of the new container instance is started and a corresponding hot update failure event information is recorded.

[0015] Optionally, the container instance implements independent management and control of the environment based on a process-level sandbox isolation mechanism of the container architecture, and different embedded management modules realize data interaction through a lightweight inter-process communication mechanism.

[0016] Optionally, the hot update method of the embedded management module further comprises:

[0017] collecting running logs and performance indicators of each embedded management module in real time, and performing data cleaning on the collected running logs and performance indicators to obtain target data;

[0018] The target data is input into the pre-trained machine learning analysis model, so as to output a fault risk prediction result, a performance bottleneck early warning result and a hot update optimization suggestion through the machine learning analysis model; the fault risk prediction result is used to predict whether there is a process fault risk within a future preset time length, the performance bottleneck early warning result is used to judge whether there is a performance index exceeding a preset normal threshold, and the hot update optimization suggestion at least includes an adjustment suggestion of an upgrade sequence.

[0019] Optionally, after switching the service running in the old container instance to the new container instance, the method further comprises:

[0020] sending a preset suspension instruction to the old container instance, so as to suspend process scheduling and network connection of the old container instance through the preset suspension instruction, and reserve running data of the old container instance;

[0021] Correspondingly, after detecting that the current embedded management module hot update fails, the method further comprises:

[0022] resuming the old container instance from the suspended state to a running state based on the reserved running data, and sending a preset termination instruction to the new container instance, so as to terminate service processes and resource occupation of the new container instance through the preset termination instruction, and record corresponding hot update failure event information.

[0023] Optionally, the decompression operation is performed on the upgrade file that passes the preset security check, comprising:

[0024] obtaining the update package through a visual interactive interface or a command line interface of the embedded management module;

[0025] extracting the upgrade file from the update package, and performing integrity check and security check on the upgrade file based on a digital signature algorithm, and performing a decompression operation on the upgrade file that passes the check.

[0026] Optionally, a health query request is sent to the new container instance to trigger a check process of the new container instance, comprising:

[0027] initiating a connection to a pre-defined socket file of the new container instance to establish a target communication channel;

[0028] sending a health query request to the new container instance through the target communication channel to trigger a check process of the new container instance; wherein the check process of the new container instance at least includes memory state detection of the new container instance, communication connection detection of the new container instance and the embedded management module associated service, and activity detection of a preset key business thread in the new container instance.

[0029] In a second aspect, the application discloses a hot update device of an embedded management module, comprising:

[0030] a decompression module configured to perform a decompression operation on the upgrade file that has passed the preset security check to obtain all the embedded management modules to be upgraded and an upgrade sequence of the embedded management modules;

[0031] a container creation module configured to read an image file of a current embedded management module from the upgrade file according to the upgrade sequence, and create a new container instance of the current embedded management module based on the image file;

[0032] a hot update module configured to send a health query request to the new container instance to trigger a verification process of the new container instance, and switch a service running on an old container instance to the new container instance to implement the hot update of the current embedded management module after receiving a verification result representing the health of the new container instance;

[0033] a loop jump module configured to jump to a step of reading an image file of a current embedded management module from the upgrade file according to the upgrade sequence until all the embedded management modules complete the hot update.

[0034] In a third aspect, the present application discloses an electronic device, comprising:

[0035] a memory configured to save a computer program;

[0036] a processor configured to execute the computer program to implement the hot update method of the embedded management module disclosed above.

[0037] In a fourth aspect, the present application discloses a computer readable storage medium configured to save a computer program; wherein the computer program is executed by a processor to implement the hot update method of the embedded management module disclosed above.

[0038] It can be seen that the application proposes a hot updating method of an embedded management module, comprising: performing a decompression operation on an upgrade file that has passed a preset security check to obtain all embedded management modules to be upgraded and an upgrade sequence of each embedded management module; reading an image file of a current embedded management module from the upgrade file according to the upgrade sequence, creating a new container instance of the current embedded management module based on the image file; sending a health query request to the new container instance to trigger a check process of the new container instance, and after receiving a check result representing the health of the new container instance, switching a service running on an old container instance to the new container instance to realize the hot updating of the current embedded management module; jumping to the step of reading the image file of the current embedded management module from the upgrade file according to the upgrade sequence until all embedded management modules complete the hot updating. As can be seen from the above, the application first performs a preset security check on the upgrade file, and then performs a decompression operation on the upgrade file that has passed the preset security check. In this way, the credibility of the source and the integrity of the content of the upgrade file are ensured, and the influence of untrusted files or damaged files on the embedded management module in the updating link is avoided. Further, the application creates a new container instance for each module to be updated according to the upgrade sequence. Since each new container instance is isolated from the running environment and the overall system architecture of other un-updated modules, when a single module is updated, a restart operation of the entire embedded management module system is not required, and only the service of the module needs to be switched from the old container instance to the new container instance. In addition, before the service of the old container instance is switched to the new container instance, a check process of the new container instance needs to be triggered. Only after receiving a check result representing the health of the new container instance, the service switching is performed. In this way, it is ensured that the service can be stably operated. BRIEF DESCRIPTION OF DRAWINGS

[0039] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description only constitute the embodiments of the present application, and for those skilled in the art, other drawings can also be obtained without creative labor based on the provided drawings.

[0040] Figure 1 A hot updating method flow chart of an embedded management module disclosed by the present application;

[0041] Figure 2 A specific hot updating method flow chart of an embedded management module disclosed by the present application;

[0042] Figure 3 A hot updating device structure schematic diagram of an embedded management module disclosed by the present application;

[0043] Figure 4A structure diagram of an electronic device is disclosed in the present application. DETAILED DESCRIPTION

[0044] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by a person of ordinary skill in the art without creative effort fall within the protection scope of the present application.

[0045] The upgrade of the embedded management module firmware generally adopts an update mode of restarting the embedded management module system after the whole firmware image is written. This mode has a significant defect: during the update process, the embedded management module must interrupt all ongoing remote management sessions, performance monitoring and log collection services and perform a restart, thereby causing an unusable service blackout period. This not only makes the operation and maintenance personnel unable to manage the server during this period, but also causes the interruption and loss of monitoring data, seriously affecting the continuity of the business and the reliability of the system. Although there are some efforts in the industry to reduce the interruption time, such as setting up asynchronous updates, this does not fundamentally solve the core problem of "restarting must interrupt".

[0046] Therefore, the present application provides a hot update scheme of an embedded management module, which does not need to perform a restart operation on the whole system when updating a single embedded management module, thereby solving the problem of "restarting must interrupt".

[0047] The present application discloses a hot update method of an embedded management module, as shown in Figure 1 The method comprises the following steps:

[0048] Step S11: performing a decompression operation on the upgrade file that has passed the preset security check, to obtain all embedded management modules to be upgraded and the upgrade sequence of each embedded management module.

[0049] In the present application, the update package is obtained through the visual interactive interface or the command line interface of the embedded management module, and the upgrade file is extracted from the update package. Then, the integrity check and the security check are performed on the upgrade file based on the digital signature algorithm, and the decompression operation is performed on the upgrade file that passes the check.

[0050] Specifically, first, an update package is obtained through a visual interactive interface (such as a Web management interface) or a command line interface (CLI) of an embedded management module (such as a BMC), and the update package encapsulates upgrade files required to implement module function updates; then, after the upgrade files are extracted from the obtained update package, integrity and security checks are performed on the extracted upgrade files based on a digital signature algorithm (RSA) or an elliptic curve digital signature algorithm (ECDSA); by verifying the digital signature corresponding to the upgrade files, it is confirmed that the file source is trusted and the content has not been tampered with; after the upgrade files pass the above preset security checks, decompression is performed on the upgrade files, and in the decompression process, a configuration file (such as an updateConfig.yml file) contained in the upgrade files is read synchronously, so as to parse and determine all embedded management modules (such as the remote control module, monitoring module, and troubleshooting module of the BMC) to be upgraded from the configuration file, and the upgrade order of each embedded management module to be upgraded is obtained.

[0051] In addition, the embedded management module in the embodiment includes a baseboard management controller (BMC), and also includes other embedded management controllers similar to the BMC in function and attribute, such as a switch baseboard management controller and a router management module, for device hardware management and remote operation and maintenance; at the same time, the embedded management module can be adapted to server platforms of different architectures, such as an ARM (Advanced RISC Machine) architecture server and a RISC-V (Reduced Instruction Set Computing-V) architecture server. To achieve efficient and unified management of the embedded management modules on different architecture platforms and different device types, the embodiment defines a unified container image format and interface specification, so that a set of update system can be compatible with the update requirements of various embedded management modules without being separately adapted to different scenarios, thereby effectively reducing the operation and maintenance complexity.

[0052] Step S12: Read the image file of the current embedded management module from the upgrade file according to the upgrade order, and create a new container instance of the current embedded management module based on the image file.

[0053] In this embodiment, first, the BMC update service is started, which locates and reads the image file corresponding to the current embedded management module (such as the remote control module, monitoring module, etc. of the BMC, or the function module of other embedded management controllers such as the switch BMC, router management module, etc.) to be updated according to the upgrade sequence determined in the updateConfig.yml configuration file in the upgrade file; then based on the containerization architecture, the namespace (Namespaces) is used to realize the isolation of system resources such as process tree and network stack, and the control group (Cgroups) is used to set the upper limit of the use of physical resources such as CPU and memory of the new container instance, to build a process-level sandbox isolation environment, to ensure that the running environment of the new container instance is independent and controllable, and does not interfere with other module containers; at the same time, the container instance follows the design characteristics of the containerization architecture, so that the container instances of different embedded management modules can realize data interaction through a lightweight inter-process communication (IPC, Inter-Process Communication) mechanism (such as Unix Domain Socket, UDS). In this way, the stability of the collaborative work between modules is ensured. It should be pointed out that the above-mentioned BMC update service refers to the update service corresponding to the BMC, and if it is other embedded management modules, it is the update service corresponding to the corresponding embedded management module.

[0054] Taking the BMC as an example, if the function modules of the BMC that need to be updated include the remote control module, the monitoring module, and the troubleshooting module, and the upgrade sequence set in the updateConfig.yml configuration file in the upgrade file is: first the remote control module, then the monitoring module, and finally the troubleshooting module, then the BMC update service will first locate and read the image file corresponding to the remote control module from the upgrade file according to the upgrade sequence, and based on the containerization architecture, an independent process tree and network stack are divided for the module by the namespace, and the CPU occupancy of the new container instance of the module is set to not more than 20% and the memory usage is set to not more than 512MB by the control group, to build a process-level sandbox isolation environment to ensure its independent running; after the remote control module new container instance is created, the BMC update service reads the image file of the monitoring module in sequence, and creates a new container instance of the monitoring module through the above-mentioned containerization mechanism, and the monitoring module container can realize data interaction with the created remote control module container through the Unix domain socket in the lightweight inter-process communication mechanism, such as real-time receiving of server hardware operation instructions transmitted by the remote control module, and then performing corresponding state monitoring tasks; finally, the BMC update service reads the image file of the troubleshooting module according to the upgrade sequence and creates a new container instance, and the troubleshooting module container can also interact with the monitoring module container through the UDS to obtain the hardware exception data collected by the monitoring module, to realize the functions of fault positioning and troubleshooting.

[0055] Step S13: sending a health query request to the new container instance to trigger a verification process of the new container instance, and switching the service running on the old container instance to the new container instance after receiving a verification result representing the health of the new container instance, so as to realize the hot update of the current embedded management module.

[0056] In the embodiment, first, the BMC update service initiates a connection to a predefined socket file of the new container instance, the socket file is constructed based on the Unix domain socket technology, and a stable target communication channel is established through the lightweight inter-process communication path to ensure the efficiency and security of data transmission; then, the BMC update service sends a structured health query request to the new container instance through the target communication channel to trigger the new container instance to start the built-in verification process. The verification process of the new container instance at least covers three detection contents: first, memory state detection, checking whether the memory allocation of the process in the container is normal, whether there is a memory leakage or overflow risk; second, associated service communication connection detection, verifying whether the network connection and data interaction between the new container instance and other associated services (such as the hardware monitoring background service of the BMC, the remote control support service, etc.) in the embedded management module are smooth; third, key business thread activity detection, confirming whether the preset key business thread realizing the core function (such as server hardware state acquisition, log recording, etc.) in the container is running normally, only when the three detections are passed, the new container instance will generate a verification result representing the health, and synchronously feedback to the BMC update service through the target communication channel.

[0057] It should be pointed out that after the BMC update service receives the health verification result of the new container instance within the set timeout time, the service switching operation is performed to switch the service traffic (such as remote management instruction receiving, hardware monitoring data reporting) originally running on the old container instance to the new container instance, and the whole switching process does not need to interrupt the overall service of the BMC system, so as to realize the hot update of the current embedded management module.

[0058] After the service running on the old container instance is switched to the new container instance, the BMC update service also sends a preset suspension instruction to the old container instance. The suspension instruction triggers the old container instance to stop process scheduling, no longer receive new service requests, and disconnect its network connection to avoid data conflicts, while completely retaining the current running data (including service cache, running log, etc.) of the old container instance. Correspondingly, if it is detected that the current embedded management module hot update fails (for example, the new container instance has interface response errors, or cannot normally complete the core service function, etc.) after the service is switched, the BMC update service will immediately start an abnormal processing mechanism: based on the running data retained by the old container instance, quickly restore the old container instance from the suspended state to the normal running state, and re-switch the service traffic back to the old container instance; at the same time, send a preset termination instruction to the new container instance to terminate all service processes of the new container instance, release the physical resources (such as CPU, memory, network, etc.) occupied by the new container instance, and record the detailed information of the hot update failure event (including the failed module name, the failure time, the failure cause diagnosis result, etc.) to the BMC event log, so that the subsequent troubleshooting and analysis of the operation and maintenance personnel can be ensured, and the BMC system can always maintain a stable running state.

[0059] Step S14: Jump to the step of reading the image file of the current embedded management module from the upgrade file according to the upgrade sequence, until all embedded management modules complete the hot update.

[0060] In this embodiment, after completing the hot update of the current embedded management module, the BMC update service jumps to the step of reading the image file of the current embedded management module from the upgrade file according to the upgrade sequence, and refers to the processes of steps S12 to S13 to perform the image file reading, new container instance creation, health check, service switching and old container suspension operations on the next embedded management module to be updated, and the operations are repeated until all the embedded management modules to be updated complete the hot update. After all the embedded management modules complete the hot update, the BMC update service sends a self-check command to all the embedded management modules (including the updated modules and the modules not participating in this update but in a running state). The self-check command includes a module identity field and a to-be-detected item field: the module identity field uses a unique code (such as “BMC_Monitor_001”) to uniquely identify each embedded management module; and the to-be-detected item field explicitly indicates the detection tasks to be performed by each module. After receiving the self-check command, each embedded management module starts an internal self-check process based on the module type and the to-be-detected item field: for example, checking whether the core process is normally running, whether the key interface can normally respond, whether the collected data conforms to the actual state of the hardware, and the like, and after the self-check process ends, generating a state identifier including “ready” (the current running state conforms to the preset requirements) or “not ready” (the current running state does not conform to the preset requirements), and self-check data recording the detection process data and the detection result values, and synchronously feeding back to the BMC update service. After obtaining the state identifier and the self-check data returned by each embedded management module, the BMC update service performs double verification: if the state identifier is “ready” and each detection index in the self-check data is in the preset normal range, it is determined that the module passes the self-check; when all the modules pass the self-check, the BMC update service starts the cleaning process of the old container instance: terminates all the suspended old container instances, releases the physical resources such as CPU and memory occupied by the old container instances, and records the completion time of this hot update, the updated module list, the update result of each module and the like in the BMC event log, and generates the hot update completion event information. If the state identifier of any module is “not ready” or there is an index exceeding the preset range in the self-check data, it is determined that the self-check fails; at this time, the BMC update service performs the reverse old container instance recovery operation according to the upgrade sequence of this time: for example, if the upgrade sequence is remote control module → monitoring module → fault elimination module, the corresponding old container instances are sequentially restored to the running state from the fault elimination module, the service traffic is switched back to the old container, and the new container instance is stopped and destroyed; after all the old container instances are restored, the cleaning process of the new container instance is started, and the module name of the module that fails the self-check, the abnormal index data and the like are written into the BMC event log, and the hot update failure event information is generated.

[0061] In this embodiment, to realize continuous monitoring of the running state of the embedded management module and optimization of the hot update strategy, the running logs (including data interaction logs, abnormal error logs, etc.) and performance indicators (including CPU usage, memory occupancy, etc.) of each embedded management module are also collected in real time, and the collected running logs and performance indicators are cleaned by a data cleaning algorithm to obtain target data with unified format and accurate data. Further, the cleaned target data is input into a pre-trained machine learning analysis model to output fault risk prediction results, performance bottleneck warning results and hot update optimization suggestions through the machine learning analysis model; wherein the fault risk prediction results are used to predict whether there is a process fault risk in the future within a preset time period, the performance bottleneck warning results are used to determine whether there is a performance indicator that exceeds a preset normal threshold, and the hot update optimization suggestions at least include adjustment suggestions for the upgrade sequence.

[0062] It should be noted that the training process of the machine learning analysis model specifically includes: collecting running logs, performance indicators, corresponding fault occurrence records and other data of different embedded management modules (including BMC, switch BMC, router management module, etc.) in different running scenarios (normal scenario, fault scenario) in a historical period (such as the past 6 months), and building a model training data set based on the data, then labeling the training data set, for example, for the fault risk prediction task, labeling sample labels such as "occurred fault" and "did not occur fault"; then dividing the labeled training data set into a training set and a validation set, and using the training set to train the model until the prediction accuracy (such as fault risk prediction accuracy ≥ 90%) of the model on the validation set reaches a preset threshold, then the model training is completed.

[0063] In addition, in the edge computing scenario, the edge server often faces the problems of limited hardware resources and complex network environment. Therefore, the embodiment proposes: supporting incremental update or differential update of part of the BMC function modules, only transmitting code fragments or configuration files that differ from the old version modules, rather than complete image files, which greatly reduces the network data transmission amount in the update process, at the same time adapts to the characteristics of low bandwidth and high delay of the edge environment, avoids update timeout or failure caused by large amount of transmitted data, and ensures efficient and stable execution of the containerized BMC module hot update on the edge server.

[0064] Referring to Figure 2As shown, first, the uploading update package operation is performed, then the preset security check is performed, if the check fails, the update is terminated, the log is recorded and the alarm is given; if it passes, the update package is decompressed, and the to-be-updated module is obtained in the upgrade order. Then a new container instance is created and a health check is carried out, if the health check fails, an abnormal log is recorded and a rollback process is triggered, that is, the old container instance is restored in reverse order, the new container instance is destroyed, then the rollback log is recorded and the alarm is given, and the process ends. If the health check passes, the business switching is performed: the old container instance is suspended, and it is judged whether there is a to-be-updated module, if yes, the step of decompressing the update package and obtaining the to-be-updated module in the upgrade order is continued; if no, a self-check command is sent to all modules, and it is checked whether all modules are in the ready state, if not, the rollback process is triggered; if yes, the old container instance is destroyed, the success log is recorded, and the update is finally successful.

[0065] As can be seen, the application proposes a hot update method of an embedded management module, comprising: performing a decompression operation on an upgrade file that has passed a preset security check, to obtain all to-be-upgraded embedded management modules and an upgrade order of each embedded management module; reading an image file of a current embedded management module from the upgrade file according to the upgrade order, and creating a new container instance of the current embedded management module based on the image file; sending a health query request to the new container instance to trigger a check process of the new container instance, and after receiving a check result representing the health of the new container instance, switching the business running on the old container instance to the new container instance to realize the hot update of the current embedded management module; jumping to the step of reading the image file of the current embedded management module from the upgrade file according to the upgrade order until all embedded management modules complete the hot update. As can be seen from the above, the application first performs a preset security check on the upgrade file, and then performs a decompression operation on the upgrade file that has passed the preset security check. In this way, the credibility and content integrity of the upgrade file are ensured, and the influence of untrusted files or damaged files on the embedded management module in the update link is avoided. Further, the application creates a new container instance for each to-be-updated module according to the upgrade order. Since each new container instance is isolated from the running environment and the overall system architecture of other non-updated modules, when updating a single module, it is not necessary to perform a restart operation on the entire embedded management module system, but only the business of the module needs to be switched from the old container instance to the new container instance. In addition, before switching the business of the old container instance to the new container instance, the check process of the new container instance needs to be triggered. Only after receiving a check result representing the health of the new container instance will the business switching be performed. In this way, it is ensured that the business can run stably.

[0066] Correspondingly, the application also discloses a hot update device of an embedded management module, as shown in Figure 3 The device comprises:

[0067] the decompression module 11 is configured to perform a decompression operation on the upgrade file that has passed the preset security check, to obtain all the embedded management modules to be upgraded and an upgrade sequence of the embedded management modules;

[0068] the container creation module 12 is configured to read, according to the upgrade sequence, an image file of a current embedded management module from the upgrade file, and create a new container instance of the current embedded management module based on the image file;

[0069] the hot update module 13 is configured to send a health query request to the new container instance, to trigger a check process of the new container instance, and switch a service running on an old container instance to the new container instance after receiving a check result representing the health of the new container instance, to implement the hot update of the current embedded management module;

[0070] the loop jump module 14 is configured to jump to the step of reading, according to the upgrade sequence, the image file of the current embedded management module from the upgrade file, until all the embedded management modules complete the hot update.

[0071] The more specific working processes of the above modules can refer to the corresponding contents disclosed in the foregoing embodiments, and will not be repeated here.

[0072] Further, the embodiment of the present application further provides an electronic device. Figure 4 is a structural diagram of an electronic device 20 according to an exemplary embodiment, and the contents in the figure cannot be considered as any limitation on the use range of the present application.

[0073] Figure 4 A structural schematic diagram of an electronic device 20 provided by the embodiment of the present application. The electronic device 20 can specifically include at least one processor 21, at least one memory 22, a display screen 23, an input / output interface 24, a communication interface 25, a power supply 26 and a communication bus 27. The memory 22 is used to store a computer program, which is loaded and executed by the processor 21 to implement the related steps in the hot update method of the embedded management module disclosed in any of the foregoing embodiments. In addition, the electronic device 20 in the embodiment can be specifically an electronic computer.

[0074] In the embodiment, the power supply 26 is used to provide working voltage for each hardware device on the electronic device 20; the communication interface 25 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol followed by the communication interface 25 can be any communication protocol applicable to the technical solution of the present application, which will not be specifically limited here; the input / output interface 24 is used to obtain external input data or output data to the outside, and the specific interface type can be selected according to the specific application needs, which will not be specifically limited here.

[0075] In addition, the memory 22 can be a read-only memory, a random access memory, a magnetic disk or an optical disk, etc., as a carrier for storing resources. The resources stored thereon can include a computer program 221, and the storage manner can be temporary storage or permanent storage. In addition to the computer program capable of completing the hot updating method of the embedded management module executed by the electronic device 20 disclosed in any of the foregoing embodiments, the computer program 221 can further include a computer program capable of completing other specific work.

[0076] Further, the embodiment of the present application further discloses a computer readable storage medium for storing a computer program, wherein the computer program is executed by a processor to implement the hot updating method of the embedded management module disclosed above.

[0077] The specific steps of the method can refer to the corresponding content disclosed in the foregoing embodiments, and will not be described here.

[0078] The embodiments in the present application are described in a progressive manner, and each embodiment focuses on the difference from other embodiments. The same or similar parts of each embodiment can be referred to each other. For the device disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple, and the relevant part can refer to the method part.

[0079] The skilled person can further realize that the units and algorithm steps of the examples described in combination with the embodiments disclosed herein can be realized by electronic hardware, computer software or a combination of the two. In order to clearly show the interchangeability of hardware and software, the components and steps of each example have been described in the above description. Whether the functions are realized by hardware or software depends on the specific application and design constraints of the technical solution. The skilled person can use different methods to realize the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0080] The steps of the method or algorithm described in combination with the embodiments disclosed herein can be directly implemented by hardware, a software module executed by a processor, or a combination of the two. The software module can be placed in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0081] Finally, it needs to be pointed out that in this article, the relationship terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between the entities or operations. Moreover, the term "includes", "contains" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, article or device including a series of elements not only includes those elements, but also includes other elements not explicitly listed or inherent to such process, method, article or device. Without more limitations, the element defined by the statement "includes a" does not exclude the presence of other identical elements in the process, method, article or device including the element.

[0082] The above provides a detailed introduction to the hot updating method, device, equipment and storage medium of the embedded management module provided by the present application. The principles and implementation modes of the present application are described in this article by applying specific examples. The above example is only used to help understand the method and core idea of the present application; at the same time, for those skilled in the art, according to the idea of the present application, the specific implementation mode and application range will be changed; in view of the above, the content of the specification should not be understood as a limitation of the present application.

Claims

1. A hot update method for an embedded management module, characterized in that, include: Perform a decompression operation on the upgrade file that has passed the preset security verification to obtain all the embedded management modules to be upgraded and the upgrade order of each embedded management module; According to the upgrade order, read the image file of the current embedded management module from the upgrade file, and create a new container instance of the current embedded management module based on the image file; A health query request is sent to the new container instance to trigger the verification process of the new container instance. After receiving the verification result indicating the health of the new container instance, the service running on the old container instance is switched to the new container instance to realize the hot update of the current embedded management module. Jump to the step of reading the image file of the current embedded management module from the upgrade file according to the upgrade order, until all embedded management modules have completed hot update.

2. The hot update method for the embedded management module according to claim 1, characterized in that, The process continues until all the embedded management modules have completed hot updates, and also includes: A self-test command is sent to all the embedded management modules so that each embedded management module can start its internal self-test process based on the self-test command and generate a status identifier and self-test data after completing the self-test process; wherein, the self-test command includes a module identity field and a test item field, the module identity field is used to uniquely identify the embedded management module, and the test item field is used to specify the test task that the embedded management module needs to perform; Obtain the status identifier and self-test data returned by each of the embedded management modules; If the status identifier indicates that the current running status of the embedded management module meets the preset requirements, and the self-test data meets the preset range, then the self-test is determined to be passed, and the cleanup process of the old container instance is started and the corresponding hot update completion event information is recorded. If the status identifier indicates that the current running status of the embedded management module does not meet the preset requirements, or the self-test data does not meet the preset range, then the self-test is determined to have failed, and the recovery operation of the old container instance is performed in reverse according to the upgrade order. Then, the cleanup process of the new container instance is started and the corresponding hot update failure event information is recorded.

3. The hot update method for the embedded management module according to claim 1, characterized in that, The container instance achieves independent management of the environment based on the process-level sandbox isolation mechanism of the containerized architecture, and different embedded management modules achieve data interaction through a lightweight inter-process communication mechanism.

4. The hot update method for the embedded management module according to claim 1, characterized in that, Also includes: The operation logs and performance indicators of each embedded management module are collected in real time, and the collected operation logs and performance indicators are cleaned to obtain the target data. The target data is input into a pre-trained machine learning analysis model so that the machine learning analysis model can output fault risk prediction results, performance bottleneck warning results, and hot update optimization suggestions. The fault risk prediction results are used to predict whether there is a process fault risk within a preset time period in the future. The performance bottleneck warning results are used to determine whether there are performance indicators that exceed a preset normal threshold. The hot update optimization suggestions include at least the suggestion to adjust the upgrade order.

5. The hot update method for the embedded management module according to claim 1, characterized in that, After switching the service running on the old container instance to the new container instance, the process also includes: Send a preset pause command to the old container instance to pause the process scheduling and network connection of the old container instance, while retaining the running data of the old container instance; Accordingly, after detecting that the current hot update of the embedded management module has failed, the following steps are also included: Based on the retained runtime data, the old container instance is restored from the paused state to the running state, and a preset termination command is sent to the new container instance to terminate the business process and resource usage of the new container instance, and the corresponding hot update failure event information is recorded.

6. The hot update method for the embedded management module according to claim 1, characterized in that, The step of performing a decompression operation on the upgrade file that has undergone preset security verification includes: Obtain the update package through the visual interactive interface or command-line interface of the embedded management module; The upgrade file is extracted from the update package, and the integrity and security of the upgrade file are verified based on the digital signature algorithm. The upgrade file that passes the verification is then decompressed.

7. The hot update method for an embedded management module according to any one of claims 1 to 6, characterized in that, Sending a health query request to the new container instance to trigger the verification process of the new container instance includes: Initiate a connection to the predefined socket file of the new container instance to establish a target communication channel; The health query request is sent to the new container instance through the target communication channel to trigger the verification process of the new container instance; wherein, the verification process of the new container instance includes at least the memory status detection of the new container instance, the communication connection detection between the new container instance and the associated services in the embedded management module, and the activity detection of the preset key business threads in the new container instance.

8. A hot-update device for an embedded management module, characterized in that, include: The decompression module is used to perform decompression operations on the upgrade file that has passed the preset security verification, so as to obtain all the embedded management modules to be upgraded and the upgrade order of each embedded management module; The container creation module is used to read the image file of the current embedded management module from the upgrade file according to the upgrade order, and create a new container instance of the current embedded management module based on the image file; The hot update module is used to send a health query request to the new container instance to trigger the verification process of the new container instance, and after receiving the verification result indicating the health of the new container instance, to switch the service running on the old container instance to the new container instance, so as to realize the hot update of the current embedded management module. The loop jump module is used to jump to the step of reading the image file of the current embedded management module from the upgrade file according to the upgrade order, until all the embedded management modules have completed hot update.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the hot update method for the embedded management module as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Used to store computer programs; wherein, when the computer programs are executed by a processor, they implement the hot update method of the embedded management module as described in any one of claims 1 to 7.

Images