Cloud chemical engineering control computing power network task scheduling method and system

Abstract

The invention provides a cloud engineering control computing power network task scheduling method and system, and relates to the technical field of computer task scheduling. According to the method, task priorities of task requirements are preset, and the task requirements of the first priority are directly arranged, scheduled and tried to be deployed; according to the method, other priority queues are constructed in advance, task requirements of other priorities are classified into the other priority queues which are constructed in advance, automatic sequencing is carried out in the other priority queues, and then arrangement scheduling and deployment trying are carried out according to the sequence of sequencing in the queues; a preset task expelling mechanism is introduced to ensure that task requirements with high task priorities are guaranteed in resource competition; according to the invention, efficient, reliable and differentiated scheduling of the industrial control task in a complex network environment is realized.

Description

Technical Field

[0001] This application relates to the field of computer task scheduling technology, and in particular to a cloud-based computer computing power network task scheduling method and system. Background Technology

[0002] In cloud-based industrial control computing power network scenarios, traditional general scheduling mechanisms are insufficient to meet the stringent challenges in the field of industrial control.

[0003] First, industrial control tasks are highly specific, ranging from latency-sensitive closed-loop control tasks (such as ultra-high priority industrial control) to latency-insensitive data analysis or model training tasks (such as low priority tasks). This highly differentiated business characteristic requires the scheduling system to provide accurate classification guarantees.

[0004] Secondly, the uncertainty of the environment brings serious risks. The communication link between the cloud computing center and industrial field equipment is highly susceptible to network fluctuations. Once the link deteriorates or is interrupted, it will directly threaten the continuity and security of core tasks such as cloud-based PLCs (Programmable Logic Controllers) and DCSs (Distributed Control Systems).

[0005] Finally, there is a deep contradiction between resource security and execution efficiency. In resource-constrained competitive scenarios, how to ensure that ultra-high priority tasks receive deterministic resource support while also taking into account the efficient processing of regular tasks through a priority-driven preemptive eviction strategy has become a core problem that urgently needs to be solved in current computing power network scheduling. Summary of the Invention

[0006] In view of the above problems, this application is proposed to provide a cloud-based computer control computing power network task scheduling method and system that overcomes or at least partially solves the above problems. The technical solution is as follows: Firstly, a cloud-based power control network task scheduling method is provided, the method comprising: In the cloud-based chemical control computing network, in response to one or more task requests from users, the task priorities of each pre-set task request are obtained; If the task priority of the task requirement is the first priority, then the task requirement with the first priority will be directly orchestrated, scheduled and deployed. If the task requirement has a priority other than the first priority, then the task requirements of other priorities will be assigned to a pre-built queue of other priorities; where the first priority is higher than other priorities. Calculate the internal priority of other priority task requirements in other priority queues, determine the internal order of other priority task requirements in other priority queues according to the internal priority of the queues, implement the internal ordering, and then perform orchestration, scheduling and deployment attempts according to the order of the internal ordering. If a first-priority task cannot be deployed due to insufficient resources, the physical resources of deployed task instances with lower priority than the first priority will be reclaimed according to the preset task eviction mechanism, and the reclaimed physical resources will be used for the deployment of the first-priority task. If other priority tasks cannot be deployed due to insufficient resources, the physical resources of deployed task instances with lower priority than other priorities will be reclaimed according to the preset task eviction mechanism, and the reclaimed physical resources will be used for the deployment of other priority tasks.

[0007] In one possible implementation, after directly orchestrating, scheduling, and attempting deployment for the first-priority task requirements, the method further includes: For the task instances corresponding to the first priority task requirements that have been deployed, mount an independent monitoring daemon. The monitoring daemon and the task instance coexist and die, and a periodic detection mechanism is established. The monitoring daemon periodically probes preset key network indicators between the user's terminal device and the cloud computing power nodes where the task instance is deployed, and obtains the network status of all candidate computing power nodes. When the detected preset key network indicators do not meet the preset service quality required by the task instance, a dynamic migration strategy is triggered. Based on the network status of all candidate computing power nodes, a target computing power node with idle resources and meeting the preset service quality is searched among all candidate computing power nodes, and the task instance is migrated to the target computing power node in real time.

[0008] In one possible implementation, the data content of other priority queues includes task requirement information, internal queue priority, queue length, queue capacity, and queue sorting function; wherein, the task requirement information includes task requirement identifier, task requirement status, and task priority of the task requirement.

[0009] In one possible implementation, the other priorities are any one of the second priority, third priority, and fourth priority; the other priority queues include the second priority queue, the third priority queue, and the fourth priority queue. If a task requirement has a priority other than the first priority, then the task requirements of other priorities will be placed into a pre-built queue of other priorities, including: If the task priority of the task requirement is the second priority, then the task requirement with the second priority will be assigned to the pre-built second priority queue. If the task priority of the task requirement is the third priority, then the task requirement with the third priority will be assigned to the pre-built third priority queue. If the task priority of the task requirement is the fourth priority, then the task requirement of the fourth priority will be assigned to the pre-built fourth priority queue.

[0010] In one possible implementation, the capacity of other priority queues is expanded using the following formula: (1) Where k takes values ​​from 1 to n, and n is a natural number; The initial queue capacity is 128; This refers to the queue capacity before expansion. This represents the expanded queue capacity.

[0011] In one possible implementation, the capacity of other priority queues is reduced using the following formula: (2) Where r takes values ​​from 1 to m, and m is a natural number; This is the actual queue length; This is the initial queue length; This represents the queue capacity before shrinking. This represents the queue capacity after shrinking.

[0012] In one possible implementation, the internal priority of task requests with other priorities within other priority queues is calculated using the following formula: (3) Where InnerPriority is the numerical value corresponding to the priority within the queue; TaskGPU, TaskCPU, and TaskMemory are the GPU, CPU, and memory sizes required for tasks of other priorities, respectively; GPU Max CPU Max and Memory Max These are the maximum number of GPU cores, the maximum number of CPU cores, and the maximum memory that the current cluster can accommodate; meanwhile, TaskGPU, TaskCPU, and TaskMemory satisfy equation (4): (4) If TaskGPU, TaskCPU, and TaskMemory do not satisfy equation (4), then other priority task requirements cannot be orchestrated, scheduled, and deployed, and subsequent steps will not be performed.

[0013] In one possible implementation, the data structure of other priority queues is a heap structure; the task requirements for other priorities are determined according to the internal priority of the queue and ordered within the other priority queues, and the internal ordering is performed, including: Place other priority task requests at the end of the other priority queue, and perform a heap structure up adjustment operation according to the internal priority of the queue to adjust the other priority task requests to the determined internal sorting position.

