STRATUM Continuum at the Edge

STRATUM Continuum treats cloud, datacenter, laboratory, and edge infrastructure as one operational environment. The network follows the mission, storage is placed where the workload needs it, compute is assigned to the right site, and the controller provides a common way to understand and operate the environment whenever connectivity permits.

Mission infrastructure can continue operating at the edge even when the path back to the controller changes. The same STRATUM architecture can extend from core datacenters to ships at sea, aircraft in flight, remote industrial sites, satellites in orbit, and other platforms where connectivity may be constrained or intermittent.

Infrastructure may be anywhere, and the available transport may change over time. A Continuum worker joins the environment using its authenticated identity and an outbound control connection to the STRATUM controller. Each worker is associated with a site, its available resources, and its execution capabilities. An operator can place VMs on eligible workers or target a specific region, vessel, installation, field deployment, or orbital platform.

This gives operators a single mission-wide view while workloads execute where they belong:

• Centralized control: Organize datacenters, sites, topology, templates, compute, and execution from STRATUM.
• Site-aware placement: Assign workloads to the worker or site where mission conditions require them.
• Local execution: Run compute at the edge instead of backhauling every operation to a remote datacenter.
• Portable networking: Extend STRATUM virtual networks across eligible Fabric-connected hosts without rebuilding the mission topology for each physical location.
• Site-local storage: Keep VM disks near the compute that needs them by using STRATUM Storage Fabric.

A satellite pass, a vessel beyond reliable coverage, a submerged platform, an aircraft in transit, or a distant industrial installation may have periods of limited or unavailable controller connectivity. STRATUM separates connectivity from compute placement so the remote site's local architecture remains intact through those changes.

When connectivity is available, workers authenticate, report their current status, and receive execution commands. When a link drops, the controller can mark the worker Offline while retaining the site's definitions, workload intent, topology, and storage placement in the STRATUM environment.

For properly provisioned edge systems, local compute and local storage make disconnected operation practical. A workload that depends on a shipboard VM disk should use shipboard Storage Fabric. A local application can then continue its work independently of the remote management connection, subject to its local service dependencies.

When the link returns, the worker reconnects and reports its environment. Operators regain access to management actions, consoles, and available services. Execution Fabric jobs already accepted into the QUEUED state can remain pending for eligible site or worker capacity and be scheduled when that capacity returns.

The most important preparation for a disconnected site is simple: place the workload's storage at the site where the workload will run.

STRATUM Storage Fabric provides virtual Storage Bins for placing VM images onto storage nodes. For a ship, submarine, oil rig, aircraft support site, or other remote installation, create a storage node at that location and make it the destination for the site's VM images.

1. Deploy the site's compute and storage nodes. Enroll them in STRATUM Continuum and assign an appropriate site identity.
2. Assign the necessary VM images to that site's Storage Fabric bin. Use Storage Fabric to select images and place them in the destination bin.
3. Select Bake Storage. STRATUM transfers and verifies the replicas before they are used for new remote VM attachments.
4. Deploy or start VMs with site-local storage bindings. STRATUM workers access the selected storage directly through its Continuum Storage endpoint; the controller does not proxy VM disk I/O.
5. Keep dependent services local too. DNS, authentication, application services, and other runtime dependencies required while disconnected should be planned for the site's operating conditions.

This keeps routine disk I/O independent of WAN availability. STRATUM Storage Fabric uses a direct storage protocol instead of requiring the execution worker to mount an ordinary remote file share.

Plan storage placement before a VM's first start. Changing a Storage Bin assignment prepares placement for new VM storage bindings. Existing writable VM disks move through a controlled storage migration before their bindings change.

High availability should match the site's operating conditions. A conventional datacenter with continuously reachable workers can use HA and restart policies suited to that environment.

For a satellite, ship, submarine, aircraft, or other intermittently connected site, an intentional non-HA, site-pinned deployment may be the correct design, keep in mind you are free to have HA within your VMs and applications.

A communications outage can occur while the remote compute hardware remains healthy. In that environment, automatic off-site workload failover may conflict with the mission requirement to keep execution on the original platform. Placement and restart behavior should reflect the site's mission and expected connectivity pattern.

The same STRATUM environment can contain highly available datacenter workloads and deliberately self-contained remote-edge workloads. The operator sets the policy; STRATUM provides the common infrastructure.

STRATUM Continuum exposes per-worker settings for adjusting routine control traffic. Workers send periodic reports, check the published Fabric mesh conditionally, and use startup jitter to avoid synchronized reconnect waves.

The Fabric mesh is built around a full peer list so eligible hosts can participate in STRATUM's distributed networks. Conditional checks, cached mesh publication, and staggered reports reduce unnecessary coordination across ordinary heartbeat intervals.

This keeps the model straightforward: one consistent Fabric with tunable reporting behavior for different communication profiles.

The following is an illustrative host configuration for a site with a constrained or intermittent link. Adjust the site name and reporting intervals for the actual deployment.

These values are per-worker, so a shipboard installation can use different reporting intervals from a datacenter worker. They are starting points for a site's connectivity profile.

The controller's worker-offline threshold and the execution command channel are separate from these reporting settings. Slower reporting may produce an Offline indication during longer interruptions; keep controller-wide timeouts aligned with real operational requirements rather than masking a genuine outage.

1. Create the site. Give the vessel a stable STRATUM site identity such as atlantic-fleet and enroll its compute workers.
2. Establish local Storage Fabric. Add shipboard storage and prepare a Storage Bin with the required VM images using Bake Storage.
3. Pin the workload. Place VM templates, mission networks, and supporting services on the appropriate shipboard worker or site.
4. Choose the right lifecycle policy. Keep automatic off-site HA disabled where intermittent connectivity is expected and the workload is intended to remain aboard. Application-level or guest-level HA can still be used inside that site where the mission requires it.
5. Operate through Continuum. Manage the site when communications are available, retain local compute and disk dependencies during outages, then resume centralized operations when the path returns.

The same pattern applies to airborne mission systems, remote drilling platforms, submarines, field installations, suitably provisioned satellite platforms, and other edge environments.