Clustering RabbitMQ en CentOS 7

• Prerrequisitos
• Configurar el firewall
• Instalar rabbitmqadmin
• Configurar DNS
• Agrupe los nodos
• Crear una política de alta disponibilidad.
• Probar la configuración
• Eliminar el usuario invitado

RabbitMQ es un agente de mensajes de código abierto que admite AMQP, STOMP y otras tecnologías de comunicación. Es ampliamente utilizado en aplicaciones empresariales y arquitecturas modernas de microservicios donde actúa como un canal de mensaje asíncrono entre diferentes microservicios. Esta guía describirá cómo puede agrupar RabbitMQ en múltiples servidores CentOS 7 para formar un agente de mensajes de alta disponibilidad. En este tutorial, un servidor actuará como servidor maestro y los otros servidores actuarán como servidores espejo en caso de que el servidor maestro no esté disponible.

Prerrequisitos

• Al menos dos instancias de CentOS 7 recientemente implementadas y actualizadas en la misma subred con redes privadas habilitadas
• RabbitMQ instalado con la consola de administración habilitada en cada servidor (consulte Cómo instalar RabbitMQ en CentOS 7 )
• Un usuario no administrador con derechos de sudo (consulte Cómo usar Sudo en Debian, CentOS y FreeBSD )

Configurar el firewall

El firewall de CentOS, ( firewalld), no permite ningún tráfico entrante de manera predeterminada. Para que RabbitMQ esté disponible para otros sistemas dentro y fuera de la red, y para permitirnos acceder a la consola de administración, primero debemos abrir algunos puertos.

La consola de administración de la interfaz web de RabbitMQ escucha de forma predeterminada en el puerto 15672. Nos gustaría que la consola de administración esté disponible públicamente para que podamos acceder a ella desde nuestra computadora. Por lo tanto, le indicaremos firewalldque abra permanentemente el puerto 15672en la zona pública (que es la zona activa y predeterminada en una instancia de Vultr).

sudo firewall-cmd --zone=public --add-port=15672/tcp --permanent

Los nodos RabbitMQ deben poder comunicarse entre sí. Nos gustaría abrir los puertos necesarios, pero solo a través de la red interna. No queremos que nadie en Internet pueda administrar o contactar directamente a nuestros servidores. Los siguientes comandos suponen que nuestros servidores están en la 192.168.0.100/24subred.

El primer servicio es el epmdservicio de descubrimiento de pares que escucha de forma predeterminada en el puerto 4369.

sudo firewall-cmd --permanent --zone=public --add-rich-rule='
  rule family="ipv4"
  source address="192.168.0.100/24"
  port protocol="tcp" port="4369" accept'

Para la comunicación entre entrenudos y CLI, RabbitMQ necesita poder comunicarse a través del puerto 25672.

sudo firewall-cmd --permanent --zone=public --add-rich-rule='
  rule family="ipv4"
  source address="192.168.0.100/24"
  port protocol="tcp" port="25672" accept'

Las herramientas CLI se comunican a través del rango de puertos 35672-35682.

sudo firewall-cmd --permanent --zone=public --add-rich-rule='
  rule family="ipv4"
  source address="192.168.0.100/24"
  port protocol="tcp" port="35672-35682" accept'

Si sus aplicaciones necesitan el protocolo AMQP, también deberá abrir puertos 5671y 5672. Si necesita poder comunicarse a través de otro protocolo, puede encontrar la información necesaria sobre los requisitos de red de RabbitMQ en la documentación oficial de RabbitMQ .

sudo firewall-cmd --permanent --zone=public --add-rich-rule='
  rule family="ipv4"
  source address="192.168.0.100/24"
  port protocol="tcp" port="5672" accept'

sudo firewall-cmd --permanent --zone=public --add-rich-rule='
  rule family="ipv4"
  source address="192.168.0.100/24"
  port protocol="tcp" port="5671" accept'

