Clusters

A cluster is one contact centre: its numbers, its queues, its agents and its reporting. It can be one server or several, and every server in it — a node — works as part of the same whole.

Several contact centres that must stand on their own are several clusters.

More servers, one contact centre

Three servers, one cluster. Agents share the same queues and the same reporting whichever server they happen to be connected to, and a caller reaches an agent regardless of which server took the call.

Everything is shared: a queue is the same queue on every server, an agent belongs to the cluster rather than to a machine, and the reporting is one set of numbers. A caller who arrives on one server reaches an agent connected to another without anybody arranging it.

The first server holds the shared parts. The others join it. That is the only asymmetry, and it is why the order below matters.

On the first server

Bring it up exactly as in your first server:

sudo xema init

That also generates the passwords the nodes use to trust each other. Then mint a pass for the next machine — single use, and it expires:

sudo xema cluster token

On every other server

Install Xema, then copy the cluster's key ring from the first server — every secret the cluster holds is encrypted with it, and a node with a different one could read none of them:

sudo scp <first server>:/etc/xema/keyring.pfx /etc/xema/keyring.pfx

Then join, saying what this server is for:

sudo xema join <the pass from above> --address <this server's IP address> \
               --roles bff,queue,astermq,fastlane

A joining server arrives holding nothing it was not given: whatever it ran before is not read, because it was not chosen for this cluster. It fetches what its roles need, joins, and starts them. Add dialer if it calls out, bridge if agents transfer, conference or are coached here.

Check it

xema cluster status

Every node should be listed, each one seen within the last minute.

Several contact centres

Two clusters, each complete on its own, each carrying on with its own callers and its own agents whatever happens to the link between them.

Separate clusters when the places are genuinely separate — different cities, different customers, different hours — and each has to carry on alone if the connection between them drops.

Each is built exactly as above: its own first server, its own xema init. They share nothing, so losing the link between them costs neither anything. Answering one cluster's callers from another cluster's agents is not part of Xema yet; within a cluster, any node's agent can take any node's call.

Choosing

	Servers	Clusters	Use it when
One server	1	1	Almost always. Start here.
One cluster, several servers	2+	1	More calls than a machine will carry
Several clusters	any	2+	Places that must carry on without each other

The honest advice: start with one server. Adding capacity later is a join, not a migration, and guessing at scale before you have it costs more than the second machine would.

Taking one out

sudo xema cluster remove <server>     # on a server that stays: takes the other out, hands over its trunks
sudo xema node reset                  # on the one leaving: removes what it runs, keeps its databases
sudo xema init                        # then, on it, if it is to be a cluster of its own

Anything the departing machine was responsible for moves to a machine that stays, rather than being left pointing at something that has gone.