A data center power load elasticity allocation system

Abstract

The application discloses a data center power load elasticity distribution system and relates to the technical field of data center power load management. The system comprises an event queue module, a strategy generation module, a priority module, a conflict resolution module and an elasticity execution module. The event queue module establishes a time-space associated event queue of a current power load topology and generates a power load elasticity container mapped with the time-space associated event queue. The strategy generation module generates an elasticity distribution strategy according to the time-space associated event queue and the power load elasticity container, and the strategy comprises a voltage frequency adjustment strategy, a server hibernation and wake-up strategy and a load migration strategy. The priority module dynamically prioritizes the elasticity distribution strategy. After a dominant strategy is selected according to the dynamic priority sorting result, the conflict resolution module performs conflict resolution between the dominant strategy and other strategies. The elasticity execution module executes the elasticity distribution according to the conflict resolution result. The system realizes the elasticity distribution of the power load based on current and power monitoring data at the end of the cabinet, effectively avoids the cabinet power over-limit risk and eliminates the resource conflict between adjustment actions.

Description

Technical Field

[0001] This invention relates to the field of data center power load management technology, specifically a data center power load elastic distribution system. Background Technology

[0002] Elastic distribution of power load in data centers is a crucial means of improving energy efficiency and power supply stability. Existing load balancing technologies typically treat server clusters as static objects, triggering uniform frequency adjustments, hibernation, or migration actions based on overall power thresholds or preset schedules, making it difficult to capture the spatiotemporal correlation characteristics of load fluctuations. In actual operation, a sudden increase in power in a local rack can propagate to neighboring areas through cooling correlations and network dependencies. Response methods based on static thresholds often lag behind the speed of event propagation, failing to provide differentiated handling in terms of timing and amount of adjustment commensurate with the severity of the impact.

[0003] Existing solutions lack effective mitigation of interference between multiple load balancing actions after generating them. When different balancing strategies are executed independently for servers within the same rack or heat dissipation zone, the cumulative power adjustments may exceed the equipment's tolerance. Alternatively, power fluctuations caused by voltage and frequency adjustments may compete for resources with the scope of load migration actions, leading to actual balancing effects deviating from expectations or even triggering new overloads. Conventional approaches rely on simple mutexes or first-come-first-served mechanisms to resolve conflicts, failing to restructure strategies from the perspectives of event priority, timing offsets, and physical coupling. This can easily result in high-impact event balancing being blocked or delayed by inefficient actions.

[0004] How to quantify the spatiotemporal propagation characteristics of rack-level power events into a sortable event queue and introduce power superposition judgment constraints in conflict resolution has become an urgent problem to be solved in the elastic allocation of power load in data centers. Summary of the Invention

[0005] This invention provides a data center power load elastic allocation system. By establishing a spatiotemporal correlation event queue for the instantaneous power of the server rack and mapping it to a power load elastic container, a variety of elastic adjustment actions are generated. After dynamic priority sorting, elastic allocation is executed to improve the timeliness of load adjustment and the coordination between actions.

[0006] The objective of this invention can be achieved through the following technical solutions: This invention provides a data center power load elastic allocation system, comprising an event queue module, a policy generation module, a priority module, a conflict resolution module, and an elastic execution module. The event queue module establishes a spatiotemporally correlated event queue of the current power load topology and generates a power load elastic container mapped to the spatiotemporally correlated event queue. The policy generation module generates elastic allocation policies based on the spatiotemporally correlated event queue and the power load elastic container. These elastic allocation policies include voltage / frequency adjustment policies, server sleep / wake-up policies, and load migration policies. The priority module dynamically prioritizes the elastic allocation policies. The conflict resolution module selects a dominant policy based on the dynamic priority ranking and then resolves conflicts between the dominant policy and other policies. The elastic execution module executes elastic allocation based on the conflict resolution results. This solution, by modeling the spatiotemporal correlation of power load events and encapsulating them into elastic containers, provides a global perspective for subsequent policy generation and scheduling, improving the alignment of allocation policies with the real-time operating status of the data center.

[0007] As a technical solution of the present invention, when the event queue module establishes the spatiotemporal related event queue of the current power load topology, it specifically does the following: collect the instantaneous power and the current at the end of each cabinet, and generate event tuples with timestamps; construct an event propagation directed graph according to the network connection relationship between cabinets, and calculate the influence distance of each event tuple in the event propagation directed graph; assign event weights to each event tuple according to the influence distance and the instantaneous power value; and store the corresponding event tuples into a double-ended queue in descending order of the event weights to form the spatiotemporal related event queue of the current power load topology. Based on this, when generating the power load elastic container mapped to the spatiotemporally related event queue, an elastic adjustment range is allocated to each event tuple in the spatiotemporally related event queue. This elastic adjustment range records the adjustable power range and adjustable power range of the cabinet corresponding to the event tuple during the event duration. The identifier of each event tuple, the event duration, the adjustable power range, and the adjustable power range are encapsulated into an elastic unit. All elastic units are combined into the power load elastic container according to the order of the corresponding event tuples in the spatiotemporally related event queue, and a memory mapping table from event tuple identifiers to elastic units is established for the power load elastic container. By introducing influence distance and event weight, the system can accurately identify key events with a wide impact range on the power load topology and large power impact, and prioritize their response. The elastic container defines a clear power adjustment boundary for each event, avoiding adjustment actions exceeding the physical limitations of the equipment, and improving the stability and security of system operation.

[0008] As a further technical solution of the present invention, when the strategy generation module generates an elastic allocation strategy based on the spatiotemporal related event queue and the power load elastic container, it traverses each event tuple in the spatiotemporal related event queue, reads the identifier of the event tuple, and finds the corresponding elastic unit through the memory mapping table of the power load elastic container; based on the adjustable power range and adjustable power range in the elastic unit, combined with the current load rate of the rack corresponding to the event tuple, it generates a candidate action set for the event tuple, the candidate action set including at least one of voltage frequency adjustment action, server sleep wake-up action, and load migration action; it randomly selects an action from the candidate action set as the elastic allocation sub-strategy for the event tuple, binds the elastic allocation sub-strategy with the identifier of the event tuple and stores it in the strategy table, and after traversal, summarizes all the bound elastic allocation sub-strategies in the strategy table into the elastic allocation strategy. This generation method combines the power elasticity space with the real-time load rate, enabling each rack to autonomously select an appropriate adjustment action based on its own adjustability potential, which ensures the diversity of strategies and avoids the computational complexity brought about by centralized decision-making.

[0009] When the priority module dynamically prioritizes the elastic allocation strategy, it reads each elastic allocation sub-strategy from the elastic allocation strategy, extracts the event weight of the event tuple corresponding to the elastic allocation sub-strategy and the action type corresponding to the elastic allocation sub-strategy; it queries a preset urgency mapping table according to the action type to obtain the urgency coefficient of the elastic allocation sub-strategy; it uses the product of the event weight and the urgency coefficient as the original priority score of the elastic allocation sub-strategy, and attenuates the original priority score according to the hierarchical depth of the cabinet corresponding to the elastic allocation sub-strategy in the network topology to obtain the final priority score; it then rearranges all elastic allocation sub-strategies in the elastic allocation strategy in descending order of the final priority scores to generate the sorted elastic allocation strategy. This sorting mechanism integrates the severity of events, the timeliness of action types, and the location of cabinets in the topology, enabling adjustment actions located on the network critical path with tight response time windows to be prioritized, thereby effectively suppressing the spread of faults or congestion along the network topology.

