2つのノードでRabbitMQクラスター(バージョン3.0.2、Erlang R15B)を実行していますが、ネットワークパーティションエラーが定期的に発生し続けます。それらは物理的に同じデータセンターに配置されており、ネットワークは信頼できるものでなければなりません。ログを確認すると、両方のサーバーで「running_partitioned_network」エラーがほぼ同時に報告され、両方のノードが実行を継続しているため、ハードウェア障害やノードの1つが予期せず終了したとは思われません。この問題を軽減するためにnet_ticktimeを120秒に変更したところ、ほぼ1か月間発生しなくなりましたが、最近、数日に1回発生し始めました。 net_ticktimeが役に立ったのか、それとも偶然だったのかはわかりません。
さらにトラブルシューティングを行うために、Wiresharkを使用してローリングネットワークトレースを開始し、スケジュールされたタスクを使用して、ノードが再びパーティション化されたときにトレースを停止しました。私の目標は、パーティションの原因がネットワークの信頼性に欠けているのか、それともアプリケーションが応答しなかったのかを判断することです。ネットワーク障害を示すものとしてパケットトレースに飛び出すものはありません。TCP再送信はほんの一握りであり、他の多くのパケットがそれらの間で正常に送信されます。
この時点で、ネットワークが障害を引き起こしたことを証明または反証するために、パケットトレースで他に何を調べるべきかわかりません。 Wiresharkはアーラン分布プロトコルを識別してデコードできますが、メッセージを解釈してノードがパーティションを検出する原因を知る方法がわかりません。また、net_ticktimeは120秒に設定されており、サーバーが相互にメッセージを受信する際に120秒のギャップは見られません。他のサーバーからErlangメッセージが受信されない最長のギャップは22秒です(TCP確認応答)を数えるとはるかに短くなります)。他の唯一の考えは、特定の「ping」タイプの場合です。メッセージをノード間で送信する必要があり、その特定のメッセージが中断されましたが、トレースでどのように表示されるかわかりません。
この問題の原因をさらに診断する方法についてのアイデアは役に立ちます。
これが実際に当てはまるかどうかはわかりませんが、大きなメッセージが渡されると、Erlangクラスタリングが機能しなくなる可能性があります。 RabbitMQディスカッションメーリングリストのこのスレッドを見てください: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2012-March/018745.html
確かに「running_partitioned_network」メッセージはありませんが、ErlangR14B03のRabbitMQ2.8.4で同様の問題が発生しました。それは私たちにとって数ヶ月間は発生していません(はい、Nagios check_rabbitmq_splitbrainチェックを行うのに十分な回数発生しました)が、それが再び発生した場合に詳細をキャプチャできるかどうかを確認します...