Server position distribution method, electronic equipment and storage medium

Abstract

The invention provides a server position distribution method, electronic equipment and a storage medium, and relates to the technical field of server position distribution, and the method comprises the steps: for any to-be-distributed server QW, determining a CPU utilization rate corresponding to each preset moment in an operation cycle of the QW; determining server power corresponding to each preset moment in the operation cycle of the QW; determining a CPU temperature determination model corresponding to the QW at each preset moment; determining a model according to the server power corresponding to each preset moment of the QW in the operation cycle and the CPU temperature, and determining the CPU temperature corresponding to each preset moment of the QW in the operation cycle; according to the server power and the CPU temperature of each to-be-allocated server at the same preset moment, allocating each to-be-allocated server to a corresponding cabinet; according to the invention, cabinet resource waste and energy redundancy are avoided, risks of local overheating and the like can be avoided, and the space and heat dissipation resources of the cabinet are utilized to the maximum extent.

Description

Technical Field

[0001] This invention relates to the field of server location allocation technology, and in particular to a server location allocation method, electronic device, and storage medium. Background Technology

[0002] In the design process of data center server rooms, rack planning and single-rack server placement are key aspects affecting resource utilization efficiency and operation and maintenance costs. Currently, data center designers generally face significant limitations of existing technologies when making related plans: on the one hand, traditional server power models fail to fully consider the differences in power characteristics under different server operating modes, nor do they incorporate the impact of intake air temperature on server power, resulting in insufficient accuracy in power prediction; on the other hand, the theoretical power of servers based on the design phase deviates significantly from the actual power after operation, lacking a systematic measurement and prediction process. This not only wastes rack space and energy resources but also increases the subsequent operation and maintenance burden of the data center, making it difficult to achieve the goals of minimizing server energy consumption and optimizing rack resource allocation. Therefore, how to combine the relationship between CPU utilization, CPU temperature, and server power during the design phase to achieve a reasonable allocation of server positions within the rack has become an urgent technical problem to be solved. Summary of the Invention

[0003] To address the aforementioned technical problems, the technical solution adopted by this invention is as follows: According to a first aspect of this application, a server location allocation method is provided, the method comprising the following steps: S100, for any server QW to be allocated, determine the CPU utilization of QW at each preset moment in the running cycle based on the workload type of QW and the CPU periodic change curve corresponding to QW. S200 determines the server power corresponding to each preset moment in the operation cycle of QW based on the data center intake air temperature, the CPU utilization rate corresponding to each preset moment in the operation cycle of QW, and the preset server power determination model; the server power determination model is determined based on the data center intake air temperature and the operation mode corresponding to each preset moment in QW. S300, based on the server power and server operating mode of QW at each preset moment in the operating cycle, determines the CPU temperature determination model of QW at each preset moment. S400 determines the CPU temperature of QW at each preset moment in its operating cycle based on the server power and CPU temperature at each preset moment in the QW's operating cycle. S500 allocates each server to a corresponding rack based on the server power and CPU temperature of each server to be allocated at the same preset time. The total server power of all servers to be allocated in each rack at any preset time is less than a preset total server power threshold, and the total CPU temperature is less than a preset total CPU temperature threshold.

[0004] According to another aspect of this application, a non-transitory computer-readable storage medium is also provided, wherein at least one instruction or at least one program is stored in the storage medium, and the at least one instruction or at least one program is loaded and executed by a processor to implement the above-described server location allocation method.

[0005] According to another aspect of this application, an electronic device is also provided, including a processor and the aforementioned non-transitory computer-readable storage medium.

[0006] The present invention has at least the following beneficial effects: The server location allocation method of this invention accurately predicts CPU utilization at preset times within the operating cycle by precisely associating server workload type with CPU periodic variation characteristics. Combined with the dual key factors of data center intake air temperature and server operating mode, it constructs a power and CPU temperature calculation logic that fits the actual operating scenario, ensuring that the calculated server power and CPU temperature results are more consistent with the real operating state. This effectively solves the problem of large deviations between theoretical and actual operating data in traditional allocation methods. Furthermore, by using server power and CPU temperature at the same preset time as the core allocation basis and strictly adhering to dual threshold constraints of total rack power and total CPU temperature, it avoids rack resource waste and energy redundancy, and mitigates risks such as localized overheating through scientific allocation. This maximizes the utilization of rack space and heat dissipation resources, significantly reduces data center construction and operation costs, reduces subsequent maintenance and adjustment workload, and improves the overall stability and energy efficiency of the data center. Attached Figure Description

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

[0008] Figure 1 A flowchart of a server location allocation method provided in an embodiment of the present invention. Detailed Implementation

[0009] 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.

[0010] It should be noted that, based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Furthermore, this device and / or practice the method can be implemented using other structures and / or functionalities besides one or more of the aspects set forth herein.

[0011] The following will refer to Figure 1 The flowchart shown illustrates a server location allocation method, introducing one such method.

[0012] The server location allocation method may include the following steps: S100: For any server QW to be assigned, determine the CPU utilization rate of QW at each preset moment within the operating cycle based on the workload type of QW and the corresponding CPU periodic change curve of QW.

[0013] In this embodiment, the power consumption of each component of the server constitutes the overall power consumption of the server. Among them, the sum of CPU power consumption, memory power consumption, and disk I / O power consumption can account for more than 90% of the server's dynamic power consumption. The power consumption of each component of the server is not a simple linear relationship; there is a certain coupling between the resource utilization of each component. When the server runs computationally intensive tasks, the CPU's memory resources will increase with the increase of CPU utilization. When the server runs data-intensive tasks, the disk I / O rate has a significant impact on the overall power consumption. There is a coupling between I / O rate and memory utilization. When the I / O rate increases, the memory space occupied will increase, leading to an increase in memory power consumption. It can be seen that there is a certain coupling relationship between CPU utilization, memory utilization, and I / O rate. Therefore, CPU utilization is considered as the main factor affecting server power consumption.

[0014] Different workloads will result in different dynamic change characteristics. According to the purpose of the server, the workload type of the server QW to be assigned can be divided into intensive computing, database, and storage. The CPU periodic change curve corresponding to QW is based on the historical monitoring data of the data center or the load pattern of similar servers. The period is fixed at 24 hours. The preset time can be divided into 1 hour / time, for a total of 24 time times; or it can be divided in other ways, such as 0.5 hours / time.

[0015] The periodic characteristics of CPU utilization vary across different workload types: For example, intensive computing servers (such as scientific research servers) have high utilization during the day (09:00-18:00), peaking at 80%-100%, while utilization drops to 10%-20% at night (00:00-06:00); database servers (such as e-commerce transaction database servers) have utilization of 60%-90% during high-concurrency periods during the day (10:00-17:00), while utilization is 30%-50% during batch processing periods at night (23:00-02:00); and storage servers (such as file storage servers) have stable utilization throughout the day, fluctuating between 20%-40%.

[0016] Based on the matched periodic curve, extract the utilization value for each preset time. Example: QW is a computing-intensive server. Its CPU periodic curve shows a utilization rate of 70% at 09:00, 90% at 14:00 (peak), and 15% at 03:00. Then, directly determine the CPU utilization rates for these three times as 70%, 90%, and 15%, respectively. Extract the remaining times according to the curve pattern.

[0017] This step achieves accurate prediction of CPU utilization by binding workload type with 24-hour periodic characteristics, avoiding the utilization estimation deviation caused by traditional methods that "rely solely on theoretical averages." Its core value lies in providing basic data that fits the actual operating scenario for subsequent power and temperature calculations—if the utilization prediction deviation is large, all subsequent quantitative calculations will be distorted. This step, through the dual constraints of "load type + historical curves," ensures the reliability of utilization data at every moment, laying the foundation for the scientific nature of the entire allocation method. At the same time, it eliminates the need for additional real-time monitoring equipment, reducing data collection costs.

