Task deployment method, device, equipment, medium and product

Abstract

The present application discloses a task deployment method, device, equipment, medium and product, which obtains the current task demand in any iteration cycle; obtains the first deployment strategy corresponding to the current task demand according to the current task demand and the current parameter conditions; when the iteration cycle has not ended and the task demand of any task to be deployed has changed, adjusts the current parameter conditions, and obtains the second deployment strategy according to the adjusted parameter conditions and the changed task demand until the iteration cycle ends, and obtains the first available decision table PAT corresponding to the iteration cycle; when multiple iteration cycles in the task demand cycle are all ended and the preset convergence conditions are met, obtains the target PAT according to the multiple optimal deployment strategies corresponding to the multiple task demands in the task demand cycle, and performs task deployment according to the target PAT. The embodiments of the present application can improve the reliability of task deployment.

Description

Technical Field

[0001] The present application belongs to the field of big data technology, and in particular relates to a task deployment method, device, equipment, medium and product. Background Art

[0002] With the continuous expansion of data center scale and the implementation of overselling strategies for server resources, multi-resource hybrid deployment has become a common means to improve resource utilization. However, traditional task deployment strategies are often based on static resource allocation and local optimal solutions, ignoring the dynamic changes in task resource requirements and the unpredictability of future task flows. This leads to a mismatch between resource allocation and actual task requirements, which in turn causes frequent task migration and resource reallocation, resulting in low reliability of task deployment. Summary of the invention

[0003] The embodiments of the present application provide a task deployment method, apparatus, device, medium and product, which can improve the reliability of task deployment.

[0004] In a first aspect, an embodiment of the present application provides a task deployment method, which may include:

[0005] Obtain the current task requirements in any iteration cycle. Multiple iteration cycles constitute a task requirement cycle.

[0006] According to the current task requirement and the current parameter condition, a first deployment strategy corresponding to the current task requirement is obtained, where the first deployment strategy is used to deploy the multiple tasks in the multiple servers, and the current parameter condition includes the current weights corresponding to the multiple tasks and the multiple servers respectively;

[0007] When the iteration cycle is not over and the task requirements of any task to be deployed are changed, the current parameter conditions are adjusted, and the second deployment strategy is obtained according to the adjusted parameter conditions and the changed task requirements until the iteration cycle is over, and the first available decision table PAT corresponding to the iteration cycle is obtained. The first available decision table PAT includes the benefits corresponding to the task requirements executed in the iteration cycle, and the benefits are positively correlated with the resource utilization rate of the server corresponding to the task requirements executed in the iteration cycle;

[0008] When multiple iteration cycles within the task requirement cycle are completed and the preset convergence conditions are met, the target PAT is obtained according to the multiple optimal deployment strategies corresponding to the multiple task requirements within the task requirement cycle, and the tasks are deployed according to the target PAT, wherein each optimal deployment strategy is the highest benefit corresponding to each task requirement, and the preset convergence conditions are determined according to the first available decision table PAT corresponding to each iteration cycle.

[0009] In a second aspect, an embodiment of the present application provides a task deployment device, which may include:

[0010] An acquisition module is used to acquire the current task requirements in any iteration cycle. Multiple iteration cycles constitute a task requirement cycle.

[0011] A first determination module is used to obtain a first deployment strategy corresponding to the current task requirement according to the current task requirement and the current parameter condition, wherein the first deployment strategy is used to deploy multiple tasks in multiple servers, and the current parameter condition includes current weights corresponding to the multiple tasks and the multiple servers respectively;

[0012] A second determination module is used to adjust the current parameter conditions when the iteration cycle has not ended and the task requirements of any task to be deployed have changed, and obtain a second deployment strategy according to the adjusted parameter conditions and the changed task requirements until the iteration cycle ends, and obtain a first available decision table PAT corresponding to the iteration cycle, wherein the first available decision table PAT includes benefits corresponding to the task requirements executed in the iteration cycle, and the benefits are positively correlated with resource utilization of the server corresponding to the task requirements executed in the iteration cycle;

[0013] A deployment module is used to obtain a target PAT according to multiple optimal deployment strategies corresponding to multiple task requirements within the task requirement cycle when multiple iteration cycles within the task requirement cycle are completed and the preset convergence condition is met, and to perform task deployment according to the target PAT, wherein each optimal deployment strategy is the highest benefit corresponding to each task requirement, and the preset convergence condition is determined according to the first available decision table PAT corresponding to each iteration cycle.

[0014] In a third aspect, an embodiment of the present application provides an electronic device, the device comprising:

[0015] processor;

[0016] a memory for storing processor-executable instructions;

[0017] The processor is configured to execute instructions to implement the task deployment method as shown in any one of the embodiments of the first aspect.

[0018] In a fourth aspect, an embodiment of the present application provides a computer storage medium, on which a computer program is stored. When the computer program is executed by a processor, the task deployment method shown in any one of the embodiments of the first aspect is implemented.

[0019] In the fifth aspect, an embodiment of the present application also provides a computer program product, which includes a computer program stored in a readable storage medium, and at least one processor of the device reads and executes the computer program from the storage medium, so that the device implements the task deployment method shown in any one of the embodiments of the first aspect.

[0020] The embodiments of the present application provide a task deployment method, apparatus, device, medium, and product. Compared with the prior art, the present application has the following beneficial effects:

[0021] The task deployment method, device, equipment, medium and product of the embodiment of the present application effectively solve the problem of low reliability of task deployment caused by static resource allocation and local optimal solution in traditional task deployment strategy by introducing dynamic iteration and parameter adjustment mechanism. The present application ensures that server resource allocation is closely matched with actual task requirements by continuously monitoring the dynamic changes of task requirements and adjusting the deployment strategy according to real-time task requirements and parameter conditions in each iteration cycle. By constructing a target available decision table (PAT) and selecting the optimal deployment strategy based on the principle of maximizing benefits, not only the utilization rate of server resources is improved, but also the number of task migrations and resource reallocations caused by resource mismatches is reduced. And through the optimization process across multiple iteration cycles, it is ensured that the overall optimal solution is achieved within the task requirement cycle, thereby enhancing the reliability of task deployment. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In order to more clearly illustrate the technical solution of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0023] Figure 1 This is one of the flowcharts of a task deployment method provided in an embodiment of the present application;

[0024] Figure 2 This is a second flowchart of a task deployment method provided in an embodiment of the present application;

[0025] Figure 3 It is a structural diagram of a task deployment device provided in an embodiment of the present application;

[0026] Figure 4 It is a structural schematic diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0027] The features and exemplary embodiments of various aspects of the present application will be described in detail below. In order to make the purpose, technical solutions and advantages of the present application clearer, the present application will be further described in detail below in conjunction with the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain the present application, rather than to limit the present application. For those skilled in the art, the present application can be implemented without the need for some of these specific details. The following description of the embodiments is only to provide a better understanding of the present application by illustrating the examples of the present application.

[0028] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the statement "include..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.

[0029] It is obvious to those skilled in the art that various modifications and changes can be made in this application without departing from the spirit or scope of this application. Therefore, this application is intended to cover modifications and changes of this application that fall within the scope of the corresponding claims (technical solutions claimed for protection) and their equivalents. It should be noted that the implementation methods provided in the embodiments of this application can be combined with each other without contradiction.

[0030] Data centers are the key support for large-scale data analysis, enterprise-level Internet applications, and cloud computing systems. In order to meet the growing computing needs, the scale of data centers and the total number of servers are growing rapidly. In order to further amortize the construction costs, overselling data center resources and realizing the redistribution of user-ordered resources during the idle period of tasks has become an ideal solution. Multi-resource hybrid deployment (hereinafter referred to as multi-dimensional hybrid deployment) is a commonly used method for task deployment on current cloud computing platforms. This method uses virtual machine technology to isolate multiple resources (such as CPU, memory, bandwidth, I / O interface, etc.) on physical machines and allocate them to multiple tasks, so as to realize the deployment and operation of multiple application tasks on the same server node. In the context of overselling of data center resources, how to reduce excess resource allocation while ensuring that task requirements are met based on multi-resource hybrid deployment has become a technical problem that needs to be solved urgently.

[0031] The essence of achieving resource overbooking is to reduce the idle time occupancy of data center resources and improve resource utilization efficiency. That is, in large-scale task deployment scenarios, considering objective factors such as server resource capacity, periodic changes in demand, and resource utilization bottlenecks, we seek the optimal way to combine and mix massive tasks and deploy them to each server. This technical problem has the following challenges:

[0032] 1) Dynamic changes in the demand for computer resources by tasks: During the operation of tasks in containers, their demand for computer resources is not constant. The resource load often fluctuates due to factors such as user schedules and production processes, which results in busy and idle periods for tasks. In traditional multi-dimensional colocation solutions, since server resources can easily meet limited task requirements, designers allocate fixed amounts of resources during the peak of busy periods for various types of computer resources required by tasks during the pre-deployment phase. Although this method ensures the operational stability of each task and provides sufficient resource supply space for possible demand fluctuations in the later period, since tasks are not always in busy periods, when actual demand decreases, some resources are idle, resulting in low server resource utilization. According to statistics, the traditional deployment method only makes the server resource utilization rate of data centers only about 30%. Since the estimation of the intensity of task resource demand cannot be completely accurate, the low resource utilization rate is further aggravated. As demand increases, data centers have to continue to expand capacity. Low resource utilization leads to considerable waste of resources, and it is obviously not realistic to continue the traditional method of "large quantity and full supply".

[0033] 2) Task migration problem: The continuous task flow in the data center means that new tasks may arrive at every time point and request the allocation of containers and resources. Since the demand is unpredictable and resources are oversold, there may not be a suitable container to accommodate large tasks. When this happens, the system needs to migrate some of the current tasks and reallocate containers to make room for new tasks. A poorly performing colocation strategy can easily lead to a large number of resource fragments (a small block of resources is free in each container, but cannot accommodate the demand block of new tasks), resulting in frequent task migration and resource reallocation. This process will incur data migration transmission costs, and some tasks will need to be suspended, which may lead to delayed task completion and even a decline in user experience.

[0034] 3) Hybrid deployment with multi-resource collaboration: In the task flow loaded in the data center, there are many types of tasks, and the requirements for various types of computer resources are also different. The difference between different types of tasks is mainly reflected in which one or which resources they require much more than other resources. For example, the demand for CPU and memory resources for computing-intensive tasks is significantly greater than bandwidth, storage and other resources; for example, user-request tasks are sensitive to latency, and their demand for bandwidth resources will be more prominent. Based on this scenario, if the hybrid deployment strategy is adopted to choose to deploy various types of tasks in containers with "complementary resource requirements", it can avoid the situation where multiple tasks of the same type are deployed in the same container, and some resources are squeezed but other resources are idle. In an ideal situation, multiple types of tasks are deployed in a container so that each type of resource can correspond to a certain type of task being run, so that multiple types of resources can be effectively utilized, and the generation of idle resources can be effectively reduced.

