Step-by-Step Guide to Deploying a RabbitMQ Active-Passive Cluster

Implementing high availability (HA) for mission-critical messaging services requires robust redundancy. A RabbitMQ Active-Passive cluster setup is a classic approach to achieve this, ensuring that if the active node fails, a designated passive node can quickly take over, minimizing downtime. This guide provides a comprehensive, step-by-step process for configuring such a deployment, covering prerequisites, node configuration, and ensuring seamless failover capabilities.

This deployment pattern relies on standard RabbitMQ clustering combined with an external mechanism (like Pacemaker or simple scripts) to manage IP address takeover upon failure. For this guide, we focus on the RabbitMQ clustering aspect that underpins the HA setup.

Prerequisites for an Active-Passive Cluster

Before beginning the configuration, ensure the following prerequisites are met across all intended cluster nodes (Node A - Active, Node B - Passive):

1. Identical Software Versions: All nodes must run the exact same version of RabbitMQ Server and Erlang/OTP.
2. Network Accessibility: All nodes must be able to communicate with each other over the necessary ports (default 5672 for AMQP, 25672 for clustering).
3. Host Resolution: Configure the /etc/hosts file (or DNS) on all nodes so that each node can resolve the hostname of all other nodes reliably.
4. Cookie Consistency: The Erlang 'magic cookie' must be identical on all nodes. This is crucial for the nodes to trust each other for clustering.

Establishing Cookie Consistency

The Erlang cookie determines whether nodes can communicate securely. It must be copied from the first node initialized to all others.

On Node A (The first node):

Locate the cookie file (usually /var/lib/rabbitmq/.erlang.cookie or ~/.erlang.cookie depending on the installation method) and copy its contents.

On Node B (and subsequent nodes):

1. Stop the RabbitMQ service:
   bash sudo systemctl stop rabbitmq-server
2. Replace the existing cookie file with the content copied from Node A, ensuring correct permissions (usually 400).
   bash # Example using echo (replace content as needed) echo "YOUR_LONG_COOKIE_STRING" | sudo tee /var/lib/rabbitmq/.erlang.cookie sudo chmod 400 /var/lib/rabbitmq/.erlang.cookie
3. Start the service on Node B:
   bash sudo systemctl start rabbitmq-server

Step 1: Configuring Hostnames and Networking

Ensure that the host files on both Node A and Node B correctly map their hostnames.

Example /etc/hosts (on both servers):

192.168.1.10   rabbitmq-node-a
192.168.1.11   rabbitmq-node-b

Step 2: Initializing the First Cluster Node (Active)

Node A will be the initial primary node, where the cluster is first established.

1. Start the service on Node A (if not already running):
   bash sudo systemctl start rabbitmq-server
2. Verify Status: Ensure the node is running correctly.
   bash rabbitmqctl status

Step 3: Joining the Second Node (Passive) to the Cluster

Now, we instruct Node B to join the cluster led by Node A.

1. Stop Service on Node B (if running):
   bash sudo systemctl stop rabbitmq-server

2. Join Command: Execute the join command on Node B, specifying the hostname of Node A as the peer.
   bash rabbitmqctl join_cluster rabbit@rabbitmq-node-a
   Tip: Use the hostname defined in /etc/hosts.

3. Start Service on Node B:
   bash sudo systemctl start rabbitmq-server

Step 4: Verifying Cluster Formation

Log into Node A and verify that both nodes recognize each other.

rabbitmqctl cluster_status

Expected Output Snippet:

You should see both rabbitmq-node-a and rabbitmq-node-b listed under running_nodes.

Cluster status of node rabbit@rabbitmq-node-a ...
[{nodes,[{disc,[rabbit@rabbitmq-node-a,rabbit@rabbitmq-node-b]}]},
 {running_nodes,[rabbit@rabbitmq-node-a,rabbit@rabbitmq-node-b]},
 ...
]

Step 5: Configuring High Availability (Clustering Queues)

Standard RabbitMQ clustering allows nodes to share metadata (users, exchanges), but messages residing in queues are typically not replicated automatically unless specific HA policies are enforced. For true Active-Passive failover, mirrored queues must be used.

Defining the Policy

A policy is applied to queues matching specific patterns to define how many copies of the queue should exist across the cluster and where they should be promoted.

Use the rabbitmqctl set_policy command on either node to enforce mirroring across the entire cluster ("^").

```bash

Set a policy named 'ha-all' that mirrors queues matching any name ('^')

to all nodes in the cluster (3 nodes total), and set the 'promote' behavior.

rabbitmqctl set_policy ha-all "^" '{"ha-mode":"all"