[0010] After selecting a dominant strategy based on the dynamic priority ranking result, the conflict resolution module executes conflict resolution between the dominant strategy and other strategies. Preferably, the top-ranked elastic allocation sub-strategy among the ranked elastic allocation strategies is selected as the dominant strategy. The rack identifier and power adjustment amount of the dominant strategy are read. Each remaining elastic allocation sub-strategy in the ranked elastic allocation strategies is then iterated through, checking if its rack identifier is the same as the dominant strategy's. If they are the same, the power adjustment amount of the elastic allocation sub-strategy and the dominant strategy are combined for conflict determination. When the combined power adjustment amount exceeds the rack's power adjustment limit, conflict resolution is triggered. The execution timestamp of each remaining elastic allocation sub-strategy is shifted to after the dominant strategy has completed execution, and the priority of the shifted elastic allocation sub-strategy is recalculated. Furthermore, upon triggering conflict resolution, the expected execution duration of the dominant strategy is obtained, and the original timestamps of the remaining elastic allocation sub-strategies are incremented by the expected execution duration to obtain offset timestamps. A delay penalty coefficient is calculated based on the difference between the offset timestamp and the current time, and this coefficient is multiplied by the original priority score of the remaining elastic allocation sub-strategies to obtain adjusted priority scores. The remaining elastic allocation sub-strategies are then reordered in the remaining queue based on the adjusted priority scores, and the strategy ranked first after reordering is updated as the new dominant strategy. The conflict resolution process is then repeated until all conflicts among the elastic allocation sub-strategies are resolved. Through timestamp offset and priority recalculation, the system resolves power superposition conflicts of multiple adjustment actions on the same rack without discarding any adjustment actions. The delay penalty mechanism ensures that delayed actions still receive a fair scheduling opportunity within the new time window.

[0011] In another implementation, when selecting a dominant strategy, the first elastic allocation sub-strategy in the sorted elastic allocation strategies is selected as a candidate dominant strategy. The rack identifier and power adjustment amount of the candidate dominant strategy are read. All elastic allocation sub-strategies in the sorted elastic allocation strategies, excluding the candidate dominant strategy, are traversed. The power adjustment amounts of all elastic allocation sub-strategies sharing the same rack identifier as the candidate dominant strategy are accumulated to obtain a cumulative adjustment amount. When the sum of the cumulative adjustment amount and the power adjustment amount of the candidate dominant strategy does not exceed the power adjustment limit of the rack, the candidate dominant strategy is formally selected as the dominant strategy. When the sum exceeds the power adjustment limit of the rack, the candidate dominant strategy is skipped, and the next elastic allocation sub-strategy in the sorted elastic allocation strategies is selected as the new candidate dominant strategy, and the selection process is repeated. This predictive selection method can avoid potential power overflow risks during the dominant strategy determination stage, reducing the number of iterations for subsequent conflict resolution.

[0012] Furthermore, when resolving conflicts between the dominant strategy and other strategies, the power adjustment amount of the dominant strategy can be locked as an immutable value. Other flexible allocation sub-strategies that do not conflict with the dominant strategy's rack identifier are then sequentially traversed. For each traversed flexible allocation sub-strategy, it is checked whether the execution of this sub-strategy will cause the total power or total current of the rack corresponding to the dominant strategy to exceed the physical limit. When the execution of this flexible allocation sub-strategy involves core monitoring components, a coupling constraint condition between power and operating status is constructed, which limits the maximum allowable power and maximum allowable current of the rack. The power adjustment amount of the flexible allocation sub-strategy is reduced according to the coupling constraint condition to generate the decoupled execution parameters, and these decoupled execution parameters are written back to the flexible allocation sub-strategy.

[0013] When the elastic execution module performs elastic allocation based on the conflict resolution results, it reads the final policy queue generated after conflict resolution. Each entry in the final policy queue contains an elastic allocation sub-policy, its adjusted execution timestamp, and the adjusted power adjustment amount. The module retrieves the corresponding elastic allocation sub-policies sequentially according to the execution timestamps and parses the action type of each sub-policy. When the action type is a voltage / frequency adjustment policy, a dynamic voltage / frequency adjustment command is sent to the target server's baseboard management controller, with the command parameters including the adjusted power adjustment amount. When the action type is a server sleep / wake-up policy, a sleep or wake-up command is sent to the target server's power management unit. When the action type is a load migration policy, a virtual machine migration command is sent to the load balancer, with the virtual machine migration command including the source server identifier, target server identifier, and migration data volume. The elastic execution module directly converts the resolved policies into standard commands for the underlying hardware and virtualization management components, achieving seamless integration from global scheduling decisions to device-level execution and ensuring the accurate implementation of elastic allocation policies.

[0014] The data center power load elastic allocation system provided by this invention abstracts the power load through a spatiotemporally correlated event queue and elastic containers, transforming discrete power into structured objects with adjustment boundaries. During the strategy generation phase, candidate actions are randomly selected, balancing efficiency and exploratory capabilities. Dynamic priority sorting integrates event weight, action urgency, and topology level to ensure critical adjustment actions are executed first. A conflict resolution mechanism handles power overlap conflicts within the same rack and achieves drop-free scheduling through timestamp offset and priority rearrangement. Finally, the elastic execution module precisely issues instructions based on type. The entire system forms a closed loop from event perception, strategy generation, priority coordination, conflict resolution to final execution, fully utilizing the power adjustment elasticity of each rack while ensuring data center power and thermal safety, thereby improving power resource utilization efficiency and load allocation flexibility.

[0015] The beneficial effects of this invention are: A directed event propagation graph is constructed based on the network connections between server racks. The influence distance of each timestamped event tuple in the topology is calculated. Event weights are assigned based on instantaneous power values, and the events are sorted by weight to form a spatiotemporally correlated event queue. Each event tuple in the queue is assigned a flexible adjustment range and encapsulated into a flexible unit, which is then combined into a power load flexible container, and a memory mapping table is established between identifiers and flexible units. This structure transforms the originally scattered power events into a priority sequence with quantifiable propagation impact. At the same time, it directly associates adjustable power ranges with events, enabling subsequent policy generation to quickly locate the adjustable range of the corresponding event, avoiding the latency and blind adjustment problems introduced by global traversal of power boundaries.

