Guía paso a paso para implementar un clúster RabbitMQ Activo-Pasivo

La implementación de alta disponibilidad (HA) para servicios de mensajería críticos requiere una redundancia robusta. Una configuración de clúster Activo-Pasivo de RabbitMQ es un enfoque clásico para lograr esto, asegurando que si el nodo activo falla, un nodo pasivo designado pueda tomar el control rápidamente, minimizando el tiempo de inactividad. Esta guía proporciona un proceso completo, paso a paso, para configurar dicha implementación, cubriendo los requisitos previos, la configuración de nodos y asegurando capacidades de failover sin interrupciones.

Este patrón de implementación se basa en la agrupación estándar de RabbitMQ combinada con un mecanismo externo (como Pacemaker o scripts simples) para administrar la toma de control de la dirección IP tras un fallo. Para esta guía, nos centramos en el aspecto de la agrupación de RabbitMQ que sustenta la configuración de HA.

Requisitos previos para un clúster Activo-Pasivo

Antes de comenzar la configuración, asegúrese de que se cumplan los siguientes requisitos previos en todos los nodos del clúster previstos (Nodo A - Activo, Nodo B - Pasivo):

1. Versiones de software idénticas: Todos los nodos deben ejecutar la misma versión exacta de RabbitMQ Server y Erlang/OTP.
2. Accesibilidad de red: Todos los nodos deben poder comunicarse entre sí a través de los puertos necesarios (por defecto 5672 para AMQP, 25672 para agrupación).
3. Resolución de host: Configure el archivo /etc/hosts (o DNS) en todos los nodos para que cada nodo pueda resolver de manera confiable el nombre de host de todos los demás nodos.
4. Consistencia de la cookie: La 'cookie mágica' de Erlang debe ser idéntica en todos los nodos. Esto es crucial para que los nodos confíen entre sí para la agrupación.

Establecimiento de la consistencia de la cookie

La cookie de Erlang determina si los nodos pueden comunicarse de forma segura. Debe copiarse del primer nodo inicializado a todos los demás.

En el Nodo A (El primer nodo):

Localice el archivo de cookie (generalmente /var/lib/rabbitmq/.erlang.cookie o ~/.erlang.cookie dependiendo del método de instalación) y copie su contenido.

En el Nodo B (y nodos subsiguientes):

1. Detenga el servicio de RabbitMQ:
   bash sudo systemctl stop rabbitmq-server
2. Reemplace el archivo de cookie existente con el contenido copiado del Nodo A, asegurando los permisos correctos (generalmente 400).
   bash # Ejemplo usando echo (reemplace el contenido según sea necesario) echo "TU_LARGA_CADENA_DE_COOKIE" | sudo tee /var/lib/rabbitmq/.erlang.cookie sudo chmod 400 /var/lib/rabbitmq/.erlang.cookie
3. Inicie el servicio en el Nodo B:
   bash sudo systemctl start rabbitmq-server

Paso 1: Configuración de nombres de host y red

Asegúrese de que los archivos de host en el Nodo A y el Nodo B mapeen correctamente sus nombres de host.

Ejemplo de /etc/hosts (en ambos servidores):

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

Paso 2: Inicialización del primer nodo del clúster (Activo)

El Nodo A será el nodo principal inicial, donde se establece por primera vez el clúster.

1. Inicie el servicio en el Nodo A (si aún no se está ejecutando):
   bash sudo systemctl start rabbitmq-server
2. Verifique el estado: Asegúrese de que el nodo se esté ejecutando correctamente.
   bash rabbitmqctl status

Paso 3: Unir el segundo nodo (Pasivo) al clúster

Ahora, instruimos al Nodo B para que se una al clúster liderado por el Nodo A.

1. Detenga el servicio en el Nodo B (si se está ejecutando):
   bash sudo systemctl stop rabbitmq-server

2. Comando de unión: Ejecute el comando de unión en el Nodo B, especificando el nombre de host del Nodo A como par.
   bash rabbitmqctl join_cluster rabbit@rabbitmq-node-a
   Consejo: Utilice el nombre de host definido en /etc/hosts.

3. Inicie el servicio en el Nodo B:
   bash sudo systemctl start rabbitmq-server

Paso 4: Verificación de la formación del clúster

Inicie sesión en el Nodo A y verifique que ambos nodos se reconozcan entre sí.

rabbitmqctl cluster_status

Fragmento de salida esperado:

Debería ver rabbitmq-node-a y rabbitmq-node-b listados bajo running_nodes.

Estado del clúster del nodo rabbit@rabbitmq-node-a ...
[{nodes,[{disc,[rabbit@rabbitmq-node-a,rabbit@rabbitmq-node-b]}]},
 {running_nodes,[rabbit@rabbitmq-node-a,rabbit@rabbitmq-node-b]},
 ...
]

Paso 5: Configuración de alta disponibilidad (Colas en clúster)

La agrupación estándar de RabbitMQ permite que los nodos compartan metadatos (usuarios, exchanges), pero los mensajes que residen en las colas generalmente no se replican automáticamente a menos que se apliquen políticas HA específicas. Para un failover Activo-Pasivo real, se deben usar colas espejadas.

Definición de la política

Se aplica una política a las colas que coinciden con patrones específicos para definir cuántas copias de la cola deben existir en el clúster y dónde deben ser promovidas.

Use el comando rabbitmqctl set_policy en cualquiera de los nodos para forzar el espejado en todo el clúster ("^").

# Establece una política llamada 'ha-all' que espeja las colas que coinciden con cualquier nombre ('^')
# a todos los nodos del clúster (3 nodos en total), y establece el comportamiento de 'promover'.
rabbitmqctl set_policy ha-all "^" '{"ha-mode":"all"'