Power management method, electronic equipment and storage medium
By responding to plug-in and unplugging events and dynamically loading the target driver when the substrate management controller has been started, the problem of manually restarting the BMC after adding the power module in the prior art is solved, and timely response and management of the state changes of the power supply unit is achieved, and the stability and ease of use of the system are improved.
Patent Information
- Application Number
- CN202510336382.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-03-20
- Publication Date
- 2025-06-10
AI Technical Summary
After the prior art adds power modules during server operation, the BMC needs to be manually restarted to achieve power management, which cannot meet the requirements of real-time, reliability and ease of use.
When the substrate management controller has been started, in response to the plug-in and unplug event that captures the plug-in and unplug operation of the target power supply unit, the device management daemon loads the preset rules corresponding to the plug-in and unplug event, dynamically loads the target driver, and executes the relationship management operation corresponding to the plug-in and unplug event, and finally sends a restart instruction to the power management module to update the in-place status and power management information.
It realizes that plug-in and unplug events can be captured without restarting the BMC, dynamically loading the target driver to manage the hot-plug state of the power supply unit, ensuring that the system correctly responds to changes in the power supply unit status, reducing system instability or errors caused by improper hardware equipment management, and improving stability.
Smart Images

Figure CN120122795A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer application technologies, and more particularly to a power management method, an electronic device, and a storage medium. Background Art
[0002] In the related art, the functions of power module loading, management, and control usually rely on underlying drivers, hardware controllers, and complex software platforms. This not only increases the complexity and cost of the system, but also limits the flexibility and scalability of the system. Especially when additional power modules need to be added due to an increase in load during the operation of a server, in the related methods, after adding a power module, it is necessary to manually restart the BMC (Baseboard Management Controller) to achieve the goal. This control method often fails to meet the requirements of real-time performance, reliability, and ease of use. Summary of the Invention
[0003] In view of the above problems, this application provides a power management method, an electronic device, and a storage medium.
[0004] According to one aspect of this application, a power management method is provided, including: when the baseboard management controller has been started, in response to capturing a plugging event that characterizes the plugging operation of a target power supply unit, calling a device management daemon to load a preset rule corresponding to the plugging event; according to the preset rule, dynamically loading a target driver corresponding to the target power supply unit, and performing a relationship management operation corresponding to the plugging event on the target power supply unit and the target driver, where the baseboard management controller is configured with a power management module and a target driver, and the power management module communicates with the target power supply unit through the target driver; and in response to determining that the relationship management operation has been successfully executed, sending a restart instruction to the power management module; and when it is detected that the power management module has restarted in response to the restart instruction, updating the presence state and power management information of the target power supply unit.
[0005] According to another aspect of this application, an electronic device is provided, including: a target driver; a power management module configured to communicate with a target power supply unit through the target driver; a baseboard management controller configured to: when it has been started, in response to capturing a plugging event that characterizes the plugging operation of a target power supply unit, calling a device management daemon to load a preset rule corresponding to the plugging event; according to the preset rule, dynamically loading a target driver corresponding to the target power supply unit, and performing a relationship management operation corresponding to the plugging event on the target power supply unit and the target driver; in response to determining that the relationship management operation has been successfully executed, sending a restart instruction to the power management module; and when it is detected that the power management module has completed restarting in response to the restart instruction, updating the presence state and power management information of the target power supply unit.
[0006] According to another aspect of the present application, there is also provided a computer-readable storage medium, on which a computer program or instructions are stored, and when the computer program or instructions are executed by a processor, the steps of the power management method of the present application are implemented. BRIEF DESCRIPTION OF THE DRAWINGS
[0007] Through the following description of the embodiments of the present application with reference to the accompanying drawings, the above content and other objects, features, and advantages of the present application will become clearer. In the drawings:
[0008] Figure 1 Schematically shows an application scenario diagram of the power management method according to an embodiment of the present application;
[0009] Figure 2 Schematically shows a flowchart of the power management method according to an embodiment of the present application;
[0010] Figure 3A Schematically shows a BMC power management timing diagram based on PSU hot plugging dynamic event detection according to an embodiment of the present application;
[0011] Figure 3B Schematically shows a processing schematic diagram of the PSU hot plugging dynamic event according to an embodiment of the present application;
[0012] Figure 4 Schematically shows a structural block diagram of the power management device according to an embodiment of the present application; and
[0013] Figure 5 Schematically shows a block diagram of an electronic device suitable for implementing the power management method according to an embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS
[0014] Hereinafter, embodiments of the present application will be described with reference to the accompanying drawings. However, it should be understood that these descriptions are merely exemplary and are not intended to limit the scope of the present application. In the following detailed description, for the sake of explanation, many specific details are set forth to provide a comprehensive understanding of the embodiments of the present application. However, it is obvious that one or more embodiments can also be implemented without these specific details. In addition, in the following description, descriptions of well-known structures and technologies are omitted to avoid unnecessarily confusing the concepts of the present application.
[0015] The terms used herein are only for describing specific embodiments and are not intended to limit the present application. The terms "including", "comprising", etc. used herein indicate the presence of the described features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.
[0016] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those of ordinary skill in the art, unless otherwise defined. It should be noted that the terms used herein should be interpreted as having a meaning consistent with the context of this specification, and should not be interpreted in an idealized or overly rigid manner.
[0017] In cases where expressions similar to "at least one of A, B, and C, etc." are used, generally, it should be interpreted according to the meaning commonly understood by those of ordinary skill in the art (for example, "a system having at least one of A, B, and C" should include, but not be limited to, a system having only A, only B, only C, having A and B, having A and C, having B and C, and / or having A, B, and C, etc.).
[0018] With the rapid development of cloud computing and big data technologies, data centers, as the key infrastructure supporting these technologies, are increasing in scale and complexity. These data centers are not only the hubs for information processing and storage but also the powerful engines driving the development of modern information-based society. However, with the sharp increase in the business volume of data centers, ensuring the high reliability, stability, and availability of data centers has become particularly critical. In this context, the core out-of-band management unit of each server node in the data center plays a crucial role. For example, an out-of-band management unit in an open-source embedded system can be responsible for monitoring and managing server hardware.
[0019] The PSU (Power Supply Unit) is a key component that provides stable power for various components of the server. With the continuous development of server technologies, the requirements for the flexibility and efficiency of power management are getting higher and higher. The traditional PSU management method often fixes the configuration and loading of the PSU at system startup, making it difficult to adapt to the dynamic changes in power demand during server operation. For example, when the server load suddenly increases and additional power supply is required, new PSU resources cannot be dynamically loaded in a timely and effective manner, or in some redundant power scenarios, the enabling and disabling of the PSU cannot be flexibly controlled according to the actual power usage situation, which may not only affect the overall performance of the server but also cause energy waste. For an open-source baseboard management controller, it can provide rich functions and scalability for server hardware management, but there is still room for further optimization and improvement in terms of PSU dynamic loading.
[0020] In the early design, when the BMC starts, it will detect whether the PSU device is connected through GPIO (General Purpose Input / Output). If the device is connected, the BMC will perform the Bing (binding) action and read the PSU information. The PSU management module will load the corresponding configuration file and create D-Bus (Desktop Bus, a message bus system) as the data middle layer between the underlying driver and the upper application for inter-process communication on the operating system.
[0021] The overall architecture process of the traditional BMC loading the PSU module includes: when the BMC starts to start, the GPIO detects the connected PSU device at the PSU hardware module layer to perform the Bing action with the PSU driver module on the connected PSU device. The PSU driver module will load the driver and read the hardware information of the connected PSU device. The PSU management module can update the Binged PSU device information and realize the communication of the Binged PSU device by reading the PSU in-place information and initializing the loading of the PSU configuration file. At this point, the BMC startup is completed.
[0022] The traditional approach brings the following potential problems:
[0023] 1. Status synchronization: When the BMC is started, one of the PSUs is not loaded due to problems such as loose hardware physical connection. After re-plugging, the hardware connection is normal. At this time, the BMC will not recognize this PSU module, resulting in abnormal display. In this case, the BMC must be restarted again or the scan is manually triggered for it to be recognized, resulting in the failure of the system redundant power supply configuration. Because the current implementation only scans the PSU device through the initialization process at startup, the newly added PSU after startup cannot be detected, resulting in the system being unable to recognize the redundant power supply or extended power supply configuration.
[0024] 2. Initialization limitation: BMC only initializes PSU devices through firmware during the startup phase, and cannot dynamically identify newly added PSUs during operation. If BMC has been running for a period of time, but needs to expand the power module again due to service area load or other external factors, this problem is the same as 1, resulting in the inability to generate corresponding object paths (ObjectPath) and properties (Property) for the newly added devices, affecting the data synchronization of management interfaces such as IPMI (Intelligent Platform Management Interface) and Redfish (an open standard).
[0025] In the process of implementing the concept of this application, the inventor found that when the above situation occurs, it is necessary to restart the BMC to trigger the scanning device, which increases the complexity of data center operation and maintenance and may also introduce new errors and problems.
[0026] Figure 1 FIG. schematically shows an application scenario diagram of a power management method according to an embodiment of the present application.
[0027] As Figure 1 shown, the application scenario 100 according to this embodiment may include a first hardware device 101, a second hardware device 102, a third hardware device 103, a dedicated interface 104, and an out-of-band management unit 105.
[0028] The first hardware device 101, the second hardware device 102, and the third hardware device 103 may include, but are not limited to, various hardware devices with storage and processing functions, such as, but not limited to, servers, network devices, storage devices, PDUs (Power Distribution Units), KVM over IP (Keyboard, Video, and Mouse over Internet Protocol), and other hardware devices.
[0029] The dedicated interface 104 is used to provide a communication connection between the out-of-band management unit 105 and the first hardware device 101, the second hardware device 102, and the third hardware device 103. The dedicated interface 104 may include various types of ports, such as Ethernet ports, serial console ports, USB interfaces, virtual management interfaces, fiber optic interfaces, etc., and is not limited thereto.
[0030] The out-of-band management unit 105 accesses the first hardware device 101, the second hardware device 102, and the third hardware device 103 through the dedicated interface 104 to ensure that the first hardware device 101, the second hardware device 102, and the third hardware device 103 can still be managed when the main network is unavailable. The out-of-band management unit 105 may include, but is not limited to, BMCs, out-of-band management tools for virtualized environments, and is not limited thereto. The out-of-band management unit 105 may be an integral part of the first hardware device 101, the second hardware device 102, and the third hardware device 103, or may be independently externally connected to the first hardware device 101, the second hardware device 102, and the third hardware device 103, which is not limited herein.
[0031] It should be noted that the power management method provided by the embodiments of the present application can generally be executed by the out-of-band management unit 105. Correspondingly, the power management device provided by the embodiments of the present application can generally be set in the out-of-band management unit 105. The power management method provided by the embodiments of the present application can also be executed by a server or a server cluster different from the out-of-band management unit 105 and capable of communicating with the first hardware device 101, the second hardware device 102, the third hardware device 103, and / or the out-of-band management unit 105. Correspondingly, the power management device provided by the embodiments of the present application can also be set in a server or a server cluster different from the out-of-band management unit 105 and capable of communicating with the first hardware device 101, the second hardware device 102, the third hardware device 103, and / or the out-of-band management unit 105.
[0032] It should be understood that Figure 1 the numbers of the first hardware device, the second hardware device, the third hardware device, the dedicated interface, and the out-of-band management unit in
[0033] are merely illustrative. According to the implementation requirements, there can be any number of electronic devices, dedicated interfaces, and out-of-band management units. Figure 1 The power management method of the embodiments of the present application will be described in detail below based on the
[0034] Figure 2 scenario described.
[0035] As Figure 2 shown, the power management method of this embodiment can include operation S210 to operation S240. This power management method can be executed by the kernel process of the BMC, for example.
[0036] In operation S210, when the baseboard management controller has been started, in response to capturing a plugging and unplugging event characterizing the plugging and unplugging operation of the target power supply unit, the device management daemon is called to load a preset rule corresponding to the plugging and unplugging event.
[0037] According to the embodiments of the present application, the power supply unit can represent an entity device, for example, it can include a PSU, and is not limited thereto. The plugging and unplugging operation can be represented as an insertion operation or a removal operation. In the preset rule, listening events and subsequent processing actions to be taken when corresponding events are listened to can be configured for various operations. The device management daemon can include a daemon determined based on the preset rule. For example, it can include a udev daemon for listening to relevant events based on the preset rule.
[0038] After the user performs the physical plugging and unplugging operation of the target power supply unit, the hardware layer can detect the device plugging and unplugging signal. At this time, based on the udev daemon, the plugging and unplugging event can be captured through the kernel event listening mechanism.
[0039] In operation S220, according to a preset rule, a target driver corresponding to the target power supply unit is dynamically loaded, and a relationship management operation corresponding to the plugging and unplugging event is performed on the target power supply unit and the target driver. The baseboard management controller is configured with a power management module and a target driver, and the power management module communicates with the target power supply unit through the target driver.
[0040] According to an embodiment of the present application, the power management module may represent a virtual module configured in the operating system kernel for managing the power supply unit. The driver may represent one or more virtual modules configured in the operating system kernel for enabling the power management module in the operating system to recognize and control the power supply unit. The operating system kernel may be configured with one or more drivers. Each driver may be compatible with one or more power supply units. The target driver may represent a driver that is compatible with the target power supply unit. The relationship management operation may be determined according to subsequent processing actions, and specifically may be characterized as binding or unbinding the target power supply unit and the target driver.
[0041] In operation S230, in response to determining that the relationship management operation has been successfully executed, a restart instruction is sent to the power management module.
[0042] According to an embodiment of the present application, when the target power supply unit is the first power supply unit, the target driver is the first driver, and the binding between the first driver and the first power supply unit in the hardware layer is successful, the first power supply unit can be detected at the driver layer, so that the service layer can receive a binding success signal indicating that the first power supply unit is in place. The restart instruction may be generated based on the binding success signal and sent to the power management module.
[0043] According to an embodiment of the present application, when the target power supply unit is the second power supply unit, the target driver is the second driver, and the unbinding between the second driver and the second power supply unit in the hardware layer is successful, the second power supply unit can no longer be detected at the driver layer, so that the service layer can receive an unbinding success signal indicating that the second power supply unit is out of position. The restart instruction may also be generated based on the unbinding success signal and sent to the power management module.
[0044] According to an embodiment of the present application, for example, systemctl restart psu-manager.service may be executed through a script to send a restart instruction to the power management module to restart the power management module.
[0045] In operation S240, when it is detected that the power management module has restarted in response to the restart instruction, the in-position status and power management information of the target power supply unit are updated.
[0046] According to an embodiment of the present application, the in-position state can be characterized as in-position or out-of-position. The power management information may include D-Bus information, specifically including at least one of the voltage, power, load, etc. of the power supply unit, and is not limited thereto. After the power management module has been restarted, the power management information of all currently bound power supply units can be loaded to normally start and use the corresponding power supply units, or release the use of the unbound power supply units. And the in-position state of the corresponding power supply unit can be updated.
[0047] Through the above embodiments of the present application, when the baseboard management controller has been started, the device management daemon is called to load the preset rules, the target driver is dynamically loaded according to the preset rules, and the relationship management operation corresponding to the plugging and unplugging event is executed. It is possible to capture the plugging and unplugging event without restarting the baseboard management controller, dynamically load the target driver based on the preset rules to manage the hot plug state of the power supply unit, ensure that the system can correctly and timely respond to the state change of the power supply unit, reduce system instability or errors caused by improper management of hardware devices, and improve stability.
[0048] According to an embodiment of the present application, the preset rules may include at least one of the following: an add event indicating an insertion operation and a binding rule configured for the add event, or a remove event indicating a removal operation and an unbinding rule configured for the remove event.
[0049] According to an embodiment of the present application, the preset rules may be pre-configured in a rule configuration directory for managing device nodes and controlling device behavior.
[0050] For example, the preset rules may include udev rules predefined in the / etc / udev / rules.d directory. Since the udev rule adaptation file is in the / etc / udev / rules.d / XX.rules path, it enables the administrator to more conveniently search for and manage relevant device rules. When configuration modification, fault troubleshooting, or adding new rules for related devices is required, the corresponding rule file can be quickly located according to the rule definition address, improving the efficiency of system management and effectively protecting the system's management method for device hot plugging and other events.
[0051] According to an embodiment of the present application, after the user performs a physical insertion operation on the target power supply unit, the hardware layer can trigger a device state change signal. At this time, a daemon process determined based on the preset rules, such as the udev daemon process, can capture the Add event through the kernel event listening mechanism. On the contrary, if the user performs a physical removal operation on the target power supply unit, the udev daemon process can capture the Remove event. Therefore, the add event in the udev rule can be constructed according to the Add event, and the remove event in the udev rule can be constructed according to the Remove event.
[0052] For the binding rules in udev rules, the configuration content may include: binding the first power supply unit to the first driver; running a restart script for restarting the power management module. For the unbinding rules in udev rules, the configuration content may include: unbinding the second power supply unit from the second driver; running a restart script for restarting the power management module.
[0053] According to an embodiment of the present application, since there may be multiple types of power supply units and drivers, different types of power supply units and drivers may be incompatible. The first power supply identifier used to represent the first power supply unit in the binding rule may be represented by a first power variable, and the first driver identifier used to represent the first driver may be represented by a first driver variable. The second power supply identifier used to label the second power supply unit in the unbinding rule may be represented by a second power variable, and the second driver identifier used to represent the second driver may be represented by a second driver variable. The mapping relationship between compatible power supply units and drivers can be pre-configured in the linux device tree, including: the first power supply unit may be compatible with the first driver, and the first mapping relationship between the first power supply identifier and the first driver identifier is pre-configured in the device tree. The second power supply unit may be compatible with the second driver, and the second mapping relationship between the second power supply identifier and the second driver identifier is pre-configured in the device tree. Thus, the variable values of the first power supply identifier and the first driver identifier in the binding rule can be determined according to the first mapping information configured in the device tree. The variable values of the second power supply identifier and the second driver identifier in the unbinding rule can be determined according to the second mapping information configured in the device tree.
[0054] For example, in the linux device tree, it is pre-configured that the driver of power supply unit 1 is driver 1, the driver of power supply unit 2 is driver 2, etc. When it is detected that the newly added first power supply unit is power supply unit 1, the variable value of the variable representing the first power supply unit in the corresponding binding rule can be determined as power supply unit 1, and according to the existing configuration information, the variable value of the variable representing the first driver in the corresponding binding rule can be determined as driver 1. Thus, the newly added first power supply unit can be automatically detected and automatically bound to the corresponding first driver.
[0055] According to an embodiment of the present application, the above operation S210 may include: in response to capturing an addition event, loading the binding rule. When the target power supply unit is the first power supply unit and the target driver is the first driver, the above operation S220 may include: determining the first driver identifier corresponding to the first power supply identifier of the first power supply unit that triggers the addition event. Using the binding rule, bind the first power supply unit and the first driver represented by the first driver identifier.
[0056] According to an embodiment of the present application, in the case of capturing an addition event, a binding rule corresponding to the addition event can be loaded from a preset rule. The first power supply identifier can be directly read after detecting a device insertion signal. On this basis, in combination with the mapping relationship between the power supply unit and the driver pre-configured in the linux device tree, the first driver identifier corresponding to the first power supply identifier can be determined. After that, by running the binding script in the binding rule, the binding relationship between the first power supply unit and the first driver can be configured to implement the binding of the first power supply unit and the first driver.
[0057] Through the above embodiments of the present application, by using the preset rule to monitor events and implement binding, the hot-swap state of the power supply unit can be timely responded without restarting the BMC, ensuring the accurate response of the system to the change of the hardware state.
[0058] According to an embodiment of the present application, in the case where the relationship management operation includes a binding operation, the above operation S240 may include: loading a configuration file related to the first power supply unit, configuring the first power supply unit, and generating power management information. Updating the presence state of the first power supply unit to present.
[0059] For example, after the power management module is restarted, the psusensor (power supply sensor) process can update the presence state of the present PSU device to present, and create a PSU object path for the newly present PSU device that establishes an electrical connection with the local BMC for the first time, or directly obtain the PSU object path of the PSU device that has established an electrical connection with the local BMC but has been absent and is present again this time and has been stored in the local kernel. Then, the entity-manager process can reload the configuration file of the corresponding PSU device and implement configuration on the corresponding PSU to generate power management information. The power management information can be stored in the PSU object path of the corresponding PSU device. After that, by reading the power management information of the corresponding PSU device, the corresponding PSU device can be normally started.
[0060] Through the above embodiments of the present application, by defining a perfect post-binding processing operation, it is ensured that the power supply device can be normally started without restarting the BMC and timely responding to the hot-swap state of the power supply device.
[0061] According to an embodiment of the present application, the loading method of the above-mentioned configuration file related to the first power supply unit may include at least one of the following: in response to detecting a presence signal indicating that the first power supply unit is present, loading a configuration file related to the first power supply unit. In response to detecting an attribute change signal for performing a change operation on the target attribute of the first power supply unit, loading the target attribute information.
[0062] According to an embodiment of the present application, the target attribute may characterize attributes of power management information such as D-Bus. The target attribute may include, for example, at least one of the following: sensor threshold, power upper and lower state, etc., and is not limited thereto. Among them, the sensor threshold may include, for example, at least one of the following: severe alarm threshold upper limit, severe alarm threshold lower limit, warning alarm threshold upper limit, warning alarm threshold lower limit, etc., and is not limited thereto. The power upper and lower state may include any one of being in the upper state and being in the lower state.
[0063] For example, when changing the in-position state of the first power supply unit to being in position, an InterfacesAdd signal may be generated, and this signal may characterize the above-mentioned in-position signal. After the entity-manager process detects the InterfacesAdd signal, it may trigger an operation to reload the configuration file to load the configuration file related to the first power supply unit.
[0064] For example, when modifying the target attribute of the first power supply unit through a web page or IPMI command, a PropertiesChanged signal may be generated, and this signal may characterize the above-mentioned attribute change signal. After the entity-manager process detects the PropertiesChanged signal, it may trigger an operation to reload the target attribute information with the modified attribute to load the target attribute information.
[0065] Through the above embodiments of the present application, the latest configuration information can be loaded in real time to achieve configuration of the power supply device according to the latest requirements.
[0066] According to an embodiment of the present application, the above operation S210 may include: in response to capturing a removal event, loading an unbinding rule. When the target power supply unit is the second power supply unit and the target driver is the second driver, the above operation S220 may include: determining a second driver identifier corresponding to the second power identifier of the second power supply unit that triggers the removal event according to the second power identifier. Using the unbinding rule, unbind the second power supply unit and the second driver characterized by the second driver identifier.
[0067] According to an embodiment of the present application, when a capture event is captured, a binding rule corresponding to the addition event may be loaded from a preset rule. The second power identifier can be directly read after detecting a device unplug signal. On this basis, in combination with the mapping relationship between the power supply unit and the driver pre-configured in the linux device tree, the second driver identifier corresponding to the second power identifier can be determined. Then, by running the unbinding script in the unbinding rule, the binding relationship between the second power supply unit and the second driver can be unbound and configured to unbind the second power supply unit from the first driver.
[0068] Through the above embodiments of the present application, by using preset rules to monitor events and perform unbinding, the hot-plug state of the power supply unit can be timely responded to without restarting the BMC, ensuring the accurate response of the system to changes in the hardware state.
[0069] According to an embodiment of the present application, when the relationship management operation includes an unbinding operation, the above operation S240 includes: updating the presence state of the second power supply unit to absent.
[0070] For example, after the power management module has been restarted, the psusensor process can update the presence state of the unbound PSU object to down, and does not need to delete the PSU object path created for the second power supply unit and the stored power management information, so that the second power supply unit can directly read and use them when it is next up.
[0071] It should be noted that according to actual business requirements, the PSU object path created for the second power supply unit and the stored power management information can also be deleted, which is not limited here.
[0072] Through the above embodiments of the present application, by defining perfect post-unbinding processing operations, the state of the power supply device can be timely updated without restarting the BMC, ensuring the accurate response of the system to changes in the hardware state.
[0073] According to an embodiment of the present application, the above power management method may further include: in response to an information acquisition request initiated for the power management information of the target power supply unit, sending the power management information to the web page for display.
[0074] For example, after the web page obtains the D-Bus information managed by the psusensor process through the application programming interface, it can update the power management information of the PSU in combination with the GET method, and the updated PSU can synchronize the detailed status of asset information such as voltage and power to the web management interface for display, so that users can operate and read.
[0075] Based on the above embodiments, Figure 3A Schematically shows the BMC power management timing diagram based on PSU hot-plug dynamic event detection according to an embodiment of the present application; Figure 3B Schematically shows the processing schematic diagram of the PSU hot-plug dynamic event according to an embodiment of the present application.
[0076] Such as Figure 3AAs shown in the figure, after performing the insertion / removal power operation of physically inserting / removing the PSU, the BMC side can first call the daemon process determined based on preset rules, such as the udev daemon process, to capture the PSU hot-plug event. Then, under the guidance of the udev rules, it can call a power sensor such as the psusensor process to perform related configurations such as binding and unbinding, and generate power management information such as D-Bus obtained from the current configuration. After that, it can call the application programming interface on the web page to further process the power management information such as D-Bus and send it to the web page for display.
[0077] such as Figure 3B As shown in the figure, after the BMC starts up, for physical plugging and unplugging actions such as the PSU, it will immediately start preset rules such as the ndev rules for loop detection. If a new PSU device is detected to be inserted or removed, it will immediately call the response module to dynamically load the corresponding driver to ensure that the PSU device can be recognized by the operating system. Specifically, based on the preset rules, in the case of detecting an add event generated by the insertion of the PSU, a binding operation can be performed. In the case of detecting a remove event generated by the removal of the PSU, an unbinding operation can be performed. Then, the Systemd (service manager) such as the power manager can be restarted to reload and obtain the power management information such as D-Bus of the currently inserted / removed PSU. After that, in combination with the application programming interface on the web page, it is possible to realize the reading, processing, and display of D-Bus information.
[0078] Through the above embodiments of the present application, a BMC power management method based on dynamic event detection is provided. By formulating udev rules and capturing, processing, and associating mechanisms for PSU hot-plug events with specific rule paths, as well as configuration reload and status synchronization operations, flexible management and control of hot-plug PSUs can be achieved through software programming, ensuring the accurate response of the system to hardware state changes.
[0079] Figure 4 The structural block diagram of the power management device according to an embodiment of the present application is schematically shown.
[0080] such as Figure 4 As shown in the figure, the power management device 400 includes a capture and load module 410, a relationship management module 420, a restart module 430, and an information update module 440.
[0081] The capture and load module 410 is configured to, when the baseboard management controller has started, in response to capturing a plug and unplug event characterizing the plugging and unplugging operation of the target power supply unit, call the device management daemon process to load the preset rules corresponding to the plug and unplug event.
[0082] The relationship management module 420 is used to dynamically load a target driver corresponding to a target power supply unit according to a preset rule, and perform relationship management operations corresponding to plugging and unplugging events on the target power supply unit and the target driver. The baseboard management controller is configured with a power management module and a target driver, and the power management module communicates with the target power supply unit through the target driver.
[0083] The restart module 430 is used to send a restart instruction to the power management module in response to determining that the relationship management operation has been successfully executed.
[0084] The information update module 440 is used to update the in-position status and power management information of the target power supply unit when it is detected that the power management module has restarted in response to the restart instruction.
[0085] According to an embodiment of the present application, the preset rule includes at least one of the following: an addition event indicating an insertion operation and a binding rule configured for the addition event, a removal event indicating a removal operation, and an unbinding rule configured for the removal event.
[0086] According to an embodiment of the present application, the capture and load module includes a binding rule loading unit.
[0087] The binding rule loading unit is used to load the binding rule in response to capturing an addition event.
[0088] According to an embodiment of the present application, when the target power supply unit is a first power supply unit and the target driver is a first driver, the relationship management module includes a first driver identification determination unit and a binding unit.
[0089] The first driver identification determination unit is used to determine a first driver identification corresponding to the first power identification according to the first power identification of the first power supply unit that triggers the addition event.
[0090] The binding unit is used to bind the first power supply unit and the first driver represented by the first driver identification by using the binding rule.
[0091] According to an embodiment of the present application, when the relationship management operation includes a binding operation, the information update module includes a configuration unit and a first status update unit.
[0092] The configuration unit is used to load a configuration file related to the first power supply unit, configure the first power supply unit, and generate power management information.
[0093] The first status update unit is used to update the in-position status of the first power supply unit to in-position.
[0094] According to an embodiment of the present application, the configuration unit includes at least one of the following: a configuration file loading subunit, a target attribute loading subunit.
[0095] A configuration file loading subunit, configured to load a configuration file related to the first power supply unit in response to detecting a presence signal indicating that the first power supply unit is present.
[0096] A target attribute loading subunit, configured to load target attribute information in response to detecting an attribute change signal for a change operation on the target attribute of the first power supply unit.
[0097] According to an embodiment of the present application, the capture loading module includes an unbinding rule loading unit.
[0098] The unbinding rule loading unit is configured to load an unbinding rule in response to capturing a removal event.
[0099] According to an embodiment of the present application, when the target power supply unit is the second power supply unit and the target drive is the second drive, the relationship management module includes a second drive identifier determination unit and an unbinding unit.
[0100] The second drive identifier determination unit is configured to determine a second drive identifier corresponding to the second power supply identifier of the second power supply unit that triggers the removal event.
[0101] The unbinding unit is configured to unbind the second power supply unit and the second drive represented by the second drive identifier by using the unbinding rule.
[0102] According to an embodiment of the present application, when the relationship management operation includes an unbinding operation, the information update module includes a second status update unit.
[0103] The second status update unit is configured to update the presence status of the second power supply unit to not present.
[0104] According to an embodiment of the present application, the power management device further includes a display module.
[0105] The display module is configured to send the power management information to a web page for display in response to an information acquisition request initiated for the power management information of the target power supply unit.
[0106] According to an embodiment of the present application, any plurality of modules among the capture and loading module 410, the relationship management module 420, the restart module 430, and the information update module 440 may be combined and implemented in one module, or any one of them may be split into multiple modules. Alternatively, at least part of the functions of one or more of these modules may be combined with at least part of the functions of other modules and implemented in one module. According to an embodiment of the present application, at least one of the capture and loading module 410, the relationship management module 420, the restart module 430, and the information update module 440 may be at least partially implemented as a hardware circuit, such as a field programmable gate array (FPGA), a programmable logic array (PLA), a system on chip, a system on substrate, a system on package, an application specific integrated circuit (ASIC), or may be implemented by any other reasonable means such as hardware or firmware by integrating or packaging circuits, or may be implemented in any one of the three implementation manners of software, hardware, and firmware or in an appropriate combination of any several of them. Alternatively, at least one of the capture and loading module 410, the relationship management module 420, the restart module 430, and the information update module 440 may be at least partially implemented as a computer program module, and when the computer program module is run, corresponding functions may be executed.
[0107] Figure 5 A block diagram of an electronic device suitable for implementing a power management method according to an embodiment of the present application is schematically shown.
[0108] As Figure 5 shown, the electronic device 500 includes a target driver 510, a power management module 520, and a baseboard management controller 530.
[0109] The power management module 520 is configured to communicate with the target power supply unit 540 through the target driver 510.
[0110] The baseboard management controller 530 is configured to: in the case of being started, in response to capturing a plug and unplug event characterizing the plug and unplug operation of the target power supply unit 540, call the device management daemon to load a preset rule corresponding to the plug and unplug event; according to the preset rule, dynamically load a target driver corresponding to the target power supply unit, and perform a relationship management operation corresponding to the plug and unplug event on the target power supply unit 540 and the target driver 510; in response to determining that the relationship management operation has been successfully executed, send a restart instruction to the power management module 520; and in the case of detecting that the restart of the power management module 520 in response to the restart instruction has been completed, update the in-position state and power management information of the target power supply unit 540.
[0111] The present application also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or may exist alone without being assembled into the device / apparatus / system. The above computer-readable storage medium carries one or more programs, and when the above one or more programs are executed, the methods according to the embodiments of the present application are implemented.
[0112] According to an embodiment of the present application, the computer-readable storage medium may be a non-volatile computer-readable storage medium, for example, it may include but is not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the above. In the present application, the computer-readable storage medium may be any tangible medium that contains or stores a program, and the program may be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to an embodiment of the present application, the computer-readable storage medium may include ROM (Read-Only Memory) and / or RAM (Random Access Memory) and / or one or more memories other than ROM and RAM.
[0113] Embodiments of the present application also include a computer program product, which includes a computer program, and the computer program contains program codes for executing the methods shown in the flowcharts. When the computer program product runs in a computer system, the program codes are used to cause the computer system to implement the power management method provided by the embodiments of the present application.
[0114] When the computer program is executed by a processor, the above functions defined in the system / apparatus of the embodiments of the present application are executed. According to an embodiment of the present application, the above-described systems, apparatuses, modules, units, etc. may be implemented by computer program modules.
[0115] In one embodiment, the computer program may rely on tangible storage media such as optical storage devices and magnetic storage devices. In another embodiment, the computer program may also be transmitted and distributed in the form of a signal on a network medium, and be downloaded and installed through the communication part, and / or be installed from a removable medium. The program codes included in the computer program may be transmitted by any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination of the above.
[0116] In such an embodiment, the computer program can be downloaded and installed from a network through the communication part, and / or installed from a removable medium. When the computer program is executed by a processor, the above functions defined in the system of the embodiments of the present application are performed. According to the embodiments of the present application, the above-described systems, devices, apparatuses, modules, units, etc. can be implemented by computer program modules.
[0117] According to the embodiments of the present application, the program code for executing the computer program provided by the embodiments of the present application can be written in any combination of one or more programming languages. Specifically, these computing programs can be implemented using high-level procedures and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages include, but are not limited to, such as Java, C++, Python, the "C" language, or similar programming languages. The program code can be executed entirely on the user computing device, partially on the user device, partially on a remote computing device, or entirely on a remote computing device or server. In the case of a remote computing device, the remote computing device can be connected to the user computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computing device (for example, by connecting through an Internet service provider via the Internet).
[0118] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architectures, functions, and operations of systems, methods, and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagram can represent a module, a program segment, or a part of code, and the above module, program segment, or part of code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than marked in the accompanying drawings. For example, two consecutive blocks shown may actually be executed substantially in parallel, and they may sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block in the block diagram or flowchart, and combinations of blocks in the block diagram or flowchart, can be implemented by a dedicated hardware-based system for performing the specified functions or operations, or can be implemented by a combination of dedicated hardware and computer instructions.
[0119] Those skilled in the art can understand that the features described in the various embodiments of the present application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in the present application. In particular, without departing from the spirit and teachings of the present application, the features described in the various embodiments of the present application can be combined and / or combined in various ways. All such combinations and / or combinations fall within the scope of the present application.
[0120] The embodiments of the present application have been described above. However, these embodiments are for illustrative purposes only and are not intended to limit the scope of the present application. Although the embodiments have been described separately above, this does not mean that the measures in each embodiment cannot be used advantageously in combination. Without departing from the scope of the present application, those skilled in the art can make various substitutions and modifications, and all such substitutions and modifications should fall within the scope of the present application.
Claims
1. A power management method, characterized in that: The method comprises: When the baseboard management controller is started, in response to capturing a plug-in and unplug-out event representing a plug-in and unplug-out operation of a target power supply unit, calling a device management daemon process to load a preset rule corresponding to the plug-in and unplug-out event; According to the preset rule, dynamically load a target driver corresponding to the target power supply unit, and perform a relationship management operation corresponding to the plug-in event on the target power supply unit and the target driver, wherein the baseboard management controller is configured with a power management module and the target driver, and the power management module communicates with the target power supply unit through the target driver; In response to determining that the relationship management operation has been successfully executed, sending a restart instruction to the power management module; and When it is detected that the power management module has restarted in response to the restart instruction, the in-place status and power management information of the target power supply unit are updated.
2. The method according to claim 1, characterized in that The preset rule includes at least one of the following: an add event indicating the presence of an insert operation and a binding rule configured for the add event, a remove event indicating the presence of a remove operation and an unbinding rule configured for the remove event.
3. The method according to claim 2, characterized in that In response to capturing a plug-in and unplug-out event representing a plug-in and unplug-out operation of a target power supply unit, calling a device management daemon to load a preset rule corresponding to the plug-in and unplug-out event includes: In response to capturing the adding event, loading the binding rule; In a case where the target power supply unit is a first power supply unit and the target driver is a first driver, dynamically loading a target driver corresponding to the target power supply unit according to the preset rule, and performing a relationship management operation corresponding to the plugging and unplugging event on the target power supply unit and the target driver includes: Determine, according to the first power source identifier of the first power supply unit that triggers the adding event, a first drive identifier corresponding to the first power source identifier; and The first power supply unit and the first driver represented by the first driver identifier are bound by using the binding rule.
4. The method according to claim 3, characterized in that In the case where the relationship management operation includes a binding operation, updating the in-place status and power management information of the target power supply unit includes: loading a configuration file related to the first power supply unit, configuring the first power supply unit, and generating the power management information; and The in-place status of the first power supply unit is updated to already in place.
5. The method according to claim 4, characterized in that The loading of a configuration file related to the first power supply unit includes at least one of the following: In response to detecting a presence signal indicating that the first power supply unit is in place, loading a configuration file related to the first power supply unit; In response to detecting a property change signal for performing a change operation on a target property of the first power supply unit, the target property information is loaded.
6. The method according to claim 2, characterized in that In response to capturing a plug-in and unplug-out event representing a plug-in and unplug-out operation of a target power supply unit, calling a device management daemon to load a preset rule corresponding to the plug-in and unplug-out event includes: In response to capturing the removal event, loading the unbinding rule; In a case where the target power supply unit is a second power supply unit and the target driver is a second driver, dynamically loading a target driver corresponding to the target power supply unit according to the preset rule, and performing a relationship management operation corresponding to the plug-in operation on the target power supply unit and the target driver includes: Determining, according to a second power source identifier of a second power supply unit that triggers the removal event, a second drive identifier corresponding to the second power source identifier; and The second power supply unit and the second driver represented by the second driver identifier are unbound by using the unbinding rule.
7. The method according to claim 6, characterized in that In the case where the relationship management operation includes an unbinding operation, updating the in-place status and power management information of the target power supply unit includes: The presence status of the second power supply unit is updated to not being present.
8. The method according to any one of claims 1 to 7, characterized in that The method further comprises: In response to an information acquisition request initiated for power management information of a target power supply unit, the power management information is sent to a web page for display.
9. An electronic device, characterized in that: The electronic device comprises: Goal driven; a power management module configured to communicate with a target power supply unit through the target driver; Baseboard management controller, configured to: In the case of being started, in response to capturing a plug-in and unplug-out event representing a plug-in and unplug-out operation of the target power supply unit, calling a device management daemon process to load a preset rule corresponding to the plug-in and unplug-out event; According to the preset rule, dynamically load a target driver corresponding to the target power supply unit, and perform a relationship management operation corresponding to the plug-in event on the target power supply unit and the target driver; In response to determining that the relationship management operation has been successfully executed, sending a restart instruction to the power management module; and When it is detected that the power management module has completed restarting in response to the restart instruction, the in-place status and power management information of the target power supply unit are updated.
10. A computer-readable storage medium having a computer program or instruction stored thereon, characterized in that: When the computer program or instruction is executed by a processor, the steps of the method according to any one of claims 1 to 8 are implemented.
Citation Information
Cited By
Power supply unit management system, server and power supply unit management method
CN120560483A
Power supply unit management system, server, and power supply unit management method
CN120560483B
Power supply control method and device of double-node server, computer equipment and medium
CN120762514A