Skip to content

Scaling and adding capacity

Domino Workspace scales horizontally — by adding servers to a role as the user population grows. This topic covers when to add capacity and how to do it. For the fixed server set and naming rules, see Domino server topology.

Reference point

A Kubernetes cluster of roughly 110 CPU, 800 GB RAM, and 6 TB of storage supports around 6,000 users across the full Domino Workspace stack. Per-role Domino resource and volume defaults are in System Requirements.

Use the signals below to decide when to add capacity.

When to add capacity

Watch these on the Domino Grafana dashboards (shipped with the chart, grafana.dashboards.enabled):

  • Mailbox count and mail-file storage per server — approaching the provisioned mailStorageA / mailStorageB size, or DAOS volume filling.
  • CPU and memory saturation — a server sitting near its configured limit under normal load.

Adding a mail cluster

A mail cluster is a dom-mailNNa / dom-mailNNb pair. To add cluster 03:

  1. Add the server entries to your environment values file, under servers::
servers:
  dom-mail03a:
    enabled: true
    register: true
    type: mail
    storage: 50Gi
    mailStorageA: 200Gi
    mailStorageB: 200Gi
    daosStorage: 100Gi
    nifnsfStorage: 80Gi
    requireNodeLabels: { topology.kubernetes.io/zone: zone-a }
  dom-mail03b:
    enabled: true
    register: true
    type: mail
    storage: 50Gi
    mailStorageA: 200Gi
    mailStorageB: 200Gi
    daosStorage: 100Gi
    nifnsfStorage: 80Gi
    requireNodeLabels: { topology.kubernetes.io/zone: zone-b }

Size mailStorageA / mailStorageB / daosStorage for the share of users this cluster will carry. Pin each server to its zone with requireNodeLabels (or to a specific node with nodeSelector) — see High availability.

  1. Upgrade the release:
helm upgrade --install domino \
  oci://hclcr.io/hcl-domino-workspace-communicate/domino/charts/domino \
  --version <version> \
  --namespace <namespace> \
  -f <your-values.yml> \
  --timeout 30m

With register: true, admin pre-creates each new server's .id file as part of its own OTS processing, and a post-upgrade hook Job extracts it into a Secret. The APISIX failover and mobile upstreams are regenerated from the full server list automatically, so the new servers are added to the fallback pools without further changes. See Server .id extraction.

  1. Wait for the new pods to complete One-Touch Setup (first boot of a mail server can take 15–20+ minutes — see Startup behaviour).

Adding capacity to other roles

The same pattern applies to files, ontime, and ldap:

  • Add servers.<name> entries with the next instance number (dom-files02a, dom-files02b), set type, storage, and zone placement, and run helm upgrade.
  • The chart default already defines dom-files01a–dom-files01d; bringing an extra file server online can be as simple as flipping enabled: true on one that is already registered.

admin and srvmgr are single-instance roles and are not scaled out.

Scaling a server vertically

To give an existing server more CPU or memory, set servers.<name>.resources and run helm upgrade:

servers:
  dom-mail01a:
    resources:
      requests: { cpu: "1", memory: 16Gi }
      limits:   { cpu: "6", memory: 32Gi }

The StatefulSet pod restarts to pick up the new limits. Use sequentialRollout to roll a change across paired servers one zone at a time.