[0016] During conflict resolution, after selecting the dominant strategy ranked first in the dynamic priority sorting, it checks whether the power adjustment amount of the remaining strategies with the same rack identifier, combined with the dominant strategy, exceeds the power adjustment limit. If it does, the execution timestamp of the strategy is shifted to after the dominant strategy has been completed, and a delay penalty coefficient is introduced to recalculate the priority score, causing the remaining strategies to be reordered to form a new dominant strategy. This process iterates until all conflicts are resolved. For actions that do not conflict with the dominant strategy but involve the same rack power supply circuit, power constraints are constructed to limit the maximum current and power of the rack, thereby reducing the power adjustment amount of that strategy. This approach solves the short-term power limit exceedance problem caused by the superposition of multiple actions in the same rack and also handles the indirect conflicts caused by thermal coupling between different racks. This ensures that the elastic allocation results are consistent in terms of timing and physical constraints, avoiding rack overcurrent tripping or power limit exceedance caused by simply prioritizing preemption. Attached Figure Description

[0017] The invention will now be further described with reference to the accompanying drawings.

[0018] Figure 1 This is a schematic diagram of a data center power load responsibility distribution system; Figure 2 This is a flowchart of the generation process for power load flexible containers; Figure 3 This is a flowchart of the flexible allocation strategy generation process; Figure 4 This is a flowchart of the dynamic priority sorting process for the flexible allocation strategy; Figure 5 It is a flowchart of parallel processing of flexible execution and conflict resolution. Detailed Implementation

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

[0020] See Figure 1 This invention provides a data center power load elastic allocation system, including an event queue module, a policy generation module, a priority module, a conflict resolution module, and an elastic execution module. The event queue module establishes a spatiotemporally correlated event queue of the current power load topology and generates a power load elastic container mapped to the spatiotemporally correlated event queue. The policy generation module generates elastic allocation policies based on the spatiotemporally correlated event queue and the power load elastic container. These policies include voltage / frequency adjustment policies, server sleep / wake-up policies, and load migration policies. The priority module dynamically prioritizes the elastic allocation policies. The conflict resolution module selects a dominant policy based on the dynamic priority ranking and then resolves conflicts between the dominant policy and other policies. The elastic execution module executes the elastic allocation based on the conflict resolution results.

[0021] In specific implementation, please refer to Figure 2 The system first establishes a spatiotemporal correlation event queue for the current power load topology and generates a power load elastic container. The implementation process is described in detail below: The system collects instantaneous power and rack-end current data for each server rack deployed within the data center. Data collection is performed by power sensors installed on each rack and high-precision current transformers and power sensors installed inside each server processor. The timing of the data collection is determined by a unified time synchronization device, forming a timestamped tuple structure, named an event tuple. An event tuple consists of: rack identifier, instantaneous power value, server identifier, and timestamp. The timestamp is accurate to milliseconds.

[0022] Construct a directed event propagation graph. Each server rack in the data center is considered a node. Directed edges between nodes are determined by the network connections between racks. If a network link exists between rack 1 and rack 2, and data flows from rack 1 to rack 2, a directed edge is created in the event propagation graph from the corresponding node in rack 1 to the corresponding node in rack 2. Each directed edge is assigned a propagation weight, which is set as the proportion of the network link bandwidth between rack 1 and rack 2 to the total network link bandwidth within the data center.

[0023] For each event tuple, calculate its influence distance in the directed event propagation graph. The calculation uses the weighted shortest path length with propagation weights. Using the node corresponding to the rack that generated the event tuple as the source node, execute Dijkstra's algorithm on the directed event propagation graph. The path length is measured as the reciprocal of the sum of the propagation weights of the directed edges along the path. When there is no path from the source node to another node, the influence distance is marked as positive infinity. The influence distance of the event tuple is the minimum of the shortest path lengths from the source node to all reachable nodes after excluding positive infinity. If all reachable nodes are positive infinity, the influence distance is set to a preset constant upper limit, which is twice the total number of racks in the data center.

[0024] Assign an event weight to each event tuple. The event weight is calculated based on the influence distance of the event tuple and the instantaneous power value in the event tuple. The calculation formula is:

[0025] in, Indicates the event weight of the event tuple; This represents the instantaneous power value in the event tuple, in watts. This indicates the influence distance of the event tuple. When the influence distance is a preset constant upper limit value, this upper limit value is used directly. It is a regulating term to avoid a denominator of zero. (Regulating term) The value is 0.01. This value is based on the principle that, in the extreme case where the influence distance may be zero, the denominator will not be zero and the impact on the order of magnitude of the weight calculation result is minimal.

[0026] Each event tuple is stored sequentially into a deque, ordered by event weight from highest to lowest. One end of the deque allows efficient insertion, and the other end allows efficient deletion. The storage method is as follows: starting from the head of the deque, event tuples are pushed into the deque one by one in descending order of event weight. If multiple event tuples with the same weight are encountered, their timestamps are compared, with the earlier timestamp placed at the beginning. The resulting deque is the spatiotemporal relational event queue for the current power load topology.

[0027] After generating the spatiotemporal correlated event queue, the system assigns a flexible adjustment range to each event tuple in the queue. The flexible adjustment range records the adjustable power range and the power range that can be increased or decreased for the corresponding rack during the event duration. The event duration is determined by the event tuple's timestamp plus a fixed observation window length, pre-configured to 30 seconds. The adjustable power range and the power range that can be increased or decreased are obtained by querying the rack power flexibility table. The rack power flexibility table is a two-dimensional power range table generated during system initialization based on the rated power limit, rated maximum current limit, and voltage and frequency adjustment range provided by the server baseboard management controller for each rack. During the query, the rack identifier and current load rate are used as indexes to retrieve the corresponding adjustable power limit and power range, thus forming a flexible adjustment range with a lower limit of the current instantaneous power minus the adjustable power limit and an upper limit of the current instantaneous power plus the power range.

[0028] Each event tuple is encapsulated into a single elastic unit, containing its identifier, event duration, adjustable power range, and adjustable power range. This elastic unit is represented by a data structure with four fields: a string-type event tuple identifier, an event duration field consisting of start and end timestamps, an adjustable power range field storing the lower and upper limits of the adjustable power, and an adjustable power range field storing the lower and upper limits of the adjustable power. All elastic units are grouped into a linear list according to the order of their corresponding event tuples in the spatiotemporal associated event queue. The order of this linear list strictly matches the order of the event tuples in the double-ended queue. This linear list constitutes the power load elastic container.

[0029] A memory mapping table is established for the power load elastic container, mapping event tuple identifiers to elastic units. This memory mapping table is implemented using a hash table, where the key is the event tuple identifier and the value is a pointer to the memory location of the corresponding elastic unit. The construction method is as follows: traverse each elastic unit in the power load elastic container, retrieve the event tuple identifier field of the elastic unit, and insert the event tuple identifier and the memory address of the elastic unit into a key-value pair in the hash table. This completes the entire generation process of the power load elastic container.

[0030] In specific implementation, please refer to Figure 3 The process of generating elastic allocation strategies by the strategy generation module is based on the collaborative implementation of a spatiotemporal correlated event queue and an elastic container for power load.