[0018] S200 determines the server power corresponding to each preset moment in the operation cycle of QW based on the data center intake air temperature, the CPU utilization rate corresponding to each preset moment in the operation cycle of QW, and the preset server power determination model; the server power determination model is determined based on the data center intake air temperature and the operation mode corresponding to each preset moment of QW.

[0019] Furthermore, step S200 includes the following steps: S210, Obtain the server power determination model P=x×u 2 +×y×u+z; where P is the server power, u is the CPU utilization, and x, y and z are the first fitting coefficient, the second fitting coefficient and the third fitting coefficient, respectively; x, y and z are obtained according to the data center air intake temperature and the preset fitting coefficient mapping table YR; YR includes several rows, each row including a set of operating modes and data center air intake temperature combinations as well as the specific values ​​of x, y and z.

[0020] In this embodiment, based on the analysis and statistics of a large amount of server operation data, it can be seen that there is a quadratic function relationship between server power and CPU utilization, in the form of P=x×u. 2 +×y×u+z; Dependent variable P: Real-time power of the server to be calculated (unit: W); Independent variable u: CPU utilization rate of S100 (range 0-1, such as u=0.9 for 90% utilization rate); Coefficients x (first fitting coefficient), y (second fitting coefficient), z (third fitting coefficient): Fixed values ​​to be obtained through dual-condition matching.

[0021] The YR table is a structured data table. Its core is that the unique combination of "operating mode + computer room air intake temperature" corresponds to a set of x / y / z coefficients. An example of the table structure is shown in Table 1. Table 1 Based on the above fitting coefficient mapping table YR, the specific values ​​corresponding to x / y / z are determined according to the current preset operating mode of the server QW to be assigned and the preset air intake temperature during the data center design phase.

[0022] Example: If the air intake temperature of the computer room is 25℃, and QW is in performance mode at 14:00, then match the corresponding row from the YR table and extract the coefficients x=-267.34, y=474.81, and z=115.62.

[0023] YR can be obtained through the following method: Multiple test scenarios were divided according to server operating mode and data center intake air temperature, covering all core scenarios adapted to the technical solution. In each scenario, CPU utilization was controlled as the sole variable (gradually ranging from 0% to 100%), and the actual operating power of the corresponding server was collected to form multiple sets of "CPU utilization u - actual power P" sample data. For the uP samples of each scenario, nonlinear fitting algorithms such as least squares were used to substitute them into the quadratic function model P=xu 2+yu+z, solve for x (first fitting coefficient), y (second fitting coefficient), and z (third fitting coefficient) that minimize the error between the fitted value and the measured value; summarize the x / y / z coefficients corresponding to each combination of "operating mode + inlet air temperature", organize them into a standardized fitting coefficient mapping table YR according to the row and column structure of "operating mode - inlet air temperature - xyz".

[0024] This step, through the design of a "fixed quadratic function model + structured coefficient mapping table," solves the problems of "parameter chaos and poor adaptability" in traditional power models. On the one hand, the fixed model form simplifies the calculation logic, eliminating the need to re-derive model formulas for different servers and lowering the barrier to entry. On the other hand, the YR table uses "operating mode + inlet air temperature" as a dual index to ensure the uniqueness and accuracy of coefficient matching—the operating mode determines the server's energy-saving strategy, and the inlet air temperature affects heat dissipation efficiency. The combination of these two factors makes the coefficients more closely reflect the actual scenario, avoiding coefficient deviations caused by matching under a single condition, and providing a core guarantee for the accuracy of subsequent power calculations. At the same time, the YR table can directly reuse the measured fitting data of the technical solution without requiring additional experimental calibration by the user, significantly reducing the cost of implementing the solution.

[0025] S220, substitute the CPU utilization rate of QW at each preset moment in the running cycle into P to obtain the server power of QW at each preset moment in the running cycle.

[0026] In this embodiment, the x / y / z coefficients matched in S210 are obtained; the CPU utilization of QW at each preset time point within the running cycle is determined in S100 (e.g., one u value per hour within 24 hours: 09:00→0.7, 14:00→0.9, 03:00→0.15, etc.). All preset times within the running cycle are traversed, and the u value at each time point is substituted into the quadratic function model to calculate the server power at the corresponding time point.

[0027] This step achieves dynamic quantification of server power through a "time-by-time calculation" approach, solving the problem of poor scenario adaptability caused by the traditional method of "only calculating average power". On the one hand, time-by-time calculation can accurately capture the fluctuation characteristics of power with CPU utilization (such as high power during the day and low power at night for computing-intensive servers), avoiding the risk of rack overload caused by average power masking peak power. On the other hand, based on the accuracy coefficient of S210 and the reliable utilization rate of S100, the deviation between the calculation results and the actual operating power of the server is minimal, effectively solving the industry pain point of "theoretical power being out of sync with actual power". In addition, the calculation process is purely mathematical, with simple logic and strong repeatability, supporting automated batch processing (such as traversing all servers and times through code), which greatly improves the efficiency of power calculation and provides high-quality quantitative basis for subsequent CPU temperature calculation and rack allocation, ensuring the scientific nature and feasibility of the entire allocation method.

[0028] S300 determines the CPU temperature determination model of QW at each preset time based on the server power and server operating mode at each preset time during the QW's operating cycle.

[0029] Furthermore, step S300 includes the following steps: S310, determine the operating mode of QW at the current preset time t; the operating mode includes performance mode and energy saving mode.

[0030] In this embodiment, the historical operating data of other servers with the same load type is statistically analyzed; or, in S100, when the CPU periodic change curve corresponding to QW is determined, the operating mode of QW at each preset time can be obtained; if the server enables energy-saving strategies (such as idle frequency reduction, fan low speed operation), it is in energy-saving mode; if it runs at full performance or balanced performance (without mandatory energy-saving restrictions), it is in performance mode.

[0031] For example, QW is a database server. During the high-concurrency period during the day (10:00-17:00), it needs to process transactions at full capacity, so it is in performance mode; during the low-load period at night (00:00-06:00), it automatically starts the energy-saving strategy, so it is in energy-saving mode.

[0032] In this embodiment, the pattern determination is based on the inherent operating rules of the server, without the need to collect additional complex data. The judgment logic is simple and efficient, and can quickly provide core basis for subsequent segmentation rules and model selection, ensuring the execution efficiency of the entire S300 step.

[0033] S320, Set the corresponding server power consumption segmentation threshold according to the operating mode: If the operating mode is energy-saving mode, set the first power consumption threshold P1, and the segmentation condition is P. t≤P1 and P t >P1; If the operating mode is performance mode, set the second power consumption threshold P2, and the segmentation condition is P. t ≤P2 and P t >P2; where P t This represents the server power corresponding to QW at the current preset time.

[0034] In this embodiment, through the analysis of a large amount of server operation data, it was found that the server power consumption growth rate decreases as the CPU utilization increases under different operating modes, and there is a clear inflection point. For example, a CPU utilization rate of 0.6 is the inflection point of the server power consumption growth rate. Accordingly, the server power consumption corresponding to the CPU utilization rate at the inflection point can be determined, i.e., the segmented threshold.

[0035] The segment threshold is a critical value that distinguishes the slope of the CPU temperature-power relationship. It is preset by the data center operation and maintenance standards or actual measurement data, and P1 (energy saving mode threshold) < P2 (performance mode threshold) (because the power consumption limit of energy saving mode is lower).

