A method and system for distributing computing power of a cloud computing power cluster

Abstract

This invention relates to the field of resource allocation technology, specifically to a method and system for allocating computing power in a cloud computing cluster. It solves the technical problem of low computing power allocation efficiency in existing technologies due to the inability of static quotas to adapt to task changes and node fluctuations. The method includes: acquiring resource status data for each node and historical execution data corresponding to the tasks to be allocated; analyzing the impact of resource utilization changes on execution latency and the proximity of resource utilization to resource saturation, and determining the demand weight of each type of resource for the tasks to be allocated based on the occupancy; screening candidate nodes, determining the comprehensive matching degree between the tasks to be allocated and each candidate node based on the demand weight and resource status data; determining an allocation decision score based on the comprehensive matching degree, the priority of the tasks to be allocated, and the resource status data, and determining the execution node for the tasks to be allocated from the candidate nodes based on the allocation decision score.

Description

Technical Field

[0001] This invention relates to the field of resource allocation technology, specifically to a method and system for allocating computing power in a cloud computing cluster. Background Technology

[0002] Cloud computing clusters are built on cloud computing infrastructure and consist of a large number of high-performance physical servers, virtualized nodes, and high-speed network interconnection. Through a distributed scheduling and unified management platform, they integrate various heterogeneous computing resources such as central processing units (CPUs), graphics processing units (GPUs), and neural network processing units (NPUs) to form a large-scale computing pool with elastic expansion and on-demand allocation capabilities. This provides unified computing support and operating environment for various high-computing tasks such as artificial intelligence training, big data analysis, scientific simulation, and real-time business inference. It enables multiple tasks and users to share computing resources and perform efficient collaborative execution, and is the core computing infrastructure supporting large-scale digital and intelligent applications.

[0003] Most current cloud computing clusters use scheduling modes based on static quotas or simple load thresholds. Typically, administrators pre-allocate fixed proportions of CPU, GPU, memory, and network resources to different services, tenants, or tasks. After a task is submitted, it is queued and scheduled according to a first-come, first-served or fixed priority rule. Some systems only perform simple load balancing based on a single indicator such as real-time CPU utilization and memory usage of nodes, and only trigger task waiting or cross-node migration when node resources are exhausted.

[0004] Because the cluster aggregates massive heterogeneous computing resources and serves multiple users and multiple tasks concurrently, various tasks have significant differences in computing power requirements, execution cycles, priorities, and resource dependencies. Static quotas and fixed priority rules are unable to perceive the bottleneck sensitivity of tasks to specific resources, and real-time fluctuations in node load cannot be effectively absorbed by a single indicator balancing strategy. This leads to disordered resource contention, load imbalance, local node overload, and overall resource idleness. Resource contention and inaccurate computing power measurement in a multi-tenant shared environment further exacerbate cluster performance loss. Summary of the Invention

[0005] To address the technical problem of low computing power allocation efficiency caused by the inability of existing technologies to adapt to task changes and node fluctuations due to static quotas, the present invention aims to provide a computing power allocation method and system for cloud computing clusters. The specific technical solution adopted is as follows: Firstly, a method for allocating computing power in a cloud computing cluster is provided, comprising: acquiring resource status data of each node in the cloud computing cluster and historical execution data corresponding to the tasks to be allocated; the historical execution data includes the occupancy, resource utilization rate, and execution latency of each type of resource in multiple historical executions of the tasks to be allocated; analyzing the impact of changes in the resource utilization rate of each type of resource on the execution latency, as well as the closeness of the resource utilization rate to the resource saturation state, and determining the demand weight of each type of resource for the tasks to be allocated based on the occupancy of each type of resource; filtering candidate nodes whose remaining amount of each type of resource is greater than or equal to the resource demand of the tasks to be allocated based on the resource status data of each node, and determining the comprehensive matching degree between the tasks to be allocated and each candidate node based on the demand weight and the resource status data of each candidate node; determining the allocation decision score based on the comprehensive matching degree, the priority of the tasks to be allocated, and the resource status data of each candidate node, and determining the execution node of the tasks to be allocated from the candidate nodes based on the allocation decision score.

[0006] Based on the above technical solution, in the cloud computing cluster computing power allocation method provided by this invention, by comprehensively considering the impact of changes in resource utilization on execution latency in historical execution data and the proximity of resource utilization to resource saturation, combined with resource occupancy, a demand weight is generated for the tasks to be allocated, reflecting their dependence on and sensitivity to each type of resource. This transforms the characterization of task resource requirements from a static declaration to a dynamically perceived, real dependency. On this basis, candidate nodes with sufficient resources are selected from the cluster nodes, and the node resource status is weighted and matched using the demand weight to obtain a comprehensive matching degree. This upgrades the task-node matching from a simple comparison of resource availability to a precise matching deeply coupled with the sensitive characteristics of the task. In the final decision-making process, the comprehensive matching degree, task priority, and node resource status are integrated to determine the execution node under multi-objective collaboration, thereby simultaneously improving resource utilization, ensuring the service quality of high-priority tasks, and suppressing uneven node load at the global level.

[0007] In conjunction with the first aspect mentioned above, in one possible implementation, the method of analyzing the impact of changes in the resource utilization rate of each type of resource on execution latency in historical execution data, as well as the degree of proximity between the resource utilization rate and the resource saturation state, and determining the demand weight of each type of resource for the task to be assigned, in conjunction with the occupancy of each type of resource, specifically includes: analyzing the trend of execution latency changes with the resource utilization rate of each type of resource in each historical execution to determine the degree of impact corresponding to each type of resource; determining the degree of proximity corresponding to each type of resource in each historical execution based on the resource utilization rate of each type of resource in each historical execution; determining the resource sensitivity factor of each type of resource in each historical execution based on the degree of impact and the degree of proximity; converting the occupancy of each type of resource in each historical execution into a resource occupancy ratio, and performing a weighted average of the resource occupancy ratio of each type of resource in multiple historical executions based on the resource sensitivity factor to obtain the demand weight of each type of resource for the task to be assigned.