[0031] The system initiates a traversal operation of the spatiotemporal correlated event queue. The traversal starts from the head of the queue and retrieves each event tuple sequentially. For the currently retrieved event tuple, the event tuple identifier stored within it is read. The event tuple identifier is a unique string assigned to each rack during the initialization of the data center monitoring system, formatted as "Rack_" followed by a four-digit number. Using the event tuple identifier as the lookup key, an exact match search is performed in the memory-mapped table of the power load elastic container. The memory-mapped table is a hash table structure where the key is the event tuple identifier and the value is a pointer to the corresponding elastic unit. The hash function uses the BKDR hash algorithm, and the collision resolution strategy uses chaining. When a key matching the event tuple identifier is found in the memory-mapped table, the corresponding value, i.e., the pointer to the elastic unit, is retrieved, and the entire field content of the elastic unit is accessed through the pointer.

[0032] Read the adjustable power range field and adjustable power range field from the elastic unit. The adjustable power range field contains a lower limit and an upper limit for adjustable power, both in watts. The adjustable power range field contains a lower limit and an upper limit for adjustable power, both also in watts. Obtain the current load rate of the cabinet corresponding to the event tuple. The current load rate is obtained by reading the instantaneous power value of the cabinet, dividing the instantaneous power value by the cabinet's rated power value. The rated power value is the maximum allowable power value marked on the cabinet's nameplate, in watts.

[0033] After obtaining the adjustable power range, adjustable power range, and current load rate, the system determines the candidate action type to be generated. The determination process is based on a load rate-driven action applicability rule set. This rule set is divided based on predefined load rate alarm thresholds: a load rate of 20% or less is defined as a light load state; a load rate greater than 40% but not greater than 47.5% is defined as a heavy load state; and a load rate greater than 47.5% is defined as an overload state. The action applicability rule set includes the following three rules: The first rule is that when the current load rate is in a light load state (i.e., load rate ≤ 20%), it indicates that the rack power utilization is low, with significant room for energy saving and frequency reduction; therefore, voltage and frequency adjustment actions and server sleep / wake-up actions are both included in the candidate action type list. The second rule is that when the current load rate is in a heavy load state (i.e., 40% < load rate ≤ 47.5%), it indicates that the rack load is approaching the warning range, requiring timely power adjustment to prevent further deterioration; therefore, voltage and frequency adjustment actions are included in the candidate action type list. The third rule states that when the current load rate is overloaded (i.e., load rate > 47.5%), it indicates that the server rack is operating under high load, posing a risk of hardware damage or downtime. Load reduction must be implemented immediately, and both voltage / frequency adjustment and load migration actions should be included in the candidate action type list. The aforementioned thresholds for lowering the load rate (20%) and raising the load rate (40% / 47.5%) are based on the typical power efficiency curves of data center servers and overload protection requirements. When the load rate is below 20%, the server's power conversion efficiency is low, making it suitable to save energy through hibernation or frequency reduction. When the load rate exceeds 40%, attention and power adjustments are necessary to mitigate risks. When the load rate exceeds the critical value of 47.5%, the server is approaching its performance bottleneck and is prone to localized hotspots; load migration is suitable to quickly balance heat distribution and prevent overload incidents.

[0034] Based on each action type in the candidate action type list, and combining the adjustable power range and adjustable power range in the elastic unit, specific candidate actions are generated. When the candidate action type list includes voltage and frequency adjustment actions, all available power level values ​​are extracted from the adjustable power range and adjustable power range. The extraction method is as follows: obtain the frequency adjustment step size supported by the target server baseboard management controller. The frequency adjustment step size is typically the power change corresponding to 100MHz. Using the frequency adjustment step size as the interval, generate discrete power target values ​​at equal intervals between the lower and upper limits of the adjustable power range, and convert each power target value into an independent voltage and frequency adjustment action. When the candidate action type list includes server sleep / wake-up actions, if the lower limit of the adjustable power range is less than the server standby power, a sleep action is generated. The sleep action is represented by a Boolean value, with a true value indicating that the server enters the S3 sleep state. If the upper limit of the adjustable power range is greater than the startup power required for server wake-up, a wake-up action is generated. The wake-up action is represented by a Boolean value, with a true value indicating that the server recovers from the S3 sleep state to the normal operating state. When the candidate action type list includes a load migration action, the upper limit of the adjustable power range must be greater than the power increment brought by a standard virtual machine migration operation. The power increment of a standard virtual machine migration operation is the average power increment brought by the most recent 100 migration operations from the historical migration log of the load balancer. When the upper limit of the adjustable power range is greater than the aforementioned average value, a load migration action is generated. The content of the load migration action includes the target server identifier and the number of memory pages of the virtual machine to be migrated.

[0035] All generated voltage / frequency adjustment actions, server sleep / wake-up actions, and load migration actions together constitute the candidate action set of the event tuple. The candidate action set is stored in the form of a set, and each element in the set is a composite data structure containing an action type field and an action parameter field.

[0036] An action is randomly selected from the candidate action set using a uniform random selection strategy. Each action in the candidate action set has an equal probability of being selected, with the probability value being 1 divided by the total number of actions in the candidate action set. A random number generator uses the Mason tween algorithm to generate pseudo-random numbers, with the random number seed being a millisecond-level timestamp of the current system time. The selected action is used as a flexible allocation sub-strategy for event tuples. The data structure of the flexible allocation sub-strategy contains three fields: an event tuple identifier field, an action type field, and an action parameter field. The event tuple identifier is copied to the event tuple identifier field of the flexible allocation sub-strategy. The action type field and action parameter field of the selected action are then copied to the action type field and action parameter field of the flexible allocation sub-strategy, respectively, completing the binding between the flexible allocation sub-strategy and the event tuple identifier.

[0037] The bound elastic allocation sub-policies are stored in a policy table. The policy table is a sequentially stored linear list, implemented using a dynamic array. Each record in the policy table stores all three fields of an elastic allocation sub-policy. Following the original order of the event tuples in the spatiotemporal associated event queue, the corresponding elastic allocation sub-policies are appended sequentially to the end of the policy table.

[0038] After the traversal operation processes all event tuples in the spatiotemporal related event queue, the policy table stores the elastic allocation sub-policy corresponding to each event tuple. The system treats all elastic allocation sub-policies in the policy table as a whole as a policy set, and the elastic allocation policy is obtained by summarizing the policy set. The summarization operation does not change the order of the elastic allocation sub-policies in the policy table, and the final output elastic allocation policy consists of the entire contents of the policy table.

[0039] In specific implementation, please refer to Figure 4 The priority module's process of dynamically prioritizing the elastic allocation strategy encompasses two stages: priority score calculation and strategy reordering.

[0040] The system reads each elastic allocation sub-strategy from the elastic allocation strategy. Elastic allocation strategies are stored in a strategy table, which is a sequential linear list, with each entry storing one elastic allocation sub-strategy. The read operation starts from the first record of the strategy table and traverses each record to the end. For the current elastic allocation sub-strategy encountered, the event weight of the corresponding event tuple is extracted. The event weight is a value calculated and persistently stored for each event tuple when the spatiotemporal associated event queue is generated; its storage location is the event weight field of the event tuple structure in the spatiotemporal associated event queue. The extraction method is as follows: read the event tuple identifier from the event tuple identifier field of the current elastic allocation sub-strategy; use the event tuple identifier as the key to search for the corresponding event tuple in the spatiotemporal associated event queue; and read the value of the event weight field of the event tuple.

