Clusters and multiple sites

Two different things, and the difference decides which one you want.

A cluster is several servers acting as one contact centre. More capacity, one set of queues, one report. A site is a contact centre that stands on its own — its own numbers, its own agents, and its own ability to keep answering when it cannot reach anywhere else.

You can have several servers in one site, several sites of one server, or both.

More servers, one contact centre

Three servers, one site. 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 site 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

Install as in your first server, then:

sudo xema cluster init --site <name>
sudo xema site secret set node-api --generate
sudo xema site secret set node --generate

Those two passwords are how the servers prove themselves to each other. Generate them once, here.

Mint a pass for the next machine — single use, and it expires:

sudo xema cluster token

On every other server

Install, then present the pass:

sudo xema cluster join --token <the string from above>

A joining server arrives holding nothing on purpose. Whatever it happened to be running before is not read, because it was not chosen for this site. Say what it is for:

sudo xema role add bff
sudo xema role add queue
sudo xema role add astermq
sudo xema role add fastlane

sudo xema node apply

Check it

xema cluster status

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

Several contact centres

Two sites, each complete on its own. While the link between them is up a caller in one city can be answered by an agent in the other; when it is down, each carries on with its own callers and its own agents.

Separate sites 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.

While the link is up, a caller in one city can be answered by an agent in the other. When it is down, each site keeps answering its own calls with its own agents and neither waits for the other. Nothing has to be switched over and nobody has to notice.

Each site is built exactly as above: its own first server, its own cluster init, its own name. They are separate by construction, which is the point.

Choosing

	Servers	Sites	Use it when
One server	1	1	Almost always. Start here.
One site, several servers	2+	1	One floor, more calls than a machine will carry
Several sites	any	2+	Places that must survive losing the link to each other
Several sites, several servers each	2+ each	2+	Large operations across locations

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

A server can be removed from a site, and a site can be reduced to one server:

sudo xema cluster remove <server>     # run on a server that stays
sudo xema cluster reset --site <name> # run on the one leaving, to make it its own site

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