[0014] In one possible implementation, the pre-defined task eviction mechanism includes: The number of tasks that can be evicted under the priority of the currently pending tasks in the current cluster is calculated using the following formula: (5) Where EnableEnvictNum is the number of tasks that can be evicted based on the priority of the currently pending tasks in the current cluster; GPUSum i CPUSum i and MemorySum i These represent the total GPU, CPU, and memory usage of the load queue with priority i in the current cluster, respectively; p represents the priority of the task to be deployed. If the priority of the task to be deployed is the first priority, then p is 1; if the priority of the task to be deployed is the second priority, then p is 2; if the priority of the task to be deployed is the third priority, then p is 3; TaskGPU, TaskCPU, and TaskMemory are the GPU, CPU, and memory sizes required for other priority tasks, that is, the GPU, CPU, and memory sizes required for the task to be deployed. When EnableEnvictNum meets the deployment limit for the current task to be deployed, the eviction logic is executed, and the proximity between the element Deploy in the already deployed instance set Entry in the load queue and the current task to be deployed is calculated according to the following formula: (6) Where proximity is the nearest neighbor; DeployGPU, DeployCPU, and DeployMemory refer to the GPU usage, CPU usage, and memory usage of the element Deploy in the set of deployed instances Entry, respectively; abs() means taking the non-negative value of the calculation result within the parentheses; The elements Deploy in the deployed instance set Entry are sorted according to their proximity to the currently to-be-deployed task to determine the eviction order. Here, the elements Deploy in the deployed instance set Entry are also called deployed task instances.

[0015] Secondly, a cloud-based power control computing network task scheduling system is provided, the system comprising: The acquisition unit is used in the cloud-based power control network to acquire the pre-set task priorities of each task requirement in response to one or more task requirements of the user. The first scheduling unit is used to directly orchestrate, schedule, and attempt to deploy tasks with the highest priority if the task requirement is the highest priority. The second scheduling unit is used to assign task requests of other priorities to a pre-built queue of other priorities if the task priority is other than the first priority; wherein the first priority is higher than other priorities; and Calculate the internal priority of other priority task requirements in other priority queues, determine the internal order of other priority task requirements in other priority queues according to the internal priority of the queues, implement the internal ordering, and then perform orchestration, scheduling and deployment attempts according to the order of the internal ordering. The intelligent eviction unit is used to reclaim the physical resources of deployed task instances with lower priority than the first priority according to a preset task eviction mechanism if the first priority task cannot be deployed due to insufficient resources, and then make the reclaimed physical resources available for the deployment of the first priority task. If other priority tasks cannot be deployed due to insufficient resources, the physical resources of deployed task instances with lower priority than other priorities will be reclaimed according to the preset task eviction mechanism, and the reclaimed physical resources will be used for the deployment of other priority tasks.

[0016] By employing the above technical solutions, this application provides a cloud-based industrial control computing power network task scheduling method and system. This method pre-sets task priorities for task requirements, directly orchestrating, scheduling, and attempting deployment for first-priority task requirements. It also pre-constructs other priority queues, automatically sorting task requirements within these queues and then orchestrating, scheduling, and attempting deployment according to their order within the queues. A pre-defined task eviction mechanism is introduced to ensure that high-priority task requirements are guaranteed in resource contention. This application achieves efficient, reliable, and differentiated scheduling of industrial control tasks in complex network environments. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below.

[0018] Figure 1 A flowchart of the cloud computing power network task scheduling method provided in an embodiment of this application is shown; Figure 2 This illustration shows a schematic diagram of the average queuing delay of the FIFO queue provided in an embodiment of this application; Figure 3 This paper illustrates the average queuing delay of a multi-level priority queue (i.e., high-priority queue, medium-priority queue, and low-priority queue) provided in an embodiment of this application. Figure 4 The diagram illustrates the scheduling deployment of three queuing methods (FIFO queuing, priority queuing without expulsion function, and priority queuing with expulsion function) provided in the embodiments of this application. Figure 5 This paper shows a structural diagram of the cloud computing power network task scheduling system provided in an embodiment of this application; Figure 6 A structural diagram of a cloud computing power network task scheduling system provided in another embodiment of this application is shown. Detailed Implementation

[0019] Exemplary embodiments of the present application will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this application will be thorough and complete, and will fully convey the scope of the present application to those skilled in the art.

[0020] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such use can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the term "comprising" and its variations should be interpreted as open-ended terms meaning "including but not limited to."

[0021] To address the aforementioned technical problems, embodiments of this application provide a cloud-based power control computing network task scheduling method, such as... Figure 1 As shown, the cloud computing power network task scheduling method may include the following steps S101 to S106: Step S101: In the cloud computing power network, in response to one or more task requests from the user, obtain the pre-set task priorities for each task request; Step S102: If the task priority of the task requirement is the first priority, then the task requirement with the first priority is directly orchestrated, scheduled and deployed. Step S103: If the task priority of the task requirement is other than the first priority, then the task requirements of other priorities are assigned to the pre-built other priority queue; wherein, the first priority is higher than other priorities. Step S104: Calculate the internal priority of other priority task requirements in other priority queues, determine the internal order of other priority task requirements in other priority queues according to the internal priority of the queues, implement the internal ordering, and then perform orchestration, scheduling and deployment attempts according to the order of the internal ordering. Step S105: If the first priority task requirement cannot be deployed due to insufficient resources, the physical resources of the deployed task instances with task priorities lower than the first priority are reclaimed according to the preset task eviction mechanism, and the reclaimed physical resources are used for the deployment of the first priority task requirement. Step S106: If other priority task requirements cannot be deployed due to insufficient resources, the physical resources of deployed task instances with lower priority than other priorities are reclaimed according to the preset task eviction mechanism, and the reclaimed physical resources are used for deployment of other priority task requirements.

[0022] In this embodiment, the first priority task requirements, also known as ultra-high priority task requirements, mainly include latency-sensitive tasks, such as industrial control tasks.

[0023] Other priorities are lower than the first priority. Other priorities can be any of the second, third, and fourth priorities; the second priority is higher than the third priority, and the third priority is higher than the fourth priority.

[0024] Second-priority task requirements, also known as high-priority task requirements, mainly include tasks such as industrial control monitoring based on AI (Artificial Intelligence).

[0025] The third priority task requirements, also known as the medium priority task requirements, mainly include closed-loop optimization of the production control process and adjustment of production rhythm.

[0026] The fourth priority task requirements, also known as low priority task requirements, mainly include data analysis or model training tasks.

[0027] This embodiment pre-sets task priorities for task requirements, directly orchestrating, scheduling, and attempting deployment for first-priority task requirements; it pre-builds other priority queues, assigns other priority task requirements to these queues, and automatically sorts them within each queue, then orchestrates, schedules, and attempts deployment according to the order of these queues; it introduces a pre-set task eviction mechanism to ensure that high-priority task requirements are guaranteed in resource contention; this application achieves efficient, reliable, and differentiated scheduling of industrial control tasks in complex network environments.

[0028] This application embodiment provides a possible implementation method. After directly orchestrating, scheduling, and attempting deployment of the first priority task requirements in step S102, it may further include the following steps a1 to a3: Step a1 involves attaching an independent monitoring daemon to the task instance corresponding to the first priority task requirement that has been deployed. The monitoring daemon and the task instance coexist and die, and a periodic detection mechanism is established.

[0029] Step a2: The monitoring daemon periodically probes the preset key network indicators between the user's terminal device and the cloud computing power nodes where the task instance is deployed, and obtains the network status of all candidate computing power nodes.

[0030] In this step, the user's terminal device, such as field I / O (Input / Output) devices, is not limited in this embodiment.

[0031] Preset key network metrics can include latency, jitter, etc., and this embodiment does not limit them.

