Setting up and starting a cluster
💰 Feature available with subscription to Yucca Enterprise
Introduction
This guide describes how to set up a Yucca cluster of 3 nodes. You'll need Yucca and Postgres installed, since cluster mode only works with this database. You'll also need a license for the required number of nodes.
Starting
To run Yucca in cluster mode, you need to enable the mode itself and specify the addresses that the servers will use to communicate with each other. We'll need to define the following parameters:
--cluster=true- Enables cluster mode.--cluster-advertise-address=127.0.0.1:9941- specifies the address at which other cluster members can reach this server.--cluster-listen-address=:9941- specifies which port to listen on for requests from cluster members.
Parameters can also be set via the configuration file or environment variables
As an example I'll run everything locally on 1 computer, whereas in a working environment these would be different physical servers.
Note that when running on a single node, servers must have a different state_dir,
since a cluster_node_id file is created in this directory, containing the server's unique identifier in the cluster.
Do not delete or modify this file. The server uses this ID to identify itself in the cluster,
and if it's deleted, the server will try to join the cluster as a new node and all previously configured cameras will be ignored.
If you move a cluster node to different hardware, be sure to move this file as well.
Let's start the first Yucca node in the cluster:
/opt/yucca/yucca server \
--data-dir=/opt/yucca/data/cluster/data1 \
--database-type="postgres" \
--telemetry=false \
--smtp-server=false \
--cluster=true \
--cluster-advertise-address=127.0.0.1:9941 \
--cluster-listen-address=0.0.0.0:9941 \
--log-level=debug \
--web.listen-address=0.0.0.0:9911
The second Yucca instance in the cluster:
/opt/yucca/yucca server \
--data-dir=/opt/yucca/data/cluster/data2 \
--database-type="postgres" \
--telemetry=false \
--smtp-server=false \
--cluster=true \
--cluster-advertise-address=127.0.0.1:9942 \
--cluster-listen-address=0.0.0.0:9942 \
--log-level=debug \
--web.listen-address=0.0.0.0:9912
The third Yucca instance in the cluster:
/opt/yucca/yucca server \
--data-dir=/opt/yucca/data/cluster/data3 \
--database-type="postgres" \
--telemetry=false \
--smtp-server=false \
--cluster=true \
--cluster-advertise-address=127.0.0.1:9943 \
--cluster-listen-address=0.0.0.0:9943 \
--log-level=debug \
--web.listen-address=0.0.0.0:9913
Next, open the interface of all 3 servers. We'll see the database initialization page on one of the servers – the one that managed to become the leader. The leader is a special server role in the cluster, responsible for a lot of operations and status tracking in the cluster, while still being a regular member that also hosts cameras, and so on. If the current leader suddenly becomes unavailable, another node will immediately take its place. This way, the cluster always has a leader. All the other nodes are members or candidates and wait for the leader to allow them to join the cluster.
- Leader
- Candidate
After initialization, add the license:
Note that I specified a license for a 2-node cluster while running 3 nodes
The leader also keeps track of quotas. If your license quota is for 2 nodes in the cluster and you try to add a 3rd, the new node will remain in the candidate awaiting to join status but won't be able to join the cluster.
The leader checks quotas not only at startup but also during operation. For example, if you apply a license with a quota of 10 nodes, configure everything, and then apply a license with a quota of 3 nodes, the leader will notice this and drain (take out of service) the extra nodes. The extra nodes are chosen at random.