143 and/or containers from container set 144. It is understood that these VCEs may be stored as images and may be transferred among and between the various physical machine hosts, either as images or after instantiation of the VCE. Cloud orchestration module 141 manages the transfer and storage of images, deploys new instantiations of VCEs and manages active instantiations of VCE deployments. Gateway 140 is the collection of computer software, hardware, and firmware that allows public cloud 105 to communicate through WAN 102.

Some further explanation of virtualized computing environments (VCEs) will now be provided. VCEs can be stored as “images.” A new active instance of the VCE can be instantiated from the image. Two familiar types of VCEs are virtual machines and containers. A container is a VCE that uses operating-system-level virtualization. This refers to an operating system feature in which the kernel allows the existence of multiple isolated user-space instances, called containers. These isolated user-space instances typically behave as real computers from the point of view of programs running in them. A computer program running on an ordinary operating system can utilize all resources of that computer, such as connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, programs running inside a container can only use the contents of the container and devices assigned to the container, a feature which is known as containerization.

PRIVATE CLOUD 106 is similar to public cloud 105, except that the computing resources are only available for use by a single enterprise. While private cloud 106 is depicted as being in communication with WAN 102, in other embodiments a private cloud may be disconnected from the internet entirely and only accessible through a local/private network. A hybrid cloud is a composition of multiple clouds of different types (for example, private, community or public cloud types), often respectively implemented by different vendors. Each of the multiple clouds remains a separate and discrete entity, but the larger hybrid cloud architecture is bound together by standardized or proprietary technology that enables orchestration, management, and/or data/application portability between the multiple constituent clouds. In this embodiment, public cloud 105 and private cloud 106 are both part of a larger hybrid cloud.

FIG. 2 illustrates an example system for implementing workload management in low Earth orbit data centers in one embodiment. In an example shown in FIG. 2, a system 201 can include an LEO satellite 202 that includes a data center 210. System 201 can be computing system 100 shown in FIG. 1 or can be a part of computing system 100 shown in FIG. 1. Data center 210 can be connected to, coupled to, attached to, integrated, or embedded in, LEO satellite 202 such that data center 210 can orbit around Earth as LEO satellite 202 orbits around Earth. LEO satellite 202 can orbit around Earth along an orbit path 204. Orbit path 204 can be relatively close to Earth's surface, such as being less than 1,000 km. Orbit path 204 can be arbitrarily defined and may not need to be defined by existing topological conventions, such as longitudinal or latitudinal lines, such as not needing to follow Earth's equator. Although one LEO satellite with a data center is shown as orbiting Earth in FIG. 2, more than one LEO satellite can orbit around Earth simultaneously, each may be connected to a respective data center.

Data center 210 can include at least an application space 212, at least one server such as servers 220, 230, at least one hardware processor such as processor 214, at least one load balancer 216, and other hardware components such as memory devices, network cards, switches, transceivers, controllers, integrated circuits (ICs), and other hardware components that can be found in a data center. Load balancer 216 can be configured to perform load balancing among servers in data center 210. In one embodiment, data center 210 can include more than one load balancers and the load balancers can be configured to perform load balancing for one server in data center 210. For example, a first load balancer can perform load balancing for server 220 and a second load balancer can perform load balancing for server 230. Processor 214 can be, for example, a microprocessor, one or more processing cores, a central processing unit (CPU), or other types of hardware processing elements. Processor 214 can include other hardware components such as memory devices. Processor 214 can be configured to control components and operations of data center 210. Application space 212, servers 220, 230, processor 214, load balancer 216, and other hardware components of data center 210 can communicate with one another via a communication bus in data center 210.

Application space 212 can store source code, executable code, and data associated with a plurality of applications. Applications in application space 212 can be assigned to different servers in data center 210. For example, a set of applications 222 can be assigned to server 220 and a set of applications 232 can be assigned to server 230. Server 220 can be configured to communicate with user devices on Earth's surface that request access to the set of applications 222 and server 230 can be configured to communicate with user devices on Earth's surface that request access to the set of applications 232.