[0008] In conjunction with the first aspect mentioned above, in one possible implementation, the method further includes: extracting the resource utilization rate and corresponding execution delay of the task to be assigned from historical execution data where the resource utilization rate is greater than a preset utilization rate threshold in each historical execution, and using the extracted resource utilization rate and execution delay to analyze the degree of impact and proximity.

[0009] In conjunction with the first aspect mentioned above, in one possible implementation, after the tasks to be assigned are completed, the method further includes: obtaining the occupancy, resource utilization rate, and execution delay of each type of resource in this execution; determining the resource sensitivity factor in this execution based on the resource utilization rate and execution delay of each type of resource in this execution; and correcting the demand weight using an exponentially weighted moving average method based on the resource sensitivity factor and resource occupancy ratio in this execution, and using the corrected value as the demand weight for the next scheduling.

[0010] In conjunction with the first aspect above, in one possible implementation, the method for determining the comprehensive matching degree between the task to be assigned and each candidate node based on the demand weight and the resource status data of each candidate node specifically includes: extracting the total capacity, remaining quantity, and occupied quantity of each type of resource from the resource status data of each candidate node; using the ratio of the remaining quantity of each type of resource to the total capacity of the candidate node as the relative abundance of each type of resource; using the demand weight of the task to be assigned for each type of resource as the weight, weighting and summing the relative abundance to obtain the initial matching degree; using the ratio of the occupied quantity of each type of resource to the total capacity of the candidate node as the resource utilization degree of each type of resource, and averaging the resource utilization degrees of multiple types of resources to obtain the load pressure factor of the candidate node; and determining the comprehensive matching degree based on the initial matching degree and the load pressure factor.

[0011] In conjunction with the first aspect above, in one possible implementation, the method for determining the allocation decision score based on the comprehensive matching degree, the priority of the task to be assigned, and the resource status data of each candidate node specifically includes: extracting the total capacity and remaining amount of multiple types of resources from the resource status data of each candidate node; determining the resource remaining ratio of the candidate node based on the ratio of the remaining amount of multiple types of resources to the total capacity; and determining the allocation decision score of the candidate node based on the comprehensive matching degree, priority, and resource remaining ratio.

[0012] In conjunction with the first aspect above, in one possible implementation, the method for determining the priority of a task to be assigned specifically includes: obtaining the preset service level, waiting time, and expected completion time of the task to be assigned; using the ratio of the waiting time to the expected completion time of the task to be assigned as the time urgency of the task to be assigned; and determining the priority of the task to be assigned based on the time urgency of the task to be assigned and the preset service level.

[0013] In conjunction with the first aspect above, in one possible implementation, the method for determining the execution node of the task to be assigned from the candidate nodes based on the allocation decision score specifically includes: selecting the candidate node with the highest allocation decision score as the execution node of the task to be assigned.

[0014] In conjunction with the first aspect above, in one possible implementation, the method further includes: if there are no candidate nodes among the multiple nodes of the cloud computing power cluster, the task to be assigned is inserted into the priority waiting queue until the resource status data of each node is re-acquired in a subsequent scheduling cycle to filter and obtain candidate nodes.

[0015] Secondly, a computing power allocation system for a cloud computing power cluster is provided, comprising: a data acquisition module, used to acquire resource status data of each node in the cloud computing power cluster and historical execution data corresponding to the tasks to be allocated; the historical execution data includes the occupancy, resource utilization rate, and execution latency of each type of resource in multiple historical executions of the tasks to be allocated; a demand analysis module, used to analyze the impact of changes in the resource utilization rate of each type of resource on the execution latency in the historical execution data, as well as the closeness of the resource utilization rate to the resource saturation state, and determine the demand weight of the tasks to be allocated for each type of resource in combination with the occupancy of each type of resource; a resource matching module, used to filter candidate nodes whose remaining amount of each type of resource is greater than or equal to the resource demand of the tasks to be allocated based on the resource status data of each node, and determine the comprehensive matching degree between the tasks to be allocated and each candidate node based on the demand weight and the resource status data of each candidate node; and a node scheduling module, used to determine the allocation decision score based on the comprehensive matching degree, the priority of the tasks to be allocated, and the resource status data of each candidate node, and determine the execution node of the tasks to be allocated from the candidate nodes based on the allocation decision score.

[0016] The present invention has the following beneficial effects: By comprehensively analyzing the impact of changes in resource utilization on execution latency in historical execution data, as well as the proximity of resource utilization to resource saturation, and combining this with resource occupancy, a demand weight is generated for each task to be assigned. This weight reflects the intensity and sensitivity of the task's dependence on each type of resource, transforming the characterization of task resource requirements from a static declaration to a dynamically perceived, realistic dependency. Based on this, candidate nodes with sufficient resources are selected from the cluster nodes, and the node resource status is weighted and matched using the demand weights to obtain a comprehensive matching degree. This upgrades the task-node matching from a simple comparison of resource availability to a precise matching deeply coupled with the task's sensitive characteristics. The final decision-making process integrates the comprehensive matching degree, task priority, and node resource status to determine the execution node under multi-objective collaboration. This simultaneously improves resource utilization at the global level, ensures the service quality of high-priority tasks, and suppresses uneven node load. Attached Figure Description

[0017] Figure 1 This is a system architecture diagram of a computing power allocation system for a cloud computing power cluster provided in one embodiment of the present invention; Figure 2 This is a flowchart illustrating a method for allocating computing power in a cloud computing cluster, as provided in one embodiment of the present invention. Detailed Implementation

[0018] The following description, in conjunction with the accompanying drawings, details the specific scheme of the computing power allocation method and system for a cloud computing power cluster provided by the present invention.

