RabbitMQ deployment option: standalone clusters - Genetec Mission Control™

Genetec Mission Control™ Deployment Guide

Applies to
Genetec Mission Control™
Last updated
Content type
Guides > Deployment guides
English (United States)
Genetec Mission Control™

You can deploy RabbitMQ in a cluster configuration on a minimum of three standalone machines.

What you should know

This deployment architecture requires a minimum of three standalone machines (nodes). They must all be on the same local area network (LAN).
NOTE: Cloud deployment is currently not supported for Genetec Mission Control™.
For this method of deployment to work the following requirements must be met:
  • The network between the nodes should be reliable, have a high performance threshold, and have low latency.
  • If deploying nodes in separate geographical regions, you must be able to guarantee the above metrics. For example, most cloud providers have very reliable links between their data centers.
  • The nodes should be on different server racks for better tolerance if deployed on-premises.
  • While more nodes improve resilience, they do not improve performance.

It is recommended that you have thorough knowledge of RabbitMQ configurations. For details, see the official RabbitMQ documentation.

High availability in RabbitMQ clusters

In a three-node cluster, losing one node even when the other two nodes are running causes a degradation in performance.

The high availability configuration of RabbitMQ uses the Raft Consensus algorithm which involves multiple servers agreeing on values.

In this scenario, this translates to having more nodes active than offline for effective operations. The formula to calculate the number of nodes you would need for effective system availability is (N/2)+1, where N is the number of nodes.
Active RabbitMQ cluster scenarios
Number of nodes in cluster Number of nodes that must be available Number of node failures supported
1 1 0
2 2 0
3 2 1
4 3 1
5 3 2
6 4 2
7 4 3
NOTE: It is imperative that all the nodes have an active link for communication between them for the Raft Consensus algorithm and therefore your cluster to work.

The bigger the cluster, the more impact it has on performance. When nodes fail and the cluster is performing in a degraded state, the performance would be greatly reduced.

To set up high availability for RabbitMQ, see Configuring high availability for RabbitMQ.

Benefits: RabbitMQ standalone clusters

High availability
Interruption to operations is minimal, even if a node is down.
RabbitMQ resources are not shared
Other services do not use the same resources and therefore do not impact RabbitMQ performance or availability.
No downtime for rolling updates
You can update the RabbitMQ setup one node at a time without affecting service availability.

Drawbacks: RabbitMQ standalone clusters

Highly complex deployment
RabbitMQ must be deployed on a minimum of three nodes. The deployment process is long and involved.
High maintenance
In the rare event that a whole cluster goes offline because of multiple network partitions, you must manually fix the issue. It is recommended to have good knowledge of RabbitMQ configurations and diagnostics.

For details, see the official RabbitMQ documentation.

Quality of service

Using this deployment architecture implies that service quality relies more on your system infrastructure. The quality of service would be directly dependent on the quality and reliability of your network infrastructures.