Dynamic task scheduling system for space control simulation model computation

Abstract

This invention discloses a dynamic task scheduling system for space control simulation model computation, comprising a scheduling center, several scheduler nodes, and several executor nodes. The scheduler nodes and executor nodes are deployed on different server clusters. The scheduling center dynamically adjusts task scheduling based on dynamic load balancing technology according to the task scheduling requirements of the space control simulation service, allocating tasks to registered scheduler nodes. The scheduler nodes are used for task production and caching, and trigger the executor center using Remote Procedure Call (RPC) technology. They are also used for dynamic elastic scaling of executor nodes for tasks that cannot be fulfilled. The executor center logs into the scheduling center via heartbeat registration to achieve remote communication between the two. It is also used to decompose tasks and trigger the corresponding executor nodes. The executor nodes execute the corresponding space control simulation model computation tasks.

Description

Technical Field

[0001] This invention relates to the field of computer system space control simulation, and more particularly to a dynamic task scheduling system for space control simulation model calculation. Background Technology

[0002] In their exploration and research in the space domain, various countries have been conducting research on space control mission simulation, including full-space orbital maintenance, camera payload detection, debris avoidance and clearance, and on-orbit operation, in order to improve spacecraft performance while reducing the risks and costs of spacecraft development. Space control mission simulation requires virtualized space control mission deduction, evaluation, control, and decision-making activities within a simulated environment. This involves complex task processing involving coupled modeling of multiple disciplines such as spacecraft dynamics, fluid mechanics, and computer vision. The scale of this task is no longer manageable by a single application or server, but rather the result of the interaction of multiple server clusters. Therefore, space control mission simulation places higher demands on the resource utilization of server clusters.

[0003] Today, server-side architecture has undergone continuous upgrades and iterations from monolithic architectures to distributed architectures and then to microservices. While microservices bring powerful and flexible application expansion, they also present challenges such as cluster deployment and scheduling optimization. To optimize cluster resource scheduling, many distributed task scheduling systems have emerged. Their bottleneck lies in how to optimally control server resources, i.e., how to assign different thread / process quotas to each computing node for different business types. Among them, Dangdang Group's Elastic-Job task scheduling system provides functions such as task sharding and elastic scaling, but does not support dynamic management of scheduled tasks or workflow-type scheduled tasks; Dianping Group's XXL-JOB task scheduling system provides lightweight dynamic management of task scheduling, but its service registration capability is relatively slow under massive business processing; Alibaba's TBSchedule task scheduling system has strong scalability, but its task types are relatively limited; Spring Cloud Scheduler task scheduling system has powerful community features, but its architecture is relatively complex and has certain hardware resource requirements.

[0004] In actual space manipulation simulation tasks, due to the performance differences of each computing node in the server cluster, many task scheduling systems will experience load imbalance, leading to problems such as decreased system processing speed and increased network latency. For example: 1) The resource roles of task nodes are fixed or relatively simple, and too many node backups cause a large amount of ineffective resource overhead; 2) During load migration, a large number of tasks will be migrated to task nodes with lighter loads, causing the task nodes to trigger load balancing again, resulting in periodic oscillations and affecting the performance of the server system.

[0005] Therefore, for space manipulation simulation tasks, how to design a task scheduling system to optimize resource utilization, minimize system response time, maximize model computation efficiency, and avoid server overload has become an urgent problem to be solved. Summary of the Invention

[0006] The purpose of this invention is to overcome the shortcomings of the prior art and to propose a dynamic task scheduling system for space manipulation simulation model calculation.

[0007] This invention addresses the challenges posed by the high-concurrency calls to massive, multi-source, heterogeneous space manipulation simulation models in large-scale space manipulation simulation experiments to traditional service architectures, and establishes a dynamic task scheduling system with a load migration model at its core.

[0008] To achieve the above objectives, this invention proposes a dynamic task scheduling system for space manipulation simulation model computation. The system includes: a scheduling center, several scheduler nodes, and several executor nodes; the scheduler nodes and executor nodes are deployed on different server clusters, wherein...

[0009] The scheduling center is used to dynamically adjust task scheduling based on dynamic load migration technology according to the task scheduling requirements of the space manipulation simulation service, and to allocate tasks to registered scheduler nodes.

[0010] The scheduler node is used to generate and cache tasks, and uses Remote Procedure Call (RPC) technology to trigger the executor center. It is also used to dynamically and elastically expand the executor node for tasks that cannot be fulfilled.

