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