
El documento de agrupación en clústeres de RabbitMQ
https://www.rabbitmq.com/clustering.html
describe un proceso mediante el cual puede implementar un archivo de configuración para la agrupación en clústeres, de modo que se cree automáticamente un clúster cuando los nodos de Rabbitmq arrancan.eg
[{rabbit,
[{cluster_nodes, {['rabbit@rabbit1', 'rabbit@rabbit2', 'rabbit@rabbit3'], ram}}]}].
Aplique este archivo en cada uno de los 3 nodos en /etc/rabbitmq/rabbitmq.config, y luego inicie Rabbitmq en cada uno y aparentemente se formará un clúster.
Esto no parece funcionar muy bien, por ejemplo
Si inicia Rabbit2 y Rabbit3 aún no se ha activado, el servicio no se iniciará en Rabbit2, ya que está intentando crear un clúster con Rabbit3.
Del mismo modo, si solo aplica la configuración en Rabbit1 y ha iniciado Rabbit2 y Rabbit3 previamente, Rabbit1 formará un clúster solo con Rabbit2, como, según la documentación (no entiendo por qué):
RabbitMQ will try to cluster to each node provided, and stop after it can cluster with one of them.
La única forma en que esto parece funcionar es si aplica el archivo de configuración en los 3 nodos y hace que comiencen enexactamenteal mismo tiempo. Estoy intentando implementar esto con Ansible, que crea los nodos secuencialmente, por lo que no funciona.
¿Que me estoy perdiendo aqui?
Respuesta1
También implemento clústeres RabbitMQ con Puppet y, en realidad, no es necesario activar todos los nodos exactamente al mismo tiempo.
Lo que suelo hacer y hasta ahora me ha funcionado es:
- instalar RabbitMQ (RPM o DEB)
- Configure el archivo de hosts en cada nodo, para que contenga entradas para los tres. ejemplo:
.
192.168.1.11 dev-c1n01-rabbitmq.example.com dev-c1n01-rabbitmq
192.168.1.12 dev-c1n02-rabbitmq.example.com dev-c1n02-rabbitmq
192.168.1.13 dev-c1n03-rabbitmq.example.com dev-c1n03-rabbitmq
nodos que estamos agrupando (porque no quiero depender de que DNS esté disponible) * implementar Rabbitmq.config
.
[
{rabbit, [
{cluster_nodes, {['rabbit@dev-c1n01-rabbitmq', 'rabbit@dev-c1n02-rabbitmq', 'rabbit@dev-c1n03-rabbitmq'], disc}},
{cluster_partition_handling, pause_minority},
{disk_free_limit, 2147483648},
{heartbeat, 0},
{tcp_listen_options, [binary, {backlog, 1024}, {nodelay, true}, {keepalive, true} ]},
{vm_memory_high_watermark, 0.6},
{default_user, <<"admin">>},
{default_pass, <<"somedefaultpass">>}
]},
{kernel, [
]}
,
{rabbitmq_management, [
{listener, [
{port, 15672}
]}
]}
].
% EOF
- implementar erlang.cookie
Para crear una cookie erlang, suelo utilizarhttp://contraseñasgenerador.net/y configúrelo para crear una cadena de 20 caracteres que solo contenga caracteres en mayúsculas. Luego, coloque esta cadena en /var/lib/rabbitmq/.erlang.cookie, así:
echo -n 'LCQLSHVOPZFHRUXMMAPF' > /var/lib/rabbitmq/.erlang.cookie
- iniciar nodos (el orden no importa siempre que tengan el mismo erlang.cookie y Rabbitmq.config)
Esto debería funcionar para ti. Probado en las versiones 3.2, 3.3 y 3.5.
Respuesta2
He hecho algunos progresos en esto.
El problema parece estar relacionado con la elección de utilizarRAMnodos en lugar dedesctnodos en el archivo Rabbitmq.config. De la documentación:
Los nodos RAM son un caso de uso avanzado; al configurar su primer clúster simplemente no debería usarlos. Debería tener suficientes nodos de disco para manejar sus requisitos de redundancia y luego, si es necesario, agregar nodos de RAM adicionales para escalar.
Un clúster que contiene sólo nodos RAM es frágil; Si el clúster se detiene, no podrá iniciarlo nuevamente y perderá todos los datos. RabbitMQ evitará la creación de un clúster de solo nodos RAM en muchas situaciones, pero no puede evitarlo por completo.
Cuando cambio el archivo de configuración para usar "disco" en lugar de "ram", la creación del clúster fue mucho más estable.
[{rabbit,
[{cluster_nodes, {['rabbit@rabbit1', 'rabbit@rabbit2', 'rabbit@rabbit3'],disc}}]}].