[0019] Please see Figure 1 The diagram illustrates a system architecture of a cloud computing power cluster computing power allocation system according to an embodiment of the present invention. The cloud computing power cluster computing power allocation system includes: a data acquisition module 1, a demand analysis module 2, a resource matching module 3, and a node scheduling module 4.

[0020] Optionally, the computing power allocation system of this cloud computing cluster is also equipped with a task queuing management module 5 and an iterative optimization module 6.

[0021] The data acquisition module 1 consists of a lightweight acquisition agent deployed on all physical servers and virtualized nodes within the cluster, and a data transceiver service deployed at the central management terminal. The acquisition agent uses the Linux system kernel reading interface, GPU-specific monitoring development components, and container runtime interface to collect node hardware metrics. Based on the collected underlying raw parameters such as CPU time, memory capacity, and GPU activity cycles, it calculates the resource utilization rate of various resources. The collected data is pushed to the message bus middleware via a dedicated transmission protocol. The central data transceiver service is additionally equipped with an active pull mechanism to avoid data loss due to acquisition agent anomalies. The collected raw data is uniformly stored in a time-series database and a columnar data warehouse. This module is mainly responsible for summarizing the resource status data of each node in the cluster, as well as the historical execution data of the entire lifecycle of tasks to be assigned. The historical execution data uniformly includes the resource consumption, resource utilization rate, and execution latency information of each task run. The standardized data stored by this module is pushed in full to the requirements analysis module 2, which is the sole data source for the requirements analysis module to perform various parameter calculations.

[0022] The requirements analysis module 2 is implemented as an independent container process running on the central scheduling server. This process can directly connect to the database associated with the data acquisition module 1, retrieving complete historical execution data at any time. Based on the retrieved data, this module quantitatively analyzes the impact of resource utilization fluctuations on task execution latency, the proximity of resource utilization to hardware resource saturation thresholds, and calculates resource sensitivity factors for each type of resource based on these two sets of indicators. Then, it combines historical resource usage data with weighted calculations to obtain the task's requirement weight for each type of resource. The final requirement weights generated by this module are fully synchronized to the resource matching module 3, serving as the core weight parameters for calculating the task-node compatibility.

[0023] Resource matching module 3 is built on a distributed parallel computing service within the cluster management server. This service can simultaneously access two types of data: node resource status data synchronized by data acquisition module 1 and demand weights output by demand analysis module 2. This module first uses the node resource status data to filter candidate nodes whose remaining resource quantities can meet the task's resource consumption requirements. Then, it breaks down the candidate nodes' total resource capacity, remaining resources, and occupied resources, calculating the relative resource abundance and overall node load pressure factor. Finally, it uses demand weights to calculate the comprehensive matching degree between the task and each candidate node. The comprehensive matching degree data produced by this module is directly sent to node scheduling module 4, providing crucial computational basis for calculating allocation decision scores.

[0024] The node scheduling module 4 is deployed within the cluster's main scheduling physical server. The scheduling service continuously receives the comprehensive matching results from the resource matching module 3, while simultaneously retrieving real-time updated node resource status data from the data acquisition module 1. This module breaks down the total resource capacity and remaining resource value of candidate nodes to obtain the resource remaining ratio. It then combines this with pre-calculated task priority, comprehensive matching degree, and resource remaining ratio to calculate an allocation decision score, selecting the candidate node with the highest score as the task execution node. The final scheduling result generated by this module is distributed to the corresponding node to initiate task deployment, and simultaneously distributed to the task queuing management module 5 and the iterative optimization module 6 to support abnormal task management and subsequent parameter iterative optimization.

[0025] The task queuing management module 5 is built on a distributed memory queue and message middleware to create an operational environment that receives candidate node screening results pushed by the node scheduling module 4 in real time. When the resource matching module 3 cannot find compliant candidate nodes, this module takes over tasks that cannot be assigned temporarily and generates a waiting queue according to task priority. It continuously and periodically pulls node resource data updated in real time by the data acquisition module 1, and works with the resource matching module 3 to re-screen candidate nodes in the next scheduling cycle. Once the tasks in the queue meet the resource allocation conditions, this module sends the task information back to the node scheduling module 4 to re-assign and score the tasks.

[0026] The iterative optimization module 6 constructs a data processing service based on a columnar data warehouse and a time-series database, continuously receiving task start and execution notifications from the node scheduling module 4. After the task execution is completed, it retrieves the resource consumption, resource utilization, and execution latency data generated during the actual task execution. Based on the measured data, it recalculates the resource sensitivity factor corresponding to a single task and corrects the original demand weights using an exponentially weighted moving average. The optimized and updated demand weights are then fed back to the demand analysis module 2, replacing the original parameters for subsequent new task weight calculations, thus achieving adaptive iterative optimization of system parameters.

[0027] Please see Figure 2 The diagram illustrates a flowchart of a cloud computing power cluster computing power allocation method according to an embodiment of the present invention. The cloud computing power cluster computing power allocation method includes: S1. Obtain the resource status data of each node in the cloud computing cluster and the historical execution data corresponding to the tasks to be assigned.

[0028] Resource status data is a collection of information characterizing the availability and occupancy of various computing resources for each physical or virtual node in the cluster at the current moment. It serves as the real-time basis for the scheduler's node selection and matching decisions. Historical execution data is a collection of information recording the actual resource consumption characteristics and performance of tasks to be assigned over multiple runs, including the resource occupancy, resource utilization, and execution latency of each type of resource in multiple historical executions. Occupancy reflects the actual amount of various resources consumed during task execution; resource utilization reflects the proportion of various resources occupied during task execution; and execution latency reflects the duration of phased processing from task submission to completion or execution. By simultaneously acquiring the real-time status of nodes and the historical execution profile of tasks, the scheduler can integrate the dynamically changing cluster supply capacity and the inherent resource dependency characteristics of tasks into subsequent comprehensive analysis, thereby providing a complete data foundation for accurate scheduling decisions.