[0036] Threshold setting example: Preset P1=200W (maximum reasonable power consumption in energy saving mode), P2=300W (critical point of normal power consumption in performance mode).

[0037] Segmentation condition determination: Obtain the server power P at the current moment calculated by S200. t If the operating mode is energy-saving mode, press "P". t ≤200W, P t >200W segment; if in performance mode, press "P". t ≤300W, P t >300W segmentation; Example: QW at 14:00 (performance mode) P t =326.71W, since 326.71W > P2 = 300W, it is determined to be "P t >P2” segment; at 03:00 (energy saving mode) P t =180.83W, since 180.83W≤P1=200W, it is determined to be "P t ≤P1” segment.

[0038] This sub-step sets thresholds based on the different operating modes, aligning with the power consumption characteristics of different modes—energy-saving mode has small power consumption fluctuations and a lower threshold; performance mode has large power consumption fluctuations and a higher threshold. This avoids the problem of inaccurate segmentation caused by a single threshold and lays the foundation for accurate matching of subsequent model coefficients.

[0039] S330, obtain the preset temperature coefficient mapping table YZ; YZ includes several rows, each row contains a set of operating mode-power consumption segmentation conditions and corresponding linear coefficients and constant terms.

[0040] The YZ table is a standardized structured table. Its core logic is that a unique combination of "operation mode - power consumption segmentation condition" corresponds to a set of "linear coefficients + constant terms". An example of the table structure is shown in Table 2. Table 2 This sub-step, through a segmented and modal model design, ensures the accuracy of CPU temperature calculation. In power-saving mode, T is calculated directly, aligning with the stable linear relationship between power consumption and temperature. In performance mode, ΔT is calculated first, avoiding interference from intake air temperature, as power consumption in performance mode is only related to the temperature difference. Furthermore, the model is a simple linear function with concise calculation logic, allowing for rapid back-calculation of CPU temperature. This provides reliable model support for S400 temperature calculation and complementary allocation of S500, and the matching process is highly automated, adaptable to large-scale server allocation scenarios.

[0041] Furthermore, the linear coefficients and constant term coefficients in the temperature coefficient mapping table YZ are derived from a quadratic function of the computer room intake air temperature, and the derivation formula is: A = G × T0 2 +L×T0+K; where G is the first fitting coefficient, L is the second fitting coefficient, and K is the third constant term.

[0042] All linear coefficients (a1 / a2 / a3 / a4) and constant terms (b1 / b2 / b3 / b4) in the YZ table are derived from the same quadratic function, with the function form fixed as A=G×T0. 2 +L×T0+K: Dependent variable A: can refer to any linear coefficient (a1 / a2 / a3 / a4) or constant term (b1 / b2 / b3 / b4) in the YZ table. Independent variable T0: Preset air intake temperature during the computer room design phase (e.g., 20℃ / 25℃ / 30℃); Fixed parameters G (first fitting coefficient), L (second fitting coefficient), and K (third constant term): For different types of A, there is a unique set of G / L / K (obtained by fitting actual measured data and kept constant).

[0043] For each type of linear coefficient (a1 / a2 / a3 / a4) and constant term (b1 / b2 / b3 / b4) in the YZ table, perform the following derivation process: Step 1: Determine the current derivation object (e.g., a1) and extract the corresponding fixed G / L / K values ​​(e.g., G=0.002, L=-0.05, K=0.32 for a1). Step 2: Substitute the computer room intake air temperature T0 to calculate the specific value of the derived object; Example 1: Deriving a1(P) under energy-saving mode t (Linear coefficients ≤ P1), T0 = 25℃: a1 = 0.002 × 25 2 +(-0.05)×25+0.32=0.32; Example 2: Deriving b4(P) in performance mode t > The constant term of P2), T0=25℃: b4=1.2×25²+(-35)×25+450=325; Step 3: Repeat steps 1-2 to derive all types of coefficient / constant terms, covering all "running mode-segmentation condition" combinations in the YZ table.

[0044] The derived coefficients / constant terms are organized according to the structure of "operation mode - consumption segmentation condition - linear coefficient A - constant term B - model independent variable" to form a complete YZ table.

[0045] This coefficient derivation method, through a design of "quadratic function of inlet air temperature + fixed G / L / K coefficients," solves the core problem of "fixed coefficients and poor adaptability" in traditional YZ tables. On one hand, the derivation formula relies solely on the preset inlet air temperature T0 of the data center, eliminating the need for additional complex data collection. The calculation logic is simple and repeatable, avoiding the tedious work of refitting coefficients in different data center environments and significantly reducing the implementation cost. On the other hand, the quadratic function accurately captures the impact of inlet air temperature on the "power-temperature relationship" (e.g., a slightly higher linear coefficient at the same power when inlet air is 30℃ compared to 20℃), making the derived coefficients more closely match actual operating scenarios and thus improving the calculation accuracy of the CPU temperature determination model. Simultaneously, all coefficients are derived using a unified formula, ensuring the consistency and standardization of data in the YZ table, supporting automated batch generation and updates, and adapting to different inlet air temperature configurations in large-scale data centers, significantly enhancing the universality and flexibility of the entire server location allocation method.

[0046] S340, based on the current preset operating mode and server power P t The corresponding linear coefficients and constant terms are matched from YZ to determine the CPU temperature determination model based on the segmentation conditions. When the operating mode is power saving mode, the CPU temperature determination model is: T=a1×P+b1, P≤P1 or T=a2×P+b2, P>P1; T is the CPU temperature, a1 is the first linear coefficient, b1 is the first constant term, a2 is the second linear coefficient, and b2 is the second constant term. When the operating mode is performance mode, the CPU temperature determination model is: ΔT=a3×P+b3, P≤P2 or ΔT=a4×P+b4, P>P2; ΔT is the temperature difference between the CPU temperature and the air intake temperature of the computer room, ΔT=T-T0.

[0047] In this embodiment, through analysis of a large amount of server operation data, it was found that: when the server is running in energy-saving mode, there is a linear relationship between server power and CPU temperature; while when running in performance mode, there is a piecewise linear relationship between server power consumption, CPU temperature, and the difference between the intake air temperature and the server room temperature; however, when the difference between the CPU temperature and the server room intake air temperature is less than a certain value, for example, ΔT≤40℃, regardless of the intake air temperature, the server power consumption is only related to the difference between the CPU temperature and the intake air temperature; based on the above rules, a piecewise CPU temperature determination model is established; it can be understood that when ΔT≤40℃, the corresponding power of the server can also be obtained, thereby determining P2.

[0048] Matching logic: Based on "current running mode + P" t The "segmentation condition" has two dimensions; the corresponding linear coefficients a and constant terms b are extracted from the YZ table. Model determination based on pattern: Power saving mode: A linear model that directly outputs the CPU temperature T—if P t ≤P1, matching a1, b1, the model is T=a1×P t +b1; if P t >P1, matching a2 and b2, the model is T=a2×P t +b2.

[0049] Example: QW at 03:00 (energy saving mode, P) t =180.83W≤P1=200W), matching a1=0.22, b1=28, the model is T=0.22×180.83+28≈67.78℃.

[0050] Performance mode: First output a linear model of the temperature difference ΔT, then derive T using T=ΔT+T0 (T0 is the air intake temperature of the computer room) -- if P t ≤P2, matching a3 and b3, the model is ΔT=a3×P t +b3; if P t >P2, matching a4 and b4, the model is ΔT=a4×P t +b4.

[0051] Example: QW at 14:00 (performance mode, P) t=326.71W>P2=300W), T0=25℃, matching a4=0.11, b4=20, the model is ΔT=0.11×326.71+20≈55.94℃, further derived T=55.94+25=80.94℃.