[0032] Step a3: When the detected preset key network indicators do not meet the preset service quality required by the task instance, a dynamic migration strategy is triggered. Based on the network status of all candidate computing power nodes, a target computing power node with idle resources and meeting the preset service quality is searched among all candidate computing power nodes, and the task instance is migrated to the target computing power node in real time.

[0033] This embodiment addresses tasks in industrial control scenarios that have extremely high requirements for deterministic networks (such as cloud-based PLCs and DCSs), ensuring business continuity through real-time sensing, rescheduling, and deployment.

[0034] This application provides a possible implementation method. The data content of other priority queues may include task requirement information, internal queue priority, queue length, queue capacity, queue sorting function, etc. The task requirement information may include task requirement identifier, task requirement status, task priority, etc., which are not limited in this embodiment. The task requirement status, such as "pending deployment," is also not limited in this embodiment.

[0035] This application provides a possible implementation method where other priorities are any one of the second, third, and fourth priorities; the other priority queue may include the second priority queue, the third priority queue, and the fourth priority queue; step S103: if the task priority of the task requirement is a priority other than the first priority, then the task requirements of other priorities are assigned to the pre-built other priority queue, which may include the following steps b1, b2, and b3: Step b1: If the task priority of the task requirement is the second priority, then the task requirement with the second priority is assigned to the pre-built second priority queue. Step b2: If the task priority of the task requirement is the third priority, then the task requirement with the third priority is assigned to the pre-built third priority queue. Step b3: If the task priority of the task requirement is the fourth priority, then the task requirement with the fourth priority is assigned to the pre-built fourth priority queue.

[0036] In this embodiment, the data content of the second priority queue may include task requirement information, queue internal priority, queue length, queue capacity, and queue sorting function; wherein, the task requirement information may include task requirement identifier, task requirement status, task priority, etc., and this embodiment does not limit this.

[0037] The data content of the third priority queue may include task requirement information, internal priority of the queue, queue length, queue capacity, and queue sorting function; among which, task requirement information may include task requirement identifier, task requirement status, task priority of the task requirement, etc., which are not limited in this embodiment.

[0038] The data content of the fourth priority queue may include task requirement information, internal priority of the queue, queue length, queue capacity, and queue sorting function; among which, task requirement information may include task requirement identifier, task requirement status, task priority of the task requirement, etc., which are not limited in this embodiment.

[0039] The second priority can also be called the high priority, and the second priority queue can also be called the high priority queue; the third priority can also be called the medium priority, and the third priority queue can also be called the medium priority queue; the fourth priority can also be called the low priority, and the fourth priority queue can also be called the low priority queue.

[0040] This embodiment constructs a multi-level priority queue, including a second priority queue, a third priority queue, and a fourth priority queue, to schedule task requirements with different priorities and achieve accurate classification and protection.

[0041] This application provides a possible implementation method for expanding the capacity of other priority queues using the following formula: (1) Where k takes values ​​from 1 to n, and n is a natural number; The initial queue capacity is 128; This refers to the queue capacity before expansion. This represents the expanded queue capacity.

[0042] This application provides a possible implementation method for reducing the queue capacity of other priority queues using the following formula: (2) Where r takes values ​​from 1 to m, and m is a natural number; This is the actual queue length; This is the initial queue length; This represents the queue capacity before shrinking. This represents the queue capacity after shrinking.

[0043] This application provides a possible implementation method, which calculates the internal priority of task requirements with other priorities within other priority queues using the following formula: (3) Where InnerPriority is the numerical value corresponding to the priority within the queue; TaskGPU, TaskCPU, and TaskMemory are the GPU, CPU, and memory sizes required for tasks of other priorities, respectively; GPU Max CPU Max and Memory Max These are the maximum number of GPU cores, the maximum number of CPU cores, and the maximum memory that the current cluster can accommodate; meanwhile, TaskGPU, TaskCPU, and TaskMemory satisfy equation (4): (4) If TaskGPU, TaskCPU, and TaskMemory do not satisfy equation (4), then other priority task requirements cannot be orchestrated, scheduled, and deployed, and subsequent steps will not be performed. Here, GPU stands for Graphics Processing Unit; CPU stands for Central Processing Unit.

[0044] This application embodiment provides a possible implementation method, where the data structure of other priority queues is a heap structure; step S104 determines the intra-queue sorting of other priority task requirements in other priority queues according to the internal priority of the queue, and implements intra-queue sorting, which may specifically include the following steps c1: Step c1: Place other priority task requirements at the end of the other priority queue, and perform a heap structure up adjustment operation according to the internal priority of the queue to adjust the other priority task requirements to the determined internal sorting position.

[0045] This application embodiment provides a possible implementation method, and the preset task eviction mechanism involved in steps S105 and S106 may include: The number of tasks that can be evicted under the priority of the currently pending tasks in the current cluster is calculated using the following formula: (5) Where EnableEnvictNum is the number of tasks that can be evicted based on the priority of the currently pending tasks in the current cluster; GPUSum i CPUSum i and MemorySum i These represent the total GPU, CPU, and memory usage of the load queue with priority i in the current cluster, respectively; p represents the priority of the task to be deployed. If the priority of the task to be deployed is the first priority, then p is 1; if the priority of the task to be deployed is the second priority, then p is 2; if the priority of the task to be deployed is the third priority, then p is 3; TaskGPU, TaskCPU, and TaskMemory are the GPU, CPU, and memory sizes required for other priority tasks, that is, the GPU, CPU, and memory sizes required for the task to be deployed. When EnableEnvictNum meets the deployment limit for the current task to be deployed, the eviction logic is executed, and the proximity between the element Deploy in the already deployed instance set Entry in the load queue and the current task to be deployed is calculated according to the following formula: (6) Where proximity is the nearest neighbor; DeployGPU, DeployCPU, and DeployMemory refer to the GPU usage, CPU usage, and memory usage of the element Deploy in the set of deployed instances Entry, respectively; abs() means taking the non-negative value of the calculation result within the parentheses; The elements Deploy in the deployed instance set Entry are sorted according to their proximity to the currently to-be-deployed task to determine the eviction order. Here, the elements Deploy in the deployed instance set Entry are also called deployed task instances.

[0046] The above introduces Figure 1 The embodiments shown have various implementation methods for each stage. The cloud computing power network task scheduling method of this application will be further explained below through specific embodiments.

[0047] In a specific embodiment, by pre-setting the task priorities of task requirements, the first-priority task requirements (also known as ultra-high-priority task requirements) are directly orchestrated, scheduled, and attempted to be deployed, and a dynamic keep-alive migration mechanism is implemented for the first-priority task requirements; by constructing a multi-level priority queue, including a second-priority queue, a third-priority queue, and a fourth-priority queue, task requirements of different priorities are scheduled to achieve accurate classification and protection; efficient intra-queue sorting is achieved by combining a heap data structure, a dynamic expansion and contraction mechanism of the queue is designed to adapt to load changes, and a task eviction mechanism based on proximity calculation is introduced to ensure that high-priority task requirements are protected in resource contention.

[0048] In cloud-based power control computing networks, task priorities for pre-setting task requirements can include any of the following: first priority (also known as ultra-high priority), second priority (also known as high priority), third priority (also known as medium priority), and fourth priority (also known as low priority).

