Satellite cloud computing internet platform satellite grouping management system

Abstract

The present disclosure provides a satellite cloud computing internet platform satellite grouping management system. It includes three modules: grouping management module, task scheduling module and low delay service migration management module, all of which run on the k3s management node k3s master. On the 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 the low delay service migration management module in the management node k3s master, and to add or delete peer relationships to the grouping management module. The API submits tasks or services to the skagent on the working node satellite. After the user's access reaches the skagent running on the working node, the skagent running on the working node forwards the user request to the corresponding module in the management node k3s master of the k3s. The skagent running on each working node is also in communication connection with the satellite distributed file system. The problem of the resource scheduling system adapting to the 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 particularly, to a satellite grouping management system for a satellite cloud computing internet platform. BACKGROUND

[0002] At present, the cloud computing resource scheduling based on the low-orbit satellite platform is still a new research field, and the related research work is still mainly based on assumption and simulation. Considering that the low-orbit satellite is more dispersed in the network topology than the data center scene, the satellite computing resource is similar to the edge scene, and the existing wide-area resource management and edge computing resource management related work can also be used as a reference. From the aspects of low-orbit satellite computing and wide-area / edge computing resource management, the related work is introduced.

[0003] The research on low-orbit satellite on-orbit computing is currently mainly focused on discussing application scenarios and future research directions, and some work has studied the service placement and arrangement problem of low-orbit satellite computing through simulation.

[0004] The work for wide-area scenarios is mainly focused on optimizing scheduling algorithms, and the placement strategy of data and computing is comprehensively considered according to the characteristics of limited bandwidth in wide-area environment and strong resource heterogeneity.

[0005] The mainstream edge task scheduling and service arrangement framework at present is mainly based on the framework simplified from Kubernetes such as KubeEdge and k3s. These frameworks basically follow the centralized design of Kubernetes and are suitable for relatively concentrated edge clusters. Such centralized design is obviously not suitable for the case of wide geographical distribution. Therefore, the edge computing mainly studies the problem of decentralization.

[0006] Problems of existing resource scheduling

[0007] 1. High-speed motion: compared with the scheduling in the fixed position data center and across data centers on the ground, the low-orbit satellite constellation is in a continuous high-speed motion state.

[0008] 2. Trajectory predictable: compared with the scene on the ground with the same motion characteristics (such as mobile edge computing), the satellite moves according to the predetermined orbit, and its trajectory can be predicted within multiple orbit periods.

[0009] 3. Difference in computing resources: due to the weaker performance of the computing load of the low-orbit satellite compared with the data center on the ground, the wide and uniform geographical distribution, and the larger inter-satellite network communication delay,

[0010] In summary: the existing resource scheduling system cannot adapt to the satellite network with wide geographical distribution and high dynamic time-varying characteristics: on the one hand, the number of satellites is huge and evenly distributed around the earth, and the existing system cannot efficiently manage satellite resources; on the other hand, the existing resource allocation strategy is difficult to adapt to the high-speed movement of satellites, and the user position distribution is uneven. SUMMARY

[0011] The embodiment of the present disclosure aims to provide a satellite grouping management system for a satellite cloud computing Internet platform. The main research goal of the present disclosure is to automatically generate code summary documents with a granularity of project level by organically combining a hierarchical model with program analysis technology. The specific object of the research is an English document, and the programming language targeted is Java. The summary document mainly reflects a short natural language summary and does not involve complex information such as directory structure, usage instructions, etc. 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 based on the model.

[0012] In one general aspect, a satellite grouping management system for a satellite cloud computing Internet platform is provided, which includes three modules: a grouping management module, a task scheduling module, and a low-latency service migration management module, all of which run on a k3s management node k3s master; the system also includes an ephemeris calculation module that provides satellite information for each module, a client skclient running on a client terminal, and an 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 the low-latency service migration management module in the management node k3s master, and to add or delete peer relationships to the grouping management module;

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

[0015] In terms of the functional aspects of each module, specifically:

[0016] The packet management module internally constructs a delay-constrained satellite packet management mechanism, and designs a geographic information-based inter-packet load balancing strategy suitable for satellite systems, constructs a packet management interface design, an adjacent packet registration mechanism and an adjacent packet state management mechanism, manages adjacent packet relationships, and collects resource states of adjacent packets; the task scheduling module is responsible for listening to user-submitted tasks, and implements three mechanism designs through task interface design, resource pool management and task scheduling, allocates computing resources or schedules to other groups for tasks according to the scheduling strategy, and simultaneously manages the resource pool; the low-delay service migration management module constructs a low-delay service migration mechanism for satellite networks, and through the design of interface, enlistment preheating mechanism and cross-group service migration mechanism, is responsible for calculating the optimal migration path according to the user location, and managing the service migration state within and between groups;

[0017] The system also includes a satellite cloud computing resource scheduling strategy simulator, which is composed 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 a 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, the visible satellite, and running on the k3s management node, 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 packet objects, the simulation process controller drives the overall simulation process, and the satellite packet object is mainly responsible for simulating the state of the packet, including the state of the task, the adjacent packet and the satellite within the packet; 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, which is implemented using Python, wherein the part related to satellite orbit and motion simulation is implemented using the python-skyfield library; the data processing module is responsible for collecting task running data generated during the simulation process, and analyzing the data after the simulation is completed, to help the user verify the actual effect of the scheduling strategy.

[0019] The specific implementation of the packet management interface design of the packet management module is as follows: first, define a PeerCluster custom resource type, the structure of the PeerCluster resource includes the unique identifier of the packet, the packet center node address, the identifier and address of the work node within the packet, and the state of the packet, and the work node is recorded through the Satellite custom type.

[0020] The specific implementation of the adjacent group registration mechanism of the group management interface design of the group management module is as follows: after the user sets the satellite information of each group through the skclient, the adjacent groups automatically discover and establish adjacent relationships through the satellite topology. First, the center node of each group calls the StartPeerDiscovery interface of the skagent on each worker node in the group. The StartPeerDiscovery interface function initiates a GetClusterSpec request to the four satellite nodes around it according to the satellite topology, and returns the aggregated 4 PeerCluster information to the center node. After the center node removes the duplicate results of each node according to the ClusterId, it adds the PeerCluster information of the non-own group to the k3s through the Create interface of the CRD. The PeerCluster resource controller will automatically update the state of the corresponding adjacent group, and start the adjacent group monitoring component to start sending heartbeats to the center node of the adjacent group.

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

[0022] When the adjacent groups complete mutual discovery, a PeerMonitor monitoring coroutine is started in each group for each adjacent group to obtain the resource state and load prediction information of the adjacent group. At the same time, each group starts a MetricAggregator program when it starts to aggregate the resource data in the own group. The PeerMonitor monitoring coroutine works in a pull information mode and periodically obtains the aggregated resource state information PeerMetric from the PeerCluster in the group except itself. To ensure the real-time nature of the information, the PeerMetric provides an external reading interface through the Kubernetes extension API mechanism.

[0023] The specific way of state interaction between groups is as follows: after the group enters the working state, the MetricAggregator obtains the resource state and load information provided by the load prediction module at a certain frequency, creates a PeerMetric object and inserts it into the local cache queue, and registers the APIServer resource with Kubernetes to expose the GetPeerMetric interface for accessing the latest data. The 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 constraint satellite group management mechanism is as follows:

[0025] First, the communication delay between satellites in the low-orbit satellite constellation is modeled: for each satellite, only two satellites in the same orbit before and after and two satellites in the same position of the adjacent orbit are communicated, the communication delay between adjacent satellites can be divided into two types: same orbit communication delay and adjacent orbit communication delay, the communication delay of non-adjacent satellites can be obtained by linear combination of the above two delays;

[0026] Given M orbital planes, N satellites on each orbital plane, the satellite network is abstracted as an M*N grid, M and N are natural numbers, and the points on the top and bottom and left and right edges of the grid are directly connected. For satellites on the same orbit, the distance D N between adjacent two satellites is:

[0027]

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

[0029]

[0030] where i is the orbital inclination of the satellite, t is assumed to be 0 when the satellite is on the equatorial plane, at this time the distance between two satellites is the farthest; by integrating the above formula and taking the average, the average distance between satellites on adjacent orbits is:

[0031]

[0032] where E is the second type of elliptic integral, divide the above distance by the speed of light c in vacuum, then the communication delay τ M and τ N between adjacent satellites can be obtained, since the constellation topology is like a two-dimensional grid, the coordinates (x, y) on the grid can be used to represent the satellites in the constellation, then it is easy to know that the communication delay τ between any two satellites (x1, y1) and (x2, y2) is the shortest hop number 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 a delay-constrained satellite grouping method: given a delay constraint T SLO , for any satellite s i , its communication delay with other satellites s jThe delay of the communication must be within the constraint, i.e. Under the condition of meeting the above constraints, the number of groups needs to be as small as possible to improve the overall resource utilization efficiency of the satellite;

[0035] A set of points R is found 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. By adding virtual nodes to normalize the distance, running the d-hop placement algorithm, and then scaling the nodes by a constant ratio, the result satisfies 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 in the scaling and rounding process, and the number of nodes in the dominating set is the number of groups. Finally, by traversing all the remaining nodes, each node is assigned to the group to which the nearest dominating node belongs.

[0036] Then the grouping calculation resource balancing strategy is constructed: first, in the process of traversing each node, temporarily ignore the nodes that can join multiple clusters or cannot join any cluster; then, the backtracking method is used to allocate clusters for the ungrouped nodes, so as to find the optimal solution under the current grouping condition; secondly, since the Torus grid is a ring topology, the determined dominating nodes are further translated on the whole grid, and the grouping is calculated for each case. Since there are at most M*N cases, the global optimal solution is obtained by exhaustive search.

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

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

[0039] Then, the geographic information and ground load density information applied by the scheduling strategy are modeled. It is assumed that users access satellites directly through ground terminals, and geographic division and traffic proportion change graph data are used as reference data. The earth's surface is divided into 72 regions with a unit of 30 degrees, the longitude range is further divided into 15 degrees, and the regions are aligned with time zones to form 144 regions. The device density index is normalized to map the task load proportion to the 144 regions. At the same time, the traffic proportion in the traffic proportion change graph is converted into the relative proportion of each time period, and the load proportion is multiplied by the corresponding time zone in the region division graph to obtain the task load proportion zoning table in each time period.

[0040] Afterwards, according to the subsatellite point trajectory of the satellites in the group, the proportion of the low-delay service task load that each satellite in the group can receive in the future is modeled by a sampling method for a certain satellite s in a group S i The proportion of the low-delay service task load in the future one satellite orbit period T is r i1 ,..., r im , where m is the sampling number, r ij is the proportion of the low-delay service task load of satellite s at time t0 i , and the subsatellite point longitude and latitude of satellite s S at time t0 i are combined with the value obtained in the dictionary described above in the time zone where the geographic coordinates are located. The load proportion R S of the entire group is the average of the load proportions of each satellite in the group. The data is converted into a histogram by calculating the interval average, where the abscissa is the discretized time period, and the ordinate is the maximum load proportion in the time period. The interval length is used as an adjustment parameter. The smaller the parameter, the higher the frequency of the resource pool size adjustment by the scheduler module, which is closer to the actual optimal load proportion, but also has a greater impact on the running tasks.