[0041] The action type of the current elastic allocation sub-policy is extracted synchronously. The action type is stored in the action type field of the current elastic allocation sub-policy. The action type field takes one of three values: voltage frequency regulation policy, server sleep / wake policy, and load migration policy. The voltage frequency regulation policy is denoted by the enumerated constant `DVFS`, the server sleep / wake policy by the enumerated constant `SLEEP_WAKE`, and the load migration policy by the enumerated constant `MIGRATION`.

[0042] The system maintains a preset urgency mapping table. This urgency mapping table is a static hash table, generated by the configuration file during system compilation and cannot be modified at runtime. The urgency mapping table contains three mapping records: the first record's key is the enumeration constant `DVFS`, and its value is an urgency coefficient of 1.0; the second record's key is the enumeration constant `SLEEP_WAKE`, and its value is an urgency coefficient of 1.8; the third record's key is the enumeration constant `MIGRATION`, and its value is an urgency coefficient of 1.5. The urgency coefficient values ​​are set based on statistical analysis of historical data from data center operations: server hibernation / wake operations involve processor context saving and restoration, have the longest execution latency and the greatest impact on business continuity, therefore, they are assigned the highest urgency coefficient of 1.8; load migration operations involve cross-network copying of virtual machine memory pages, have a moderate execution latency and business impact, therefore, they are assigned the middle value of 1.5; voltage and frequency adjustment operations are processor internal instruction-level adjustments, have the shortest execution latency and no impact on running services, therefore, they are assigned the base value of 1.0. Based on the action type of the current elastic allocation sub-strategy, query the urgency mapping table to obtain the urgency coefficient that matches the action type.

[0043] Calculate the original priority score for the current elastic allocation sub-strategy. The original priority score is derived by multiplying the event weight by the urgency coefficient. The specific value of the product is denoted as the original priority score, which is a double-precision floating-point number.

[0044] The original priority score is attenuated. This attenuation is based on the cabinet's hierarchy depth within the network topology corresponding to the current elastic allocation sub-policy. The cabinet's hierarchy depth is defined as follows: taking the core layer switch of the data center as the root node (depth 0), the hierarchy depth of the access layer switch connected to the cabinet is its hierarchy number within the topology. The hierarchy depth is obtained as follows: read the event tuple identifier of the current elastic allocation sub-policy and parse out the cabinet identifier; using the cabinet identifier as the query condition, retrieve the access layer switch identifier corresponding to the cabinet identifier from the data center network topology configuration database; then, trace back up the network topology tree from the access layer switch identifier to the core layer switch; the number of switch levels traversed during this backtracking process is the hierarchy depth value.

[0045] The calculation formula used for attenuation processing is:

[0046] in: Indicates the final priority score; Represents the original priority score; The base of the natural logarithm is 2.71828. This represents the attenuation factor, a preset constant with a value range of real numbers greater than 0. It is set to 0.15. The basis for this setting is to ensure that the priority score decreases by about 14% for each additional topology level, so that the rack strategy near the core layer receives appropriate weight in priority ranking without completely blocking the strategy of edge layer racks. This represents the cabinet's hierarchy depth in the network topology, with values ​​ranging from positive integers starting from 1, and the maximum value being the maximum number of hierarchy levels in the data center network topology. The final priority score for each elastic allocation sub-policy is calculated sequentially and temporarily stored in an auxiliary data structure corresponding to the current elastic allocation sub-policy. This auxiliary data structure also stores an index pointing to the current elastic allocation sub-policy's position in the policy table.

[0047] All flexible allocation sub-policies are rearranged according to their final priority scores, from highest to lowest. The rearrangement uses a stable sorting algorithm based on merge sort, with the final priority score stored in an auxiliary data structure as the key, and the sorting direction is descending. If two flexible allocation sub-policies have strictly equal final priority scores, the timestamps of the event tuples corresponding to the two policies are compared; the flexible allocation sub-policy corresponding to the event tuple with the earlier timestamp is placed first. After rearrangement, a new sequential linear list is generated, and the order of the flexible allocation sub-policies in the new sequential linear list is the sorted order. This new sequential linear list constitutes the sorted flexible allocation policies. The sorted flexible allocation policies are then passed as the output of the priority module to the conflict resolution module.

[0048] In practice, the conflict resolution module receives the sorted flexible allocation strategy and completes the entire resolution process through an iterative process of selecting the dominant strategy and handling conflicts.

[0049] The system selects the top-ranked elastic allocation sub-strategy from the sorted elastic allocation strategies as the dominant strategy. The sorted elastic allocation strategies are a sequential linear list, with indices starting from zero and increasing sequentially. The position with index zero stores the top-ranked elastic allocation sub-strategy. The system reads the rack identifier and power adjustment amount from the dominant strategy. The rack identifier is stored in the event tuple bound to the dominant strategy. The reading path is: obtain the event tuple identifier from the event tuple identifier field of the dominant strategy; use the event tuple identifier as the key to find the corresponding event tuple in the spatiotemporal associated event queue; and extract the rack identifier from the rack identifier field of the event tuple. The power adjustment amount is stored in the action parameter field of the dominant strategy. The action parameter field is a signed integer; a positive value represents the number of watts of power increase, and a negative value represents the number of watts of power decrease.

[0050] Starting from index 1 in the sorted elastic allocation strategies, traverse each remaining elastic allocation sub-strategy sequentially until the end of the linear list. For each elastic allocation sub-strategy, extract its rack identifier, following the same extraction path as the dominant strategy's rack identifier extraction. Perform a string equality comparison between the extracted rack identifier and the dominant strategy's rack identifier. If every character of the two rack identifier strings is identical, a rack identifier conflict is determined between the elastic allocation sub-strategy and the dominant strategy.

[0051] For any elastic allocation sub-strategy identified as having a rack identifier conflict, a superimposed conflict determination is performed. The power adjustment amount of this elastic allocation sub-strategy is read from the action parameter field and arithmetically summed with the power adjustment amount of the dominant strategy. The result of the arithmetic sum is recorded as the superimposed power adjustment amount. The power adjustment upper limit for the rack corresponding to this rack identifier is obtained. The power adjustment upper limit is the upper limit of the adjustable power range of the rack within the elastic unit of the power load elastic container, in watts. The superimposed power adjustment amount is compared with the power adjustment upper limit. If the superimposed power adjustment amount is greater than the power adjustment upper limit, a superimposed conflict is determined to have occurred, triggering the conflict resolution process.

[0052] The first step in the conflict resolution process is to offset the execution timestamp of the elastic allocation sub-policy that triggered the conflict to after the dominant policy has been completed. The expected execution duration of the dominant policy is obtained; this value is determined based on the action type of the dominant policy. When the dominant policy's action type is a voltage / frequency regulation policy, the expected execution duration is 200 milliseconds; when it's a server sleep / wake-up policy, the expected execution duration is 5000 milliseconds; and when it's a load migration policy, the expected execution duration is 30000 milliseconds. These expected execution duration values ​​are based on the maximum response time for voltage / frequency regulation, the maximum completion time for sleep / wake-up, and the maximum duration for virtual machine memory page migration across the network, extracted from the operation manuals of various server types within the data center. The original timestamp of the elastic allocation sub-policy that triggered the conflict is read from the timestamp field of the corresponding event tuple. The original timestamp is added to the expected execution duration of the dominant policy; the result is recorded as the offset timestamp.