Ahora que firewalldestá configurado, debemos indicarle que vuelva a cargar la configuración.

sudo firewall-cmd --reload

Repita los pasos de esta sección en todos los servidores.

Instalar en pc rabbitmqadmin

El complemento de administración viene con una herramienta llamada Python rabbitmqadminque se puede instalar fácilmente en el sistema una vez que el complemento de administración está habilitado.

sudo wget http://localhost:15672/cli/rabbitmqadmin
sudo mv rabbitmqadmin /usr/local/bin/
sudo chmod +x /usr/local/bin/rabbitmqadmin

Configurar DNS

Debe usar los nombres de host del servidor para identificar los servidores cuando se agrupan. Por defecto, los servidores no tienen ningún registro DNS asignado y la conexión fallará. Para superar esto rápidamente, agregue el nombre de host maestro y espejo al /etc/hostsarchivo usando su editor favorito.

Por ejemplo, el archivo de hosts de su maestro podría tener el siguiente aspecto. Observe los dos últimos registros, que permiten a los servidores identificarse entre sí por su nombre de host. Asegúrese de cambiar las direcciones IP a las suyas.

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

127.0.0.1 guest
::1       guest

127.0.0.1 YOUR_MASTER_SERVER_HOST_NAME
::1       YOUR_MASTER_SERVER_HOST_NAME


192.168.0.101 YOUR_MASTER_SERVER_HOST_NAME
192.168.0.102 YOUR_MIRROR_SERVER_HOST_NAME

Agrupe los nodos

Un requisito previo de importación para permitir que los nodos se unan entre sí es que la cookie Erlang de todos los nodos sea idéntica. Por defecto, a cada nodo se le asignará una cookie única de Erlang, por lo que debe volver a configurarla en todos los nodos.

El siguiente comando configurará la cookie Erlang en " WE<3COOKIES", pero no dude en cambiar esto a su gusto. Haga esto en todos los servidores.

sudo sh -c "echo 'WE<3COOKIES' > /var/lib/rabbitmq/.erlang.cookie"

Reinicie RabbitMQ en todos los servidores para asegurarse de que la cookie Erlang se vuelva a cargar correctamente.

sudo systemctl restart rabbitmq-server.service

Ejecute los siguientes comandos en todos los servidores excepto en el servidor maestro. Esto permitirá que los nodos se unan al servidor maestro y formen un clúster.

sudo rabbitmqctl stop_app
sudo rabbitmqctl join_cluster "rabbit@<YOUR_MASTER_SERVER_HOST_NAME>"
sudo rabbitmqctl start_app

Verifique que los nodos se hayan unido al clúster ejecutando el siguiente comando.

sudo rabbitmqctl cluster_status

Todos sus nodos aparecerán en la sección nodesy running_nodesde la salida. A partir de ahora, ya no necesita repetir los pasos en cada servidor, la configuración se reflejará automáticamente en los otros nodos.

Crear una política de alta disponibilidad.

Ahora que tenemos un clúster de nodos RabbitMQ, podemos usar esto para hacer colas e intercambios de alta disponibilidad estableciendo una nueva política. Esta política se puede agregar a través de la Consola de administración RabbitMQ o usando la interfaz de línea de comando.

sudo rabbitmqctl set_policy -p "/" --priority 1 --apply-to "all" ha ".*" '{ "ha-mode": "exactly", "ha-params": 2, "ha-sync-mode": "automatic"}'

La siguiente lista explicará lo que significa cada parte del comando.

• -p "/": Use esta política en el "/"vhost (el valor predeterminado después de la instalación)
• --priority 1: El orden en el que aplicar las políticas
• --apply-to "all": Puede ser "queues", "exchanges"o"all"
• ha: El nombre que le damos a nuestra política
• ".*": La expresión regular que se utiliza para decidir a qué colas o intercambios se aplica esta política. ".*"coincidirá con cualquier cosa
• '{ "ha-mode": "exactly", "ha-params": 2, "ha-sync-mode": "automatic"}': La representación JSON de la política. Este documento describe lo que queremos: exactamente 2 nodos en los que los datos se sincronizan automáticamente