In an aspect, the assignment of applications in application space 212 to different servers in data center 210 can be dependent on geographical locations. By way of example, applications 222 can be dedicated to a first geographical or activation region 224 such that server 220 can activate applications 222 when data center 210 orbits to a location above activation region 224. In an aspect, an activation region can be a geographical region on Earth that is bounded by predefined geographical boundaries. Applications 232 can be dedicated to a second geographical or activation region 234 such that server 230 can activate applications 232 when data center 210 orbits to a location above activation region 234. The assignments can be mutually exclusive, such that server 220 may not activate applications 222 when data center 210 orbits to the location above activation region 234 and vice versa. In one embodiment, the dedication or assignments of applications to different activation regions can be predefined by users of data center 210. In one embodiment, the geographical boundaries defining activation regions of the applications in application space 212 can be defined as part of the permission policies of the applications.

Data center 210 can orbit around Earth and communicate with user devices, such as edge devices, mobile devices, IoT devices, or the like, at different activation regions on Earth's surface. The capability of LEO satellite data centers, such as data center 210 shown in FIG. 2, to exchange data with user devices on Earth's surface can offer various benefits. Since the user devices are directly connected to LEO processing locations, the transmission latency is relatively low due to omitted interference of intermediate network components. Further, since LEO satellites are orbiting closer to Earth's surface, user devices on Earth can connect directly to the LEO satellites for data exchange without intermediate processing such as Earth-based eNodeB. In an aspect, LEO satellites may replace eNodeB in fifth generation (5G) and sixth generation (6G) applications for mobile devices due to their capability to connect to the LEO transceivers to serve the connections to the target endpoints (e.g., user devices).

In an aspect, since LEO satellites revolve around Earth with relatively lower height, they are not stationary with respect to Earth's movement. Further, since their movement can be observed from Earth, to maintain the rotation equilibrium, the orbiting speed of LEO satellites can be relatively high. The relatively high orbiting speed of LEO satellites can impact the footprint region where the LEO satellites are being used for direct connection. By way of example, the high orbiting speed can decrease the coverage time of the LEO satellites, thus limiting the footprint region. Therefore, multiple orbiting LEO satellites may be needed in a plane to define a mesh network to offer continuous coverage for an area being covered by the plane. The LEO satellites in the mesh network can communicate with each other via inter-satellite link that can be a high speed network line between the LEO satellites.