[0049] Ultra-high priority task requirements mainly include latency-sensitive tasks, such as industrial control tasks; high priority task requirements mainly include AI-based industrial control monitoring tasks; medium priority task requirements mainly include closed-loop optimization of production control processes and production rhythm adjustment; low priority task requirements mainly include data analysis or model training tasks.

[0050] For ultra-high priority tasks, orchestration, scheduling, and deployment attempts are performed directly. Meanwhile, to address the stringent requirements of industrial control scenarios, a dynamic keep-alive migration mechanism is introduced to mitigate the impact of network fluctuations on task continuity.

[0051] For high-priority task requirements, they are assigned to a pre-built second-priority queue, also known as a high-priority queue.

[0052] For medium-priority task requirements, they are assigned to a pre-built third-priority queue, also known as the medium-priority queue.

[0053] For low-priority task requirements, they are assigned to a pre-built fourth priority queue, also known as the low-priority queue.

[0054] In resource contention scenarios, a priority-driven preemptive eviction mechanism is adopted to release the physical resources of deployed task instances with lower task priorities, thereby ensuring the deterministic execution of core business operations.

[0055] 1) Dynamic keep-alive migration mechanism for ultra-high priority task requirements.

[0056] For cloud-based PLCs and DCSs, a dynamic keep-alive mechanism based on network awareness and smooth migration has been introduced. Given the volatility of the industrial control network environment, if the communication link between the user's terminal equipment (such as field I / O devices) and the cloud computing cluster deteriorates or is interrupted, the orchestration platform will initiate real-time rescheduling.

[0057] For example, at time T1, only computing node B meets the network constraints that require real-time control, and the PLC logic is deployed on this node; at time T2, if the link quality of node B deteriorates, a dynamic keep-alive mechanism is triggered, and the instance is immediately migrated to computing node A or C with a better network status.

[0058] The computing power network management platform mounts an independent monitoring daemon on each cloud-based PLC instance, and the daemon lives and dies in tandem with the cloud-based PLC instance. This monitoring daemon periodically probes deterministic network indicators between the device and the cluster and compares them with preset network requirements. If a violation is detected, candidate computing power nodes with available resources and meeting real-time constraints are retrieved and redeployed.

[0059] The implementation steps for the dynamic keep-alive migration mechanism for ultra-high priority task requirements are as follows: Step 1.1: Attribute Identification and Monitoring Enabled. Identify task priority; if determined to be extremely high priority, attach a separate monitoring daemon to it. This monitoring daemon lives and dies with the task instance and establishes a periodic detection mechanism.

[0060] Step 1.2: Real-time collection of network metrics. The monitoring daemon periodically detects key network metrics (such as latency and jitter) between terminal devices and cloud computing power nodes, and obtains the current network status of all candidate computing power nodes.

[0061] Step 1.3: Violation Detection and Early Warning. The real-time collected network metrics are compared with the task's preset QoS (Quality of Service) requirements. If the network quality of the current computing node deteriorates and no longer meets the real-time constraints, a dynamic migration strategy is triggered.

[0062] Step 1.4: Reschedule Execution. Retrieve candidate computing nodes with idle resources and meeting real-time constraints, and immediately migrate (redeploy) the task instance to a new node with good network conditions to achieve a smooth switchover.

[0063] This embodiment addresses tasks in industrial control scenarios that have extremely high requirements for deterministic networks (such as cloud-based PLCs and DCS), ensuring business continuity through real-time sensing and rescheduling.

[0064] 2) Construction of multi-level priority queues.

[0065] A second priority queue (also known as a high priority queue), a third priority queue (also known as a medium priority queue), and a fourth priority queue (also known as a low priority queue) are constructed to schedule task requirements with different priorities, thereby achieving accurate classification and guarantee.

[0066] The data content of each priority queue may include task requirement information, internal queue priority, queue length, queue capacity, queue sorting function, etc.; among which, task requirement information may include task requirement identifier, task requirement status, task priority, etc., which are not limited in this embodiment. The task requirement status, such as pending deployment, is not limited in this embodiment.

[0067] 3) Automatic scaling mechanism for each priority queue.

[0068] If the priority queue's capacity is too small, it cannot handle too many tasks; if the queue's capacity is too large, it will waste resources during idle periods. Therefore, the priority queue's capacity should be dynamically variable. Expansion can be achieved through multiplicative or additive methods. With a small initial capacity, additive expansion can easily lead to frequent expansions, while with a large initial capacity, multiplicative expansion can easily result in space redundancy. Furthermore, expansion and contraction involve deep data copying, so the number of expansions and contractions should be minimized to avoid the performance overhead of data copying.

[0069] When designing an expansion algorithm, it is necessary to consider the performance loss caused by expansion operations and the impact of queue length on memory. In this specific embodiment, a dynamic expansion mechanism is adopted according to the queue capacity, as shown in Equation (1). In order to reduce the number of expansions, the queue capacity threshold is set to 1024. When the queue capacity before expansion is less than 1024, a multiplicative expansion mechanism is adopted; when the queue capacity before expansion is greater than or equal to 1024, an additive expansion mechanism is adopted.

[0070] (1) Where k takes values ​​from 1 to n, and n is a natural number; The initial queue capacity is 128; This refers to the queue capacity before expansion. This represents the expanded queue capacity.

[0071] To balance the number of expansions and contractions with resource consumption, after experimental verification, the initial queue capacity set in this embodiment is 128. The length of 128 capacity is sufficient for most low-load operation scenarios. Even under high load conditions, such as when expanding from 128 to 2048 elements, only 4 expansions will occur.

[0072] Similarly, a similar mechanism is adopted when shrinking the queue. The specific expression is shown in equation (2). In order to reduce the number of shrinking operations, the queue length threshold is set to 65536 in this embodiment. When the queue capacity before shrinking minus the actual queue length is greater than or equal to 65536, the queue shrinks by 65536 units each time; otherwise, when the queue capacity before shrinking is greater than or equal to twice the actual queue length, the queue shrinks to half of its original size each time, and is shortened to the initial queue length at the minimum.

[0073] (2) Where r takes values ​​from 1 to m, and m is a natural number; This is the actual queue length; This is the initial queue length; This represents the queue capacity before shrinking. This represents the queue capacity after shrinking.

[0074] All thresholds in Equations (1) and (2) can be changed through configuration files according to the actual application scenario.

[0075] The implementation steps for the automatic scaling mechanism of each priority queue are as follows: Step 3.1: Capacity Status Monitoring. Check the current queue length and capacity in real time before tasks are enqueued.

[0076] Step 3.2: Differentiated Expansion Judgment. Expansion is triggered when the queue length reaches the capacity limit. If the current capacity is less than a preset threshold (e.g., 1024), multiplicative expansion (capacity doubles) is adopted; if the capacity has exceeded the threshold, additive expansion is switched (increasing by a fixed step size, such as 1024 units).

[0077] Step 3.3: Deep copy and update of data. Allocate a new data cache space, and deep copy all elements from the original queue to the new space, then update the queue's memory reference.

[0078] Step 3.4: Redundancy reduction. When the queue is found to have too much idle space (e.g., capacity minus length is greater than 65536) or the capacity is more than twice the length, the queue is reduced proportionally or in fixed steps, but the initial capacity is maintained at a minimum (e.g., 128) to maintain the basic operating environment.