[0052] This sub-step, through a segmented and modal model design, ensures the accuracy of CPU temperature calculation—in energy-saving mode, T is calculated directly, aligning with the stable linear relationship between power consumption and temperature; in performance mode, ΔT is calculated first, avoiding interference from intake air temperature in the temperature calculation. Simultaneously, the model is a simple linear function with concise calculation logic, enabling rapid back-calculation of CPU temperature. This provides reliable model support for S400 temperature calculation and complementary allocation of S500, and the matching process is highly automated, adaptable to large-scale server allocation scenarios.

[0053] S400 determines the CPU temperature of QW at each preset moment in its operating cycle based on the server power and CPU temperature at each preset moment in the QW's operating cycle.

[0054] Obtain the server power P calculated by S200 at the current preset time. t (e.g., 14:00→326.71W, 03:00→180.83W); The CPU temperature determination model for the corresponding time determined by S300 (including the matched linear coefficient a, constant term b, and model type—directly calculate T or calculate ΔT first); Traverse all preset times within the operating cycle, calculate the CPU temperature corresponding to each preset time, and generate a "preset time-CPU temperature" correspondence table for QW (e.g., 24 rows of data), which serves as the core temperature basis for S500 rack allocation.

[0055] This step achieves accurate reverse calculation of CPU temperature through the logic of "mode-based + segmented calculation". The mode-based calculation adapts to the different operating characteristics of servers - the power saving mode directly calculates T, while the performance mode first calculates ΔT. The calculation is simplified by using a linear formula to ensure accurate and efficient results. The output time-by-time temperature data, together with the power data, constitutes a "dual-dimensional allocation basis", avoiding the risk of local overheating caused by allocating based solely on power. This provides reliable support for the complementary layout of S500. At the same time, the calculation process can be automated and executed in batches, adapting to large-scale server scenarios and improving the practicality and efficiency of the entire allocation method.

[0056] S500 allocates each server to a corresponding rack based on the server power and CPU temperature of each server to be allocated at the same preset time. The total server power of all servers to be allocated in each rack at any preset time is less than a preset total server power threshold, and the total CPU temperature is less than a preset total CPU temperature threshold.

[0057] Furthermore, step S500 includes the following steps: S510 classifies all servers to be allocated according to the power fluctuation amplitude and temperature fluctuation amplitude during the operating cycle, resulting in a high fluctuation group, a medium fluctuation group, and a low fluctuation group; where the power fluctuation amplitude is the difference between the maximum and minimum server power during the operating cycle, and the temperature fluctuation amplitude is the difference between the maximum and minimum CPU temperature during the operating cycle.

[0058] In this embodiment, S510 is implemented as follows: S511 calculates the dual fluctuation amplitude of a single server.

[0059] For each server to be allocated, based on the time-by-time power data from S200 and the time-by-time temperature data from S400, two core indicators are calculated: Power fluctuation amplitude (ΔP) = Maximum server power (P_max) - Minimum server power (P_min) within the operating cycle; Temperature fluctuation amplitude (ΔTQ) = Maximum CPU temperature (T_max) - Minimum CPU temperature (T_min) within the operating cycle. Example: Server A has P_max = 326.71W and P_min = 180.83W within 24 hours, ΔP = 326.71 - 180.83 = 145.88W; T_max = 80.94℃ and T_min = 57.36℃, ΔQT = 80.94 - 57.36 = 23.58℃.

[0060] S512, Grouping by Statistical Quantiles Calculate the 25th percentile (Q1) and 75th percentile (Q3) of ΔP and ΔTQ for all servers, with high volatility ≥ Q3, medium volatility = Q1~Q3, and low volatility ≤ Q1.

[0061] This sub-step, through "dual fluctuation amplitude + joint grouping," accurately distinguishes the load stability characteristics of servers, solving the peak aggregation problem caused by the traditional "indiscriminate mixed allocation." Servers in the high fluctuation group are the difficult allocation target (prone to exceeding thresholds due to peak clustering); after being separately categorized, they can be prioritized for targeted matching. Medium / low fluctuation groups serve as complementary resources, flexibly balancing rack load. The grouping rules are quantifiable and flexibly configurable, adapting to the distribution of different server types in different data centers. This provides a clear classification basis for subsequent complementary matching, avoiding resource waste or threshold exceeding caused by blind combination, and improving allocation efficiency and rationality.

[0062] The S520 pre-calculates the corresponding remaining power capacity and remaining temperature capacity for each rack.

[0063] The core constraints for each server rack are preset as follows: ① Preset total server power threshold (P_total, e.g., 4000W); ② Preset total CPU temperature threshold (T_total, e.g., 500℃), which are determined based on the server rack's hardware capacity and heat dissipation design.

[0064] The remaining capacity must ensure that it does not exceed the limit at any preset time, therefore it is calculated based on the maximum total load of the allocated servers: Remaining power capacity (ΔP_remain) = P_total - Maximum total power of allocated servers at all times (P_all_max); Remaining temperature capacity (ΔT_remain) = T_total - Maximum total temperature of allocated servers at all times (T_all_max); Example: For a server rack HU, P_total = 4000W, T_total = 500℃, and 3 servers are allocated. Their maximum total power P_all_max = 1200W and maximum total temperature T_all_max = 180℃ in 24 hours. Then, ΔP_remain = 4000 - 1200 = 2800W, ΔT_remain = 500 - 180 = 320℃.

[0065] For an empty server rack that has not been assigned any servers, the remaining power capacity = P_total and the remaining temperature capacity = T_total (e.g., for an empty server rack HU, ΔP_remain = 4000W and ΔT_remain = 500℃).

[0066] This sub-step calculates remaining capacity by "deducting from maximum total load," completely resolving the risk of subsequent peak load exceeding limits caused by the traditional "calculation based on current load" approach. If only the current total load is considered, peak loads from already allocated servers may overlap in subsequent moments, preventing new servers from being added. By reserving capacity based on maximum total load, it ensures that the total rack load never exceeds the threshold after a new server is added, guaranteeing rack operational stability. Simultaneously, the quantitative calculation of remaining capacity provides clear constraints for subsequent server combination selection, avoiding invalid matching attempts and improving allocation efficiency.

[0067] S530: Select one server from the high fluctuation group as the baseline server, traverse the candidate servers in the medium fluctuation group and the low fluctuation group, and calculate the sum of the power difference and the sum of the temperature difference between the baseline server and the candidate servers at each preset time, as the complementary matching weight.

[0068] One server is randomly selected from the high volatility group or selected based on "maximum volatility priority" as the baseline server (e.g., server B in the high volatility group, ΔP=220W, ΔT=38℃). The high volatility server is given priority to reduce the difficulty of allocation.

[0069] The candidate servers are all unassigned servers in the medium volatility group and the low volatility group (such as server A in the medium volatility group and server C in the low volatility group).

[0070] Furthermore, the complementary matching weights in step S530 conform to the following relationship: η=α×∑ n i=1 |P i，1 -P i，2 |+β×∑ n i=1 |T i，1 -T i，2 |; Where α and β are preset weighting coefficients, α + β = 1, P i，1 P is the server power of the baseline server at the i-th preset time. i，2 Let T be the server power of the candidate server at the i-th preset time. i，1 Let T be the CPU temperature of the benchmark server at the i-th preset time. i，2 Let i be the CPU temperature of the candidate server at the i-th preset time; i ranges from 1 to n, where n is the number of preset times within the running cycle.