[0011] The executor center is used to log in to the scheduling center via heartbeat registration to achieve remote communication between the two; it is also used to perform specific calculation processes and task decomposition for tasks, and trigger the corresponding executor nodes to achieve high-concurrency execution of task scheduling.

[0012] The actuator node is used to perform the corresponding spatial manipulation simulation model calculation task.

[0013] As an improvement to the above system, the dynamic load migration technology establishes an optimal control load migration model using a dynamic load migration algorithm; wherein, the load migration model includes:

[0014] The status information returned by scheduler node j is determined by the task scheduling queue length Q. i The number T of idle threads in the scheduler's thread pool j Form N pairs < Q i ,T j >, i, j = 1, 2, ..., N, the load balancing time of the scheduler node. The length of the task scheduling queue is directly proportional to the number of threads concurrently processing this type of task, satisfying the following formula:

[0015]

[0016]

[0017] in, This represents the idle time of scheduler node j serving i tasks, where α is the transmission attenuation coefficient, a constant related to the server-side switch and controller, E[ΔL]. i,j [(t)] is the mathematical expectation of the load change of the scheduler node.

[0018] As an improvement to the above system, the establishment of the optimal control load migration model specifically includes:

[0019] Define the Real-Time Load (RLP) metric L i,j (t) satisfies the following equation:

[0020] L i,j (t)=(aN c +bC c +cM c ) / (N r +C r +M r )

[0021] Where a, b, and c represent the proportions of network bandwidth, CPU resources, and memory resources in the overall server resources, respectively; the subscript r represents the overall server resources; the subscript c represents the currently used resources; N represents network bandwidth; C represents CPU computing resources; and M represents memory size.

[0022] Define the task scheduling and allocation weights TSW index W i,j (t) satisfies the following equation:

[0023] W i,j (t)=h i,j (t-1)ξ i (L i,j (t)-L i,j (t-1)) / Q i

[0024] Where, ξ i For task scheduling complexity, h i,j (t-1) represents the load migration flag coefficient of the current scheduler node. If the scheduler node did not perform a load migration operation at the previous sampling time, h i,j (t-1) defaults to 1, h is used when the load has been migrated. i,j (t-1) is 0.5;

[0025] The load migration time (TLT) metric U(t) is defined as satisfying the following formula:

[0026]

[0027] Among them, u i,j (t) represents the load migration amount in a single operation;

[0028] Obtain the load balancing time of the scheduler node for:

[0029]

[0030] Meet the scheduler node load balancing time To minimize the rate of change of the load migration amount (TLT) metric U(t) and reduce the frequency of server resource adjustments, the optimal control load migration amount U is obtained at the t-th sampling time. * (t) is:

[0031] U * (t)=U(t-1)-E i,j {α / 2W i,j (t)Q i T j}

[0032] Where U(t-1) represents the load migration time TLT index at the (t-1)th sampling time, E i,j {} represents the mathematical expectation calculation.

[0033] As an improvement to the above system, the dynamic load migration algorithm specifically includes:

[0034] Input the length Q of the task scheduling queue at time t. i (t) and the number of threads T in the scheduler's thread pool j (t);

[0035] Each scheduler node is added to the set Φ{desc} in descending order of RLP metrics, and the load balancing threshold u at the current moment is calculated. thr (t), and stipulates that at any given time, the scheduler node will only respond to one load migration request, and can only accept another request after this request is completed;

[0036] A greedy algorithm is used to iterate through the optimal load migration node at each sampling time of each scheduler node, and the optimal load migration amount is calculated.

[0037] As an improvement to the above system, the method employs a greedy approach to iterate through the optimal load migration node at each sampling time of each scheduler node, performing iterative selection and calculating the optimal load migration amount; specifically, it includes:

[0038] Calculate the TLT metric and select the scheduler node with the lowest idle time as the load migration target;

[0039] If multiple scheduler nodes with the same idle degree exist, calculate the TSW metric for a single scheduler node, and select the scheduler node with the higher weight as the first load migration target. Calculate the single load migration amount u based on the resource status of that scheduler node. i,j (t), when the amount of a single load migration exceeds the load balancing threshold u i,j When (t), the scheduler node is removed from the set, and the subsequent scheduler node is selected to recalculate whether the task scheduling request is acceptable.

[0040] Calculate the total load migration U for optimal control. * (t), and mark the scheduler node, and set the load migration marking coefficient h. i,j (t) is set to 0.5.

[0041] As an improvement to the aforementioned system, the system further includes: a global resource control module, a monitor, an elastic scaling module, and container orchestration tools; wherein,