[0041] Afterwards, a dynamic resource pool partitioning strategy is constructed, including resource pool node sequencing and resource pool capacity adjustment strategies:

[0042] The resource pool node sequencing part uses a greedy algorithm to sequence all nodes so that the nodes in the resource pool are as evenly distributed as possible during the expansion and contraction process. First, a breadth-first search is used to start from the center node to divide the nodes in the group into two categories so that the nodes in the two categories are not adjacent. At this time, the distribution of nodes in each category is uniform. Afterwards, the strategy sequences the two categories of nodes. The sequencing idea is to find one unsequenced node that is closest to the average distance from all sequenced nodes and add it to the sequenced nodes. Finally, the orders of the two categories of nodes are spliced to obtain the final node order.

[0043] The resource pool capacity adjustment strategy is specifically as follows: after the node sequencing is completed, the scheduler module performs resource pool expansion or contraction operation according to the load prediction information, the expansion operation includes two aspects of node tagging and expelling the running geography-independent tasks, and the contraction operation only performs node label removal operation; when the monitoring module of the system detects that the low-latency service resource pool is insufficient in resources, or the scheduler module judges that expansion is needed according to the above load prediction information, the scheduler module performs resource pool expansion, adds labels to nodes in sequence according to the subscript of the last node in the current resource pool, until the required resource quantity requirement of expansion is reached; the scheduler module checks all running geography-independent tasks, if the task is running in the node that has been in the new resource pool, the task is marked as “to be migrated”, but only when the scheduler module selects to schedule a new low-latency service task to the node and finds that the resource is insufficient, the task will be expelled and rescheduled; when the system monitoring module finds that the task occupies resources in the resource pool is lower than the threshold, combined with the load prediction information to judge that contraction is needed, the scheduler performs resource pool contraction, at this time the scheduler removes the node labels in reverse order from the last node in the resource pool, and the scheduler can reschedule the geography-independent tasks to these nodes; the scheduler module does not actively expel the running tasks, 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 geography-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 resource remaining data and load prediction data in the future orbit period of all candidate groups through local cache or communication with adjacent groups; according to these data, the resource scheduler scores all candidate groups, the scoring formula is: W1*whether the task can be directly executed+W2*the number of remaining resources+W3*the time to 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 according to the scoring result, and adds one to the scheduling number attached to the task; if the group with the highest score is the group where the task is located, the resource scheduler directly submits the task to the local group's task queue; if the task has reached the maximum scheduling number, the last scheduling task will be directly submitted to the corresponding group's task queue.

[0045] The specific way of task interface design in the task scheduling module is that two tasks are defined in the form of CRD: a geographic position independent task ComputeJob and a low latency service task LowLatencyService, the two tasks are basically consistent in Pod description, submission time, submission location and other fields, but the ComputeJob contains the number of rescheduling times and the grouping identification information of final execution, and the LowLatencyService contains the migration process identification; the user can submit or stop the task to the system through the interface provided by the skclient, and the task only modifies the InitialSatelliteId after reaching the skagent, and then is directly submitted to the k3s central node through the Create interface provided by the CRD.

[0046] The specific way of resource pool management in the task scheduling module is that the ResourcePool custom resource is defined first, and then the workflow of the ResourcePool controller is constructed, when the group is created, each group creates the ResourcePool resource in its own k3s cluster; after the controller corresponding to the resource is started, it first requests the MetricAggregator to obtain the current cluster resource information; then the controller sorts all worker nodes according to the node sorting strategy defined by the SortPolicy, the sorting strategy includes uniformization strategy, satellite number order sorting, resource capacity sorting 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, which contains the time and the target size of the resource pool, and starts the node labeling coroutine NodeLabeler; the labeling process is to update the worker node label through the Update method of Kubernetes according to the CurrentPoolSize and CurrentLastNode information in the ResourcePool and the target size of the resource pool in the NextAdjustment according to the node identification in the NodeOrder; after updating the NextAdjustment field, the LoadWatcher coroutine regularly collects the cluster resource status information and updates it to the load prediction module.

[0047] The specific way of task scheduling implementation in the task scheduling module is that the mixed scheduling of the two tasks is realized by using the custom ComputeJob controller, LowLatencyService controller extension framework and Kubernetes controller extension framework:

[0048] The ComputeJob controller implements the scheduling of location-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 state, and the controller submits the task object in the INCOMING state to the initial scheduling queue IncomingQueue in the controller, which is implemented by 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 select the group for execution according to the load balancing strategy; if the task needs to be scheduled to other groups, the ComputeJob controller calls the Update method in the PeerCluster to submit the task to other groups, and deletes the task in the group; if the task needs to be executed in the group, the ComputeJob controller modifies the task state to PENDING; the task scheduling coroutine in the ComputeJob controller continuously polls all PENDING state tasks, and submits the unsubmitted Pod to the k3s cluster through Create, waiting for the central scheduler to schedule; when all the Pods in the task are started, the controller modifies the task state to RUNNING, and modifies the state to FINISHED until all the Pods are completed;