[0035] However, the prior art usually quantifies the computing power required by the newly arrived task and the computing power of the target container, compares the degree of fit, and selects the container to be deployed. However, the prior art only considers the optimal deployment plan at the moment when the new task arrives, and deploys it. Although the prior art can select the container with the highest degree of fit to ensure the real-time optimal solution, the task flow is continuous, and it is difficult to ensure that after a period of time, when the subsequent tasks arrive, it is still the overall optimal solution. (For example: There are currently two containers A and B with a total resource of 10, and the available resources are 7 and 5 respectively. There is a task with a resource requirement of 4. The container with a lower actual computing power utilization rate is selected from the above patent and placed in A. The remaining available resources of the two containers become 3 and 5. At this time, another task with a resource requirement of 6 arrives. At this time, both containers have remaining resources but cannot accommodate the newly arrived task, and the existing tasks have to be migrated first to make room; if the first task with a requirement of 4 is deployed in B, A will have enough space to deploy the task with a resource requirement of 6, thus saving bandwidth, storage and other resource overheads used during task migration). The local optimal solution approach easily generates external fragmentation in the container, resulting in a small amount of remaining resources in the container not being allocated and limiting resource utilization.

[0036] In order to solve the problems existing in the prior art, the embodiments of the present application provide a task deployment method, apparatus, device, medium and product.

[0037] The present application embodiment provides a task deployment method, apparatus, device, medium and product. The following first introduces the task deployment method provided by the present application embodiment. Figure 1 As shown, the method specifically comprises the following steps:

[0038] S100, obtaining the current task requirement in any iteration cycle, where multiple iteration cycles constitute a task requirement cycle.

[0039] Optionally, in a feasible implementation of the present application, through a preset monitoring and collection mechanism, within a specific time interval (i.e., iteration cycle), the task requirement information of all tasks to be deployed or deployed but needing to be re-evaluated in the current iteration cycle is systematically collected and summarized. Such requirement information includes but is not limited to CPU computing power, memory space, storage access, network bandwidth requirements, and possible specific hardware or software resource requirements.

[0040] In order to ensure the accuracy and timeliness of information, multiple data sources can be integrated, such as task management systems, resource allocation databases, real-time performance monitoring tools, etc. These data sources will send the latest task status and task requirement information in real time or regularly. At the same time, the priority, urgency and user-defined constraints of the task can also be taken into account, such as the exclusivity of resource use, resource reservation within a specific period of time, etc. These factors will be taken into consideration as part of the task requirements.

[0041] After collecting these task requirement information, they can be sorted and analyzed so that appropriate deployment strategies can be formulated according to the current task requirements in the subsequent steps. The sorting process can include classifying requirements by type, evaluating the competition relationship between each task for resources, calculating the gap between overall resource requirements and available resources, etc. Through these processes, a comprehensive and accurate understanding of the task requirements in the current iteration cycle can be formed, providing a solid data foundation for subsequent resource allocation and deployment decisions.

[0042] In addition, the task demand cycle is determined according to the operating rules of the data center or cloud computing platform, the periodic characteristics of task submission, and the needs of system management. It represents the overall changes in task demand over a longer period of time. The iteration cycle is a subdivided period within the task demand cycle, which is used to respond to and adjust task demands in real time within each shorter time window to cope with possible demand fluctuations and resource competition. Therefore, the accurate implementation of step S100 not only depends on an efficient data collection and collation mechanism, but also requires an in-depth understanding and reasonable setting of the task demand cycle and iteration cycle.

[0043] S200, based on the current task requirements and current parameter conditions, obtain a first deployment strategy corresponding to the current task requirements, the first deployment strategy is used to deploy multiple tasks in multiple servers, and the current parameter conditions include current weights corresponding to the multiple tasks and the multiple servers respectively.

[0044] Optionally, in an embodiment of the present application, each of the several servers can provide a known amount of multidimensional computer resources, such as CPU, memory, bandwidth, I / O, etc. There are several long-term tasks (i.e., tasks are deployed in the server for a long time), and the number of tasks is greater than the number of servers. Each task has a certain demand for multidimensional computer resources (in this application, it can be assumed that the user payment method is a long-term reserved instance, that is, a time-based rental of quantitative resources), where the minimum threshold for each resource demand is known, the bottleneck resource type is known, and the peak demand is known (the initial regulation is the upper limit of the instance resource amount rented by the user).

[0045] Since the resource demand of long-term tasks fluctuates over time during operation, if the tasks are deployed according to the upper limit of resources leased by the user, the idle resource phenomenon is more serious when the demand is low. This application hopes to fit the actual demand status of the task and compress the actual supply of resources to improve resource utilization. For example: during periods of low resource usage, the server elasticity is improved so that the visible capacity of the server is greater than the actual capacity, so as to accommodate more tasks when deploying tasks. At this time, the actual resource usage of the task is less than the demand, so the quality can still be guaranteed in actual operation. In addition, due to changes in task requirements, multiple tasks deployed on the same server cannot fully utilize server resources at any time. How to reasonably combine tasks for mixed deployment and make the resource usage between tasks "increase and decrease" as much as possible is also the direction of this application for improving resource utilization.

[0046] Optionally, in a feasible implementation of the present application, first, the task requirements obtained in the current iteration cycle can include the specific requirements of each task for multi-dimensional computer resources (such as CPU, memory, bandwidth, I / O, etc.), as well as the volatility prediction of these requirements (if available). At the same time, the current parameter conditions can also be referred to, which cover the current weights corresponding to multiple tasks and multiple servers, and these weights can be dynamically calculated based on factors such as task priority, resource sensitivity, historical resource utilization or server processing capacity, load balancing status, etc.

[0047] Next, we use optimization algorithms (such as linear programming, integer programming, genetic algorithms, reinforcement learning, etc.) or specialized deployment models to perform complex calculations and simulations in combination with the above task requirements and parameter conditions. This process aims to find an optimal or near-optimal task deployment solution, namely the first deployment strategy. This strategy must ensure that the resource utilization of the server is maximized while meeting the minimum demand thresholds and bottleneck resource constraints of all tasks, while taking into account the complementarity of resource usage between tasks, that is, tasks with "increases and decreases" in resource requirements in different time periods are mixed and deployed on the same server to reduce resource idleness.

[0048] S300, when the iteration cycle has not ended and the task requirements of any task to be deployed have changed, adjust the current parameter conditions, and obtain a second deployment strategy according to the adjusted parameter conditions and the changed task requirements until the iteration cycle ends, and obtain a first possible action table (Possible Action Table, PAT) corresponding to the iteration cycle, wherein the first possible decision table PAT includes the benefits corresponding to the task requirements executed in the iteration cycle, and the benefits are positively correlated with the resource utilization of the server corresponding to the task requirements executed in the iteration cycle.

[0049] Optionally, in a feasible implementation of the present application, the task requirements of all tasks to be deployed in the current iteration cycle are first continuously monitored. Once a change in the task requirements of any task is detected (such as an increase or decrease in resource requirements, a change in the type of requirements, or an increase in urgency, etc.), the parameter adjustment mechanism will be immediately triggered. This mechanism involves re-evaluation and adjustment of current parameter conditions, including recalculating the weights of each task and server in the current context. These weights are dynamically adjusted based on factors such as the real-time requirements of the task, priority changes, real-time load conditions of the server, and changes in resource utilization.

[0050] Subsequently, the calculation process of the deployment strategy is re-executed using the updated parameter conditions and the changed task requirements. This process is similar to step S200, but the difference is that it occurs within the iteration cycle and is based on real-time updated information. The system explores the optimal or near-optimal deployment solution possible under the existing conditions through optimization algorithms or deployment models, namely the second deployment strategy. This strategy aims to respond quickly to changes in task requirements and ensure that the resource utilization of the server can be maintained at a high level by reallocating tasks to the server, while minimizing resource idleness and conflicts.

[0051] After obtaining the second deployment strategy, the deployment is not executed immediately, but it is compared with the previous deployment plan to evaluate whether it really brings about an improvement in resource utilization or an improvement in task execution efficiency. If the evaluation result shows that the second deployment strategy is better, the system will make deployment adjustments; otherwise, the system may choose to maintain the current deployment status or continue to look for a better deployment plan. This process is repeated in the iteration cycle until the end of the cycle, and finally a first available decision table (PAT) containing all task requirement changes and their corresponding deployment adjustment records in the cycle is generated. This PAT not only reflects the system's ability to respond quickly to changes in task requirements, but also provides valuable reference data for subsequent deployment optimization by quantifying benefits (positively correlated with resource utilization). Through the implementation of the S300 step, it is possible to maintain a high degree of flexibility and adaptability in a complex and changing task requirement environment, ensuring efficient utilization of resources and smooth execution of tasks.

[0052] S400, when multiple iteration cycles within the task requirement cycle are completed and the preset convergence condition is met, a target PAT is obtained according to multiple optimal deployment strategies corresponding to multiple task requirements within the task requirement cycle, and tasks are deployed according to the target PAT, wherein each optimal deployment strategy is the highest benefit corresponding to each task requirement, and the preset convergence condition is determined according to the first available decision table PAT corresponding to each iteration cycle.

[0053] Optionally, in a feasible implementation of the present application, achieving task deployment optimization across iteration cycles and generating the final target PAT is a comprehensive decision-making process. When all iteration cycles within the task requirement cycle are successfully completed, the system first collects and analyzes the first available decision table (PAT) generated at the end of each iteration cycle. These PATs not only record the changes in task requirements and the adjustments to deployment strategies within each iteration cycle, but also evaluate the effects of different deployment strategies by quantifying the benefits (which are directly related to the improvement in server resource utilization). The system then summarizes and compares these PATs according to preset convergence conditions. The preset convergence conditions can be based on a series of indicators, such as the stability of resource utilization, the trend of revenue growth, the frequency of adjustment of deployment strategies, etc., to ensure that after multiple iteration cycles, the system can find a relatively stable and efficient deployment mode.

[0054] After the convergence conditions are met, the system further analyzes multiple optimal deployment strategies within the task demand cycle. Each optimal deployment strategy is a deployment solution that is calculated for specific task requirements within the corresponding iteration cycle and can bring the highest benefits. The system compares these optimal strategies to find the commonalities and differences between them, especially focusing on those deployment modes and resource allocation strategies that continue to perform well in different iteration cycles. This process helps the system extract more universal and stable deployment rules.

