Cluster

The Cluster area monitors and manages the nodes of a high availability cluster. It adapts to the deployment: a clustered server shows the full cluster console, while a standalone server shows an informational page about this single node. The page is a live status surface and refreshes automatically.

Standalone server

On a standalone server the page explains that all configuration and data live on this single node, and that there are no peers to monitor or manage.

It shows this node's ID and version, and lets you set a friendly description for the node. A short explanation describes how clustering works: a cluster is formed during setup, and when another node joins, the two nodes automatically create the cluster and begin replicating; once a peer joins, this page becomes the full cluster console.

NOTE

High availability clustering may require a higher license edition. When it is not licensed, a notice explains the limit.

Clustered server

In a cluster the page opens with an overview showing this node, the total number of nodes, how many are online, the last replication time, and an overall cluster state (Active, Degraded, or Standalone).

Per node cards

Each node is shown as a card with a status indicator and the node ID (your own node is tagged), plus address, version, uptime, clock drift, last heartbeat, and last sync. A draining or partially draining node is tagged accordingly.

Each card can expand to list the virtual sites running on that node, with their live session counts and current status.

Node actions

Depending on the node and its state, a card offers:

• Force re-sync: forces a full re-sync of all data from a peer node to this node. Use it only when replication has fallen out of sync. This is a disruptive action and asks for confirmation.
• Drain: drains the node so its virtual sites stop accepting new connections while existing sessions finish. A confirmation dialog lists the affected virtual sites and their live session counts.
• Undrain: resumes accepting new connections on the node. This runs immediately.
• Remove node: removes the node from the cluster. This is a disruptive action and asks for confirmation.

Danger zone

A Leave cluster action makes this node leave the cluster and become a standalone server. It will no longer receive replicated data, and this cannot be undone from here. It asks for confirmation.

Data encryption key

Every credential a Syncplify Server! installation stores, from LDAP and SMTP passwords to storage credentials and authenticator seeds, is encrypted at rest with a key unique to that installation. The key is generated on first start and kept in a file beside the database. It is never stored in the database itself, so a copied database, a disk image or a backup archive does not decrypt on its own.

In a cluster all nodes share one key, because they all replicate the same records. Nothing needs to be done to arrange this:

• A node joining a cluster receives the cluster's key as part of joining. If the joining node runs an older version that cannot accept it, the join is refused and the node must be updated first.
• A cluster that has been updated from a version that predates per installation keys receives one automatically, once every member is online and running the new version. Until that happens, the cluster keeps using the previous encryption scheme, exactly as it did before the update, and nothing is degraded while it waits.

NOTE

If cluster members are reported as using different encryption keys, a notification is raised and no automatic change is made. That situation needs support; do not remove or rejoin nodes first, because doing so can make records unreadable.

A node that leaves a cluster keeps the key, so its data stays readable.

Converting existing data

A newly generated key protects everything written from that point on. Records saved earlier remain encrypted with the previous scheme until they are rewritten. To convert them all at once, run on one node:

ss-webrest reencrypt

Secrets already encrypted with the current key are left alone, so the command is safe to repeat and an interrupted run can simply be started again. On a cluster, run it on a single node: the rewritten records replicate to the others normally. Because it rewrites every record that holds a credential, prefer a quiet period on a large installation.