En resumen, esta política garantizará que siempre tengamos 2 copias de los datos en una cola o intercambio siempre que tengamos al menos 2 nodos en funcionamiento. Si tiene más nodos, puede aumentar el valor de ha-params. Se N/2 + 1recomienda un quórum ( ) de nodos. Tener más copias de sus datos daría como resultado un mayor uso de disco, E / S y red, lo que podría provocar un rendimiento degradado.

Si desea duplicar los datos en todos los nodos del clúster, puede usar el siguiente documento JSON.

'{ "ha-mode": "all", "ha-sync-mode": "automatic"}'

Si desea reflejar los datos solo en nodos específicos (por ejemplo: node-1y node-2), puede usar lo siguiente.

'{ "ha-mode": "nodes", "ha-params" :["rabbit@node-1", "rabbit@node-2"], "ha-sync-mode": "automatic"}'

Puede cambiar la expresión regular para asignar diferentes políticas a diferentes colas. Digamos que tenemos los siguientes tres nodos:

• conejo @ maestro
• conejo @ cliente-ha
• conejo @ producto-ha

Entonces podemos crear dos políticas que darán como resultado que las colas tengan un nombre que comience con "cliente" para reflejarse en el rabbit@client-hanodo y todas las colas que tengan un nombre que comience con "producto" se reflejen en el rabbit@product-hanodo.

sudo rabbitmqctl set_policy -p "/" --priority 1 --apply-to "queues" ha-client "client.*" '{ "ha-mode": "nodes", "ha-params": ["rabbit@master", "rabbit@client-ha"], "ha-sync-mode": "automatic"}
sudo rabbitmqctl set_policy -p "/" --priority 1 --apply-to "queues" ha-product "product.*" '{ "ha-mode": "nodes", "ha-params": ["rabbit@master", "rabbit@product-ha"], "ha-sync-mode": "automatic"}

Un pequeño comentario aquí: las colas exclusivas nunca se reflejan o son duraderas en RabbitMQ, incluso si esta política coincidiera con tales colas. Las colas exclusivas se destruyen automáticamente una vez que un cliente se desconecta y, como tal, no sería útil replicarlo en otro servidor. Si el servidor fallara, el cliente se desconectaría y la cola se destruiría automáticamente. Las instancias reflejadas también serían destruidas.

Probar la configuración

Para probar la configuración en clúster, podemos crear una nueva cola usando la interfaz de línea de comandos a través de la consola de administración.

sudo rabbitmqadmin declare queue --vhost "/" name=my-ha-queue durable=true

Esto creará una cola duradera en el /vhost predeterminado con el nombre my-ha-queue.

Ejecute el siguiente comando y verifique en la salida que la cola tiene nuestra política 'ha' asignada y tiene pid's en el maestro y en un nodo espejo.

sudo rabbitmqctl list_queues name policy state pid slave_pids

Ahora podemos publicar un mensaje en la cola desde el nodo maestro y detener RabbitMQ en el nodo maestro.

sudo rabbitmqadmin -u user_name -p password  publish routing_key=my-ha-queue payload="hello world"
sudo systemctl rabbitmqctl shutdown

Ahora recupere la conexión al nodo espejo.

 sudo rabbitmqadmin -H MIRROR_NODE_IP_OR_DNS -u user_name -p password get queue=my-ha-queue

Finalmente, podemos reiniciar nuestro nodo maestro.

sudo systemctl start rabbitmq-server.service

Eliminar el usuario invitado

Como se mencionó anteriormente, RabbitMQ crea automáticamente un usuario invitado con una contraseña de invitado predeterminada. Sería una mala práctica dejar a este usuario predeterminado en un sistema expuesto públicamente.

sudo rabbitmqctl delete_user guest