The LEO satellite data centers motion dynamics (e.g., high speed, close to Earth's surface, and not limited to specific paths) may not need to be considered for terrestrial data centers since terrestrial data centers are static to a defined location on Earth's surface. However, when an LEO satellite data center is deployed, there are multiple factors that will impact the performance of the LEO satellite data center due to the motion dynamics and of the LEO satellite data center itself. In an aspect, the motion dynamics can cause workload imbalance on the physical devices in the satellite data centers.

By way of example, when data center 210 orbits to the location above activation region 224, server 220 can run the set of applications 222 and the user devices in activation region 224 can communicate with server 220 to access and request data from applications 222. In the event that the first server becomes overloaded when data center 210 is above activation region 224, load balancer 216 can detect the overload condition and perform load balancing. For example, load balancer 216 can move requests from user devices in activation region 224 to another server, different from server 220, that is also assigned to run the set of applications 222. However, due to the motion dynamics of LEO satellite 202 and data center 210 (e.g., moving at relatively high speed), data center 210 may orbit outside of activation region 224 before load balancer 216 makes a decision to perform load balancing, or before all requests in activation region 224 are completed. The same situation can occur for server 230 when data center 210 orbits to the location above activation region 234.

To be described in more detail below, processor 214 in data center 210 can be configured to proactively retrieve various data relating to LEO satellite 202 and data center 210, and use the retrieved data to estimate the motion dynamics of LEO satellite 202 and data center 210. The estimated motion dynamics can include at least estimation of arrival times, locations, and duration of stay of LEO satellite 202 and data center 210. The estimated motion dynamics can be used for managing, balancing and optimizing workload among the servers in data center 210.

FIG. 3 illustrates components of a processor that can be used for implementing workload management in low Earth orbit data centers in one embodiment. Descriptions of FIG. 3 may reference components that are shown in FIG. 2. In an embodiment shown in FIG. 3, processor 214 can include a plurality of hardware and/or logic components configured to estimate trajectory and locations of LEO satellite 202 and data center 210 shown in FIG. 2, and to determine activation time windows for applications. The information estimated by processor 214 can be used for proactive workload balancing of applications and other workloads, where proactive workload balancing can refer to actively initiating workload balancing without the workload balancing being triggered by specific events. In the example embodiment shown in FIG. 3, processor 214 can include a memory device or memory 301. Memory 301 can include volatile memory and non-volatile memory devices configured to store various data retrieved and determined by processor 214.

Further, processor 214 can run or invoke a plurality of application programming interfaces (APIs) 304 to communicate with applications in application space 212, via a platform interface 302, and/or to allow applications in application space 212 to communicate with one another. Processor 214 can also run APIs 304 to retrieve data from applications in application space 212. In one embodiment, processor 214 can perform handshaking with LEO satellite 202 and transmit data requirement signals to LEO satellite 202 for requesting specific required data, and to detect network orchestration events of network planes that include LEO satellite 202. Processor 214 can run a logic component labeled as event detection 306 to invoke LEO infrastructure APIs among APIs 304 to perform the handshaking.

Processor 214 can be further configured to run a logic component labeled as orbit parser 332. In one embodiment, processor 214 can invoke APIs 304 to allow orbit parser 332 to communicate with LEO satellite 202. Processor 214 can run orbit parser 332 to retrieve the physical parameters, from various LEO infrastructure resources, relating to motion dynamics of LEO satellite 202. In one embodiment, the physical parameters can be received in the form of tuples and orbit parser 332 can translate the tuples into digital data having data structure that can be interpreted and processed by processor 214. Processor 214 can store the physical parameters, in the digital form outputted by orbit parser 332, as orbital statistics 310 and geo locations 312 in memory 301. In one embodiment, processor 214 can retrieve the physical parameters over time and store the physical parameters from different times as historical physical parameters. Processor 214 can also determine various statistics, such as averages, medians, standard deviations, or other statistics, of heights, footprint region durations, trajectories, moving or orbiting speeds, rotations, of LEO satellite 202. The determined statistics can be among the stored orbital statistics 310.

Processor 214 can further retrieve a plurality of application permission policies from one or more applications in application space 212. For example, processor 214 can retrieve a plurality of application permission policies from every application in application space 212. In one embodiment, processor 214 can invoke APIs 304 to retrieve the permission policies from application space 212. The permission policies being retrieved can include blackout regions and times, geographical or activation regions where the applications are permitted to run, peak allowed activation policies indicating peak workload timelines of the applications, or other permission policies. By way of example, the permission policies can indicate that applications 222 are permitted to run in activation region 224 and that applications 232 are permitted to run in activation region 234.

In one embodiment, processor 214 can send in-band message queue (PLMQ) based queries to one or more applications in application space 212 to retrieve the permission policies and activation regions. Processor 214 can further run a function labeled as policy parser 320 to translate the retrieved permission policies that resulted from the PLMQ based queries into digital data having data structure that can be interpreted and processed by processor 214. Processor 214 can store the permission policies, in the digital form outputted by policy parser 320, as application policies 314 in memory 301 in FIG. 3. In one embodiment, processor 214 can store application policies 314 as metadata classes such that application policies 314 can be used by a policy to timeline mapper 322.

Processor 214 can further run a logic component labeled as a policy to timeline mapper 322 (“mapper 322”). Processor 214 can run mapper 322 to map locations of LEO satellite 202 at different times with activation time windows of the applications in application space 212 as indicated in application policies 314. The outputs from mapper 322 can indicate whether the orbit path 204 includes locations that are above activation regions of applications in application space 212 that are assigned to the servers in data center 210. For example, to manage and plan workload of server 220, processor 214 can identify locations along orbit path 204 that are above activation region 224 of applications 222 assigned to server 220. The outputs of mapper 322 can indicate the identified locations as overlapping points between locations of LEO satellite 202 at different times with activation time windows of the applications.

In response to identifying locations on orbit path 204 that are above activation region 224, processor 214 can analyze orbital movements of LEO satellite 202 to determine a time window, or coverage times, in which LEO satellite 202 orbits to the identified locations. These coverage times determined by processor 214 can be stored as workload expectation data 324 in memory 301. processor 214 can run a function labeled as scheduler 308 to schedule activation of applications based on the determined coverage times. Processor 214 can also run scheduler 308 to assign different servers to run different applications separately during peak workload time periods.

Processor 214 can be further configured to run a logic component labeled as resource manager 326 to manage availability of resources for allocation. In one embodiment, processor 214 can run a logic component labeled as application examination 316 to determine the type of resources that may be suitable for one or more applications in application space 212. In one embodiment, processor 214 can run a logic component labeled as resource group generator 328 to generate a plurality of resource groups. A resource group can include at least a network resource, a compute resource, and a storage resource. Examples of resource groups are shown in FIG. 5.

In response to generating resource groups, processor 214 can run a logic component labeled as resource group allocator 330 to allocate different resource groups to different applications in application space 212. Resource group allocator 330 may allocate resource groups such that applications running at the same time does not have overlapping resource groups.

In one embodiment, processor 214 can run a logic component labeled as location to resource mapper 318 (“mapper 318”) to map allocated resource groups to activation regions. Processor 214 can run scheduler 308 to ensure that a resource group mapped to an activation region is available when LEO satellite 202 orbits to the activation region. In response to allocating different resource groups to different applications, processor 214 can run scheduler 308 to update the assignments and schedules of servers in data center 210 to run the applications. Scheduler 308 can schedule expected workload according to activation time windows and resource allocations. Processor 214 can provide the scheduled expected workload to load balancer 216 and load balancer 216 can assign the servers in data center 210 to run applications according to the schedule.

FIG. 4 illustrates a method or process for implementing workload management in low Earth orbit data centers in one embodiment. The method or process shown in FIG. 4 can be implemented by one or more computer processors. For example, at least some of the components shown in FIG. 3 for implementing workload management in low Earth orbit data centers may perform the method shown in FIG. 4. in one embodiment. An LEO offload manager and identifier process (or process 350) can be a process that can be implemented by one or more computer processors, an example of which is shown as processor 214 in FIG. 3. A computer processor can run process 350 to proactively retrieve various information relating to LEO satellite 202 and data center 210, and to use the retrieved information to manage and schedule workload among servers in data center 210 and/or among different LEO satellite data centers. Process 350 can be a proactive process, for example, process 350 can be performed without being triggered by spontaneous events such as overload conditions at servers of data center 210.

In one embodiment, a processor such as a computer processor can create an instance of process 350 and run the created instance to perform the steps of process 350 shown in FIG. 4. Upon the creation of the instance, the processor can also define and load data structures that can be used by the created instance. The processor can also trigger various data resources in data center 210 to send data streams including data that may be necessary for running process 350. The processor can also identify receiving locations to receive and store the data being provided by the data resources. In one embodiment, the processor can use softwarization insertions (e.g., integration of software-based components, features, or functionality) in existing management components of data center 210 (e.g., processor 214 and/or load balancer 216) and trigger virtual network functions to provision data from the data resources. In one embodiment, the processor can invoke APIs 304 shown in FIG. 3 to perform handshaking with LEO satellite 202 and transmit data requirement signals to LEO satellite 202 for requesting specific required data, and to detect network orchestration events of network planes that include LEO satellite 202.

At block 354, the processor can retrieve or pull physical parameters of LEO satellites from various data resources. In one embodiment, the processor can invoke APIs, such as APIs 304 shown in FIG. 3, to retrieve the physical parameters. Physical parameters being retrieved at block 354 can include, for example, current height, footprint region, satellite geolocations, trajectory, orbital plane information, average moving speed, orbital characteristics of motion information including direction vectors, speed and rotation information of LEO satellite 202, or other physical parameters of LEO satellites and data centers orbiting around Earth, including LEO satellite 202 and data center 210.

At block 356, the processor can retrieve a plurality of application permission policies from applications in application space 212. In one embodiment, the processor can invoke APIs, such as APIs 304 shown in FIG. 3, to retrieve the permission policies from application space 212. The permission policies being retrieved at block 356 can include blackout regions and times, geographical or activation regions where the applications are permitted to run, peak allowed activation policies indicating peak workload timelines of the applications, or other permission policies. By way of example, the permission policies can indicate that applications 222 are permitted to run in activation region 224 and that applications 232 are permitted to run in activation region 234.

At block 358, the processor can determine activation time windows of applications in application space 212. Activation time windows of an application can be a time window in which the application is activated. In one embodiment, application policies 314 can include workload information of the applications in application space 212.

By way of example, application policies 314 can include information indicating a blackout activation time for a public transportation application is 12 AM to 6 AM and its peak workload times can be during morning and evening commuting hours. In another example, a meal delivery application may have blackout activation time between 9 PM to 9 AM and its peak workload times can be during lunch and dinner timeframes. Based on these information, the processor can determine that an activation time window for the public transportation application can be 6 AM to 12 AM and an activation time window for the meal delivery application can be 9 AM to 9 PM. In this example, the public transportation application and meal delivery application can have overlapping activation times. Also, in an aspect, evening commuting hours and dinner time may have similar time frame, thus the peak workload times for the public transportation application and the meal delivery application may have overlapping peak workload times.

By way of example, if server 220 is assigned to run the meal delivery application, then the processor can determine that server 220 needs to be activated between 9 AM to 9 PM. If server 220 is assigned to run both the public transportation application and the meal delivery application, then the processor can determine that server 220 needs to be activated between 6 AM to 11 PM.

At block 360, the processor can estimate or determine orbital movements of all LEO satellites and their attached data center, including LEO satellite 202 and data center 210, using the physical parameters retrieved in block 354. By way of example, based on a plurality of locations of LEO satellite 202 at different times, the processor can determine orbit path 204 shown in FIG. 2. The processor can also determine orbit paths for different LEO satellites orbiting around Earth. In an aspect, different LEO satellites can have differential orbital characteristics. For example, different LEO satellites can orbit around Earth along their respective orbit path with different speeds. The processor can be configured to determine different orbital characteristics and movements of different LEO satellites using the physical parameters.

At block 362, the processor can map the activation time windows determined at block 358 to the orbital movements determined at block 360. In one embodiment, the processor can run policy to timeline mapper 322 shown in FIG. 3 to perform block 362.

In response to identifying locations that are above activation region 224, the processor can analyze orbital movements of LEO satellite 202 to determine a time window in which LEO satellite 202 orbits to the identified locations. By way of example, if LEO satellite 202 is within the identified locations 7 AM to 11 AM, then the processor can determine that server 220 can provide coverage for the public transportation application for activation region 224 at the time window 7 AM to 11 AM. If LEO satellite 202 is within the identified locations 4 AM to 8 AM, then the processor can determine that server 220 can provide coverage for the public transportation application for activation region 224 at the time window 6 AM to 8 AM since the times 4 AM to 6 AM is outside of the activation time window of the public transportation application. These coverage times determined by the processor can be stored as workload expectation data 324 in memory 301.

Further, additional servers in data center 210 different from server 220 can be assigned to run applications 222. If applications 222 include the public transportation application, and the processor can determine that morning commute hours, such as 7 AM to 9 AM, is a peak workload time period of the public transportation application, the processor can identify the additional servers to run the public transportation application during the peak workload time period with server 220 simultaneously.

In one embodiment, more than one LEO satellite can orbit along respective orbit paths that can also include locations above activation region 224. When multiple LEO satellite data centers orbit to locations above activation region 224, the LEO satellite data centers can form a mesh network to provide coverage for devices in activation region 224. The LEO satellite data centers forming the mesh network can change over time since different LEO satellite data centers can have different orbital characteristics. For example, some LEO satellite data centers in the mesh network can leave activation region 224 first while new LEO satellite data centers can reach activation region 224 to join the mesh network. LEO satellite data centers forming the mesh network can communicate with one another using inter-satellite links. By way of example, if the processor determines that servers in data center 210 may only cover 7 AM to 11 AM, the processor can communicate with other LEO satellite data centers to seek coverage for activation region 224 from 6 AM to 7 AM and from 11 AM to 12 AM.

In response to determining the coverage of activation region 224 by data center 210 and other LEO satellite data centers, the processor can run a scheduler, such as scheduler 308 shown in FIG. 3, to schedule activation of applications based on the determined coverage. By way of example, if data center 210 can cover 7 AM to 11 AM for the public transportation application, the processor can run scheduler 308 to schedule server 220, and other servers assigned with the public transportation application, to activate the public transportation application 7 AM to 11 AM. The processor can also communicate with other processors in other LEO satellite data centers that provides coverage from 6 AM to 7 AM and 11 AM to 12 AM.

In one embodiment, if two applications have overlapping peak workload time periods, then the processor can run the scheduler to assign different servers to run the two applications separately during the peak workload time periods. By way of example, if the public transportation application and the meal delivery application have overlapping peak workload time periods at 6 PM to 8 PM, then the processor can run the scheduler to schedule server 220 to run the public transportation application and another server to run the meal delivery application from 6 PM to 8 PM.

At block 364, the processor can allocate resources in data center 210 to different applications in application space 212. In one embodiment, the processor can run resource manager 326 shown in FIG. 3 to manage availability of resources for allocation. Further, in block 364, the processor can run application examination 316 shown in FIG. 3 to determine the type of resources that may be suitable for applications in application space 212. Also in block 364, the processor can run resource group generator 328 shown in FIG. 3 to generate a plurality of resource groups. A resource group can include at least a network resource, a compute resource, and a storage resource. Examples of resource groups are shown in FIG. 5.

Network resources can be resources for network communications such as network cards, transceivers, switches, or other network communication equipment. Compute resources can be resources for computations such as processors, processor cores, microprocessors, processing pipelines, application specific integrated circuits, or other computing resources. Storage resources can be memory devices including volatile and non-volatile memory devices, caches, registers, or specific groups of memory addresses. Further, one or more resource groups, can be end-to-end component groups, which can be a group of components allocated to an application for the application to utilize from a start of the application to an end of the application. In other words, applications may not be switching resource groups while being run by their assigned servers.

In response to generating resource groups, the processor can run a resource group allocator, such as resource group allocator 330 shown in FIG. 3, to allocate different resource groups to different applications in application space 212. The resource group allocator can allocate resource groups such that applications running at the same time may not have overlapping resource groups. By way of example, if the public transportation application and the meal delivery application have overlapping activation time windows, such as 9 AM to 9 PM, then resource group allocator 330 can allocate a first resource group to the public transportation application and can allocate a second resource group to the meal delivery application.

At block 366, the processor can optionally rebalance or optimize the workload scheduled by the scheduler, such as scheduler 308 shown in FIG. 3. In an aspect, the workload of applications in application space can change over time, thus changing workload of the servers in data center 210 as well. In one embodiment, to perform rebalance or optimization, the processor can make changes to the allocated resource groups. For example, if a first application's workload is reducing over time and a second application's workload is increasing over time, and if a resource group with stronger processing power is already allocated to the first application, then the processor can rebalance by reallocating the resource group with stronger processing power to the second application and another resource group with weaker processing power to the first application.

At block 368, if there are any changes to any applications in application space 212, the processor can update various information that are retrieved and determined in process 350. In one embodiment, the processor can detect, such as via APIs 304 and platform interface 302 shown in FIG. 3, changes to applications in application space 212. In response to detection of the changes, the processor can issue an interrupt to process 350 and restart process 350 to acquire new information, such as new workload information and activation windows, to update workload expectations, mappings, and reschedule server activations.

FIG. 5 also shows an allocation example of six applications, labeled as App 1, App 2, App 3, App 4, App 5, App 6. Some of the six applications can be activated at different activation regions Loc 1, Loc 2, Loc 3. By way of example, App 1 and App 6 can be activated in activation region Loc 1, App 3 and App 4 can be activated in activation region Loc 2, and App 2 and App 5 can be activated in activation region Loc 3. A resource group 380 can be allocated to App 1, App 2 and App 4, a resource group 382 can be allocated to App 3 and App 6 and a resource group 384 can be allocated to App 5. Note that since App 1, App 2 and App 4 are being activated in different activation regions, one application among App 1, App 2 and App 4 can use resource group 380 at one activation region. Further, App 1 and App 6 are allocated with different resource groups 380, 382 and thus, at activation region Loc 1, App 1 and App 6 would not be sharing resources and the server running these applications can achieve balanced workload.

In one embodiment, a particular resource group can be assigned to multiple applications in the same activation region, where the multiple applications may not have overlapping activation time window. By way of example, a first application can have an activation time window of 7 AM to 8 AM and a second application can have an activation time window of 9 AM to 11 AM. A resource group can be allocated to both the first application and the second application and the first and second applications can utilize the resource group at their respective activation time windows.

In one embodiment, processor 214 can run location to resource mapper 318 (“mapper 318”) to map allocated resource groups to activation regions. Using FIG. 5 as an example, resource group 380 can be mapped to Loc 1, Loc 2 and Loc 3. resource group 382 can be mapped to Loc 1 and Loc 2, and resource group 384 can be mapped to Loc 3. Processor 214 can run scheduler 308 to ensure that a resource group mapped to an activation region is available when LEO satellite 202 orbits to the activation region. For example, as LEO satellite 202 leaves Loc 1 and enters Loc 2, resource groups 380, 382 may need to reset specific parameters and settings to prepare for running applications App 4 and App 3 at Loc 2. Scheduler 308 can schedule activation of servers that run applications App 4 and App 3 at Loc 2 at a time that allows sufficient time for resource groups 380, 382 to reset.

In response to allocating different resource groups to different applications, processor 214 can run scheduler 308 to update the assignments and schedules of servers in data center 210 to run the applications. By way of example, scheduler can schedule server 220 to use the first set of resources to run the public transportation application during the time window 7 AM to 11 AM (e.g., when LEO satellite 202 is above activation region 224) and schedule server 220 to use the second set of resources to run the meal delivery application during the same time window 7 AM to 11 AM. Thus, scheduler 308 can schedule expected workload according to activation time windows and resource allocations.

In one embodiment, to perform rebalance or optimization, the processor can perform a cross-group resource reallocation where individual resource in resource groups are reallocated instead of reallocating entire resource groups. For example, if a first application's workload is reducing over time and a second application's workload is increasing over time, and if a resource group having a stronger compute resource is already allocated to the first application, then the processor can rebalance by swapping the compute resource in the first application's resource group with the compute resource in the to the second application's resource group such that the second application can utilize the stronger computer resource.