[0055] Finally, based on the above analysis, the system integrates all the information in the mission requirement cycle to generate a target PAT. The target PAT not only represents the optimal deployment plan for the entire mission requirement cycle, but also reflects the system's ability to predict and adapt to future changes in mission requirements. It details how to effectively deploy tasks to servers under given mission requirements to maximize resource utilization and ensure smooth execution of tasks. By executing the target PAT, the system can achieve efficient resource management and optimization in a complex mission deployment environment, providing stable and reliable support for long-term missions. At the same time, the generation of the target PAT also provides valuable reference and reference for subsequent deployment optimization work.

[0056] The task deployment method, device, equipment, medium and product of the embodiment of the present application effectively solve the problem of low reliability of task deployment caused by static resource allocation and local optimal solution in traditional task deployment strategy by introducing dynamic iteration and parameter adjustment mechanism. The present application ensures that server resource allocation is closely matched with actual task requirements by continuously monitoring the dynamic changes of task requirements and adjusting the deployment strategy according to real-time task requirements and parameter conditions in each iteration cycle. By constructing a target available decision table (PAT) and selecting the optimal deployment strategy based on the principle of maximizing benefits, not only the utilization rate of server resources is improved, but also the number of task migrations and resource reallocations caused by resource mismatches is reduced. And through the optimization process across multiple iteration cycles, it is ensured that the overall optimal solution is achieved within the task requirement cycle, thereby enhancing the reliability of task deployment.

[0057] In one embodiment, the current task demand includes the current multi-dimensional resource availability of each server, the upper limit of each task's use of all resources, and the minimum demand threshold vector of each task; the current parameter condition includes the current multi-dimensional resource normalization weight of each task, and the current demand elasticity of each server;

[0058] The obtaining, according to the current task requirement and the current parameter condition, a first deployment strategy corresponding to the current task requirement includes:

[0059] Determine the demand for all resources for each task based on the upper limit of each resource used by each task and the normalized weight of the current multi-dimensional resources of each task;

[0060] Determining the available computing power of each server according to the current demand elasticity of each server and the current multi-dimensional resource availability of each server;

[0061] Determine the required computing power of each task based on the current multi-dimensional resource normalization weight of each task and the minimum required threshold vector of each task;

[0062] The mixed deployment constraint BRL algorithm based on bottleneck resource limitation obtains the first deployment strategy according to the demand of each task for all resources, the available computing power of each server and the required computing power of each task. The BRL algorithm is used to deploy the multiple tasks in a load-balanced manner among the multiple servers, and the standard deviation between the required computing power of the tasks deployed on the multiple servers is minimized.

[0063] Optionally, in the embodiment of the present application, firstly, according to the preset "iteration cycle" (such as once every 1-2 hours, which can be adjusted to 5-6 hours according to the model convergence situation), the task demand acquisition process is started regularly. In any iteration cycle, through the real-time monitoring and update mechanism, the available amount information of multi-dimensional resources (such as CPU, memory, storage, network bandwidth, etc.) of all current servers is collected to form a server resource state vector At the same time, the task list is updated to obtain the upper limit vector of each task's use of each resource. , these upper limits represent the amount of resources that the user purchases or allocates for the task. In addition, the system also evaluates and determines the minimum demand threshold vector for each task To ensure the minimum amount of resources required for the task to run normally. In order to manage resources more accurately, the system can also preliminarily evaluate and set the bottleneck resource vector of each task according to the task type and characteristics. , which helps to prioritize the allocation of bottleneck resources in subsequent deployment strategies. Through the above steps, the system can comprehensively and accurately obtain the current task requirements in any iteration cycle, providing a solid data foundation for the subsequent formulation of deployment strategies.

[0064] Optionally, in an embodiment of the present application, the bottleneck resource definition is one or several computer resources required by the task. For non-bottleneck resources, if the amount of allocated resources cannot meet the actual demand, the task running rate may be reduced; but for bottleneck resources, if the amount of allocated resources cannot meet the actual demand, the task cannot be run. Compared with other non-bottleneck resources, bottleneck resources have a more prominent effect on the running stability of tasks. Bottleneck resources can be a hard requirement of the task itself, or they can be later regulations to improve task performance. In the mixed-location constraints with bottleneck resource restrictions in multi-dimensional resource constraint scenarios, priority is given to whether the bottleneck resources can meet the constraints; at the same time, during calculation, the demand for bottleneck resources is assigned an accurate peak value to ensure that the task will not stop running due to resource constraints.

[0065] Optionally, in a feasible implementation of the present application, first, the system calculates the specific amount of resources actually required for each task through vector operations based on the upper limit of each task's use of various resources and the current multi-dimensional resource normalization weights of these tasks. This step ensures the accurate quantification of task resource requirements and provides basic data for subsequent deployment.

[0066] Next, the system considers the current demand elasticity of each server and its multi-dimensional resource availability to evaluate the server's available computing power. The demand elasticity reflects the server's flexibility and ability to cope with additional loads, while the resource availability directly determines the server's carrying capacity in its current state. By comprehensively considering these two factors, the system can more accurately grasp the actual computing power status of the server and provide strong support for task deployment.

[0067] After determining the resource requirements and computing power of tasks and servers, the system further calculates the required computing power of each task based on the current multi-dimensional resource normalization weight and minimum required threshold vector of each task. This step not only takes into account the overall resource requirements of the task, but also takes into account the minimum required threshold of the task for resources, ensuring the feasibility and stability of task deployment.

[0068] Finally, the system uses the Bottleneck Resource Limited (BRL) algorithm based on bottleneck resource restrictions to formulate the first deployment strategy. The core idea of ​​this algorithm is to achieve load balancing between servers and "peak-valley complementarity" of bottleneck resources by optimizing the task deployment plan, while meeting the task bottleneck resource requirements and the comprehensive computing power capacity of the server. Specifically, the algorithm first groups tasks according to their bottleneck resource types and computing power requirements to ensure that tasks with high requirements for the same type of resources are not overly concentrated on the same server, thereby avoiding resource conflicts and waste. Then, the algorithm continuously adjusts the task grouping and deployment plan through iterative optimization to minimize the standard deviation of the computing power actually used by each server, thereby achieving the purpose of load balancing.

[0069] Through the implementation of this series of steps, step S200 not only achieves accurate grasp and quantitative analysis of the current task requirements, but also obtains a first deployment strategy that meets the task requirements and achieves efficient resource utilization through the optimization calculation of the BRL algorithm. This strategy provides scientific and reasonable guidance for subsequent task deployment, ensuring the efficient operation and stable performance of the overall system.

[0070] Optionally, the mixed deployment constraint solution with bottleneck resource restrictions is a solution to deal with the situation with multi-dimensional resource requirements, which is caused by improper allocation of elastic coefficients, resulting in too many tasks in the server and reduced performance. By ensuring sufficient resource supply for each task's bottleneck resources, the running stability of the task can be stabilized under the situation of changing demand. Even if other non-bottleneck resources are preempted, the task can temporarily slow down its running rate instead of stagnating.

[0071] BRL is the algorithm used in this application to formulate the allocation matrix. This algorithm has two main characteristics. The first is that it avoids the large-scale deployment of tasks of the same type in the same server, and concentrates on using individual resources while keeping other resources idle. Relatively speaking, through this algorithm, various resource requirements of tasks will be mixed and deployed in a "peak-to-valley complementary" manner, which ensures the lower limit of resource utilization in a multi-dimensional resource mixed deployment scenario. The second is to provide an initial load-balanced allocation scheme for the reinforcement learning process mentioned, so that under this scheme, the frequent task scheduling caused by the shortage of server resources is reduced in advance, and the convergence speed of the reinforcement learning process is accelerated.

[0072] In these optional embodiments, by comprehensively considering the multi-dimensional resource requirements of the task, the resource availability and elasticity of the server, as well as the normalized weight and minimum requirement threshold of the task, the accuracy of task deployment and resource utilization are effectively improved. The BRL algorithm is used to perform mixed deployment constraints based on bottleneck resource restrictions, which not only ensures that the task load is evenly deployed on the server, but also achieves efficient resource utilization and stable operation of the system by minimizing the standard deviation of the task demand computing power between servers. This method significantly improves the flexibility and response speed of task deployment, reduces the risk of resource conflicts and waste, and provides strong support for task scheduling and resource management in complex environments.

[0073] In one embodiment, the hybrid BRL algorithm based on bottleneck resource restriction obtains the first deployment strategy according to the demand of each task for all resources, the available computing power of each server and the required computing power of each task, including:

[0074] According to the demand of each task for all resources, the demand of each task for the bottleneck resource corresponding to each task is obtained, wherein the bottleneck resource is a necessary resource for each task among all resources;

[0075] The number of servers required for the multiple tasks is calculated according to the first formula, where the first formula is: , where k is the number of servers required for the multiple tasks, The required computing power for each task, For each server’s available computing power, is the current demand elasticity corresponding to the j-th server, and n is the total number of the multiple servers;

[0076] According to the BRL algorithm, based on the demand for bottleneck resources of each task under the corresponding bottleneck resources, the multiple tasks are allocated to the required number of servers to obtain the first deployment strategy, wherein in the first deployment strategy, the standard deviation between the required computing power of the tasks deployed by the multiple servers is minimized.

[0077] Optionally, in a feasible implementation of the present application, in the implementation process of the BRL algorithm, the tasks are first sorted according to their bottleneck resource tags and computing power requirements, and then the number of servers required, that is, the number of groups, is preliminarily estimated. Next, the task requirement sequence is traversed, and the tasks are divided into several groups using the BRL constraint algorithm. The tasks in each group are relatively balanced in computing power requirements, and excessive concentration of similar tasks is avoided. Finally, an allocation matrix (i.e., the first deployment strategy) is generated to represent the results of the task grouping, which clearly shows which server group each task is assigned to.

[0078] Optionally, in an embodiment of the present application, in order to predict demand fluctuations caused by task changes and considering the repetitiveness and periodicity of task submission, the present application uses the idea of ​​"pre-deployment, then adjustment", first implements a deployment plan, and monitors changes in task demand and the arrival of new tasks, makes local adjustments based on specific circumstances, and uses the current deployment plan and plan performance records as input and feedback before adjustments, thereby solving the "periodic self-optimization" problem and achieving the next time a similar task demand appears, based on the parameter adjustment of the model, being able to select the deployment plan with the best estimated performance.

[0079] This application can infer possible future changes in task requirements based on historical data, and based on the predicted changes, give advance amounts in the deployment plan to reduce external fragmentation and possible task migration. This is an iterative strategy based on the periodicity of task requirements. It can train a reinforcement learning model based on historical deployment plans and changes in task requirements as input, and give a predictable and appropriate deployment plan when similar task requirements appear in the same period of the next cycle. In addition, the reinforcement learning model can summarize the time distribution of demand fluctuations based on historical demand changes, adjust the elasticity coefficient mentioned in Distinguishing Point 1 in advance, and improve resource utilization.