[0071] In this embodiment, η is used to quantify the complementarity between the baseline server and the candidate server; the larger the value of η, the stronger the complementarity. α (power difference weighting coefficient) and β (temperature difference weighting coefficient) are constrained by α+β=1 (to ensure weight normalization and avoid double calculation), with values ​​ranging from 0 to 1 and 0 to 1, determined by the data center operation and maintenance priority. An example is shown below: Scenario 1: The risk of power overload in the data center is higher than the risk of heat dissipation (e.g., the power supply line of the server rack has limited load-bearing capacity): Set α=0.7, β=0.3 (focusing on power complementarity); Scenario 2: The heat dissipation pressure in the data center exceeds the power constraint (such as a high-density server rack cluster, which is prone to local overheating): Set α=0.3, β=0.7 (focusing on temperature complementarity); Scenario 3: Power and temperature are equally important (standard data center configuration): Set α=0.5, β=0.5 (balanced weighting).

[0072] The design of this weighted formula significantly optimizes the scientific rigor and flexibility of complementarity assessment, with its core advantages manifested in three aspects: Adapting to different data center priority requirements: By dynamically adjusting the α and β coefficients, it can specifically match the core requirements of data centers such as "power constraint priority", "heat dissipation priority" or "balance constraint", solving the problem that traditional fixed weights cannot take into account diverse scenarios. For example, high-density rack clusters can enhance temperature complementarity by increasing the β weight to avoid local overheating; data centers with limited power supply can increase the α weight to ensure stable power load and reduce the risk of overload.

[0073] The accuracy of quantitative complementarity assessment: The logic of "sum of time-by-time differences + weighted normalization" is adopted, which not only retains the core principle that "the larger the difference, the stronger the complementarity", but also avoids the evaluation distortion caused by weight superposition through the constraint of α+β=1. This allows the η value to objectively reflect the overall complementary effect of the two servers. Compared with simple summation, it can more accurately select the optimal combination of "power peak shifting + temperature peak shifting".

[0074] Improve the adaptability of the allocation scheme: All basic data in the formula comes from the actual test data of S200 and S400 in the early stage, which ensures the reliability of the weight calculation. At the same time, the coefficient setting is simple and intuitive, and the data center operation and maintenance personnel can quickly adjust it according to the actual operation. There is no need for complex modeling, which greatly reduces the difficulty of implementing the scheme and makes the allocation results more in line with the actual operation needs of the data center, further improving the utilization rate of rack resources and operational stability.

[0075] S540 filters server combinations whose complementary matching weights are higher than the preset weight thresholds, and whose total server power is less than or equal to the remaining power capacity and total CPU temperature is less than or equal to the remaining temperature capacity at each time point after combination.

[0076] A preset weight threshold (W_threshold, e.g., 1500) is set. Combinations with weights higher than this threshold are considered to have "complementarity met" (the threshold can be adjusted based on rack capacity and server fluctuation characteristics).

[0077] For each combination of "baseline server + candidate server", two core conditions are verified: ① the total power at all preset times after combination is less than or equal to the remaining power capacity; ② the total temperature at all preset times after combination is less than or equal to the remaining temperature capacity.

[0078] Example: The combination of baseline server B and candidate server A has a maximum total power of 2200W≤2800W and a maximum total temperature of 250℃≤320℃ at all times, and η=2120>1500, which meets the conditions; summarize all combinations that "meet the weight standard + meet the double constraint standard" to form a candidate combination list (such as [B+A,B+C]).

[0079] This sub-step employs a dual screening process of "weighted threshold + dual capacity constraints" to ensure that the selected combinations possess both strong complementarity and strict compliance with rack operation constraints. The weighted threshold filters out combinations with poor complementarity (such as high-fluctuation + high-fluctuation combinations), preventing excessive fluctuations in total load; the dual capacity constraints directly mitigate the risk of power or temperature exceeding thresholds, ensuring rack operational stability. The screening logic is quantifiable and can be automated without manual intervention, significantly improving the efficiency of combination screening, especially suitable for large-scale server allocation scenarios, while ensuring the scientific validity and reliability of the screening results.

[0080] S550: Assign the highest-scoring server combination to the current rack, and update the remaining power capacity and remaining temperature capacity of the current rack; repeat S530-S540 until the remaining capacity of the current rack cannot accommodate the new server combination, then switch to the next empty rack to continue the allocation.

[0081] Select the combination with the highest complementary matching weight from the candidate combination list (e.g., B+A, η=2120 > B+C, η=1800), and allocate the server of this combination to the current rack. After allocation, recalculate the remaining capacity of the current rack and repeat S530-S540: select the next baseline server from the high volatility group (if the high volatility group has been fully allocated, select the baseline from the medium volatility group), match the remaining candidate servers, filter the combinations that meet the conditions and allocate them, until the remaining capacity of the current rack cannot accommodate any new combination (e.g., ΔP_remain=500W, no candidate server power ≤500W), then switch to the next empty rack and repeat the above process until all servers are allocated.

[0082] This sub-step, through "optimal combination priority allocation + dynamic capacity update + cyclic switching," maximizes the utilization of rack resources and efficiently allocates servers. Optimal combination priority ensures the strongest server complementarity within each rack, resulting in the most stable overall load and reducing the risk of localized overheating and overload. Dynamically updating remaining capacity guarantees the accuracy of subsequent allocation constraints, avoiding overloading caused by capacity calculation errors. The cyclic switching mechanism ensures that all rack resources are used evenly, preventing single racks from being overloaded while others remain idle. The entire allocation process is highly automated, requiring no manual intervention, and is suitable for the server deployment needs of large-scale data centers, ultimately achieving the goals of "maximizing rack resource utilization, optimizing operational stability, and maximizing allocation efficiency."

[0083] Furthermore, step S500 also includes the following steps: S560 If no single candidate server can meet the threshold requirement when combined with the baseline server, then select two or more low-fluctuation group servers as supplementary combinations, calculate the total power and total temperature of the baseline server and the supplementary combinations, until the remaining capacity constraint is met.

[0084] This step is triggered when no combination of "single candidate server + baseline server" meets the requirements after S540 screening (i.e., after all single candidate servers are combined with the baseline server, either the complementary matching weight is lower than the threshold, or the total power / total temperature exceeds the remaining capacity).

[0085] Unassigned servers are selected from the low-fluctuation group and sorted by "fluctuation amplitude from smallest to largest" (prioritizing servers with the smallest fluctuation to avoid increasing the total load fluctuation after supplementation) to form a supplementary server pool (e.g., servers C, D, and E in the low-fluctuation group, ΔP ≤ 100W and ΔTQ ≤ 15℃).

[0086] The number of servers is gradually increased in the order of "1 base server + 2 low-fluctuation servers" and "1 base server + 3 low-fluctuation servers". For each combination, the following calculations are performed: ① Complementary matching weights of the combination (η=α×∑|P) i,基准 -P i,补充组合 |+β×∑|T i,基准 -T i,补充组合 |, where P i,补充组合 =∑P of a single low-fluctuation server i T i,补充组合 =∑T of a single low-fluctuation server i ); ② Combine the total power (Pt_total = Pt_baseline + ∑Pt_low fluctuation) and total temperature (Tt_total = Pt_baseline + ∑Tt_low fluctuation) at all preset times.

[0087] Filter the smallest supplementary combination where "complementary matching weight ≥ preset threshold" and "all times Pt_total ≤ remaining power capacity, Tt_total ≤ remaining temperature capacity" (preferably select 2 supplementary servers to avoid resource waste); allocate the multi-server combination to the current rack, and update the rack's remaining power capacity and remaining temperature capacity according to "maximum total power of combination, maximum total temperature".

