Skip to content

Multisite Cloud

Expose multiple distinct cloud sites as one schedulable environment while preserving site identity so placement, data movement, policy, latency, and failure-domain tradeoffs remain explicit.

Version
v2 · 2026-09-06 · History
Domain-specific #
2336
Origin domain
computer science
Subdomain
distributed cloud computing
Aliases
Multi-site cloud, Multi-datacenter cloud, Cross-site cloud

Core Idea

A multisite cloud is a cloud-computing environment composed of multiple explicitly distinguishable sites—typically data centers or regions, under one or several providers—that a user or scheduler can employ within one workload or workflow. The abstraction preserves site identity because compute capacity, data, policy, cost, latency, and failure are not uniform across the combined environment.

NIST's cloud definition supplies the shared resource, elasticity, service, and metering baseline.[1] Multisite architecture adds a placement layer over more than one administrative or failure location.

Structural Signature

  • Two or more separately located cloud sites or data centers.
  • A resource and service inventory for each site.
  • A user, broker, or scheduler able to address multiple sites.
  • Workload decomposition into tasks, services, or replicas.
  • Placement decisions constrained by site capability and policy.
  • Data location, transfer cost, and inter-site bandwidth.
  • Site-specific latency, price, jurisdiction, trust, or hardware.
  • Failure domains and a declared resilience objective.
  • Identity, credentials, networking, and observability across sites.
  • A coordination plane that does not erase local control.
  • Reconciliation of workload state after delay, partition, or site loss.

What It Is Not

It is not merely a provider owning several buildings, because the sites must matter to user-visible placement or operation. It is not synonymous with multi-cloud, which emphasizes multiple providers, nor hybrid cloud, which joins distinct deployment models such as private and public. It is not automatically a single strongly consistent cluster, and geographical spread alone does not guarantee resilience.

Scope of Application

Multisite clouds support scientific workflows, disaster recovery, latency-sensitive services, regulatory placement, capacity bursting, and geographically distributed data processing. Liu and colleagues identify data placement, scheduling, provenance, reliability, and transfer as coupled concerns in data-intensive scientific workflow management.[2] Deelman and colleagues show how workflow systems separate abstract dependencies from resource-specific execution planning.[3]

Clarity

List sites, providers, regions, trust boundaries, identity domains, service compatibility, data residency, network topology, consistency model, placement authority, and failure assumptions. Distinguish active-active service, active-passive recovery, independent workflow task placement, and opportunistic bursting; they impose different coordination requirements.

Manages Complexity

The model makes heterogeneity schedulable. Rather than pretend resources are one uniform pool, it exposes site as a decision variable and lets the planner trade data movement against compute availability, latency, price, policy, and resilience.

Abstract Reasoning

  1. Inventory site capabilities, limits, identities, and policies.
  2. Map task dependencies and data locations.
  3. Define hard placement constraints before optimizing preferences.
  4. Estimate compute time, queue delay, transfer time, and egress cost.
  5. Select placements and replication levels.
  6. Establish cross-site authentication, routing, and observability.
  7. Define consistency and recovery behavior under partition or loss.
  8. Schedule, monitor, and re-plan as availability changes.
  9. Validate that correlated dependencies do not defeat claimed site independence.

OpenStack's multi-site guidance emphasizes that regions and availability zones are architectural and operational boundaries, not interchangeable labels.[4]

Knowledge Transfer

The portable pattern is coordinate a shared workload across multiple explicit sites without collapsing the differences that make placement consequential. It transfers to grid computing and edge–cloud systems. The proposed immediate parent is Network.

Examples

A scientific workflow may keep a large dataset at one site, run data-intensive stages there, and send smaller derived products to a second site with specialized accelerators. A service may place replicas in two regions but keep writes anchored to one region under a declared failover policy.

Two virtual machines in one data center do not form a multisite cloud. Conversely, two sites owned by the same provider can qualify when they are separately addressable placement and failure domains.

Structural Tensions

  • Unified access versus site-local autonomy.
  • Compute availability versus data-movement cost.
  • Geographic redundancy versus correlated control-plane dependency.
  • Strong consistency versus partition tolerance and latency.
  • Portability versus provider-specific capabilities.

Structural–Framed Character

Distributed placement and coordinated execution are structural. Clouds, data centers, provider APIs, site policies, workflows, and inter-site networks are constitutive. The identity is domain-specific.

Structural Core vs. Domain Accent

The structural core is multiple heterogeneous sites -> explicit placement -> coordinated execution -> failure-aware recovery. The domain accent is cloud-computing resources and APIs.

Network is the proposed immediate parent. Orchestration, Distribution, Dependency Distribution Concentration, Locality, and Resilience are related primes. AI Infrastructure is a workload-specific neighbor.

The prospective queue contains one strict edge to prime:network. No live DAG mutation is authorized.

Relationships to Other Abstractions

Local relationship map for Multisite CloudParents appear above the current abstraction, mutual partners to the right, and children below. Node labels state whether each abstraction is prime or domain-specific; colors identify relation types.Multisite CloudDOMAINPrime abstraction: Network — is a kind ofNetworkPRIME

Current abstraction Multisite Cloud Domain-specific

Parents (1) — more general patterns this builds on

  • Multisite Cloud is a kind of Network Prime

    Network is the proposed immediate parent.

Hierarchy path (1) — routes to 1 parentless root

Neighborhood in Abstraction Space

Multisite Cloud sits in a sparse region of the domain-specific corpus (99th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Unclustered & Miscellaneous (1565 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-09-08

Not to Be Confused With

  • Multi-cloud.
  • Hybrid cloud.
  • One provider's opaque internal replication.
  • One cluster spanning racks in a single failure site.
  • Content-delivery network.
  • Grid computing as the broader federated-resource tradition.

References

[1] Peter Mell and Timothy Grance, The NIST Definition of Cloud Computing, NIST SP 800-145 (2011), doi:10.6028/NIST.SP.800-145. registry ↩

[2] Ji Liu, Esther Pacitti, Patrick Valduriez, and Marta Mattoso, “A Survey of Data-Intensive Scientific Workflow Management,” Journal of Grid Computing 13 (2015): 457–493, doi:10.1007/s10723-015-9329-8. registry ↩

[3] Ewa Deelman et al., “Pegasus, a Workflow Management System for Science Automation,” Future Generation Computer Systems 46 (2015): 17–35, doi:10.1016/j.future.2014.10.008. registry ↩

[4] OpenStack Foundation, OpenStack Architecture Design Guide: Multi-Site, 2021 documentation edition. registry ↩