Satellite cloud computing internet platform-oriented satellite grouping management system

Abstract

The invention provides a satellite grouping management system for a satellite cloud computing internet platform. Comprising three modules: a grouping management module, a task scheduling module and a low-delay service migration management module, and the three modules all run on a management node k3s master of k3s; in the functional architecture, the client side skclient accesses an API provided by a system through a remote procedure call frame gRPC, and is used for submitting tasks to a task scheduling module and a low-delay service migration management module in a management node k3s master and adding and deleting a peer relation to a grouping management module; the API submits a task or service to the skagent on the working node satellite, and after the access of a user reaches the skagent running on the working node, the skagent running on the working node forwards a user request to a corresponding module of a management node k3s master of k3s; and the skagent running on each working node is also in communication connection with a satellite distributed file system. The problem that a resource scheduling system adapts to a satellite network with wide geographical distribution and high dynamic time-varying characteristics is solved.

Description

Technical Field

[0001] The present disclosure relates to the field of satellite resource scheduling, and more specifically, to a satellite grouping management system for a satellite cloud computing Internet platform. Background Art

[0002] At present, cloud computing resource scheduling based entirely on low-orbit satellite platforms is still a relatively new research field, and related research work is still mainly based on assumptions and simulations. Considering that low-orbit satellites are more dispersed in network topology than data center scenarios, satellite computing resources are similar to edge scenarios, and existing wide-area resource management and edge computing resource management related work can also be used as a reference. This paper introduces related work from two aspects: low-orbit satellite computing and wide-area / edge computing resource management.

[0003] The research on on-orbit computing of low-orbit satellites is currently focused on exploring application scenarios and future research directions. Some work has studied the service placement and orchestration issues of low-orbit satellite computing through simulation.

[0004] The work for wide-area scenarios mainly focuses on optimizing scheduling algorithms, and comprehensively considers data and computing placement strategies based on the characteristics of wide-area environments such as limited bandwidth and strong resource heterogeneity.

[0005] At present, the mainstream edge task scheduling and service orchestration frameworks are mainly based on frameworks streamlined from Kubernetes, such as KubeEdge and k3s. These frameworks basically follow the centralized design of Kubernetes and are suitable for relatively centralized edge clusters. This centralized design is obviously not suitable for situations with wide geographical distribution. Therefore, edge computing mainly studies the problem of how to decentralize.

[0006] Problems with existing resource scheduling

[0007] 1. High-speed movement: Compared with the scheduling within and across data centers at fixed locations on the ground, low-orbit satellite constellations are in a state of continuous high-speed movement.

[0008] 2. Predictable trajectory: Compared with scenarios with motion characteristics on the ground (such as mobile edge computing), satellites move in a predetermined orbit, and their trajectory is predictable within multiple orbital periods.

[0009] 3. Computing resource differences: Since the computing load of low-orbit satellites is weaker than that of ground data centers, the geographical distribution is wide and uniform, and the inter-satellite network communication delay is large,

[0010] In summary: the existing resource scheduling systems are unable to adapt to satellite networks that are geographically widely distributed and have highly dynamic time-varying characteristics: on the one hand, the number of satellites is huge and evenly distributed around the earth, and the existing systems cannot efficiently manage satellite resources; on the other hand, the existing resource allocation strategies are difficult to adapt to scenarios where satellites move at high speeds and user locations are unevenly distributed. Summary of the invention

[0011] The purpose of the embodiments of the present disclosure is to provide a satellite group management system for a satellite cloud computing Internet platform. The main research goal of the present invention is to realize the automatic generation of code summary documents with project-level granularity through the organic combination of a hierarchical model and program analysis technology. The specific object of the study is English documents, and the programming language targeted is Java. The summary document is mainly reflected in a short natural language summary, and does not involve complex information such as directory structure, instructions for use, etc. Based on this model, an open source code repository summary automatic generation tool is designed and implemented on the Eclipse IDE in the form of an Eclipse plug-in.

[0012] In a general aspect, a satellite group management system for a satellite cloud computing Internet platform is provided, which includes three modules: a group management module, a task scheduling module and a low-latency service migration management module, all of which run on the management node k3s master of k3s; the system also includes an ephemeris calculation module that provides satellite information for each module, a client skclient running on a client terminal, and a skagent running on a working node satellite;

[0013] In terms of functional architecture, the client skclient accesses the API provided by the system through the remote procedure call framework gRPC, which is used to submit tasks to the task scheduling module and low-latency service migration management module in the management node k3s master, and to add and delete peer relationships to the group management module;

[0014] The API can be used to submit tasks or services to the skagent on the work node satellite. After the user's access reaches the skagent running on the work node, the skagent running on the work node forwards the user request to the corresponding module of the k3s management node k3s master; the skagent running on each work node is also connected to the satellite distributed file system;

[0015] The functions of each module are as follows:

[0016] The group management module internally constructs a delay-constrained satellite group management mechanism, and designs a load balancing strategy between groups based on geographic information suitable for satellite systems, constructs a group management interface design, an adjacent group registration mechanism and an adjacent group status management mechanism, manages adjacent group relationships, and collects the resource status of adjacent groups; the task scheduling module is responsible for monitoring tasks submitted by users, and implements three mechanism designs through task interface design, resource pool management, and task scheduling, and allocates computing resources to tasks or schedules them to other groups according to the scheduling strategy. At the same time, this module is also responsible for the management of the resource pool; the low-latency service migration management module constructs a satellite network low-latency service migration mechanism, and is responsible for calculating the optimal migration path according to the user's location through interface design, enlistment warm-up mechanism, and cross-group service migration mechanism design, and manages the migration status of services within and between groups;

[0017] The system also includes a scheduling strategy simulator for satellite cloud computing resources, which consists of a task generation module, an ephemeris management module, a simulation module, a scheduler module, and a data processing module;

[0018] The task generation module is responsible for generating the task load within a period of time according to the task generation configuration provided by the user, and mapping it to the corresponding satellite; the ephemeris management module is responsible for providing satellite-related information, including the communication interval with the ground position and visible satellites. It runs on the k3s management node and is responsible for providing the user communication interval information required by the scheduling algorithm, while maintaining the current satellite position information of the group; the simulation module is composed of a simulation process controller and a plurality of satellite grouping objects. The simulation process controller drives the overall simulation process. The satellite grouping object is mainly responsible for simulating the grouping state, including the state of tasks within the group, adjacent groups and satellites within the group; the scheduler module implements various scheduling strategies. The satellite cluster process completes the simulation of task scheduling by calling the interface provided by the scheduler module. It is implemented in Python, and the part involving satellite orbit and motion simulation is implemented using the python-skyfield library; the data processing module is responsible for collecting the task operation data generated during the simulation process, and analyzing the data after the simulation is completed to help users verify the actual effect of the scheduling strategy.

[0019] The specific implementation method of the group management interface design of the group management module is as follows: first define the custom resource type PeerCluster, the structure of the PeerCluster resource contains the unique identifier of the group, the address of the group center node, the identifier and address of the working node in the group, and the status of the group, and the working node is recorded through the Satellite custom type.

[0020] The specific implementation method of the adjacent group registration mechanism designed by the group management interface of the group management module is as follows: after the user sets the satellite information of each group through skclient, the adjacent groups automatically discover and establish adjacent relationships through the satellite topology. First, the central node of each group calls the StartPeerDiscovery interface of skagent on each working node in the group. The StartPeerDiscovery interface function initiates a GetClusterSpec request to the four surrounding satellite nodes according to the satellite topology, and returns the aggregated 4 PeerCluster information to the central node; after the central node deduplicates the return results of each node according to ClusterId, the PeerCluster information of non-self-groups is added to k3s through the Create interface of CRD, and the PeerCluster resource controller automatically updates the status of the corresponding adjacent group, starts the adjacent group monitoring component, and starts sending heartbeats to the central node of the adjacent group.

[0021] The specific implementation of the adjacent group state management mechanism designed by the group management interface of the group management module is as follows:

[0022] When adjacent groups have completed mutual discovery, each group starts a PeerMonitor monitoring coroutine for each adjacent group to obtain the resource status and load forecast information of the adjacent group; at the same time, each group starts the MetricAggregator program at startup to aggregate the resource data within its own group; the PeerMonitor monitoring coroutine works in a way of pulling information, and regularly obtains the aggregated resource status information PeerMetric from the PeerCluster other than itself in the group; to ensure the real-time nature of the information, PeerMetric provides a separate external reading interface through the Kubernetes extended API mechanism;

[0023] The specific way of status interaction between groups is as follows: after the group enters the working state, MetricAggregator obtains the resource status of the current cluster and the load information provided by the load prediction module at a certain frequency, creates a PeerMetric object and inserts it into its own cache queue, and registers the APIServer resource to Kubernetes, exposing the GetPeerMetric interface for accessing the latest data; PeerMonitor obtains the PeerMetric structure of the adjacent group by polling the GetPeerMetric interface exposed by the adjacent cluster, and finally calls the Update interface to update the local CRD record.

[0024] The specific implementation of the delay-constrained satellite grouping management mechanism is as follows:

[0025] First, the communication delay between satellites in the low-orbit satellite constellation is modeled: for the case where each satellite only communicates with the two satellites in front and behind in the same orbit and the two satellites in the same position in the adjacent orbit, the communication delay between adjacent satellites can be divided into two types: the communication delay in the same orbit and the communication delay in the adjacent orbit. The communication delay of non-adjacent satellites can be obtained by linear combination of the above two delays.

[0026] Given M orbital planes and N satellites on each orbital plane, the satellite network is abstracted as an M*N grid, where M and N are natural numbers, and the points on the top and bottom and on the left and right sides of the grid are directly connected. For satellites on the same orbital plane, since their front and back positions are fixed, the distance D between two adjacent satellites is N for:

[0027]

[0028] where r E is the radius of the earth, h is the orbital height. Since the distance between satellites in adjacent orbits changes periodically with the orbital period T, within a given time t∈[0, T), the distance between two satellites in adjacent orbits is:

[0029]

[0030] Where i is the orbital inclination of the satellite. When t is 0, it is assumed that the satellite is in the equatorial plane. At this time, the distance between the two satellites is the farthest. By integrating and averaging the above formula, the average distance between adjacent orbital satellites can be obtained:

[0031]

[0032] Where E is the second kind of elliptic curve integral. Dividing the above distance by the speed of light in vacuum c, we can get the communication delay τ between adjacent satellites. M and τ N , since the constellation topology is like a two-dimensional grid, the coordinates (x, y) on the grid can be used to refer to the satellites in the constellation. It is easy to know that the communication delay τ between any two satellites (x1, y1) and (x2, y2) is the shortest number of hops between the two coordinates multiplied by the delay:

[0033] T=min(abs(x1-x2)%M, abs(x2-x1)%M)*τ M +min(abs(y1-y2)%N, abs(y2-y1)%N)*τ N

[0034] Then construct the delay constraint satellite grouping method: given the delay constraint T SLO , for any satellite s i , which is different from other satellites in the same group jThe communication delay must be within the constraints, that is, Under the condition of meeting the above constraints, the number of groups should be as small as possible to improve the overall resource utilization efficiency of the satellite;

[0035] Find a set of points R in the grid such that the distance between any point in the graph and exactly one point in R is less than or equal to d. Normalize the distance by adding virtual nodes, run the d-hop placement algorithm, and then scale the nodes proportionally. The result is such that the distance from each node to the nodes in the dominating set is less than or equal to d+∈, where ∈ is the error generated during the scaling and rounding process. The number of nodes in the dominating set is the number of groups. Finally, traverse all remaining nodes and assign each node to the group to which the dominating node closest to it belongs.

[0036] Then, a group computing resource balancing strategy is constructed: first, in the process of traversing each node, nodes that can join multiple clusters or cannot join any cluster are temporarily ignored; then, clusters are assigned to ungrouped nodes through the backtracking method to find the optimal solution under the current grouping situation; secondly, since the Torus grid is a ring topology, the determined dominant nodes are further translated on the overall grid, and the grouping is calculated separately for each situation. Since there are at most M*N situations, the global optimal solution is obtained directly through exhaustive enumeration.

[0037] The specific implementation method of the inter-group load balancing strategy based on geographic information is:

[0038] First, define the task parameters running on the low-orbit satellite computing platform. Each task consists of 1 to N Pods, and each Pod contains the required CPU and memory resources. Each task is accompanied by the satellite information to which it was initially submitted, recorded in the coordinates of the satellite in the constellation. Low-latency service tasks also contain the location information of ground users, recorded in longitude and latitude. Finally, each task also includes the time it was submitted to the computing platform.

[0039] Afterwards, the geographic information and ground load density information used in the scheduling strategy are modeled. Assuming that users directly access the satellite through ground terminals, the geographic division and traffic ratio change map data used are used as benchmark data. The earth's surface is divided into 72 regions in units of 30 degrees, and the longitude range is further divided in units of 15 degrees. The regions are aligned with time zones to form 144 regions, and the equipment density index is normalized to the task load ratio and mapped to the 144 regions; at the same time, the traffic ratio of each time period in the traffic ratio change map is converted into the relative ratio of each time period, and the corresponding time zone is multiplied with the load ratio in the regional division map to obtain the task load ratio zoning table for each time period;

[0040] Afterwards, based on the sub-satellite trajectory of the satellites in the group, the sampling method is used to model the change in the proportion of the ground low-latency service task load that each group may receive in the future. For each satellite s in a group S i , starting from the same time t0, the low-latency service mission load ratio within the next satellite orbit period T is r i1 , ..., r im , where m is the number of samples, r ij for Time Satellites i The latitude and longitude of the subsatellite point combined with the value obtained from the dictionary mentioned above in the time zone where the geographic coordinates are located, the load ratio R of the entire group S is the mean of the load ratio of each satellite in the group. The data is converted into a histogram by finding the interval mean, where the horizontal axis is the discretized time period, the vertical axis is the maximum value of the load ratio in the time period, and the interval length is used as the adjustment parameter. The smaller the parameter, the higher the frequency of the scheduler module to adjust the resource pool size, which is closer to the actual optimal load ratio, but also has a greater impact on the running tasks;

