Skip to content

Compute Resources

This document explains how much CPU, memory, and storage Sovereign Home Cloud needs, and how to size the nodes it runs on.

Workloads to Size

Workload Runs Count
Control plane The Cloud Console, the Ops UI and every service behind them, in one Java process One
Bundled data stores PostgreSQL, OpenSearch, Valkey and the object store, when you do not bring your own One each
In-cluster event broker The control plane's own event broker, when you do not use an external one One
Datacenter agent Manages a datacenter's event broker services One per datacenter
Event broker services Your event broker services One or more pods each, depending on the service class

The control plane and the bundled data stores are a fixed cost. Event broker services grow with the number of services you create, and usually dominate the cluster's size.

These are the chart's defaults:

Workload CPU request CPU limit Memory request Memory limit Volume
Control plane 2 3 8 GiB 8 GiB —
PostgreSQL 250m 1 512 MiB 1 GiB 8 GiB
OpenSearch 250m 1 1 GiB 2 GiB 8 GiB
Valkey 100m 500m 256 MiB 512 MiB 8 GiB
Object store 200m 500m 128 MiB 512 MiB 20 GiB
In-cluster event broker 1 2 3 GiB 8 GiB 10 GiB
Datacenter agent 500m 500m 768 MiB 768 MiB —

Totals with everything bundled and the default datacenter: about 4.3 CPU and 13.6 GiB of memory requested, and 54 GiB of volumes, before any event broker services.

Change a workload's sizing with its resources value, for example composite.resources for the control plane, broker.resources for the in-cluster event broker, or dataLayer.opensearch.resources.

The control plane's memory

The control plane's Java heap is 70% of its memory limit; the rest holds everything else the process needs. Raise the limit and the heap grows with it. Keep a memory limit on the control plane: without one, the heap is sized from the whole node's memory.

If the control plane is restarted with exit code 137 and no error in its own log, the container ran out of memory. Raise composite.resources.limits.memory.

Event Broker Service Sizing

Each event broker service's resources come from its service class, chosen when the service is created. For example, a developer-class event broker service requests:

Container CPU request CPU limit Memory request Memory limit
Event broker service 1.05 2 7.0 GiB 7.0 GiB
Monitoring sidecar 200m 500m 256 MiB 1 GiB

It also gets two volumes: 20 GiB for data and 32 GiB for its message spool. Larger service classes need more of each, and high-availability classes run more than one event broker pod.

Node Sizing

  • Requests decide where pods fit. A pod is scheduled only on a node with enough unrequested CPU and memory. The control plane alone needs a node with at least 2 CPU and 8 GiB of memory available to pods, after what the node reserves for itself.
  • Leave room for event broker services. Plan capacity for the event broker services you expect to create, not only for Sovereign Home Cloud.
  • Leave room to move. In Early Access, every Sovereign Home Cloud workload runs as a single replica. When a node fails or is drained, its pods are rescheduled onto the remaining nodes, which need enough free capacity to take them.
  • Volumes are per zone. On clouds where volumes are tied to an availability zone, a stateful pod can only be rescheduled to a node in the same zone as its volume.

As an example, an evaluation with every data store bundled, the in-cluster event broker, two datacenters and two developer-class event broker services ran on four nodes of 4 vCPU and 16 GiB each.

Replicas and Availability

Every Sovereign Home Cloud workload runs as one replica in Early Access, and the control plane cannot be scaled out. While its pod restarts or is rescheduled, the Cloud Console, the Ops UI and the API are unavailable; event broker services keep serving messages. For data stores that survive a node failure, use your own replicated ones; see Installing for Production.

Next Steps