[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 a low-latency service, the state of the object is first marked as INCOMING state, and the controller creates a corresponding MigrationProcess object for the task object in this state, and then marks 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 marks 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 objects in the SERVING state until their state changes to FINISHED, and deletes the running Pod and MigrationProcess object;

[0051] The extension framework of the Kubernetes controller extends the central scheduler so that it can distinguish between 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 between two types of tasks according to labels in the Pods and arrange the Pods of low-latency service tasks in the 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 two types of Pods; for low-latency service tasks, if no suitable node is selected in the Filter stage, the extension framework of the Kubernetes controller enables the scheduler to attempt to evict part of the geographically independent 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 sort and score nodes for low-latency service task Pods according to the access satellite information provided by the MigrationProcess through the strategy in the previous chapter.

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

[0053] The MigrationProcess custom resource is defined, the PrevProcess and NextProcess point to the MigrationProcess objects of the task in other groups, and the Path field contains a list composed of PathNode, 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 node current state, since the nodes on the migration path are only partially 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 calculates the communication interval in the future according to the user's location using the ephemeris calculation module, and creates a Path according to the path selection algorithm; when the first PathNode in the Path points to the current group, the controller will modify the state of the task object, and submit the Pods 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 Pods corresponding to the previous PathNode, and schedule new Pods 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.

[0055] The service preheating mechanism in the low-latency service migration management module specifically introduces the concept of a service preheating window 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 the service state, and the satellite corresponding to this node is providing services for users. The PathNode immediately following is in the preheating state, and the satellite corresponding to this node needs to pre-start the Pod of the corresponding service, waiting for the user to directly access after migration. The other PathNodes within the window are in the environment preparation state, and the satellites corresponding to these nodes need to create MigrationProcess objects in advance and prepare the environment required for starting the Pod, such as pulling container images. The PathNodes outside the window are in the waiting state, and the satellites corresponding to these nodes do not need to perform any operations temporarily. When the PathNode in the service state in the window reaches the service deadline, the entire service preheating window moves one node backward. At this time, the MigrationProcess controller corresponding to the PathNode that has just ended sends window updates to the controllers of the PathNodes in the subsequent window in a chain-like manner. The controller of the PathNode at the end of the previous window needs to create a MigrationProcess object in the corresponding group based on the information of the new end PathNode after receiving the update information, and complete the movement of the window.

[0056] The construction method of the cross-group service migration mechanism in the low-latency service migration management module specifically includes:

[0057] The cooperation between the MigrationProcess controllers between groups enables smooth migration of tasks between groups.

[0058] When the end PathNode 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 Path information to the NextProcess through the Update interface. If the newly created MigrationProcess object finds that there is no corresponding LowLatencyService object in the group, it supplements the creation of the object and adjusts its state.

[0059] If the preheating stage Pod cannot be started due to insufficient resources and other problems, the controller needs to regenerate the migration path when selecting a satellite outside the optimal service satellite set; at this time, the MigrationProcess controller needs to first send the new Path information to the PrevProcess, and update the information according to the newly generated subsequent PathNode, so as to realize the update of the entire migration path;

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

[0061] The low-delay service migration path selection uses QoS constraints to constrain the delay between the user access satellite and the satellite providing services, thereby reducing the service migration frequency while ensuring service quality.

[0062] Given the user's location (lat u , lon u ), in a future period T from the user's task submission time t0, the satellite entering the user's communication range and its communication interval set in [t0, t0+T) are calculated by the SGP4 orbit model; first, select the satellite with the longest communication duration at the current time of the user as the access satellite, so that the access satellite sequence [(s1), (s2),..., (s n )] changing with time can be obtained, wherein for each access satellite, a corresponding set of candidate service satellite sets S can be obtained according to the QoS constraint, thereby obtaining the candidate service satellite set sequence [S1, S2,... S n ]; selecting one 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 continuous service and does not need to be migrated, so adjacent and same elements can be combined into one; at this time, the problem can be converted to: select a service migration path, so that the number of satellites contained in the path is only possible to be less;

[0063] The dynamic programming method is used to solve the problem, first the definition of state is given, define dp[i][j] as the minimum subsequence number after removing duplicates in the sequence ending with x j i in the first i sets, for a new set Si, for each number x p , add the number to the current sequence; for the case where the number x p appears only once, directly add the number x pis added to the current sequence and dp[i][p] is updated as dp[i-1][j]+1, where j represents the sequence ending with x in the previous i-1 sets; for the number x j is added to the current sequence and dp[i][p] is updated as dp[i-1][j]+1, where j represents the sequence ending with x in the previous i-1 sets; for the number x p is added to the current sequence and dp[i][p] is updated as dp[i-1][j]+1, where j represents the sequence ending with x in the previous i-1 sets; for the number x p is added to the current sequence and dp[i][p] is updated as dp[i-1][j]+1, where j represents the sequence ending with x in the previous i-1 sets; for the number x

[0064] The final answer is dp[n][j], where n represents the number of sets, and the minimum value in dp[n][j] is sought, and a pre array is maintained to record the predecessor state of each state, and finally a sequence meeting the conditions is obtained by backtracking from dp[n][j].

[0065] The migration path-aware task scheduling strategy converts the user's communication interval information into a directed acyclic graph, where each node represents a satellite and contains the start and end times of the user's communication with the satellite, and the weight on the upper edge of the node represents the time the user stays after migrating from other satellites to the satellite. The satellites are divided into multiple stages according to the start and end times of the service in the graph, and the communication end time of the satellites in each stage is strictly greater than that of the previous stage. The satellites are sorted according to the service deadline in each stage, and the satellite with the latest deadline is located on the optimal path. If the satellite is returned to the optimal path from other suboptimal migration paths, it needs to be migrated once more in the stage. In addition, since the satellites in the same stage are also close in distance, the sets of service satellites that meet the QoS requirements also have intersections, so the sets of service satellites in each stage can be divided into multiple disjoint subsets, corresponding to different satellites in the stage.

[0066] The overall architecture of the scheduling strategy simulator is composed 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 communication intervals with ground locations, visible satellites, etc. The simulation module is the core of the entire simulator, composed of a simulation process controller and multiple satellite grouping objects. The controller drives the overall simulation process, while the satellite grouping objects are mainly responsible for simulating the grouping state, including the state of tasks, 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 interfaces provided by the scheduler module. The data processing module is responsible for collecting task running 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 mode of the task generation module of the scheduling strategy simulator is: first, generating tasks according to the configuration file input by the user, and since the number of tasks in each geographical division area is different, the task generation process is carried out in each geographical distribution division area; the arrival time of each task is generated by using the idea of random sampling, first, the number of tasks per hour in each area can be obtained by multiplying the normalized load position and time distribution information by the total number of daily tasks, the average arrival interval of tasks in the hour is obtained according to the number, since the arrival time of the task obeys the Poisson distribution, the interval between adjacent tasks obeys 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, a set of random variables obeying the exponential distribution is generated by using the average arrival interval of the task, and the arrival interval of each task in each hour is generated by using this method, so as to determine the arrival time of the task.

[0069] The implementation mode of the simulation process of the scheduling strategy simulator is:

[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, that is, according to the user configuration, a corresponding number of satellite objects and available resources of each satellite are generated, and the satellites are grouped in advance according to the grouping strategy, and a plurality of satellite grouping objects are created; secondly, since the task is submitted to the center node of each group first, this stage allocates each task to different grouping objects according to its submission time and place, and caches the task-grouping mapping, when the same task load set and satellite configuration are used in subsequent simulation, the step is directly skipped; finally, according to the geographical position and time information in the task set, the satellite communication interval information required by each low-delay service task is generated and cached in a file, and the file is loaded into the memory by the runtime simulator and searched, so as to reduce the calculation amount;

[0072] The simulation stage adopts the mode of event simulation, and possible events in the scheduler are put into a priority queue sorted by time, and the controller takes out the event with the earliest time from the head of the queue after the simulation starts, steps the simulator time, and calls the processing function of the event, and in the event processing process, if a new event is generated, the new event will be re-inserted into the priority queue by the controller;

[0073] The events in the simulator are divided into two categories: task simulation events and statistical data events; the task simulation event is mainly responsible for the simulation of the task execution process, and the statistical data event is responsible for the statistics of the cluster load and the task execution condition, which specifically includes:

[0074] JobSubmit: indicates task submission to the cluster, after task submission, the controller sends the task to the scheduling module, for a geography-independent computing task, the scheduling module selects a group according to the inter-group scheduling strategy, and then the task in the Pod is handed over to the intra-group scheduler for scheduling. If the Pod is successfully started at this time, a PodFinish event is generated and inserted into the event queue, and if it is not started, it is inserted into the task waiting queue of the cluster. For a low-latency service task, the controller sends the task to the service migration management module and generates a migration path, and sends the Pod to the intra-group scheduler for scheduling, and finally generates a ServiceFinish event and inserts it into the event queue;

[0075] PodFinish: indicates the end of Pod execution, and the occupied computing resources need to be released after the end of Pod execution, and the execution state of the corresponding task is modified;

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

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

[0078] ResourcePoolUpdate: indicates updating the resource pool in the cluster, for the scheduling strategy, the resource pool partitioning in the group needs to be updated in time according to the position of the satellite;

[0079] UserAccessChange: indicates user access satellite change, for each low-latency service, the controller will generate a series of user access change events, and when processing the event, the system will count the delay of the user access service in the last switching process;

[0080] StatsSample: indicates collecting the load state of the cluster, the system will generate a batch of events according to the interval requirement at the start time, which is used to collect the load information of the cluster in the simulation process;

[0081] After the simulation is finished, the scheduling strategy simulator generates a plurality of statistical data record files, and the work of the data processing stage is to integrate these data into the execution status of the task as a whole.

[0082] The embodiment of the application has the following innovations:

[0083] The present application solves the problem of adapting the resource scheduling system to the satellite network with wide geographical distribution and high dynamic time-varying characteristics, and based on the Kubernetes platform, a scheme for efficiently managing resources and adapting to the satellite scenario is realized, and is deployed on a satellite computing simulation platform composed of multiple lightweight virtual machines, and the inter-satellite network is simulated through external network traffic control. Users can submit tasks to the prototype platform to observe the state of load balancing and service migration. BRIEF DESCRIPTION OF DRAWINGS

[0084] The above and other objects and features of the present disclosure will become more apparent from the following description of the embodiments given for the purposes of a better understanding based on the accompanying drawings.

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

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

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

[0088] Figure 4 is a schematic diagram of a process of updating the state of an adjacency grouping according to an embodiment of the present disclosure;

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

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

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

[0092] The following detailed description is provided to help the reader understand the method, device and / or system described herein. However, various changes, modifications and equivalents can be made to the method, device and / or system described herein after understanding the disclosure of the present application. For example, the order of the operations described herein is only an example and is not limited to those set forth herein, but can be changed as will be clear after understanding the disclosure of the present application, except for the operations that must occur in a specific order. In addition, the description of features known in the art can be omitted for the sake of clarity and brevity.

[0093] The features described herein can be implemented in different forms and should not be construed as limited to the examples described herein. Rather, these described examples have been provided as an example of carrying out the methods described herein, devices, and / or systems described herein, some of the many possible ways of implementing these methods, devices, and / or systems as will be apparent after an understanding of the disclosure.

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

[0095] Although terms such as "first", "second", and "third" can be used herein to describe various elements, components, regions, layers or sections, these elements, components, regions, layers or sections should not be limited by these terms. Rather, these terms are only used to distinguish one element, component, region, layer or section from another element, component, region, layer or section. Thus, the first element, first component, first region, first layer or first section referred to in the examples described herein can also be called a second element, second component, second region, second layer or second section without departing from the teachings of the examples.

[0096] In the description, when an element such as a layer, a region, or a substrate is described as "on" another element, "connected to" or "coupled to" another element, it can be "directly on" the other element, "directly connected to" or "directly coupled to" the other element, or one or more other elements can be interposed therebetween. In contrast, when an element is described as being "directly on" another element, "directly connected to" or "directly coupled to" another element, there can be no other element interposed therebetween.

[0097] The terminology used herein is for the purpose of describing various examples only and is not intended to be limiting of the disclosure. Singular forms are intended to include plural forms unless the context clearly indicates otherwise. The terms "comprises", "includes", and "has" specify the presence of stated features, numbers, operations, components, elements, and / or combinations thereof, but do not preclude the presence or addition of one or more other features, numbers, operations, components, elements, and / or combinations thereof.

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

[0099] Moreover, in the description of the examples, detailed descriptions of related structures or functions that are considered to be perfunctory in the case where it is deemed that such detailed descriptions will cause obscuring of the present disclosure will be omitted.

[0100] Figure 1 is a schematic diagram showing a satellite cloud computing internet platform satellite grouping management system 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 application is developed based on the most popular resource management framework Kubernetes in the current cloud native field. Based on the grouping scheduling architecture proposed by the present application, resources are managed by a centralized scheduler within each group, so the system can fully utilize the existing implementation of resource management 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 application can be easily introduced. Considering the limited resources of satellites, the present application develops k3s, a Kubernetes distribution optimized for edge computing. The overall architecture of the system is shown in Figure 1 .

[0103] The satellite cloud computing resource management system implemented by the present application includes three main modules: grouping management module, task scheduling module, and low-latency service migration management module. The above three modules are all running on the k3s management node k3s master. The grouping management module is mainly responsible for managing the adjacent grouping (Peer) relationship and collecting the resource state of the adjacent grouping. The task scheduling module is responsible for listening to the tasks submitted by the user, allocating computing resources or scheduling to other groupings according to the scheduling strategy, and at the same time, 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 location and managing the service migration state 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 worker node satellite. The ephemeris management module also runs on the k3s management node, responsible for providing user communication interval information required by the scheduling algorithm, while maintaining the current satellite position information of the grouping. The skclient accesses the API provided by the system through the remote procedure call framework gRPC, which is used to manage satellite groupings, submit tasks, etc.; since the actual communication satellite of the user is the worker node with a large probability, the user's access mainly reaches the skagent running on the worker node, which is responsible for forwarding the user's request to the corresponding module in the central node.

[0104] Grouping management module:

[0105] The packet management module is the basis for the entire system to achieve packet management. Its functions mainly include the following parts: 1) providing packet control functions for users, including searching or updating the current packet management nodes and other adjacent packet information; 2) providing adjacent packet registration functions, other packets register to become adjacent packets of the current packet through this mechanism; 3) providing adjacent packet state management functions for the scheduler, including collecting resource information of nodes in the current packet, sending heartbeats to other packets, and collecting resource information of other packets.

[0106] (1) Packet management interface design:

[0107] The packet management module first defines a PeerCluster custom resource type (CRD). Since each packet has the same status in the system, the information of the local packet can also be recorded through this type. The structure of the PeerCluster resource is shown in Table 1, which includes the unique identifier of the packet, the address of the packet center node, the identifier and address of the work node in the packet, and the state of the packet. The work 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 corresponding resource controller listens to the resource information changes and performs corresponding operations. To make user operations convenient, skclient encapsulates interfaces for adding, deleting, modifying, and querying PeerCluster resources. Users only need to provide satellite packet description file information, and skclient can modify the resources by accessing the PeerCluster resource interface.

[0113] (2) Adjacent packet registration mechanism:

[0114] After the user sets the satellite information of each packet through skclient, adjacent packets can automatically discover and establish adjacent relationships through satellite topology. The specific process is as follows Figure 3The center node of each group calls the StartPeerDiscovery interface of the skagent on each worker node within the group. According to the satellite topology, the interface function initiates a GetClusterSpec request to the four satellite nodes around it, and returns the aggregated 4 PeerCluster information to the center node. After deduplication of the returned results of each node according to the ClusterId, the center node 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 state of the corresponding adjacent group and start the adjacent group monitoring component to start sending heartbeats to the center node of the adjacent group.

[0115] (3) Adjacent group state management mechanism:

[0116] When the adjacent groups complete the discovery of each other, a PeerMonitor monitoring coroutine will be started for each adjacent group within each group to obtain the resource state and load prediction information of the adjacent group. At the same time, each group will also start a MetricAggregator program when starting to aggregate the resource data within the self group. The PeerMonitor monitoring coroutine works in a pull information mode and periodically obtains the aggregated resource state information PeerMetric from the PeerCluster within the group except itself. To ensure the real-time nature of the information, PeerMetric, although also a CRD, provides a separate external reading interface through the Kubernetes extension API mechanism. The specific definition is shown in Table 3.