[0029] In some implementations, the specific process of acquiring resource status data for each node includes: deploying a lightweight data acquisition agent on each node of the cloud computing cluster; the agent polls the node's operating system kernel interface and hardware management library at preset intervals to extract real-time status information for at least one type of resource, including CPU utilization, GPU memory and computing power reserve, memory usage, and network bandwidth load; and simultaneously interacts with the container runtime interface to obtain resource usage details for each container to determine the occupied amount of each type of resource. The preset acquisition interval is typically set to 1 second to strike a balance between data real-time performance and acquisition overhead. The acquisition agent formats the acquired status data into structured messages and pushes them to the central scheduler's data bus via a high-performance communication protocol. It also supports a backup mode where the scheduler actively pulls the data to prevent data loss due to agent failure. After receiving data reported by each node, the scheduler performs outlier filtering and timestamp alignment. First, a median filter with a window size of 3 is used to smooth the collected data, eliminating isolated outliers caused by instantaneous sampling jitter. To avoid filtering out real load fluctuations, if indicators show significant changes in the same direction for multiple consecutive sampling periods (i.e., continuously exceeding a preset mutation threshold), they are considered real load changes, and the original values ​​are retained without smoothing. After denoising, the local timestamps carried by all reported data are aligned according to a preset aggregation window. For example, the average value of each indicator is calculated using the past 5 seconds as a window, serving as the real-time resource status data for that node. The preset mutation threshold is based on offline calibration and online correction of task load characteristics. For typical task types in the cluster (such as online inference and offline training), different levels of load pressure are pre-injected into the test environment to calibrate the minimum rate and magnitude of increase in various resource utilization rates during real load increases. The lower percentile value of the calibration results is used as the initial mutation threshold. Meanwhile, during online operation, events that are confirmed as real load mutations after filtering are continuously collected, their change amplitude distribution is fitted, and the threshold is periodically adjusted using an exponential moving average method so that the threshold adapts to the evolution of the cluster operation mode.

[0030] The specific process of obtaining historical execution data corresponding to tasks to be assigned includes: When a user submits a task through a command-line interface or application programming interface, the system provides a structured description template and receives the user's declared resource requirements, task type, and service level. If the user does not provide a complete declaration, the system supplements it with preset default values, such as a default value for computational load of 1000 million floating-point operations per second multiplied by seconds, and a default value for memory of 1 gigabyte. After the task starts execution, the collection agent on the node continuously collects real-time statistics on the task's consumption of various resources through the control group mechanism, including cumulative CPU usage time, resident memory size, and GPU memory usage. After the task finishes running, it calculates the actual computational load based on CPU time, processor frequency, and the number of allocated cores, which is taken as the actual resource usage for this execution. At the same time, the resource utilization rate is collected and recorded in the monitoring log by the monitoring agent deployed on the node at preset sampling intervals (e.g., 1 second) during task execution, and the execution latency is calculated based on the timestamp of the request and completion of the task processing phase. After a task finishes execution, the time series of resource utilization and corresponding execution latency observations during the execution process are extracted from the monitoring logs, along with lifecycle information such as start and end times recorded when the task was submitted. The scheduler stores the resource usage, utilization, and execution latency generated by each execution, as well as the total capacity of various resources on the node where the execution occurred, as a historical execution record in the task profile database, forming a collection of multiple historical execution data corresponding to the tasks to be assigned.

[0031] S2. Analyze the impact of changes in resource utilization rate of each type of resource on execution delay in historical execution data, as well as the degree of proximity between resource utilization rate and resource saturation state, and determine the demand weight of each type of resource for the task to be assigned based on the occupancy of each type of resource.

[0032] The degree of execution delay impact corresponding to changes in resource utilization can characterize the strength of interference of resource fluctuations on task operation efficiency from a performance perspective. The degree of proximity of resource utilization to resource saturation can reflect the adaptation constraints brought about by resource scarcity from a resource stock perspective. Resource occupancy can reflect the objective resource consumption volume of the task. These three types of information comprehensively depict the inherent dependence of the task on various resources from three levels: performance loss, resource scarcity, and actual consumption. The demand weight formed by the comprehensive calculation can accurately quantify the importance of different resources in task operation.

[0033] Specifically, for new tasks submitted for execution for the first time without historical execution data, a cold start mode is adopted: based on the resource requirements declared by the user when submitting the task, initial requirement weights are generated through normalization so that the sum of all resource weights is 1; or a preset equal-weighted initial value is directly used. After the task completes its first execution, the requirement weights are adjusted online using the actual execution data to gradually approximate the true dependency characteristics.

[0034] In some implementations, during each execution, the monitoring system collects the current resource utilization rate and the task's response time or phased processing delay at a certain frequency, forming a data sequence of execution delay changes with resource utilization. Analyzing the trend of execution delay changes with resource utilization for each type of resource in each historical execution determines the degree of influence for each resource type. Specifically, for each resource type, during a historical execution, multiple sampling points are continuously collected and recorded at a preset sampling period (e.g., 1 second). A univariate linear fit is performed with resource utilization rate as the independent variable and task execution delay as the dependent variable, generating a fitted line. The slope of the line is divided by the average execution delay in that execution, and the absolute value is taken to obtain the relative sensitivity of execution delay to changes in resource utilization rate. This relative sensitivity represents the degree of influence of the corresponding resource; a larger value indicates that a fluctuation in resource utilization of the same magnitude will cause a greater change in task delay.