[0041] After that, a dynamic partitioning strategy for computing resource pools is constructed, which includes two parts: resource pool node sorting and resource pool capacity adjustment strategy:

[0042] The node sorting part of the resource pool uses a greedy algorithm to sort all nodes, so that the distribution of nodes in the resource pool is as uniform as possible during the expansion and contraction process; first, the nodes in the group are divided into two categories starting from the central node using breadth-first search, so that the two types of nodes are not adjacent to each other, and the distribution of each type of nodes is uniform; then, the strategy sorts the two types of nodes respectively, and the idea of ​​sorting is: find the unsorted node whose sum of distances to all sorted nodes is closest to the mean, and add it to the sorted nodes; finally, the order of the two types of nodes is spliced ​​to get the final node order;

[0043] The resource pool capacity adjustment strategy is specifically as follows: after completing the node sequencing, the scheduler module performs resource pool expansion or contraction operations according to the load prediction information. The expansion operation includes tagging nodes and expelling geographically irrelevant tasks that are running, while the contraction operation only removes node labels. When the system's monitoring module detects that the low-latency service resource pool is insufficient, or the scheduler module determines that expansion is required based on the above load prediction information, the scheduler module executes resource pool expansion, and adds labels to the nodes in order according to the node index at the end of the current resource pool until the required number of resources for expansion is reached. The scheduler module checks all running geographical For irrelevant tasks, if the node where the task is running is already in the new resource pool, the task will be marked as "to be migrated", but the task will be evicted and rescheduled only when the scheduler module chooses to schedule a new low-latency service task to the node and finds that the resources are insufficient; when the system monitoring module finds that the resources occupied by the tasks in the resource pool are lower than the threshold, and combines the load forecast information to determine that the capacity needs to be reduced, the scheduler executes the resource pool reduction. At this time, the scheduler removes the node labels in reverse order starting from the last node in the resource pool, and the scheduler can reschedule geographically irrelevant tasks to these nodes; the scheduler module does not actively evict tasks that are still running, but waits for them to migrate to other nodes by themselves;

[0044] Finally, a task load balancing strategy between groups is constructed: load balancing is achieved by scheduling geographically independent tasks between groups. When a task is submitted to a satellite group, the resource scheduler of the group selects itself and adjacent groups as candidate groups, and obtains the remaining resource data of all candidate groups and the load forecast data for the next orbital period through local cache or communication with adjacent groups; based on these data, the resource scheduler scores all candidate groups, and the scoring formula is: W1*whether the task can be executed directly+W2*the number of remaining resources+W3*the time until the next resource pool expansion+W4*whether the task is located in the current group; the resource scheduler submits the task to the group with the highest score based on the scoring result, and increases the number of schedulings attached to the task by one; if the group with the highest score is the group where the current task is located, the resource scheduler directly submits the task to the queue of tasks to be scheduled of the local group; if the task has reached the maximum number of schedulings, the last scheduled task will be directly submitted to the queue of tasks to be scheduled of the corresponding group.

[0045] The specific method of designing the task interface in the task scheduling module is as follows: two tasks are defined in the form of CRD: the geographical location-independent task ComputeJob and the low-latency service task LowLatencyService. The two tasks are basically consistent in fields such as Pod description, submission time, and submission location, but ComputeJob contains the number of rescheduling times and the final execution group identification information, while LowLatencyService contains the migration process identification; users can submit or stop tasks to the system through the interface provided by skclient. After the task arrives at skagent, only the InitialSatelliteId is modified, and then it is directly submitted to the k3s central node through the Create interface provided by CRD.

[0046] The specific method of resource pool management in the task scheduling module is as follows: first, define the ResourcePool custom resource, and then build the workflow of the ResourcePool controller. When creating a group, each group creates a ResourcePool resource in its own k3s cluster; after the controller corresponding to the resource is started, first request the MetricAggregator to obtain the current cluster resource information; then the controller sorts all working nodes according to the node sorting strategy defined by SortPolicy, and the sorting strategy includes the homogenization strategy, sorting by satellite number order, sorting by resource capacity and other strategies; after the sorting is completed, the controller starts the LoadWatcher coroutine to update the NextAdjustment field, including time and resource pool target size, according to the prediction information provided by the load prediction module, and starts the node labeling coroutine NodeLabeler; the labeling process is to update the working node label in turn through the Update method of Kubernetes according to the CurrentPoolSize and CurrentLastNode information in ResourcePool and the resource pool target size in NextAdjustment according to the node identifier in NodeOrder; after updating the NextAdjustment field, the LoadWatcher coroutine regularly collects cluster resource status information and updates it to the load prediction module.

[0047] The specific method of implementing task scheduling in the task scheduling module is: using the customized ComputeJob controller, LowLatencyService controller extension framework and Kubernetes controller extension framework to implement mixed scheduling of two tasks:

[0048] The ComputeJob controller implements the scheduling of geographically independent tasks and cross-group load balancing functions; when a user submits a ComputeJob object through skclient, the state of the object is first marked as INCOMING, and the controller submits the task object in INCOMING state to the initial scheduling queue IncomingQueue inside the controller, which is implemented using the workqueue library provided by Kubernetes; at the same time, the load balancing coroutine in the ComputeJob controller will take out the task object to be scheduled from the queue, and the load balancing strategy will select the group to execute; if the task needs to be scheduled to other groups, the ComputeJob controller calls the Update method in PeerCluster to submit the task to other groups and delete the tasks in this group; if the task needs to be executed in this group, the ComputeJob controller modifies the task status to PENDING; the task scheduling coroutine in the ComputeJob controller continuously polls all tasks in PENDING state, and submits the unsubmitted Pods to the k3s cluster through Create, waiting for scheduling by the central scheduler; when all Pods in the task are started, the controller modifies the task status to RUNNING, and until all Pods are completed, the status is modified to FINISHED;

[0049] The LowLatencyService controller is mainly responsible for scheduling low-latency service tasks according to the scheduling path information provided by the migration management module; after the user submits the low-latency service, the object state is first marked as INCOMING state, and the controller will create a corresponding MigrationProcess object for the task object in this state, and then mark it as PENDING state; at this time, the LowLatencyService controller only needs to wait for the MigrationProcess controller to submit the Pod to the central scheduler, and mark the corresponding task object as SERVING, indicating that the task Pod is being scheduled in the cluster;

[0050] The LowLatencyService controller continuously polls the task object in the SERVING state until its state changes to FINISHED and then deletes the running Pod and MigrationProcess objects;

[0051] The extension framework of the Kubernetes controller extends the central scheduler so that it can distinguish Pods belonging to different task types and adopt corresponding scheduling strategies; in the QueueSort stage, the extension framework of the Kubernetes controller enables the scheduler to distinguish the two types of tasks according to the labels in the Pod, and arrange the Pods of low-latency service tasks in front to ensure that the user QoS is not affected; in the Filter stage, the extension framework of the Kubernetes controller enables the scheduler to select nodes in different resource pools for the two types of Pods; for low-latency service tasks, if no suitable nodes are selected in the Filter stage, the extension framework of the Kubernetes controller enables the scheduler to try to evict some geographically irrelevant task Pods to release resources in the PostFilter stage, and notify the resource pool management module to record load conflict information; in the Score stage, the extension framework of the Kubernetes controller enables the scheduler to rank and score the nodes for low-latency service task Pods according to the access satellite information provided by MigrationProcess using the strategy in the previous chapter.

[0052] The interface design in the low-latency service migration management module is specifically as follows:

[0053] Define the MigrationProcess custom resource. PrevProcess and NextProcess point to the MigrationProcess object corresponding to the task in other groups. The Path field contains a list of PathNodes. Each PathNode represents a node on the path, including the user's access satellite ID, service start and end time, optimal satellite and alternative satellite set, and the current state of the node. Since only some of the nodes on the migration path are located in the group, the PathNode information corresponding to the current group also needs to be recorded.

[0054] When the user submits a low-latency service task, the LowLatencyService object automatically creates the first MigrationProcess object; then the MigrationProcess controller uses the ephemeris calculation module to calculate the communication interval for a period of time in the future based on the user's location, and creates a Path based on the path selection algorithm; when it is determined that the first PathNode in the Path points to its own group, the controller will modify the state of the task object and submit the Pod to the scheduler based on the Pod description information of the task object; when the end time specified by the PathNode is reached, the controller will clean up the Pod corresponding to the previous PathNode and schedule a new Pod based on the new PathNode; when the number of nodes in the Path is less than the threshold, the controller will continue to calculate and update the new migration path.

[0055] The service preheating mechanism in the low-latency service migration management module is specifically as follows: the concept of service preheating window is introduced, and four PathNode states: service state, preheating state, environment preparation state and waiting state; the PathNode at the head of the preheating window is in service state, and the satellite corresponding to the node is providing services to users; the PathNode immediately following it is in preheating state, and the satellite corresponding to the node needs to pre-start the Pod of the corresponding service, waiting for the user to directly access after migration; the other PathNodes in the window are in environment preparation state, and the satellites corresponding to these nodes need to create MigrationProcess objects in advance and prepare the environment required to start the Pod, such as pulling container images; the PathNodes outside the window are in waiting state, and the satellites corresponding to these nodes do not need to perform any operations temporarily; when the PathNode in the service state of the window reaches the service deadline, the entire service preheating window moves back one node, and the MigrationProcess controller corresponding to the PathNode that has just ended will send window updates to the controllers of the group where the PathNode is located in the subsequent window in a chained manner; after receiving the update information, the controller to which the PathNode at the end of the previous window belongs needs to create a MigrationProcess object in the corresponding group according to the new end PathNode information to complete the window backward movement.

[0056] The method for constructing the cross-packet service migration mechanism in the low-latency service migration management module is specifically as follows:

[0057] Through the cooperation of MigrationProcess controllers between groups, tasks can be smoothly migrated between groups;

[0058] When the satellite corresponding to the PathNode at the end of the window does not belong to the current group, the MigrationProcess controller needs to create a new MigrationProcess object in the corresponding group through the Create interface, and update the NextProcess and PrevProcess fields of itself and the new object; at the same time, the MigrationProcess controller sends its own Path information to NextProcess through the Update interface; if the newly created MigrationProcess object finds that there is no corresponding LowLatencyService object in the group, it will create an additional object and adjust its status;

[0059] If the Pod in the preheating phase cannot be started due to insufficient resources and other issues, and a satellite needs to be selected outside the optimal service satellite set, the controller needs to regenerate the migration path. At this time, the MigrationProcess controller needs to first send the new Path information to the PrevProcess, and then chain update information backwards based on the newly generated subsequent PathNode, thereby updating the entire migration path.

[0060] In the low-latency service migration management module: the construction method of the satellite network low-latency service migration mechanism is specifically: including two modules of low-latency service migration path selection and migration path-aware task scheduling strategy;

[0061] The low-latency service migration path selection uses QoS constraints to limit the delay between the user accessing the satellite and the satellite providing the service, thereby reducing the service migration frequency while ensuring the service quality;

[0062] Given a user's location (lat u ,lon u ), in the future period T starting from the time t0 when the user submits the task, the set of satellites and their communication intervals that enter the user's communication range within [t0, t0+T) are calculated by the SGP4 orbit model; first, the satellite with the longest communication time at the user's current moment is selected as the access satellite, so that the access satellite sequence [(s1), (s2), ..., (s n )], where for each access satellite, a corresponding set of candidate service satellite sets S can be obtained according to the QoS constraints, thereby obtaining a candidate service satellite set sequence [S1, S2, ...S n ]; Select a satellite from each set to form a service migration path [(x1), (x2), ..., (x n )], if the adjacent elements in the sequence are the same, it means that the satellite provides services continuously and does not need to be migrated, so the adjacent and identical elements can be merged into one; at this time, the problem can be transformed into: select a service migration path so that the number of satellites contained in the path is as small as possible;

[0063] Use dynamic programming to solve this problem. First, give the definition of the state. Define dp[i][j] as the number of states in the first i sets with x. j is the minimum number of subsequences after deduplication in the ending sequence. For a new set Si, for each number x in it p , add the number to the current sequence; for number x p If it only occurs once, just replace the number x pAdd to the current sequence and update dp[i][p] = dp[i-1][j] + 1, where j represents the number of ps in the first i-1 sets with x. j is the sequence ending with; for the number x p If the number x has already appeared in the current sequence, there is no need to p To add to the current sequence, we only need to update dp[i][p] = dp[i-1][j], which means the number of independent numbers in the sequence remains unchanged;

[0064] The final answer is dp[n][j], where n represents the number of sets. We look for the minimum value in dp[n][j] by maintaining a pre array to record the predecessor state of each state. Finally, we trace back from dp[n][j] to obtain a sequence that meets the conditions.

[0065] The migration path-aware task scheduling strategy converts the user's communication interval information into a directed acyclic graph, in which each node represents a satellite, including the start and end time of the user's communication with the satellite, and the weight on the node represents the time the user stays after migrating from other satellites to the satellite. The satellite is divided into multiple stages according to the start and end time of the service in the figure. The end time of satellite communication in each stage is strictly greater than the previous stage. The satellites in the stage are sorted according to the service deadline. The satellite with the latest deadline is on the optimal path. To return to the optimal path from satellites on other suboptimal migration paths, an additional migration is required within the stage. In addition, since the distance between satellites in the same stage is also relatively close, the service satellite sets that meet the QoS requirements also have intersections. Therefore, all service satellite sets in each stage can be divided into multiple non-overlapping subsets, corresponding to different satellites in the stage.

[0066] The overall architecture of the scheduling strategy simulator consists of a task generation module, an ephemeris management module, a simulation module, a scheduler module and a data processing module;

