Guía paso a paso para implementar un clúster activo-pasivo de RabbitMQ

La alta disponibilidad de RabbitMQ necesita más que dos servidores que puedan verse entre sí. Necesitas clustering para metadatos compartidos, colas replicadas para la disponibilidad de mensajes y una ruta de conmutación por error clara para los clientes.

Esta guía muestra el lado de RabbitMQ de una implementación de estilo activo-pasivo. La conmutación por error del cliente generalmente proviene de un balanceador de carga, cambio de DNS, descubrimiento de servicios o una IP virtual gestionada fuera de RabbitMQ.

Prerrequisitos para un clúster activo-pasivo

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

Versiones de software compatibles: Mantén las versiones de RabbitMQ Server y Erlang/OTP alineadas entre los nodos. En la práctica, ejecuta la misma versión de RabbitMQ en cada nodo a menos que estés siguiendo la ruta de actualización progresiva documentada de RabbitMQ.
Accesibilidad de red: Los nodos deben comunicarse a través de los puertos AMQP utilizados por los clientes, el puerto de distribución utilizado para el clustering y cualquier puerto de gestión o TLS que habilites.
Resolución de nombres de host: Configura el archivo /etc/hosts (o DNS) en todos los nodos para que cada nodo pueda resolver el nombre de host de todos los demás nodos de manera confiable.
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 el clustering.

Estableciendo consistencia de la cookie

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

En el Nodo A (El primer nodo):

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

En el Nodo B (y nodos subsiguientes):

Detén el servicio de RabbitMQ:
```
sudo systemctl stop rabbitmq-server
```

Reemplaza el archivo de cookie existente con el contenido copiado del Nodo A, asegurando los permisos correctos (generalmente 400).

# Ejemplo usando echo (reemplaza el contenido según sea necesario)
echo "TU_CADENA_DE_COOKIE_LARGA" | sudo tee /var/lib/rabbitmq/.erlang.cookie
sudo chmod 400 /var/lib/rabbitmq/.erlang.cookie

Inicia el servicio en el Nodo B:
```
sudo systemctl start rabbitmq-server
```

Paso 1: Configurando nombres de host y redes

Asegúrate de que los archivos de host tanto en el Nodo A como en el Nodo B mapeen correctamente sus nombres de host.

Ejemplo /etc/hosts (en ambos servidores):

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

Paso 2: Inicializando el primer nodo del clúster (Activo)

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

Inicia el servicio en el Nodo A (si aún no está en ejecución):
```
sudo systemctl start rabbitmq-server
```
Verifica el estado: Asegúrate de que el nodo se esté ejecutando correctamente.
```
rabbitmqctl status
```

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

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

Detén la aplicación de RabbitMQ en el Nodo B mientras mantienes disponible el nodo de Erlang:
```
sudo rabbitmqctl stop_app
```
Reinicia el estado local del Nodo B si ya ha sido inicializado como un nodo independiente:
```
sudo rabbitmqctl reset
```
Comando de unión: Ejecuta el comando de unión en el Nodo B, especificando el nombre de host del Nodo A como par.
```
sudo rabbitmqctl join_cluster rabbit@rabbitmq-node-a
```
Consejo: Usa el nombre de host definido en /etc/hosts.
Inicia la aplicación de RabbitMQ en el Nodo B:
```
sudo rabbitmqctl start_app
```

Paso 4: Verificando la formación del clúster

Inicia sesión en el Nodo A y verifica que ambos nodos se reconozcan mutuamente.

rabbitmqctl cluster_status

Fragmento de salida esperado:

Deberías ver tanto rabbitmq-node-a como rabbitmq-node-b listados bajo 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]},
 ...
]

Paso 5: Configurando alta disponibilidad para colas

El clustering estándar de RabbitMQ comparte metadatos como usuarios, intercambios, enlaces y políticas. El contenido de las colas necesita un tipo de cola replicada si deseas que los mensajes sobrevivan a una falla de nodo.

Para implementaciones modernas de RabbitMQ, usa colas de quórum para colas durables replicadas. Las colas reflejadas clásicas usaban políticas ha-mode en versiones anteriores de RabbitMQ, pero ese enfoque está obsoleto y eliminado de las versiones principales más nuevas.

Declarar una cola de quórum

Puedes declarar colas de quórum desde tu aplicación o con rabbitmqadmin. Este ejemplo crea una cola de quórum durable:

rabbitmqadmin declare queue name=orders durable=true arguments='{"x-queue-type":"quorum"}'

Para laboratorios de dos nodos, una cola de quórum puede ejecutarse, pero no puede tolerar la pérdida de un nodo y aún mantener una mayoría. Para producción, usa al menos tres nodos de RabbitMQ para colas de quórum para que un nodo pueda fallar mientras la cola aún tenga mayoría.

Paso 6: Probar la conmutación por error

Antes de declarar el clúster listo, prueba la ruta que usarán tus clientes:

Publica algunos mensajes de prueba persistentes en una cola de quórum.
Detén la aplicación de RabbitMQ del nodo activo con sudo rabbitmqctl stop_app.
Confirma que los clientes se reconecten a través de tu balanceador de carga, destino DNS o configuración de descubrimiento de servicios.
Consume los mensajes de prueba desde el nodo superviviente.
Inicia la aplicación detenida nuevamente con sudo rabbitmqctl start_app y verifica rabbitmqctl cluster_status.

Conclusión final

El clustering de RabbitMQ te proporciona metadatos compartidos del broker, pero la disponibilidad de las colas depende del tipo de cola y del diseño de conmutación por error del cliente. Usa colas de quórum para colas durables replicadas, mantén al menos tres nodos para una verdadera tolerancia a fallos y prueba la conmutación por error con la misma ruta de conexión que usan tus aplicaciones.