[0042] The global resource control module is used to receive the suspension status of tasks in the server cluster through a heartbeat mechanism;

[0043] The monitor is used to periodically monitor the task suspension status in the server cluster where the executor node is located by subscribing to the heartbeat information of the global resource control module.

[0044] The elastic scaling module is used to create new executor nodes and save them to the expansion queue Expanding Q based on the task suspension status using the dynamic elastic scaling algorithm Auto Scale(·). It is also used to send instructions to create new executor nodes to the container orchestration tool.

[0045] The container orchestration tool is used to read new executor node information from the expansion queue, create new executor nodes, and add them to the container cluster.

[0046] As an improvement to the above system, the processing procedure of the elastic scaling module specifically includes:

[0047] The type of the executor node is set according to the resource information of each suspended task. If the executor node type is contained in the expansion queue Expanding Q, the search for the next suspended task continues. Otherwise, the executor node is added to the expansion queue Expanding Q.

[0048] As an improvement to the above system, the processing of the scheduler node further includes:

[0049] When the scheduler detects a newly added executor node, it reawakens the suspended task and checks again whether the executor node meets the task's resource requirements: if the executor node meets the task's resource requirements, the task will be scheduled to the executor node; if it still does not meet the requirements, the task will be put back into a suspended state.

[0050] Compared with the prior art, the advantages of the present invention are:

[0051] 1. This invention breaks through key technologies such as dynamic task scheduling, dynamic load migration, and dynamic elastic expansion, optimizes server resource allocation to improve task processing capabilities, and provides technical support for high-concurrency task computing needs in large-scale space manipulation simulation experiments.

[0052] 2. This invention promotes the development of task scheduling platforms and load balancing technologies based on microservices technology, and solves the technical problems of slow service registration capabilities, large server-side resource consumption, and oscillating load migration cycles in existing technologies under high-concurrency task response.

[0053] 3. This invention establishes a dynamic task scheduling system based on a load migration model to achieve optimal server resource allocation. At the same time, a dynamic load migration algorithm is designed to avoid load balancing oscillations, effectively constraining load migration behavior, improving server stability, and ultimately improving the performance of handling massive tasks.

[0054] 4. This invention establishes a generalizable platform system suitable for large-scale space manipulation simulation experiments, supporting activities such as space manipulation simulation, evaluation, control, and decision-making involving multidisciplinary coupled modeling and complex task processing, and has high application value. Attached Figure Description

[0055] Figure 1 This is a technical roadmap for the dynamic task scheduling system for space manipulation simulation model calculation according to the present invention;

[0056] Figure 2 It is a sequence diagram of the fully asynchronous distributed dynamic task scheduling process;

[0057] Figure 3 This is a description of the dynamic load migration algorithm process;

[0058] Figure 4 This describes dynamic elastic expansion technology;

[0059] Figure 5 It refers to hardware environment deployment;

[0060] Figure 6It is the real-time load status of the 40G control object interaction data packets;

[0061] Figure 7(a) shows the real-time load status of task scheduling at different magnitudes;

[0062] Figure 7(b) shows the load balancing time for task scheduling of different magnitudes. Detailed Implementation

[0063] This invention relates to a dynamic task scheduling system for space manipulation simulation model computation, and the technical approach is as follows: Figure 1 As shown:

[0064] The system includes: a scheduling center, several scheduler nodes, and several executor nodes; the scheduler nodes and executor nodes are deployed on different server clusters, wherein...

[0065] The scheduling center is used to dynamically adjust task scheduling based on dynamic load migration technology according to the task scheduling requirements of the space manipulation simulation service, and to allocate tasks to registered scheduler nodes.

[0066] The scheduler node is used to generate and cache tasks, and uses Remote Procedure Call (RPC) technology to trigger the executor center. It is also used to dynamically and elastically expand the executor node for tasks that cannot be fulfilled.

[0067] The executor center is used to log in to the scheduling center via heartbeat registration to achieve remote communication between the two; it is also used to perform specific calculation processes and task decomposition for tasks, and trigger the corresponding executor nodes to achieve high-concurrency execution of task scheduling.

[0068] The actuator node is used to perform the corresponding spatial manipulation simulation model calculation task.

[0069] The technical solution of the present invention will be described in detail below with reference to the accompanying drawings and embodiments.

[0070] Example 1