[0080] Specifically, this application seeks a hybrid solution B, so that in a certain state s, deploying tasks according to B can maximize the average resource utilization of the server. Since this problem is an NP problem and it is difficult to obtain the optimal solution through an algorithm, this application uses reinforcement learning technology to assist in solving it. The solution process can be described as follows: in state s, initially use the BRL constraint to obtain a preliminary strategy (i.e., an allocation matrix B), deploy it according to it, and evaluate the benefit r after a certain period of time (depending on the resource utilization and the time cost of task rescheduling), and calculate the Q value of strategy B and record it. Among them This Q value is standardized and used as a probability value to select a strategy for deployment in the next iteration. Therefore, the higher the Q value, the easier it is to adopt the strategy (i.e., a task allocation matrix B). After multiple rounds of iterations, the reinforcement model converges and the optimal solution in state s is obtained.

[0081] During the iteration process, there will be several rescheduling caused by changes in resource demand. The system records the allocation matrix after these rescheduling and records it in PAT as a possible strategy. Since the demand changes have a certain randomness, the reinforcement matrix will converge more slowly, but it also solves the problem of falling into the local optimal solution in non-convex problems to a certain extent.

[0082] Finally, the system gradually compresses the resource supply space of the task by modifying the elasticity parameter θ and the resource usage weight α of the task, and updates the state. At a certain state s, the model no longer converges. We believe that it is close to the upper limit of resource utilization and has obtained an approximate optimal solution.

[0083] In these optional embodiments, the BRL algorithm based on bottleneck resource restrictions effectively improves the efficiency of task deployment and resource utilization by accurately identifying the bottleneck resource requirements of the task. By calculating the match between the computing power required for the task and the available computing power of the server, the algorithm reasonably estimates and allocates server resources to ensure that the task can be deployed in a load-balanced manner. In addition, the algorithm also minimizes the standard deviation of the computing power required for tasks between servers by optimizing task grouping, further improving the stability and response speed of the system. This mixed deployment constraint strategy based on bottleneck resource restrictions not only helps to avoid resource waste and conflicts, but also can flexibly adjust the deployment plan according to the elasticity of server demand, providing strong support for task management and resource scheduling in complex environments.

[0084] In one embodiment, when the iteration cycle has not ended and the task requirements of any task to be deployed have changed, the current parameter conditions are adjusted, and a second deployment strategy is obtained according to the adjusted parameter conditions and the changed task requirements until the iteration cycle ends, and a first available decision table PAT corresponding to the iteration cycle is obtained, including:

[0085] When the iteration cycle has not ended and the task requirement of any task to be deployed has changed, adjusting the current parameter condition according to the type of change of the task requirement;

[0086] A second deployment strategy is obtained according to the adjusted parameter conditions and the changed task requirements until the iteration cycle ends, and the current state and the benefit corresponding to the current state are recorded, wherein the benefit is used to characterize the average actual resource utilization of each server and the total overhead of the task migration time in the iteration cycle when the first deployment strategy is adopted under the current state. The smaller the current benefit, the smaller the average actual resource utilization of each server, and the greater the total overhead of the task migration time; the current state includes the current multi-dimensional resource normalization weight of each task and the current demand elasticity of each server, and one current state corresponds to one task requirement;

[0087] The current state and the benefit corresponding to the current state are stored in the first available decision table PAT.

[0088] Optionally, in a feasible implementation of the present application, the challenges brought by changes in task requirements are effectively addressed through a dynamic adjustment mechanism within the iteration cycle. When the iteration cycle has not ended and the task requirements have changed, the current parameter conditions are first flexibly adjusted according to the type of demand change, such as the multi-dimensional resource normalization weights of the task and the server's demand elasticity, to quickly respond to demand fluctuations. Subsequently, based on the adjusted parameter conditions and the changed task requirements, the system recalculates and generates a second deployment strategy to ensure that resource allocation is always highly matched with task requirements. During the iteration process, the system continuously records the current state and its corresponding benefits, which comprehensively considers the average actual resource utilization of the server and the total overhead of the task migration time, providing a quantitative indicator for evaluating the effectiveness of the deployment strategy.

[0089] At the end of each iteration cycle, the system stores the current state and its benefit information in the first available decision table (PAT) as input data for the reinforcement learning model. Through reinforcement learning, the system can continuously optimize the policy parameters in the PAT and improve the ability to select the optimal deployment strategy under similar conditions. At the same time, the system also has the ability to monitor changes in demand. Once events such as fluctuations in task demand or the arrival of new tasks are detected, the rescheduling mechanism will be triggered immediately. Depending on the specific type of demand change, the system may respond by adjusting task weights, updating task and server lists, or adjusting server resource elasticity coefficients to ensure efficient use of resources and stable operation of tasks.

[0090] It is worth noting that when dealing with demand changes, the system gives priority to making local adjustments without affecting the current task operation, such as reallocation of server internal resources. Global rescheduling is considered only when local adjustments cannot meet the demand, and is performed uniformly at the end of the iteration cycle as much as possible to reduce the overhead of task migration and the impact on system stability. In addition, the system also provides valuable data support for subsequent performance analysis and optimization by recording information such as rescheduling time and current timestamp.

[0091] In summary, this embodiment achieves rapid response and efficient handling to changes in task requirements by introducing a dynamic adjustment mechanism and reinforcement learning optimization strategy within the iteration cycle, providing a more flexible and intelligent solution for task management and resource scheduling in complex environments.

[0092] In these optional embodiments, by accurately identifying the type of change and adjusting the parameter conditions in real time, new deployment strategies can be quickly generated to ensure efficient and balanced resource utilization. At the same time, the current status and corresponding benefits are recorded, providing valuable data support for optimizing decisions. This mechanism not only reduces resource waste and task delays caused by demand changes, but also continuously optimizes the decision table (PAT) through reinforcement learning, provides intelligent guidance for future decisions, realizes the intelligence and automation of resource management and task scheduling, and improves the stability and response speed of the overall system.

[0093] In one embodiment, the change type includes one of the following:

[0094] The resources of any server cannot meet the computing power required by the tasks deployed therein or the computing power required by the bottleneck resources corresponding to the deployed tasks;

[0095] A new task arrives and the remaining computing power of any server cannot meet the resource demand computing power of the new task;

[0096] The resource utilization of the multiple servers under the first deployment scheme is less than a preset threshold;

[0097] The adjusting of the current parameter conditions according to the change type of the task requirements includes:

[0098] When any server resource cannot meet the computing power of the tasks deployed therein or the computing power required by the bottleneck resources corresponding to the deployed tasks, the multi-dimensional resource normalization weights of the tasks with increased resource requirements are adjusted;

[0099] When a new task arrives and the remaining computing power of any server cannot meet the resource demand computing power of the new task, add a new server;

[0100] When the resource utilization of the multiple servers under the first deployment solution is less than a preset threshold, the demand elasticity of each server is adjusted.

[0101] In these optional embodiments, by carefully distinguishing the types of task demand changes and adjusting parameter conditions in a targeted manner, the flexibility of resource allocation and the efficiency of system operation are effectively improved. When resources are insufficient, the task weights are adjusted or new servers are added to ensure smooth execution of tasks; when resources are in excess, the elasticity of server demand is adjusted to promote balanced resource utilization. This dynamic adjustment mechanism not only reduces resource waste, but also improves the response speed and stability of the system, providing a more intelligent and efficient solution for task management and resource scheduling in complex environments.

[0102] In one embodiment, when the multiple iteration cycles within the task requirement cycle are all completed and the preset convergence condition is met, the target PAT is obtained according to the multiple optimal deployment strategies corresponding to the multiple task requirements within the task requirement cycle, including:

[0103] When multiple iteration cycles within the task requirement cycle are completed, if the same deployment strategy is selected under any task requirement within a continuous preset number of task requirement cycles, the current parameter conditions under the first requirement are adjusted, and the first available decision table PAT is adjusted according to the adjusted parameter conditions and the first requirement; until the first available decision table PAT does not change under the first requirement, the target PAT is obtained according to multiple optimal deployment strategies corresponding to multiple task requirements within the task requirement cycle, and the first requirement is any task requirement.

[0104] Optionally, in a feasible implementation of the present application, after the task demand cycle ends, the stability and optimization space of the current strategy are evaluated by continuously observing the convergence of the deployment strategy in multiple iteration cycles. When it is found that the same deployment strategy is selected continuously under multiple similar task demand states, it is considered that the reinforcement learning decision has converged. At this time, the multi-dimensional resource normalization weight and server resource elasticity coefficient of the task are actively adjusted to explore a deployment scheme with higher resource utilization. This adjustment process gradually fine-tunes the parameters (such as reducing the task resource weight and increasing the server resource elasticity) to enable the system to enter a new state and re-iterate convergence. After multiple iterations, when the system can no longer further optimize resource utilization in a certain state, it is considered that it is close to the upper limit of resource utilization. At this time, based on multiple optimal deployment strategies corresponding to multiple task requirements in the task demand cycle, the target PAT (available decision table) is generated. This process not only improves the adaptive ability of the system, but also ensures the efficient utilization of resources and the stable operation of tasks through continuous optimization.

[0105] In these optional embodiments, after selecting a stable deployment strategy in a continuous task demand cycle, the parameters are actively adjusted to explore a better solution until a new stable state is reached. This process not only accelerates the adaptability to complex environments, but also ensures that the target PAT (available decision table) can accurately reflect the optimal deployment strategy under each task requirement through continuous iterative optimization, thereby improving the accuracy of resource allocation and the overall operating efficiency of the system. In addition, by adjusting parameter conditions and updating PAT, the system can continuously approach the optimal solution for resource utilization, providing strong support for future task deployment.

[0106] In order to better illustrate the task deployment method provided by this application, a specific embodiment is described below:

[0107] This application seeks to find a solution for mixed task deployment, so that each server can achieve the highest average resource utilization rate possible in a certain period of time to meet the task requirements at that time. Among them, the total required computing power of tasks deployed on the same server at the same time shall not exceed the elastic computing power available on the server (e.g. elastic computing power = actual computing power × θ, the specific value can be adjusted according to demand fluctuations and scenarios, such as θ = 120%). The above problem is now expressed mathematically:

[0108] Table 1: Parameter mapping table (all vectors are column vectors by default)

[0109] The following uses the ratio of "actual computing power" to "total computing power" to represent the utilization rate of resources in the server. Comprehensive computing power is defined as a normalized quantitative standard for the multi-dimensional resources required by a server or a task. It is used to evaluate the comprehensive resource supply / demand of a server or a task. The calculation method is as follows:

[0110]

[0111] in Represents the normalization parameter for n-dimensional resources, which is the weight of each resource in the calculation of comprehensive computing power (by default, the units of each type of resource have been standardized to maintain a uniform magnitude), which can be adjusted by the system according to specific circumstances during the iteration process; Represents the resource demand vector of the task; C represents the computing power.

[0112] This system model includes: Tasks exist Data center servers In the above, a total of Class I resources are required. (hereinafter, );

[0113] Calculate the available computing power of each server, for any :

[0114]

[0115] Calculate the computing power required for each task, for any :

[0116]

[0117] Alternatively, calculate the available computing power of each server and :

[0118]

[0119] Similarly, the computing power required for each task is calculated for any :

[0120]

[0121] in, for dimensional vector, each element of which is assigned a value using the BRL constraint, based on the bottleneck resource vector of application i The position of mark 1, assignment The value of the element at the corresponding position; The 0 position is assigned The value of the element at the corresponding position; (such as: );

[0122] The purpose of this application is to find an allocation scheme, represented as an allocation matrix (Composed of 0 and 1, indicating which server each task is deployed to. ), so that the average resource utilization of each server is maximized. The objective function is as follows:

[0123]

[0124]

[0125] in, Corresponding vectors The kth element of Refers to the average resource usage of each server. It represents the resource utilization rate of server j, and the calculation formula is as follows:

[0126]

[0127] It can be seen from the above objective function that the problem being solved is a "combinatorial optimization problem", which is an NP-hard problem with a time complexity of O(n!). The solution space is extremely large, and it is difficult to calculate the optimal solution through known algorithms. However, since task requirements have a certain periodic regularity, such as the similarity of the daily demand peak and trough distribution, it can be optimized based on historical data and iterated to obtain an approximate optimal solution. And if the allocation state is required to maintain the greatest possible resource utilization under the condition of task demand fluctuations over a period of time, it is necessary to frequently adjust task deployment and perform scheduling, which is costly and not worth the cost. Therefore, this application can use the following two methods to solve the above problem in an approximate optimal solution.

[0128] This application can use BRL to replace the multi-dimensional resource constraints in the above problem. Compared with the hard constraints on each dimension of resources, BRL only ensures that the bottleneck resources of each task can be fully supplied, and at the same time imposes overall constraints on the comprehensive computing power. This can simplify the computational complexity while bringing a certain degree of flexibility to hybrid deployment and improve the actual resource utilization of the server.

[0129] In addition, the present application can also meet the load balancing of each server through the BRL algorithm, and then use the reinforcement learning model to record the performance benefit r of the current allocation plan based on the historical data of the detection (including the allocation matrix, resource utilization, the duration of resource shortage or surplus, etc.), and iteratively tune the allocation plan of the mixed task, so that after the iteration of the reinforcement learning model, the probability of external fragmentation in the server can be reduced, the scheduling cost can be controlled, and the resource utilization rate can be improved at the same time, approaching the overall optimal solution.

[0130] like Figure 2 As shown, in a complete embodiment, the following steps are included:

[0131] Step 1: Regular deployment cycle begins: Regular deployment refers to iterative global deployment based on a predetermined period of time (such as 6 or 8 hours). This approach can comprehensively consider the deployment plan based on the needs of each task and the server capacity, and iterate and optimize based on historical cycle performance. Note: Please distinguish between the "state iteration cycle" and the "task demand fluctuation cycle". The task demand fluctuation cycle (i.e., task demand cycle) refers to the cycle of fluctuations in task demand changes. It has a certain degree of repeatability and exists objectively, such as 0:00-23:59 every day as a cycle. The state iteration cycle (i.e., iteration cycle) refers to the cycle for global redeployment evaluation (i.e., Figure 2 The cycle described in the previous section is initially set at 1-2 hours for iterating the reinforcement learning model. After the model converges and stabilizes, it is increased to 5-6 hours to reduce the time overhead caused by frequent global deployment. The following steps 2-11 represent the process within a state iteration cycle.

[0132] Step 2: Obtain requirements: monitor and update the current server and task list, and update the available vector of the server's multi-dimensional resources and the upper limit vector of each resource used by the task (the upper limit of resources purchased by the user); determine the minimum demand threshold vector for each task (Evaluable). Evaluate the bottleneck resource vector of each task (Initially, one resource is allocated as the bottleneck resource for each type of task based on experience, such as bandwidth for delay-sensitive tasks and CPU for computationally intensive tasks).

[0133] Step 3: Formulate a plan: Obtain the normalized parameter matrix of the current multidimensional resource , and the degree of demand elasticity , here and After initialization ( The normalized weights of various resources in are initialized to 1. The elasticity of each server is initially set to 100%), and the resource demand vector of each task is calculated:

[0134]

[0135] The "*" indicates the corresponding multiplication of the elements of the two vectors; calculate the computing power required for each server And the computing power required for each task , the calculation formula is as follows:

[0136] , .

[0137] Use the BRL constraint algorithm to formulate a colocation plan: In this algorithm, the original objective function is relaxed to solve the goal. That is, the server's capacity for all types of resources is not considered for the time being. Only the bottleneck resource requirements for each task and the comprehensive computing capacity are considered. Under the premise of meeting the above requirements, the allocation matrix is ​​solved.

[0138] The allocation matrix requires that the actual computing power load of each server is balanced while the bottleneck resources are "peak-to-valley complementary". The computing power load is required to be balanced because the initial constraint parameters a and θ are determined by experience and may not conform to the actual scenario. The relatively loose load pressure on the server can reduce the possibility of the system rescheduling a large number of tasks when the task requirements change. The requirement for "peak-to-valley complementary" bottleneck resources is because different tasks focus on different types of resources. The BRL algorithm will avoid deploying similar tasks on the same server (such as deploying a large number of computing-intensive tasks on the same server, which have high CPU resource requirements but less bandwidth requirements, which will cause a large amount of idle bandwidth resources in the server. In contrast, mixing computing-intensive tasks and I / O tasks (with high bandwidth requirements and low CPU requirements) can maximize the utilization of multiple types of resources in the server).

[0139] The specific method of the BRL algorithm is to combine tasks according to the "peak-valley complementarity" of bottleneck resources, so that the standard deviation of the total computing power of tasks distributed on each server is minimized. The task grouping here uses the following steps: 1) Mark the tasks according to their bottleneck resources and arrange them in descending order of computing power requirements; 2) Preliminary estimate of the number of servers required (i.e. the number of groups, ),in , round up, here we assume that the server capacity is basically the same, and use the average server computing capacity to estimate the computing capacity of a single server; 3) traverse the task demand sequence and divide the tasks into The group is formed (using the BRL constraint algorithm as shown below), so that the standard deviation of the sum of the computing power required by each group is minimized, and there are not a large number of similar tasks in the same group. Finally, the grouping result is expressed as an allocation matrix Output; Matrix It can be understood that m tasks are divided into k groups. Each column corresponds to a group, consisting of 0 and 1. The tasks in the group are marked as 1, otherwise they are marked as 0.

[0140] Step 4: Record the solution. The data recorded here includes the parameters used in the first two steps. and , Resource Demand Matrix , and the current resource allocation matrix .in Corresponding tasks The normalized weight vector of multi-dimensional resources, Corresponding servers degree of elasticity.

[0141] Step 5: Implement deployment and deploy each task to each server according to the allocation matrix. The specific allocation method is as follows: 1) Fill to n columns, that is ,yes The augmented matrix of is a zero matrix; 2) sequentially traverse the allocation matrix For each column (i.e. each group), for the i-th column , calculate the sum of the required computing power of the tasks in this group ; 3) Deploy k valid groups in n servers, and the available computing power of the servers is , arrange the server capacities in order, and for each group, select the first server deployment that can accommodate the traversal; 4) After each group in the , selects the corresponding server, record the allocation matrix of each group deployed in the server at this time As the available strategy for the current state s, it is added to PAT, and the initial Q value is 1. The available strategy table is used as the available strategy library for reinforcement learning. In the next same state s, the strategy deployment in PAT is selected according to the probability based on the Q value.

[0142] Step 6: After a period of time, determine whether the regular deployment cycle has ended. If the timer has not reached the scheduled time, proceed to step 7; if the timer reaches the scheduled time, end this cycle and record the current status <id, start timestamp, cycle duration T, each task requirement matrix , each server capacity matrix , multi-dimensional resource weight parameter matrix a, server capacity elasticity parameter set θ>, take the allocation matrix as the current policy, and obtain the return of taking the policy in state s , where represents the average actual resource utilization rate of each server, and c represents the total overhead of task migration time in this cycle. When the task migration overhead is large and the resource utilization rate is low, r takes a lower value; otherwise, r takes a higher value. Input the return r into the reinforcement learning model to update the parameters of the PAT table (the available policy table is introduced in step 11):

[0143] ,

[0144] where refers to the Q value obtained when taking a certain policy in the next state , , represents the L2 norm of the cosine similarity between matrices . The closer it is to 0, the lower the similarity degree of the two matrices. At the same time, record the task allocation state at the end of the cycle, which is represented as the allocation matrix, record it in the available policy table PAT, save it to the system, and use it as the optional policy in state s. Enter the next cycle. In the following iterative process, select the policy according to the probability after normalizing the Q value;

[0145] Step 7: Listen for demand changes. Here, demand changes include the demand fluctuations of deployed tasks, as well as ended tasks and newly arrived other tasks.

[0146] Step 8: Determine whether there is a demand change. If not, return to step 6 to listen to the timing cycle timer; if there is a demand change, enter step 9.

[0147] Step 9: Determine whether the demand change triggers the listening conditions, which mainly include 3 categories: 1) The server resources cannot meet the computing power or bottleneck resource requirements of the task growth; 2) New tasks arrive and the remaining computing power of any server cannot meet their resource requirements; 3) Most servers are idle and the resource utilization rate is too low. If the above 3 conditions are not triggered, the system adapts to the demand change (allocate more resources or recycle resources within the server) and returns to step 7; if the conditions are triggered, enter step 10.

[0148] Step 10: Record the rescheduling time and the current timestamp. Record the conditions triggered in step 9, and record the duration from the deployment of the current plan at this time.

[0149] Step 11: The system can handle the three rescheduling conditions listed in step 9 in the following three ways:

[0150] 1) Modify tasks that have increased resource requirements The weight vector , for one or more types of resources that are in short supply, increase their weight in calculating the comprehensive computing power. For example: for resource l, the corresponding weight a was originally set to 0.5. Later, it was found that due to the increase in demand for l, the server could not fully supply all the tasks in it, so the increased tasks were migrated to other idle servers with sufficient resources. After the task migration, the task allocation state after task scheduling is represented as the allocation matrix available under the current state s Recorded in the available strategy table PAT. The function of the available strategy table is to expand the available strategy library of reinforcement learning. In the next same state s, the strategy deployment in PAT is selected according to the probability based on the Q value. After the end, return to step 7.

[0151] 2) Update the task and server list, add or delete tasks or servers. This method is used when new tasks are migrated or server failures occur, resulting in the remaining computing power of the server being unable to meet the needs of undeployed tasks. In this case, the colocation solution needs to be re-evaluated. However, since this proposal mainly considers the colocation of long-term tasks, task flow scheduling problems rarely occur, and there are usually idle servers to meet emergencies, so there is no need for global rescheduling.

[0152] 3) Adjust the server Resource elasticity coefficient This action is applied when the utilization of most servers is low. When make .

[0153] After performing methods 2) and 3), steps 2-6 need to be repeated to re-plan the deployment plan, update the state s, and then represent the re-scheduled task allocation state as the allocation matrix Recorded in the available strategy table PAT. However, this process causes all tasks to be suspended and redeployed to new servers, which has a large overhead. Therefore, unless the task performance is seriously degraded, it is generally best not to adjust the parameters during the cycle, but to make unified adjustments at the end of the cycle based on the operation status during the cycle.

[0154] Supplementary step: After a cycle, if it is found that the resource requirements of each task can be met, the operation is stable, and the reinforcement learning decision converges (the same deployment strategy is selected in several consecutive similar states), the state in method 1) and 3) in step 11 can be actively performed in the next same state. The weight vector in and elastic modulus Adjustment, with the updated state Replace the original state, re-iterate convergence in the new state, and optimize the colocation solution in the new state to try to achieve higher resource utilization. The specific adjustments are: , ,in .

[0155] Finally, after multiple iterations, the system gradually compresses the resource supply space of the task by modifying the elasticity parameter θ and the resource usage weight α of the task, and updates the state. If the model no longer converges, it can be considered that The upper limit of resource utilization is approached and a near optimal solution is obtained.

[0156] Case 1 (the steps here correspond to the steps in the above process):

[0157] Step 1: Assume that there are currently 6 tasks and 4 available servers. Set 24 hours a day as a task demand fluctuation cycle and every 2 hours as a state iteration cycle. Consider multi-dimensional resources including (storage space (PB), memory (GB), CPU (number of cores), processing frequency (GHz), bandwidth (Gbps)). The resource requirements / capacity are as follows:

[0158] Step 2: The server capacities are:

[0159] Table 2: Task List

[0160] Standardization: Standardize the demand values ​​of various resources to the same order of magnitude for the next step of calculation. The standardization method is For the convenience of representation, the calculation results of this case are rounded to integers. The processed data are as follows:

[0161] Table 3: Task List

[0162] The server capacity is:

[0163] Step 3: Initial Resource Weight Matrix :

[0164] Table 4: Initial resource weight matrix

[0165] Initial server elasticity parameters .

[0166] Compute the task resource requirement vector , since the resource weight matrix All elements are 1, and Consistent (list display omitted here).

[0167] Computational power:

[0168] , .

[0169] The server's computing power is 250, and the required computing power for tasks 1-6 is 25, 47, 74, 95, 107, and 157 respectively. Calculate the number of groups , where n is the number of servers (4), and the result is rounded up, the number of groups is 3.

[0170] Use the BRL algorithm to calculate the allocation matrix and record the allocation matrix :

[0171]

[0172] At this time, the resource capacity and computing capacity of each server are as follows:

[0173] Table 5: Resource and computing capacity of each server

[0174] Step 4: Record the parameters of state s1 at this time: s1=<0, 2:00, 2, , , , >.

[0175] Step 5: Assign the matrix ,Will Padding to augmented matrix , and distribute them to the servers accordingly to get the distribution matrix = .

[0176] The distribution matrix The strategy for the current state s1 is stored in PAT. Initially 1, PAT table (there are 12 states in PAT at this time, but it has not been actually experienced at this time, so the Q value of other states is 0, which is omitted here, and only the modification after adding B is shown:

[0177] Table 6: PAT table

[0178] Step 6: After 2 hours, the state cycle ends. This stage does not trigger rescheduling (because each task is initially assigned the maximum resource demand limit). The allocation matrix at the end of the settlement cycle is still B because no rescheduling occurred during the period. The Q value is updated as follows:

[0179] ,

[0180] Since the Q value of the next state s2 is 0, ,function It can be determined according to the needs. The calculation is omitted here. The design result is 1.2, and the PAT value is updated. (In the next state s1, PAT is used to determine the deployment strategy. For the available strategies under s1, the Q value is first standardized to a probability between 0 and 1, and then randomly selected according to the probability).

[0181] Supplementary stage: After several days, since the allocation scheme B is the only strategy in the current state and is used several times, it is detected that the resource utilization rate of this state iteration cycle is low. The reasons are as follows: 1) It is 2:00 a.m. on a certain day, which is a low period, and the actual resource usage of each task does not meet the demand; 2) The server itself has a large amount of idle resources; at this time, the parameters of state s1 are actively adjusted and ,like:

[0182] 1) Adjust the server elasticity factor , ,for . .

[0183] 2) Adjustment , reduce the weight coefficient of non-bottleneck resources, such as:

[0184] Table 7: Adjusted resource weight matrix

[0185] In this case, make the above adjustments, update the parameters of state s1, and use the parameters in the next iteration of s1. Reset the Q values ​​of all strategies in state s1 in strategy PAT to 0.

[0186] Case 2 (This case supplements steps 7-11 not covered in Case 1):

[0187] This case assumes the scenario after several rounds of iterations of Case 1, so the state cycle, task requirements and server capacity are the same as those in Case 1. Assume that at 18:00 on a certain day, state s10 starts, s10=<9, 18:00, 2, , , , >, here , for:

[0188] Table 8:

[0189] The allocation matrix B1 (strategy) is selected in PAT according to probability as follows:

[0190]

[0191] From B1, we can see that tasks 1, 3, and 6 are deployed on server 1, and tasks 2, 4, and 5 are deployed on server 2. At this time, the server computing power usage status is as follows (due to the elasticity coefficient, the computing power capacity may be greater than the total capacity):

[0192] Table 9: Server list:

[0193] Step 6: The state iteration cycle has not ended, so go to step 7.

[0194] Step 7: Monitor the fluctuation status of each demand.

[0195] Step 8: If demand changes, go to Step 9.

[0196] Step 9: Assume that the number of CPU cores required for task 3 increases to 256, which exceeds the resource capacity of the server.

[0197] Step 10: Record the timestamp and the event that occurred, that is, Task 3 needs to be scheduled.

[0198] Step 11: Since tasks 1, 3, and 6 are deployed on the same server and the resource supply is tight, task 3 performs poorly due to insufficient CPU cores. Task 3 is now migrated to server 3. Record the allocation matrix B2 after migration:

[0199]

[0200] Record B2 in PAT with an initial Q value of 1. Return to step 6.

[0201] Step 6: After a period of time, the cycle ends and the current allocation matrix B2 is checked. The Q value of B2 is calculated and updated as in Case 1. If the Q value of B2 is higher than that of B1, then in the next s10 state, B2 is selected as the allocation scheme at the beginning of the s10 state.

[0202] Optionally, in the embodiment of the present application, since the demand has a certain fluctuation range over time, its range is between a given minimum threshold and an expected peak value. The present application improves the elasticity of the available computing power of each server during the low period of task demand (such as the early morning period), that is, when the actual resource amount of the container remains unchanged, the constraint on the accommodating computing power is relaxed, so that a container can deploy more tasks (at this time, the actual use of computing power of a single task is less than its required computing power), in order to achieve the purpose of improving resource utilization (in the busy period of task demand, the elasticity is relatively reduced, and spare computing power is reserved for each task). Among them, computing power refers to the unit of comprehensive quantification of multi-dimensional computer resources (such as CPU, memory, bandwidth, I / O interface, etc.). Considering that computing power is a standard for comprehensively measuring various types of computer resources, in order to avoid the comprehensive computing power being accommodating but individual types of resources being overloaded, it is also necessary to pay attention to detecting each dimension for specific demand constraints. In addition, in order to avoid the decrease in task operation stability due to the increase in elasticity, which causes the container to accommodate too many tasks, the present application uses a mixed deployment constraint algorithm with bottleneck resource restrictions. When performing mixed deployment combination of tasks, the bottleneck resource of each task is used as the primary constraint of the mixed deployment combination.

[0203] In these optional embodiments, in a mixed deployment scenario where task demands fluctuate, the supply elasticity of server resources is dynamically adjusted according to demand changes, and the intensity of resource demand is adapted in real time. During the trough period of task resource demand, a large amount of idle resources can be detected in time, and the capacity of computing power can be relaxed, and the task flow can be informed that it has the ability to accommodate more tasks, thereby improving resource utilization. During the peak period of resource demand, the operating status of the accommodated tasks can be detected in time, the constraints on computing power demand can be increased, and sufficient spare resources can be reserved for the tasks to avoid resource preemption, thereby ensuring the stability of task operation in the context of resource oversale.

[0204] In actual scenarios, long-term tasks deployed in servers have certain volatility and regularity in resource demand. In order to cope with the oversale of resources that may occur during the low demand period and improve resource utilization, this application sets an elasticity coefficient for each server. , which is expressed as . It changes periodically over time according to the actual resource usage of the tasks deployed in the server. , making the visible capacity of the server larger than the actual capacity, so as to accommodate more tasks when deploying tasks and improve resource utilization. At this time, the actual resource usage of the task is less than the demand, so the quality can still be guaranteed in actual operation. Relatively speaking, during peak hours, this coefficient , task deployment is carried out under the premise of reserving spare resources to ensure that there is no shortage of supply within the server.

[0205] Optionally, in an embodiment of the present application, the present application can improve the decision-making system's ability to cope with demand fluctuations in deployment scenarios for long-term tasks. The present application uses the proposed elastic resource supply strategy to dynamically adjust the supply elasticity of server resources according to demand changes, adapt to resource demand intensity in real time, and ensure the flexibility of resource allocation, so as to achieve the purpose of improving server resource utilization.

[0206] Moreover, the present application can periodically collect historical data, summarize the changing trends of task requirements through the above-mentioned demand prediction-based self-optimizing deployment strategy, and speculate on possible changes in task requirements, so as to provide advance amounts in the deployment plan, reduce external fragmentation problems, reduce scheduling costs caused by possible task migration, and improve the reliability of the deployment plan.

