Clúster de RabbitMQ: Configuración, Ajustes y Mejores Prácticas

El clúster de RabbitMQ a menudo se malinterpreta. Un clúster te da un único broker lógico compuesto por múltiples nodos Erlang. Comparte usuarios, vhosts, intercambios, enlaces, políticas y otros metadatos entre esos nodos. No hace automáticamente que los mensajes de cada cola estén disponibles en todas partes. La disponibilidad de la cola depende del tipo de cola y su configuración de replicación.

Esa diferencia importa en producción. Un clúster puede facilitar la gestión y el enrutamiento, y puede soportar colas de alta disponibilidad, pero no es un interruptor mágico de rendimiento. Si pones todas las colas activas en un nodo, ese nodo sigue haciendo el trabajo. Si usas colas clásicas sin replicación y el nodo líder de la cola desaparece, esa cola no estará disponible hasta que el nodo regrese. Diseña el clúster alrededor de las colas que realmente ejecutas.

Lo que un clúster comparte, y lo que no

Los metadatos del clúster de RabbitMQ se replican. Si declaras un intercambio en un nodo, los otros nodos lo saben. Si agregas un usuario o política, el clúster almacena esa definición. Las aplicaciones cliente pueden conectarse a cualquier nodo y usar la misma topología.

Los mensajes son diferentes. Una cola tiene un líder. Para colas clásicas, los mensajes viven en el nodo que aloja esa cola a menos que uses colas reflejadas más antiguas. Para colas de quórum, RabbitMQ replica los datos de la cola a través de un grupo de nodos usando un protocolo de consenso. Para flujos, los datos se replican según la configuración del flujo. En despliegues modernos de RabbitMQ, las colas de quórum suelen ser la opción más segura para colas de trabajo durables y replicadas.

Los artículos antiguos a menudo hablan de "colas HA" como si fuera el valor predeterminado moderno. En la terminología de RabbitMQ, eso generalmente significa colas clásicas reflejadas configuradas por política. Todavía existen en algunas instalaciones, pero las colas de quórum son la dirección que la mayoría de los nuevos diseños de colas durables replicadas deberían considerar. Siempre verifica la versión de RabbitMQ y las restricciones operativas de tu entorno antes de migrar una carga de trabajo existente.

Antes de unir nodos

Haz primero las comprobaciones aburridas:

• Los nodos deben resolver los nombres de host de los demás de manera consistente.
• El puerto de distribución de Erlang y los puertos de RabbitMQ deben ser accesibles entre nodos.
• Las versiones de RabbitMQ y Erlang deben ser compatibles en todo el clúster.
• Todos los nodos deben compartir la misma cookie de Erlang.
• La sincronización de tiempo debe ser sensata, especialmente si tu monitoreo y TLS dependen de ella.

La cookie de Erlang es un secreto compartido utilizado por los nodos Erlang. En muchos paquetes de Linux se encuentra en /var/lib/rabbitmq/.erlang.cookie, propiedad del usuario rabbitmq y modo 600.

sudo systemctl stop rabbitmq-server
sudo install -o rabbitmq -g rabbitmq -m 600 .erlang.cookie /var/lib/rabbitmq/.erlang.cookie
sudo systemctl start rabbitmq-server

No regeneres la cookie casualmente en un clúster en ejecución. Si un nodo tiene una cookie diferente, no podrá comunicarse con los demás, y el mensaje de error no siempre es amigable.

Unir un nodo

Supón que rabbit@rmq-a ya está en ejecución y rabbit@rmq-b debe unirse a él. En rmq-b:

sudo rabbitmqctl stop_app
sudo rabbitmqctl reset
sudo rabbitmqctl join_cluster rabbit@rmq-a
sudo rabbitmqctl start_app

Luego verifica desde cualquier nodo:

rabbitmqctl cluster_status
rabbitmq-diagnostics cluster_status

reset elimina la base de datos local de RabbitMQ del nodo antes de unirse. Eso suele ser lo que quieres para un nodo nuevo vacío. No es algo para ejecutar casualmente en un nodo que posee colas que te importan.

Para tres nodos, repite el mismo proceso desde rmq-c. Puedes unir tanto rmq-b como rmq-c a rmq-a; una vez unidos, no hay un "maestro" permanente para metadatos como la gente a veces imagina.