[0117] In the above information, nodeMetric and PeerMetric are defined similarly, including four {uint64, uint64} structures, respectively corresponding to total available, in use, Pod application resources and Pod resource limits. The two uint64 values represent CPU and memory resource quantities, respectively, 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 4The MetricAggregator obtains the resource status of the current cluster and the load information provided by the load prediction module at a certain frequency after the group enters the working state, creates a PeerMetric object and inserts it into the self-cache queue, and at the same time registers the APIServer resource of Kubernetes, exposes the interface GetPeerMetric for accessing the latest data. The PeerMonitor obtains the PeerMetric structure of the adjacent group by polling the GetPeerMetric interface exposed by the adjacent group, and finally calls the Update interface to update the local CRD record.

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

[0122] Satellite networks differ from any existing scenario on the ground in terms of geographical distribution and hardware environment: compared with the cloud environment, the geographical distribution of satellites is extensive, the average delay between any nodes is larger, the node performance is weaker and has heterogeneity; compared with the edge environment and the wide area environment, the network topology between satellites is relatively stable, and the bandwidth resources are relatively sufficient. In this scenario, a centralized architecture cannot be used to organize all nodes because the delay difference between two satellites is too large, and a hybrid architecture cannot be applied. The present application proposes a satellite group management mechanism that utilizes the delay constraint of satellite communication, cooperatively considers resource distribution factors, divides the satellite network into multiple groups, and thus realizes a resource scheduling mode of centralized scheduling within the group and collaborative work between groups.

[0123] Satellite communication delay modeling

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

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

[0126]

[0127] where r ER is the radius of the earth, h is the orbit height. Since the distance between two adjacent orbit satellites varies periodically with the orbit period T, the distance between two satellites in adjacent orbits at a given time t∈[0, T) is:

[0128]

[0129] where i is the orbit inclination of the satellite. The distance between two satellites is the largest when t is 0, which is assumed to be the time when the satellite is in the equatorial plane. The average distance between two satellites in adjacent orbits can be obtained by integrating the above equation and taking the average:

[0130]

[0131] where E is the second kind of elliptic integral. The communication delay τ M and τ N between two adjacent satellites can be obtained by dividing the above distance by the speed of light c in vacuum. Since the constellation topology is like a two-dimensional grid, the coordinates (x, y) on the grid can be used to represent 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 hop distance 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 the delay constraint τ SLO , the goal of the present application is to group any satellite s i with other satellites s j in the same group such that the communication delay between them must be within the constraint, 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 a d-hop dominating set problem in a Torus network, that is, finding a set of points R in the grid such that the distance (hop number) from any point in the grid to a point in R is less than or equal to d. As long as a dominating set consisting of n nodes can be found in the grid with a d-hop constraint, and the remaining nodes are added to the set of points centered on each point in the set, n groups can be obtained, and the communication delay between any two satellites in the group is less than 2d. Since the communication time in the same orbit and across the orbit in the satellite network is different, the present application normalizes the distance by adding virtual nodes, and then scales the nodes by a constant ratio after running the d-hop placement algorithm. The resulting result satisfies the distance from each node to the dominating set node is less than or equal to d+∈, wherein ∈ is the error generated in 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 assigned to the group to which the nearest dominating node belongs.

[0136] Grouping resource balancing strategy

[0137] The above grouping method can guarantee the delay constraint within the group, but does not consider the heterogeneous characteristics of satellite resources. Specifically, the computing power of each satellite can be abstracted as two resources [cpu, mem], and for K groups, the resource skewness index Φ = Var(∑cpu(S i ))+Var(∑mem(S i )) can be calculated, which is the sum of the variances of the total resources of each group. The index needs to be minimized to make the resources of each group as evenly distributed as possible. The present application uses two strategies to further achieve resource balancing. First, in the process of traversing each node, temporarily ignore the nodes that can be added to multiple clusters or cannot be added to any cluster (line 29); then the backtracking method can be used to assign clusters to the ungrouped nodes (lines 1-21), thereby finding the optimal solution under the current grouping condition. Second, since the Torus grid is a ring topology, the determined dominating nodes can be further translated on the overall grid, and the grouping is calculated separately for each case. Since there are at most M*N cases, the global optimal solution can be obtained directly by exhaustive search (lines 26-39). The pseudo code 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: low-latency service load requires user access delay to be as low as possible, and the service users are mostly concentrated in the land area; the geographic-independent computing task load is not sensitive to delay and geographic location. Considering that the satellite is uniformly distributed around the earth and moves at high speed, in the satellite grouping scenario, due to the uneven distribution of task submission positions, it may cause uneven load among groups and cannot fully utilize the satellite computing resources. In addition, the competition for resources between the two types of tasks may also cause user service degradation. Therefore, the present application utilizes the predictability of the satellite motion trajectory, combines the geographic location information and load prediction information to dynamically adjust the resource allocation in each group, and proposes a task load balancing strategy among groups, which improves the utilization of computing resources without affecting the QoS of low-latency service.

[0142] Firstly, the present application defines the task parameters running on the low-orbit satellite computing platform in detail. 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 attached with the satellite information where the task is initially submitted, recorded in the coordinates of the satellite in the constellation. The low-latency service type task also contains the location information of the ground user, recorded in latitude and longitude. Finally, each task also contains 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 accesses the satellite directly through the ground terminal, the load density of users in different areas on the ground depends on population density, economic conditions and other factors. Considering that the initial value of the area division and the load does not affect the algorithm process, and can be corrected as the system runs, the present application adopts the geographic division and traffic proportion change chart data as the reference data, divides the earth surface into 72 regions with 30 degrees as the unit, the present application further divides the longitude range with 15 degrees as the unit, and aligns the regions with the time zone to form 144 regions, and normalizes the device density index to map the task load proportion into the 144 regions. At the same time, the present application converts the traffic proportion in the traffic proportion change chart into the relative proportion of each time period, multiplies the load proportion in the area division chart according to the corresponding time zone, to obtain the task load proportion zoning table in each time period. Since the table only contains 144*24=3456 data, the whole table can be directly stored in a dictionary with (longitude index, latitude index, UTC time) as the key.

[0146] After abstracting the above information, this invention models the change in the proportion of ground low-latency service tasks that each group may receive over a future period of time based on the nadir trajectories of satellites within a group, using a sampling method. Specifically, for each satellite s within a certain group S... i Starting from the same time t0, the proportion of low-latency service tasks within a future satellite orbital 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 nadir point are combined with the time zone of the geographic coordinates and retrieved from the dictionary mentioned above. The load ratio R of the entire group. S This represents the average load ratio of each satellite within a group. Based on the above method, the trend data of the low-latency service task ratio of each group over time can be obtained. To facilitate the scheduler's decision-making based on this data, this invention converts the data into a histogram by calculating the interval mean, where the horizontal axis represents the discretized time period, and the vertical axis represents the maximum load ratio within that time period. Furthermore, the interval length is an adjustable parameter; the smaller this parameter, the more frequently the scheduler adjusts the resource pool size, closer to the actual optimal load ratio, but the greater the impact on running tasks.

[0147] Dynamic partitioning strategy for computing resource pools

[0148] Based on the aforementioned load ratio information, a common resource management strategy is to divide resource pools for different task types. Each task type uses resources from its own pool, and the size of the two pools is dynamically adjusted when the load ratio changes or is about to change. According to the load information modeled earlier, the low-latency service load in satellite networks can be divided into an increasing and decreasing phase, corresponding to the expansion and contraction phases of the low-latency service resource pool, respectively. During the expansion phase, nodes belonging to geographically unrelated task resource pools need to be moved to the low-latency service resource pool; the contraction phase does the opposite. Since there are only two resource pools, a single label can be used to distinguish between the two types of nodes based on whether a node belongs to the low-latency service resource pool. The expansion process involves adding labels to nodes within a group in a certain order, while the contraction process involves removing labels in the reverse order. Based on these conditions, this invention proposes a dynamic partitioning strategy for computing resource pools oriented towards satellite network topology, comprising two parts: resource pool node sorting and resource pool capacity adjustment strategies.

[0149] Considering that in the ground scene, the resources can be arbitrarily divided into different resource pools since the nodes are located in the data center of the network cluster, and there is no need to consider the location problem between nodes. In the satellite scene, since the satellite network is distributed in a grid shape, and the satellite position is related to the user access position, the satellites in the low-delay service task resource pool should be as evenly distributed as possible in the entire grid. Therefore, the application adopts a greedy algorithm to sequence all nodes, so that the nodes in the resource pool are as evenly distributed 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 from the center node (lines 1-20), so that the two categories of nodes are not adjacent to each other. This situation is similar to the case when the number of nodes in the two resource pools is similar, at this time the distribution of each category of nodes is uniform. Then, the strategy sequences the two categories of nodes. The idea of sequencing is to find one of the unsequenced nodes that is closest to the average distance from all sequenced nodes, and add it to the sequenced nodes (lines 24-37). Under this idea, the distance between the selected new node and the sequenced nodes will not be too far or too close. Finally, the orders of the two categories of nodes are spliced, and the final node order is obtained (lines 38-42).

[0154] After the node sequencing is completed, the scheduler can perform resource pool expansion or contraction operation according to the load prediction information. The expansion operation includes two aspects of node tagging and expelling the running geography-independent tasks, and the contraction operation only performs node tag removal operation. When the monitoring module of the system detects that the low-latency service resource pool is insufficient in resources, or the scheduler judges that expansion is needed according to the above load prediction information, the scheduler performs resource pool expansion, adds tags to the nodes in order according to the subscript of the last node in the current resource pool, until the required resource quantity requirement of the expansion is reached. In addition, the scheduler will check all running geography-independent tasks, if the task is running in the node that has been in the new resource pool, the task will be marked as “to be migrated”, but only when the scheduler selects to schedule a new low-latency service task to the node and finds that the resource is insufficient, the task will be expelled and rescheduled. When the system monitoring module finds that the task occupies resources in the resource pool is lower than the threshold, combined with the load prediction information to judge that contraction is needed, the scheduler performs resource pool contraction, at this time the scheduler removes the node tags in reverse order from the last node in the resource pool, and the scheduler can reschedule the geography-independent tasks to these nodes. Considering that the low-latency service migration frequency is high, the scheduler will not actively expel the running tasks, 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 at the same time minimize the impact on running tasks.

[0155] Inter-group task load balancing strategy

[0156] On the basis of the above low-latency service load information and resource pool dynamic division mechanism, the present application further realizes load balancing by scheduling geography-independent tasks between groups. This strategy adopts a hierarchical scheduling idea: each geography-independent task needs to be initially scheduled at the group level when submitted to a certain satellite group, and then assigned to the group computing resources by the scheduler in the group after a certain execution group is determined. To implement this strategy, the maximum scheduling number parameter needs to be added to the geography-independent task, so that the task can be scheduled to a more idle group. The pseudo code of this strategy is as follows:

[0157] Table 6 Inter-group load balancing strategy pseudo code

[0158]