[0067] The task generation module is mainly responsible for generating task loads within a period of time according to the task generation configuration provided by the user, and mapping them to the corresponding satellites; the ephemeris management module is responsible for providing satellite-related information, including the communication range with the ground position, visible satellites, etc.; the simulation module is the core of the entire simulator, consisting of a simulation process controller and multiple satellite grouping objects. The controller drives the overall simulation process, and the satellite grouping objects are mainly responsible for simulating the grouping status, including the status of tasks within the group, adjacent groups, and satellites within the group; the scheduler module implements various scheduling strategies, and the satellite cluster process completes the simulation of task scheduling by calling the interface provided by the scheduler module; the data processing module is responsible for collecting the task operation data generated during the simulation process, and analyzing the data after the simulation is completed to help users verify the actual effect of the scheduling strategy.

[0068] The implementation method of the task generation module of the scheduling strategy simulator is as follows: first, tasks are generated according to the configuration file input by the user. Since the number of task loads in each geographically divided area is different, the process of generating tasks is carried out one by one according to the geographically divided areas; the arrival time of each task is generated using the idea of ​​random sampling. First, according to the normalized load location and time distribution information, multiplying by the total number of daily tasks can obtain the number of tasks per hour in each area, and the average arrival interval of the tasks in the hour is obtained based on the number. Since the arrival time of the task obeys the Poisson distribution, the intervals between the arrivals of adjacent tasks obey the exponential distribution with λ as the parameter, where λ means the frequency of task arrival, then the value of the average arrival interval is 1 / λ. According to the idea of ​​random sampling, the average arrival interval of the task is used to generate a set of random variables that obey the exponential distribution. This method is used to generate the arrival interval of each task in each hour, thereby determining the arrival time of the task.

[0069] The simulation process of the scheduling strategy simulator is implemented as follows:

[0070] The whole simulation process is divided into three stages: environment preparation stage, simulation stage and data processing stage;

[0071] The environment preparation stage first generates task load and satellite constellation information. The satellite constellation information generation is to generate a corresponding number of satellite objects and available resources for each satellite according to the user configuration, and to group the satellites in advance according to the grouping strategy to create multiple satellite grouping objects; secondly, since the task first reaches the central node of each group when it is submitted, each task is assigned to a different grouping object according to its submission time and location in this stage, and the task-group mapping is cached. When the subsequent simulation uses the same task load set and satellite configuration, this step is directly skipped; finally, according to the geographical location and time information in the task set, the satellite communication interval information required for each low-latency service task is generated and cached in a file. The simulator loads the file into memory and searches it at runtime to reduce the amount of calculation;

[0072] The simulation stage adopts an event simulation mode, and puts the events that may occur in the scheduler into a priority queue sorted by time. After the simulation starts, the controller takes out the earliest event from the head of the queue in turn, steps the simulator time, and calls the processing function of the event. During the event processing process, if a new event is generated, the new event will be reinserted into the priority queue by the controller;

[0073] Events in the simulator are divided into two categories: task simulation events and statistical data events. Task simulation events are mainly responsible for simulating the task execution process. Statistical data events are responsible for counting cluster load and task execution status, including:

[0074] JobSubmit: indicates that the task is submitted to the cluster. After the task is submitted, the controller sends the task to the scheduling module. For geographically independent computing tasks, the scheduling module selects a group according to the inter-group scheduling strategy, and then the scheduler in the group schedules the Pod in the task. If the Pod is successfully started at this time, a PodFinish event is generated and inserted into the event queue. If it is not started, it is inserted into the cluster's task waiting queue. For low-latency service tasks, the controller sends the task to the service migration management module and generates a migration path, and sends the Pod to the scheduler in the group for scheduling, and finally generates a ServiceFinish event and inserts it into the event queue;

[0075] PodFinish: indicates that the Pod execution is finished. When the Pod execution is finished, the occupied computing resources need to be released and the execution status of the corresponding task needs to be modified.

[0076] ServiceFinish: indicates that the low-latency service execution is finished, all running Pods and preheated Pods corresponding to the service are cleaned up, and service execution information is counted;

[0077] ServiceMigrate: indicates low-latency service migration. This event is generated by the service migration module when a task is submitted. The service migration module needs to submit the Pod to the scheduler of the corresponding group according to the next service satellite indicated by the event, and close the Pod that has completed the previous service.

[0078] ResourcePoolUpdate: indicates updating the resource pool in the cluster. For the scheduling strategy, the resource pool division in the group needs to be updated in time according to the location of the satellite;

[0079] UserAccessChange: indicates that the user access satellite has changed. For each low-latency service, the controller generates a series of user access change events. When processing the event, the system will count the delay between the event and the user access service during the last switching process.

[0080] StatsSample: indicates the collection of cluster load status. When the system starts, it will generate this event in batches according to the interval requirements. It is used to collect cluster load information during the simulation process.

[0081] After the simulation is completed, the scheduling strategy simulator generates multiple statistical data record files. The work of the data processing stage is to integrate these data into the overall execution status of the task.

[0082] The innovation of the embodiment of the present invention lies in:

[0083] The present invention solves the problem of adapting the resource scheduling system to satellite networks with wide geographical distribution and highly dynamic time-varying characteristics. Based on the Kubernetes platform extension, a solution for efficient resource management and adaptability to satellite scenarios is implemented, and deployed on a satellite computing simulation platform composed of multiple lightweight virtual machines, simulating intersatellite networks through external network traffic control. Users can observe the status of load balancing and service migration by submitting tasks to the prototype platform. BRIEF DESCRIPTION OF THE DRAWINGS

[0084] The above and other objects and features of the present disclosure will become more apparent from the following description in conjunction with the accompanying drawings.

[0085] Figure 1 is a schematic diagram showing an architecture diagram of a satellite group management system for a satellite cloud computing Internet platform according to an embodiment of the present disclosure;

[0086] Figure 2 is a schematic diagram showing a PeerCluster description file according to an embodiment of the present disclosure;

[0087] Figure 3 is a schematic diagram showing a process of establishing an adjacency relationship according to an embodiment of the present disclosure;

[0088] Figure 4 is a schematic diagram showing a neighbor group state update process according to an embodiment of the present disclosure;

[0089] Figure 5 is a schematic diagram showing a workflow diagram of a resource pool controller according to an embodiment of the present disclosure;

[0090] Figure 6 is a schematic diagram showing the overall architecture of a scheduling strategy simulator according to an embodiment of the present disclosure;

[0091] Figure 7 It is a schematic diagram showing stages of a simulation process according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0092] The following specific embodiments are provided to help the reader obtain a comprehensive understanding of the methods, devices and / or systems described herein. However, after understanding the disclosure of the present application, various changes, modifications and equivalents of the methods, devices and / or systems described herein will be clear. For example, the order of operations described herein is only an example and is not limited to those orders set forth herein, but can be changed as will be clear after understanding the disclosure of the present application, except for operations that must occur in a specific order. In addition, for greater clarity and simplicity, the description of features known in the art may be omitted.

[0093] The features described herein can be implemented in different forms and should not be construed as being limited to the examples described herein. Rather, the examples described herein have been provided to illustrate only some of the many possible ways to implement the methods, devices, and / or systems described herein, which will be clear after understanding the disclosure of the present application.

[0094] As used herein, the term "and / or" includes any one of the associated listed items and any combination of any two or more.

[0095] Although terms such as "first", "second", and "third" may be used herein to describe various members, components, regions, layers, or portions, these members, components, regions, layers, or portions should not be limited by these terms. Instead, these terms are only used to distinguish one member, component, region, layer, or portion from another member, component, region, layer, or portion. Therefore, without departing from the teachings of the examples described herein, the first member, first component, first region, first layer, or first portion referred to in the examples may also be referred to as the second member, second component, second region, second layer, or second portion.

[0096] In the specification, when an element (such as a layer, a region or a substrate) is described as being “on”, “connected to” or “coupled to” another element, the element may be directly “on”, “connected to” or “coupled to” another element, or one or more other elements may be present therebetween. Conversely, when an element is described as being “directly on”, “directly connected to” or “directly coupled to” another element, there may be no other elements present therebetween.

[0097] The terms used herein are only used to describe various examples and are not intended to limit the disclosure. Unless the context clearly indicates otherwise, the singular form is also intended to include the plural form. The terms "comprise", "include" and "have" indicate the presence of the described features, quantities, operations, components, elements and / or combinations thereof, but do not exclude the presence or addition of one or more other features, quantities, operations, components, elements and / or combinations thereof.

[0098] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as those generally understood by a person of ordinary skill in the art to which the present disclosure belongs after understanding the present disclosure. Unless explicitly defined as such herein, terms (such as those defined in a general dictionary) should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and the present disclosure, and should not be interpreted in an idealized or overly formal manner.

[0099] Furthermore, in the description of examples, when it is considered that a detailed description of a well-known related structure or function would cause vague interpretation of the present disclosure, such a detailed description will be omitted.

[0100] Figure 1 It is a schematic diagram showing a satellite group management system for a satellite cloud computing Internet platform according to an embodiment of the present disclosure.

[0101] Overall architecture:

[0102] The satellite Internet cloud computing resource scheduling system prototype designed and implemented by the present invention is developed based on Kubernetes, the most popular resource management framework in the current cloud native field. Based on the group scheduling architecture proposed by the present invention, resources are managed by a centralized scheduler in each group, so the system can make full use of existing resource management implementations in Kubernetes, such as Pod and container management, worker node management, and scheduler framework. At the same time, based on the custom resource and controller mechanism of Kubernetes, the satellite system abstraction and various strategies designed by the present invention can be easily introduced. Taking into account the limited satellite resources, the present invention develops a Kubernetes distribution k3s optimized for edge computing. The overall architecture of the system is as follows: Figure 1 shown.

[0103] The satellite cloud computing resource management system implemented by the present invention includes three main modules: a group management module, a task scheduling module and a low-latency service migration management module. The above three modules all run on the management node k3s master of k3s. The group management module is mainly responsible for managing the relationship between adjacent groups (Peer) and collecting the resource status of adjacent groups. The task scheduling module is responsible for monitoring the tasks submitted by users, allocating computing resources to tasks or scheduling them to other groups according to the scheduling strategy, and the module is also responsible for the management of the resource pool. The low-latency service migration management module is mainly responsible for calculating the optimal migration path according to the user's position, and managing the migration status of services within and between groups. In addition, the system also includes an ephemeris calculation module that provides satellite information for each module, a client skclient running on the client terminal, and a skagent running on the working node satellite. The ephemeris management module also runs on the k3s management node, is responsible for providing the user communication interval information required by the scheduling algorithm, and maintains the current satellite position information of the group. skclient accesses the API provided by the system through the remote procedure call framework gRPC, which is used to manage satellite grouping, submit tasks, etc.; since the satellites that users actually communicate with are most likely working nodes, user access mainly reaches skagent running on the working nodes, and skagent is responsible for forwarding user requests to the corresponding modules of the central node.

[0104] Group management module:

[0105] The group management module is the basis for the entire system to implement group management. Its functions mainly include the following parts: 1) Providing group control functions for users, including finding or updating the nodes and other adjacent group information managed by the current group; 2) Providing adjacent group registration function, through which other groups register as adjacent groups of this group; 3) Providing adjacent group status management function for the scheduler, including collecting resource information of nodes in the current group, sending heartbeats to other groups, and collecting resource information of other groups.

[0106] (1) Group management interface design:

[0107] The group management module first defines the custom resource type (CRD) of PeerCluster. Since each group has the same status in the system, the information of the local group can also be recorded through this type. The structure description of the PeerCluster resource is shown in Table 1, which includes the unique identifier of the group, the address of the group center node, the identifier and address of the working node in the group, and the status of the group. The working node is recorded through the Satellite custom type, as shown in Table 2.

[0108] Table 1 PeerCluster resource description

[0109]

[0110] Table 2 Satellite resource description

[0111]

[0112] Based on the CRD mechanism provided by Kubernetes, users can directly add, delete, modify and query resource types through kubectl commands or client libraries, and the controller of the corresponding resource performs corresponding operations by monitoring changes in resource information. To facilitate user operations, skclient encapsulates the interface for adding, deleting, modifying and querying PeerCluster resources. Users only need to provide the description file information of the satellite group, and skclient can modify the resources by accessing the resource interface of PeerCluster.

[0113] (2) Adjacent Group Registration Mechanism:

[0114] After the user sets the satellite information of each group through skclient, the adjacent groups can automatically discover and establish adjacency through the satellite topology. The specific process is as follows: Figure 3As shown. First, the central node of each group calls the StartPeerDiscovery interface of skagent on each working node in the group. This interface function initiates a GetClusterSpec request to the four surrounding satellite nodes according to the satellite topology, and returns the aggregated 4 PeerCluster information to the central node. After the central node deduplicates the return results of each node according to the ClusterId, it adds the PeerCluster information of non-self-groups to k3s through the Create interface of CRD. At this time, the PeerCluster resource controller will automatically update the status of the corresponding adjacent group, start the adjacent group monitoring component, and start sending heartbeats to the central node of the adjacent group.

[0115] (3) Adjacency Group State Management Mechanism:

[0116] When adjacent groups complete mutual discovery, each group will start a PeerMonitor monitoring coroutine for each adjacent group to obtain the resource status and load forecast information of the adjacent group. At the same time, each group will also start the MetricAggregator program when it starts to aggregate the resource data within its own group. The PeerMonitor monitoring coroutine works by pulling information, and regularly obtains the aggregated resource status information PeerMetric from the PeerCluster other than itself in the group. To ensure the real-time nature of the information, although PeerMetric is also a CRD, a separate external reading interface is provided through the Kubernetes extended API mechanism. The specific definition is shown in Table 3.

[0117] In the above information, nodeMetric is similar to PeerMetric in definition, including four {uint64,uint64} structures, corresponding to total available, in use, Pod request resources and Pod resource limits. The two uint64 values ​​represent the CPU and memory resources, where CPU is in milli-CPU units and memory is in KB. loadHistogramItem contains time and load ratio data.

