You can deploy RabbitMQ in a cluster configuration on a minimum of three standalone machines.
What you should know
- 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.
(N/2)+1, where N is the number of
nodes.
| 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 |
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.