[0053] The second step in the conflict resolution process is to recalculate the priority of the elastic allocation sub-strategy after the offset. This calculation introduces a delay penalty coefficient. The delay penalty coefficient is determined based on the difference between the offset timestamp and the current time, expressed in milliseconds. The formula for calculating the delay penalty coefficient is:

[0054] in: This represents the delay penalty coefficient. The range of values ​​for is a real number greater than 0 and less than or equal to 1; Represented by natural constant The natural logarithm function with base 0; This represents the difference between the offset timestamp and the current time, in seconds. The value is a real number greater than or equal to 0. The calculated delay penalty coefficient is multiplied by the original priority score of the elastic allocation sub-policy. The original priority score is the value calculated by the priority module and persistently stored in the elastic allocation sub-policy. The product is recorded as the adjusted priority score.

[0055] The elastic allocation sub-policies that have completed offset timestamp updates and priority score calculations are placed into a remaining queue. The remaining queue is initially empty and implemented using a doubly linked list structure. After all remaining elastic allocation sub-policies in the sorted elastic allocation policies have been traversed and conflict resolution completed, all elastic allocation sub-policies in the remaining queue are sorted once according to their adjusted priority scores from highest to lowest. The sorting algorithm uses stable merge sort, and the sorting direction is descending. If two elastic allocation sub-policies have strictly equal adjusted priority scores, the one with the earlier offset timestamp is placed in the earlier position.

[0056] The top-ranked elastic allocation sub-policy in the remaining queue is updated as the new dominant policy. The remaining queue is cleared, and the process returns to the traversal and conflict determination steps following the selection of the dominant policy. The same conflict resolution process is repeated for the updated set of remaining elastic allocation sub-policies. The conflict resolution process terminates when, in a given iteration, after traversing all remaining elastic allocation sub-policies, no superimposed conflict determination is triggered, or the number of remaining elastic allocation sub-policies is zero. At this point, the execution timestamps and priorities of all elastic allocation sub-policies have been adjusted, forming the final policy queue after conflict resolution.

[0057] In specific implementation, please refer to Figure 5 The elastic execution module reads the final policy queue generated after conflict resolution and distributes the elastic allocation sub-policies in the final policy queue to each execution unit in the data center in timestamp order to complete the elastic allocation.

[0058] The system obtains the final policy queue from the output interface of the conflict resolution module. The final policy queue is a sequentially stored linear list. Each entry in the list contains three fields: a flexible allocation sub-policy, an adjusted execution timestamp, and an adjusted power adjustment amount. The flexible allocation sub-policy field contains an event tuple identifier sub-field, an action type sub-field, and an action parameter sub-field. The adjusted execution timestamp is the offset timestamp written after the conflict resolution process is completed, recording the earliest time the flexible allocation sub-policy is allowed to begin execution. The adjusted power adjustment amount is the power adjustment value after reduction processing during the conflict resolution process.

[0059] The final policy queue is sorted once according to the adjusted execution timestamps in ascending order. The sorting algorithm is a timestamp-first stable sort, with the adjusted execution timestamp as the sorting key and the sorting direction in ascending order. If two entries have the same adjusted execution timestamp value, their original relative order at the time of conflict resolution is maintained. After sorting, the system starts from the position with index zero and retrieves one entry at a time, parsing the action type of the flexible allocation sub-policy in each entry.

[0060] When the action type of the elastic allocation sub-strategy is voltage-frequency adjustment, the system reads the adjusted power adjustment amount from the action parameter field of the elastic allocation sub-strategy and converts the adjusted power adjustment amount into the target value for voltage-frequency adjustment. The conversion process queries the frequency-power mapping table stored in the target server's baseboard management controller. The frequency-power mapping table records the mapping relationship between each frequency level supported by the target server's processor and the corresponding processor power consumption. The lookup method is as follows: find the processor power consumption value in the frequency-power mapping table that is closest to the absolute value of the adjusted power adjustment amount, and retrieve the frequency level corresponding to that processor power consumption value. The frequency level and the sign of the adjusted power adjustment amount are combined to form a dynamic voltage-frequency adjustment command. The format of the dynamic voltage-frequency adjustment command conforms to the intelligent platform management interface specification supported by the baseboard management controller. The opcode field of the command is set to 0x2E, and the data field contains the frequency level code and the voltage adjustment step number. The path to determine the target server is as follows: Parse the rack identifier from the event tuple identifier field of the current entry's elastic allocation sub-policy; query the rack-server mapping table using the rack identifier as the key to obtain the list of server identifiers corresponding to the rack identifier; select the server with the highest current load rate from the server identifier list as the target server. Send the dynamic voltage and frequency adjustment command via the local area network to port 623 of the target server's baseboard management controller IP address.

[0061] When the action type of the elastic allocation sub-policy is a server hibernation / wake-up policy, the system reads the hibernation / wake-up flag from the action parameter field of the elastic allocation sub-policy. The hibernation / wake-up flag is a Boolean value; a true value represents a hibernation command, and a false value represents a wake-up command. The path to the target server is determined to be consistent with the path determined in the voltage and frequency regulation policy. When the hibernation / wake-up flag is true, the system constructs a hibernation command. The format of the hibernation command follows the Advanced Configuration and Power Management Interface (AMAC) specification, and the command opcode is set to the encoding value 0x05 corresponding to the S3 hibernation state. The hibernation command is sent via the local area network (LAN) to port 664 of the IP address of the target server's power management unit. When the hibernation / wake-up flag is false, the system constructs a wake-up command. The wake-up command uses the LAN wake-up packet format. The target media access control (MAC) address of the LAN wake-up packet is the MAC address of the target server's network card, and the data payload contains a 6-byte 0xFF prefix and the MAC address repeated 16 times. The LAN wake-up packet is broadcast via the LAN to all ports of the virtual LAN where the target server resides.

[0062] When the action type of the elastic allocation sub-policy is load migration, the system reads the source server identifier, target server identifier, and migration data volume from the action parameter field of the elastic allocation sub-policy. The migration data volume is measured in memory pages, with each memory page being 4KB in size. The system constructs a virtual machine migration command. The format of the virtual machine migration command conforms to the Hypertext Transfer Protocol Application Programming Interface (HTTP) specification supported by the load balancer. The request method of the interface is POST, and the request Uniform Resource Locator (URL) is "http: / / [load balancer IP address]:8080 / v1 / migration". The request body is encoded in JSON format and contains three key-value pairs: the "source_host" key corresponds to the source server identifier string, the "target_host" key corresponds to the target server identifier string, and the "page_count" key corresponds to the migration data volume value. The virtual machine migration command is sent via the local area network to port 8080 of the load balancer's IP address.