[0159] When a task is submitted to a satellite group, the resource scheduler of this group selects itself and its adjacent groups as candidate groups, and obtains the resource remaining data and the load prediction data of all candidate groups within the next orbit period through local cache or communication with adjacent groups. According to these data, the scheduler scores all candidate groups according to the following formula: W1*whether the task can be directly executed+W2*the amount of remaining resources+W3*the time to the next resource pool expansion+W4*whether the task is located in the current group (lines 1-7, 15-18). The scheduler submits the task to the group with the highest score and increases the scheduling number of the task by one. If the group with the highest score is the group where the task is located, the scheduler directly submits the task to the local group's task queue (lines 21-26). If the task has reached the maximum scheduling number, the last scheduling task will be directly submitted to the corresponding group's task queue (lines 10-13). Through the above strategy, 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 future idle computing resources.

[0160] Task scheduling module:

[0161] The task scheduling module is the core of the entire satellite cloud computing resource scheduling system, and is responsible for the following functions: 1) providing two task submission and deletion interfaces for users; 2) resource pool management, mainly responsible for dividing the resource pool according to ephemeris calculation and load prediction data, i.e. adding / removing labels to the worker nodes in order; 3) implementing a hierarchical task scheduling mode, including a task inter-group scheduling interface and a scheduler extension plug-in for implementing Pod scheduling within a 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: location-independent task ComputeJob and low-latency service task LowLatencyService. The definitions of the two tasks are shown in Table 7 and Table 8, respectively. As can be seen from the tables, the two tasks are basically the same in Pod description, submission time, submission location, etc. However, ComputeJob contains the number of rescheduling times and the final execution group identifier information, while LowLatencyService contains the migration process identifier. The details of MigrationProcess will be described in the low-latency service management section.

[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 the skclient. Once the task reaches the skagent, it only modifies the InitialSatelliteId, and then directly submits it to the k3s central node through the Create interface provided by the 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 node sorting and node labeling according to the sorting. This module is still implemented in the mode of CRD and custom controller. The definition of ResourcePool custom resource is shown in Table 9.

[0171] Table 9 ResourcePool resource description

[0172]

[0173] The workflow of ResourcePool controller is shown in Figure 5 When the group is created, a ResourcePool resource will be created in the k3s cluster of each group. After the controller corresponding to this resource is started, it first requests the MetricAggregator module mentioned in the previous chapter to obtain the current cluster resource information. Then the controller sorts all worker nodes according to the node sorting strategy defined in SortPolicy. In addition to the uniformization strategy mentioned in the previous chapter, the sorting strategy also includes sorting by satellite number order and sorting by resource capacity. After sorting, the controller updates the NextAdjustment field containing the target size of the resource pool and the time 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 labels of worker nodes in order according to the node identifier in NodeOrder through the Update method of Kubernetes, according to the CurrentPoolSize and CurrentLastNode information in ResourcePool and the target size of the resource pool in NextAdjustment. After updating the NextAdjustment field, the LoadWatcher coroutine also regularly collects cluster resource information and updates it to the load prediction module.

[0174] (3) Task scheduling implementation:

[0175] In combination with the inter-group task load balancing strategy and the path-aware low-latency service task scheduling strategy described above, the application implements hybrid scheduling of the two tasks using a custom controller and the Scheduler Framework of Kubernetes.

[0176] The ComputeJob controller is mainly responsible for scheduling tasks regardless of geographical location and cross-group load balancing. When a user submits a ComputeJob object through the skclient, the state of the object is first marked as INCOMING. The controller submits the task object in the INCOMING state to the initial scheduling queue IncomingQueue in the controller. This queue 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 a group for execution according to the load balancing strategy described above. If the task needs to be scheduled to another group, the controller will call the Update method in the PeerCluster to submit the task to the other group and delete the task in the current group. If the task needs to be executed in the current group, the controller will modify the task state to PENDING. The task scheduling coroutine in the controller will continuously poll all PENDING state tasks and submit the Pods that have not been submitted to the k3s cluster through Create, waiting for the central scheduler to schedule. When all the Pods in the task are started, the controller will modify the task state to RUNNING and modify the state to FINISHED when all the 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 a low-latency service, the object state is first marked as INCOMING. The controller will create a corresponding MigrationProcess object for the task object in this state and then mark it as PENDING. At this time, the controller only needs to wait for the MigrationProcess controller to submit the Pods to the central scheduler and mark the corresponding task object as SERVING, indicating that the task Pods are being scheduled in the cluster. The controller needs to continuously poll the task objects in the SERVING state until their state changes to FINISHED, and then delete the running Pods and MigrationProcess objects. From this process, it can be seen that the LowLatencyService controller is only responsible for managing the state of the task and cleaning up when the task is finished, and does not care about the startup and migration process of the Pods.

[0178] Since the unit that the final scheduling executes in Kubernetes is a Pod, the default scheduler does not know the task type corresponding to the Pod, and therefore the application extends the central scheduler based on the scheduler framework of Kubernetes, so that the central scheduler can distinguish between 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 application extends the QueueSort, Filter, PostFilter and Score plugins in the above table. In the QueueSort stage, the scheduler distinguishes between two types of tasks according to the labels in the Pod, and arranges the Pods of low-latency service tasks in the front to ensure that the user QoS is not affected. In the Filter stage, the scheduler selects nodes in different resource pools for two types of Pods. For low-latency service tasks, if no suitable node is selected in the Filter stage, the scheduler will try to evict part of the geographically independent task Pods to release resources in the PostFilter stage, and notify the resource pool management module to record the load conflict information. In the Score stage, the scheduler will score the nodes for low-latency service task Pods according to the access satellite information provided by the MigrationProcess through the strategy in the previous chapter. By using the above plugins, the scheduling strategy described in the application 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 for implementing the low-latency service migration strategy. The main functions of this module include: 1) generating a migration path for the low-latency service submitted by the user, and continuously updating the path as the service runs; 2) controlling the start and stop of low-latency service Pods within a group; 3) providing a service warm-up mechanism.

[0184] (1) Interface design

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

[0186] Table 11 MigrationProcess resource description

[0187]

[0188] In the above definition, PrevProcess and NextProcess point to the MigrationProcess objects corresponding to the task in other groups, respectively. This design makes the MigrationProcess objects in multiple groups belonging to the same task form a doubly linked list, which is mainly used to implement service migration across groups. In addition, the Path field contains a list of PathNodes, representing the optimal migration path calculated by combining the user's location and the user's access satellite. Each PathNode represents a node on the path, containing 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 part of the nodes on the migration path are located within the group, the PathNode information corresponding to the current group also needs to be recorded.

[0189] When the user submits a low-latency service task, the LowLatencyService object automatically creates the first MigrationProcess object. Subsequently, the MigrationProcess controller uses the ephemeris calculation module to calculate the communication interval for a future period of time based on the user's location, and creates a Path based on the path selection algorithm described earlier. When the first PathNode in the Path points to the current 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 warm-up mechanism:

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

[0192] When the PathNode in the service state in the window reaches the service deadline, the entire service warm-up window moves one node backward, and at this time the MigrationProcess controller corresponding to the PathNode that has just ended sends window updates to the controllers of the PathNodes in the subsequent window in a chain-like manner. The controller of the PathNode at the end of the previous window needs to create a MigrationProcess object in the corresponding group according to the information of the new end PathNode after receiving the update information, and complete the movement of the window.

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

[0194] Since the satellites on the migration path may belong to different groups, and the scheduler in the group cannot directly schedule tasks to the satellites of other groups. The application introduces a cross-group service migration mechanism to make the task migrate smoothly between groups through the cooperation of the MigrationProcess controllers between groups.

[0195] In combination with the pre-warming window mechanism in the previous subsection, when the last PathNode of the window corresponds to a satellite that 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 the controller and the new object, which is similar to adding a node at the end of a linked list. At the same time, the controller also needs to send its Path information to the NextProcess through the Update interface. The newly created MigrationProcess object will supplement the creation of an object and adjust its state if it finds that there is no corresponding LowLatencyService object in the group.

[0196] Under normal circumstances, as the window moves backward, only the previous group needs to pass the Path information to the subsequent group. However, if the pods in the pre-warming phase cannot be started due to resource shortages or other problems, the controller needs to regenerate the migration path when selecting a satellite outside the optimal service satellite set. At this time, the controller needs to first send the new Path information to the PrevProcess, and update the information according to the newly generated subsequent PathNode, so as to realize the update of the entire migration path.

[0197] (3) Low-latency service migration mechanism in satellite network

[0198] Since low-latency services are strongly related to geographic location, frequent inter-satellite migration is needed to meet QoS. Existing inter-satellite service migration strategies only consider the delay impact, but this leads to very frequent service migration, and multiple services migrate at the same time, which also causes contention for resources. At the same time, under the premise of grouping satellites, each service needs to migrate between groups, and the scheduling nodes of different groups need to work together. Therefore, the present application designs a migration path selection strategy for QoS and migration cost optimization using the characteristics of satellite movement direction, and designs a service cross-group migration mechanism based on this, which reduces the service migration cost while ensuring service quality.

[0199] Low-latency service migration path selection:

[0200] Given the user's location and starting time, the user's communicable satellites and communication intervals in the future can be calculated through the satellite's movement trajectory. A simple strategy is to constantly select the satellite closest to the user to deploy the task, under which strategy the user's access to the service has the lowest delay, but the cost is a higher service migration frequency. The present application proposes a scheme that uses QoS constraints instead of optimal distance, by constraining the delay between the satellite the user accesses and the satellite that provides the service, while reducing the service migration frequency, the service quality is guaranteed.

[0201] Given the user's location (latu , Ion u ), in the future time T from the user submits the task time t0, through the SGP4 orbit model can be calculated [t0, t0+T) into the user's communication range of satellite and its communication interval set. As shown in Figure 4 To reduce the user's overhead caused by frequent switching access satellite, first of all, the user should select the current time of the longest satellite communication duration as the access satellite, so that we can get the access satellite sequence [(s1), (s2),..., (s n )] (as shown in the blue node in the figure). Wherein for each access satellite, we can get a corresponding set of candidate service satellite set S according to the QoS constraint, so as to get the candidate service satellite set sequence [S1, S2,... S n ] (as shown in the white circle in the figure). From each set, a satellite can be selected 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 continuous service and does not need to migrate, so the adjacent and same elements can be combined into one (as shown in the green node in the figure). At this time, the problem can be transformed into: selecting a service migration path, so that the number of satellites contained in the path is only possible. Using this selection method can make the number of service switching only possible under the condition of meeting the QoS constraint, thereby reducing the overhead of frequent migration. This problem can be solved by dynamic programming method, 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] Using dynamic programming method to solve the problem, first of all, we need to consider the definition of state. Define dp[i][j] as the minimum subsequence number in the sequence ending with x j in the first i sets. For a new set Si, for each number x p in it, we can add the number to the current sequence. At this time, we need to consider two cases:

[0206] • The number x p only appears once. In this case, we can directly add the number x p to the current sequence, and update dp[i][p] = dp[i-1][j]+1, where j represents the sequence ending with x jThe sequence is the end. (13-17 lines)

[0207] • The number x p Has appeared in the current sequence. In this case, we do not need to add the number x p To the current sequence, just update dp[i][p] = dp[i-1][j], indicating that the number of independent numbers in the sequence is unchanged (19-22 lines)

[0208] The final answer is dp[n][j], where n represents the number of sets. We need to find the minimum sequence number, 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 the sequence meeting the conditions can be obtained by backtracking from dp[n][j] (28-37 lines). In the actual use of the algorithm, all satellites are randomly numbered, and each candidate service satellite set needs to be sorted according to the number. The final returned sequence 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, the satellite resources on the optimal migration path may be insufficient. Considering that the above algorithm has non-unique solutions and there are more suboptimal migration paths, the scheduler can select appropriate migration paths according to the resource situation, thereby avoiding resource contention among low-latency tasks.

[0211] For ground users, at any time, users can directly access multiple adjacent satellites, but the length of the accessible communication interval is different. 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 application converts the user's communication interval information into a directed acyclic graph, such as Figure 5The figure shows that each node represents a satellite, contains the start and end time of the user's communication with the satellite, and the weight on the upper edge of 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 communication end time of the satellite in each stage is strictly greater than that of the previous stage. For the 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, only the service duration is different, so the satellites in the stage can be sorted according to the service deadline, and the satellite with the latest deadline is located on the optimal path. Returning to the optimal path from the satellites on other suboptimal migration paths requires an additional migration within the stage. In addition, since the satellites in the same stage are also relatively close, the intersection of the service satellite sets that meet the QoS requirements also exists, so all service satellite sets in each stage can be divided into multiple disjoint subsets, which correspond to different satellites in the stage.

[0212] The scheduler can optimize task resource scheduling according to the above-mentioned stage satellite information combined with the resource condition. First, the scheduler should preferentially allocate resources in the low-latency service resource pool mentioned above. Under the resource pool constraint, the scheduler allocates resources to the corresponding satellites according to the path provided by the optimal path selection algorithm. If the satellite resource is insufficient, the scheduler will select other satellites in the service satellite subset that accesses the optimal satellite of the user, and the selection process is according to the distance sorting. In special cases, if there is still no available resource in the subset, the scheduler will select resources in the service satellite subset of the suboptimal access satellite according to the satellite sorting in the stage, and re-run the path selection algorithm. If the extreme case of still no available resource occurs, the scheduler can select satellites outside the resource pool for scheduling. Through the above strategy, the scheduler can maximize the use of user communication interval information to realize reasonable allocation of resources.

[0213] Scheduler strategy simulator:

[0214] Because the number of nodes of the low-orbit satellite constellation is large, and the system designed by the present application needs the cooperation of each node, 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 application 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 simulation in advance, and finally displays the simulation result data in an intuitive form.

[0215] Overall architecture of the simulator:

[0216] The overall architecture of the scheduler strategy simulator is as follows: Figure 6The 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 to the corresponding satellite. The ephemeris management module is responsible for providing satellite-related information, including the communication interval with the ground position, the visible satellite, etc. The simulation module is the core of the entire simulator, which is composed of a simulation process controller and multiple satellite grouping objects. The controller drives the overall simulation process, while the satellite grouping object is mainly responsible for simulating the grouping state, including the state of the task, the adjacent grouping, and the satellite in the grouping. The scheduler module mainly implements various scheduling strategies, including the strategy introduced in the present application and some comparative 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 running data generated in the simulation process, and analyzing the data after the simulation is completed to help the user verify the actual effect of the scheduling strategy. The scheduling simulator of the present application is implemented using Python, wherein the part related to 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 described in the foregoing. The task definition is similar to the task CRD definition described in the foregoing. However, since the simulator does not run actual tasks, the end time information is also included in the definition of each task. The simulation module judges whether the task is ended according to the information, and modifies the state of the corresponding task and satellite. It is noted that the information is not exposed to the scheduler, so the scheduler still schedules the tasks according to the actual state of the satellite computing resources.

[0219] Before the simulation process starts, the task generation module will generate 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 types of tasks can be configured differently.

[0220] Table 13 Task Generation Configuration Parameters

[0221]

[0222] Since the number of tasks in each geographical division is different, the process of generating tasks is carried out one by one according to the geographical distribution division. In order to make the generated task load more realistic, the present application generates the arrival time of each task by using the idea of random sampling. First, according to the normalized load position and time distribution information, the total number of tasks per day can be obtained by multiplying the number of tasks per hour in each region. According to the number, the average arrival interval of the task in the hour can be obtained. Since the arrival time of the task obeys the Poisson distribution, the interval between adjacent tasks obeys the exponential distribution with λ as the parameter, where λ represents the frequency of task arrival, then 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 can be generated by using the average arrival interval of the task. By using this method, the arrival interval of each task in each hour can be generated, so as to determine the arrival time of the task.

[0223] (2) Simulation process:

[0224] The goal of the simulator is to simulate the execution of the generated tasks according to the scheduling strategy in a specific satellite scenario according to the user input configuration, and finally output the overall situation of the task execution. The most time-consuming part in the whole process is the calculation of the user-satellite communication interval, especially since the low-latency service task needs to be migrated according to the satellite and user position information, the simulator not only needs to simulate task scheduling, but also needs to calculate the position information of the satellite and the ground user in real time. Therefore, the present application divides the whole simulation process into three stages: environment preparation stage, simulation stage and data processing stage, so as to reduce the calculation amount of the simulation stage as much as possible and improve the overall efficiency of the simulation. Figure 7

[0225] The environment preparation stage first needs to generate task load and satellite constellation information, wherein the task load generation is as described above, 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 to pre-group the satellites according to the grouping strategy to create multiple satellite grouping objects. Secondly, since the task is submitted to the center node of each group first, this stage needs to allocate each task to different grouping objects according to its submission time and place. Considering that this step is time-consuming and the satellite environment and load are fixed when comparing the scheduling strategy, this stage will also cache the task-group mapping, so that when the same task load set and satellite configuration are used in subsequent simulation, this step can be directly skipped. Finally, according to the geographical position and time information in the task set, the satellite communication interval information required by each low-latency service task is generated and cached in a file, and the file is loaded into the memory by the runtime simulator and searched, so as to reduce the calculation amount.

[0226] ​The simulation stage is to simulate the execution of the tasks on the satellites according to the scheduling strategy, and record the execution data. The simulation mode of the event is adopted, and the events that can occur in the scheduler are put into a priority queue sorted by time. The controller takes the event with the earliest time from the head of the queue after the simulation starts, steps the simulator time, and calls the processing function of the event. In the event processing process, if a new event is generated, the new event will be re-inserted into the priority queue by the controller. The events in the simulator can be divided into two categories: task simulation events and statistical data events. The task simulation events are mainly responsible for the simulation of the task execution process, such as the start and end of the task, the low-delay service migration, etc.; the statistical data events are mainly responsible for the statistics of the cluster load and the task execution status. Specific events include the following:

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

[0228] PodFinish: indicates the end of Pod execution. When the Pod execution is completed, 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-delay service execution. All running Pods and warm-up Pods corresponding to the service are cleaned up, and service execution information is counted.

[0230] ServiceMigrate: indicates low-delay service migration. The 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 in the corresponding group according to the next service satellite indicated by the event, and close the Pod that has completed the service.

[0231] ResourcePoolUpdate: indicates the update of the resource pool in the cluster. For the scheduling strategy proposed in the present application, the resource pool division in the group needs to be updated in time according to the position of the satellite.

[0232] UserAccessChange: indicates the user access satellite change. For each low latency service, the controller generates a series of user access change events, and the system will count the delay of the user access service in the last switching process when processing the event.

[0233] StatsSample: indicates the collection of cluster load state. The system will generate this event in batches according to the interval requirements at startup, which is used to collect the load information of the cluster during simulation.

[0234] Table 14 Simulator statistics

[0235]

[0236] After the end of the simulation, the simulator generates a plurality of statistical data record files, and the work of the data processing stage is to integrate these data into the execution status of the task as a whole. This stage only takes the statistical data record file as input, and therefore can be run independently of the simulation stage. The final statistics of the data processing stage can be divided into three categories, as shown in Table 14. Users can compare the pros and cons of different scheduling strategies through these data.

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

[0238] Since there is no satellite cloud computing platform deployed at present, in order to further verify the load balancing and service migration mechanism, the satellite cloud computing resource scheduling system prototype is designed and implemented. The prototype is implemented based on the extension of the Kubernetes platform and is deployed on a satellite computing simulation platform composed of multiple lightweight virtual machines, and the inter-satellite network is simulated through external network traffic control. Users can submit tasks to the prototype platform to observe the state of load balancing and service migration. In addition, in order to efficiently verify the effect of resource scheduling strategies in large-scale satellite network scenarios, the satellite cloud computing resource scheduling simulator is designed and implemented to verify the pros and cons of different scheduling strategies.

[0239] Although some embodiments of the present disclosure have been shown and described, those skilled in the art should understand that modifications can be made to these embodiments without departing from the principles and spirits of the present disclosure, which are defined by the claims and their equivalents.

Claims