[0118] Table 3 PeerMetric structure description

[0119]

[0120] The specific way of state interaction between groups is as follows Figure 4As shown. After the group enters the working state, MetricAggregator obtains the resource status of the current cluster and the load information provided by the load prediction module at a certain frequency, creates a PeerMetric object and inserts it into its own cache queue, and registers the APIServer resource with Kubernetes, exposing the GetPeerMetric interface for accessing the latest data. PeerMonitor obtains the PeerMetric structure of the adjacent group by polling the GetPeerMetric interface exposed by the adjacent cluster, and finally calls the Update interface to update the local CRD record.

[0121] (4) Delay-constrained satellite grouping management mechanism:

[0122] Satellite networks are different from any existing scenarios on the ground in terms of geographical distribution and hardware environment: compared with the cloud environment, satellites are widely distributed geographically, the average delay between any nodes is larger, and the node performance is weaker and heterogeneous; compared with the edge environment and the wide area environment, the network topology between satellites is relatively stable, and bandwidth resources are relatively sufficient. In this scenario, it is impossible to use a centralized architecture to organize all nodes, because the delay difference between satellites is too large, and the hybrid architecture cannot be applied. The present invention intends to implement a satellite group management mechanism, which utilizes the delay constraints of inter-satellite communications and collaboratively considers resource distribution factors to divide the satellite network into multiple groups, thereby realizing centralized scheduling within the group and collaborative resource scheduling between groups.

[0123] Satellite Communications Delay Modeling

[0124] The application of the delay-constrained grouping method first requires modeling the communication delay between satellites in the low-orbit satellite constellation. Considering the assumptions of the present invention on the satellite constellation, each satellite only communicates with the two satellites in front and behind in the same orbit and the two satellites in the same position in the adjacent orbit. The communication delay between adjacent satellites can be divided into two types: the communication delay in the same orbit and the communication delay in the adjacent orbit. The communication delay of non-adjacent satellites can be obtained by linear combination of the above two delays.

[0125] Given M orbital planes and N satellites on each orbital plane, the satellite network can be abstracted as an M*N grid, with the points on the top and bottom and on the left and right sides of the grid directly connected. The ideal delay for inter-satellite communication can be obtained by calculating the distance between satellites. For satellites on the same orbital plane, since their front and back positions are fixed, the distance between two adjacent satellites is:

[0126]

[0127] where r Eis the radius of the earth, and h is the orbital height. Since the distance between satellites in adjacent orbits changes periodically with the orbital period T, within a given time t∈[0, T), the distance between two satellites in adjacent orbits is:

[0128]

[0129] Where i is the satellite's orbital inclination. When t is 0, it is assumed that the satellite is in the equatorial plane, at which time the distance between the two satellites is the farthest. By integrating and averaging the above formula, the average distance between adjacent orbital satellites can be obtained:

[0130]

[0131] Where E is the second kind of elliptic curve integral. Dividing the above distance by the speed of light in vacuum c, we can get the communication delay τ between adjacent satellites. M and τ N Since the constellation topology is shaped like a two-dimensional grid, the coordinates (x, y) on the grid can be used to refer to the satellites in the constellation. It is easy to know that the communication delay between any two satellites (x1, y1) and (x2, y2) is the shortest number of hops between the two coordinates multiplied by the delay:

[0132] τ=min(abs(x1-x2)%M, abs(X2-x1)%M)*τ M +min(abs(y1-y2)%N, abs(y2-y1)%N)*τ N

[0133] Delay Constrained Satellite Grouping Method

[0134] Given a delay constraint τ SLO The goal of the present invention is to i , which is different from other satellites in the same group j The communication delay must be within the constraints, that is, At the same time, under the condition of meeting the above constraints, the number of groups should be as small as possible to improve the overall resource utilization efficiency of the satellite.

[0135] The above problem can be converted into the d-hop dominating set problem in the Torus network, that is, to find a set of points R in the grid so that the distance (number of hops) between any point in the graph and exactly one point in R is less than or equal to d. As long as n nodes can be found in the grid with d hops as the constraint to form a dominating set, and the remaining nodes are added with each of the points in this group as the center, n groups can be obtained, and the communication delay between any two satellites in the group is less than 2d. Due to the different co-orbit and cross-orbit communication times in the satellite network, the present invention normalizes the distance by adding virtual nodes, runs the d-hop placement algorithm, and then scales the nodes proportionally. The result generated satisfies that the distance from each node to the dominating set node is less than or equal to d+∈, where ∈ is the error generated during the scaling and rounding process. The number of nodes in the dominating set is the number of groups. Finally, by traversing all the remaining nodes, each node is classified into the group to which the dominating node closest to it belongs.

[0136] Group computing resource balancing strategy

[0137] The above grouping method can ensure the delay constraint within the group, but it does not take into account the heterogeneous characteristics of satellite resources. Specifically, the computing power of each satellite can be abstracted into two resources [cpu, mem]. For K groups, the resource tilt index Φ = Var(∑cpu(S i ))+Var(∑mem(S i )) is the sum of the variances of the sum of resources in each group, and this index needs to be minimized so that each group of resources is as evenly distributed as possible. The present invention adopts two strategies to further achieve resource balancing. First, in the process of traversing each node, nodes that can join multiple clusters or cannot join any cluster are temporarily ignored (line 29); then, clusters can be assigned to ungrouped nodes by backtracking (lines 1-21), thereby finding the optimal solution for the current grouping. Secondly, since the Torus grid is a ring topology, the determined dominant nodes can be further translated on the overall grid, and the grouping can be calculated separately for each case. Since there are at most M*N cases, the global optimal solution can be obtained directly by exhaustive enumeration (lines 26-39). The pseudocode of the algorithm is as follows:

[0138] Table 3 Pseudo code of resource balancing grouping algorithm

[0139]

[0140] (5) Load balancing strategy between groups based on geographic information:

[0141] The main service scenarios of the satellite computing platform include two categories. The low-latency service load requires the user access delay to be as low as possible, and the service users are mostly concentrated in land areas; the geographically independent computing task load is insensitive to delay and geographical location. Considering that satellites are evenly distributed around the earth and move at high speed, in the scenario of satellite grouping, the uneven task submission locations may lead to unbalanced loads between groups, and satellite computing resources cannot be fully utilized. In addition, the contention for resources between the two types of tasks may also lead to user service degradation. Therefore, the present invention utilizes the predictability of satellite motion trajectories, combines geographic location information and load prediction information to dynamically adjust the resource allocation within each group, and proposes a task load balancing strategy between groups to improve computing resource utilization without affecting the low-latency service QoS.

[0142] First, the present invention defines in detail the task parameters running on the low-orbit satellite computing platform. As shown in Table 4, each task is composed of 1 to N Pods, and each Pod contains the required CPU and memory resources. In addition, since the task needs to be submitted to the low-orbit satellite computing platform from the ground or other satellites, each task is accompanied by the satellite information to which it was initially submitted, recorded in the coordinates of the satellite in the constellation. Low-latency service tasks also include the location information of ground users, recorded in longitude and latitude. Finally, each task also includes the time of submission to the computing platform.

[0143] Table 4 Task load modeling parameters

[0144]

[0145] The geographic information and ground load density information applied to the scheduling strategy are modeled. Assuming that the user directly accesses the satellite through the ground terminal, the load density of users in different ground areas depends on factors such as population density and economic conditions. Considering that the initial value of the regional division and load itself does not affect the algorithm flow, and can be corrected as the system runs, the present invention uses the geographical division and the flow ratio change diagram data as the reference data, and divides the earth's surface into 72 regions in units of 30 degrees. The present invention further divides the longitude range into units of 15 degrees, and aligns the region with the time zone to form 144 regions, and normalizes the equipment density index to the task load ratio and maps it to the 144 regions. At the same time, the present invention converts the proportion of traffic in each period of the flow ratio change diagram to the relative proportion of each time period, and multiplies the corresponding time zone with the load ratio in the regional division diagram to obtain the task load ratio zoning table for the time period. Since the table only contains 144*24=3456 data, the entire table can be directly stored in a dictionary with (longitude subscript, latitude subscript, UTC time) as the key.

[0146] After the above information is abstracted, the present invention uses a sampling method to model the change in the proportion of ground low-latency service task load that each group may receive in the future based on the sub-satellite point trajectory of the satellites in the group. Specifically, for each satellite s in a group S i , starting from the same time t0, the low-latency service mission load ratio within the next satellite orbit period T is r i1 , ..., r im , where m is the number of samples, r ij for Time Satellites i The latitude and longitude of the subsatellite point combined with the value obtained from the dictionary mentioned above in the time zone where the geographic coordinates are located. The load ratio of the entire group R S is the mean of the load ratio of each satellite in the group. Based on the above method, the time-varying trend data of the low-latency service task ratio of each group can be obtained. In order to facilitate the scheduler to make decisions based on the data, the present invention converts the data into a histogram by calculating the interval mean, where the horizontal axis is the discretized time period and the vertical axis is the maximum value of the load ratio in the time period. In addition, the interval length is an adjustable parameter. The smaller the parameter, the higher the frequency of the scheduler adjusting the resource pool size, which is closer to the actual optimal load ratio, but the impact on the running tasks is also greater.

[0147] Computing resource pool dynamic partitioning strategy

[0148] Based on the above load ratio information, a commonly used resource management strategy is to divide resource pools for different task types. The two types of tasks use the resources of their own resource pools respectively. When the load ratio has changed or is about to change, the sizes of the two resource pools are dynamically adjusted. According to the load information modeled in the previous article, it can be seen that the low-latency service load in the satellite network can be divided into an ascending stage and a descending stage in terms of the change trend, which correspond to the expansion stage and the contraction stage of the low-latency service resource pool respectively. In the expansion stage, some nodes belonging to the geographically irrelevant task resource pool need to be moved to the low-latency service resource pool, and vice versa in the contraction stage. Since there are only two resource pools, a tag is used to determine whether a node belongs to the low-latency service resource pool to distinguish between the two nodes. The expansion process of the resource pool is to add labels to the nodes in the group in a certain order, and the contraction process is to remove the labels in the opposite order. Based on the above conditions, the present invention proposes a dynamic partitioning strategy for computing resource pools for satellite network topology, which includes two parts: resource pool node sorting and resource pool capacity adjustment strategy.

[0149] Considering that in the ground scenario, since the nodes are located in a centralized data center, resources can be arbitrarily divided into different resource pools, and there is no need to consider the location issues between the nodes. In the satellite scenario, since the satellite network is distributed in a grid shape, and there is a correlation between the satellite position and the user access position, it is necessary to ensure that the satellites in the low-latency service task resource pool should be distributed as evenly as possible in the entire grid. Therefore, the present invention adopts a greedy algorithm to sequence all nodes so that the nodes in the resource pool are distributed as evenly as possible during the expansion and contraction process. The pseudo code of the algorithm is shown in Table 5.

[0150] Table 5 Node sequencing strategy pseudo code

[0151]

[0152]

[0153] The strategy first uses breadth-first search to divide the nodes in the group into two categories starting from the central node (lines 1-20), so that the two types of nodes are not adjacent to each other. This situation is similar to the state when the number of nodes in the two resource pools is similar, and the distribution of each type of nodes is uniform. After that, the strategy sorts the two types of nodes separately. The idea of ​​sorting is: find the unsorted node whose sum of distances to all sorted nodes is closest to the mean, and add it to the sorted nodes (lines 24-37). The new node selected under this idea will not be too far or too close to the sorted node. Finally, the order of the two types of nodes is spliced ​​together to get the final node order (lines 38-42).

[0154] After completing the node sequencing, the scheduler can perform resource pool expansion or contraction operations based on the load prediction information. The expansion operation includes two aspects: labeling nodes and expelling running geographically independent tasks, while the contraction operation only removes node labels. When the system's monitoring module detects that the low-latency service resource pool is insufficient, or the scheduler determines that expansion is required based on the above load prediction information, the scheduler performs resource pool expansion, and adds labels to the nodes in order according to the node index at the end of the current resource pool until the required number of resources for expansion is reached. In addition, the scheduler will check all running geographically independent tasks. If the node where the task is running is already in the new resource pool, the task will be marked as "to be migrated", but only when the scheduler chooses to schedule a new low-latency service task to the node and finds that the resources are insufficient, the task will be expelled and rescheduled. When the system monitoring module finds that the resources occupied by the tasks in the resource pool are lower than the threshold, and combined with the load prediction information, it determines that contraction is required, the scheduler executes resource pool contraction. At this time, the scheduler removes the node labels in reverse order starting from the node at the end of the resource pool, and the scheduler can reschedule geographically independent tasks to these nodes. Considering the high frequency of low-latency service migration, the scheduler will not actively evict tasks that are still running, but wait for them to migrate to other nodes. The above expansion and contraction process can ensure that the system can quickly respond to load changes, ensure the quality and availability of low-latency services, and minimize the impact on running tasks.

[0155] Task load balancing strategy between groups

[0156] Based on the above-mentioned low-latency service load information and dynamic resource pool partitioning mechanism, the present invention further achieves load balancing by scheduling geographically independent tasks between groups. This strategy adopts the idea of ​​hierarchical scheduling: when each geographically independent task is submitted to a certain satellite group, it first needs to be initially scheduled at the group level until a certain execution group is determined, and then the scheduler in the group allocates computing resources within the group. To implement this strategy, it is necessary to increase the maximum scheduling number parameter for geographically independent tasks so that tasks can be scheduled to more idle groups. The pseudo code of this strategy is as follows:

[0157] Table 6 Pseudo code of load balancing strategy between groups

[0158]