Pon a los clientes detrás de un punto final estable

Las aplicaciones no deberían tener un único host de broker codificado si esperas mantenimiento de nodos. Usa un balanceador de carga, estrategia DNS o una lista de conexión de la biblioteca cliente. El balanceador de carga debe verificar si la aplicación RabbitMQ está en ejecución, no solo si el puerto 5672 está abierto.

Una simple verificación TCP puede enviar clientes a un nodo que está vivo pero bloqueado por alarmas o no completamente unido. En entornos más estrictos, usa verificaciones de salud expuestas a través del plugin de gestión o una pequeña verificación local que ejecute rabbitmq-diagnostics -q ping.

Elige los tipos de cola deliberadamente

Para cargas de trabajo durables replicadas, una cola de quórum suele ser un buen valor predeterminado:

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

O a través de la declaración de la aplicación:

channel.queue_declare(
    queue='orders.pending',
    durable=True,
    arguments={'x-queue-type': 'quorum'}
)

Las colas de quórum intercambian algo de rendimiento y latencia por un comportamiento de replicación más fuerte. No son una actualización gratuita para cada cola. Para colas de respuesta temporales, suscriptores fanout de corta duración o trabajo transitorio de bajo valor, las colas clásicas pueden estar bien. Para eventos de negocio que deben sobrevivir a la pérdida de un nodo, usa un tipo de cola replicada y prueba la conmutación por error.

Las particiones de red son un evento operativo, no una casilla de verificación

Una partición de red significa que los nodos del clúster no pueden comunicarse todos entre sí. RabbitMQ tiene estrategias de manejo de particiones, pero ninguna convierte una red rota en una saludable. La respuesta correcta es diseñar el clúster para que las particiones sean raras, visibles y recuperadas cuidadosamente.

Para la mayoría de los clústeres de producción, usa un número impar de nodos para cargas de trabajo basadas en quórum y evita estirar un clúster pequeño a través de enlaces poco fiables. Tres nodos en tres zonas de disponibilidad pueden funcionar bien si la latencia es aceptable. Dos nodos divididos en dos sitios es una fuente común de decisiones dolorosas porque no hay mayoría si el enlace se rompe.

Después de una partición sospechada, verifica:

rabbitmqctl cluster_status
rabbitmq-diagnostics alarms
rabbitmq-diagnostics check_running
rabbitmqctl list_queues name type leader members online state

Si los líderes de cola se movieron o los miembros se desconectaron, no asumas que la aplicación está bien porque las conexiones se recuperaron. Observa las confirmaciones del publicador, las tasas de error del consumidor y los mensajes no confirmados.

Hábitos de mantenimiento que previenen sorpresas en el clúster

Drena las conexiones antes de detener un nodo cuando sea posible. Si pones clientes detrás de un balanceador de carga, elimina el nodo de la rotación, espera a que los clientes se reconecten en otro lugar, luego reinicia RabbitMQ.

Verifica la distribución de colas periódicamente:

rabbitmqctl list_queues name type leader messages consumers

Si cada líder de cola activa se sienta en un nodo, el clúster no está equilibrado para esa carga de trabajo. Puede que necesites redeclarar colas, revisar políticas o usar configuraciones de localizador de líder de cola apropiadas para tu versión de RabbitMQ.

Mantén las políticas bajo control de versiones. Una política que cambia el tipo de cola, la eliminación de mensajes, la longitud máxima o el comportamiento de reflejo es infraestructura de producción, no un ajuste de interfaz de usuario.

Las copias de seguridad siguen siendo importantes. El clúster no es un reemplazo para la exportación de definiciones, la automatización de infraestructura o la planificación de recuperación ante desastres. Exporta definiciones después de cambios de topología:

rabbitmqadmin export rabbitmq-definitions.json

Finalmente, prueba la falla que crees que puedes sobrevivir. Detén un nodo que tenga un líder de cola. Mata a un consumidor mientras tiene mensajes no confirmados. Bloquea a un publicador durante una alarma de disco en un entorno de prueba. Un clúster de RabbitMQ gana confianza a través de ensayos aburridos, no a través de un diagrama con tres nodos.