[0071] The embodiments of the present invention propose a dynamic task scheduling system for spatial manipulation simulation model computation. The dynamic task scheduling system mainly consists of three parts: task scheduling, remote execution, and data management. The dynamic task scheduling system mainly involves three key technologies: fully asynchronous distributed dynamic task scheduling technology, dynamic load migration technology based on load migration model, and dynamic elastic scaling technology.

[0072] To meet the scheduling needs of various space control simulation tasks, such as spacecraft orbital maneuvering simulation, attitude adjustment, space-to-ground and inter-satellite communication, and space operations, the dynamic task scheduling system utilizes fully asynchronous distributed dynamic task scheduling technology for high-concurrency computation of massive simulation tasks. First, the scheduling center dynamically activates each scheduler node. Then, each scheduler node uses Remote Procedure Call (RPC) technology to publish messages to the executor center. The executor center breaks down the computation process into corresponding computation tasks and assigns executor nodes to each task for computation. Finally, the computation results are synchronized to relational and non-relational databases, enabling rapid data caching, storage, retrieval, and management. The scheduling center employs dynamic load migration technology based on a load migration model to achieve adaptive scheduler node resource allocation. If the current server cluster resources do not meet the resource consumption requirements of the task allocation, dynamic elastic scaling technology is used to vertically expand the server cluster, increasing node resources to complete the computation tasks.

[0073] (1) Fully asynchronous distributed dynamic task scheduling technology

[0074] The specific working sequence of the fully asynchronous distributed dynamic task scheduling technology is as follows: Figure 2 As shown, when new task scheduling needs arise externally, tasks are distributed to the scheduling center through a dynamic load migration algorithm. The scheduling center does not participate in the execution of computational tasks but instead redistributes the tasks to registered scheduler nodes. The scheduler nodes then produce and write tasks to the consumer queue cache at the queue interaction layer. Subsequently, based on the task allocation results from the scheduler nodes, the tasks in the consumer queue are stabilized in the writing order, and the executor center in the computation layer is triggered using Remote Procedure Call (RPC) technology. The executor center can be deployed in a distributed cluster within the server cluster and logs into the scheduling center via heartbeat registration to achieve remote communication between the two. Finally, the executor center performs specific computational processes and task decomposition on the tasks, triggering the corresponding executor nodes to achieve high-concurrency execution of task scheduling.

[0075] The dynamic task scheduling system uses the scheduling center as the control platform. It quickly analyzes the user's relevant computing needs to trigger the scheduling center to allocate jobs, and the actual processing of jobs is carried out through the executor center. It supports the registration or removal of corresponding executors for dynamic elastic expansion, realizing a fully asynchronous design and distributed deployment of task scheduling.

[0076] The specific working sequence of the fully asynchronous distributed dynamic task scheduling technology is as follows: Figure 2As shown, when new task scheduling needs arise externally, tasks are distributed to the scheduling center through a dynamic load migration algorithm. The scheduling center does not participate in the execution of computational tasks but instead redistributes the tasks to registered scheduler nodes. The scheduler nodes then produce and write tasks to the consumer queue cache at the queue interaction layer. Subsequently, based on the task allocation results from the scheduler nodes, the tasks in the consumer queue are stabilized in the writing order, and the executor center in the computation layer is triggered using Remote Procedure Call (RPC) technology. The executor center can be deployed in a distributed cluster within the server cluster and logs into the scheduling center via heartbeat registration to achieve remote communication between the two. Finally, the executor center performs specific computational processes and task decomposition on the tasks, triggering the corresponding executor nodes to achieve high-concurrency execution of task scheduling.

[0077] The core of the fully asynchronous distributed dynamic task scheduling technology lies in how to optimally allocate tasks to scheduler nodes. Therefore, this invention proposes a dynamic task scheduling algorithm, TaskSchedule(·), which obtains a set of nodes that meet the resource requirements by traversing all scheduler nodes in the server cluster, and uses dynamic load migration technology based on the load migration model to dynamically adjust task scheduling. For tasks that cannot be met under this scheduling strategy, dynamic elastic scaling technology is used to vertically scale up the server cluster, increase node resources to complete the scheduling task. The overall idea is shown in Table 1.

[0078] Table 1. Dynamic Task Scheduling Algorithm (Task Schedule)

[0079]

[0080]