[0159] When a task is submitted to a satellite group, the resource scheduler of the group selects itself and adjacent groups as candidate groups, and obtains the remaining resource data of all candidate groups and the load forecast data in the next orbital cycle through local cache or communication with adjacent groups. Based on these data, the scheduler scores all candidate groups, and the scoring formula is: W1*whether the task can be executed directly+W2*the number of remaining resources+W3*the time until the next resource pool expansion+W4*whether the task is in the current group (lines 1-7, 15-18). According to the scoring results, the scheduler submits the task to the group with the highest score and increases the number of schedulings attached to the task by one. If the group with the highest score is the group where the current task is located, the scheduler directly submits the task to the queue of tasks to be scheduled in the local group (lines 21-26). If the task has reached the maximum number of schedulings, the last scheduled task will be directly submitted to the queue of tasks to be scheduled in the corresponding group (lines 10-13). Through the above strategies, the scheduler can dynamically adjust the task load in different groups according to the resource and load conditions, and make the best use of the computing resources that will be idle in the future.

[0160] Task scheduling module:

[0161] The task scheduling module is the core of the entire satellite cloud computing resource scheduling system. This module is responsible for the following functions: 1) Providing users with two types of task submission and deletion interfaces; 2) Resource pool management, which is mainly responsible for dividing the resource pool according to ephemeris calculation and load prediction data, that is, adding / removing labels for working nodes in sequence; 3) Implementing the task hierarchical scheduling mode, including the task group scheduling interface and the scheduler extension plug-in for implementing Pod scheduling within the group.

[0162] (1) Task interface design:

[0163] According to the definition of tasks in the satellite cloud computing platform in the previous chapter, the present invention also defines two tasks in the form of CRD: the geographical location-independent task ComputeJob and the low-latency service task LowLatencyService. The definitions of the two are shown in Table 7 and Table 8 respectively. As can be seen from the table, the two tasks are basically the same in the fields such as Pod description, submission time, and submission location, but ComputeJob contains the number of rescheduling and the final execution group identification information, while LowLatencyService contains the migration process identification. The MigrationProcess related content will be described in detail in the low-latency service management part.

[0164] Table 7 ComputeJob resource description

[0165]

[0166] Table 8 LowLatencyService resource description

[0167]

[0168] Users can submit or stop tasks to the system through the interface provided by skclient. After the task reaches skagent, only InitialSatelliteId is modified, and then it is directly submitted to the k3s central node through the Create interface provided by CRD.

[0169] (2) Resource pool management:

[0170] According to the resource pool division strategy mentioned in the previous chapter, the main functions of the resource pool management module include sorting nodes and marking nodes according to the sorting. This module is still implemented in the mode of CRD and custom controller. The definition of ResourcePool custom resources is shown in Table 9.

[0171] Table 9 ResourcePool resource description

[0172]

[0173] The workflow of ResourcePool controller is as follows Figure 5 As shown. When creating a group, each group will create a ResourcePool resource in its own k3s cluster. After the controller corresponding to the resource is started, it first requests the MetricAggregator module mentioned above to obtain the current cluster resource information. Then the controller sorts all working nodes according to the node sorting strategy defined by SortPolicy. In addition to the homogenization strategy mentioned in the previous chapter, the sorting strategy also includes sorting by satellite number order and sorting by resource capacity. After the sorting is completed, the controller starts the LoadWatcher coroutine to update the NextAdjustment field, including time and resource pool target size, according to the prediction information provided by the load prediction module, and starts the node labeling coroutine NodeLabeler. The labeling process is to update the working node label in Kubernetes' Update method in accordance with the CurrentPoolSize and CurrentLastNode information in ResourcePool and the resource pool target size in NextAdjustment according to the node identifier in NodeOrder. After updating the NextAdjustment field, the LoadWatcher coroutine will also regularly collect cluster resource status information and update it to the load prediction module.

[0174] (3) Task scheduling implementation:

[0175] Combining the inter-group task load balancing strategy and the path-aware low-latency service task scheduling strategy described above, the present invention uses a custom controller and the Kubernetes scheduler extension framework (Scheduler Framework) to achieve hybrid scheduling of the two tasks.

[0176] The ComputeJob controller is mainly responsible for implementing the scheduling of geographically independent tasks and cross-group load balancing. When a user submits a ComputeJob object through skclient, the state of the object is first marked as INCOMING. The controller submits the task object in INCOMING state to the initial scheduling queue IncomingQueue inside the controller, which is implemented using the workqueue library provided by Kubernetes. At the same time, the load balancing coroutine in the controller will take out the task object to be scheduled from the queue and select the group to execute according to the load balancing strategy described above. If the task needs to be scheduled to other groups, the controller will call the Update method in PeerCluster to submit the task to other groups and delete the tasks in this group. If the task needs to be executed in this group, the controller will change the task status to PENDING. The task scheduling coroutine in the controller will continuously poll all tasks in PENDING state, and submit the unsubmitted Pods to the k3s cluster through Create, waiting for scheduling by the central scheduler. When all Pods in the task are started, the controller will change the task status to RUNNING, and change the status to FINISHED until all Pods are completed.

[0177] The LowLatencyService controller is mainly responsible for scheduling low-latency service tasks according to the scheduling path information provided by the migration management module. After the user submits the low-latency service, the object state is first marked as INCOMING state. The controller will create a corresponding MigrationProcess object for the task object in this state, and then mark it as PENDING state. At this time, the controller only needs to wait for the MigrationProcess controller to submit the Pod to the central scheduler, and mark the corresponding task object as SERVING, indicating that the task Pod is being scheduled in the cluster. The controller needs to continuously poll the task object in the SERVING state until its state changes to FINISHED and then delete the running Pod and MigrationProcess object. From this process, it can be seen that the LowLatencyService controller is only responsible for managing the status of the task and cleaning up at the end of the task, and does not care about the startup and migration process of the Pod.

[0178] Since the final scheduling execution unit in Kubernetes is Pod, the default scheduler does not know the task type corresponding to Pod. Therefore, the present invention extends the central scheduler based on the scheduler framework of Kubernetes so that it can distinguish Pods belonging to different task types and adopt corresponding scheduling strategies. The main extension points and functions of the scheduler framework are shown in Table 10.

[0179] Table 10 Scheduler framework extension points

[0180]

[0181] The present invention extends the QueueSort, Filter, PostFilter and Score plug-ins in the above table. In the QueueSort stage, the scheduler will distinguish between the two types of tasks based on the labels in the Pod, and arrange the Pods of low-latency service tasks in front to ensure that the user QoS is not affected. In the Filter stage, the scheduler selects nodes in different resource pools for the two types of Pods. For low-latency service tasks, if no suitable nodes are selected in the Filter stage, the scheduler will try to evict some geographically irrelevant task Pods to release resources in the PostFilter stage, and notify the resource pool management module to record load conflict information. In the Score stage, the scheduler will sort and score the nodes for low-latency service task Pods according to the access satellite information provided by MigrationProcess using the strategy in the previous chapter. Using the above plug-ins, the scheduling strategy described in the present invention can be implemented without affecting the original scheduling function of Kubernetes.

[0182] Low latency service migration management module:

[0183] The low-latency service migration management module is the core of the system to implement the low-latency service migration strategy. The main functions of this module include: 1) generating migration paths for low-latency services submitted by users, and continuously updating the paths as the services run; 2) controlling the start and stop of low-latency service Pods within the group; 3) providing a service preheating mechanism.

[0184] (1) Interface design

[0185] The low-latency service migration management is mainly implemented by the MigrationProcess CRD and its controller mentioned above. Each low-latency service task submitted by the user corresponds to a MigrationProcess object in the group, and the two are in a one-to-one correspondence. At the same time, a low-latency service task can correspond to MigrationProcess objects in multiple groups. The definition of the MigrationProcess custom resource is shown in Table 11:

[0186] Table 11MigrationProcess resource description

[0187]

[0188] In the above definition, PrevProcess and NextProcess point to the MigrationProcess object corresponding to the task in other groups respectively. This design makes the MigrationProcess objects in multiple groups belonging to the same task form a bidirectional linked list, which is mainly used to realize cross-group service migration. In addition, the Path field contains a list of PathNodes, which represents the most optimal migration path calculated by the user's location and the user's access satellite. Each PathNode represents a node on the path, including the user's access satellite identifier, service start and end time, optimal satellite and alternative satellite set, and the current state of the node. Since only some of the nodes on the migration path are located in the group, it is also necessary to record the PathNode information corresponding to the current group.

[0189] When the user submits a low-latency service task, the LowLatencyService object automatically creates the first MigrationProcess object. The MigrationProcess controller then uses the ephemeris calculation module to calculate the communication interval for a period of time in the future based on the user's location, and creates a Path based on the path selection algorithm described above. When it is determined that the first PathNode in the Path points to its own group, the controller will modify the state of the task object and submit the Pod to the scheduler based on the Pod description information of the task object. When the end time specified by the PathNode is reached, the controller will clean up the Pod corresponding to the previous PathNode and schedule a new Pod based on the new PathNode. When the number of nodes in the Path is less than the threshold, the controller will continue to calculate and update the new migration path.

[0190] (2) Service preheating mechanism:

[0191] Considering the high frequency of service migration, insufficient resources when migrating to a new satellite will cause service interruption, thereby reducing the user experience. Therefore, the present invention introduces a service preheating mechanism to reduce the cost of service migration by starting the Pod in advance on the subsequent migration node. Based on the idea of ​​sliding window, the present invention introduces the concept of service preheating window, and introduces four PathNode states: service state, preheating state, environment preparation state and waiting state. The PathNode at the head of the preheating window is in service state, and the satellite corresponding to this node is providing services to users; the PathNode immediately following it is in preheating state, and the satellite corresponding to this node needs to start the Pod of the corresponding service in advance, waiting for users to directly access after migration; the other PathNodes in the window are in environment preparation state, and the satellites corresponding to these nodes need to create MigrationProcess objects in advance and prepare the environment required to start the Pod, such as pulling container images, etc.; the PathNodes outside the window are in waiting state, and the satellites corresponding to these nodes do not need to perform any operations for the time being.

[0192] When the PathNode in the service state of the window reaches the service deadline, the entire service warm-up window moves back one node. At this time, the MigrationProcess controller corresponding to the PathNode that has just ended will send window updates to the controllers of the group where the PathNode is located in the subsequent window in a chained manner. After receiving the update information, the controller to which the PathNode at the end of the previous window belongs needs to create a MigrationProcess object in the corresponding group according to the new end PathNode information to complete the window's backward movement.

[0193] (3) Cross-group service migration mechanism:

[0194] Since satellites on the migration path may belong to different groups, the scheduler in the group cannot directly schedule tasks to satellites in other groups. To solve this problem, the present invention introduces a cross-group service migration mechanism, which enables tasks to be smoothly migrated between groups through the cooperation of MigrationProcess controllers between groups.

[0195] Combined with the warm-up window mechanism in the previous section, when the satellite corresponding to the PathNode at the end of the window does not belong to the current group, the controller needs to create a new MigrationProcess object in the corresponding group through the Create interface, and update the NextProcess and PrevProcess fields of itself and the new object. This process is similar to adding a node at the end of a linked list. At the same time, the controller also needs to send its own Path information to NextProcess through the Update interface. If the newly created MigrationProcess object finds that there is no corresponding LowLatencyService object in the group, it will create an additional object and adjust its status.

[0196] Under normal circumstances, as the window moves backward, only the preceding group needs to pass the Path information to the subsequent group. However, if the Pod in the warm-up phase cannot be started due to insufficient resources and other issues, and a satellite needs to be selected outside the optimal service satellite set, the controller needs to regenerate the migration path. At this time, the controller needs to first send the new Path information to PrevProcess, and then chain update information backward based on the newly generated subsequent PathNode, thereby updating the entire migration path.

[0197] (3) Satellite network low-latency service migration mechanism

[0198] Since low-latency services are strongly related to geographical location, frequent inter-satellite migration is required to meet QoS. The existing inter-satellite service migration strategy only considers the impact of latency, but it leads to very frequent service migration, and there is also contention for resources when multiple services migrate at the same time. At the same time, under the premise of grouping satellites, each service needs to migrate between groups at the same time, and the scheduling nodes of different groups need to work together. Therefore, the present invention uses the characteristics of satellite movement direction to design a migration path selection strategy for QoS and migration cost optimization, and based on this, designs a service cross-group migration mechanism to reduce the service migration cost while ensuring service quality.

[0199] Low latency service migration path selection:

[0200] When the user's location and start time are known, the satellites and communication intervals that the user can communicate with in the future can be calculated through the satellite motion trajectory. A simple strategy is to continuously select the satellite deployment task closest to the user. Under this strategy, the user's access to the service has the lowest delay, but the cost is a high frequency of service migration. The present invention proposes a solution that uses QoS constraints instead of the optimal distance. By constraining the delay between the user accessing the satellite and the satellite providing the service, the service quality is guaranteed while reducing the service migration frequency.

[0201] Given a user's location (latu ,lon u ), in the future period T starting from the time t0 when the user submits the task, the set of satellites and their communication intervals that enter the user's communication range within [t0, t0+T) can be calculated through the SGP4 orbit model. Figure 4 As shown in Fig. 1, in order to reduce the user's overhead caused by frequent switching of access satellites, the satellite with the longest communication time at the current moment should be selected as the access satellite, so that the access satellite sequence [(s1), (s2), ..., (s n )] (as shown in the blue node in the figure). For each access satellite, a corresponding set of candidate service satellite sets S can be obtained according to the QoS constraints, thereby obtaining a candidate service satellite set sequence [S1, S2, ...S n ] (as shown in the white circle in the figure). Selecting a satellite from each set can form a service migration path [(x1), (x2), ..., (x n )], if the adjacent elements in the sequence are the same, it means that the satellite provides services continuously and does not need to be migrated, so the adjacent and identical elements can be merged into one (the green node in the figure). At this time, the problem can be transformed into: select a service migration path so that the number of satellites contained in the path is as small as possible. This selection method can make the number of service switching as small as possible while satisfying the QoS constraints, thereby reducing the overhead of frequent migration. This problem can be solved by dynamic programming, and T can be appropriately reduced to reduce the size of the search solution space. The pseudo code of the specific strategy is shown in Table 12.