1. A satellite packet management system for satellite cloud computing internet platforms, characterized in that, The system includes three modules: a group management module, a task scheduling module, and a low-latency service migration management module. All three modules run on the k3s management node k3s master. The system also includes an ephemeris calculation module that provides satellite information for each module, a client skclient that runs on the client terminal, and skagent that runs on the working node satellite. In terms of functional architecture, the client skclient accesses the system's API through the remote procedure call framework gRPC to submit tasks to the task scheduling module and low-latency service migration management module in the management node k3s master, and to add or delete peer relationships to the group management module. The API can submit tasks or services to the skagent on the worker node satellite. After the user's access reaches the skagent running on the worker node, the skagent running on the worker node forwards the user request to the corresponding module in the k3s management node k3s master. The skagent running on each worker node also communicates with the satellite distributed file system. In terms of the functionality of each module, specifically: The group management module internally constructs a delay-constrained satellite group management mechanism and designs a geographic information-based inter-group load balancing strategy suitable for satellite systems. It also constructs a group management interface design, an adjacent group registration mechanism, and an adjacent group status management mechanism to manage adjacent group relationships and collect the resource status of adjacent groups. The task scheduling module is responsible for listening to user-submitted tasks and implementing three mechanisms: task interface design, resource pool management, and task scheduling. Based on the scheduling strategy, it allocates computing resources to tasks or schedules them to other groups. This module is also responsible for managing the resource pool. The low-latency service migration management module constructs a satellite network low-latency service migration mechanism and, through interface design, pre-entry mechanism, and cross-group service migration mechanism design, is responsible for calculating the optimal migration path based on the user's location and managing the service's migration status within and between groups. The system also includes a satellite cloud computing resource scheduling strategy simulator, 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 task loads for a period of time based on 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 communication intervals with the ground location and visible satellites. Running on the k3s management node, it is responsible for providing the user communication interval information required by the scheduling algorithm and maintaining the current satellite position information of the group. The simulation module consists of a simulation process controller and multiple satellite group objects. The simulation process controller drives the overall simulation process, and the satellite group objects are mainly responsible for simulating the group 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 task scheduling simulation by calling the interface provided by the scheduler module. It is implemented using Python, with the parts involving satellite orbit and motion simulation implemented using the python-skyfield library. The data processing module is responsible for collecting task execution 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 specific implementation method of the delay-constrained satellite grouping management mechanism is as follows: First, we model the communication delay between satellites in a low-Earth orbit satellite constellation: for the case where each satellite only communicates with the two satellites in the same orbit and the two satellites at the same position in adjacent orbits, the communication delay between adjacent satellites can be divided into two types: communication delay in the same orbit and communication delay in adjacent orbits. The communication delay of non-adjacent satellites can be obtained by linearly combining the above two delays. Given Each orbital plane, on each orbital plane A satellite, a satellite network is abstracted as a single satellite. The grid, Given a natural number and points on the top, bottom, left, and right sides of the grid that are directly connected, for satellites in the same orbital plane, since their front and rear positions remain fixed, the distance between two adjacent satellites is... for: ; in For the Earth's radius, The altitude is the orbital altitude, as the distance between adjacent satellites varies with the orbital period. Periodic changes, within a given time Within this range, the distance between two satellites in adjacent orbits is: ; in The orbital inclination of the satellite, When the value is 0, it is assumed that the satellite is in the equatorial plane, at which point the distance between the two satellites is the greatest. By integrating the above equation and taking the average, the average distance between satellites in adjacent orbits can be obtained: ; in It is a second-type elliptic curve integral, which divides the aforementioned distance by the speed of light in a vacuum. This allows us to obtain the communication delay between adjacent satellites. and Since the topology of constellations resembles a two-dimensional grid, coordinates on the grid can be used. Referring to satellites within a constellation, it is easy to identify any two satellites. and Communication delay The shortest hop count between the two coordinates multiplied by the delay: ; Where % represents the modulo operation and abs represents the absolute value operation; then, a delay-constrained satellite grouping method is constructed: given delay constraints... For any satellite It and other satellites in the same group The communication delay must be within the constraints, that is... Under the above constraints, the number of groups should be as small as possible in order to improve the overall resource utilization efficiency of the satellite; Find a set of points in the grid. Such that any point in the graph is connected to... The distance to exactly one of the points is less than or equal to Distance normalization is achieved by adding virtual nodes, and the process is then completed. After using the jump placement algorithm and then scaling the nodes proportionally, the result satisfies the condition that the distance from each node to the dominating set node is less than or equal to... ,in To account for the error generated during scaling and rounding, the number of nodes in the dominance set is equal to the number of groups. Finally, by traversing all the remaining nodes, each node is assigned to the group to which its nearest dominance node belongs. Next, a resource balancing strategy for grouped computation is constructed: First, during the traversal of each node, nodes that can join multiple clusters or cannot join any cluster are temporarily ignored; then, clusters are assigned to ungrouped nodes using a backtracking method, thereby finding the optimal solution for the current grouping situation; second, since the Torus mesh is a ring topology, the determined dominant nodes are further translated on the overall mesh, and grouping is calculated separately for each case, since there are at most only In the case of a certain situation, the global optimal solution can be obtained directly through exhaustive search.

2. The satellite packet management system for satellite cloud computing internet platforms as described in claim 1, characterized in that, The specific implementation of the group management interface design of the group management module is as follows: First, define the PeerCluster custom resource type. The structure of the PeerCluster resource includes the unique identifier of the group, the address of the group's central node, the identifier and address of the worker nodes in the group, and the status of the group. The worker nodes are recorded using the Satellite custom type.

3. A satellite packet management system for a satellite cloud computing internet platform as described in claim 2, characterized in that, The specific implementation of the adjacency group registration mechanism in the group management interface design of the group management module is as follows: After the user sets the satellite information of each group through skclient, adjacent groups are automatically discovered and established through 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 returned results of each node based on the 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 groups and start the adjacent group monitoring component to start sending heartbeats to the central node of the adjacent groups.

4. A satellite packet management system for a satellite cloud computing internet platform as described in claim 3, characterized in that, The specific implementation method of the adjacency group state management mechanism in the group management interface design of the group management module is as follows: Once adjacent groups have discovered each other, each group starts a PeerMonitor monitoring goroutine for each adjacent group to obtain resource status and load prediction information of the adjacent groups. At the same time, each group starts a MetricAggregator program at startup to aggregate resource data within its own group. The PeerMonitor monitoring goroutine works by pulling information, periodically obtaining aggregated resource status information PeerMetric from PeerClusters other than itself within 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 method of state interaction between groups is as follows: After a group enters the working state, MetricAggregator obtains the current cluster resource status and 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 to expose 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 packet management system for a satellite cloud computing internet platform as described in claim 4, characterized in that, The specific implementation method of the geographic information-based inter-group load balancing strategy is as follows: First, define the mission parameters running on the low-Earth orbit satellite computing platform. Each mission is defined by a number from 1 to... It consists of Pods, each containing the required CPU and memory resources. Each task is accompanied by its initial satellite information, recorded in the coordinates of the satellite within the constellation. Low-latency service tasks also include the location information of the ground user, recorded in latitude and longitude. Finally, each task also includes the time of submission to the computing platform. Next, 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 are used as the reference data. The Earth's surface is divided into 72 regions in 30-degree units, and the longitude range is further divided into 15-degree units. The regions are aligned with the time zones to form 144 regions. The equipment density index is normalized to the task load ratio and mapped to the 144 regions. At the same time, the proportion of traffic in each time period to the total daily traffic in the traffic ratio change map is converted into the relative proportion of each time period. The corresponding time zone is multiplied by the load ratio in the regional division map to obtain the task load ratio zoning table for each time period. The entire table is stored in a dictionary with (longitude subscript, latitude subscript, UTC time) as the key. Subsequently, based on the nadir trajectories of satellites within the group, a sampling method is used to model the changes in the proportion of ground low-latency service tasks that each group may receive over a future period. For a given group... Each satellite within At the same time Starting from this point, the next satellite orbital cycle The low-latency service task load ratio within is ,in For the number of samples, for Time Satellite The latitude and longitude of the nadir point, combined with the time zone of that geographic coordinate, are obtained from the dictionary mentioned above, to determine the load ratio of the entire group. To calculate the average load ratio of each satellite within a group, the data is converted into a histogram by calculating the interval mean. The horizontal axis represents the discretized time period, and the vertical axis represents the maximum load ratio within that time period. The interval length is used as an adjustment parameter. The smaller this parameter is, the more frequently the scheduler module adjusts the resource pool size, which is closer to the actual optimal load ratio, but it also has a greater impact on running tasks. Next, a dynamic partitioning strategy for the computing resource pool is constructed, comprising two parts: resource pool node sorting and resource pool capacity adjustment strategy. The resource pool node sorting part uses a greedy algorithm to order all nodes, ensuring that the distribution of nodes in the resource pool is as uniform as possible during expansion and contraction. First, a breadth-first search is used to divide the nodes in the group into two categories starting from the central node, ensuring that the nodes in these two categories are not adjacent to each other. At this point, the distribution of nodes in each category is uniform. Then, the strategy is to sort the nodes in the two categories separately. The sorting idea is to 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 categories of nodes is concatenated to obtain the final node order. The resource pool capacity adjustment strategy is as follows: After completing node sequencing, the scheduler module performs resource pool expansion or contraction operations based on load prediction information. Expansion includes tagging nodes and evicting currently running geographically irrelevant tasks, while contraction only involves removing node labels. When the system monitoring module detects insufficient low-latency service resource pool resources, or when the scheduler module determines that expansion is necessary based on the aforementioned load prediction information, the scheduler module performs resource pool expansion, adding labels to nodes sequentially according to the current end node index of the resource pool until the required resource quantity for expansion is reached. The scheduler module checks all currently running geographic... For irrelevant tasks, if the node where the task is currently running is already in the new resource pool, the task is marked as "pending migration." However, the task will only be evicted and rescheduled if the scheduler module selects to schedule a new low-latency service task to that node and finds insufficient resources. When the system monitoring module finds that the resources occupied by tasks in the resource pool are below the threshold and determines that scaling down is necessary based on load prediction information, the scheduler performs resource pool scaling down. At this time, the scheduler removes node labels in reverse order, starting from the last node in the resource pool. 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 on their own. Finally, a task load balancing strategy is constructed between groups: load balancing is achieved by scheduling geographically independent tasks among groups. When a task is submitted to a satellite group, the resource scheduler of that group selects itself and its neighboring groups as candidate groups. It obtains the remaining resource data and load prediction data for the next orbital period of all candidate groups through local caching or communication with neighboring groups. Based on this data, the resource scheduler scores all candidate groups using the following scoring formula: Can the task be executed directly? Remaining resource quantity Time until the next resource pool expansion Is the task located in the current group? Based on the scoring results, the resource scheduler submits the task to the group with the highest score and increments the scheduling count associated with the task by one. If the group with the highest score is the group containing the current task, the resource scheduler will directly submit the task to the queue of tasks to be scheduled in the local group. If a task has reached the maximum number of scheduling attempts, the last scheduled task will be directly submitted to the queue of tasks to be scheduled in the corresponding group.