[0063] While the elastic execution module executes the above distribution process, the conflict resolution module simultaneously executes the dominant strategy selection process. The conflict resolution module selects the first elastic allocation sub-strategy from the sorted elastic allocation strategies as the candidate dominant strategy. It then reads the rack identifier and power adjustment amount of the candidate dominant strategy. The rack identifier is read by retrieving the event tuple identifier from the event tuple identifier field of the candidate dominant strategy, using the event tuple identifier as the key to find the corresponding event tuple in the spatiotemporal associated event queue, and then reading the rack identifier field of the event tuple. The power adjustment amount is read directly from the action parameter field of the candidate dominant strategy.

[0064] The conflict resolution module iterates through all elastic allocation sub-strategies in the sorted elastic allocation strategies, excluding the candidate dominant strategy. For each elastic allocation sub-strategy encountered, its rack identifier is extracted, following the same extraction path as the rack identifier extraction for the candidate dominant strategy. A string equality comparison is performed between the rack identifier of the encountered elastic allocation sub-strategy and the rack identifier of the candidate dominant strategy. If every character of the two rack identifier strings is identical, the encountered elastic allocation sub-strategy is determined to share the same rack identifier as the candidate dominant strategy. The power adjustment amount of all elastic allocation sub-strategies sharing the same rack identifier with the candidate dominant strategy is accumulated. The accumulation method is as follows: an initial cumulative adjustment amount variable is set to zero; for each elastic allocation sub-strategy sharing the same rack identifier, its power adjustment amount is added to the cumulative adjustment amount variable. After iterating through all elastic allocation sub-strategies sharing the same rack identifier, the cumulative adjustment amount is obtained.

[0065] The cumulative adjustment amount is arithmetically summed with the power adjustment amount of the candidate dominant strategy, and the sum is recorded as the total. The power adjustment limit of the cabinet corresponding to the cabinet identifier of the candidate dominant strategy is obtained. The power adjustment limit is the upper limit of the adjustable power range of the elastic unit corresponding to that cabinet identifier in the power load elastic container, in watts. The total is compared with the power adjustment limit. If the total does not exceed the power adjustment limit, the candidate dominant strategy is officially selected as the dominant strategy. If the total exceeds the power adjustment limit, the candidate dominant strategy is skipped, and the next elastic allocation sub-strategy in the sorted elastic allocation strategies is selected as the new candidate dominant strategy. The above reading, traversal, accumulation, and comparison steps are repeated until a candidate dominant strategy that satisfies the condition that the total does not exceed the power adjustment limit is selected as the dominant strategy.

[0066] Once the dominant strategy is selected, the conflict resolution module performs conflict resolution between the dominant strategy and other strategies. The power adjustment amount of the dominant strategy is locked as an immutable value. The locking method is as follows: a read-only flag is written to the metadata of the dominant strategy. The read-only flag occupies one byte, and a byte value of 0xFF indicates a locked state. All subsequent operations involving modifying the power adjustment amount of the dominant strategy will be intercepted.

[0067] The conflict resolution module iterates through other elastic allocation sub-strategies that do not conflict with the dominant strategy regarding rack identifiers. The criterion for determining that there is no rack identifier conflict is: extract the rack identifier of the traversed elastic allocation sub-strategy, perform a string equality comparison with the rack identifier of the dominant strategy, and if the comparison result is not equal, it is determined that there is no rack identifier conflict.

[0068] For each elastic allocation sub-policy that does not conflict with the rack identifier, check whether the execution action of the traversed elastic allocation sub-policy will cause the total power or total current of the rack corresponding to the dominant policy to exceed the physical limit. The checking method is as follows: read the action parameter field of the traversed elastic allocation sub-policy and determine whether the action parameter field contains parameters that may affect the total power or total current of the rack (such as voltage frequency adjustment amplitude, sleep / wake-up state changes, load migration data volume, etc.). When the action parameter field contains the central sensor identifier string, it is determined that the execution action of the traversed elastic allocation sub-policy involves the central sensor. When the execution action of the traversed elastic allocation sub-policy involves the same rack power supply circuit, construct rack electrical safety constraints. The constraints are based on the rack's current and power capacity limits. The specific determination formula is:

[0069] in: and These represent the current real-time total power and total current of the server rack, respectively. and These represent the rated maximum power and maximum current of the server rack, respectively. and These represent the power and current changes caused by the sub-policy to be executed, respectively. The coupling constraint limits the upper limit of the changes in the relevant monitoring indicators after the execution of the traversed elastic allocation sub-policy. The upper limit of the change is set to a preset safety range. The basis for setting this is to prevent the state of the core components inside the server from exceeding the safety protection threshold. The safety protection threshold is usually set within a critical range. During normal operation, the state of the components is generally maintained in a stable range. This upper limit of the change can ensure that the state of the components will not touch the safety protection threshold.

[0070] The power adjustment amount of the traversed elastic allocation sub-strategy is reduced based on coupling constraints. The reduction method is to directly verify whether the adjusted power adjustment amount exceeds the rated maximum power of the rack. or rated maximum current Compare the adjusted power level with the remaining adjustable power margin of the rack.

[0071] in This represents the current real-time total power of the server rack. When the absolute value of the adjusted power adjustment is greater than the remaining adjustable power margin, the absolute value of the adjusted power adjustment is replaced with the remaining adjustable power margin, while retaining the original sign of the adjusted power adjustment. Let the adjusted power adjustment be... The execution parameters after coupling decoupling are ,but

[0072] The reduced values ​​generate the decoupled execution parameters. The decoupled execution parameters are then written back to the action parameter field of the traversed elastic allocation sub-strategy, overwriting the original power adjustment value in the action parameter field.

[0073] The foregoing has provided a detailed description of one embodiment of the present invention, but this description is merely a preferred embodiment and should not be construed as limiting the scope of the invention. All equivalent variations and modifications made within the scope of the claims of this invention should still fall within the patent coverage of this invention.

Claims

1. A flexible power load distribution system for a data center, characterized in that, The system includes: The event queue module is used to establish a spatiotemporal associated event queue of the current power load topology and generate a power load elastic container mapped to the spatiotemporal associated event queue. The strategy generation module is used to generate an elastic allocation strategy based on the spatiotemporal related event queue and the power load elastic container. The elastic allocation strategy includes a voltage frequency adjustment strategy, a server hibernation and wake-up strategy, and a load migration strategy. The priority module is used to dynamically prioritize the elastic allocation strategy. The conflict resolution module is used to select a dominant strategy based on the dynamic priority ranking result and then resolve the conflict between the dominant strategy and other strategies. The elastic execution module is used to perform elastic allocation based on the conflict resolution results; An elastic allocation strategy is generated based on the spatiotemporal correlated event queue and the power load elastic container, specifically as follows: Traverse each event tuple in the spatiotemporal related event queue, read the identifier of the event tuple, and find the corresponding elastic unit through the memory mapping table of the power load elastic container; Based on the adjustable power range and adjustable power range in the elastic unit, and combined with the current load rate of the cabinet corresponding to the event tuple, a candidate action set for the event tuple is generated. The candidate action set includes at least one of voltage frequency adjustment action, server hibernation wake-up action, and load migration action. Randomly select an action from the candidate action set as the elastic allocation sub-strategy for the event tuple, bind the elastic allocation sub-strategy to the identifier of the event tuple and store it in the strategy table. After traversal, summarize all the bound elastic allocation sub-strategies in the strategy table into the elastic allocation strategy.