[0202] Table 12 Minimum migration path algorithm

[0203]

[0204]

[0205] To solve this problem using dynamic programming, we first need to consider the definition of the state. Define dp[i][j] as the number of states in the first i sets with x j is the minimum number of subsequences after deduplication in the ending sequence. For a new set Si, for each number x in it p , we can add that number to the current sequence. At this point, we need to consider two cases:

[0206] ·Digit x p appears only once. In this case, we can simply replace the number x with p Add to the current sequence and update dp[i][p] = dp[i-1][j] + 1, where j represents the number of ps in the first i-1 sets with x. jThe ending sequence. (Lines 13-17)

[0207] ·Digit x p has already appeared in the current sequence. In this case, we do not need to change the number x p To add to the current sequence, just update dp[i][p] = dp[i-1][j], which means the number of independent numbers in the sequence remains unchanged (lines 19-22)

[0208] The final answer is dp[n][j], where n represents the number of sets. We need to find the minimum number of sequences, that is, the minimum value in dp[n][j]. In the algorithm implementation, a pre array can be maintained to record the predecessor state of each state, and finally backtracking from dp[n][j] to obtain a sequence that meets the conditions (lines 28-37). When the algorithm is actually used, the present invention randomly numbers all satellites, and each candidate service satellite set needs to be sorted according to the number, and the sequence finally returned is the selected optimal migration path.

[0209] Migration path-aware task scheduling strategy:

[0210] For each low-latency service task, an optimal migration path can be obtained according to the above algorithm, but in the actual scheduling process, there may be insufficient satellite resources on the optimal migration path. Considering that the solution of the above algorithm is not unique and there are more suboptimal migration paths, the scheduler can select an appropriate migration path according to the resource situation to avoid resource contention among low-latency tasks.

[0211] For ground users, they can directly access multiple adjacent satellites at any time, but the accessible communication intervals are of different lengths. The above algorithm obtains the optimal migration path by continuously selecting the satellite with the longest service time after switching, but there are still many other satellites to choose from. The present invention converts the user's communication interval information into a directed acyclic graph, such as Figure 5As shown, each node represents a satellite, including the start and end time of the user's communication with the satellite, and the weight above the node represents the time the user stays after migrating from other satellites to the satellite. In the figure, the satellites are divided into multiple stages according to the start and end time of the service, and the end time of satellite communication in each stage is strictly greater than the previous stage. For satellites in the same stage, it can be seen from the figure that the number of times the user service migrates to these satellites is the same, and there is only a difference in the service duration. Therefore, the satellites in the stage can be sorted according to the service deadline, and the satellite with the latest deadline is on the optimal path. To return to the optimal path from satellites on other suboptimal migration paths, an additional migration is required within the stage. In addition, since the distance between satellites in the same stage is also relatively close, there is also an intersection between the sets of service satellites that meet the QoS requirements. Therefore, all service satellite sets in each stage can be divided into multiple non-overlapping subsets, corresponding to different satellites in the stage.

[0212] The scheduler can optimize the task resource scheduling based on the above-mentioned stage satellite information combined with the resource status. First, the scheduler should give priority to allocating resources in the low-latency service resource pool mentioned above. Under the resource pool constraint, the scheduler allocates the resources of the corresponding satellite according to the path provided by the optimal path selection algorithm. If the satellite resources are insufficient, the scheduler will select other satellites in the service satellite subset belonging to the user's optimal access satellite, and the selection process is sorted by distance. In special cases, if there are still no available resources in the subset, the scheduler selects the resources in the service satellite subset of the suboptimal access satellite according to the satellite sorting in the stage, and re-runs the path selection algorithm. In the extreme case where there are still no resources available, the scheduler can select satellites outside the resource pool for scheduling. Through the above strategies, the scheduler can maximize the use of user communication interval information and achieve reasonable allocation of resources.

[0213] Scheduling Strategy Simulator:

[0214] Since there are many nodes in the low-orbit satellite constellation, and the system designed by the present invention requires the nodes to work together, a large amount of computing resources are needed to simulate the actual satellite nodes, and it is difficult to verify whether the scheduling strategy is effective in a short time. Therefore, the present invention designs and implements a satellite cloud computing resource scheduling strategy simulator, which simulates multiple satellite clusters in a multi-process manner, and improves the execution speed of the simulator by generating the tasks and satellite communication interval information required for the simulation in advance, and finally displays the simulation result data in an intuitive form.

[0215] The overall architecture of the emulator:

[0216] The overall architecture of the scheduling strategy simulator is as follows Figure 6As shown. The simulator is mainly composed of a task generation module, an ephemeris management module, a simulation module, a scheduler module and a data processing module. The task generation module is mainly responsible for generating task loads within a period of time according to the task generation configuration provided by the user, and mapping them to the corresponding satellites. The ephemeris management module is responsible for providing satellite-related information, including the communication interval with the ground position, visible satellites, etc. The simulation module is the core of the entire simulator, and is composed of a simulation process controller and a plurality of satellite grouping objects. The controller drives the overall simulation process, and the satellite grouping object is mainly responsible for simulating the grouping state, including the state of tasks within the group, adjacent groups and satellites within the group. The scheduler module mainly implements various scheduling strategies, including the strategies introduced in the present invention and some comparison strategies. The satellite cluster process completes the simulation of task scheduling by calling the interface provided by the scheduler module. The data processing module is responsible for collecting the task operation data generated during the simulation process, and analyzing the data after the simulation is completed to help users verify the actual effect of the scheduling strategy. The scheduling simulator of the present invention is implemented using Python, and the part involving satellite orbit and motion simulation is implemented using the python-skyfield library.

[0217] (1) Task load generation:

[0218] The simulator also implements the two types of tasks mentioned above, and the task definition is similar to the task CRD definition mentioned above. However, since the simulator does not run actual tasks, the definition of each task also includes end time information. The simulation module determines whether the task has ended based on this information and modifies the status of the corresponding task and satellite. Note that this information is not exposed to the scheduler, so the scheduler still schedules tasks according to the actual status of the satellite computing resources.

[0219] Before the simulation process starts, the task generation module generates tasks according to the configuration file input by the user. The main information contained in the configuration file is shown in Table 13 Task generation configuration parameters. The load distribution and task parameters of the two tasks can be configured differently.

[0220] Table 13 Task generation configuration parameters

[0221]

[0222] Since the number of task loads in each geographically divided area is different, the process of generating tasks is carried out one by one according to the geographically divided areas. In order to make the generated task load more realistic, the present invention uses the idea of ​​random sampling to generate the arrival time of each task. First, according to the normalized load position and time distribution information, multiplying by the total daily task amount can obtain the number of tasks per hour in each area. According to this number, the average arrival interval of the tasks in this hour can be obtained. Since the arrival time of the task obeys the Poisson distribution, the interval between the arrivals of adjacent tasks obeys the exponential distribution with λ as the parameter, where λ means the frequency of task arrival, and the value of the average arrival interval is 1 / λ. According to the idea of ​​random sampling, the average arrival interval of the task can be used to generate a set of random variables that obey the exponential distribution. Using this method, the arrival interval of each task in each hour can be generated, thereby determining the arrival time of the task.

[0223] (2) Simulation process:

[0224] The goal of the simulator is to simulate the execution of generated tasks according to the scheduling strategy in a specific satellite scenario based on the configuration input by the user, and finally output the overall situation of task execution. The longest time-consuming part of the entire process is the part of calculating the communication interval between the user and the satellite. In particular, since the low-latency service task needs to be migrated according to the satellite and user location information, the simulator not only needs to simulate task scheduling, but also needs to calculate the location information of the satellite and ground users in real time. Therefore, the present invention divides the entire simulation process into the following Figure 7 The simulation process consists of three stages: environment preparation stage, simulation stage and data processing stage, which can reduce the amount of calculation in the simulation stage as much as possible and improve the overall efficiency of the simulation.

[0225] In the environment preparation phase, the task load and satellite constellation information need to be generated first. The task load generation is as described above. The satellite constellation information generation is to generate the corresponding number of satellite objects and the available resources of each satellite according to the user configuration, and to group the satellites in advance according to the grouping strategy to create multiple satellite grouping objects. Secondly, since the task first reaches the central node of each group when it is submitted, this stage needs to assign each task to different grouping objects according to its submission time and location. Considering that this step is time-consuming and the satellite environment and load are fixed when comparing scheduling strategies, the task-group mapping will also be cached in this stage. When the subsequent simulation uses the same task load set and satellite configuration, this step can be skipped directly. Finally, this stage will also generate the satellite communication interval information required for each low-latency service task based on the geographic location and time information in the task set and cache it in the file. The simulator will load the file into memory and search it at runtime to reduce the amount of calculation.

[0226] The simulation stage is to schedule the task to the satellite for simulated execution according to the scheduling strategy, and record the execution data. The present invention adopts the event simulation mode to put the events that may occur in the scheduler into a priority queue sorted by time. After the simulation starts, the controller takes out the earliest event at the head of the queue in turn, steps the simulator time, and calls the processing function of the event. During the event processing process, if a new event is generated, the new event will be reinserted into the priority queue by the controller. Events in the simulator can be divided into two categories: task simulation events and statistical data events. Task simulation events are mainly responsible for the simulation of the task execution process, such as the start and end of tasks, low-latency service migration, etc.; statistical data events are mainly responsible for statistical cluster load and task execution status. Specific events include the following:

[0227] JobSubmit: indicates that the task is submitted to the cluster. After the task is submitted, the controller sends the task to the scheduling module. For geographically independent computing tasks, the scheduling module selects a group according to the inter-group scheduling strategy, and then the scheduler within the group schedules the Pod in the task. If the Pod is successfully started at this time, a PodFinish event is generated and inserted into the event queue. If it is not started, it is inserted into the cluster's task waiting queue. For low-latency service tasks, the controller sends the task to the service migration management module and generates a migration path, and sends the Pod to the scheduler within the group for scheduling, and finally generates a ServiceFinish event and inserts it into the event queue.

[0228] PodFinish: indicates that the Pod execution is finished. When the Pod execution is finished, the occupied computing resources need to be released and the execution status of the corresponding task needs to be modified.

[0229] ServiceFinish: Indicates the end of low-latency service execution. Clean up all running Pods and preheated Pods corresponding to the service, and count service execution information.

[0230] ServiceMigrate: indicates low-latency service migration. This event is generated by the service migration module when the task is submitted. The service migration module needs to submit the Pod to the scheduler of the corresponding group according to the next service satellite indicated by the event, and close the Pod that completed the previous service.

[0231] ResourcePoolUpdate: indicates updating the resource pool in the cluster. For the scheduling strategy proposed in the present invention, it is necessary to timely update the resource pool division in the group according to the position of the satellite.

[0232] UserAccessChange: indicates that the user access satellite has changed. For each low-latency service, the controller will generate a series of user access change events. When processing the event, the system will count the delay between the event and the user access service during the last switching process.

[0233] StatsSample: indicates the collection of cluster load status. When the system starts, it will generate this event in batches according to the interval requirements, which is used to collect cluster load information during the simulation process.

[0234] Table 14 Simulator statistics

[0235]

[0236] After the simulation is finished, the simulator will generate multiple statistical data record files. The work of the data processing stage is to integrate these data into the overall execution status of the task. This stage only takes the statistical data record file as input, so it can run independently of the simulation stage. The final statistical data of the data processing stage can be divided into three categories, as shown in Table 14. Users can use these data to compare the advantages and disadvantages of different scheduling strategies.

[0237] (3) Satellite cloud computing resource scheduling system prototype and simulator implementation:

[0238] Since there is no satellite cloud computing platform that has been deployed, in order to further verify the load balancing and service migration mechanism, the present invention designs and implements a prototype of a satellite cloud computing resource scheduling system. The prototype is implemented based on the Kubernetes platform extension and deployed on a satellite computing simulation platform composed of multiple lightweight virtual machines, simulating the intersatellite network through external network traffic control. Users can observe the status of load balancing and service migration by submitting tasks to the prototype platform. In addition, in order to efficiently verify the effect of resource scheduling strategies in large-scale satellite network scenarios, the present invention also designs and implements a satellite cloud computing resource scheduling simulator to verify the advantages and disadvantages of different scheduling strategies.

[0239] Although some embodiments of the present disclosure have been shown and described, it will be appreciated by those skilled in the art that modifications may be made to the embodiments without departing from the principles and spirit of the present disclosure, the scope of which is defined by the claims and their equivalents.

Claims

