Cloud resource pool energy-saving scheduling method, electronic device and product
By monitoring multi-dimensional cluster resource utilization and the number of host machines, a target baseline is established. An energy-saving strategy of multi-indicator collaborative decision-making and dynamic adjustment is adopted to solve the problems of resource allocation imbalance and energy waste in existing technologies, and achieve efficient energy-saving management of cloud resource pools.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- CHINA MOBILE GROUP ZHEJIANG
- Filing Date
- 2026-03-03
- Publication Date
- 2026-05-29
AI Technical Summary
Existing cloud resource management methods mainly suffer from limitations in single-indicator decision-making and a lack of adaptability in static thresholds, leading to imbalances in resource allocation and energy waste, making it difficult to achieve a precise balance between resource utilization and energy consumption.
By monitoring multi-dimensional cluster resource utilization indicators and the number of running host machines, a target baseline is established. Energy-saving strategies involving multi-indicator collaborative decision-making and dynamic adjustment, including hibernation and wake-up of host machines, are adopted to return to the target baseline.
It achieves a precise balance between resource utilization and energy consumption while ensuring business stability, avoiding excessive dormancy or insufficient wake-up, and significantly improving energy efficiency and automation management.
Smart Images

Figure CN122111614A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of cloud computing and data center resource management technology, and in particular to a cloud resource pool energy-saving scheduling method, electronic equipment and products. Background Technology
[0002] With the widespread adoption of cloud computing technology and the continuous expansion of data center scale, energy consumption has become a critical global challenge. Statistics show that data centers consume enormous amounts of electricity annually, and this figure continues to grow. The inherent dynamism of cloud environments, such as the real-time creation and release of virtual machines and the uncertainty of user task runtime, makes resource management extremely complex.
[0003] Existing cloud resource management and energy-saving methods have the following main shortcomings: 1. Limitations of single-indicator decision-making: Most methods rely on a single resource indicator (such as CPU utilization) for scheduling or energy-saving decisions, which can easily lead to resource imbalance. For example, when memory resources are scarce and the CPU is idle, making decisions based solely on CPU indicators may ignore memory bottlenecks, potentially triggering memory swapping and damaging service performance and stability.
[0004] 2. Static thresholds lack adaptability: Using preset fixed thresholds (such as triggering expansion when CPU utilization reaches 70%) to trigger resource adjustments is a static method that cannot adapt to dynamically changing workloads, resulting in low energy efficiency. For example, during low-load periods, improper threshold settings may prevent redundant host servers from effectively hibernating, leading to energy waste.
[0005] Therefore, there is an urgent need for a method that can comprehensively consider the multi-dimensional resource status and dynamically adjust energy-saving strategies in order to achieve a precise balance between resource utilization and energy consumption. Summary of the Invention
[0006] To address the aforementioned issues, embodiments of this application provide a cloud resource pool energy-saving scheduling method, device, storage medium, and product.
[0007] According to a first aspect of the embodiments of this application, a cloud resource pool energy-saving scheduling method is provided, the method comprising: Monitor multi-dimensional cluster resource utilization indicators and the number of running host machines in the cloud resource pool; Establish a target baseline, which is used to define the target range for multi-dimensional cluster resource utilization indicators and the number of running host machines; If the multi-dimensional cluster resource utilization index and the number of running hosts meet all hibernation criteria, then the number of hibernating hosts is determined based on the minimum number of hibernating hosts required for each of the multi-dimensional cluster resource utilization index and the number of running hosts to return to the target baseline, and a host hibernation operation is performed so that after hibernation, the cluster resource utilization and the number of running hosts return to the target baseline; or, If any of the multi-dimensional cluster resource utilization indicators meet any wake-up determination conditions, then the number of host machines that can be woken up is determined based on the maximum number of host machines required for each indicator in the multi-dimensional cluster resource utilization indicators to return to the target baseline, and the host machine wake-up operation is performed so that the cluster resource utilization returns to the target baseline after the wake-up is completed.
[0008] In one implementation, the multi-dimensional cluster resource utilization index includes: The overall CPU utilization of the cluster is obtained based on the ratio of the amount of CPU resources currently used by the cluster to the total amount of CPU resources currently used by the cluster. The overall memory utilization rate of the cluster is obtained based on the ratio of the amount of memory resources currently used by the cluster to the total memory resources of the cluster. The overall cluster memory allocation rate is obtained based on the ratio of the currently allocated memory resources to the current total memory resources of the cluster.
[0009] In one implementation, the hibernation determination condition is that all of the following conditions are met simultaneously: The number of running host machines exceeds the preset minimum number of running host machines threshold; The overall CPU utilization of the cluster has been below the first sleep threshold for several consecutive time periods. The overall memory utilization of the cluster is lower than the second sleep threshold for several consecutive time periods, and the second sleep threshold is greater than the first sleep threshold.
[0010] In one implementation, determining the number of hibernable hosts based on the minimum number of hibernating hosts required for each of the multi-dimensional cluster resource utilization indicators and the number of running hosts to revert to the target baseline includes: Based on the current total number of CPU cores in the cluster, the overall CPU utilization of the cluster, and the maximum number of physical CPU cores that a single host in the current cluster can provide, the first number of hibernating hosts is determined. The first number of hibernating hosts is the maximum number of hibernating hosts that can make the overall CPU utilization of the cluster return to the target range of the overall CPU utilization of the cluster in the target baseline. Based on the current total memory capacity of the cluster, the overall memory utilization of the cluster, and the maximum memory capacity that a single host machine in the current cluster can provide, the second number of hibernating hosts is determined. The second number of hibernating hosts is the maximum number of hibernating hosts that can make the overall memory utilization of the cluster return to the target range of the overall memory utilization of the cluster in the target baseline. Based on the current total memory capacity of the cluster, the overall memory allocation rate of the cluster, and the maximum memory capacity that a single host machine in the current cluster can provide, the number of third hibernating hosts is determined. The number of third hibernating hosts is the maximum number of hibernating hosts that can make the overall memory allocation rate of the cluster return to the target range of the overall memory allocation rate of the cluster in the target baseline. The fourth number of hibernating hosts is determined based on the difference between the number of hosts in the cluster that are in running state and the minimum number of running hosts threshold. The fourth number of hibernating hosts is the maximum number of hibernating hosts that can be hibernated within the target range that makes the number of hosts in the running state return to the number of running hosts in the target baseline. The minimum value among the first number of hibernating host machines, the second number of hibernating host machines, the third number of hibernating host machines, and the fourth number of hibernating host machines shall be taken as the number of hibernating host machines.
[0011] In one implementation, performing the host machine hibernation operation includes: Select running host machines from the cloud resource pool; If there are no virtual machines on the running host machine, then attempt to put the running host machine into hibernation mode directly; If there are virtual machines on the running host, then attempt to modify the cluster resource scheduling policy to cause the running host to migrate its load and enter a hibernation state, until the number of newly hibernating host machines reaches the number of hibernating host machines.
[0012] In one implementation, the wake-up determination condition is triggered when any of the following conditions are met: The overall CPU utilization of the cluster is greater than or equal to the first wake-up threshold; The overall cluster memory utilization is greater than or equal to the second wake-up threshold; The overall cluster memory allocation rate is greater than or equal to the third wake-up threshold, wherein the first wake-up threshold is less than the second wake-up threshold, and the second wake-up threshold is less than the third wake-up threshold.
[0013] In one implementation, determining the number of wakeable hosts based on the maximum number of wakeable hosts required for each indicator in the multi-dimensional cluster resource utilization metrics to revert to the target baseline includes: Based on the current total number of CPU cores in the cluster, the overall CPU utilization of the cluster, and the minimum number of physical CPU cores that a single host in the current cluster can provide, the first number of wakeable hosts is determined. The first number of wakeable hosts is the minimum number of wakeable hosts that makes the overall CPU utilization of the cluster return to the target range of the overall CPU utilization of the cluster in the target baseline. Based on the current total memory capacity of the cluster, the overall memory utilization rate of the cluster, and the minimum memory capacity that a single host machine in the current cluster can provide, the second number of wakeable hosts is determined. The second number of wakeable hosts is the minimum number of wakeable hosts that makes the overall memory utilization rate of the cluster return to the target range of the overall memory utilization rate of the cluster in the target baseline. Based on the current total memory capacity of the cluster, the overall memory allocation rate of the cluster, and the minimum memory capacity that a single host machine in the current cluster can provide, the number of third wake-up hosts is determined. The number of third wake-up hosts is the minimum number of wake-up hosts that makes the overall memory allocation rate of the cluster return to the target range of the overall memory allocation rate of the cluster in the target baseline. The maximum value among the first number of wakeable host machines, the second number of wakeable host machines, and the third number of wakeable host machines is taken as the number of wakeable host machines.
[0014] In one implementation, the host wake-up operation includes: Select host machines that are in a dormant state from the cloud resource pool; According to the number of host machines that can be woken up, the wake-up actions are performed on the host machines that are in a dormant state in sequence; After the host machine in a dormant state is successfully woken up, the cluster resource scheduling policy is modified to include the newly woken-up host machine resources back into the cluster's total resource pool.
[0015] According to a second aspect of the embodiments of this application, an electronic device is provided, comprising: A memory on which computer programs are stored; A processor for executing the computer program in the memory to implement the steps of the method of any one of the first aspects.
[0016] According to a third aspect of the embodiments of this application, a non-transitory computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the steps of the method described in any one of the first aspects.
[0017] According to a fourth aspect of the embodiments of this application, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the method described in any one of the first aspects.
[0018] The embodiments of this application achieve the following beneficial effects: By monitoring multi-dimensional cluster resource utilization indicators and the number of running hosts, a target baseline is established to define reasonable ranges for each indicator. When all hibernation judgment conditions are met, a hibernation operation is performed based on the minimum number of hibernating hosts required for each indicator to return to the baseline, so that resource utilization and the number of hosts return to the baseline. When any wake-up condition is met, a wake-up operation is performed based on the maximum number of wake-up hosts required for each indicator to return to the baseline, so that resource utilization returns to the baseline. This scheme realizes multi-indicator collaborative decision-making and dynamic quantity calculation, overcomes the shortcomings of single-indicator or fixed threshold methods, and can accurately balance resource utilization and energy consumption while ensuring business stability. It avoids excessive hibernation affecting services or insufficient wake-up leading to performance degradation, and significantly improves the energy efficiency and automation management level of cloud data centers.
[0019] Other features and advantages of this application will be described in detail in the following detailed description section. Attached Figure Description
[0020] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a flowchart of a cloud resource pool energy-saving scheduling method provided in an embodiment of this application.
[0021] Figure 2 This is a flowchart of a cloud resource pool energy-saving scheduling method provided in an embodiment of this application.
[0022] Figure 3 This is a flowchart of a cloud resource pool energy-saving scheduling method provided in an embodiment of this application.
[0023] Figure 4 This is a flowchart of a cloud resource pool energy-saving scheduling method provided in an embodiment of this application.
[0024] Figure 5 This is a flowchart of a cloud resource pool energy-saving scheduling method provided in an embodiment of this application.
[0025] Figure 6 This is a block diagram of an electronic device provided in one embodiment of this application. Detailed Implementation
[0026] The specific embodiments of this application will be described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are for illustration and explanation only and are not intended to limit this application.
[0027] It should be understood that the term "comprising" and its variations as used herein are open-ended, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the following description.
[0028] It should be noted that the concepts of "first" and "second" mentioned in this application are only used to distinguish different devices, modules, or units, and are not used to limit the order of functions performed by these devices, modules, or units or their interdependencies. The modifications of "one" and "multiple" mentioned in this application are illustrative rather than restrictive, and those skilled in the art should understand that, unless explicitly stated in the context, they should be understood as "one or more". In the description of this application, unless otherwise stated, "multiple" means two or more, and other quantifiers are similar; "at least one item", "one item or multiple items", or similar expressions refer to any combination of these items, including any combination of single or multiple items.
[0029] Although operations or steps are described in a specific order in the accompanying drawings in the embodiments of this application, this should not be construed as requiring these operations or steps to be performed in the specific order or serial order shown, or requiring all of the shown operations or steps to be performed to obtain the desired result. In the embodiments of this application, these operations or steps may be performed serially; they may be performed in parallel; or a portion of these operations or steps may be performed.
[0030] The names of the messages or information exchanged between multiple devices in the embodiments of this application are for illustrative purposes only and are not intended to limit the scope of these messages or information. It is understood that before using the technical solutions disclosed in the embodiments of this application, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this application in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.
[0031] First, the application scenario of this application will be explained. With the rapid development of cloud computing technology and the continuous expansion of data center scale, energy consumption has become a key challenge restricting the sustainable development of the industry. According to statistics, the annual power consumption of global data centers accounts for 1-2% of the total global power consumption, and this trend continues to grow. This phenomenon stems from the dynamic nature of cloud computing: virtual machines are requested and released in real time, and task execution time is determined by scheduling algorithms, but the actual usage time is entirely controlled by the user, making it difficult for the system to control the virtual machine usage cycle. Therefore, resource scheduling must ensure efficient task completion while also achieving energy conservation by shortening execution time.
[0032] Current cloud resource management methods primarily focus on optimizing single resource metrics (such as CPU or memory utilization) or triggering resource adjustments through preset fixed thresholds (such as CPU utilization). These methods lack dynamic adaptability and struggle to achieve multi-dimensional resource coordination. Single-metric decisions can easily lead to unbalanced resource allocation. When memory allocation is too high, even with low CPU utilization, the system may still experience a decline in memory swapping performance, affecting service stability. Using fixed threshold-triggered energy-saving mechanisms, on the other hand, cannot dynamically adjust based on actual load, resulting in low energy efficiency. For example, decisions based solely on CPU utilization may ignore idle memory resources, leading to energy waste.
[0033] In view of this, embodiments of this application provide a cloud resource pool energy-saving scheduling method, device, storage medium, and product. Based on multi-indicator collaborative decision-making, by establishing multi-dimensional dynamic baselines such as CPU / memory utilization, memory allocation rate, and number of hosts, and setting trigger conditions in the hibernation / wake-up logic and host number calculation logic, a precise balance between cloud resource pool resource utilization efficiency and energy consumption is achieved. The following description, in conjunction with specific embodiments, illustrates this application.
[0034] Figure 1 This is a flowchart illustrating a cloud resource pool energy-saving scheduling method provided in one embodiment of this application. Figure 1 As shown in the figure, this application provides a cloud resource pool energy-saving scheduling method, which may include the following steps: In step S10, the multi-dimensional cluster resource utilization indicators and the number of running host machines in the cloud resource pool are monitored.
[0035] For example, the multi-dimensional cluster resource utilization metrics of a cloud resource pool may include overall cluster CPU utilization, overall cluster memory utilization, and overall cluster memory allocation rate.
[0036] In step S20, a target baseline is established, which is used to define the target range of multi-dimensional cluster resource utilization indicators and the number of running host machines.
[0037] For example, by defining reasonable ranges for core cluster resource metrics, a benchmark coordinate system for dynamic resource adjustment can be constructed to ensure that cluster resource utilization remains within an elastic and scalable range after hibernation / wake-up operations. Based on cloud operating system maintenance experience and platform stability requirements, the target baseline... It can be obtained from the following formula: S= Formula 1 in, For the overall CPU utilization of the cluster, For the overall memory utilization of the cluster, For the overall memory allocation rate of the cluster, and The allowable deviation threshold, typically set to a certain value. , , This represents the number of running host machines.
[0038] Cluster resource pool C can be represented as ,in Indicates the first One host machine.
[0039] In step S30, if the multi-dimensional cluster resource utilization index and the number of running hosts meet all hibernation determination conditions, then the number of hibernating hosts is determined based on the minimum number of hibernating hosts required for each index of the multi-dimensional cluster resource utilization index and the number of running hosts to return to the target baseline, and the host hibernation operation is performed so that after hibernation, the cluster resource utilization and the number of running hosts return to the target baseline.
[0040] For example, the number of first hibernating hosts can be determined based on the current total number of CPU cores in the cluster, the overall CPU utilization of the cluster, and the maximum number of physical CPU cores that a single host in the cluster can currently provide. The first hibernating host number is the maximum number of hibernating hosts that can be hibernated within the target range of overall CPU utilization that brings the overall CPU utilization of the cluster back to the target baseline. The number of second hibernating hosts can be determined based on the current total memory capacity of the cluster, the overall memory utilization of the cluster, and the maximum memory capacity that a single host in the cluster can currently provide. The second hibernating host number is the maximum number of hibernating hosts that can be hibernating within the target range of overall memory utilization that brings the overall memory utilization of the cluster back to the target baseline. The number of third hibernating hosts can be determined based on the current total memory capacity of the cluster, the overall memory allocation rate of the cluster, and the maximum memory capacity that a single host in the cluster can currently provide. The third hibernating host number is the maximum number of hibernating hosts that can be hibernating within the target range of overall memory allocation rate that brings the overall memory allocation rate of the cluster back to the target baseline. The maximum number of hibernating hosts within the target range of the overall cluster memory allocation rate is determined by the difference between the number of hosts in the running state and the minimum threshold for the number of running hosts. The fourth hibernation host number is the maximum number of hibernating hosts within the target range that brings the number of hosts in the running state back to the target baseline. Then, the minimum value among the first, second, third, and fourth hibernation host numbers is taken as the number of hibernating hosts. Next, hosts in the running state are selected from the cloud resource pool. If there are no virtual machines on a host in the running state, the host in the running state is directly put into hibernation. If there are virtual machines on a host in the running state, the cluster resource scheduling policy is modified to migrate the load of the host in the running state and put it into hibernation, until the number of newly hibernating hosts reaches the number of hibernating hosts.
[0041] In step S40, if the multi-dimensional cluster resource utilization index meets any one of the wake-up determination conditions, the number of wakeable hosts is determined based on the maximum number of wakeable hosts required for each index in the multi-dimensional cluster resource utilization index to return to the target baseline, and the host wake-up operation is performed so that the cluster resource utilization returns to the target baseline after the wake-up is completed.
[0042] For example, the first number of wakeable hosts can be determined based on the current total number of CPU cores in the cluster, the overall CPU utilization of the cluster, and the minimum number of physical CPU cores that a single host in the cluster can provide. This first number of wakeable hosts is the minimum number of wakeable hosts required to bring the overall CPU utilization of the cluster back to the target range of the target baseline. Then, the second number of wakeable hosts can be determined based on the current total memory capacity of the cluster, the overall memory utilization of the cluster, and the minimum memory capacity that a single host in the cluster can provide. This second number of wakeable hosts is the minimum number of wakeable hosts required to bring the overall memory utilization of the cluster back to the target range of the target baseline. Based on the overall cluster memory allocation rate and the minimum memory capacity that a single host in the current cluster can provide, the number of third wake-up hosts is determined. The third wake-up host number is the minimum number of wake-up hosts required to bring the overall cluster memory allocation rate back to the target baseline within the target range. Then, the maximum value among the first, second, and third wake-up host numbers is taken as the number of wake-up hosts. Next, hosts in a dormant state are selected from the cloud resource pool, and wake-up actions are performed on the dormant hosts in sequence according to the number of wake-up hosts. After a dormant host is successfully woken up, the cluster resource scheduling policy is modified to reintegrate the resources of the newly woken-up host into the total cluster resource pool.
[0043] This application's embodiments monitor multi-dimensional cluster resource utilization indicators and the number of running hosts to establish a target baseline defining reasonable ranges for each indicator. When all hibernation criteria are met, a hibernation operation is performed based on the minimum number of hibernating hosts required for each indicator to return to the baseline, thus bringing resource utilization and host count back to the baseline. When any wake-up condition is met, a wake-up operation is performed based on the maximum number of wake-up hosts required for each indicator to return to the baseline, thus bringing resource utilization back to the baseline. This solution achieves multi-indicator collaborative decision-making and dynamic quantity calculation, overcoming the shortcomings of single-indicator or fixed-threshold methods. It can accurately balance resource utilization and energy consumption while ensuring business stability, avoiding excessive hibernation affecting services or insufficient wake-up leading to performance degradation, significantly improving the energy efficiency and automation management level of cloud data centers.
[0044] In one possible implementation, the multi-dimensional cluster resource utilization index may include: The overall CPU utilization of the cluster is calculated as the ratio of the currently used CPU resources to the total current CPU resources of the cluster. For example, the overall CPU utilization of the cluster... It can be obtained from the following formula: Formula 2 in, Indicates the first The amount of CPU resources already used by the host machine Indicates the first The total CPU resources of each host machine, where n is the total number of hosts in the cluster resource pool. Not zero.
[0045] The overall cluster memory utilization rate is calculated based on the ratio of currently used memory resources to the total current memory resources of the cluster. For example, the overall cluster memory utilization rate... It can be obtained from the following formula: Formula 3 in, Indicates the first The amount of memory resources already used by the host machine Indicates the first The total memory resources of each host machine, where n is the total number of host machines in the cluster resource pool. Not zero.
[0046] The overall cluster memory allocation rate is calculated based on the ratio of currently allocated memory resources to the total current memory resources of the cluster. For example, the overall cluster memory allocation rate... It can be obtained from the following formula: Formula 4 in, Indicates the first The amount of memory resources already allocated to each host machine. Indicates the first The total memory resources of each host machine, where n is the total number of host machines in the cluster resource pool. Not zero.
[0047] These three metrics depict the cluster's resource usage from different dimensions: CPU utilization reflects the processor's workload, memory utilization reflects actual memory usage, and memory allocation rate reflects the urgency of resource commitments. Combining these three metrics allows for a comprehensive assessment of the cluster's load and stress, providing a solid foundation for subsequent energy-saving decisions. The number of running hosts directly reflects the cluster's energy consumption base and scale.
[0048] In one possible implementation, the hibernation determination condition is that all of the following conditions are met simultaneously: The number of running host machines is greater than the preset minimum number of running host machines threshold.
[0049] The overall CPU utilization of the cluster has been below the first sleep threshold for several consecutive time periods.
[0050] The overall memory utilization of the cluster is lower than the second sleep threshold for several consecutive time periods, and the second sleep threshold is greater than the first sleep threshold.
[0051] For example, the design of the hibernation determination criteria balances security and effectiveness. First, it requires the number of running hosts to be greater than a preset minimum threshold (e.g., 5 hosts). This is to prevent hibernation in small clusters, which could leave the remaining hosts unable to provide basic high availability or fault tolerance. Second, it requires CPU utilization and memory utilization to be below their respective hibernation thresholds (e.g., 15% for the first hibernation threshold and 20% for the second) for multiple consecutive periods (e.g., 4 consecutive periods with 15-minute intervals). This consistent determination effectively filters out momentary fluctuations or short-term load troughs, preventing frequent hibernation due to misjudgments and impacting system stability. Specifically, the memory hibernation threshold is set higher than the CPU hibernation threshold to account for the unique characteristics of memory resources. Even with slightly higher utilization, memory can be optimized through scheduling, while a persistently low CPU utilization more clearly indicates excess computing resources.
[0052] Figure 2 This is a flowchart illustrating a cloud resource pool energy-saving scheduling method provided in one embodiment of this application. Figure 2 As shown, determining the number of hibernable hosts based on the minimum number of hibernating hosts required for each of the multi-dimensional cluster resource utilization indicators and the number of running hosts to regress to the target baseline may include the following steps: In step S301, the first number of hibernating hosts is determined based on the current total number of CPU cores in the cluster, the overall CPU utilization of the cluster, and the maximum number of physical CPU cores that a single host in the current cluster can provide. The first number of hibernating hosts is the maximum number of hibernating hosts that can make the overall CPU utilization of the cluster return to the target range of the overall CPU utilization of the cluster in the target baseline.
[0053] For example, the number of first hibernating hosts It can be obtained from the following formula: Formula 5 in, This indicates the current number of physical CPUs and the total number of cores in the cluster. This indicates the maximum number of physical CPU cores that a single host machine in the current cluster can provide; this value is not zero. This indicates rounding down to the nearest integer.
[0054] In step S302, the number of second hibernation hosts is determined based on the current total memory capacity of the cluster, the overall memory utilization rate of the cluster, and the maximum memory capacity that a single host in the current cluster can provide. The number of second hibernation hosts is the maximum number of hibernation hosts that can make the overall memory utilization rate of the cluster return to the target range of the overall memory utilization rate of the cluster in the target baseline.
[0055] For example, the number of second hibernation hosts It can be obtained from the following formula: Formula 6 in, This indicates the current total memory capacity of the cluster. This indicates the maximum memory capacity that a single host machine in the current cluster can provide; this value is not zero. This indicates rounding down to the nearest integer.
[0056] In step S303, the number of third hibernating hosts is determined based on the current total memory capacity of the cluster, the overall memory allocation rate of the cluster, and the maximum memory capacity that a single host in the current cluster can provide. The number of third hibernating hosts is the maximum number of hibernating hosts that can make the overall memory allocation rate of the cluster return to the target range of the overall memory allocation rate of the cluster in the target baseline.
[0057] For example, the number of third hibernation hosts It can be obtained from the following formula: Formula 7 In step S304, the fourth number of hibernating hosts is determined based on the difference between the number of hosts in the running state and the minimum number of running hosts threshold. The fourth number of hibernating hosts is the maximum number of hibernating hosts that can cause the number of hosts in the running state to return to the target range of the number of running hosts in the target baseline.
[0058] For example, the number of fourth hibernation hosts It can be obtained from the following formula: Formula 8 In step S305, the minimum value among the first number of hibernating host machines, the second number of hibernating host machines, the third number of hibernating host machines, and the fourth number of hibernating host machines is taken as the number of hibernating host machines.
[0059] In this step, the number of first hibernating host machines will be... Number of second hibernation host machines Number of third hibernation host machines And the number of fourth hibernation hosts The minimum value among them is used as the number of hibernating host machines. For example, the number of hibernating hosts. It can be obtained from the following formula: Formula 9 Where min is the function that takes the minimum value.
[0060] The calculation logic for the number of hibernation instances reflects the "bottleneck effect" and the principle of minimum intrusion. The system first calculates, based on the current total CPU resources, current CPU utilization, and the maximum CPU capacity of a single host, the theoretical maximum number of host machines that can be shut down to increase CPU utilization to the upper limit of the target range (e.g., 30%), denoted as N1. Similarly, N2 and N3 are calculated based on memory utilization and memory allocation rate, respectively. Simultaneously, based on the difference between the current number of running hosts and the minimum number of running hosts, the maximum number of hosts that can be shut down, N4, to meet the minimum host count requirement, is calculated. The final number of hibernation instances is the minimum value among N1, N2, N3, and N4. This means that any constraint in any resource dimension can become a bottleneck limiting the number of hibernation instances. For example, even if CPU utilization is very low, if the memory allocation rate is already close to the upper limit, then N3 will be very small, thus limiting the total number of hibernation instances. This prevents excessive memory allocation rates on remaining hosts due to host shutdowns, which could lead to virtual machine creation failures. This mechanism ensures that hibernation operations are always performed within safe resource boundaries.
[0061] Figure 3 This is a flowchart illustrating a cloud resource pool energy-saving scheduling method provided in one embodiment of this application. Figure 3 As shown, the process of performing a host machine hibernation operation may include the following steps: In step S306, host machines that are in operation are selected from the cloud resource pool.
[0062] In step S307, if there are no virtual machines on the running host machine, an attempt is made to directly put the running host machine into a hibernation state.
[0063] In step S308, if there are virtual machines on the running host, the cluster resource scheduling policy is modified to migrate the load of the running host and put it into hibernation until the number of newly hibernating hosts reaches the number of hibernating hosts.
[0064] For example, when performing a host hibernation operation, the system prioritizes idle hosts without virtual machines, putting them directly into hibernation—this is the ideal energy-saving scenario. For hosts hosting virtual machines, the system doesn't forcibly force hibernation. Instead, it first attempts to modify the cluster's resource scheduling strategy, such as setting DPM (Distributed Power Management) or DRS (Distributed Resource Scheduler) to a more aggressive migration mode, prompting the virtual machines on that host to migrate to other active hosts. Only after all virtual machines on that host have successfully migrated will the system put it into hibernation. This process is repeated until the total number of newly hibernating hosts reaches the previously calculated number of hibernable hosts. The entire process design fully considers business continuity, minimizing the impact on running services by migrating before hibernating.
[0065] In one possible implementation, the wake-up determination condition can be triggered if any of the following conditions are met: The overall CPU utilization of the cluster is greater than or equal to the first wake-up threshold.
[0066] The overall cluster memory utilization is greater than or equal to the second wake-up threshold.
[0067] The overall cluster memory allocation rate is greater than or equal to the third wake-up threshold, wherein the first wake-up threshold is less than the second wake-up threshold, and the second wake-up threshold is less than the third wake-up threshold.
[0068] For example, the wake-up decision uses an "OR" logic, meaning that the system will immediately trigger a wake-up if any one of the three parameters—CPU utilization, memory utilization, or memory allocation rate—exceeds its corresponding wake-up threshold. This design contrasts sharply with the "AND" logic of the hibernation logic, reflecting the principle of "rapid response to risks." Regarding the threshold values, the CPU wake-up threshold (e.g., the first wake-up threshold of 45%) is set the lowest, followed by the memory utilization wake-up threshold (e.g., the second wake-up threshold of 70%), and the memory allocation rate wake-up threshold (e.g., the third wake-up threshold of 95%) is the highest. This is because CPU stress typically affects computing performance and requires a fast response; memory utilization stress affects operational performance and also needs attention; while a memory allocation rate approaching its upper limit means resources are about to be exhausted, potentially impacting new service deployments—one of the most severe states. Once any threshold is triggered, the system must act immediately.
[0069] Figure 4 This is a flowchart illustrating a cloud resource pool energy-saving scheduling method provided in one embodiment of this application. Figure 4As shown, determining the number of wakeable hosts based on the maximum number of wakeable hosts required for each indicator in the multi-dimensional cluster resource utilization metrics to regress to the target baseline may include the following steps: In step S401, the first number of wakeable hosts is determined based on the current total number of CPU cores in the cluster, the overall CPU utilization of the cluster, and the minimum number of physical CPU cores that a single host in the current cluster can provide. The first number of wakeable hosts is the minimum number of wakeable hosts required to bring the overall CPU utilization of the cluster back to the target range of the overall CPU utilization of the cluster in the target baseline.
[0070] For example, the first number of wakeable host machines It can be obtained from the following formula: Formula 10 in, This indicates the minimum number of physical CPU cores that a single host machine in the current cluster can provide; this value is not zero. This indicates rounding up to the nearest integer.
[0071] In step S402, based on the current total memory capacity of the cluster, the overall memory utilization rate of the cluster, and the minimum memory capacity that a single host machine in the current cluster can provide, the second number of wakeable hosts is determined. The second number of wakeable hosts is the minimum number of wakeable hosts required to bring the overall memory utilization rate of the cluster back to the target range of the overall memory utilization rate of the cluster in the target baseline.
[0072] For example, the second number of wakeable host machines It can be obtained from the following formula: Formula 11 in, This indicates the minimum memory capacity that a single host machine in the current cluster can provide; this value is not zero. This indicates rounding up to the nearest integer.
[0073] In step S403, based on the current total memory capacity of the cluster, the overall memory allocation rate of the cluster, and the minimum memory capacity that a single host in the current cluster can provide, the number of third wake-up hosts is determined. The number of third wake-up hosts is the minimum number of wake-up hosts required to bring the overall memory allocation rate of the cluster back to the target range of the overall memory allocation rate of the cluster in the target baseline.
[0074] For example, the third number of wakeable host machines It can be obtained from the following formula: Formula 12 In step S404, the maximum value among the first number of wakeable host machines, the second number of wakeable host machines, and the third number of wakeable host machines is taken as the number of wakeable host machines.
[0075] In this step, the number of the first wakeable host machines will be... Second, the number of host machines that can be woken up. And the number of third-party wake-up host machines The maximum value in the range is used as the number of host machines that can be woken up. For example, the number of host machines that can be woken up. It can be obtained from the following formula: Formula 13 Where max is the function for finding the maximum value.
[0076] The calculation logic for the number of wake-up requests follows the "maximum value" principle, prioritizing the resolution of the most pressing resource conflicts. Based on the current total CPU resources, current CPU utilization, and the minimum CPU capacity of a single host machine, the system calculates the minimum number of host machines that need to be woken up to reduce CPU utilization to the lower limit of the target range (e.g., 30%), denoted as N1'. Similarly, N2' and N3' are calculated based on memory utilization and memory allocation rates, respectively. The final number of wake-up requests is the maximum value among N1', N2', and N3'. For example, if memory utilization pressure is high, requiring 10 wake-ups to alleviate the problem, while CPU pressure is low, requiring only 1 wake-up request, the system will ultimately choose to wake up 10 machines. This ensures that the wake-up action satisfies the most critical resource needs in one go, preventing repeated triggering of problems due to insufficient wake-up requests and guaranteeing smooth business operation.
[0077] Figure 5 This is a flowchart illustrating a cloud resource pool energy-saving scheduling method provided in one embodiment of this application. Figure 5 As shown, the host machine wake-up operation may include the following steps: In step S405, host machines in a dormant state are selected from the cloud resource pool.
[0078] In step S406, the wake-up actions are performed on the host machines in hibernation state in sequence according to the number of host machines that can be woken up.
[0079] In step S407, after the host machine in the dormant state is successfully woken up, the cluster resource scheduling policy is modified to re-include the resources of the newly woken-up host machine into the total cluster resource pool.
[0080] For example, when performing a host wake-up operation, the system will wake up hosts from a pre-marked list of dormant hosts in a predetermined order (e.g., those with larger resource capacity are prioritized). Each successfully woken-up host's computing and memory resources are added back to the cluster's total resource pool. Subsequently, the system modifies the cluster's resource scheduling policy, such as setting DRS to load balancing mode, so that newly woken-up hosts can actively attract or passively allocate a portion of the virtual machine load, thereby distributing the pressure. This process continues until the number of woken-up hosts reaches the calculated number of waking-up hosts. This process ensures that resources can be smoothly and orderly redeployed into production, quickly responding to the demands of business growth.
[0081] In summary, this application's embodiments achieve a precise balance between cloud resource pool resource utilization efficiency and energy consumption by establishing a multi-dimensional resource target baseline and employing a collaborative decision-making mechanism that triggers hibernation using "AND" logic and wake-up using "OR" logic, combined with a method for dynamically calculating the number of hibernation / wake-up events based on multi-dimensional indicators. Taking the minimum value during hibernation ensures operational security and avoids the impact of excessive energy saving on business operations; taking the maximum value during wake-up ensures sufficient response and can quickly resolve resource bottlenecks. The entire solution overcomes the shortcomings of traditional single-indicator, fixed-threshold methods, improving the energy efficiency and automation management level of cloud data centers.
[0082] Figure 6 This is a block diagram of an electronic device provided in one embodiment of this application. For example... Figure 6 As shown, the electronic device 600 may include a processor 601 and a memory 602. The electronic device 600 may also include one or more of a multimedia component 603, an input / output (I / O) interface 604, and a communication component 605.
[0083] The processor 601 controls the overall operation of the electronic device 600 to complete all or part of the steps in the cloud resource pool energy-saving scheduling method described above. The memory 602 stores various types of data to support the operation of the electronic device 600. This data may include, for example, instructions for any application or method operating on the electronic device 600, and application-related data such as contact data, sent and received messages, pictures, audio, video, etc. The memory 602 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, disk, or optical disk. The multimedia component 603 may include a screen and audio components. The screen may be, for example, a touchscreen, and the audio component is used to output and / or input audio signals. For example, the audio component may include a microphone for receiving external audio signals. The received audio signals may be further stored in memory 602 or transmitted via communication component 605. The audio component also includes at least one speaker for outputting audio signals. I / O interface 604 provides an interface between processor 601 and other interface modules, such as a keyboard, mouse, buttons, etc. These buttons may be virtual or physical buttons. Communication component 605 is used for wired or wireless communication between the electronic device 600 and other devices. Wireless communication, such as Wi-Fi, Bluetooth, Near Field Communication (NFC), 2G, 3G, 4G, NB-IoT, eMTC, or other 5G technologies, or combinations thereof, is not limited here. Therefore, the corresponding communication component 605 may include: a Wi-Fi module, a Bluetooth module, an NFC module, etc.
[0084] In an exemplary embodiment, the electronic device 600 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to execute the cloud resource pool energy-saving scheduling method described above.
[0085] In another exemplary embodiment, a computer-readable storage medium including program instructions is also provided, which, when executed by a processor, implement the steps of the cloud resource pool energy-saving scheduling method described above. For example, the computer-readable storage medium may be the memory 602 including the program instructions described above, which may be executed by the processor 601 of the electronic device 600 to complete the cloud resource pool energy-saving scheduling method described above.
[0086] In another exemplary embodiment, a computer program product is also provided, the computer program product comprising a computer program executable by a programmable device, the computer program having a code portion for performing the cloud resource pool energy-saving scheduling method described above when executed by the programmable device.
[0087] The preferred embodiments of this application have been described in detail above with reference to the accompanying drawings. However, this application is not limited to the specific details of the above embodiments. Within the scope of the technical concept of this application, various simple modifications can be made to the technical solution of this application, and these simple modifications all fall within the protection scope of this application.
[0088] It should also be noted that the various specific technical features described in the above embodiments can be combined in any suitable manner without contradiction. In order to avoid unnecessary repetition, this application will not describe the various possible combinations separately.
[0089] Furthermore, various different implementations of this application can be combined in any way, as long as they do not violate the spirit of this application, they should also be regarded as the content disclosed in this application.
Claims
1. A cloud resource pool energy-saving scheduling method, characterized in that, The method includes: Monitor multi-dimensional cluster resource utilization indicators and the number of running host machines in the cloud resource pool; Establish a target baseline, which is used to define the target range for multi-dimensional cluster resource utilization indicators and the number of running host machines; If the multi-dimensional cluster resource utilization index and the number of running hosts meet all hibernation criteria, then the number of hibernating hosts is determined based on the minimum number of hibernating hosts required for each of the multi-dimensional cluster resource utilization index and the number of running hosts to return to the target baseline, and a host hibernation operation is performed so that after hibernation, the cluster resource utilization and the number of running hosts return to the target baseline; or, If any of the multi-dimensional cluster resource utilization indicators meet any wake-up determination conditions, then the number of host machines that can be woken up is determined based on the maximum number of host machines required for each indicator in the multi-dimensional cluster resource utilization indicators to return to the target baseline, and the host machine wake-up operation is performed so that the cluster resource utilization returns to the target baseline after the wake-up is completed.
2. The method according to claim 1, characterized in that, The multi-dimensional cluster resource utilization metrics include: The overall CPU utilization of the cluster is obtained based on the ratio of the amount of CPU resources currently used by the cluster to the total amount of CPU resources currently used by the cluster. The overall memory utilization rate of the cluster is obtained based on the ratio of the amount of memory resources currently used by the cluster to the total memory resources of the cluster. The overall cluster memory allocation rate is obtained based on the ratio of the currently allocated memory resources to the current total memory resources of the cluster.
3. The method according to claim 2, characterized in that, The hibernation determination condition is that all of the following conditions are met simultaneously: The number of running host machines exceeds the preset minimum number of running host machines threshold; The overall CPU utilization of the cluster has been below the first sleep threshold for several consecutive time periods. The overall memory utilization of the cluster is lower than the second sleep threshold for several consecutive time periods, and the second sleep threshold is greater than the first sleep threshold.
4. The method according to claim 3, characterized in that, The determination of the number of hibernable hosts based on the minimum number of hibernating hosts required for each of the multi-dimensional cluster resource utilization indicators and the number of running hosts to regress to the target baseline includes: Based on the current total number of CPU cores in the cluster, the overall CPU utilization of the cluster, and the maximum number of physical CPU cores that a single host in the current cluster can provide, the first number of hibernating hosts is determined. The first number of hibernating hosts is the maximum number of hibernating hosts that can make the overall CPU utilization of the cluster return to the target range of the overall CPU utilization of the cluster in the target baseline. Based on the current total memory capacity of the cluster, the overall memory utilization of the cluster, and the maximum memory capacity that a single host machine in the current cluster can provide, the second number of hibernating hosts is determined. The second number of hibernating hosts is the maximum number of hibernating hosts that can make the overall memory utilization of the cluster return to the target range of the overall memory utilization of the cluster in the target baseline. Based on the current total memory capacity of the cluster, the overall memory allocation rate of the cluster, and the maximum memory capacity that a single host machine in the current cluster can provide, the number of third hibernating hosts is determined. The number of third hibernating hosts is the maximum number of hibernating hosts that can make the overall memory allocation rate of the cluster return to the target range of the overall memory allocation rate of the cluster in the target baseline. The fourth number of hibernating hosts is determined based on the difference between the number of hosts in the cluster that are in running state and the minimum number of running hosts threshold. The fourth number of hibernating hosts is the maximum number of hibernating hosts that can be hibernated within the target range that makes the number of hosts in the running state return to the number of running hosts in the target baseline. The minimum value among the first number of hibernating host machines, the second number of hibernating host machines, the third number of hibernating host machines, and the fourth number of hibernating host machines shall be taken as the number of hibernating host machines.
5. The method according to claim 4, characterized in that, The execution of the host machine hibernation operation includes: Select running host machines from the cloud resource pool; If there are no virtual machines on the running host machine, then attempt to put the running host machine into hibernation mode directly; If there are virtual machines on the running host, then attempt to modify the cluster resource scheduling policy to cause the running host to migrate its load and enter a hibernation state, until the number of newly hibernating host machines reaches the number of hibernating host machines.
6. The method according to claim 2, characterized in that, The wake-up determination condition can be triggered if any of the following conditions are met: The overall CPU utilization of the cluster is greater than or equal to the first wake-up threshold; The overall cluster memory utilization is greater than or equal to the second wake-up threshold; The overall cluster memory allocation rate is greater than or equal to the third wake-up threshold, wherein the first wake-up threshold is less than the second wake-up threshold, and the second wake-up threshold is less than the third wake-up threshold.
7. The method according to claim 6, characterized in that, The determination of the number of wakeable hosts based on the maximum number of host machines required for each indicator in the multi-dimensional cluster resource utilization metrics to regress to the target baseline includes: Based on the current total number of CPU cores in the cluster, the overall CPU utilization of the cluster, and the minimum number of physical CPU cores that a single host in the current cluster can provide, the first number of wakeable hosts is determined. The first number of wakeable hosts is the minimum number of wakeable hosts that makes the overall CPU utilization of the cluster return to the target range of the overall CPU utilization of the cluster in the target baseline. Based on the current total memory capacity of the cluster, the overall memory utilization rate of the cluster, and the minimum memory capacity that a single host machine in the current cluster can provide, the second number of wakeable hosts is determined. The second number of wakeable hosts is the minimum number of wakeable hosts that makes the overall memory utilization rate of the cluster return to the target range of the overall memory utilization rate of the cluster in the target baseline. Based on the current total memory capacity of the cluster, the overall memory allocation rate of the cluster, and the minimum memory capacity that a single host machine in the current cluster can provide, the number of third wake-up hosts is determined. The number of third wake-up hosts is the minimum number of wake-up hosts that makes the overall memory allocation rate of the cluster return to the target range of the overall memory allocation rate of the cluster in the target baseline. The maximum value among the first number of wakeable host machines, the second number of wakeable host machines, and the third number of wakeable host machines is taken as the number of wakeable host machines.
8. The method according to claim 7, characterized in that, The execution of the host machine wake-up operation includes: Select host machines that are in a dormant state from the cloud resource pool; According to the number of host machines that can be woken up, the wake-up actions are performed on the host machines that are in a dormant state in sequence; After the host machine in a dormant state is successfully woken up, the cluster resource scheduling policy is modified to include the newly woken-up host machine resources back into the cluster's total resource pool.
9. An electronic device, characterized in that, include: A memory on which computer programs are stored; A processor for executing the computer program in the memory to implement the steps of the method according to any one of claims 1-8.
10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1-8.