[0081] Specifically, first, the server cluster is initialized using Resources init, and then user-submitted task scheduling requests enter the scheduling queue Q. i In the sequence i = {1, 2, ..., N}, by traversing all scheduler nodes in the server cluster, the resource requirements Q carried by the task itself are determined. i The local scheduler first checks if the resources of its own node, `localNode.res`, meet the requirements. If so, the task is scheduled to its own node. If not, the dynamic load balancing algorithm `Load Balance()` is executed. This algorithm iterates through all nodes in the cluster to obtain a set of nodes that meet the resource requirements and then uses the dynamic load balancing algorithm to obtain the optimal task scheduling allocation result on this set of nodes. If the resources of any node cannot meet the resource requirements of the task, the task is suspended. iWhile pending, the server cluster is simultaneously being scaled up using the Auto Scale algorithm. Scale-up operations are divided into horizontal and vertical scaling. Horizontal scaling can only replicate configured resource nodes, while vertical scaling is more flexible and can recreate resource nodes based on task resource requirements. When a new node is added to the server cluster, the pending tasks are re-examined, and their resource requirements are checked. If a node meets the requirements, the pending tasks are re-entered into a ready state and rescheduled to the newly added node.

[0082] (2) Dynamic load migration technology based on load migration model

[0083] 1) Definition of load migration model

[0084] The bottleneck of fully asynchronous distributed dynamic task scheduling technology lies in how to optimally control server resources, i.e., how to allocate different computing nodes to each computing task. Load balancing strategies ensure balanced scheduling of computing nodes, avoiding overload or idle states. Most current load balancing strategies are based on the assumption that client access volume and service response time exhibit an exponential distribution. However, spatial manipulation simulation tasks involve synchronous calls to large-scale computing services and high-frequency data interaction and read / write operations, making it difficult to accurately calculate service response times. To accurately assess the load status of each node on the server and efficiently allocate new task requests, while avoiding server overload caused by a surge in computing tasks or server hibernation due to a sudden decrease in tasks, this invention establishes a load migration model to achieve optimal node resource allocation.

[0085] The status information returned by server node j is determined by the task scheduling queue length Q. i The number of idle threads T in the server thread pool j The N pairs of tuples < Q i ,T j >i,j=1,2,...,N. Load balancing time for each node of the server. It is directly proportional to the length of the task scheduling queue and inversely proportional to the number of threads that concurrently process this type of task.

[0086]

[0087] This represents the idle time of server node j serving i task scheduling, and is inversely proportional to the server node load balancing time. α is the transmission attenuation coefficient, a constant related to the server-side switch, controller, and other systems.

[0088] E[ΔL i,j [(t)] is the mathematical expectation of the change in server node load.

[0089] Definition 1 Real-time Load Probability (RLP): The server's workload status is related to factors such as network bandwidth N, CPU computing resources C, and memory size M. The formula for calculating RLP is shown in formula (2):

[0090]

[0091] Where a, b, and c represent the resource weights of network bandwidth, CPU resources, and memory resources in the overall service component, respectively; the subscript r represents the overall resources of the service component; and the subscript c represents the various types of resources currently in use.

[0092] Definition 2: Task Scheduler Weight (TSW): TSW is defined as the priority relationship of the server in allocating tasks for scheduling, and it is directly proportional to the idle level of the current node. The smaller the TSW, the more "discriminated" the corresponding business flow is in resource scheduling.

[0093]

[0094] Where ξ i For task scheduling complexity, h i,j (t-1) is the load migration flag coefficient of the current node. If the node did not perform a load migration operation at the previous sampling time, the coefficient is 1 by default. When the load has been migrated, the coefficient is 0.5.

[0095] Definition 3: Total Load Transform (TLT): TLT is defined as the total load transformation between server nodes and idle threads, used to describe the overall system overhead.

[0096]

[0097] Among them, u i,j (t) represents the load migration amount in a single operation. Combining formulas (1) and (4), the server load balancing time can be obtained as follows:

[0098]

[0099] In summary, server-side thread / process scheduling can establish an optimal load migration model. On the one hand, it aims to minimize the load balancing time across server nodes; on the other hand, it minimizes the rate of change of TLT to reduce system overhead. The loss function is constructed as follows:

[0100]

[0101] Where E i,jLet U(t) be the mathematical expectation. When the loss reaches its minimum value, the derivative with respect to U(t) is zero, and we have:

[0102]

[0103] Solving equation (6), the load migration amount of the optimal control at the t-th sampling time is obtained as follows:

[0104] U * (t)=U(t-1)-E i,j {α / 2W i,j (t)Q i T j} (8)

[0105] 2) Dynamic load migration algorithm

[0106] When performing load migration between server threads or processes, it is necessary to consider how to address the oscillating migration phenomenon caused by server overload due to a surge in tasks, which necessitates further load migration. To address this, this invention designs a dynamic load migration algorithm, Load Balance(·), based on a load migration model. This algorithm can effectively constrain load migration behavior and avoid load balancing oscillations.