[0079] 4) Automatic sorting mechanism for each priority queue.

[0080] The queue nodes composed of tasks are placed into different priority queues according to task priority. Within the same priority queue, tasks are further sorted and orchestrated based on resource requirements. This embodiment designs a queue based on prioritizing large tasks to reduce resource fragmentation. When the queue priority is configured as prioritizing large tasks, tasks with high resource requirements will be given priority in the orchestration and scheduling process within this priority queue.

[0081] The internal implementations of priority queues can be vectors, ordered vectors, linked lists, ordered linked lists, and heap structures, each with different time and space complexities. Table 1 shows the differences in time complexity for insertion, search, and deletion of elements using these different implementations. The time complexity directly affects the program's speed. Since each element in the queue involves insertion, search, and deletion operations, the total operational complexity should be the sum of the time complexities of these three types of operations. According to Table 1, the implementation with the lowest time complexity is the heap structure.

[0082] Table 1 Comparison of Time Complexity for Different Structures

[0083] In Table 1, w represents the number of elements currently stored in the data structure, i.e., the data size. O(1) indicates that the time required for the operation is constant and does not change with the number of elements w. O(w) indicates that the time required for the operation is proportional to the number of elements w. O(log w) indicates that the time required for the operation is proportional to the logarithm of w.

[0084] Therefore, this embodiment selects a heap structure as the data structure for each priority queue. The priority of sorting within the heap will be determined by the InnerPriority variable of the queue element. The larger the InnerPriority value, the higher its priority in the queue, and the more likely it should be placed at the front of the queue. The InnerPriority variable is calculated as shown in equation (3): (3) Where InnerPriority is the numerical value corresponding to the priority within the queue; TaskGPU, TaskCPU, and TaskMemory are the GPU, CPU, and memory sizes required for tasks of other priorities, respectively; GPU Max CPU Max and Memory MaxThese are the maximum number of GPU cores, the maximum number of CPU cores, and the maximum memory that the current cluster can accommodate; meanwhile, TaskGPU, TaskCPU, and TaskMemory satisfy equation (4): (4) If TaskGPU, TaskCPU, and TaskMemory do not satisfy equation (4), then other priority task requirements cannot be orchestrated, scheduled, and deployed, and subsequent steps will not be performed.

[0085] Combining heap sort mechanism can ensure that queue elements are always in an ordered state when inserted, searched and deleted.

[0086] By leveraging the characteristics of the heap data structure, we ensure that tasks within each priority queue can be scheduled in an orderly manner. The implementation steps for in-queue sorting based on the heap structure are as follows: Step 4.1: Task Resource Quantification. Extract the GPU, CPU, and memory values ​​required for the new task.

[0087] Step 4.2: Calculate the intra-queue priority. Based on the ratio of task resource requirements to the maximum capacity of cluster nodes, calculate the intra-queue priority variable InnerPriority for this task.

[0088] Step 4.3: Heapification insertion operation. Place the new task element at the end of the queue, and then perform a heap structure up-adjustment operation.

[0089] Step 4.4: Dynamically maintain order. By comparing the InnerPriority values ​​of parent and child nodes and swapping their positions, the top of the heap is always the highest priority task (such as the task with the greatest resource demand), thus ensuring the efficiency of search and deletion operations.

[0090] 5) Mission expulsion mechanism.

[0091] To ensure service availability for high-priority task requests, a priority queue eviction mechanism was designed. When the resource pool is full and no new tasks can be deployed, high-priority task requests can evict low-priority task instances, thereby ensuring the normal deployment and operation of their own services.

[0092] The entire expulsion process consists of two steps: The first step is to calculate and determine the number of vehicles that can be evicted, EnableEnvictNum.

[0093] Each cluster maintains different load queues according to different priorities. An Entry is a collection of already deployed instances. The number of tasks that can be evicted under the priority of the currently pending task in the current cluster is calculated according to the following formula: (5) Where EnableEnvictNum is the number of tasks that can be evicted based on the priority of the currently pending tasks in the current cluster; GPUSum i CPUSum i and MemorySum i These represent the total GPU, CPU, and memory usage of the load queue with priority i in the current cluster, respectively. `p` represents the priority of the task to be deployed. If the task has the highest priority, `p` is 1; if it has the second highest priority, `p` is 2; if it has the third highest priority, `p` is 3. `TaskGPU`, `TaskCPU`, and `TaskMemory` represent the GPU, CPU, and memory requirements for tasks of other priorities, i.e., the GPU, CPU, and memory requirements for the task to be deployed. Since a task to be deployed can only evict tasks with lower priorities, `EnableEnvictNum` should be calculated starting from priority p+1.

[0094] The second step is to remove specific instances from the resource pool.

[0095] When calculating EnableEnvictNum, no actual eviction is performed. Eviction logic is executed when EnableEnvictNum meets the deployment quantity of the current task to be deployed. The proximity of the Deploy element in the Entry set of deployed instances in the load queue to the current task to be deployed is calculated according to the following formula: (6) Where proximity is the nearest neighbor; DeployGPU, DeployCPU, and DeployMemory refer to the GPU usage, CPU usage, and memory usage of the element Deploy in the set of deployed instances Entry, respectively; abs() means taking the non-negative value of the calculation result within the parentheses; The elements Deploy in the deployed instance set Entry are sorted according to their proximity to the currently to-be-deployed task to determine the eviction order. Here, the elements Deploy in the deployed instance set Entry are also called deployed task instances.

[0096] The time and space complexity of a sorting algorithm directly affect its running speed and memory consumption. Therefore, this embodiment chooses the pdqsort (pattern defeating quicksort) algorithm for the eviction task sorting. The pdqsort algorithm combines the advantages of quicksort, heapsort, and insertion sort, and is currently the most commonly used sorting algorithm in industry. The pdqsort algorithm is relatively simple in principle: it uses insertion sort for short sequences less than 12, and quicksort for long sequences. When the sorting algorithm performs poorly, causing the number of imbalances in the left and right subsequences after quicksort to reach a limit, pdqsort will use heapsort to complete the subsequent sorting, thus ensuring that the worst-case time complexity is still O(wlogw); where left and right subsequence imbalance is defined as a difference in length between the left and right subsequences greater than 7 times.

[0097] The implementation steps of priority-driven smart eviction are as follows: Step 5.1: Calculate the eviction threshold. When a new task cannot be deployed directly, count the set of all tasks in the current cluster with a priority lower than the task to be deployed, and calculate the total resources they consume.

[0098] Step 5.2: Determination of Demolition Feasibility. Calculate the number of demolitions, EnableEnvictNum, based on the amount of resources that can be released, and determine whether demolitions can meet the resource gap for the new mission.

[0099] Step 5.3: Proximity Calculation and Sorting. Calculate the resource proximity between instances in the low-priority task queue and the tasks to be deployed.

[0100] Step 5.4: Execution of efficient sorting strategy. The pdqsort algorithm is used to sort the instances, automatically switching between insertion sort, quicksort, and heapsort based on the sequence length and distribution.

[0101] Step 5.5: Resource reclamation and instance termination. Based on the sorting results, prioritize evicting the instance with the highest matching degree, releasing the physical resources it occupies for use by new tasks.