[0035] The degree of proximity for each resource type in each historical execution is determined by the resource utilization rate of each resource type in each historical execution. Specifically, the resource full load threshold (usually 100%) is divided by the difference between the resource full load threshold and the average resource utilization rate during the execution. The resulting ratio is used as the degree of proximity, representing the proportion of the resource approaching saturation. The higher the value, the closer the resource utilization rate is to the full load threshold. To avoid meaningless calculations, a very small positive value, such as 0.01, is added to the denominator based on the difference between the resource full load threshold and the resource utilization rate to ensure numerical stability when the resource utilization rate approaches 100%.

[0036] The resource sensitivity factor for each type of resource in each historical execution is determined based on the degree of impact and proximity. In the specific implementation, the first part generates a performance impact correction term based on the degree of impact: by adding 1 to the degree of impact, the degree of impact is transformed into a performance impact correction term based on 1. The greater the degree of impact, the larger the performance impact correction term, thus amplifying the sensitivity. The second part calculates a load approximation term based on the proximity: using a logarithmic function with the natural constant as the base, the function input is the sum of 1 and the proximity. The load approximation term increases non-linearly with increasing resource utilization, especially with a sharp increase in growth rate after the utilization exceeds 80%, accurately capturing the amplified effect of the threat to task performance when resources are approaching saturation. Then, the performance impact correction term from the first part is multiplied by the load approximation term from the second part to obtain the resource sensitivity factor, which comprehensively reflects the actual impact of changes in resource utilization on task latency and the potential risks brought about by resource saturation in a historical execution. The formula for calculating the resource sensitivity factor can be expressed as: In the formula, This represents the resource sensitivity factor of resource type i in the j-th execution. This indicates the degree to which the change in resource utilization of resource type i affects execution latency during the j-th execution. This represents the average resource utilization rate of resource type i in the j-th execution. is a very small positive value; ln represents the logarithmic function with the natural constant as the base.

[0037] For each historical execution of a task, the resource usage of each type of resource is divided by the total capacity of that type of resource in that execution to obtain the resource usage ratio, ensuring that all resource types correspond to a dimensionless number in a uniform form. Based on the resource sensitivity factor, a weighted average of the resource usage ratios of each type of resource across multiple historical executions is calculated to obtain the demand weight of the task to be assigned for each type of resource. Specifically, for each type of resource, after obtaining the resource sensitivity factor corresponding to the task to be assigned in multiple historical executions, the resource usage ratio of that type of resource in each historical execution is multiplied by the resource sensitivity factor corresponding to that execution, and then divided by the sum of the products of all resources in the same historical execution to obtain the normalized consumption ratio of that type of resource in a single historical execution. The arithmetic mean of the normalized consumption ratios across all historical executions is then calculated to obtain the demand weight of the task to be assigned for each type of resource, which is dimensionless and represents the multiple of the task's demand intensity for each type of resource relative to the benchmark. In executions with extremely saturated resources and drastically degraded performance, the resource sensitivity factor will take a very large value. Multiplying this by the resource utilization ratio amplifies the weight contribution of historical execution data to the average value. Conversely, in executions with ample resources and stable performance, the sensitivity factor approaches a small positive value, resulting in a smaller weight contribution of the corresponding data. The formula for calculating the demand weight can be expressed as: In the formula, This represents the weight of the resource requirement of the task to be assigned to the i-th type; This represents the resource usage ratio of the i-th type of resource in the j-th execution; This represents the resource sensitivity factor of resource type i in the j-th execution. This represents the resource usage ratio of the k-th type of resource in the j-th execution; This represents the resource sensitivity factor of resource type k in execution j; N represents the total number of resource types; and M represents the total number of historical executions. Specifically, if the resource occupancy ratio of all resources in a single historical execution is 0, that historical execution is not included in the calculation.

[0038] Preferably, because task performance is generally not constrained by resources when resource utilization is low, the fluctuation of execution latency is mainly caused by the task's own logic or external unrelated factors. Only in high-load intervals will resource competition make latency exhibit a significant and stable sensitivity to changes in utilization. Based on this, the resource utilization and corresponding execution latency of the tasks to be assigned are extracted from historical execution data for each historical execution where resource utilization exceeds a preset utilization threshold. The extracted resource utilization and execution latency are used to analyze the degree of impact and proximity. The preset utilization threshold is determined based on the statistical rules of industry operation and maintenance for general computing power tasks. Industry tests show that when resource utilization exceeds a specified percentage, resource scarcity will significantly amplify task latency fluctuations. When it is below this percentage, resources are abundant, and index fluctuations have almost no impact on task performance. For example, the preset utilization threshold is set to 80%, which can be fine-tuned to 75% for memory-intensive special computing power tasks. After the filtering process is completed, only resource usage data with resource utilization exceeding the threshold and matching task execution latency data are retained. The filtering process can eliminate invalid samples under low load, reduce the computational overhead caused by invalid data, and improve the accuracy of subsequent parameter calculations.

[0039] Furthermore, after the assigned task is completed in this execution, the feedback data generated from this execution is used to adjust the demand weights online, ensuring that the weights continuously adapt to changes in task behavior. Specifically, the resource occupancy ratio, resource utilization rate, and execution latency of each type of resource in this execution are obtained. Based on the resource utilization rate and execution latency of each type of resource in this execution, the resource sensitivity factor in this execution is determined. Based on the resource sensitivity factor and resource occupancy ratio in this execution, the demand weights are adjusted using an exponentially weighted moving average method. First, the product of the current resource occupancy ratio and the current resource sensitivity factor is calculated, and then divided by the sum of the products of all resources in this execution to obtain the normalized consumption ratio of that type of resource in this execution. The decay factor is multiplied by the normalized consumption ratio, and then the difference between 1 and the decay factor is multiplied by the initial demand weight. The result is used as the demand weight for the next scheduling. Through this incremental update, the system does not need to backtrack all historical data before each scheduling, achieving adaptive evolution of demand weights while ensuring computational efficiency. The attenuation factor is a preset value between 0 and 1, for example, set to 0.3. A larger attenuation factor indicates a greater impact of new data on the weights, and a faster response of the weights to recent changes in task behavior. The formula for adjusting the required weights can be expressed as: In the formula, This represents the weight of the resource requirement of the task to be assigned in the next scheduling; Indicates the attenuation factor; This indicates the proportion of resources newly acquired by the i-th type of resource after this execution. This represents the resource sensitivity factor newly acquired after the i-th type of resource is completed in this execution. This indicates the proportion of resources newly acquired after the current execution of resource type k. This represents the resource sensitivity factor newly acquired after the current execution of resource type k; N represents the total number of resource types. This represents the demand weight of the task to be assigned for the i-th type of resource in this scheduling. Specifically, when the resource occupancy ratio of all resources is 0 in this execution, this execution will not participate in the correction.

