Я использую кластер RabbitMQ (версия 3.0.2, Erlang R15B) с двумя узлами, и они продолжают периодически испытывать ошибку раздела сети. Они физически расположены в одном центре обработки данных, и их сеть должна быть надежной. Когда я проверяю их журналы, оба сервера сообщают об ошибке «running_partitioned_network» примерно в одно и то же время, и оба узла продолжают работать, поэтому я не думаю, что это аппаратный сбой или неожиданное завершение работы одного из узлов. Я изменил net_ticktime на 120 секунд, чтобы попытаться смягчить проблему, и она перестала возникать почти на месяц, но недавно стала повторяться каждые несколько дней. Теперь я не уверен, помог ли net_ticktime или это было просто совпадением.
Для дальнейшего устранения неполадок я запустил скользящую трассировку сети с помощью Wireshark и использовал запланированное задание, чтобы остановить трассировку, когда узлы снова стали разделенными. Моя цель - определить, вызвано ли разделение ненадежной сетью или приложение не ответило. В трассировке пакетов нет ничего, что указывало бы на сбой сети, существует лишь несколько повторных передач TCP, и между ними успешно передается множество других пакетов.
На данный момент я не уверен, что еще нужно посмотреть в трассировке пакетов, чтобы доказать или опровергнуть, что сеть вызвала сбой. Wireshark может идентифицировать и декодировать протокол распределения Erlang, но я не знаю, как интерпретировать сообщения, чтобы узнать, что заставит узлы обнаруживать раздел. Кроме того, net_ticktime установлен на 120 секунд, и я не вижу 120-секундного промежутка между серверами, получающими сообщения друг от друга. Самый длинный промежуток, в течение которого сообщения Erlang не принимаются от другого сервера, составляет 22 секунды (намного меньше, если вы считаете подтверждения TCP). Моя единственная другая мысль заключается в том, что если между узлами необходимо отправить определенное сообщение типа «пинг», и это конкретное сообщение было прервано, но я не знаю, как это будет выглядеть при трассировке.
Любые идеи о том, как в дальнейшем диагностировать причину этой проблемы, были бы полезны.
Я не уверен, так ли это на самом деле, но похоже, что кластеризация Erlang может сломаться при передаче больших сообщений. Взгляните на эту ветку в списке рассылки обсуждения RabbitMQ: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2012-March/018745.html
Я видел похожие проблемы с RabbitMQ 2.8.4 на Erlang R14B03, правда, без сообщения «running_partitioned_network». Для нас этого не происходило уже несколько месяцев (да, это случалось достаточно раз, когда у нас была проверка Nagios check_rabbitmq_splitbrain), но я посмотрю, смогу ли я зафиксировать некоторые детали, если это произойдет снова ...