[0102] When resources are scarce, the deployment of core tasks can be guaranteed by reclaiming the physical resources of low-priority task instances.

[0103] It should be noted that the sequence numbers of the steps in the above embodiments do not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. In practical applications, all the above possible implementation methods can be arbitrarily combined in a combined manner to form possible embodiments of this application, which will not be described in detail here.

[0104] Next, a simulation experiment was chosen to model the cluster. The simulation device was a Windows 10 laptop equipped with an i7 7700H (a high-performance CPU) and 16GB of RAM. The simulation software was implemented using Go (a statically typed, compiled programming language commonly used for efficient system programming and concurrent processing), version v1.20.7, to evaluate the performance of average task queuing and task eviction mechanisms.

[0105] 1. Average queuing delay experiment.

[0106] In this experiment, the simulated scheduling platform creates 100 task requirements each according to three priorities (high, medium, and low), and randomly shuffles the submission order of the task requirements. Then, it tests the queuing latency of each task requirement in a FIFO (First In First Out) queue and a multi-level priority queue (high priority, medium priority, and low priority). Table 2 shows the task requirements and cluster resource configuration used in this experiment. Multiple task requirements 1, 2, 3, and 4 can be created to achieve the goal of creating 100 task requirements according to each of the three priorities.

[0107] Table 2 Resource Allocation Table

[0108] In Table 2, core represents the number of cores and GiB represents gigabytes.

[0109] Throughout the experiment, the orchestration and scheduling process was completely consistent with the actual system. Calculations using the actual system showed that orchestrating and scheduling a single-copy task requirement takes approximately 600ms. Therefore, in this embodiment, for orchestration and scheduling processes that took less than 600ms, the time was padded to 600ms to simulate the real environment as closely as possible. In the experiment, this embodiment applied the same set of out-of-order task requirements to two different queuing scheduling systems. To ensure the robustness of the experiment, this embodiment will run the simulation 100 times, regenerating the out-of-order task requirement queue in each simulation. After 100 experiments, the final experimental results are as follows: Figure 2 and Figure 3 As shown.

[0110] exist Figure 2 In the diagram, the horizontal axis Epoch represents the number of rounds, and the vertical axis Queuing delay represents the queuing delay, in milliseconds (ms). Figure 2It can be seen that after 100 scheduling cycles, in the simulated concurrent scenario, the average queuing latency for High Priority tasks in the FIFO queue system is 90296.11ms, that is, the High Priority Mean is 90296.11ms.

[0111] The average queuing latency for Mid Priority tasks is 90755.07ms, which is the Mid Priority Mean.

[0112] The average queuing latency for low priority tasks is 91064.85ms, which is the Low Priority Mean.

[0113] Although FIFO queues can solve the task submission problem in high-concurrency scenarios, there is no significant difference in queuing latency for task requests with different priorities.

[0114] exist Figure 3 In the diagram, the horizontal axis Epoch represents the number of rounds, and the vertical axis Queuing delay represents the queuing delay, in milliseconds (ms). Figure 3 It can be seen that after 100 scheduling cycles, in a simulated concurrent scenario, in a multi-level priority queue system, the average queuing latency for High Priority tasks is 30028.21ms, that is, High PriorityMean is 30028.21ms.

[0115] The average queuing latency for Mid Priority tasks is 90493.34ms, which is the Mid Priority Mean.

[0116] The average queuing latency for low priority tasks is 151008.7ms, which is the Low Priority Mean.

[0117] For the same task requirements, using a multi-level priority queue can significantly reduce the queuing latency of high-priority tasks. In experimental scenarios, the average queuing latency of high-priority tasks in a multi-level priority queue is reduced by approximately 67% compared to the average queuing latency in a FIFO queue, and this reduction increases with the number of tasks.

[0118] 2. Mission Expulsion Experiment.

[0119] This experiment will verify whether the eviction function works when cluster resources are insufficient. In this experiment, this embodiment will still create 100 task requirements each according to three priorities (i.e., high priority, medium priority, and low priority) and randomly shuffle them. However, the cluster capacity will be reduced, and the cluster will not be able to accommodate all the task requirements. The underlying cluster configuration for this experiment is a cluster with 380 GPU cores, 380 CPU cores, and 600 GiB of memory, and 150 low-priority task requirements will be pre-deployed, so that there are 150 low-priority deployed task instances in the cluster.

[0120] This experiment will set up three queuing methods: FIFO queuing, Priority (priority queuing without eviction), and Priority With Drain (priority queuing with eviction). The deployment success rate of each priority task will be used as the evaluation metric. Here, High Priority represents high-priority task requirements, Mid Priority represents medium-priority task requirements, and Low Priority represents low-priority task requirements. The final experimental results are as follows: Figure 4 As shown.

[0121] analyze Figure 4 The experimental results show that the number of tasks scheduled and deployed for High Priority in the FIFO queue is 52, with a scheduling deployment rate of 52 / 100=52%; the number of tasks scheduled and deployed for Mid Priority is 45, with a scheduling deployment rate of 45 / 100=45%.

[0122] Compared to FIFO queues, enabling priority queues (without eviction) effectively ensures that high-priority task requests are scheduled and deployed. In this case, the number of High Priority task requests scheduled and deployed is 100, with a scheduling and deployment rate of 100 / 100=100%. Then, since there is no eviction function, under the condition of limited underlying resources, the number of Mid Priority task requests scheduled and deployed is 54, with a scheduling and deployment rate of 54 / 100=54%. The number of Low Priority task requests scheduled and deployed is 150, which are the low-priority deployed task instances during the experiment, so the scheduling and deployment rate of low-priority task requests is 0%.

[0123] After enabling priority queues and introducing eviction functionality, the number of scheduled deployments for High Priority task requests is 100, and the scheduling deployment rate remains at 100 / 100=100%. However, at this time, mid-priority task requests can preempt the physical resources of low-priority deployed task instances, so the number of scheduled deployments for Mid Priority task requests increases to 100, and the scheduling deployment rate also increases to 100%.

[0124] Based on the cloud computing power network task scheduling method provided in the above embodiments, and based on the same inventive concept, this application also provides a cloud computing power network task scheduling system.

[0125] Figure 5 This is a structural diagram of the cloud-based computer control computing power network task scheduling system provided in the embodiments of this application. For example... Figure 5 As shown, the cloud computing power network task scheduling system may specifically include an acquisition unit 510, a first scheduling unit 520, a second scheduling unit 530, and an intelligent expulsion unit 540.

[0126] The acquisition unit 510 is used to acquire the pre-set task priorities of each task requirement in response to one or more task requirements of the user in the cloud-based chemical control computing power network. The first scheduling unit 520 is used to directly orchestrate, schedule and attempt to deploy the task requirement with the first priority if the task requirement has the first priority. The second scheduling unit 530 is configured to, if the task priority of a task request is any priority other than the first priority, assign the task request of that other priority to a pre-built queue of other priorities; wherein the first priority is higher than the other priorities; and Calculate the internal priority of other priority task requirements in other priority queues, determine the internal order of other priority task requirements in other priority queues according to the internal priority of the queues, implement the internal ordering, and then perform orchestration, scheduling and deployment attempts according to the order of the internal ordering. The intelligent eviction unit 540 is used to reclaim the physical resources of deployed task instances with lower priority than the first priority according to a preset task eviction mechanism if the first priority task cannot be deployed due to insufficient resources, and then make the reclaimed physical resources available for the deployment of the first priority task. If other priority tasks cannot be deployed due to insufficient resources, the physical resources of deployed task instances with lower priority than other priorities will be reclaimed according to the preset task eviction mechanism, and the reclaimed physical resources will be used for the deployment of other priority tasks.