[0107] Table 2 Dynamic Load Migration Algorithm Load Balance(·)

[0108]

[0109]

[0110] The overall idea of ​​the dynamic load balancing algorithm is shown in Table 2, and the algorithm flowchart is as follows. Figure 3 As shown, the algorithm input is the length Q of the task scheduling queue at time t. i (t) and the number of threads T in the server thread pool j (t), where i,j={1,2,...,N}. First, each resource node is added to the set Φ{desc} in descending order of RLP, and the load balancing threshold u at the current moment is calculated. thr (t), and stipulates that at the same time, a resource node can only respond to one load migration request, and can only accept another request after the first request is completed. Then, a greedy approach is used to determine the resource nodes that can accept the request: (1) Calculate the real-time load according to formula (2), and select the node with the smallest idle degree as the load migration object; (2) If there are multiple nodes with the same idle degree, calculate the task scheduling allocation weight (TSW) of each node according to formula (3), and select the node with the higher weight as the first load migration object. Calculate the single load migration amount u according to the resource status of the node. i,j (t), when the amount of a single load migration exceeds the load balancing threshold ui,j When (t), the resource node is removed from the set, and the subsequent resource nodes are selected to recalculate whether the task scheduling request is acceptable. Finally, based on the loss function of the optimal control load migration model derived from formula (8), the total load migration U of the optimal control is calculated. * (t), and mark the resource node, that is, the load migration marking coefficient h. i,j (t) is set to 0.5. Similarly, the optimal load migration node is iteratively selected for subsequent sampling times, and the optimal load migration amount is calculated. Since the algorithm prioritizes nodes with lower task scheduling weights (TSW) as load migration targets, the probability of this resource node being selected again at the next sampling time will be increased, in order to minimize the overall number of load migrations.

[0111] (3) Dynamic elastic expansion technology

[0112] Scaling operations are divided into horizontal scaling and vertical scaling. Horizontal scaling can only replicate configured resource nodes, while vertical scaling has a more flexible mechanism and can recreate resource nodes according to the resource requirements of tasks. For tasks that cannot be scheduled under the aforementioned dynamic load migration technology, this invention designs a dynamic elastic scaling technology to vertically scale the server cluster, adding node resources to complete scheduling: It re-traverses suspended tasks and checks their resource requirements. When a node meets the requirements, the suspended task is converted back to a ready state and rescheduled to the newly added node, thus reducing the server cluster load together with horizontal scaling.

[0113] Dynamic elastic expansion technology mechanism such as Figure 4 As shown, a monitor is set up to manage the expansion process, and the elastic scaling module is responsible for the specific execution of the expansion. The specific process is as follows:

[0114] (1) When the server cluster node cannot meet the task resource requirements, the task is put into a suspended state, and the resource B required by the node will be transmitted to the global resource control module through the heartbeat mechanism.

[0115] (2) The monitor monitors the cluster status by subscribing to heartbeats. The monitor receives information from the global resource control module every heartbeat time, including the resource requirements of suspended tasks (Resource B). Then, it triggers vertical expansion. The elastic scaling module creates new resource nodes according to the dynamic elastic scaling algorithm Auto Scale(·) and saves them to the expansion queue Expanding Q. The dynamic elastic scaling algorithm is shown in Table 3.

[0116] (3) After receiving the instruction to create a new node, the container orchestration tool reads the node information from the expansion queue, creates the new node, and adds it to the container cluster. Once the new node is created, it removes the corresponding node from the expansion queue.

[0117] (4) Finally, the scheduler will detect the newly added node, re-wake up the suspended task, and determine again whether the node meets the task resource requirements: if the node meets the task resource requirements, the task will be scheduled to this node; if it still does not meet the requirements, the task will be put back into a suspended state.

[0118] Table 3. Dynamic Elastic Expansion Algorithm Auto Scale(·)

[0119]

[0120] In the Auto Scale (·) dynamic elastic scaling algorithm, a node type is set based on the resource information of each suspended task. If the scaling queue contains a node of that type, the search for the next suspended task continues iteratively; otherwise, the node type is added to the scaling queue. By setting up the scaling queue, the node creation time is reduced, while preventing a suspended task from creating too many nodes.

[0121] Simulation example:

[0122] (1) Preparation of experimental environment