1. A satellite group management system for satellite cloud computing Internet platform, characterized in that: It includes three modules: group management module, task scheduling module and low-latency service migration management module. All three modules run on the management node k3s master of k3s. The system also includes an ephemeris calculation module that provides satellite information for each module, a client skclient running on the client terminal, and skagent running on the satellite of the working node. In terms of functional architecture, the client skclient accesses the API provided by the system through the remote procedure call framework gRPC, which is used to submit tasks to the task scheduling module and low-latency service migration management module in the management node k3s master, and to add and delete peer relationships to the group management module; The API can be used to submit tasks or services to the skagent on the work node satellite. After the user's access reaches the skagent running on the work node, the skagent running on the work node forwards the user request to the corresponding module of the k3s management node k3s master; the skagent running on each work node is also connected to the satellite distributed file system; The functions of each module are as follows: The group management module internally constructs a delay-constrained satellite group management mechanism, designs a load balancing strategy between groups based on geographic information applicable to the satellite system, constructs a group management interface design, an adjacent group registration mechanism and an adjacent group status management mechanism, manages adjacent group relationships, and collects the resource status of adjacent groups; The task scheduling module is responsible for monitoring tasks submitted by users, and implements three mechanism designs through task interface design, resource pool management, and task scheduling. It allocates computing resources to tasks or schedules them to other groups according to the scheduling strategy. At the same time, this module is also responsible for the management of the resource pool. The low-latency service migration management module builds a satellite network low-latency service migration mechanism, and is responsible for calculating the optimal migration path according to the user's location and managing the migration status of services within and between groups through interface design, enlistment warm-up mechanism, and cross-group service migration mechanism design. The system also includes a scheduling strategy simulator for satellite cloud computing resources, which consists of a task generation module, an ephemeris management module, a simulation module, a scheduler module, and a data processing module; The task generation module is responsible for generating the task load within a period of time according to the task generation configuration provided by the user, and mapping it to the corresponding satellite; the ephemeris management module is responsible for providing satellite-related information, including the communication interval with the ground position and visible satellites. It runs on the k3s management node and is responsible for providing the user communication interval information required by the scheduling algorithm, while maintaining the current satellite position information of the group; the simulation module is composed of a simulation process controller and a plurality of satellite grouping objects. The simulation process controller drives the overall simulation process. The satellite grouping object is mainly responsible for simulating the grouping state, including the state of tasks within the group, adjacent groups and satellites within the group; the scheduler module implements various scheduling strategies. The satellite cluster process completes the simulation of task scheduling by calling the interface provided by the scheduler module. It is implemented in Python, and the part involving satellite orbit and motion simulation is implemented using the python-skyfield library; the data processing module is responsible for collecting the task operation data generated during the simulation process, and analyzing the data after the simulation is completed to help users verify the actual effect of the scheduling strategy.

2. A satellite group management system for a satellite cloud computing Internet platform as claimed in claim 1, characterized in that: The specific implementation method of the group management interface design of the group management module is as follows: first define the custom resource type PeerCluster, the structure of the PeerCluster resource contains the unique identifier of the group, the address of the group center node, the identifier and address of the working node in the group, and the status of the group, and the working node is recorded through the Satellite custom type.

3. A satellite group management system for a satellite cloud computing Internet platform as claimed in claim 2, characterized in that: The specific implementation method of the adjacent group registration mechanism designed by the group management interface of the group management module is as follows: after the user sets the satellite information of each group through skclient, the adjacent groups automatically discover and establish adjacent relationships through the satellite topology. First, the central node of each group calls the StartPeerDiscovery interface of skagent on each working node in the group. The StartPeerDiscovery interface function initiates a GetClusterSpec request to the four surrounding satellite nodes according to the satellite topology, and returns the aggregated 4 PeerCluster information to the central node; After the central node deduplicates the return results of each node according to ClusterId, it adds the PeerCluster information of non-self-groups to k3s through the Create interface of CRD. The PeerCluster resource controller will automatically update the status of the corresponding adjacent group, start the adjacent group monitoring component, and start sending heartbeats to the central node of the adjacent group.

4. A satellite group management system for a satellite cloud computing Internet platform as claimed in claim 3, characterized in that: The specific implementation of the adjacent group state management mechanism designed by the group management interface of the group management module is as follows: When adjacent groups have completed mutual discovery, each group starts a PeerMonitor monitoring coroutine for each adjacent group to obtain the resource status and load forecast information of the adjacent group; at the same time, each group starts the MetricAggregator program at startup to aggregate the resource data within its own group; the PeerMonitor monitoring coroutine works in a way of pulling information, and regularly obtains the aggregated resource status information PeerMetric from the PeerCluster other than itself in the group; to ensure the real-time nature of the information, PeerMetric provides a separate external reading interface through the Kubernetes extended API mechanism; The specific way of status interaction between groups is as follows: after the group enters the working state, MetricAggregator obtains the resource status of the current cluster and the load information provided by the load prediction module at a certain frequency, creates a PeerMetric object and inserts it into its own cache queue, and registers the APIServer resource to Kubernetes, exposing the GetPeerMetric interface for accessing the latest data; PeerMonitor obtains the PeerMetric structure of the adjacent group by polling the GetPeerMetric interface exposed by the adjacent cluster, and finally calls the Update interface to update the local CRD record.

5. A satellite group management system for satellite cloud computing Internet platform as claimed in claim 4, characterized in that: The specific implementation of the delay-constrained satellite grouping management mechanism is as follows: First, the communication delay between satellites in the low-orbit satellite constellation is modeled: for the case where each satellite only communicates with the two satellites in front and behind in the same orbit and the two satellites in the same position in the adjacent orbit, the communication delay between adjacent satellites can be divided into two types: the communication delay in the same orbit and the communication delay in the adjacent orbit. The communication delay of non-adjacent satellites can be obtained by linear combination of the above two delays. Given M orbital planes and N satellites on each orbital plane, the satellite network is abstracted as a grid of ω, where M and N are natural numbers, and the points on the upper and lower sides and the left and right sides of the grid are directly connected. For satellites on the same orbital plane, since their front and back positions are fixed, the distance D between two adjacent satellites is N for: where r E is the radius of the earth, h is the orbital height. Since the distance between satellites in adjacent orbits changes periodically with the orbital period T, within a given time t∈[0,T), the distance between two satellites in adjacent orbits is: Where i is the orbital inclination of the satellite. When t is 0, it is assumed that the satellite is in the equatorial plane. At this time, the distance between the two satellites is the farthest. By integrating and averaging the above formula, the average distance between adjacent orbital satellites can be obtained: Where E is the second kind of elliptic curve integral. Dividing the above distance by the speed of light in vacuum c, we can get the communication delay τ between adjacent satellites. M and τ N , since the constellation topology is shaped like a two-dimensional grid, the coordinates (x, y) on the grid can be used to refer to the satellites in the constellation. It is easy to know that the communication delay τ between any two satellites (x1, y1) and (x2, y2) is the shortest number of hops between the two coordinates multiplied by the delay: τ=min(abs(x1-x2)%M,abs(x2-x1)%M)*τ M +min(abs(y1-y2)%N,abs(y2-y1)%N)*τ N Where % is the modulus operation, and abs is the absolute value operation; then construct the delay constraint satellite grouping method: given the delay constraint τ SLO , for any satellite s i , which is different from other satellites in the same group j The communication delay must be within the constraints, that is, Under the condition of meeting the above constraints, the number of groups should be as small as possible to improve the overall resource utilization efficiency of the satellite; Find a set of points R in the grid such that the distance between any point in the graph and exactly one point in R is less than or equal to d. Normalize the distance by adding virtual nodes, run the d-hop placement algorithm, and then scale the nodes proportionally. The result is such that the distance from each node to the nodes in the dominating set is less than or equal to d+∈, where ∈ is the error generated during the scaling and rounding process. The number of nodes in the dominating set is the number of groups. Finally, traverse all remaining nodes and assign each node to the group to which the dominating node closest to it belongs. Then, a group computing resource balancing strategy is constructed: first, in the process of traversing each node, nodes that can join multiple clusters or cannot join any cluster are temporarily ignored; then, clusters are assigned to ungrouped nodes through the backtracking method to find the optimal solution under the current grouping situation; secondly, since the Torus grid is a ring topology, the determined dominant nodes are further translated on the overall grid, and the grouping is calculated separately for each situation. Since there are at most M*N situations, the global optimal solution is obtained directly through exhaustive enumeration.

6. A satellite group management system for a satellite cloud computing Internet platform as claimed in claim 5, characterized in that: The specific implementation method of the inter-group load balancing strategy based on geographic information is: First, define the task parameters running on the low-orbit satellite computing platform. Each task consists of 1 to N Pods, and each Pod contains the required CPU and memory resources. Each task is accompanied by the satellite information to which it was initially submitted, recorded in the coordinates of the satellite in the constellation. Low-latency service tasks also contain the location information of ground users, recorded in longitude and latitude. Finally, each task also includes the time it was submitted to the computing platform. Afterwards, the geographic information and ground load density information used in the scheduling strategy are modeled. Assuming that users directly access the satellite through ground terminals, the geographic division and traffic ratio change map data used are used as benchmark data. The earth's surface is divided into 72 regions in units of 30 degrees, and the longitude range is further divided in units of 15 degrees. The regions are aligned with time zones to form 144 regions, and the equipment density index is normalized to the task load ratio and mapped to the 144 regions; at the same time, the traffic ratio of each time period in the traffic ratio change map is converted into the relative ratio of each time period, and the corresponding time zone is multiplied with the load ratio in the regional division map to obtain the task load ratio zoning table for each time period; Afterwards, based on the sub-satellite trajectory of the satellites in the group, the sampling method is used to model the change in the proportion of the ground low-latency service task load that each group may receive in the future. For each satellite s in a group S i , starting from the same time t0, the low-latency service mission load ratio within the next satellite orbit period T is r i1 ,…,r im , where m is the number of samples, r ij for Time Satellites i The latitude and longitude of the subsatellite point combined with the value obtained from the dictionary mentioned above in the time zone where the geographic coordinates are located, the load ratio R of the entire group S is the mean of the load ratio of each satellite in the group. The data is converted into a histogram by finding the interval mean, where the horizontal axis is the discretized time period, the vertical axis is the maximum value of the load ratio in the time period, and the interval length is used as the adjustment parameter. The smaller the parameter, the higher the frequency of the scheduler module to adjust the resource pool size, which is closer to the actual optimal load ratio, but also has a greater impact on the running tasks; After that, a dynamic partitioning strategy for computing resource pools is constructed, which includes two parts: resource pool node sorting and resource pool capacity adjustment strategy: The node sorting part of the resource pool uses a greedy algorithm to sort all nodes, so that the distribution of nodes in the resource pool is as uniform as possible during the expansion and contraction process; first, the nodes in the group are divided into two categories starting from the central node using breadth-first search, so that the two types of nodes are not adjacent to each other, and the distribution of each type of nodes is uniform; then, the strategy sorts the two types of nodes respectively, and the idea of ​​sorting is: find the unsorted node whose sum of distances to all sorted nodes is closest to the mean, and add it to the sorted nodes; finally, the order of the two types of nodes is spliced ​​to get the final node order; The resource pool capacity adjustment strategy is specifically as follows: after completing the node sequencing, the scheduler module performs resource pool expansion or contraction operations according to the load prediction information. The expansion operation includes tagging nodes and expelling geographically irrelevant tasks that are running, while the contraction operation only removes node labels. When the system's monitoring module detects that the low-latency service resource pool is insufficient, or the scheduler module determines that expansion is required based on the above load prediction information, the scheduler module executes resource pool expansion, and adds labels to the nodes in order according to the node index at the end of the current resource pool until the required number of resources for expansion is reached. The scheduler module checks all running geographical For irrelevant tasks, if the node where the task is running is already in the new resource pool, the task will be marked as "to be migrated", but the task will be evicted and rescheduled only when the scheduler module chooses to schedule a new low-latency service task to the node and finds that the resources are insufficient; when the system monitoring module finds that the resources occupied by the tasks in the resource pool are lower than the threshold, and combines the load prediction information to determine that the capacity needs to be reduced, the scheduler executes the resource pool reduction. At this time, the scheduler removes the node labels in reverse order starting from the last node in the resource pool, and the scheduler can reschedule geographically irrelevant tasks to these nodes; the scheduler module does not actively evict tasks that are still running, but waits for them to migrate to other nodes by themselves; Finally, a task load balancing strategy between groups is constructed: load balancing is achieved by scheduling geographically independent tasks between groups. When a task is submitted to a satellite group, the resource scheduler of the group selects itself and adjacent groups as candidate groups, and obtains the remaining resource data of all candidate groups and the load forecast data for the next orbital cycle through local cache or communication with adjacent groups; based on these data, the resource scheduler scores all candidate groups, and the scoring formula is: W1*whether the task can be executed directly+W2*the number of remaining resources+W3*the time until the next resource pool expansion+W4*whether the task is in the current group; based on the scoring result, the resource scheduler submits the task to the group with the highest score and increases the number of scheduling times attached to the task by one; If the group with the highest score is the one where the current task is located, the resource scheduler directly submits the task to the queue of tasks to be scheduled in the local group; If the task has reached the maximum number of scheduling times, the last scheduled task will be directly submitted to the queue of tasks to be scheduled in the corresponding group.