[0127] This application provides one possible implementation method, such as... Figure 6 As shown above, Figure 5 The system shown may also include a dynamic keep-alive migration unit 610, used for: After the first scheduling unit 520 directly orchestrates, schedules, and attempts to deploy the first priority task requirements, it attaches an independent monitoring daemon to the task instance corresponding to the deployed first priority task requirements. The monitoring daemon and the task instance coexist and die, and a periodic detection mechanism is established. The monitoring daemon periodically probes preset key network indicators between the user's terminal device and the cloud computing power nodes where the task instance is deployed, and obtains the network status of all candidate computing power nodes. When the detected preset key network indicators do not meet the preset service quality required by the task instance, a dynamic migration strategy is triggered. Based on the network status of all candidate computing power nodes, a target computing power node with idle resources and meeting the preset service quality is searched among all candidate computing power nodes, and the task instance is migrated to the target computing power node in real time.

[0128] This application provides a possible implementation method in which the data content of other priority queues includes task requirement information, internal priority of the queue, queue length, queue capacity, and queue sorting function; wherein, the task requirement information includes task requirement identifier, task requirement status, and task priority of the task requirement.

[0129] This application embodiment provides a possible implementation, wherein the other priorities are any one of the second priority, third priority, and fourth priority; the other priority queues include the second priority queue, the third priority queue, and the fourth priority queue; the second scheduling unit 530 is further configured to: If the task priority of the task requirement is the second priority, then the task requirement with the second priority will be assigned to the pre-built second priority queue. If the task priority of the task requirement is the third priority, then the task requirement with the third priority will be assigned to the pre-built third priority queue. If the task priority of the task requirement is the fourth priority, then the task requirement of the fourth priority will be assigned to the pre-built fourth priority queue.

[0130] This application provides one possible implementation method, such as... Figure 6 As shown above, Figure 5 The system shown may also include a queue expansion / shrinking unit 620, used for: The capacity of other priority queues can be increased using the following formula: (1) Where k takes values ​​from 1 to n, and n is a natural number; The initial queue capacity is 128; This refers to the queue capacity before expansion. This represents the expanded queue capacity.

[0131] This application embodiment provides a possible implementation, wherein the queue expansion / shrinking unit 620 is further configured to: The capacity of other priority queues can be reduced using the following formula: (2) Where r takes values ​​from 1 to m, and m is a natural number; This is the actual queue length; This is the initial queue length; This represents the queue capacity before shrinking. This represents the queue capacity after shrinking.

[0132] This application embodiment provides a possible implementation, wherein the second scheduling unit 530 is further configured to: The internal priority of other priority task requirements within other priority queues is calculated using the following formula: (3) Where InnerPriority is the numerical value corresponding to the priority within the queue; TaskGPU, TaskCPU, and TaskMemory are the GPU, CPU, and memory sizes required for tasks of other priorities, respectively; GPU Max CPU Max and Memory Max These are the maximum number of GPU cores, the maximum number of CPU cores, and the maximum memory that the current cluster can accommodate; meanwhile, TaskGPU, TaskCPU, and TaskMemory satisfy equation (4): (4) If TaskGPU, TaskCPU, and TaskMemory do not satisfy equation (4), then other priority task requirements cannot be orchestrated, scheduled, and deployed, and subsequent steps will not be performed.

[0133] This application embodiment provides a possible implementation method, wherein the data structure of other priority queues is a heap structure; the second scheduling unit 530 is further configured to: Place other priority task requests at the end of the other priority queue, and perform a heap structure up adjustment operation according to the internal priority of the queue to adjust the other priority task requests to the determined internal sorting position.

[0134] This application provides a possible implementation method, and the preset task eviction mechanism includes: The number of tasks that can be evicted under the priority of the currently pending tasks in the current cluster is calculated using the following formula: (5) Where EnableEnvictNum is the number of tasks that can be evicted based on the priority of the currently pending tasks in the current cluster; GPUSum i CPUSum i and MemorySum i These represent the total GPU, CPU, and memory usage of the load queue with priority i in the current cluster, respectively; p represents the priority of the task to be deployed. If the priority of the task to be deployed is the first priority, then p is 1; if the priority of the task to be deployed is the second priority, then p is 2; if the priority of the task to be deployed is the third priority, then p is 3; TaskGPU, TaskCPU, and TaskMemory are the GPU, CPU, and memory sizes required for other priority tasks, that is, the GPU, CPU, and memory sizes required for the task to be deployed. When EnableEnvictNum meets the deployment limit for the current task to be deployed, the eviction logic is executed, and the proximity between the element Deploy in the already deployed instance set Entry in the load queue and the current task to be deployed is calculated according to the following formula: (6) Where proximity is the nearest neighbor; DeployGPU, DeployCPU, and DeployMemory refer to the GPU usage, CPU usage, and memory usage of the element Deploy in the set of deployed instances Entry, respectively; abs() means taking the non-negative value of the calculation result within the parentheses; The elements Deploy in the deployed instance set Entry are sorted according to their proximity to the currently to-be-deployed task to determine the eviction order. Here, the elements Deploy in the deployed instance set Entry are also called deployed task instances.

[0135] This embodiment pre-sets task priorities for task requirements, directly orchestrates and attempts to deploy first-priority task requirements (also known as ultra-high-priority task requirements), and implements a dynamic keep-alive migration mechanism for first-priority task requirements. By constructing multi-level priority queues, including second-priority queues (also known as high-priority queues), third-priority queues (also known as medium-priority queues), and fourth-priority queues (also known as low-priority queues), it schedules task requirements with different priorities to achieve accurate classification and protection. Combined with a heap data structure, it achieves efficient intra-queue sorting, designs a dynamic queue expansion and contraction mechanism to adapt to load changes, and introduces a task eviction mechanism based on proximity calculation to ensure that high-priority task requirements are protected in resource contention.

[0136] Those skilled in the art will clearly understand that the specific working process of the systems, devices, and modules described above can be referred to the corresponding process in the foregoing method embodiments. For the sake of brevity, it will not be repeated here.

[0137] Those skilled in the art will understand that the technical solution of this application, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several program instructions to cause an electronic device (e.g., a personal computer, server, or network device) to execute all or part of the steps of the methods described in the embodiments of this application when running the program instructions. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory, random access memory, magnetic disks, or optical disks.

[0138] Alternatively, all or part of the steps of the foregoing method embodiments can be implemented by hardware (such as electronic devices like personal computers, servers, or network devices) associated with program instructions. The program instructions can be stored in a computer-readable storage medium. When the program instructions are executed by the processor of the electronic device, the electronic device executes all or part of the steps of the methods described in the embodiments of this application.

[0139] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that within the spirit and principles of this application, modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein; and these modifications or substitutions do not cause the corresponding technical solutions to leave the protection scope of this application.