[0123] The dynamic task scheduling system and method designed in this invention were field-tested in a large spacecraft experimental simulation system. The system deployed two types of cloud computing virtual node clusters: 1) a task scheduling central control cluster: consisting of 3 servers, using cloud platform technology to virtualize cloud computing nodes, responsible for deploying the scheduling center to receive massive simulation task scheduling requests from users; 2) an actuator processing cluster: consisting of 5 servers, responsible for deploying the actuator center and database for efficient task processing and data storage. Its hardware deployment diagram is shown below. Figure 5 As shown in Table 2, based on the principle of domestic self-reliance and controllability, the basic environment is built using a Loongson rack server TL621 cluster, a Galaxy Kylin server operating system V4.0, and a Shenzhou General domestic database V7.0. The detailed configuration parameters are shown in Table 2.

[0124] Table 4 Hardware and Software Environment Parameter Configuration Table

[0125]

[0126] (2) Analysis of experimental results

[0127] To meet the scheduling needs of various space control simulation missions, such as spacecraft orbital maneuvering simulation, step attitude adjustment, space-to-ground and inter-satellite communication, and space operations, the actual performance of the dynamic mission scheduling system in this invention is verified through experiments. The experimental results and analysis are compared and analyzed from the aspects of architecture latency and load balancing performance.

[0128] 1) Architecture response latency experiment

[0129] By simultaneously calculating 1000 spacecraft orbit simulations, spacecraft on-orbit attitude calculations, and space-to-ground and inter-satellite communication time periods, the response latency of the dynamic task scheduling system was compared with that of the current mainstream open-source microservice architectures at home and abroad. The experimental results are shown in Table 5. It can be seen that Xxl-job, as a lightweight architecture, has a shorter overall latency, while Spring Cloud has a longer business response latency due to its more complex architecture. The dynamic task scheduling system in this invention performs well in different architectures, and the average single task response latency is shortened by 0.10s, 0.25s, and 0.92s compared with the other three task scheduling architectures.

[0130] 2) Load balancing performance test

[0131] The following observation metrics were selected for real-time load balancing (RLP) calculation to test load balancing time: (1) CPU utilization; (2) memory utilization; (3) disk transfer volume; (4) network traffic. Load balancing time was calculated by recording the above observation metrics every 0.2 seconds from the start of server operation. The maximum time interval before and after task scheduling was calculated when handling different task schedules. Figure 6 As shown, the observation indicators (1)-(4) were initially in a balanced state at 6.02s, 6.05s, 0.12s, and 0.10s, respectively. During the processing of interactive data packets of 4000 individual 10M control objects, the indicators reached a balanced state again at 24.34s, 24.10s, 22.26s, and 26.15s, respectively. The time intervals between the two balanced states were 18.32s, 18.05s, 22.14s, and 26.05s, respectively. Therefore, the average load balancing time of the dynamic task scheduling system of the present invention is 21.56s.

[0132] The system handles various space control simulation tasks, including spacecraft orbit deduction, spacecraft on-orbit attitude calculation, and satellite-to-ground and inter-satellite communication time calculation. Figure 7(a) shows the load balancing time under increasing task numbers: load balancing time is positively correlated with the number of scheduled tasks, and the higher the algorithm complexity of the space control simulation task, the longer the load balancing time. Figure 7(b) shows the real-time load status of one type of space control simulation task under increasing spacecraft orbit deduction task numbers: system CPU utilization and disk read / write rate are directly proportional to the number of scheduled tasks, while memory utilization increases along with the number of scheduled tasks until saturation. Simultaneously, when processing 2000-level tasks, although memory utilization approaches its limit, the dynamic load migration technology based on the load migration model of this invention ensures that computational scheduling only acquires computational tasks matching the current effective load, and the remaining computational tasks are queued for processing. Therefore, computational scheduling blocking leading to server crashes does not occur. Future prospects suggest that with upgrades and expansion of the hardware and software environment, the dynamic task scheduling system of this invention can support the processing of tens of thousands, millions, and even larger-scale space control simulation tasks.

[0133] It should be noted that the simulation model for space control is not limited to spacecraft, but also includes simulation models for communication links in ground application systems. This system can also be applied to model calculations for all large-scale, high-concurrency applications.

[0134] Innovation points:

[0135] (1) At present, domestic and foreign task scheduling systems have problems such as complex architecture, single task type, and slow service registration capability under massive business processing. This invention builds a fully asynchronous and distributed dynamic task scheduling system, which has the advantages of rapid response of computing tasks and high throughput stability.