6. A satellite packet management system for a satellite cloud computing internet platform as described in claim 5, characterized in that, The task interface design in the task scheduling module is as follows: two types of tasks are defined in the form of CRD: the geographically independent task ComputeJob and the low-latency service task LowLatencyService. The two tasks are basically the same in terms of Pod description, submission time, submission location, etc., but ComputeJob includes the number of rescheduling times and the group identifier information of the final execution, while LowLatencyService includes the migration process identifier. 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. The specific method of resource pool management in the task scheduling module is as follows: First, the custom resource of ResourcePool is defined, and then the workflow of ResourcePool controller is constructed. When a group is created, each group creates a ResourcePool resource in its own k3s cluster. After the controller corresponding to the resource starts, it first requests the MetricAggregator to obtain the current cluster resource information. Then, the controller sorts all worker nodes according to the node sorting strategy defined by SortPolicy. The sorting strategy includes uniformity strategy, sorting by satellite number order, sorting by resource capacity, etc. After sorting, the controller starts the LoadWatcher coroutine to update the NextAdjustment field, including the time and the target size of the resource pool, 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 worker node label sequentially through the Kubernetes Update method according to the node identifier in NodeOrder, based on the CurrentPoolSize and CurrentLastNode information in ResourcePool and the target size of the resource pool in NextAdjustment. After updating the NextAdjustment field, the LoadWatcher coroutine periodically collects cluster resource status information and updates it to the load prediction module. The task scheduling module implements task scheduling in the following way: it utilizes a custom ComputeJob controller, a LowLatencyService controller extension framework, and a Kubernetes controller extension framework to achieve hybrid scheduling of two types of tasks. The ComputeJob controller implements location-independent task scheduling and cross-group load balancing. When a user submits a ComputeJob object via skclient, the object's status is initially marked as INCOMING. The controller then submits the INCOMING task object to the IncomingQueue, an initial scheduling queue implemented using the Kubernetes workqueue library. Simultaneously, the load balancing goroutine within the ComputeJob controller retrieves task objects to be scheduled from this queue, and the load balancing strategy selects a group for execution. If the task needs to be scheduled to another group, the ComputeJob controller calls the Update method in PeerCluster to submit the task to the other group and deletes the task from the current group. If the task needs to be executed within this group, the ComputeJob controller changes the task status to PENDING. The task scheduling goroutine within the ComputeJob controller continuously polls all tasks in the PENDING state and submits any uncommitted Pods to the k3s cluster via Create, waiting for scheduling by the central scheduler. Once all Pods in the task have started, the controller changes the task status to RUNNING, and continues to change the status to FINISHED until all Pods have completed. The LowLatencyService controller is primarily responsible for scheduling low-latency service tasks based on the scheduling path information provided by the migration management module. After a user submits a low-latency service, the object's status is initially marked as INCOMING. The controller then creates a corresponding MigrationProcess object for the task object in this state and subsequently marks it as PENDING. At this point, 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 within the cluster. The LowLatencyService controller continuously polls task objects in the SERVING state until their status changes to FINISHED, at which point it deletes the running Pod and the MigrationProcess object. The extended framework of the Kubernetes controller extends the central scheduler, enabling it to distinguish Pods belonging to different task types and adopt corresponding scheduling strategies. In the QueueSort phase, the extended framework allows the scheduler to differentiate between the two task types based on the tags in the Pods, prioritizing Pods for low-latency service tasks to ensure no impact on user QoS. In the Filter phase, the extended framework allows the scheduler to select nodes from different resource pools for the two Pod types. For low-latency service tasks, if no suitable node is selected in the Filter phase, the extended framework in the PostFilter phase allows the scheduler to attempt to evict some geographically unrelated task Pods to release resources and notifies the resource pool management module to record load conflict information. In the Score phase, the extended framework allows the scheduler to score and rank nodes for low-latency service task Pods based on the satellite access information provided by the MigrationProcess, using the strategies described in the previous chapter.

7. A satellite packet management system for a satellite cloud computing internet platform as described in claim 6, characterized in that, The interface design of the low-latency service migration management module is as follows: Define a custom resource for MigrationProcess. PrevProcess and NextProcess point to the MigrationProcess objects corresponding to the task in other groups, respectively. The Path field contains a list of PathNodes. Each PathNode represents a node on the path and includes the user's access satellite identifier, service start and end time, optimal and alternative satellite sets, and the current status 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. When a 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 future period based on the user's location and creates a Path based on the path selection algorithm. When the first PathNode in the Path points to its own group, the controller modifies the task object's state and submits the Pod to the scheduler based on the task object's Pod description information. When the end time specified by the PathNode is reached, the controller cleans up the Pod corresponding to the previous PathNode and schedules a new Pod based on the new PathNode. When the number of nodes in the Path is less than a threshold, the controller continues to calculate and update new migration paths. The service preheating mechanism in the low-latency service migration management module is as follows: It introduces the concept of a service preheating window 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 the service state, meaning the satellite corresponding to this node is currently providing services to users. The PathNode immediately following it is in the preheating state, meaning the satellite corresponding to this node needs to pre-start the corresponding service Pod, waiting for users to directly access it after migration. Other PathNodes within the window are in the environment preparation state, meaning the satellites corresponding to these nodes need to pre-create the MigrationProcess object and prepare the environment required to start the Pod, such as pulling container images. PathNodes outside the window are in the waiting state, meaning the satellites corresponding to these nodes do not need to perform any operations temporarily. When a PathNode in the service state in the window reaches its service deadline, the entire service preheating window moves one node backward. At this time, the MigrationProcess controller corresponding to the just-ended PathNode will send window updates in a chain to the controllers of the groups containing the PathNodes in subsequent windows. 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 based on the new end PathNode information, completing the window shift.

8. A satellite packet management system for a satellite cloud computing internet platform as described in claim 7, characterized in that, The specific method for constructing the cross-group service migration mechanism in the low-latency service migration management module is as follows: The task can be smoothly migrated between groups through the cooperation of the MigrationProcess controllers 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 the object and adjust its state. If a Pod cannot start during the preheating phase due to insufficient resources or 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 update the information in a chain according to the newly generated subsequent PathNodes, thereby updating the entire migration path. The method for constructing the satellite network low-latency service migration mechanism in the low-latency service migration management module specifically includes two modules: low-latency service migration path selection and migration path-aware task scheduling strategy. The low-latency service migration path selection uses QoS constraints, which reduce the frequency of service migration while ensuring service quality by constraining the latency between the user access satellite and the satellite providing the service. Given the user's location From the time the user submits the task The initial future period T is calculated using the SGP4 orbital model. The set of satellites and their communication intervals that enter the user's communication range; firstly, the satellite with the longest available communication time at the user's current moment is selected as the access satellite, thus obtaining the access satellite sequence that changes over time. For each access satellite, a set of candidate serving satellites can be obtained based on QoS constraints. This yields a sequence of candidate service satellites. By selecting one satellite from each set, a service migration path can be formed. If adjacent elements in the sequence are the same, it means that the satellite provides continuous service and does not need to be migrated. Therefore, adjacent and identical elements can be merged into one. At this time, the problem can be transformed into: choosing a service migration path such that the number of satellites in the path is as small as possible. This problem is solved using dynamic programming. First, the definition of the state is given. For in front In each set, with Let S be the minimum number of unique subsequences in the sequence ending with S. For a new set Si, for each number in Si... Add the number to the current sequence; For numbers If it only happens once, directly change the number. Add to the current sequence and update ,in Indicates preceding In each set A sequence ending with; for numbers For numbers that have already appeared in the current sequence, there is no need to add them. To add to the current sequence, simply update This indicates that the number of independent numbers in the sequence remains unchanged; The final answer is ,in Represents the number of sets, and the search is... The minimum value in the middle is obtained by maintaining a An array that records the predecessor state of each state, ultimately from... Start backtracking forward to obtain a sequence that meets the conditions; The migration path-aware task scheduling strategy transforms the user's communication interval information into a directed acyclic graph (DAG), where each node represents a satellite and includes the start and end times of the user's communication with that satellite. The weights on the nodes represent the time the user stays after migrating from other satellites to that satellite. The graph divides satellites into multiple stages according to the start and end times of their services. The end time of satellite communication in each stage is strictly greater than that of the previous stage. Satellites within a stage are sorted according to their service deadlines. The satellite with the latest deadline is located on the optimal path. If a satellite returns to the optimal path from a satellite on a suboptimal migration path, an additional migration is required within the stage. Furthermore, since satellites within the same stage are relatively close, their sets of service satellites that meet QoS requirements also overlap. Therefore, all service satellite sets in each stage can be divided into multiple disjoint subsets, each corresponding to a different satellite within the stage.

9. A satellite packet management system for a satellite cloud computing internet platform as described in claim 8, 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 primarily responsible for generating task loads over a period of time based on the user-provided task generation configuration and mapping them to the corresponding satellites. The ephemeris management module is responsible for providing satellite-related information, including communication ranges with the ground location and visible satellites. 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, while the satellite grouping objects are mainly responsible for simulating group states, including the status of tasks within a group, adjacent groups, and satellites within a group. The scheduler module implements various scheduling strategies, and the satellite cluster process completes task scheduling simulation by calling the interface provided by the scheduler module. The data processing module is responsible for collecting task execution data generated during the simulation process and analyzing the data after the simulation is completed to help users verify the actual effectiveness of the scheduling strategies. The task generation module of the scheduling strategy simulator is implemented as follows: First, tasks are generated based on the configuration file input by the user. Since the number of tasks varies in each geographical region, the task generation process is carried out one by one according to the geographically divided regions. The arrival time of each task is generated using the idea of ​​random sampling. First, based on the normalized load location and time distribution information, multiplying by the total number of tasks per day yields the number of tasks per hour in each region. Based on this number, the average arrival interval of tasks within that hour is obtained. Since the arrival time of tasks follows a Poisson distribution, the interval between the arrival of adjacent tasks follows a Poisson distribution. Let the parameter be an exponential distribution, where The meaning is the frequency of task arrivals, and the average arrival interval is the value of that frequency. Based on the idea of ​​random sampling, a set of random variables following the exponential distribution are generated using the average arrival interval of the tasks. This method is used to generate the arrival interval of each task within each hour, thereby determining the arrival time of the tasks. The simulation process of the scheduling strategy simulator is implemented as follows: The entire simulation process is divided into three stages: environment preparation, simulation, and data processing. The environment preparation phase first generates the task load and satellite constellation information. The satellite constellation information generation involves generating a corresponding number of satellite objects and the available resources for each satellite according to the user configuration, and pre-grouping the satellites according to the grouping strategy to create multiple satellite group objects. Secondly, since the task submission first reaches the central node of each group, this stage assigns each task to different group objects according to its submission time and location, and caches the task-group mapping. When subsequent simulations use the same task load set and satellite configuration, this step is skipped directly. Finally, based on 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 runtime simulator can reduce the amount of computation by loading the file into memory and looking it up. The simulation phase adopts an event simulation mode, in which possible events in the scheduler are placed into a priority queue sorted by time. After the simulation starts, the controller takes out the earliest event from the head of the queue, steps the simulator time, and calls the event processing function. If a new event is generated during the event processing, the new event will be re-inserted 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 primarily responsible for compiling simulation statistics during task execution. Other events are responsible for tracking cluster load and task execution status, specifically including: JobSubmit: This 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 policy, and then the scheduler within the group schedules the Pods in the task. If the Pod starts successfully at this time, a PodFinish event is generated and inserted into the event queue. If it does not start, 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. Finally, a ServiceFinish event is generated and inserted into the event queue. PodFinish: Indicates that the Pod has finished executing. When the Pod finishes executing, the computing resources it occupies need to be released and the execution status of the corresponding task needs to be modified. ServiceFinish: Indicates the end of low-latency service execution, cleans up all running and preheating Pods corresponding to the service, and collects service execution information; ServiceMigrate: This indicates a 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 this event, and shut down the Pod that has completed the previous service. ResourcePoolUpdate: This indicates that the resource pool within the cluster is updated. For scheduling strategies, the resource pool allocation within the group needs to be updated in a timely manner based on the satellite's position. UserAccessChange: This indicates a change in user access to the satellite. For each low-latency service, the controller will generate a series of user access change events. When processing this event, the system will calculate the latency between this event and the last handover process. StatsSample: This indicates the cluster load status to be collected. The system will generate this event in batches according to the interval requirements when it starts up, and 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 data processing stage involves integrating these data into the overall execution status of the task.

Images