Claims

1. A cloud-based computer control computing power network task scheduling method, characterized in that, The method includes: In the cloud-based chemical control computing network, in response to one or more task requests from users, the task priorities of each pre-set task request are obtained; If the task priority of the task requirement is the first priority, then the task requirement with the first priority will be directly orchestrated, scheduled and deployed. If the task requirement has a priority other than the first priority, then the task requirements of other priorities will be assigned to a pre-built queue of other priorities; where the first priority is higher than other priorities. Calculate the internal priority of other priority task requirements in other priority queues, determine the internal order of other priority task requirements in other priority queues according to the internal priority of the queues, implement the internal ordering, and then perform orchestration, scheduling and deployment attempts according to the order of the internal ordering. If a first-priority task cannot be deployed due to insufficient resources, the physical resources of deployed task instances with lower priority than the first priority will be reclaimed according to the preset task eviction mechanism, and the reclaimed physical resources will be used for the deployment of the first-priority task. If other priority tasks cannot be deployed due to insufficient resources, the physical resources of deployed task instances with lower priority than other priorities will be reclaimed according to the preset task eviction mechanism, and the reclaimed physical resources will be used for the deployment of other priority tasks.

2. The method according to claim 1, characterized in that, After orchestrating, scheduling, and attempting deployment for first-priority task requirements, the method further includes: For the task instances corresponding to the first priority task requirements that have been deployed, mount an independent monitoring daemon. The monitoring daemon and the task instance coexist and die, and a periodic detection mechanism is established. The monitoring daemon periodically probes preset key network indicators between the user's terminal device and the cloud computing power nodes where the task instance is deployed, and obtains the network status of all candidate computing power nodes. When the detected preset key network indicators do not meet the preset service quality required by the task instance, a dynamic migration strategy is triggered. Based on the network status of all candidate computing power nodes, a target computing power node with idle resources and meeting the preset service quality is searched among all candidate computing power nodes, and the task instance is migrated to the target computing power node in real time.

3. The method according to claim 1, characterized in that, The data content of other priority queues includes task requirement information, internal queue priority, queue length, queue capacity, and queue sorting function; among which, task requirement information includes task requirement identifier, task requirement status, and task priority.

4. The method according to claim 3, characterized in that, Other priorities are any one of the second, third, and fourth priorities; other priority queues include the second priority queue, the third priority queue, and the fourth priority queue. If a task requirement has a priority other than the first priority, then the task requirements of other priorities will be placed into a pre-built queue of other priorities, including: If the task priority of the task requirement is the second priority, then the task requirement with the second priority will be assigned to the pre-built second priority queue. If the task priority of the task requirement is the third priority, then the task requirement with the third priority will be assigned to the pre-built third priority queue. If the task priority of the task requirement is the fourth priority, then the task requirement of the fourth priority will be assigned to the pre-built fourth priority queue.

5. The method according to claim 4, characterized in that, The capacity of other priority queues can be increased using the following formula: （1） Where k takes values ​​from 1 to n, and n is a natural number; The initial queue capacity is 128; This refers to the queue capacity before expansion. This represents the expanded queue capacity.

6. The method according to claim 4, characterized in that, The capacity of other priority queues can be reduced using the following formula: （2） Where r takes values ​​from 1 to m, and m is a natural number; This is the actual queue length; This is the initial queue length; This represents the queue capacity before shrinking. This represents the queue capacity after shrinking.

7. The method according to claim 4, characterized in that, The internal priority of other priority task requirements within other priority queues is calculated using the following formula: （3） where InnerPriority is the value corresponding to the inner priority of the queue; TaskGPU, TaskCPU, and TaskMemory are the GPU, CPU, and memory size required by the task demand of other priorities; GPU Max , CPU Max , and Memory Max are the maximum GPU core number, the maximum CPU core number, and the maximum memory that can be accommodated in the current cluster, respectively. At the same time, TaskGPU, TaskCPU, and TaskMemory satisfy equation (4): （4） If TaskGPU, TaskCPU, and TaskMemory do not satisfy equation (4), then other priority task requirements cannot be orchestrated, scheduled, and deployed, and subsequent steps will not be performed.

8. The method according to claim 4, characterized in that, Other priority queues use a heap structure for their data structure. Tasks of other priorities are ordered within these queues according to their internal priority, and this ordering is performed, including: Place other priority task requests at the end of the other priority queue, and perform a heap structure up adjustment operation according to the internal priority of the queue to adjust the other priority task requests to the determined internal sorting position.

9. The method according to claim 7, characterized in that, The default task eviction mechanism includes: The number of tasks that can be evicted under the priority of the currently pending tasks in the current cluster is calculated using the following formula: （5） Where EnableEnvictNum is the number of tasks that can be evicted based on the priority of the currently pending tasks in the current cluster; GPUSum i CPUSum i and MemorySum i These represent the total GPU, CPU, and memory usage of the load queue with priority i in the current cluster, respectively; p represents the priority of the task to be deployed. If the priority of the task to be deployed is the first priority, then p is 1; if the priority of the task to be deployed is the second priority, then p is 2; if the priority of the task to be deployed is the third priority, then p is 3; TaskGPU, TaskCPU, and TaskMemory are the GPU, CPU, and memory sizes required for other priority tasks, that is, the GPU, CPU, and memory sizes required for the task to be deployed. When EnableEnvictNum meets the deployment limit for the current task to be deployed, the eviction logic is executed, and the proximity between the element Deploy in the already deployed instance set Entry in the load queue and the current task to be deployed is calculated according to the following formula: （6） Where proximity is the nearest neighbor; DeployGPU, DeployCPU, and DeployMemory refer to the GPU usage, CPU usage, and memory usage of the element Deploy in the set of deployed instances Entry, respectively; abs() means taking the non-negative value of the calculation result within the parentheses; The elements Deploy in the deployed instance set Entry are sorted according to their proximity to the currently to-be-deployed task to determine the eviction order. Here, the elements Deploy in the deployed instance set Entry are also called deployed task instances.

10. A cloud-based computer control computing power network task scheduling system, characterized in that, The system includes: The acquisition unit is used in the cloud-based power control network to acquire the pre-set task priorities of each task requirement in response to one or more task requirements of the user. The first scheduling unit is used to directly orchestrate, schedule, and attempt to deploy tasks with the highest priority if the task requirement is the highest priority. The second scheduling unit is used to assign task requests of other priorities to a pre-built queue of other priorities if the task priority is other than the first priority; wherein the first priority is higher than other priorities; and Calculate the internal priority of other priority task requirements in other priority queues, determine the internal order of other priority task requirements in other priority queues according to the internal priority of the queues, implement the internal ordering, and then perform orchestration, scheduling and deployment attempts according to the order of the internal ordering. The intelligent eviction unit is used to reclaim the physical resources of deployed task instances with lower priority than the first priority according to a preset task eviction mechanism if the first priority task cannot be deployed due to insufficient resources, and then make the reclaimed physical resources available for the deployment of the first priority task. If other priority tasks cannot be deployed due to insufficient resources, the physical resources of deployed task instances with lower priority than other priorities will be reclaimed according to the preset task eviction mechanism, and the reclaimed physical resources will be used for the deployment of other priority tasks.

Images