How to Build a High‑Availability RabbitMQ Cluster with HAProxy & Keepalived

Introduction

Any service deployed on a single node has performance limits; RabbitMQ is no exception. When a single RabbitMQ instance reaches its message‑processing bottleneck, a cluster can provide high availability and load balancing.

RabbitMQ Cluster Basics

In a RabbitMQ cluster each service is a node. Nodes can be memory nodes (metadata in RAM, optionally persisting to disk) or disk nodes (metadata stored on disk, at least one required for HA).

Metadata includes queue names, exchange types, bindings, vhosts, but not the actual message payloads.

RabbitMQ supports two cluster modes: classic (ordinary) and mirrored queues.

Classic Cluster Mode

In classic mode nodes only synchronize metadata; messages are stored on a single node. If a client connects to a node that does not hold the queue data, the broker forwards the request to the node that does. However, if the node holding the data fails, the messages are lost, so classic mode does not provide true HA.

Mirrored Queue Mode

Mirrored queues replicate both metadata and message bodies across mirror nodes, offering higher availability at the cost of additional network overhead.

Building a RabbitMQ Cluster

Remove any previous single‑node data, e.g. rm -rf /var/lib/rabbitmq/mnesia or the equivalent path in your installation directory.

Start three RabbitMQ instances on different ports, specifying unique node names and management ports, for example:

RABBITMQ_NODE_PORT=5672 RABBITMQ_SERVER_START_ARGS="-rabbitmq_management listener [{port,15672}]" RABBITMQ_NODENAME=rabbit1 rabbitmq-server -detached
RABBITMQ_NODE_PORT=5673 RABBITMQ_SERVER_START_ARGS="-rabbitmq_management listener [{port,15673}]" RABBITMQ_NODENAME=rabbit2 rabbitmq-server -detached
RABBITMQ_NODE_PORT=5674 RABBITMQ_SERVER_START_ARGS="-rabbitmq_management listener [{port,15674}]" RABBITMQ_NODENAME=rabbit3 rabbitmq-server -detached

Choose one node as the master (e.g., rabbit1) and have the other nodes join the cluster after resetting them:

// rabbit2 joins as RAM node
rabbitmqctl -n rabbit2 stop_app
rabbitmqctl -n rabbit2 reset
rabbitmqctl -n rabbit2 join_cluster --ram rabbit1@`hostname -s`
rabbitmqctl -n rabbit2 start_app

// rabbit3 joins as disk node
rabbitmqctl -n rabbit3 stop_app
rabbitmqctl -n rabbit3 reset
rabbitmqctl -n rabbit3 join_cluster --disc rabbit1@`hostname -s`
rabbitmqctl -n rabbit3 start_app

Verify the cluster status with rabbitmqctl cluster_status, which should show two disk nodes and one RAM node.

To enable mirrored queues, set a policy on the master:

rabbitmqctl -n rabbit1 set_policy ha-all "^" '{"ha-mode":"all"}'

Note: In a single‑machine setup the .erlang.cookie file must be identical on all nodes.

HAProxy + Keepalived High‑Availability Architecture

When a cluster contains multiple RAM nodes, clients need a stable entry point. Embedding the selection logic in client code is fragile, so a proxy layer such as HAProxy (or Nginx/LVS) is used to monitor node health and forward traffic.

Combining HAProxy with Keepalived provides both load balancing and failover. Keepalived runs the VRRP protocol to manage a virtual IP; the virtual IP is always served by the current master HAProxy instance.

HAProxy Overview

HAProxy is an open‑source, high‑performance load balancer that can operate at layer 4 (transport) or layer 7 (application).

Load‑Balancing Layers

Layer‑4 load balancing uses NAT to rewrite source IP/port and forwards packets based on network addresses only. Layer‑7 load balancing inspects the HTTP request path and can route traffic to different back‑ends accordingly.

High‑Availability HAProxy

Deploying HAProxy itself in a cluster avoids a single point of failure. Keepalived ensures that one HAProxy instance holds the virtual IP, while the others standby.

VRRP Protocol

VRRP (Virtual Router Redundancy Protocol) provides a virtual IP that automatically moves to a backup router when the master fails, eliminating a single point of failure.

Conclusion

The article introduced RabbitMQ clustering concepts, compared classic and mirrored modes, demonstrated a step‑by‑step cluster setup, and showed how HAProxy and Keepalived can be combined to achieve a truly highly available, load‑balanced messaging service.