Как настроить аварийное переключение с кластером rabbitmq с помощью loadbalancer типа f5
Я безуспешно пытался найти информацию на f5 developer central и internet о следующей настройке.
Мы хотим иметь кластер rabbitmq с 3 узлами. 1 узел всегда будет основным / главным узлом для ВСЕХ очередей. 1. Отправьте все соединения / трафик для всех очередей текущему первичному узлу (A). 2. Когда узел A не отвечает (из-за проблем прикладного уровня или сетевого уровня), балансировщик нагрузки должен автоматически переключать весь трафик на узел (B). 3. Если узел B дает сбой, перейдите к узлу C.
Вопрос: как решить, что узел не отвечает, и должно произойти аварийное переключение на отдельный узел? Есть ли способ вызвать вызов rabbitmq, используя протокол amqp через loadbalancer для этой цели? Не могу найти это хорошо задокументировано.
Даже если вы не знаете, как реализовать это с помощью F5, не стесняйтесь ответить на него с другой точки зрения балансировки нагрузки или кода.
Дополнение к вопросу: я думаю, что какой бы ни была эта проверка работоспособности, она должна быть достаточно конкретной, чтобы кластер rabbitmq уже перестал работать через главный узел на узел B, когда происходит переключение LB и не было ложной тревоги.
Спасибо, что нашли время, чтобы прочитать и ответить.
2 ответа
Я выполнил балансировку нагрузки L4 для кластеризованного RabbitMQ с балансировщиками нагрузки Stingray - он работает хорошо, и мы выполнили RR без каких-либо особых проблем.
В случае выхода из строя одного узла Rabbit сбой соединения TCP и балансировщик нагрузки отправляют трафик на другой узел.
Теперь это технически неэффективно, так как любая запись, отправляемая на узел A, будет также отправляться на узел B, и наоборот, внутри Кролика через Эрланга. epmd,
Одно очень важное замечание: вы должны настроить балансировщик нагрузки так, чтобы TCP-соединения оставались открытыми бесконечно. Это распространенная проблема, поскольку rabbit MQ использует долго выполняющиеся tcp-соединения, но большинство балансировщиков нагрузки ориентированы на параметры HTTP-esque соединения. Некоторые программы (nginx) имеют очень агрессивные окна очистки TCP и закрывают эти TCP-соединения, вызывая сбой соединения, даже если все машины работают.
Я бы пропустил балансировщик нагрузки, если вы следуете только за мастером, используете keepalived и проверку статуса, чтобы увидеть, является ли self мастером, если он мастер, тогда он будет использовать vip.