[0088] This sub-step, through a mechanism of "combining multiple low-fluctuation servers," completely resolves the difficulty in allocating high-fluctuation servers caused by the inability of a single candidate server to match the baseline server. Low-fluctuation servers are characterized by stable load and low peak loads. Even after combining multiple servers, the overall load fluctuation remains controllable. This not only offsets the peak load of the baseline server through complementarity but also prevents exceeding thresholds due to excessive power / temperature of a single server. Simultaneously, prioritizing the "minimum number of replacements" avoids excessive rack capacity usage, ensuring maximum resource utilization. This mechanism significantly improves the robustness of the allocation scheme, especially suitable for scenarios with a high proportion of high-fluctuation servers, preventing some servers from becoming idle due to mismatch and ensuring the integrity and efficiency of the entire allocation process.

[0089] S570 If, during the allocation process, the difference between the total server power and the total server power threshold is less than the first preset warning threshold at a certain preset moment, or the difference between the total CPU temperature and the total CPU temperature threshold is less than the second preset warning threshold, then the server with the highest power or temperature at that moment will be adjusted to another rack with more remaining power and temperature capacity. The total power and total temperature of the two racks at each moment after adjustment will be recalculated to ensure that the corresponding threshold requirements are met.

[0090] Two types of warning thresholds are preset (based on a ratio or a fixed difference between the rack thresholds): First preset warning threshold (power warning): can be 10% of the total power threshold (e.g., if the total power threshold is 4000W, the first warning threshold = 400W), or a fixed difference (e.g., 300W). The second preset warning threshold (temperature warning) can be 10% of the total temperature threshold (e.g., if the total temperature threshold is 500℃, the second warning threshold = 50℃), or a fixed difference (e.g., 40℃).

[0091] After each server combination allocation, iterate through the total power and total temperature of the current rack at all preset times to determine whether to trigger an alert: Power warning trigger: There exists a moment when the total power (Pt_total) satisfies "total power threshold - Pt_total < first preset warning threshold" (e.g., 4000-3700=300W < 400W). Temperature warning trigger: There is a moment when the total temperature (Tt_total) satisfies "total temperature threshold - Tt_total < second preset warning threshold" (e.g., 500-470=30℃ < 50℃).

[0092] For the time when the warning is triggered (e.g., rack HU1 triggers a power warning at 14:00 with a total power of 3700W), filter the server with the highest power (when the power warning is triggered) or the highest temperature (when the temperature warning is triggered) in the rack at that time (e.g., server A has a power of 280W at 14:00, which is the highest in the rack).

[0093] Iterate through other allocated servers or empty racks, and filter racks with "remaining power capacity ≥ maximum power of the server to be adjusted" and "remaining temperature capacity ≥ maximum temperature of the server to be adjusted" (e.g., rack HU2 has a remaining power capacity of 500W ≥ 280W and a remaining temperature capacity of 80℃ ≥ 65℃). Prioritize the rack with the most sufficient remaining capacity.

[0094] Migrate the server to be adjusted from the original rack to the target rack. Recalculate the total power and total temperature of both the original and target racks at all preset times to ensure: ① The original rack no longer triggers any warnings (e.g., after HU1 adjustment, total power at 14:00 = 3700 - 280 = 3420W, 4000 - 3420 = 580W ≥ 400W); ② The target rack does not trigger any new warnings (e.g., after HU2 adjustment, total power at 14:00 = 2200 + 280 = 2480W ≤ 4000W, difference 1520W ≥ 400W). Simultaneously update the remaining power capacity and remaining temperature capacity of both the original and target racks to ensure the accuracy of subsequent allocation constraints.

[0095] This sub-step employs a dynamic optimization mechanism of "early warning trigger + precise adjustment" to proactively mitigate the potential risk of racks operating "close to the threshold." Traditional allocation methods only verify the threshold after allocation is complete, easily leading to unstable operating states where "the peak value appears to be within the threshold but is actually close." This step, however, monitors in real-time during allocation and avoids overload, overheating, or sudden increases in localized heat dissipation pressure by migrating high-load servers to racks with sufficient remaining capacity. The adjustment logic focuses on the "highest load server at the time of the early warning," precisely addressing risk points and avoiding inefficiencies caused by large-scale adjustments. Simultaneously, it re-verifies the load of both racks at all times, ensuring that the overall load still meets constraints after adjustment, guaranteeing the stability and reliability of the data center operation. This mechanism significantly reduces the probability of equipment failure and adjustment costs in subsequent maintenance, making the allocation scheme more practical and secure.

[0096] Furthermore, after step S500, the method further includes the following steps: S600 obtains the server power, CPU temperature, and corresponding peak power and peak temperature periods for all servers in any rack HU at preset times during the operating cycle; wherein, the peak power period is the preset time interval in which the power of a single server reaches its maximum value within its own operating cycle, and the peak temperature period is the preset time interval in which the CPU temperature of a single server reaches its maximum value within its own operating cycle.

[0097] From the calculation results of S200 and S400, extract three types of core data for all allocated servers in the rack HU: ① Server power at each preset time during the operating cycle (e.g., 24 hours / 1 hour per time, a total of 24 sets of P data); ② CPU temperature at each preset time (a total of 24 sets of T data); ③ Peak power (P_max, maximum power during its own operating cycle) and peak temperature (T_max, highest temperature during its own operating cycle) of a single server.

[0098] The peak period is defined as "a preset time interval that continuously meets the peak conditions," and the determination criteria are as follows: Peak power period: The peak power period is defined as [Ts_P,Te_P] when the power at a certain moment is ≥P_max×K (K is the peak proportion threshold, which is preset to 85%-95%, such as K=90%) and the condition is met for ≥2 consecutive preset moments. Temperature peak period: When the temperature is ≥ T_max × K (same as K value) at a certain moment, and this condition is met for ≥ 2 consecutive preset moments, the temperature peak period is denoted as [Ts_T,Te_T]. Special handling: If only one moment meets the condition (instantaneous peak), it is judged as "no independent peak period" and merged into the adjacent period; if there are multiple discontinuous peak periods (such as [10:00, 12:00] and [14:00, 16:00]), they are merged into a comprehensive peak period [10:00, 16:00].

[0099] Iterate through each server in the rack and extract the peak power and peak temperature periods according to the above rules. Since the peak power and peak temperature periods overlap significantly (≥80%), if there is partial overlap between the two periods, take the union of the two as the final peak period (e.g., peak power [10:00, 16:00] and peak temperature [11:00, 17:00] are merged into [10:00, 17:00]).

[0100] In this step, the peak period directly reflects the server's high load and heat generation window. Only after identifying this window can we avoid localized overheating by staggering peak times.

[0101] S610 divides the servers in the rack HU into several peak groups according to the peak power period and the peak temperature period. Each peak group corresponds to a unique peak period, and the peak periods of different peak groups do not overlap.

[0102] Collect the final peak time periods of all servers within the rack HU and integrate them into a rack-level basic peak interval according to the "overlapping / adjacent merge" rule: ① If Te of time period 1 is greater than or equal to Ts of time period 2 (e.g., S1[10:00,17:00] and S2[12:00,15:00]), merge them into [10:00,17:00]; ② If the time interval is less than or equal to 1 time (e.g., [10:00,12:00] and [13:00,15:00]), they are considered adjacent and merged.

[0103] Following the rule that "sub-interval duration = 2-3 preset times + interval ≥ 1 time", the merged base interval is split into independent sub-intervals (ensuring no overlap between groups): ① The duration of the sub-interval is adjusted according to the total length of the base interval (e.g., the base interval [10:00, 17:00] has a total of 8 times, which is split into 3 2-hour sub-intervals); ② The interval between sub-intervals is ≥ 1 time to avoid edge overlap.