[0207] In the scenario of multi-dimensional resource colocation, this application uses the idea of ​​"resource demand complementarity" to differentiate each task according to the "bottleneck resources" of its prominent demand, and tries not to deploy tasks with the same bottleneck resources in the same container as much as possible. This method avoids the same type of tasks from preempting a certain resource, while maximizing the use of various types of computer resources in the container, thereby improving the overall resource utilization rate.

[0208] Based on a task deployment device provided in the above embodiment, accordingly, Figure 3 As shown, an embodiment of the present application provides a task deployment device, which may include:

[0209] An acquisition module 301 is used to acquire the current task requirement in any iteration cycle, and multiple iteration cycles constitute a task requirement cycle;

[0210] A first determination module 302 is used to obtain a first deployment strategy corresponding to the current task requirement according to the current task requirement and the current parameter condition, wherein the first deployment strategy is used to deploy multiple tasks in multiple servers, and the current parameter condition includes current weights corresponding to the multiple tasks and the multiple servers respectively;

[0211] The second determination module 303 is used to adjust the current parameter conditions and obtain a second deployment strategy according to the adjusted parameter conditions and the changed task requirements when the iteration cycle has not ended and the task requirements of any task to be deployed have changed, until the iteration cycle ends, and obtain a first available decision table PAT corresponding to the iteration cycle, wherein the first available decision table PAT includes the benefits corresponding to the task requirements executed in the iteration cycle, and the benefits are positively correlated with the resource utilization of the server corresponding to the task requirements executed in the iteration cycle;

[0212] The deployment module 304 is used to obtain a target PAT according to multiple optimal deployment strategies corresponding to multiple task requirements within the task requirement cycle when multiple iteration cycles within the task requirement cycle are completed and the preset convergence condition is met, and perform task deployment according to the target PAT, wherein each optimal deployment strategy is the highest benefit corresponding to each task requirement, and the preset convergence condition is determined according to the first available decision table PAT corresponding to each iteration cycle.

[0213] In one embodiment, the current task demand includes the current multi-dimensional resource availability of each server, the upper limit of each task's use of all resources, and the minimum demand threshold vector of each task; the current parameter condition includes the current multi-dimensional resource normalization weight of each task, and the current demand elasticity of each server; the first determination module 302 may include:

[0214] The first determination submodule is used to determine the demand of each task for all resources according to the upper limit of each task's use of each resource and the normalized weight of the current multi-dimensional resources of each task;

[0215] A second determination submodule is used to determine the available computing power of each server according to the current demand elasticity of each server and the current available multi-dimensional resources of each server;

[0216] A third determination submodule is used to determine the required computing power of each task according to the current multi-dimensional resource normalization weight of each task and the minimum required threshold vector of each task;

[0217] The fourth determination submodule is used to obtain the first deployment strategy based on the mixed deployment constraint BRL algorithm based on bottleneck resource restrictions according to the demand of each task for all resources, the available computing power of each server and the required computing power of each task. The BRL algorithm is used to deploy the multiple tasks in a load-balanced manner among the multiple servers, and the standard deviation between the required computing power of the tasks deployed on the multiple servers is minimized.

[0218] In one embodiment, the fourth determining submodule may include:

[0219] A first acquisition unit is used to acquire the bottleneck resource demand of each task under the corresponding bottleneck resource according to the demand of each task for all resources, wherein the bottleneck resource is a necessary resource for each task among all resources;

[0220] The first calculation unit is used to calculate the number of servers required for the multiple tasks according to the first formula, where the first formula is: , where k is the number of servers required for the multiple tasks, The required computing power for each task, For each server’s available computing power, is the current demand elasticity corresponding to the j-th server, and n is the total number of the multiple servers;

[0221] The first determination unit is used to allocate the multiple tasks to the required number of servers based on the demand for bottleneck resources of each task under the corresponding bottleneck resources in accordance with the BRL algorithm, so as to obtain the first deployment strategy, wherein in the first deployment strategy, the standard deviation of the required computing power of the tasks deployed by the multiple servers is minimized.

[0222] In one embodiment, the second determining module may include:

[0223] A first adjustment submodule is used to adjust the current parameter condition according to the change type of the task requirement change when the iteration cycle has not ended and the task requirement of any task to be deployed has changed;

[0224] A recording submodule is used to obtain a second deployment strategy according to the adjusted parameter conditions and the changed task requirements until the end of the iteration cycle, and record the current state and the benefit corresponding to the current state, wherein the benefit is used to characterize the average actual resource utilization of each server and the total overhead of the task migration time in the iteration cycle when the first deployment strategy is adopted under the current state. The smaller the current benefit, the smaller the average actual resource utilization of each server, and the greater the total overhead of the task migration time; the current state includes the current multi-dimensional resource normalization weight of each task and the current demand elasticity of each server, and one current state corresponds to one task requirement;

[0225] The storage submodule is used to store the current state and the benefit corresponding to the current state in the first available decision table PAT.

[0226] In one embodiment, the change type includes one of the following:

[0227] The resources of any server cannot meet the computing power required by the tasks deployed therein or the computing power required by the bottleneck resources corresponding to the deployed tasks;

[0228] A new task arrives and the remaining computing power of any server cannot meet the resource demand computing power of the new task;

[0229] The resource utilization of the multiple servers under the first deployment scheme is less than a preset threshold; the first adjustment submodule may include:

[0230] A first adjustment unit is used to adjust the multi-dimensional resource normalization weight of the task with increased resource demand when any server resource cannot meet the increased computing power of the task deployed therein or the required computing power of the bottleneck resource corresponding to the deployed task;

[0231] The second adjustment unit is used to add a new server when a new task arrives and the remaining computing power of any server cannot meet the resource requirement computing power of the new task;

[0232] A third adjustment unit is configured to adjust the demand elasticity of each server when the resource utilization of the multiple servers under the first deployment solution is less than a preset threshold.

[0233] In one embodiment, the deployment module 304 may include:

[0234] A deployment submodule is used to adjust the current parameter conditions under the first requirement if the same deployment strategy is selected under any task requirement within a preset number of consecutive task requirement cycles when multiple iteration cycles within the task requirement cycle are completed, and adjust the first available decision table PAT according to the adjusted parameter conditions and the first requirement; until the first available decision table PAT does not change under the first requirement, the target PAT is obtained according to multiple optimal deployment strategies corresponding to multiple task requirements within the task requirement cycle, and the first requirement is any task requirement.

[0235] The technicians in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In practical applications, the above-mentioned function allocation can be completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated in a processing unit, or each unit can exist physically separately, or two or more units can be integrated in one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, which will not be repeated here.

[0236] Figure 4 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present application is shown.

[0237] The device may include a processor 401 and a memory 402 storing program instructions.

[0238] When the processor 401 executes the program, the steps in any of the above method embodiments are implemented.

[0239] Exemplarily, the program may be divided into one or more modules / units, one or more modules / units are stored in the memory 402, and executed by the processor 401 to complete the present application. One or more modules / units may be a series of program instruction segments capable of completing a specific function, and the instruction segments are used to describe the execution process of the program in the device.

[0240] Specifically, the processor 401 may include a central processing unit (CPU), or an application specific integrated circuit (ASIC), or may be configured to implement one or more integrated circuits of the embodiments of the present application.

[0241] Memory 402 may include a large capacity memory for data or instructions. By way of example and not limitation, memory 402 may include a hard disk drive (HDD), a floppy disk drive, a flash memory, an optical disk, a magneto-optical disk, a magnetic tape, or a universal serial bus (USB) drive or a combination of two or more of these. In appropriate cases, memory 402 may include a removable or non-removable (or fixed) medium. In appropriate cases, memory 402 may be inside or outside of an integrated gateway disaster recovery device. In a specific embodiment, memory 402 is a non-volatile solid-state memory.

[0242] The memory may include read-only memory (ROM), random access memory (RAM), magnetic disk storage media devices, optical storage media devices, flash memory devices, electrical, optical or other physical / tangible memory storage devices. Thus, typically, the memory includes one or more tangible (non-transitory) readable storage media (e.g., memory devices) encoded with software including computer executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method according to an aspect of the present disclosure.

[0243] The processor 401 implements any one of the methods in the above embodiments by reading and executing program instructions stored in the memory 402 .

[0244] In one example, the electronic device may further include a communication interface 403 and a bus 410. The processor 401, the memory 402, and the communication interface 403 are connected via the bus 410 and communicate with each other.

[0245] The communication interface 403 is mainly used to implement communication between various modules, devices, units and / or equipment in the embodiments of the present application.

[0246] Bus 410 includes hardware, software or both, and the parts of online data flow billing equipment are coupled to each other. For example, but not limitation, bus may include accelerated graphics port (AGP) or other graphics bus, enhanced industrial standard architecture (EISA) bus, front-side bus (FSB), hypertransport (HT) interconnection, industrial standard architecture (ISA) bus, infinite bandwidth interconnection, low pin count (LPC) bus, memory bus, micro channel architecture (MCA) bus, peripheral component interconnection (PCI) bus, PCI-Express (PCI-X) bus, serial advanced technology attachment (SATA) bus, video electronics standard association local (VLB) bus or other suitable bus or two or more of these combinations. In appropriate cases, bus 410 may include one or more buses. Although the present application embodiment describes and shows a specific bus, the present application considers any suitable bus or interconnection.

[0247] In addition, in combination with the method in the above embodiment, the embodiment of the present application can provide a storage medium for implementation. The storage medium stores program instructions; when the program instructions are executed by a processor, any one of the methods in the above embodiment is implemented.

[0248] An embodiment of the present application further provides a chip, which includes a processor and a communication interface, wherein the communication interface and the processor are coupled, and the processor is used to run programs or instructions to implement the various processes of the above-mentioned method embodiment, and can achieve the same technical effect. To avoid repetition, it will not be repeated here.

[0249] It should be understood that the chip mentioned in the embodiments of the present application can also be called a system-level chip, a system chip, a chip system or a system-on-chip chip, etc.

[0250] An embodiment of the present application provides a computer program product, which is stored in a storage medium. The program product is executed by at least one processor to implement the various processes of the above-mentioned method embodiment and can achieve the same technical effect. To avoid repetition, it will not be repeated here.

[0251] It should be clear that the present application is not limited to the specific configuration and processing described above and shown in the figures. For the sake of simplicity, a detailed description of the known method is omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present application is not limited to the specific steps described and shown, and those skilled in the art can make various changes, modifications and additions, or change the order between the steps after understanding the spirit of the present application.