[0040] S3. Based on the resource status data of each node, select candidate nodes whose remaining amount of each type of resource is greater than or equal to the resource requirement of the task to be assigned. Determine the comprehensive matching degree between the task to be assigned and each candidate node based on the requirement weight and the resource status data of each candidate node.

[0041] Resource requirements represent the minimum guaranteed amount of various resources needed for the task. Candidate nodes must have remaining resources of at least the required amount at any given time. Nodes that clearly do not meet the basic operational conditions of the task are eliminated, narrowing the matching calculation range and improving scheduling efficiency. The overall matching degree is a quantitative indicator used to measure the overall suitability between the task to be assigned and the candidate nodes. Its determination process considers both the task's resource requirements and the real-time resource status of the candidate nodes, ensuring that subsequent allocation decisions achieve a balance between resource matching accuracy and node load balancing.

[0042] The resource requirements can be set according to different task types. For example, for general computing tasks, the default CPU requirement is 1 core and the default memory requirement is 1 gigabyte; for GPU computing tasks, the default GPU requirement is 1 GPU and the default video memory requirement is 4 gigabytes.

[0043] In some implementations, the total capacity, remaining amount, and occupied amount of each resource type are extracted from the resource status data of each candidate node. Total capacity represents the node's maximum supply capacity for that resource type, occupied amount represents the amount of resources currently occupied by other tasks, and remaining amount represents the amount of resources available for allocation to new tasks. After extracting these three basic indicators, candidate nodes are evaluated along two dimensions: The first dimension is the resource matching dimension, which measures the degree of fit between the remaining resource distribution of candidate nodes and the resource preferences of the task. First, the ratio of the remaining amount of each type of resource to the total capacity of the candidate nodes is used as the relative abundance of each type of resource. The larger this ratio, the higher the idle rate of that type of resource on the node, the lower the risk of contention, and the stronger the guarantee for the subsequent operation of the task. Then, the relative abundance is weighted and summed using the demand weight of the task to be assigned for each type of resource as the weight, to obtain the initial matching degree. The resource type with the larger the demand weight, the more significant its relative abundance contributes to the initial matching degree, allowing nodes with relatively abundant resources in the most sensitive and dependent resources of the task to obtain higher matching scores, achieving targeted resource matching.

[0044] The second dimension is the load balancing dimension, used to measure the overall load level of candidate nodes and avoid scheduling tasks to nodes already under high load. The ratio of the occupied amount of each resource type to the total capacity of the candidate node is used as the resource utilization level of each resource type; a higher ratio indicates that the resource type is closer to saturation. The load pressure factor of the candidate node is obtained by taking the arithmetic mean of the resource utilization levels of multiple resource types, comprehensively reflecting the average utilization level of the node across multiple resources. The smaller the value, the more idle the node is overall, and the stronger its ability to accept new tasks. The selection range of multiple resource types can be all resource types included in the scheduling management on the candidate node, or a specified set of resource types related to task resource requirements. In the calculation of the load pressure factor, the averaging of the utilization levels of multiple resource types can be done by using an arithmetic mean, treating each resource type equally, or by assigning different weights to different resource types according to the cluster management strategy, and then performing a weighted average. For example, if the overall GPU resources of the cluster are scarce while CPU resources are abundant, the GPU utilization level can be given a higher weight, making the load pressure factor more focused on reflecting the load status of the GPU dimension.

[0045] The overall matching degree is determined based on the initial matching degree and the load pressure factor. The overall matching degree is positively correlated with the initial matching degree and negatively correlated with the load pressure factor. One method is to calculate the product of the initial matching degree and the difference between 1 and the load pressure factor as the overall matching degree. In this method, the closer the load pressure factor is to 1, the closer 1 minus the load pressure factor is to 0, significantly suppressing the product result. Even if a node performs exceptionally well in resource matching, its high load state will significantly reduce the overall matching degree, thus automatically suppressing the selection of high-load nodes in scheduling decisions and achieving a synergy between affinity optimization and load balancing.

[0046] S4. Based on the overall matching degree, the priority of the task to be assigned, and the resource status data of each candidate node, determine the allocation decision score, and determine the execution node of the task to be assigned from the candidate nodes according to the allocation decision score.

[0047] Priority is a quantitative indicator used to measure the urgency of task scheduling, reflecting the scheduling priority a task should receive based on its business importance and the length of time it has been waiting in the queue. Building upon the overall matching degree, this approach further integrates the task's own priority requirements and the remaining resource space characteristics of candidate nodes. This allows scheduling decisions to simultaneously consider multiple objectives, such as the suitability between tasks and nodes and the urgency of the task, resulting in an allocation decision score. This allocation decision score is a comprehensive evaluation indicator used to ultimately select the execution node from multiple candidate nodes. By using the collaborative scoring of these multi-dimensional factors to select execution nodes, it is possible to ensure timely response to high-priority tasks while guiding tasks to converge on nodes with a higher proportion of remaining resources, reducing resource fragmentation caused by improper scheduling, and improving the overall utilization efficiency of the cluster.

