A hierarchical power control method and system for heterogeneous service boards
Patent Information
- Application Number
- CN202611135976.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-29
- Publication Date
- 2026-10-23
AI Technical Summary
[0003]同时，业务板卡的IP地址可能处于机箱内网，外部管理系统无法直接访问；也可能处于可直连网络
（1）统一异构板卡功耗控制入口。
Smart Images
Figure CN122963323A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of device power management technology, specifically to a hierarchical power control method and system for heterogeneous service boards. Background Technology
[0002] In a device management scenario, multiple service boards may be deployed within the same chassis or device system. These service boards differ in hardware architecture, processor type, coprocessor loading method, and management channel. Some boards can achieve slight energy savings through operating system CPU frequency adjustment, while others require dedicated coprocessor loading or unloading logic to control runtime power consumption. Still others require power-off, power-on, or restart commands from the management card side during deep energy saving or recovery.
[0003] Meanwhile, the IP addresses of service cards may be located on the internal network of the chassis, inaccessible to the external management system; or they may be located on a directly connectable network. If the control system does not distinguish between access topology and power consumption levels, the following problems may easily occur: erroneously executing deep power-down commands during slight power reduction; erroneously executing commands that should be issued by the management card on the service card during deep recovery; failure to establish direct connections to unreachable internal network service cards; and initiating IPMI-type commands on cards that do not support management control.
[0004] Furthermore, existing technologies are mostly geared towards single devices, complete systems, or power supply modules, making it difficult to cover the differentiated power consumption control actions of different service boards. On the other hand, existing solutions often fail to distinguish between light power consumption modes and deep power consumption modes, easily mixing operations such as CPU frequency adjustment, coprocessor loading control, power-off, and restart, resulting in unclear execution domains and risk levels. Without considering asset topology for access link selection, control failures are likely to occur. For deep power consumption control, without first determining whether the board supports management control capabilities, power-off or restart commands may be issued to unsupported objects. Inconsistent return results from different commands are also detrimental to batch processing by upper-layer systems. Summary of the Invention
[0005] To help solve the above-mentioned technical problems, this application provides a hierarchical power consumption control method and system for heterogeneous service boards.
[0006] Firstly, this application provides a hierarchical power consumption control method for heterogeneous service boards, comprising: Receive a power consumption control request, the request carrying at least a target power consumption mode and a target power consumption level, the target power consumption level including a light level and a deep level; wherein, the light level is a level that reduces power consumption by adjusting the operating parameters of the service board without interrupting service operation, and the deep level is a level that switches power consumption by changing the power supply state of the service board and will interrupt service operation; Query the asset topology to obtain the business card type of the target business card and the topological relationship between the target business card and the management card, and determine the access link based on the topological relationship; Before switching power consumption modes, the current power consumption mode of the target service board is queried through the access link. If the current power consumption mode is consistent with the target power consumption mode, it is returned directly. If they are inconsistent, then the corresponding control action will be executed based on the service board type and the target power consumption level: When the target power consumption level is at a low level, runtime power consumption control is performed on the target service board to reduce power consumption and maintain the operation of the service board by adjusting the operating parameters of the service board; When the target power consumption level is the deep level, the management card is first used to detect whether the target service board supports power control. After confirming that it supports power control, power control is executed to achieve power consumption switching by changing the power supply state of the service board. The execution output and exception information of the control action are parsed into standardized power consumption status and unified return code.
[0007] After receiving the power consumption control request, the method further includes: Verify whether the target power consumption mode and the target power consumption level belong to the preset enumeration range. If they do not, return a parameter error.
[0008] The query asset topology obtains the business card type of the target business card and the topological relationship between the target business card and the management card, including: Based on the device identifier and target service board identifier in the power consumption control request, obtain the slot, service board type, service board IP, service board login information, management card IP, and management card login information of the target service board.
[0009] The process of determining the access link based on the topology includes: Based on the topology, determine whether the target service board is in a preset private network segment; If the network is located in the private network segment, configure an access link that jumps through the management card; otherwise, configure an access link that directly connects to the target service card.
[0010] The step of querying the current power consumption mode of the target service board through the access link includes: Select the corresponding status query command based on the service board type and the target power consumption level, execute the status query command through the access link, and parse the query result into power saving mode, performance mode or abnormal status.
[0011] The running power consumption control includes coprocessor loading state control commands, coprocessor unloading state control commands, CPU frequency adjustment commands, or CPU maximum frequency limit commands; the power control includes power-off commands, power-on commands, or restart commands. Execute corresponding control actions based on the service board type and the target power consumption level, including: For the first type of service board, the coprocessor loading status control command or the coprocessor unloading status control command is executed at the light level, and the power control command is executed at the deep level. For the second type of business board, CPU frequency adjustment command or CPU maximum frequency limit command is executed at the light level, and power control command is executed at the deep level. For unmatched service board types, an unsupported result is returned.
[0012] The execution of power control includes: When the target power consumption mode is energy saving mode, execute the power-off command; when the target power consumption mode is performance mode, execute the power-on command or restart command.
[0013] The runtime power consumption control is performed in the execution domain of the target service board; the power supply control is performed in the execution domain of the management card. When the target service board is in a preset private network segment and needs to perform runtime power consumption control, the management card will jump to the execution domain of the target service board for execution.
[0014] The step of parsing the execution output and exception information of the control action into standardized power consumption states and unified return codes includes: Map the reachability results, CPU frequency limit results, and coprocessor console output results to power saving mode or performance mode; Network errors, timeouts, authentication errors, permission errors, parsing errors, parameter errors, and unsupported errors are mapped to corresponding unified error codes and error descriptions.
[0015] Secondly, this application provides a hierarchical power consumption control system for heterogeneous service boards, wherein the system for executing the method as described in any one of the first aspects includes a unified power consumption control entry layer, an asset and topology identification layer, a strategy selection layer, a status verification layer, a command execution layer, and a result normalization layer. The unified power control entry layer is used to receive power control requests, the requests carrying at least the target power mode and the target power level; The asset and topology identification layer is used to query the asset topology, obtain the business card type of the target business card, and the topological relationship between the target business card and the management card, and determine the access link based on the topological relationship. The strategy selection layer is used to match the corresponding power control command and execution domain according to the service board type and the target power consumption level. The status verification layer is used to query the current power consumption mode of the target service board through the access link before switching power consumption modes. If the current power consumption mode is consistent with the target power consumption mode, it returns directly. When the target power consumption level is a deep level, it is also used to detect whether the target service board supports power control through the management card. The command execution layer is used to perform corresponding control actions based on the service board type and the target power consumption level when the current power consumption mode is inconsistent with the target power consumption mode: when the target power consumption level is a light level, running power control is performed on the target service board; when the target power consumption level is a deep level, power control is performed after confirmation of support. The result normalization layer is used to parse the execution output and exception information of the control action into standardized power consumption states and unified return codes.
[0016] In summary, compared with the prior art, this application has the following beneficial effects: (1) Unified power consumption control entry for heterogeneous boards.
[0017] This application shields the control differences between different service boards by using a unified request entry point, so that the upper-layer system does not need to directly perceive the underlying differences such as CPU frequency adjustment commands, coprocessor loading commands, and IPMI-type power commands, thereby reducing the coupling of the operation and maintenance system with board models and command details.
[0018] (2) Achieve graded control of light power consumption and deep power consumption.
[0019] This application divides power consumption control into light and deep levels. The light level focuses on reducing power consumption during operation, minimizing or eliminating interruptions to service boards; the deep level focuses on stronger control actions such as power-off, power-on, or restart. This classification method facilitates the selection of control strength based on service risks and avoids mixing low-risk actions such as frequency modulation with high-risk actions such as power-off.
[0020] (3) Automatically adapt to the execution domain of the business card and the execution domain of the management card.
[0021] This application automatically selects the service card execution domain or the management card execution domain based on the target power consumption level, target mode, and access topology. For service cards located within the chassis intranet, access is automatically redirected via the management card, resolving the issue of control failure caused by the inability to directly connect service cards.
[0022] (4) Reduce the risk of repeated switching and misoperation.
[0023] This application queries the current power consumption mode before setting it, and returns success directly if the current mode is equal to the target mode, avoiding repeated execution of the switching command. For deeper levels, it also checks the management control capabilities or IPMI support status; if not supported, it returns directly, thereby reducing the risk of anomalies caused by accidental power outages, accidental restarts, and unsupported commands.
[0024] (5) Facilitates the expansion of new board types and control commands. This application abstracts and encapsulates command generation, command execution environment, and output parsing logic through a command executor. When adding a new board type, new type matching rules and command executors can be added without changing the upper-layer interface and main process.
[0025] (6) Unified return status facilitates automated operation and maintenance.
[0026] This application normalizes different command outputs and exception information into a unified power consumption mode, return code, and error description. The upper-layer system can then use this to implement batch power consumption management, automatic retries, alarm prompts, and operation auditing. Attached Figure Description
[0027] Figure 1 This is a flowchart illustrating a hierarchical power consumption control method for heterogeneous service boards according to this application. Figure 2 This is a schematic block diagram of a hierarchical power consumption control system for heterogeneous service boards according to this application. Detailed Implementation
[0028] The present application will be further described below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely for explaining the present application and are not intended to limit the present application.
[0029] The core idea of this application is to first query the asset topology based on the device identifier and service board identifier to identify the service board type, service board address, management card address, and their topological relationships; then, based on the target power consumption mode and target power consumption level, select the corresponding command executor from the preset mapping relationship; subsequently, before execution, query the current power consumption mode. If the current mode is already consistent with the target mode, return success directly without repeated switching; if the target is a deep level, first probe the management and control capabilities, and execute deep power control only after confirming support; if the service board is located in a preset private network segment, establish a jump link for access through the management card; finally, unify the different command outputs, status query results, and abnormal information into standard power consumption status, return codes, and error messages.
[0030] Figure 1This application provides a flowchart illustrating a hierarchical power consumption control method for heterogeneous service boards. Based on the service board asset topology, the method first identifies the board type, management card information, and topological relationships, and determines the access link; then, it selects the corresponding control action according to the target power consumption level; before setting, it reads the current power consumption status, and skips the switching if the target is consistent; if it is deep control, it further detects management control capabilities; after execution, it parses the results of different commands into standardized power consumption status and unified return codes.
[0031] The following is combined with Figure 1 The method flow of the embodiments of this application will be described in detail below. The method includes the following steps: Step S1: Receive a power consumption control request.
[0032] The system receives power control requests submitted by upper-layer systems. These requests at least carry a target power consumption mode and a target power consumption level. The target power consumption level includes a light level and a deep level. The light level reduces power consumption by adjusting the operating parameters of service boards without interrupting service operation. The deep level switches power consumption by changing the power supply state of service boards, which will interrupt service operation. The target power consumption mode may include an energy-saving mode and a performance mode.
[0033] It should be noted that the distinction between light and deep control levels in this application is essentially based on the mechanism of the control action and its impact on business operations, rather than on specific power consumption thresholds. Light control levels involve reducing real-time power consumption by altering the internal operating parameters of the service board while maintaining the operating system and uninterrupted business logic. This type of operation carries low risk; even if it fails, it will not cause the service board to go offline or become unusable. Deep control levels, on the other hand, directly control the power supply circuit of the service board, either by cutting off power to completely stop it from working or by powering it on or restarting it. This type of operation will cause a complete interruption of all services on the service board and is considered a high-risk action. Therefore, in its process design, this application adds a pre-step for detecting management control capabilities for deep control levels to prevent accidental power-off or restart commands from being issued to boards that do not support power management.
[0034] Step S2: Verify the mode and level parameters.
[0035] Verify whether the target power consumption mode and the target power consumption level fall within a preset enumeration range. If the parameters are invalid, return a parameter error and terminate the process.
[0036] Step S3: Query the asset topology.
[0037] The asset topology is queried to obtain the service card type of the target service card and the topological relationship between the target service card and the management card. Specifically, based on the device identifier and the target service card identifier in the request, the slot, service card type, service card IP, service card login information, management card IP, and management card login information of the target service card are obtained.
[0038] Step S4: Determine the access link.
[0039] Based on the topology, determine whether the target service board is located in a preset private network segment. If it is located in the private network segment, configure an access link via the management card; otherwise, configure an access link directly connected to the target service board.
[0040] Step S5: Query the current power consumption mode.
[0041] Before switching power consumption modes, the current power consumption mode of the target service board is queried through the access link. Specifically, the corresponding status query command is selected according to the service board type and the target power consumption level, the status query command is executed through the access link, and the query result is parsed as power saving mode, performance mode, or abnormal status.
[0042] Step S6: Perform a target consistency check.
[0043] The current power consumption mode is compared with the target power consumption mode. If the current power consumption mode matches the target power consumption mode, the process returns directly and ends, avoiding repeated execution of the switching command.
[0044] Step S7: Determine if it is a depth level.
[0045] If the current power consumption mode is inconsistent with the target power consumption mode, the target power consumption level is further determined. If the target power consumption level is a deep level, proceed to step S8; if the target power consumption level is a light level, proceed to step S10.
[0046] Step S8: Detect management and control capabilities.
[0047] When the target power consumption level is at the deep level, the management card first detects whether the target service board supports power control. If it does not support it, a "not supported" result is returned, and the process terminates.
[0048] Step S9: Select and execute deep power control.
[0049] After confirming support for power control, power control is executed to switch power consumption by changing the power supply state of the service board. The power control includes a power-down command, a power-on command, or a restart command. Specifically, when the target power consumption mode is energy-saving mode, a power-down command is executed; when the target power consumption mode is performance mode, a power-on command or a restart command is executed. Then, proceed to step S11.
[0050] In this application, runtime power consumption control and power control are two different sets of control actions. Runtime power consumption control refers to control methods that act at the operating system or firmware level of the service board. Its characteristic is that the controlled object is the operating parameters of the service board itself, and the control result does not change the overall power supply state of the service board; the service board is always in a powered-on operating state. Power control, on the other hand, refers to control methods that act at the management card or power supply module level. Its characteristic is that the controlled object is the power supply state of the service board, and the control result directly changes the power-on or power-off state of the service board.
[0051] Step S10: Select and execute mild operating state power consumption control.
[0052] When the target power consumption level is low, runtime power consumption control is performed on the target service board to reduce power consumption while maintaining service board operation by adjusting the operating parameters of the service board. The runtime power consumption control includes coprocessor load state control commands, coprocessor unload state control commands, CPU frequency adjustment commands, or CPU maximum frequency limit commands.
[0053] When executing corresponding control actions based on the service board type and the target power consumption level, the specific rules are as follows: For the first type of service board, execute the coprocessor loading status control command or the coprocessor unloading status control command at the light level, and execute the power control command at the deep level; for the second type of service board, execute the CPU frequency adjustment command or the CPU maximum frequency limit command at the light level, and execute the power control command at the deep level; for unmatched service board types, return an unsupported result.
[0054] Step S11: Determine the execution domain and execute the command.
[0055] The runtime power consumption control is performed in the execution domain of the target service board; the power control is performed in the execution domain of the management card. When the target service board is in a preset private network segment and runtime power consumption control needs to be performed, the management card switches to the execution domain of the target service board. After determining the execution domain, the corresponding control command is issued and executed, and the original return output of the command, execution status, and other information are collected simultaneously.
[0056] The execution domain mentioned in this application refers to the actual location where power consumption control commands are issued and executed. Depending on the command type, the execution domain is divided into the service card execution domain and the management card execution domain. The service card execution domain means that commands are executed directly on the operating system or management interface of the target service card, suitable for light-level runtime power consumption control commands. The management card execution domain means that commands are executed on the management card, which controls the target service card, suitable for deep-level power control commands. When the target service card is located in a preset private network segment, even commands in the service card execution domain require a jump access link to be established through the management card; that is, the management card sends the command data to the target service card and transmits the result back.
[0057] Step S12: parse the status and error and return a unified result.
[0058] The execution output and exception information of the control actions are parsed into standardized power consumption states and unified return codes. Specifically, reachability results, CPU frequency limit results, and coprocessor console output results are mapped to power saving mode or performance mode; network exceptions, timeouts, authentication exceptions, permission exceptions, parsing exceptions, parameter exceptions, and unsupported exceptions are mapped to corresponding unified error codes and error descriptions. Finally, a standardized unified return result is output, including the final standard power consumption state, unified return code, and error description, and the entire power consumption control process ends.
[0059] Figure 2 This is a schematic block diagram of a hierarchical power consumption control system for heterogeneous service boards, used to execute the aforementioned method. The system adopts a top-down hierarchical structure, divided into six layers from request access to result output. Each layer transmits data and control logic via arrows and includes multiple cross-layer branch links, fully covering the entire power consumption control process. The layers are connected by a top-down serial main link and multiple branch cross-layer links: the main link sequentially connects all layers along the request processing direction, completing the entire process of power consumption control requests; multiple cross-layer branch links are set up, corresponding to four special logics: private network link determination, command distribution, status return, and capability verification, to achieve precise transmission of data and control signals. Each layer's internal units are divided into two connection types based on functional logic: serial cascading and parallel input / output. The system includes: A unified power consumption control entry layer receives power consumption control requests, which at least carry the target power consumption mode and target power consumption level. This layer receives power consumption control requests submitted by the upper-layer system, performs basic parameter verification, and passes valid requests to the subsequent asset and topology identification layer. The target power consumption mode may include energy-saving mode and performance mode, and the target power consumption level may include mild level and deep level. The mild level reduces power consumption by adjusting the operating parameters of the service board without interrupting service operation, while the deep level switches power consumption by changing the power supply state of the service board, which will interrupt service operation.
[0060] This layer contains a request parsing unit and a parameter validation unit: The request parsing unit is used to receive and parse the power control requests submitted by the upper layer system, and extract core parameters such as device identifier, service board identifier, target power mode, and target power level. The parameter verification unit is used to verify whether the target power consumption mode and target power consumption level are within the preset enumeration range, and directly returns the parameter error result for illegal parameters.
[0061] The internal units of this layer are in a serial cascaded relationship: the output of the request parsing unit is connected to the input of the parameter verification unit. The request parsing is completed first, and then the parameter validity verification is performed.
[0062] The external connection relationship of this layer is as follows: the output of the parameter verification unit is connected downwards to the input of the asset and topology identification layer, and only valid requests that pass the verification are passed downwards.
[0063] The asset and topology identification layer is used to query the asset topology, obtain the service card type of the target service card, and the topological relationship between the target service card and the management card, and determine the access link based on the topological relationship. This layer queries the asset topology database based on the device identifier and target service card identifier in the request to obtain the slot, service card type, service card IP, service card login information, management card IP, and management card login information of the target service card. This layer also determines whether the IP address of the target service card belongs to the chassis intranet based on a preset private network segment; if it belongs to the chassis intranet, it configures an access link via the management card; if it does not belong to the chassis intranet, it configures an access link directly connected to the target service card.
[0064] It should be noted that the management card mentioned in this application refers to a board within the same chassis or equipment system that undertakes external communication and internal management functions. In this application, the management card plays two key roles: first, as a jump node, when the target service board is in a preset private network segment, the external system establishes a jump access link through the management card, forwards commands to the target service board, and returns the execution results; second, as an execution agent for power control, for deep-level power-down, power-on, or restart commands, the power management interface on the management card side executes them uniformly, rather than the service board itself.
[0065] This layer contains service board information units, management card information units, and private network judgment units: The business board information unit is used to extract basic data such as the slot, board type, IP address, and login information of the target business board from the asset topology. The management card information unit is used to extract management-side data such as the IP address and login information of the corresponding management card from the asset topology; The private network determination unit is used to determine whether the target service board is on the internal network of the chassis based on the preset private network segment, thereby determining the configuration method of the access link.
[0066] The internal units of this layer are in a parallel processing relationship: the business board information unit and the management card information unit receive the request identifiers sent down from the upper layer in parallel and extract the corresponding asset information respectively; the private network judgment unit performs network segment judgment based on the IP address data output by the business board information unit. The three types of processing results together constitute the main output of this layer.
[0067] This layer's external connections are divided into two paths: The main output link connects downwards to the input end of the policy selection layer, transmitting topology information such as board type and access address to the policy matching stage; The private network judgment unit has a separate vertical branch link that connects to the jump access link unit of the command execution layer and the unified response unit of the result normalization layer in sequence. It transmits the private network judgment result throughout the process and is used to control the selection of access link and the collection of link status of the final result.
[0068] The strategy selection layer is used to match the corresponding control command executor and execution domain based on the service board type and target power consumption level. This layer internally includes a board type identification unit, a power consumption level identification unit, and a command executor selection unit. The board type identification unit is used to identify the hardware type of the target service board and distinguish the board categories of different control logics. A power level identification unit is used to identify whether the target power level in the request is a light level or a deep level. The command executor selection unit is used to match the corresponding command executor based on the service board type and the target power consumption level: for the first type of service board, a coprocessor load / unload control command executor is matched at the light level, and a power control command executor is matched at the deep level; for the second type of service board, a CPU frequency adjustment or CPU maximum frequency limit command executor is matched at the light level, and a power control command executor is matched at the deep level; for unmatched board types, an unsupported return result is generated.
[0069] The internal units of this layer are connected in a parallel input and aggregated output manner: the board type identification unit and the power consumption level identification unit receive the topology information and request parameters output from the upper layer in parallel. The identification results of the two are jointly input to the command executor selection unit, which completes the matching and output of control commands and execution domains.
[0070] This layer's external connections are divided into two paths: 1. The main output link connects downwards to the input of the status verification layer, transmitting the board type, power consumption level, and matching rules to the pre-verification stage; 2. The command executor selection unit leads out two diagonal branch links respectively. The left branch connects to the service card execution domain unit of the command execution layer, and the right branch connects to the management card execution domain unit of the command execution layer, so as to directly distribute the matched control commands to the corresponding execution domain.
[0071] The status verification layer is used to query the current power consumption mode of the target service board through the access link before switching power consumption modes. If the current power consumption mode is consistent with the target power consumption mode, it returns directly. When the target power consumption level is a deep level, it is also used to detect whether the target service board supports power control through the management card. This layer queries the current power consumption mode before executing the setting. If the current power consumption mode is already equal to the target power consumption mode, it returns directly without repeating the switching command. If the target power consumption level is a deep level, this layer also executes a management capability detection command through the management card to determine whether the target service board supports deep power control; if it does not support it, it returns a result indicating that it does not support it.
[0072] This layer contains a current pattern query unit, a target consistency judgment unit, and a management capability detection unit. The current mode query unit is used to select the corresponding status query command according to the board type and power consumption level, obtain the current power consumption mode of the target service board through the determined access link, and parse it into a standard state. The target consistency judgment unit is used to compare the current power consumption mode with the target power consumption mode. If the two are consistent, it will directly return success and terminate the subsequent switching process. The management capability detection unit is used to detect whether the target service board supports power control when the target power consumption level is deep level. If it does not support power control, it returns a result indicating that it does not support power control.
[0073] The internal unit connection relationship of this layer is as follows: the current mode query unit receives the parameters and rules input from the upper layer, and outputs the current power consumption status obtained from the query to the target consistency judgment unit; when the target power consumption level is the depth level, the target consistency judgment unit triggers the management capability detection unit to perform detection, and the detection result is output independently.
[0074] This layer's external connections are divided into three paths: 1. The main output link connects downwards to the input end of the command execution layer, passing the verified switching command to the execution stage; 2. The target consistency judgment unit leads out a direct return branch link, which directly connects to the unified response unit of the result normalization layer. When the current state is consistent with the target, it skips the execution layer and directly returns a success result. 3. The management capability detection unit leads out a verification branch link, which connects downward to the management card execution domain unit of the command execution layer. The management card execution domain is only allowed to start the deep power control command when the detection is successful.
[0075] The command execution layer is used to perform corresponding control actions based on the service board type and the target power consumption level when the current power consumption mode is inconsistent with the target power consumption mode: when the target power consumption level is a light level, runtime power consumption control is performed on the target service board to reduce power consumption and maintain service board operation by adjusting the operating parameters of the service board; when the target power consumption level is a deep level, power control is performed after confirmation of support to achieve power consumption switching by changing the power supply state of the service board.
[0076] This layer contains service card execution domain units, management card execution domain units, and redirection access link units: The service card execution domain unit, as the main body for light power consumption control, is responsible for executing the running power consumption control commands on the service board side; The management card execution domain unit, as the main body for deep power control, is responsible for executing power control commands such as power-off, power-on, and restart on the management card side; The jump access link unit is used to establish an access channel with the management card as the jump node when the target service card is in the private network segment of the chassis, so as to realize the issuance of commands and status query of the internal network service card.
[0077] Specifically, for the first type of service board, a coprocessor loading status control command or a coprocessor unloading status control command is used at the light level, and a power control command is used at the deep level; for the second type of service board, a CPU frequency adjustment command or a CPU maximum frequency limit command is used at the light level, and a power control command is used at the deep level; for unmatched board types, an unsupported result is returned.
[0078] During command execution, power consumption control at the light-level runtime is performed within the execution domain of the target service board; power control at the deep-level runtime is performed within the execution domain of the management card. For service boards located in a preset private network segment, this layer establishes an access link through the management card as a jump node, thus enabling command execution on the service board side even when external systems cannot directly connect to the target service board.
[0079] The internal unit connection relationship of this layer is as follows: the service card execution domain unit and the management card execution domain unit are parallel independent execution channels, which respectively receive the corresponding control commands distributed by the upper layer; the jump access link unit receives the private network determination result transmitted by the asset and topology identification layer, and provides jump access channel support for the service card execution domain unit when the target service card is in the private network segment.
[0080] The external connections of this layer are as follows: the input end receives command distribution signals from the strategy selection layer, switching instructions and capability verification signals from the status verification layer, and private network determination signals from the asset and topology identification layer; the output results of all execution channels are uniformly connected downwards to the input end of the result normalization layer.
[0081] The result normalization layer is used to parse the execution output and exception information of the control actions into standardized power consumption states and unified return codes. This layer parses different command outputs into unified standard power consumption states and error information. Specifically, it maps reachability results, CPU frequency limit results, and coprocessor console output results to power-saving mode or performance mode; for network exceptions, timeouts, authentication exceptions, permission exceptions, parsing exceptions, parameter exceptions, and unsupported exceptions, it outputs unified error codes and error descriptions.
[0082] This layer contains a state resolution unit, an error classification unit, and a unified response unit. The state parsing unit is used to uniformly map the original execution output of different control commands into standard power consumption states such as energy-saving mode and performance mode. The error classification unit is used to map various exception information during the execution process, such as network exceptions, timeouts, authentication exceptions, and permission exceptions, into corresponding unified error codes and error descriptions; The unified response unit is used to collect standardized power consumption status and error information, and output the final response result in a unified format.
[0083] The internal units of this layer are connected in a parallel parsing and output aggregation relationship: the state parsing unit and the error classification unit receive the raw output of the command execution layer in parallel, and respectively complete the state mapping and error encoding; the processing results of the two are input into the unified response unit, which aggregates them into a standardized final response.
[0084] The external connection relationships of this layer are as follows: the input end simultaneously receives three types of signals: the command execution output of the command execution layer, the status consistency return signal of the status verification layer, and the link status signal of the asset and topology identification layer; the unified response unit, as the final output end of the entire system, returns power consumption status, return code, and error description in a unified format to the upper layer system.
[0085] The technical scope of this application is not limited to the contents of the above specification. Those skilled in the art can make various modifications and variations to the above embodiments without departing from the technical concept of this application, and all such modifications and variations should fall within the scope of this application.
Claims
1. A hierarchical power consumption control method for heterogeneous service boards, characterized in that, include: Receive a power consumption control request, the request carrying at least a target power consumption mode and a target power consumption level, the target power consumption level including a light level and a deep level; wherein, the light level is a level that reduces power consumption by adjusting the operating parameters of the service board without interrupting service operation, and the deep level is a level that switches power consumption by changing the power supply state of the service board and will interrupt service operation; Query the asset topology to obtain the business card type of the target business card and the topological relationship between the target business card and the management card, and determine the access link based on the topological relationship; Before switching power consumption modes, the current power consumption mode of the target service board is queried through the access link. If the current power consumption mode is consistent with the target power consumption mode, it is returned directly. If they are inconsistent, then the corresponding control action will be executed based on the service board type and the target power consumption level: When the target power consumption level is at a low level, runtime power consumption control is performed on the target service board to reduce power consumption and maintain the operation of the service board by adjusting the operating parameters of the service board; When the target power consumption level is the deep level, the management card is first used to detect whether the target service board supports power control. After confirming that it supports power control, power control is executed to achieve power consumption switching by changing the power supply state of the service board. The execution output and exception information of the control action are parsed into standardized power consumption status and unified return code.
2. The method according to claim 1, characterized in that, After receiving the power consumption control request, the method further includes: Verify whether the target power consumption mode and the target power consumption level belong to the preset enumeration range. If they do not, return a parameter error.
3. The method according to claim 1, characterized in that, The query asset topology obtains the business card type of the target business card and the topological relationship between the target business card and the management card, including: Based on the device identifier and target service board identifier in the power consumption control request, obtain the slot, service board type, service board IP, service board login information, management card IP, and management card login information of the target service board.
4. The method according to claim 1, characterized in that, The process of determining the access link based on the topology includes: Based on the topology, determine whether the target service board is in a preset private network segment; If the network is located in the private network segment, configure an access link that jumps through the management card; otherwise, configure an access link that directly connects to the target service card.
5. The method according to claim 1, characterized in that, The step of querying the current power consumption mode of the target service board through the access link includes: Select the corresponding status query command based on the service board type and the target power consumption level, execute the status query command through the access link, and parse the query result into power saving mode, performance mode or abnormal status.
6. The method according to claim 1, characterized in that, The running power consumption control includes coprocessor loading state control commands, coprocessor unloading state control commands, CPU frequency adjustment commands, or CPU maximum frequency limit commands; the power control includes power-off commands, power-on commands, or restart commands. Execute corresponding control actions based on the service board type and the target power consumption level, including: For the first type of service board, the coprocessor loading status control command or the coprocessor unloading status control command is executed at the light level, and the power control command is executed at the deep level. For the second type of business board, CPU frequency adjustment command or CPU maximum frequency limit command is executed at the light level, and power control command is executed at the deep level. For unmatched service board types, an unsupported result is returned.
7. The method according to claim 1, characterized in that, The execution of power control includes: When the target power consumption mode is energy saving mode, execute the power-off command; when the target power consumption mode is performance mode, execute the power-on command or restart command.
8. The method according to claim 1, characterized in that, The runtime power consumption control is performed in the execution domain of the target service board; the power supply control is performed in the execution domain of the management card. When the target service board is in a preset private network segment and needs to perform runtime power consumption control, the management card will jump to the execution domain of the target service board for execution.
9. The method according to claim 1, characterized in that, The step of parsing the execution output and exception information of the control action into standardized power consumption states and unified return codes includes: Map the reachability results, CPU frequency limit results, and coprocessor console output results to power saving mode or performance mode; Network errors, timeouts, authentication errors, permission errors, parsing errors, parameter errors, and unsupported errors are mapped to corresponding unified error codes and error descriptions.
10. A hierarchical power consumption control system for heterogeneous service boards, characterized in that, The system for implementing the hierarchical power consumption control method for heterogeneous service boards as described in any one of claims 1 to 9 includes a unified power consumption control entry layer, an asset and topology identification layer, a policy selection layer, a status verification layer, a command execution layer, and a result normalization layer. The unified power control entry layer is used to receive power control requests, the requests carrying at least the target power mode and the target power level; The asset and topology identification layer is used to query the asset topology, obtain the business card type of the target business card, and the topological relationship between the target business card and the management card, and determine the access link based on the topological relationship. The strategy selection layer is used to match the corresponding power control command and execution domain according to the service board type and the target power consumption level. The status verification layer is used to query the current power consumption mode of the target service board through the access link before switching power consumption modes. If the current power consumption mode is consistent with the target power consumption mode, it returns directly. When the target power consumption level is a deep level, it is also used to detect whether the target service board supports power control through the management card. The command execution layer is used to perform corresponding control actions based on the service board type and the target power consumption level when the current power consumption mode is inconsistent with the target power consumption mode: when the target power consumption level is a light level, running power control is performed on the target service board; when the target power consumption level is a deep level, power control is performed after confirmation of support. The result normalization layer is used to parse the execution output and exception information of the control action into standardized power consumption states and unified return codes.