[0104] Based on the principle of "the longest intersection between the server's peak time period and the sub-interval", each server is assigned to a unique peak group; servers without peak time periods are assigned to the "basic group" (independent of all peak groups).

[0105] This step, through a "merge-split" logic, transforms highly overlapping peak periods within the rack into non-overlapping groups, resolving the core pain point of "peak overlap leading to localized overheating." The non-overlapping group design ensures that when servers with different peak groups are subsequently deployed in adjacent U-positions, the high-load heat dissipation windows are completely staggered, preventing heat accumulation in a temporal sequence. Simultaneously, the grouping rules are quantifiable and can be automatically executed, adapting to different server numbers and peak distribution scenarios, providing a clear grouping basis for subsequent U-position deployment and improving the scientific nature and operability of the deployment logic.

[0106] S620 arranges servers whose peak power periods and peak temperature periods do not overlap in adjacent U positions, and the average power difference and average CPU temperature difference between adjacent U position servers during their operating cycles are not less than a preset power difference threshold and a preset temperature difference threshold.

[0107] For each server in the rack, calculate two core average metrics: ① Average power (P_avg = total power at all times during the running cycle / n, n = 24); ② Average CPU temperature (T_avg = total temperature at all times during the running cycle / n).

[0108] Two preset quantization thresholds are provided: ① Preset power difference threshold (ΔP_th, e.g., 50W); ② Preset temperature difference threshold (ΔT_th, e.g., 15℃). The thresholds are set based on the heat dissipation capacity of the rack and the type of server (the thresholds can be appropriately increased for high-density racks).

[0109] Servers are allocated in rack unit (U-position) order from top to bottom (or bottom to top), with the following core rules: ① Adjacent U-positions must be assigned servers from different peak groups (to ensure that peak periods do not overlap); ② The |A_avg-B_avg| of adjacent U-position servers must be greater than or equal to ΔP_th and |T_A_avg-T_B_avg| must be greater than or equal to ΔT_th (to ensure that power / temperature is complementary); ③ If a U-position does not have a server that meets the conditions, it will be selected from the basic group (without peak periods) to ensure that the rules are implemented.

[0110] This step optimizes the arrangement of adjacent server racks from both temporal and numerical dimensions through a dual complementary rule of "staggered peak load groups + acceptable average difference". Temporally, different peak load groups prevent the superposition of high-load heat; numerically, ensuring acceptable power / temperature differences guarantees significant differences in load and heat intensity among adjacent servers, forming a "high-low mix" to balance local heat dissipation pressure. Compared to traditional "random arrangement" or "sorting by power," this rule effectively reduces the risk of heat accumulation in adjacent racks, improves the uniformity of heat dissipation within the rack, reduces server throttling or failures caused by localized overheating, and extends equipment lifespan.

[0111] Based on the airflow structure of the rack HU, the S630 places servers with higher average CPU temperatures in the U-position area with higher airflow efficiency, and servers with lower average CPU temperatures in the U-position area with lower airflow efficiency.

[0112] Based on the inherent airflow design of the cabinet, the ventilation efficiency zones are divided (core basis: the resistance on the airflow path): ① Front-in / rear-out cabinets: the middle U-position (e.g., U4-U8) has the highest ventilation efficiency (lowest airflow resistance), while the top (U9-U12) and bottom (U1-U3) have lower ventilation efficiency; ② Bottom-in / top-out cabinets: the bottom U-position (U1-U4) has the highest ventilation efficiency, while the top (U9-U12) has lower ventilation efficiency; ③ Mark the range of each zone (e.g., high-efficiency ventilation zone for front-in / rear-out cabinets: U4-U8, low-efficiency zone: U1-U3, U9-U12).

[0113] All servers in the rack are sorted from highest to lowest temperature (T_avg) and divided into three groups: high temperature group (T_avg≥T_avg_total×1.2, where T_avg_total is the average temperature of all servers in the rack), medium temperature group (T_avg_total×0.8~1.2), and low temperature group (T_avg≤T_avg_total×0.8).

[0114] Temperature and ventilation efficiency are adapted for optimal layout, with the core rule: high-temperature group servers → high-efficiency ventilation zone; medium-temperature group → medium-efficiency ventilation zone (if applicable); low-temperature group → low-efficiency ventilation zone. Simultaneously, it must be compatible with S620's adjacent complementary rules (prioritizing peak group staggering and difference thresholds, then adjusting temperature adaptation).

[0115] This step, combined with the temperature-adaptive arrangement of the airflow structure, solves the problem of "focusing only on temporal complementarity while neglecting airflow paths, leading to uneven heat dissipation." High-efficiency ventilation zones ensure smooth airflow, quickly removing heat from high-temperature servers and preventing heat buildup due to insufficient ventilation. Low-temperature servers are placed in low-efficiency zones, ensuring overall heat dissipation isn't affected by poor ventilation, while fully utilizing rack ventilation resources. This rule, combined with the complementary arrangement of the S620, forms a dual optimization of "temporal + spatial" design, staggering peak heat generation in time and optimizing heat dissipation paths spatially to maximize overall rack heat dissipation efficiency, reduce data center air conditioning energy consumption, and further ensure server operational stability, making it particularly suitable for high-density rack cluster scenarios.

[0116] Furthermore, although the steps of the method in this disclosure are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or a step may be broken down into multiple steps.

[0117] Embodiments of the present invention also provide a non-transitory computer-readable storage medium that can be disposed in an electronic device to store at least one instruction or at least one program related to implementing a method in the method embodiments, wherein the at least one instruction or the at least one program is loaded and executed by the processor to implement the method provided in the above embodiments.

[0118] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0119] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0120] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0121] Program code for performing the operations of this application can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0122] Embodiments of the present invention also provide an electronic device, including a processor and the aforementioned non-transitory computer-readable storage medium.

[0123] The electronic device is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments in this application.

[0124] Electronic devices are manifested in the form of general-purpose computing devices. Components of an electronic device may include, but are not limited to: at least one processor, at least one memory, and a bus connecting different system components (including memory and processor).

[0125] The memory stores program code that can be executed by the processor, causing the processor to perform the steps in the various embodiments described in this specification.

[0126] The memory may include readable media in the form of volatile memory, such as random access memory (RAM) and / or cache memory, and may further include read-only memory (ROM).

[0127] The memory may also include programs / utilities having a set (at least one) of program modules, including but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0128] A bus can represent one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus that uses any of the various bus structures.

[0129] Electronic devices can also communicate with one or more external devices (e.g., keyboards, pointing devices, Bluetooth devices, etc.), one or more devices that enable user interaction with the electronic device, and / or any device that enables the electronic device to communicate with one or more other computing devices (e.g., routers, modems, etc.). This communication can be achieved through input / output (I / O) interfaces. Furthermore, electronic devices can communicate with one or more networks (e.g., local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) via network adapters. The network adapter communicates with other modules of the electronic device via a bus. It should be understood that other hardware and / or software modules can be used in conjunction with the electronic device, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0130] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, terminal device, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

[0131] Embodiments of the present invention also provide a computer program product including program code, which, when the program product is run on an electronic device, causes the electronic device to perform the steps of the methods described above in various exemplary embodiments of the present invention.

[0132] While specific embodiments of the invention have been described in detail by way of examples, those skilled in the art should understand that the examples are for illustrative purposes only and are not intended to limit the scope of the invention. Those skilled in the art should also understand that various modifications can be made to the embodiments without departing from the scope and spirit of the invention.

Claims