7. A satellite group management system for a satellite cloud computing Internet platform as claimed in claim 6, characterized in that: The specific method of designing the task interface in the task scheduling module is as follows: two tasks are defined in the form of CRD: geographically independent task ComputeJob and low-latency service task LowLatencyService. The two tasks are basically consistent in fields such as Pod description, submission time, and submission location, but ComputeJob contains the number of rescheduling times and the final execution group identification information, while LowLatencyService contains the migration process identification; users can submit or stop tasks to the system through the interface provided by skclient. After the task arrives at skagent, only InitialSatelliteId is modified, and then it is directly submitted to the k3s central node through the Create interface provided by CRD; The specific method of resource pool management in the task scheduling module is as follows: first, define the ResourcePool custom resource, and then build the workflow of the ResourcePool controller. When creating a group, each group creates a ResourcePool resource in its own k3s cluster; after the controller corresponding to the resource is started, first request the MetricAggregator to obtain the current cluster resource information; then the controller sorts all working nodes according to the node sorting strategy defined by SortPolicy, and the sorting strategy includes the homogenization strategy, sorting by satellite number order, sorting by resource capacity and other strategies; after the sorting is completed, the controller starts the LoadWatcher coroutine to update the NextAdjustment field according to the prediction information provided by the load prediction module, including the time and the target size of the resource pool, and starts the node labeling coroutine NodeLabeler; the labeling process is to update the working node label according to the CurrentPoolSize and CurrentLastNode information in ResourcePool and the target size of the resource pool in NextAdjustment, and according to the node identifier in NodeOrder, in turn through the Update method of Kubernetes; after updating the NextAdjustment field, the LoadWatcher coroutine regularly collects cluster resource status information and updates it to the load prediction module; The specific method of implementing task scheduling in the task scheduling module is: using the customized ComputeJob controller, LowLatencyService controller extension framework and Kubernetes controller extension framework to implement mixed scheduling of two tasks: The ComputeJob controller implements the scheduling of geographically independent tasks and cross-group load balancing functions; when a user submits a ComputeJob object through skclient, the state of the object is first marked as INCOMING, and the controller submits the task object in INCOMING state to the initial scheduling queue IncomingQueue inside the controller, which is implemented using the workqueue library provided by Kubernetes; at the same time, the load balancing coroutine in the ComputeJob controller will take out the task object to be scheduled from the queue, and the load balancing strategy will select the group to execute; if the task needs to be scheduled to other groups, the ComputeJob controller calls the Update method in PeerCluster to submit the task to other groups and delete the tasks in this group; If the task needs to be executed in this group, the ComputeJob controller changes the task status to PENDING; the task scheduling coroutine in the ComputeJob controller continuously polls all tasks in the PENDING status, and submits the unsubmitted Pods to the k3s cluster through Create, waiting for scheduling by the central scheduler; when all Pods in the task are started, the controller changes the task status to RUNNING, and changes the status to FINISHED after all Pods are completed; The LowLatencyService controller is mainly responsible for scheduling low-latency service tasks according to the scheduling path information provided by the migration management module; after the user submits the low-latency service, the object state is first marked as INCOMING state, and the controller will create a corresponding MigrationProcess object for the task object in this state, and then mark it as PENDING state; at this time, the LowLatencyService controller only needs to wait for the MigrationProcess controller to submit the Pod to the central scheduler, and mark the corresponding task object as SERVING, indicating that the task Pod is being scheduled in the cluster; the LowLatencyService controller continuously polls the task object in SERVING state until its state changes to FINISHED, and then deletes the running Pod and MigrationProcess object; The extension framework of the Kubernetes controller extends the central scheduler so that it can distinguish Pods belonging to different task types and adopt corresponding scheduling strategies; in the QueueSort stage, the extension framework of the Kubernetes controller enables the scheduler to distinguish the two types of tasks according to the labels in the Pod, and arrange the Pods of low-latency service tasks in front to ensure that the user QoS is not affected; in the Filter stage, the extension framework of the Kubernetes controller enables the scheduler to select nodes in different resource pools for the two types of Pods; for low-latency service tasks, if no suitable nodes are selected in the Filter stage, the extension framework of the Kubernetes controller enables the scheduler to try to evict some geographically irrelevant task Pods to release resources in the PostFilter stage, and notify the resource pool management module to record load conflict information; in the Score stage, the extension framework of the Kubernetes controller enables the scheduler to rank and score the nodes for low-latency service task Pods according to the access satellite information provided by MigrationProcess using the strategy in the previous chapter.

8. A satellite group management system for a satellite cloud computing Internet platform as claimed in claim 7, characterized in that: The interface design in the low-latency service migration management module is specifically as follows: Define the MigrationProcess custom resource. PrevProcess and NextProcess point to the MigrationProcess object corresponding to the task in other groups. The Path field contains a list of PathNodes. Each PathNode represents a node on the path, including the user's access satellite ID, service start and end time, optimal satellite and alternative satellite set, and the current state of the node. Since only some of the nodes on the migration path are located in the group, the PathNode information corresponding to the current group also needs to be recorded. When the user submits a low-latency service task, the LowLatencyService object automatically creates the first MigrationProcess object; then the MigrationProcess controller uses the ephemeris calculation module to calculate the communication interval for a period of time in the future according to the user's location, and creates a Path according to the path selection algorithm; when it is determined that the first PathNode in the Path points to its own group, the controller will modify the state of the task object and submit the Pod to the scheduler according to the Pod description information of the task object; when the end time specified by the PathNode is reached, the controller will clean up the Pod corresponding to the previous PathNode and schedule a new Pod according to the new PathNode; when the number of nodes in the Path is less than the threshold, the controller will continue to calculate and update the new migration path; The service preheating mechanism in the low-latency service migration management module is specifically as follows: the concept of service preheating window is introduced, and four PathNode states: service state, preheating state, environment preparation state and waiting state; the PathNode at the head of the preheating window is in service state, and the satellite corresponding to the node is providing services to users; the PathNode immediately following it is in preheating state, and the satellite corresponding to the node needs to pre-start the Pod of the corresponding service, waiting for the user to directly access after migration; the other PathNodes in the window are in environment preparation state, and the satellites corresponding to these nodes need to create MigrationProcess objects in advance and prepare the environment required to start the Pod, such as pulling container images; the PathNodes outside the window are in waiting state, and the satellites corresponding to these nodes do not need to perform any operations temporarily; when the PathNode in the service state of the window reaches the service deadline, the entire service preheating window moves back one node, and the MigrationProcess controller corresponding to the PathNode that has just ended will send window updates to the controllers of the group where the PathNode is located in the subsequent window in a chained manner; after receiving the update information, the controller to which the PathNode at the end of the previous window belongs needs to create a MigrationProcess object in the corresponding group according to the new end PathNode information to complete the window backward movement.

9. A satellite group management system for a satellite cloud computing Internet platform as claimed in claim 8, characterized in that: The method for constructing the cross-packet service migration mechanism in the low-latency service migration management module is specifically as follows: Through the cooperation of MigrationProcess controllers between groups, tasks can be smoothly migrated between groups; When the satellite corresponding to the PathNode at the end of the window does not belong to the current group, the MigrationProcess controller needs to create a new MigrationProcess object in the corresponding group through the Create interface, and update the NextProcess and PrevProcess fields of itself and the new object; at the same time, the MigrationProcess controller sends its own Path information to NextProcess through the Update interface; if the newly created MigrationProcess object finds that there is no corresponding LowLatencyService object in the group, it will create an additional object and adjust its status; If the Pod in the preheating phase cannot be started due to insufficient resources and other issues, and a satellite needs to be selected outside the optimal service satellite set, the controller needs to regenerate the migration path. At this time, the MigrationProcess controller needs to first send the new Path information to the PrevProcess, and then chain update information backwards based on the newly generated subsequent PathNode, thereby updating the entire migration path. In the low-latency service migration management module: the construction method of the satellite network low-latency service migration mechanism is specifically: including two modules of low-latency service migration path selection and migration path-aware task scheduling strategy; The low-latency service migration path selection uses QoS constraints to limit the delay between the user accessing the satellite and the satellite providing the service, thereby reducing the service migration frequency while ensuring the service quality; Given a user's location (lat u ,lon u ), in the future period T starting from the time t0 when the user submits the task, the set of satellites and their communication intervals that enter the user's communication range within [t0, t0+T) are calculated by the SGP4 orbit model; first, the satellite with the longest communication time at the user's current moment is selected as the access satellite, so that the access satellite sequence [(s1), (s2), …, (s n )], where for each access satellite, a corresponding set of candidate service satellite sets S can be obtained according to the QoS constraints, thereby obtaining a candidate service satellite set sequence [S1, S2, …S n ]; select a satellite from each set to form a service migration path [(x1), (x2), …, (x n )], if the adjacent elements in the sequence are the same, it means that the satellite provides services continuously and does not need to be migrated, so the adjacent and identical elements can be merged into one; at this time, the problem can be transformed into: select a service migration path so that the number of satellites contained in the path is as small as possible; Use dynamic programming to solve this problem. First, give the definition of the state. Define dp[i][j] as the number of sets in the first i with x. j is the minimum number of subsequences after deduplication in the ending sequence. For a new set Si, for each number x in it p , add the number to the current sequence; for number x p If it only occurs once, just replace the number x p Add to the current sequence and update dp[i][p] = dp[i-1][j] + 1, where j represents the number of ps in the first i-1 sets with x. j is the sequence ending with; for the number x p If the number x has already appeared in the current sequence, there is no need to p To add to the current sequence, we only need to update dp[i][p] = dp[i-1][j], which means the number of independent numbers in the sequence remains unchanged; The final answer is dp[n][j], where n represents the number of sets. We look for the minimum value in dp[n][j] by maintaining a pre array to record the predecessor state of each state. Finally, we trace back from dp[n][j] to obtain a sequence that meets the conditions. The migration path-aware task scheduling strategy converts the user's communication interval information into a directed acyclic graph, in which each node represents a satellite, including the start and end time of the user's communication with the satellite, and the weight on the node represents the time the user stays after migrating from other satellites to the satellite. The satellite is divided into multiple stages according to the start and end time of the service in the figure. The end time of satellite communication in each stage is strictly greater than the previous stage. The satellites in the stage are sorted according to the service deadline. The satellite with the latest deadline is on the optimal path. To return to the optimal path from satellites on other suboptimal migration paths, an additional migration is required within the stage. In addition, since the distance between satellites in the same stage is also relatively close, the service satellite sets that meet the QoS requirements also have intersections. Therefore, all service satellite sets in each stage can be divided into multiple non-overlapping subsets, corresponding to different satellites in the stage.

10. A satellite group management system for a satellite cloud computing Internet platform as claimed in claim 9, characterized in that: The overall architecture of the scheduling strategy simulator consists of a task generation module, an ephemeris management module, a simulation module, a scheduler module and a data processing module; The task generation module is mainly responsible for generating task loads within a period of time according to the task generation configuration provided by the user, and mapping them to the corresponding satellites; the ephemeris management module is responsible for providing satellite-related information, including the communication interval with the ground position, visible satellites, etc.; the simulation module is the core of the entire simulator, consisting of a simulation process controller and multiple satellite grouping objects. The controller drives the overall simulation process, and the satellite grouping objects are mainly responsible for simulating the grouping state, including the state of tasks within the group, adjacent groups, and satellites within the group; the scheduler module implements various scheduling strategies, and the satellite cluster process completes the simulation of task scheduling by calling the interface provided by the scheduler module; the data processing module is responsible for collecting the task operation data generated during the simulation process, and analyzing the data after the simulation is completed to help users verify the actual effect of the scheduling strategy; The implementation method of the task generation module of the scheduling strategy simulator is as follows: first, tasks are generated according to the configuration file input by the user. Since the number of task loads in each geographically divided area is different, the process of generating tasks is carried out one by one according to the geographically divided areas; the arrival time of each task is generated using the idea of ​​random sampling. First, according to the normalized load location and time distribution information, the number of tasks per hour in each area can be obtained by multiplying it by the total number of daily tasks. The average arrival interval of the tasks in the hour is obtained based on the number. Since the arrival time of the tasks obeys the Poisson distribution, the intervals between the arrivals of adjacent tasks obey the exponential distribution with λ as the parameter, where λ means the frequency of task arrival, and the value of the average arrival interval is 1 / λ. According to the idea of ​​random sampling, a set of random variables obeying the exponential distribution is generated using the average arrival interval of the tasks. This method is used to generate the arrival interval of each task in each hour, thereby determining the arrival time of the tasks; The simulation process of the scheduling strategy simulator is implemented as follows: The whole simulation process is divided into three stages: environment preparation stage, simulation stage and data processing stage; The environment preparation stage first generates the task load and satellite constellation information. The satellite constellation information generation is to generate a corresponding number of satellite objects and available resources of each satellite according to the user configuration, and group the satellites in advance according to the grouping strategy to create multiple satellite grouping objects; Secondly, since the task first arrives at the central node of each group when it is submitted, each task is assigned to a different group object according to its submission time and location, and the task-group mapping is cached. When the subsequent simulation uses the same task load set and satellite configuration, this step is skipped directly; finally, based on the geographic location and time information in the task set, the satellite communication interval information required for each low-latency service task is generated and cached in a file. The simulator can load the file into memory and search it at runtime to reduce the amount of calculation; The simulation stage adopts an event simulation mode, and puts the events that may occur in the scheduler into a priority queue sorted by time. After the simulation starts, the controller takes out the earliest event from the head of the queue in turn, steps the simulator time, and calls the processing function of the event. During the event processing process, if a new event is generated, the new event will be reinserted into the priority queue by the controller; Events in the simulator are divided into two categories: task simulation events and statistical data events; Task simulation events are mainly responsible for the simulation statistics of the task execution process. Events are responsible for statistics on cluster load and task execution status, including: JobSubmit: indicates that the task is submitted to the cluster. After the task is submitted, the controller sends the task to the scheduling module. For geographically independent computing tasks, the scheduling module selects a group according to the inter-group scheduling strategy, and then the Pod in the task is scheduled by the scheduler within the group. If the Pod is successfully started at this time, a PodFinish event is generated and inserted into the event queue. If it is not started, it is inserted into the task waiting queue of the cluster. For low-latency service tasks, the controller sends the task to the service migration management module and generates a migration path, and sends the Pod to the scheduler within the group for scheduling. Finally, a ServiceFinish event is generated and inserted into the event queue. PodFinish: indicates that the Pod execution is finished. When the Pod execution is finished, the occupied computing resources need to be released and the execution status of the corresponding task needs to be modified. ServiceFinish: indicates that the low-latency service execution is finished, all running Pods and preheated Pods corresponding to the service are cleaned up, and service execution information is counted; ServiceMigrate: indicates low-latency service migration. This event is generated by the service migration module when a task is submitted. The service migration module needs to submit the Pod to the scheduler of the corresponding group according to the next service satellite indicated by the event, and close the Pod that has completed the previous service. ResourcePoolUpdate: indicates updating the resource pool in the cluster. For the scheduling strategy, the resource pool division in the group needs to be updated in time according to the location of the satellite; UserAccessChange: indicates that the user access satellite has changed. For each low-latency service, the controller generates a series of user access change events. When processing the event, the system will count the delay between the event and the user access service during the last switching process. StatsSample: indicates the collection of cluster load status. When the system starts, it will generate this event in batches according to the interval requirements. It is used to collect cluster load information during the simulation process. After the simulation is completed, the scheduling strategy simulator generates multiple statistical data record files. The work of the data processing stage is to integrate these data into the overall execution status of the task.

Images