[0048] In some implementations, the preset service level, elapsed waiting time, and expected completion time of the task to be assigned are obtained. The preset service level is an initial level identifier specified by the user or assigned by the system based on the business type when the task is submitted, used to characterize the business importance of the task. For example, the level of a core online business task can be set to 5, and the level of an offline batch processing task can be set to 1. The elapsed waiting time is the queuing time since the task was submitted and entered the scheduling queue, calculated by the difference between the system clock and the task submission timestamp. The expected completion time is the maximum allowed execution time of the task, declared by the user or preset by the system based on the task type. For example, the expected completion time of an online inference task can be preset to 100 milliseconds.

[0049] The ratio of the waiting time of a task to its expected completion time is used to determine the time urgency of the task. The larger the ratio, the closer the task is to or beyond the expected time due to the increased waiting time, and the higher the scheduling urgency.

[0050] The priority of tasks to be assigned is determined based on their time urgency and preset service level. One method is to calculate the product of the preset service level and 1 plus the sum of the time urgency levels, which serves as the priority of the task. Tasks with higher preset service levels have higher base priority. As waiting time accumulates and time urgency increases, the priority dynamically increases, preventing low-level tasks from waiting indefinitely due to a fixed priority.

[0051] After obtaining the overall matching degree and the priority of the tasks to be assigned for each candidate node, it is also necessary to extract the total capacity and remaining amount of multiple types of resources from the resource status data of each candidate node. The total capacity of multiple types of resources refers to the maximum total supply of various physical or virtual configurations of resources in the candidate node, and the remaining amount refers to the amount of currently unoccupied available resources. The ratio of the remaining amount of multiple types of resources to the total capacity is calculated. This can be done by calculating the ratio for each type of resource separately and then taking the average, or by selecting the minimum value of the ratio among the various types of resources as the resource remaining ratio of the candidate node. This ratio reflects the scale of idle resources that the candidate node may have left after this scheduling. The higher the ratio, the more abundant the overall remaining space of the node, and the lower the probability of small fragmentation after accepting tasks.

[0052] Then, the allocation decision score for candidate nodes is determined based on the overall matching degree, priority, and remaining resource ratio. One method is to multiply the overall matching degree, priority, and 1 by the sum of the remaining resource ratio, and use the product as the allocation decision score. In this method, the overall matching degree ensures resource adaptation and load balancing between tasks and nodes, priority ensures priority scheduling for urgent tasks, and the remaining resource ratio guides tasks to prioritize nodes with sufficient remaining space to suppress fragmentation. The three factors combine to form a synergistic effect, and a low score in any one of these factors will significantly lower the total score, ensuring that the finally selected node has no significant weaknesses in any of the three aspects.

[0053] In some implementations, the candidate node with the highest allocation decision score is selected as the execution node for the task to be assigned. If multiple candidate nodes have the same highest allocation decision score, one can be randomly selected, or the node with the highest overall matching degree can be selected, or the node with the highest remaining resource ratio can be selected, to fine-tune scheduling preferences. After the execution node is selected, the system updates the resource status data of that node, deducts the various resource requirements declared for this task from the remaining amount, updates the occupied amount, completes resource reservation, and sends the task to that node to start execution.

[0054] Besides selecting the candidate node with the highest allocation decision score as the execution node, the following alternative selection method can be used: all candidate nodes with allocation decision scores exceeding a preset decision threshold are considered as selectable nodes, and one is randomly selected as the execution node. The preset decision threshold can be set based on the distribution of allocation decision scores in historical scheduling records. For example, the lower quartile of the scores corresponding to successfully allocated tasks in each scheduling cycle can be used as the threshold. This ensures that the selected node meets the basic requirements in terms of overall suitability while increasing the randomness of node selection, avoiding all tasks concentrating on the few nodes with the highest scores and causing cluster load hotspots.

[0055] In some implementations, if multiple nodes in the cloud computing cluster do not meet the condition that the remaining amount of a certain type of resource is greater than or equal to the resource requirement of the task (i.e., there are no candidate nodes), it indicates that the current cluster's remaining resources cannot meet the minimum operating requirements of the task. In this case, the task to be assigned is inserted into a priority waiting queue, and the current scheduling is paused until a subsequent scheduling cycle when the resource status data of each node is retrieved again to filter for candidate nodes. In the priority waiting queue, tasks are arranged in descending order of priority. Tasks with higher priority are re-attempted for assignment earlier in the next scheduling cycle, ensuring that urgent tasks receive priority scheduling opportunities after resources are released.

[0056] Based on the above technical solution, by comprehensively analyzing the impact of changes in resource utilization on execution latency in historical execution data, as well as the proximity of resource utilization to resource saturation, and combining this with resource occupancy, a demand weight is generated for each task to be assigned. This weight reflects the intensity and sensitivity of the task's dependence on each type of resource, transforming the characterization of task resource requirements from a static declaration to a dynamically perceived, realistic dependency. Furthermore, candidate nodes with sufficient resources are selected from the cluster nodes, and the demand weights are used to perform a weighted matching of node resource status to obtain a comprehensive matching degree. This upgrades the task-node adaptation from a simple comparison of resource availability to a precise matching deeply coupled with the sensitive characteristics of the task. In the final decision-making process, the comprehensive matching degree, task priority, and node resource status are integrated to determine the execution node under multi-objective collaboration. This simultaneously improves resource utilization at the global level, ensures the service quality of high-priority tasks, and suppresses uneven node load.

Claims

