Como configurar o failover com o cluster rabbitmq com um loadbalancer como f5

Question

Eu tenho tentado encontrar informações sobre a central de desenvolvedores da f5 e a Internet a respeito da configuração a seguir, sem sorte.

Queremos ter um cluster rabbitmq com 3 nós. Um nó será sempre um nó principal / principal para TODAS as filas. 1. Envie todas as conexões / tráfego para todas as filas para o nó primário atual (A). 2. Quando o nó A não responde (devido a problemas na camada de aplicativo ou na camada de rede), o balanceador de carga deve fazer failover automaticamente de todo o tráfego para o nó (B). 3. Se o nó B falhar, mova para o nó C.

A pergunta: Como decidir se um nó não está respondendo e o failover para o nó separado deve acontecer? Existe uma maneira de invocar uma chamada para rabbitmq usando o protocolo amqp através do balanceador de carga para essa finalidade? Não é possível encontrá-lo bem documentado.

Mesmo que você não saiba como implementar isso com a F5, sinta-se à vontade para respondê-la de uma perspectiva de balanceador de carga ou código diferente.

Além da pergunta: Eu acho que seja qual for a verificação de saúde, tem que ser concreto o suficiente para que o cluster rabbitmq já tenha falhado sobre o nó mestre para o nó B, quando ocorrer a mudança de LB e não houver falsa alarme.

Obrigado por reservar um tempo para ler e responder.

    

Answer 1

Eu fiz o balanceamento de carga L4 para o RabbitMQ em cluster com balanceadores de carga Stingray - ele funciona bem e fizemos RR sem nenhum problema específico.

No caso de um nó Rabbit ficar inativo, as conexões TCP falharão e o balanceador de carga enviará tráfego para o outro nó.

Agora, isso é tecnicamente ineficiente, já que qualquer envio de registro para o nó A será enviado ao nó B também e vice-versa internamente por Rabbit via epmd de Erlang.

Uma nota importante muito é que você deve definir o balanceador de carga para manter as conexões TCP abertas indefinidamente. Esse é um problema comum, já que o coelho MQ usa conexões tcp de longa duração, mas a maioria dos balanceadores de carga são direcionados para parâmetros de conexão HTTP-esque. Algum software (nginx) tem janelas de limpeza TCP muito agressivas e irá fechar essas conexões TCP, causando uma falha de conexão, mesmo que todas as máquinas estejam felizes.

    

Answer 2

Eu ignoraria o balanceador de carga se você estivesse apenas seguindo o mestre, use keepalived e uma verificação de status para ver se self é master, se for master, ele usará o vip.