1. A server location allocation method, characterized in that, The method includes the following steps: S100, for any server QW to be allocated, determine the CPU utilization of QW at each preset moment in the running cycle based on the workload type of QW and the corresponding CPU periodic change curve of QW. S200 determines the server power corresponding to each preset moment in the operation cycle of QW based on the data center intake air temperature, the CPU utilization rate corresponding to each preset moment in the operation cycle of QW, and the preset server power determination model; the server power determination model is determined based on the data center intake air temperature and the operation mode corresponding to each preset moment in QW. S300, based on the server power and server operating mode of QW at each preset moment in the operating cycle, determines the CPU temperature determination model of QW at each preset moment. S400 determines the CPU temperature of QW at each preset moment in its operating cycle based on the server power and CPU temperature at each preset moment in the QW's operating cycle. S500 allocates each server to a corresponding rack based on the server power and CPU temperature of each server to be allocated at the same preset time. The total server power of all servers to be allocated in each rack at any preset time is less than a preset total server power threshold, and the total CPU temperature is less than a preset total CPU temperature threshold.

2. The server location allocation method according to claim 1, characterized in that, Step S200 includes the following steps: S210, Obtain the server power determination model P=x×u 2 +×y×u+z; where P is the server power, u is the CPU utilization, and x, y and z are the first fitting coefficient, the second fitting coefficient and the third fitting coefficient, respectively; x, y and z are obtained according to the data center air intake temperature and the preset fitting coefficient mapping table YR; YR includes several rows, each row including a set of operating modes and data center air intake temperature combinations as well as the specific values ​​of x, y and z. S220, substitute the CPU utilization rate of QW at each preset moment in the running cycle into P to obtain the server power of QW at each preset moment in the running cycle.

3. The server location allocation method according to claim 1, characterized in that, Step S300 includes the following steps: S310, determine the operating mode of QW at the current preset time t; the operating mode includes performance mode and energy-saving mode; S320, Set the corresponding server power consumption segmentation threshold according to the operating mode: If the operating mode is energy-saving mode, set the first power consumption threshold P1, and the segmentation condition is P. t ≤P1 and P t >P1; If the operating mode is performance mode, set the second power consumption threshold P2, and the segmentation condition is P. t ≤P2 and P t >P2; where P t This represents the server power of QW at the current preset time. S330, obtain the preset temperature coefficient mapping table YZ; YZ includes several rows, each row contains a set of operating mode-power consumption segmentation conditions and corresponding linear coefficients and constant terms; S340, based on the current preset operating mode and server power P t The corresponding linear coefficients and constant terms are matched from YZ to determine the CPU temperature determination model based on the segmentation conditions. When the operating mode is power saving mode, the CPU temperature determination model is: T=a1×P+b1, P≤P1 or T=a2×P+b2, P>P1; T is the CPU temperature, a1 is the first linear coefficient, b1 is the first constant term, a2 is the second linear coefficient, and b2 is the second constant term. When the operating mode is performance mode, the CPU temperature determination model is: ΔT=a3×P+b3, P≤P2 or ΔT=a4×P+b4, P>P2; ΔT is the temperature difference between the CPU temperature and the air intake temperature of the computer room, ΔT=T-T0.

4. The server location allocation method according to claim 3, characterized in that, The linear coefficients and constant coefficients in the temperature coefficient mapping table YZ are derived from a quadratic function of the air intake temperature of the computer room. The derivation formula is: A=G×T0²+L×T0+K; where G is the first fitting coefficient, L is the second fitting coefficient, and K is the third constant term.

5. The server location allocation method according to any one of claims 1-4, characterized in that, Step S500 includes the following steps: S510 classifies all servers to be allocated according to the power fluctuation amplitude and temperature fluctuation amplitude during the operating cycle, resulting in high fluctuation group, medium fluctuation group and low fluctuation group; where the power fluctuation amplitude is the difference between the maximum server power and the minimum server power during the operating cycle, and the temperature fluctuation amplitude is the difference between the maximum CPU temperature and the minimum CPU temperature during the operating cycle. S520 pre-calculates the corresponding remaining power capacity and remaining temperature capacity for each rack. S530: Select one server from the high fluctuation group as the reference server, traverse the candidate servers in the medium fluctuation group and the low fluctuation group, and calculate the sum of the power difference and the sum of the temperature difference between the reference server and the candidate servers at each preset time, as the complementary matching weight. S540 filters server combinations whose complementary matching weights are higher than the preset weight thresholds, and whose total server power is less than or equal to the remaining power capacity and total CPU temperature is less than or equal to the remaining temperature capacity at each time point after combination. S550: Assign the highest-scoring server combination to the current rack, and update the remaining power capacity and remaining temperature capacity of the current rack; repeat S530-S540 until the remaining capacity of the current rack cannot accommodate the new server combination, then switch to the next empty rack to continue the allocation.

6. The server location allocation method according to claim 5, characterized in that, Step S500 further includes the following steps: S560 If no single candidate server can meet the threshold requirement when combined with the baseline server, then select two or more low-fluctuation group servers as supplementary combinations, calculate the total power and total temperature of the baseline server and the supplementary combinations, until the remaining capacity constraint is met. S570 If, during the allocation process, the difference between the total server power and the total server power threshold is less than the first preset warning threshold at a certain preset moment, or the difference between the total CPU temperature and the total CPU temperature threshold is less than the second preset warning threshold, then the server with the highest power or temperature at that moment will be adjusted to another rack with more remaining power and temperature capacity. The total power and total temperature of the two racks at each moment after adjustment will be recalculated to ensure that the corresponding threshold requirements are met.

7. The server location allocation method according to claim 5, characterized in that, The complementary matching weights in step S530 conform to the following relationship: η=α×∑ n i=1 |P i，1 -P i，2 |+β×∑ n i=1 |T i，1 -T i，2 |; Where α and β are preset weighting coefficients, α + β = 1, P i，1 Let P be the server power of the baseline server at the i-th preset time. i，2 Let T be the server power of the candidate server at the i-th preset time. i，1 Let T be the CPU temperature of the benchmark server at the i-th preset time. i，2 Let i be the CPU temperature of the candidate server at the i-th preset time; i ranges from 1 to n, where n is the number of preset times within the running cycle.

8. The server location allocation method according to claim 1, characterized in that, Following step S500, the method further includes the following steps: S600 obtains the server power, CPU temperature, and corresponding peak power and peak temperature periods for all servers in any rack HU at preset times during the operating cycle; wherein, the peak power period is the preset time interval in which the power of a single server reaches its maximum value within its own operating cycle, and the peak temperature period is the preset time interval in which the CPU temperature of a single server reaches its maximum value within its own operating cycle. S610 divides the servers in the rack HU into several peak groups according to the peak power period and the peak temperature period. Each peak group corresponds to a unique peak period, and the peak periods of different peak groups do not overlap. S620 arranges servers whose peak power periods and peak temperature periods do not overlap in adjacent U positions, and the average power difference and average CPU temperature difference between adjacent U position servers during their operating cycle are not less than a preset power difference threshold and a preset temperature difference threshold. Based on the airflow structure of the rack HU, the S630 places servers with higher average CPU temperatures in the U-position area with higher airflow efficiency, and servers with lower average CPU temperatures in the U-position area with lower airflow efficiency.

9. A non-transitory computer-readable storage medium, wherein the storage medium stores at least one instruction or at least one program segment, characterized in that, The at least one instruction or the at least one program segment is loaded and executed by the processor to implement the server location allocation method as described in any one of claims 1-8.

10. An electronic device, characterized in that, Includes a processor and the non-transitory computer-readable storage medium as described in claim 9.

Images