1. A method for allocating computing power in a cloud computing cluster, characterized in that, include: Obtain resource status data and historical execution data corresponding to the tasks to be assigned from each node in the cloud computing cluster; the historical execution data includes the resource occupancy, resource utilization rate and execution latency of each type of resource in multiple historical executions of the tasks to be assigned; The impact of changes in resource utilization rates of each type of resource on execution latency and the degree of proximity between resource utilization rates and resource saturation states are analyzed in the historical execution data. The demand weight of each type of resource for the task to be assigned is determined in combination with the occupancy of each type of resource. Candidate nodes are selected based on the resource status data of each node, and the remaining amount of each type of resource is greater than or equal to the resource requirement of the task to be assigned. The comprehensive matching degree between the task to be assigned and each candidate node is determined based on the requirement weight and the resource status data of each candidate node. Based on the overall matching degree, the priority of the task to be assigned, and the resource status data of each candidate node, an allocation decision score is determined, and the execution node of the task to be assigned is determined from the candidate nodes based on the allocation decision score.

2. The computing power allocation method for a cloud computing power cluster according to claim 1, characterized in that, The analysis examines the impact of changes in resource utilization rates for each type of resource on execution latency within the historical execution data, as well as the proximity of resource utilization rates to resource saturation. Based on the occupancy of each type of resource, the demand weights of the tasks to be assigned for each type of resource are determined, including: Analyze the trend of execution delay as a function of resource utilization rate in each historical execution to determine the degree of impact for each resource type; The degree of proximity for each type of resource in each historical execution is determined based on the resource utilization rate of each type of resource in each historical execution. The resource sensitivity factor for each type of resource in each historical execution is determined based on the degree of influence and the degree of proximity. The resource usage of each type of resource in each historical execution is converted into a resource usage ratio. Based on the resource sensitivity factor, the resource usage ratio of each type of resource in multiple historical executions is weighted and averaged to obtain the demand weight of the task to be allocated for each type of resource.

3. The computing power allocation method for a cloud computing power cluster according to claim 2, characterized in that, The method further includes: Extract the resource utilization rate and corresponding execution delay of the task to be assigned from the historical execution data for each historical execution where the resource utilization rate is greater than a preset utilization rate threshold. The extracted resource utilization rate and execution delay are used to analyze the degree of impact and the degree of proximity.

4. The computing power allocation method for a cloud computing power cluster according to claim 2, characterized in that, After the assigned task is completed, the following is also included: Obtain the resource usage, resource utilization rate, and execution latency for each type of resource during this execution; Based on the resource utilization rate and execution delay of each type of resource in this execution, the resource sensitivity factors in this execution are determined; Based on the resource sensitivity factors and resource occupancy ratios during this execution, the demand weights are adjusted using an exponentially weighted moving average method, and the adjusted values ​​are used as the demand weights for the next scheduling.

5. The computing power allocation method for a cloud computing power cluster according to claim 1, characterized in that, The overall matching degree between the task to be assigned and each candidate node is determined based on the demand weight and the resource status data of each candidate node, including: Extract the total capacity, remaining amount, and occupied amount of each type of resource from the resource status data of each candidate node; The ratio of the remaining amount of each type of resource in the candidate node to the total capacity is used as the relative abundance of each type of resource. Using the demand weight of each type of resource for the task to be assigned as the weight, the relative abundance is weighted and summed to obtain the initial matching degree; The ratio of the occupied amount of each type of resource in the candidate node to the total capacity is used as the resource utilization degree of each type of resource, and the load pressure factor of the candidate node is obtained by averaging the resource utilization degrees of multiple types of resources. The overall matching degree is determined based on the initial matching degree and the load pressure factor.

6. The computing power allocation method for a cloud computing power cluster according to claim 1, characterized in that, Based on the overall matching degree, the priority of the tasks to be assigned, and the resource status data of each candidate node, an allocation decision score is determined, including: Extract the total capacity and remaining quantity of multiple resource types from the resource status data of each candidate node; The resource remaining ratio of the candidate node is determined based on the ratio of the remaining amount of the various types of resources to the total capacity. The allocation decision score of the candidate node is determined based on the overall matching degree, the priority, and the remaining resource ratio.

7. The computing power allocation method for a cloud computing power cluster according to claim 6, characterized in that, Determining the priority of the tasks to be assigned includes: Obtain the preset service level, waiting time, and expected completion time of the task to be assigned; The ratio of the waiting time of the task to be assigned to the expected completion time limit is used as the time urgency of the task to be assigned. The priority of the tasks to be assigned is determined based on their time urgency and preset service level.

8. The computing power allocation method for a cloud computing power cluster according to claim 1, characterized in that, Determining the execution node of the task to be assigned from the candidate nodes based on the allocation decision score includes: The candidate node with the highest allocation decision score is selected as the execution node for the task to be assigned.

9. The computing power allocation method for a cloud computing power cluster according to claim 1, characterized in that, The method further includes: If the candidate node is not found among the multiple nodes of the cloud computing cluster, the task to be assigned is inserted into the priority waiting queue until the resource status data of each node is re-acquired and candidate nodes are obtained in a subsequent scheduling cycle.

10. A computing power allocation system for a cloud computing cluster, characterized in that, include: The data acquisition module is used to acquire resource status data of each node in the cloud computing power cluster and historical execution data corresponding to the tasks to be assigned; the historical execution data includes the resource occupancy, resource utilization rate and execution latency of each type of resource in multiple historical executions of the tasks to be assigned; The demand analysis module is used to analyze the impact of changes in the resource utilization rate of each type of resource on the execution latency in the historical execution data, as well as the degree of proximity between the resource utilization rate and the resource saturation state, and to determine the demand weight of each type of resource for the task to be assigned based on the occupancy of each type of resource. The resource matching module is used to filter out candidate nodes whose remaining amount of each type of resource is greater than or equal to the resource requirement of the task to be assigned based on the resource status data of each node, and to determine the comprehensive matching degree between the task to be assigned and each candidate node based on the requirement weight and the resource status data of each candidate node. The node scheduling module is used to determine the allocation decision score based on the comprehensive matching degree, the priority of the task to be allocated, and the resource status data of each candidate node, and to determine the execution node of the task to be allocated from the candidate nodes based on the allocation decision score.

Images