Architecture · Reliability & operations

Keeping every deployment running.

Reliability in Oasis Stack is about the partner’s physical deployment: the infrastructure at every site, watched through Observa, with capacity managed and the federation kept informed. The partner runs it, or contracts the Oasis Stack team to, as a shared responsibility.

Across your deployments Talk to an architect

Scope: Your physical deployments
Watched by: Observa and Amin
Run by: You, the Oasis Stack team, or both
Status: Shared across the federation

Across your physical deployments

The infrastructure, watched and managed at every site.

The same control and management across every physical deployment the partner runs, so the cloud stays up for the partner’s customers and for the federation.

Infrastructure control

The local physical infrastructure — compute, storage and network — controlled and managed across every site, from one platform.

Monitoring and observability

Observa, CloudHost’s observability stack, watches health, performance and security signals; its wellness dashboard is built on Grafana, Prometheus and Wazuh.

Capacity management

Where headroom is running out, what to add and when, with Amin reading the signals before an order cannot be fulfilled.

Status across the federation

Issues and their status are shared across the federation, so other clouds know what affects the services they consume.

Status page and notifications

A status page for customers, notifications when something affects them, and SLA credits when service levels are missed.

Support, routed

Support cases are raised in the built-in helpdesk and routed between federated clouds when a service runs in another partner’s region.

How Amin works

Who runs it

You, the Oasis Stack team, or both.

Operating a deployment is a shared responsibility between the partner or customer and the Oasis Stack team.

Run it yourself

Your own teams operate the deployment, with the platform’s tools.

Outsource it

The Oasis Stack team operates it for you, under a support contract.

Shared responsibility

What the partner or customer holds and what the Oasis Stack team holds is set out in the support contract.

The operating model

Failure behaviour

What happens when something is unavailable.

Each part of the architecture fails differently. These are the behaviours the design is built around.

If this is unavailable

What it affects

What happens

The management plane

Portals, APIs and Oasis Core

Running workloads keep running on the infrastructure underneath. The management layer orchestrates; it does not carry them.

The link to the admin centre

Licences, releases and transactions

Financial and contractual transactions and new publishing wait for the link to return; workloads are not affected. The admin centre itself runs across multiple locations, in redundancy.

A federated partner cloud

Services you consume from it

Degraded, not broken: your own services never depended on it, and they keep running.

An integrated technology, mid-request

Provisioning that fails halfway

The platform reconciles against what the technology reports, rather than leaving an orphaned resource.

A site

The workloads placed there

Workloads recover to the site chosen for them, and recovery is run from the same console as everything else.

Recovery

Designed per workload, not per platform.

Recovery targets are set per workload: another site of your own, a partner Oasis cloud by agreement, or, for the non-sensitive workloads you select, a public cloud through the integrations with Acronis Cloud and Commvault. A DR site can be a full deployment, or Oasis Edge Cloud built only for the critical workloads.

Recovery is ordered, tested and governed like any other service, and run from the same console operators use every day.

Business continuity, in detail

Releases and upgrades

Installed for you. Upgraded centrally.

Installed by the Oasis Stack team

Modules are deployed as separate deployments above infrastructure that is already running.

Rolled out centrally

Version upgrades are released through the Oasis Stack admin centre by the central team. Air-gapped deployments are installed and upgraded on site by the Oasis Stack team: Licences, updates and patches are carried in by Oasis Stack team members, on USB or as encrypted files, and VirtueSuite, Observa and Oditr run fully inside the deployment.

Signed and itemised

Releases are signed and come with a software bill of materials, so a deployment can verify what it installs.

Validated against releases

Integrations are validated against specific releases of the technologies beneath the platform.

Deferred, or refused outside the federation

An operator can defer an upgrade. A deployment outside the federation network can also refuse one; a deployment in it cannot.

Designed per deployment

Management-plane availability and scale are designed for each deployment, from the partner’s deployment guide and chosen modules.

The same platform everywhere

An edge site and a national cloud stay on the same platform, because both are upgraded the same way.

Review the architecture with your team.

Walk the failure scenarios with an architect.

Bring the workloads that cannot stop. We will walk what happens to each, and where it recovers to.

Talk to an architect Business continuity