2. The data center power load flexible distribution system according to claim 1, characterized in that, The specific method for establishing the spatiotemporal correlation event queue of the current power load topology is as follows: Collect the instantaneous power and current at the end of each rack, and generate event tuples with timestamps; Construct an event propagation directed graph based on the network connection relationships between server racks, and calculate the influence distance of each event tuple in the event propagation directed graph; Assign event weights to each event tuple based on the values ​​of the influence distance and the instantaneous power; The corresponding event tuples are stored in a double-ended queue in descending order of event weight to form the spatiotemporal correlation event queue of the current power load topology.

3. A data center power load flexible distribution system according to claim 2, characterized in that, The specific method for generating the power load elastic container mapped to the spatiotemporally related event queue is as follows: Each event tuple in the spatiotemporal correlated event queue is assigned a flexible adjustment range, which records the adjustable power range and adjustable power range of the cabinet corresponding to the event tuple during the event duration. Encapsulate the identifier of each event tuple, the duration of the event, the adjustable power range, and the adjustable power range into a single elastic unit; All elastic units are combined into the power load elastic container according to the order of the corresponding event tuples in the spatiotemporal associated event queue, and a memory mapping table from event tuple identifiers to elastic units is established for the power load elastic container.

4. A data center power load flexible distribution system according to claim 2, characterized in that, The elastic allocation strategy is dynamically prioritized, specifically as follows: Read each elastic allocation sub-strategy in the elastic allocation strategy, and extract the event weight and action type of the event tuple corresponding to the elastic allocation sub-strategy; The urgency coefficient of the elastic allocation sub-strategy is obtained by querying a preset urgency mapping table based on the action type. The product of the event weight and the urgency coefficient is used as the original priority score of the elastic allocation sub-strategy. The original priority score is then attenuated according to the hierarchical depth of the cabinet corresponding to the elastic allocation sub-strategy in the network topology to obtain the final priority score. All elastic allocation sub-strategies in the elastic allocation strategy are rearranged according to the final priority score from high to low to generate a sorted elastic allocation strategy.

5. A data center power load flexible distribution system according to claim 1, characterized in that, After selecting the dominant strategy based on the dynamic priority ranking result, the conflict resolution between the dominant strategy and other strategies is performed, specifically as follows: Select the first-ranked elastic allocation sub-strategy among the sorted elastic allocation strategies as the dominant strategy, and read the rack identifier and power adjustment amount of the dominant strategy; Iterate through each remaining elastic allocation sub-strategy in the sorted elastic allocation strategy, and check whether the rack identifier of the elastic allocation sub-strategy is the same as the rack identifier of the dominant strategy. If they are the same, perform a conflict determination by superimposing the power adjustment amount of the elastic allocation sub-strategy with the power adjustment amount of the dominant strategy. When the combined power adjustment exceeds the power adjustment limit of the rack, conflict resolution is triggered. The execution timestamp of each remaining elastic allocation sub-strategy is shifted to after the execution of the dominant strategy, and the priority of the shifted elastic allocation sub-strategy is recalculated.

6. A data center power load flexible distribution system according to claim 5, characterized in that, The conflict resolution process involves shifting the execution timestamps of the remaining elastic allocation sub-policies to after the dominant policy has been executed, and recalculating the priority of the shifted elastic allocation sub-policies. Specifically, this is done as follows: Obtain the expected execution duration of the dominant strategy, and add the expected execution duration to the original timestamps of the remaining elastic allocation sub-strategies to obtain the offset timestamps; The delay penalty coefficient is calculated based on the difference between the offset timestamp and the current time. The delay penalty coefficient is then multiplied by the original priority score of the remaining elastic allocation sub-strategy to obtain the adjusted priority score. The remaining flexible allocation sub-policies are reordered in the remaining queue according to the adjusted priority scores, and the policy ranked first after reordering is updated as the new dominant policy. The conflict resolution step is then performed until all conflicts of the flexible allocation sub-policies are resolved.

7. A data center power load flexible distribution system according to claim 1, characterized in that, The specific method for performing flexible allocation based on the conflict resolution result is as follows: Read the final policy queue generated after conflict resolution. Each entry in the final policy queue contains an elastic allocation sub-policy, its adjusted execution timestamp, and its adjusted power adjustment amount. According to the order of the execution timestamps, the corresponding elastic allocation sub-policies are retrieved sequentially, and the action type of the elastic allocation sub-policy is parsed. When the action type is a voltage and frequency adjustment strategy, a dynamic voltage and frequency adjustment command is sent to the baseboard management controller of the target server, and the command parameters include the adjusted power adjustment amount; When the action type is a server sleep / wake-up policy, a sleep command or wake-up command is sent to the power management unit of the target server; When the action type is a load migration policy, a virtual machine migration instruction is sent to the load balancer. The virtual machine migration instruction contains the source server identifier, the target server identifier, and the amount of migration data.

8. A data center power load flexible distribution system according to claim 1, characterized in that, The method for selecting the dominant strategy based on the dynamic priority ranking result is as follows: The first elastic allocation sub-strategy in the sorted elastic allocation strategies is taken as the candidate dominant strategy, and the rack identifier and power adjustment amount of the candidate dominant strategy are read. Traverse all elastic allocation sub-strategies in the sorted elastic allocation strategy except for the candidate dominant strategy, accumulate the power adjustment amount of all elastic allocation sub-strategies that share the same rack identifier with the candidate dominant strategy, and obtain the cumulative adjustment amount; When the sum of the cumulative adjustment amount and the power adjustment amount of the candidate dominant strategy does not exceed the power adjustment limit of the cabinet, the candidate dominant strategy is officially selected as the dominant strategy. When the sum exceeds the power adjustment limit of the cabinet, the candidate dominant strategy is skipped, and the next elastic allocation sub-strategy in the sorted elastic allocation strategy is taken as the new candidate dominant strategy, and the selected steps are repeated.

9. A data center power load flexible distribution system according to claim 1, characterized in that, The conflict resolution between the dominant strategy and other strategies is carried out in the following manner: The power adjustment amount of the dominant strategy is locked as an unchangeable amount, and other flexible allocation sub-strategies that do not conflict with the rack identifier of the dominant strategy are traversed in turn. For each other elastic allocation sub-policy encountered, check whether the execution of the elastic allocation sub-policy will cause the total power or total current of the cabinet corresponding to the dominant policy to exceed the physical limit; When the execution of this flexible allocation sub-strategy involves core monitoring components, a coupling constraint condition between power and operating status is constructed, which limits the maximum allowable power and maximum allowable current of the cabinet. The power adjustment amount of the elastic allocation sub-strategy is reduced according to the coupling constraint condition, the execution parameters after coupling is resolved are generated, and the execution parameters after coupling is resolved are written back to the elastic allocation sub-strategy.

Images