[0136] (2) In practical applications, due to the differences in performance of each computing node in the server cluster, the task scheduling system will have a load imbalance phenomenon. Current domestic and foreign load balancing technologies have limitations such as large resource consumption caused by node backup and load migration cycle fluctuations. This invention can shorten the load balancing cycle, optimize the allocation of server node resources, and improve server stability by using task scheduling algorithm, dynamic load migration algorithm, and dynamic elastic expansion algorithm in the dynamic task scheduling system.

[0137] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to the embodiments, those skilled in the art should understand that modifications or equivalent substitutions to the technical solutions of the present invention do not depart from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A dynamic task scheduling system for space control simulation model calculation, characterized in that, The system includes: a scheduling center, several scheduler nodes, and several executor nodes; the scheduler nodes and executor nodes are deployed on different server clusters, wherein... The scheduling center is used to dynamically adjust task scheduling based on the optimal control load migration model according to the task scheduling requirements of the space manipulation simulation service, and to allocate tasks to registered scheduler nodes. The scheduler node is used to generate and cache tasks, and uses Remote Procedure Call (RPC) technology to trigger the executor center. It is also used to dynamically and elastically expand the executor node for tasks that cannot be fulfilled. The executor center is used to log in to the scheduling center via heartbeat registration to achieve remote communication between the two; it is also used to decompose the calculation process and calculation tasks of the tasks, and trigger the corresponding executor nodes to achieve high-concurrency execution of task scheduling. The actuator node is used to perform the corresponding spatial manipulation simulation model calculation task; The optimal control load migration model is established using a dynamic load migration algorithm; the specific establishment process includes: Define Real-Time Load (RLP) Metrics ; Define the task scheduling and allocation weights TSW index Satisfy the following formula: ； in, For the complexity of task scheduling, For the current scheduler node j The load migration flag coefficient is used if the scheduler node did not perform a load migration operation at the previous sampling time. The default value is 1, which is used when the load has been migrated. It is 0.5; The length of the task scheduling queue; Define the Load Migration Time (TLT) metric ; Obtain the load balancing time of the scheduler node for: ； in, The transmission attenuation factor is a constant related to the server-side switch and controller. This represents the number of idle threads in the scheduler's thread pool. Get the first t Optimal load migration at each sampling time for: ； in, Indicates the first t -1 sampling time point load migration TLT index Calculate the mathematical expectation; The dynamic load migration algorithm specifically includes: Enter current t Task scheduling queue length at any given time and the number of threads in the scheduler's thread pool ; Each scheduler node is added to the set in descending order of the real-time load RLP metric. At the same time, the load balancing threshold at the current moment is calculated, and it is stipulated that at the same time, the scheduler node only responds to one load migration request. Calculate the load migration time (TLT) metric and select the scheduler node with the lowest idle time as the load migration target. If there are multiple scheduler nodes with the same idle level, calculate the Task Scheduling Allocation Weight (TSW) index for a single scheduler node, and select the scheduler node with the higher weight as the first load migration target. Calculate the single load migration amount based on the resource status of the scheduler node. When the single load migration amount exceeds the load balancing threshold, remove the scheduler node from the set, and recalculate whether the subsequent scheduler nodes can accept the task scheduling request. Calculate the total load migration for optimal control and mark the scheduler node, setting the load migration marking coefficient to 0.

5.

2. The dynamic task scheduling system for space manipulation simulation model calculation according to claim 1, characterized in that, The system also includes: an elastic scaling module, a global resource control module, a monitor, and container orchestration tools; wherein... The processing steps of the elastic scaling module include: setting the type of executor node based on the resource information of each suspended task; if the expansion queue contains the executor node type, then iteratively searching for the next suspended task; otherwise, adding the executor node to the expansion queue; the elastic scaling module is also used to send instructions to create new executor nodes to the container orchestration tool. The global resource control module is used to receive the suspension status of tasks in the server cluster through a heartbeat mechanism; The monitor is used to periodically monitor the task suspension status in the server cluster where the executor node is located by subscribing to the heartbeat information of the global resource control module. The container orchestration tool is used to read new executor node information from the expansion queue, create new executor nodes, and add them to the container cluster.

3. The dynamic task scheduling system for space manipulation simulation model calculation according to claim 1, characterized in that, The processing of the scheduler node also includes: When the scheduler detects a newly added executor node, it reawakens the suspended task and checks again whether the executor node meets the task's resource requirements: if the executor node meets the task's resource requirements, the task will be scheduled to the executor node; if it still does not meet the requirements, the task will be put back into a suspended state.

Images