[0252] The functional modules shown in the above block diagram can be implemented as hardware, software, firmware or their combination. When implemented in hardware, it can be, for example, an electronic circuit, an application specific integrated circuit (ASIC), suitable firmware, a plug-in, a function card, etc. When implemented in software, the elements of the present application are programs or code segments that are used to perform the required tasks. Programs or code segments can be stored in machine-readable media, or transmitted on a transmission medium or a communication link by a data signal carried in a carrier wave. "Machine-readable media" can include any medium that can store or transmit information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, optical fiber media, radio frequency (RF) links, etc. Code segments can be downloaded via computer grids such as the Internet, intranets, etc.

[0253] It should also be noted that the exemplary embodiments mentioned in this application describe some methods or systems based on a series of steps or devices. However, this application is not limited to the order of the above steps, that is, the steps can be performed in the order mentioned in the embodiment, or in a different order from the embodiment, or several steps can be performed simultaneously.

[0254] Aspects of the present disclosure are described above with reference to the flowchart and / or block diagram of the method, device (system) and program product according to the embodiment of the present disclosure. It should be understood that each box in the flowchart and / or block diagram and the combination of each box in the flowchart and / or block diagram can be implemented by computer program instructions. These program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer or other programmable data processing device to produce a machine so that these instructions executed by the processor of the computer or other programmable data processing device enable the implementation of the function / action specified in one or more boxes of the flowchart and / or block diagram. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor or a field programmable logic circuit. It can also be understood that each box in the block diagram and / or flowchart and the combination of boxes in the block diagram and / or flowchart can also be implemented by dedicated hardware that performs a specified function or action, or can be implemented by a combination of dedicated hardware and computer instructions.

[0255] The above are only specific implementation methods of the present application. Those skilled in the art can clearly understand that for the convenience and simplicity of description, the specific working processes of the systems, modules and units described above can refer to the corresponding processes in the aforementioned method embodiments, and will not be repeated here. It should be understood that the protection scope of the present application is not limited to this. Any technician familiar with the technical field can easily think of various equivalent modifications or replacements within the technical scope disclosed in this application, and these modifications or replacements should be included in the protection scope of this application.

Claims

1. A task deployment method, characterized in that the method include: Obtain the current task requirements in any iteration cycle. Multiple iteration cycles constitute a task requirement cycle. According to the current task requirement and the current parameter condition, a first deployment strategy corresponding to the current task requirement is obtained, wherein the first deployment strategy is used to deploy the multiple tasks in the multiple servers, and the current parameter condition includes the current weights corresponding to the multiple tasks and the multiple servers respectively; When the iteration cycle has not ended and the task requirements of any task to be deployed have changed, the current parameter conditions are adjusted, and a second deployment strategy is obtained according to the adjusted parameter conditions and the changed task requirements until the iteration cycle ends, and a first available decision table PAT corresponding to the iteration cycle is obtained, wherein the first available decision table PAT includes the benefits corresponding to the task requirements executed in the iteration cycle, and the benefits are positively correlated with the resource utilization rate of the server corresponding to the task requirements executed in the iteration cycle; When multiple iteration cycles within the task requirement cycle are all completed and the preset convergence condition is met, a target PAT is obtained according to multiple optimal deployment strategies corresponding to multiple task requirements within the task requirement cycle, and tasks are deployed according to the target PAT, wherein each optimal deployment strategy is the highest benefit corresponding to each task requirement, and the preset convergence condition is determined according to the first available decision table PAT corresponding to each iteration cycle; The current task requirements include the current multi-dimensional resource availability of each server, the upper limit of each task's use of all resources, and the minimum requirement threshold vector of each task; the current parameter conditions include the current multi-dimensional resource normalization weight of each task, and the current demand elasticity of each server; The obtaining, according to the current task requirement and the current parameter condition, a first deployment strategy corresponding to the current task requirement includes: Determine the demand for all resources for each task based on the upper limit of each resource used by each task and the normalized weight of the current multi-dimensional resources of each task; Determining the available computing power of each server according to the current demand elasticity of each server and the current multi-dimensional resource availability of each server; Determine the required computing power of each task based on the current multi-dimensional resource normalization weight of each task and the minimum required threshold vector of each task; The mixed deployment constraint BRL algorithm based on bottleneck resource limitation obtains the first deployment strategy according to the demand of each task for all resources, the available computing power of each server and the required computing power of each task. The BRL algorithm is used to deploy the multiple tasks in a load-balanced manner among the multiple servers, and the standard deviation between the required computing power of the tasks deployed on the multiple servers is minimized.

2. The method according to claim 1, characterized in that The hybrid BRL algorithm based on bottleneck resource restriction obtains the first deployment strategy according to the demand of each task for all resources, the available computing power of each server and the required computing power of each task, including: According to the demand of each task for all resources, the demand of each task for the bottleneck resource corresponding to each task is obtained, wherein the bottleneck resource is a necessary resource for each task among all resources; The number of servers required for the multiple tasks is calculated according to a first formula, where the first formula is: , where k is the number of servers required for the multiple tasks, The required computing power for each task, For each server’s available computing power, is the current demand elasticity corresponding to the j-th server, and n is the total number of the multiple servers; According to the BRL algorithm, based on the demand for bottleneck resources of each task under the corresponding bottleneck resources, the multiple tasks are allocated to the required number of servers to obtain the first deployment strategy, wherein in the first deployment strategy, the standard deviation between the required computing power of the tasks deployed by the multiple servers is minimized.

3. The method according to claim 1, characterized in that When the iteration cycle is not over and the task requirements of any task to be deployed are changed, the current parameter conditions are adjusted, and a second deployment strategy is obtained according to the adjusted parameter conditions and the changed task requirements until the iteration cycle is over, and a first available decision table PAT corresponding to the iteration cycle is obtained, including: When the iteration cycle has not ended and the task requirement of any task to be deployed has changed, adjusting the current parameter condition according to the type of change of the task requirement; A second deployment strategy is obtained according to the adjusted parameter conditions and the changed task requirements until the iteration cycle ends, and the current state and the benefit corresponding to the current state are recorded, wherein the benefit is used to characterize the average actual resource utilization of each server and the total overhead of the task migration time in the iteration cycle when the first deployment strategy is adopted under the current state. The smaller the current benefit, the smaller the average actual resource utilization of each server, and the greater the total overhead of the task migration time; the current state includes the current multi-dimensional resource normalization weight of each task and the current demand elasticity of each server, and one current state corresponds to one task requirement; The current state and the benefit corresponding to the current state are stored in the first available decision table PAT.

4. The method according to claim 3, characterized in that The change type includes one of the following: The resources of any server cannot meet the computing power required by the tasks deployed therein or the computing power required by the bottleneck resources corresponding to the deployed tasks; A new task arrives and the remaining computing power of any server cannot meet the resource demand computing power of the new task; The resource utilization of the multiple servers under the first deployment scheme is less than a preset threshold; The adjusting of the current parameter conditions according to the change type of the task requirements includes: When any server resource cannot meet the computing power of the tasks deployed therein or the computing power required by the bottleneck resources corresponding to the deployed tasks, the multi-dimensional resource normalization weights of the tasks with increased resource requirements are adjusted; When a new task arrives and the remaining computing power of any server cannot meet the resource demand computing power of the new task, add a new server; When the resource utilization of the multiple servers under the first deployment solution is less than a preset threshold, the demand elasticity of each server is adjusted.

5. The method according to claim 1, characterized in that When the multiple iteration cycles within the task requirement cycle are all completed and the preset convergence condition is met, the target PAT is obtained according to the multiple optimal deployment strategies corresponding to the multiple task requirements within the task requirement cycle, including: When multiple iteration cycles within the task requirement cycle are completed, if the same deployment strategy is selected under any task requirement within a continuous preset number of task requirement cycles, the current parameter conditions under the first requirement are adjusted, and the first available decision table PAT is adjusted according to the adjusted parameter conditions and the first requirement; until the first available decision table PAT does not change under the first requirement, the target PAT is obtained according to multiple optimal deployment strategies corresponding to multiple task requirements within the task requirement cycle, and the first requirement is any task requirement.

6. A task deployment device, characterized in that: The device comprises: An acquisition module is used to acquire the current task requirements in any iteration cycle. Multiple iteration cycles constitute a task requirement cycle. A first determination module is used to obtain a first deployment strategy corresponding to the current task requirement according to the current task requirement and the current parameter condition, wherein the first deployment strategy is used to deploy multiple tasks in multiple servers, and the current parameter condition includes current weights corresponding to the multiple tasks and the multiple servers respectively; A second determination module is used to adjust the current parameter conditions when the iteration cycle has not ended and the task requirements of any task to be deployed have changed, and obtain a second deployment strategy according to the adjusted parameter conditions and the changed task requirements until the iteration cycle ends, and obtain a first available decision table PAT corresponding to the iteration cycle, wherein the first available decision table PAT includes benefits corresponding to the task requirements executed in the iteration cycle, and the benefits are positively correlated with resource utilization of the server corresponding to the task requirements executed in the iteration cycle; A deployment module, used for obtaining a target PAT according to multiple optimal deployment strategies corresponding to multiple task requirements in the task requirement cycle when multiple iteration cycles in the task requirement cycle are completed and a preset convergence condition is met, and performing task deployment according to the target PAT, wherein each optimal deployment strategy is the highest benefit corresponding to each task requirement, and the preset convergence condition is determined according to the first available decision table PAT corresponding to each iteration cycle; The current task requirements include the current multi-dimensional resource availability of each server, the upper limit of each task's use of all resources, and the minimum requirement threshold vector of each task; the current parameter conditions include the current multi-dimensional resource normalization weight of each task, and the current demand elasticity of each server; The obtaining, according to the current task requirement and the current parameter condition, a first deployment strategy corresponding to the current task requirement includes: Determine the demand for all resources for each task based on the upper limit of each resource used by each task and the normalized weight of the current multi-dimensional resources of each task; Determining the available computing power of each server according to the current demand elasticity of each server and the current multi-dimensional resource availability of each server; Determine the required computing power of each task based on the current multi-dimensional resource normalization weight of each task and the minimum required threshold vector of each task; The mixed deployment constraint BRL algorithm based on bottleneck resource limitation obtains the first deployment strategy according to the demand of each task for all resources, the available computing power of each server and the required computing power of each task. The BRL algorithm is used to deploy the multiple tasks in a load-balanced manner among the multiple servers, and the standard deviation between the required computing power of the tasks deployed on the multiple servers is minimized.

7. An electronic device, characterized in that: The device comprises: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, the task deployment method as described in any one of claims 1 to 5 is implemented.

8. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer program instructions, and when the computer program instructions are executed by a processor, the task deployment method according to any one of claims 1 to 5 is implemented.

9. A computer program product, characterized in that When the instructions in the computer program product are executed by a processor of an electronic device, the electronic device executes the task deployment method as described in any one of claims 1 to 5.

Images