TCP 再送信タイムアウト

各 Elasticsearch ノードのペアは、ノードの一方がシャットダウンするか、基盤となるインフラストラクチャの障害によってノード間の通信が中断されるまで、いくつかの TCP 接続を介して通信します。

TCP は、通信アプリケーションから一時的なネットワークの中断を隠すことによって、時折信頼性のないネットワーク上で信頼性のある通信を提供します。オペレーティングシステムは、問題を送信者に通知する前に、失われたメッセージを何度か再送信します。Elasticsearch は再送信が行われている間待機し、オペレーティングシステムが諦めることを決定したときにのみ反応できます。したがって、ユーザーも再送信のシーケンスが完了するのを待たなければなりません。

ほとんどの Linux ディストリビューションは、失われたパケットを 15 回再送信することをデフォルトとしています。再送信は指数関数的にバックオフするため、これらの 15 回の再送信には 900 秒以上かかります。これは、Linux がこの方法でネットワークパーティションやノードの障害を検出するのに数分かかることを意味します。Windows はデフォルトで 5 回の再送信を行い、これは約 13 秒のタイムアウトに相当します。

Linux のデフォルトは、非常に長いパケットロスの期間を経験する可能性のあるネットワーク上での通信を許可しますが、このデフォルトは過剰であり、ほとんどの Elasticsearch インストールで使用される高品質のネットワークでは有害です。クラスターがノードの障害を検出すると、失われたシャードの再割り当て、検索のルーティングの変更、場合によっては新しいマスターノードの選出を行います。高可用性のクラスターは、ノードの障害を迅速に検出できる必要があり、これは許可される再送信の数を減らすことで達成できます。リモートクラスターへの接続も、Linux のデフォルトが許可するよりもはるかに迅速に障害を検出することを優先すべきです。したがって、Linux ユーザーは TCP 再送信の最大数を減らすべきです。

最大 TCP 再送信数を 5 に減少させるには、root として次のコマンドを実行します。5 回の再送信は約 13 秒のタイムアウトに相当します。

  1. sysctl -w net.ipv4.tcp_retries2=5

この値を永続的に設定するには、net.ipv4.tcp_retries2 設定を /etc/sysctl.conf で更新します。再起動後に確認するには、sysctl net.ipv4.tcp_retries2 を実行します。

この設定はすべての TCP 接続に適用され、Elasticsearch クラスター以外のシステムとの通信の信頼性にも影響します。クラスターが低品質のネットワークを介して外部システムと通信する場合、net.ipv4.tcp_retries2 のためにより高い値を選択する必要があるかもしれません。このため、Elasticsearch はこの設定を自動的に調整しません。

関連する設定

Elasticsearch は、Linux のデフォルトの再送信タイムアウトよりもはるかに短いタイムアウトを持つ独自の内部ヘルスチェックも実装しています。これらはアプリケーションレベルのヘルスチェックであるため、タイムアウトはガーベジコレクションの一時停止などのアプリケーションレベルの影響を考慮する必要があります。これらのアプリケーションレベルのヘルスチェックに関連するタイムアウトを短縮しないでください。

また、ノード間の長期間の接続に干渉しないように、ネットワークインフラストラクチャを確保する必要があります。接続がアイドル状態に見える場合でも、接続が特定の年齢に達したときに切断されるデバイスは、Elasticsearch クラスターにとって一般的な問題の原因であり、使用してはいけません。