【原】什么？ Elasticsearch 集群 18 個(gè)協(xié)調(diào)節(jié)點(diǎn)？

銘毅天下 2025-05-26 發(fā)布于廣東

展開(kāi)全文

1、問(wèn)題概述

球友的 Elasticsearch 集群(版本7.17.22)出現(xiàn)協(xié)調(diào)節(jié)點(diǎn)頻繁離開(kāi)和加入集群的情況。

根據(jù)主節(jié)點(diǎn)日志、協(xié)調(diào)節(jié)點(diǎn)日志，主要觀察到以下癥狀：

主節(jié)點(diǎn)與協(xié)調(diào)節(jié)點(diǎn)建連失敗，協(xié)調(diào)節(jié)點(diǎn)頻繁離開(kāi)和加入集群
有大量"receive response timeout"警告日志
CPU 和內(nèi)存資源未達(dá)到瓶頸
集群內(nèi)有耗時(shí)2-3分鐘的 update_by_query 操作
集群配置為3個(gè)專有 master 節(jié)點(diǎn)、18個(gè)專有協(xié)調(diào)節(jié)點(diǎn)、39個(gè)專有數(shù)據(jù)節(jié)點(diǎn)
QPS高達(dá) 100k /秒
集群狀態(tài)一直保持 green
問(wèn)題出現(xiàn)突然，之前系統(tǒng)運(yùn)行穩(wěn)定多年
即使將協(xié)調(diào)節(jié)點(diǎn)減少到12個(gè)甚至6個(gè)（后面交流后的試驗(yàn)），問(wèn)題依然存在。——問(wèn)題來(lái)源：https://t./1jlj3

2、問(wèn)題分析

2.1. 核心日志分析

從master節(jié)點(diǎn)日志可以看到TCP握手超時(shí)問(wèn)題：

[2025-05-20T01:05:54,449Z] [WARN] [o.e.t.OutboundHandler] [cluster_name: "counos-history-pii-es", node_name: "master-new-b-10-21-68-72"] 
message: "[Request{internal: tcp/handshake}][2858533]{false}{false}{true}] of size [58] on [Netty4TcpChannel{localAddress=/10.219.68.72:39467, remoteAddress=/10.219.199.222/10.210.190.222:9300, profile=default}]] 
took [10004ms] which is above the warn threshold of [5000ms] with success [false]"

從協(xié)調(diào)節(jié)點(diǎn)日志可以看到連接超時(shí)問(wèn)題：

[2025-05-16T22:10:42,149Z] [WARN] [o.e.c.c.ClusterApplierService] [cluster_name: "counos-history-pii-es", node_name: "client-new-a-10-219-68-72"] 
message: "failed to connect to {client-new-c-10-210-188-186}{8RkYvZGRt83q4tnJBEw}{}[oP2Y5fnmW6t2038g-eg]{10.210.190.222}{10.210.190.222:9300}{aws-az-ap-northeast-2c, xpack.installed=true, transform_node=false} 
(tried [[#transport#-#[221]{8RkYvZGRt83q4tnJBEw}]]); java.io.IOException: timeout"

2.2. 潛在原因分析

2.2.1 協(xié)調(diào)節(jié)點(diǎn)數(shù)量過(guò)多

根據(jù) Elasticsearch 最佳實(shí)踐，18 個(gè)協(xié)調(diào)節(jié)點(diǎn)對(duì)于 39 個(gè)數(shù)據(jù)節(jié)點(diǎn)的集群配比過(guò)高。

我和金兄（金多安）討論過(guò)這個(gè)問(wèn)題，我的第一反應(yīng)是不需要那么多協(xié)調(diào)節(jié)點(diǎn)。

官方有沒(méi)有明確指出多大集群規(guī)模需要配置多少個(gè)協(xié)調(diào)節(jié)點(diǎn)？

這個(gè)實(shí)話說(shuō)，翻遍官方文檔是沒(méi)有提及的。

但是，從一些實(shí)踐博客、球友的反饋中基本可以得出如下實(shí)踐結(jié)論，詳見(jiàn)后文附的鏈接。

大量協(xié)調(diào)節(jié)點(diǎn)可能導(dǎo)致 master 節(jié)點(diǎn)需要維護(hù)過(guò)多連接，增加網(wǎng)絡(luò)和處理負(fù)擔(dān)。

由于官方文檔未提供具體數(shù)量，建議參考以下步驟來(lái)確定協(xié)調(diào)節(jié)點(diǎn)數(shù)量：

unsetunset監(jiān)控集群性能。unsetunset

使用工具如 Kibana 或 Elasticsearch API 監(jiān)控協(xié)調(diào)節(jié)點(diǎn)的CPU、內(nèi)存、網(wǎng)絡(luò)負(fù)載以及查詢延遲。

如果數(shù)據(jù)節(jié)點(diǎn)因協(xié)調(diào)任務(wù)過(guò)載，考慮引入專用協(xié)調(diào)節(jié)點(diǎn)。

unsetunset從少量開(kāi)始，不要“一口吃個(gè)大胖子”。unsetunset

對(duì)于中小型集群（10-20個(gè)數(shù)據(jù)節(jié)點(diǎn)），從1-2個(gè)協(xié)調(diào)節(jié)點(diǎn)開(kāi)始，逐步增加并測(cè)試性能。

unsetunset大型集群調(diào)整，對(duì)于20-50個(gè)數(shù)據(jù)節(jié)點(diǎn)的集群，3-6個(gè)協(xié)調(diào)節(jié)點(diǎn)可能是一個(gè)合理的范圍。unsetunset

但需通過(guò)負(fù)載測(cè)試驗(yàn)證。注意前文提到的用戶集群 39 個(gè)專有數(shù)據(jù)節(jié)點(diǎn)，配備了18個(gè)協(xié)調(diào)節(jié)點(diǎn)。

unsetunset超大型集群，對(duì)于50+節(jié)點(diǎn)的集群，6-12個(gè)協(xié)調(diào)節(jié)點(diǎn)的建議可能適用于高負(fù)載場(chǎng)景。unsetunset

但需監(jiān)控主節(jié)點(diǎn)的集群狀態(tài)同步負(fù)載，以避免過(guò)多協(xié)調(diào)節(jié)點(diǎn)導(dǎo)致的開(kāi)銷。

特別說(shuō)明：協(xié)調(diào)節(jié)點(diǎn)通常相對(duì)較低的磁盤(pán)和 CPU 資源，但內(nèi)存需求可能較高（建議50% RAM分配給JVM堆，最大不超過(guò)32GB）。

2.2.2 網(wǎng)絡(luò)通信問(wèn)題

日志顯示節(jié)點(diǎn)間通信超時(shí)(54s/54040ms和51s/51039ms)，可能是由于：網(wǎng)絡(luò)延遲或丟包。盡管用戶檢查未發(fā)現(xiàn)丟包，但 AWS EC2 環(huán)境中網(wǎng)絡(luò)偶發(fā)性延遲仍可能發(fā)生。

事后，我交流環(huán)節(jié)得知 docker 部署集群，docker 集群網(wǎng)絡(luò)的穩(wěn)定性也是我懷疑的原因。我對(duì) docker 網(wǎng)絡(luò)穩(wěn)定性一直存有疑問(wèn)。

也可能存在 TCP 連接管理問(wèn)題，Elasticsearch 期望節(jié)點(diǎn)間的TCP連接保持長(zhǎng)期開(kāi)放，可能有連接被提前關(guān)閉。

2.2.3 節(jié)點(diǎn)間連接建立與維護(hù)問(wèn)題

協(xié)調(diào)節(jié)點(diǎn)和 master 節(jié)點(diǎn)之間的 TCP 握手失敗，導(dǎo)致連接無(wú)法建立。

節(jié)點(diǎn)健康檢查超時(shí)，可能是因?yàn)?follower check retry count exceeded"。

2.2.4 耗時(shí)的update_by_query操作

update_by_query 內(nèi)部是scan and scroll操作，持續(xù)耗時(shí)2-3分鐘的操作會(huì)占用大量資源。

這類操作可能導(dǎo)致集群網(wǎng)絡(luò)壓力增大，影響節(jié)點(diǎn)間通信質(zhì)量。

長(zhǎng)時(shí)間運(yùn)行的update_by_query會(huì)增加集群整體負(fù)載，尤其是當(dāng) QPS 已經(jīng)高達(dá)10萬(wàn)/秒時(shí)。

3、解決方案

3.1. 優(yōu)化協(xié)調(diào)節(jié)點(diǎn)配置

（1）減少協(xié)調(diào)節(jié)點(diǎn)數(shù)量

這是我的第一個(gè)建議。

將協(xié)調(diào)節(jié)點(diǎn)數(shù)量減少到 12個(gè)，并逐步減少到6個(gè)，以匹配 39 個(gè)數(shù)據(jù)節(jié)點(diǎn)的規(guī)模。

盡管球友嘗試過(guò)減少數(shù)量但問(wèn)題未解決，這可能是因?yàn)閱?wèn)題根源不僅在于數(shù)量，還涉及其他因素。

（2）優(yōu)化節(jié)點(diǎn)間通信配置：

調(diào)整discovery.zen.fd.ping_timeout和discovery.zen.fd.ping_retries參數(shù)以適應(yīng)網(wǎng)絡(luò)環(huán)境。

特別說(shuō)明：8.X 版本已經(jīng)不支持。

https://www./guide/en/elasticsearch/reference/8.9/migrating-8.0.html

檢查 TCP 連接保持設(shè)置，確保節(jié)點(diǎn)間的TCP連接不會(huì)被過(guò)早關(guān)閉。

3.2. 優(yōu)化網(wǎng)絡(luò)配置

檢查AWS EC2網(wǎng)絡(luò)設(shè)置：

檢查安全組是否有對(duì) TCP 連接的不適當(dāng)限制；確認(rèn)net.ipv4.tcp_retries2配置合理，避免過(guò)早放棄 TCP 重試；檢查 VPC 網(wǎng)絡(luò)配置和子網(wǎng)間通信質(zhì)量。

3.3. 優(yōu)化update_by_query操作

（1）分批執(zhí)行update_by_query：對(duì)大規(guī)模 update_by_query 操作進(jìn)行分批處理，避免單個(gè)任務(wù)運(yùn)行時(shí)間過(guò)長(zhǎng)。

考慮使用slicing機(jī)制：

POST /index/_update_by_query?slices=auto

（2）限制并發(fā)update_by_query數(shù)量：

使用wait_for_completion=false和任務(wù) API 管理并發(fā)量。

避免大量 update_by_query 同時(shí)運(yùn)行。

（3）優(yōu)化update_by_query查詢條件：

確保查詢使用了適當(dāng)?shù)倪^(guò)濾器和索引，目的減少數(shù)據(jù)量。

考慮提高 refresh_interval 暫時(shí)減少刷新頻率。

4、總結(jié)

針對(duì)協(xié)調(diào)節(jié)點(diǎn)頻繁離開(kāi)和加入集群的問(wèn)題，我們分析了可能的原因，包括網(wǎng)絡(luò)通信問(wèn)題、節(jié)點(diǎn)連接維護(hù)問(wèn)題、協(xié)調(diào)節(jié)點(diǎn)數(shù)量配置不當(dāng)以及耗時(shí)update_by_query 操作的影響。

雖然減少協(xié)調(diào)節(jié)點(diǎn)數(shù)量是一個(gè)合理的嘗試，但根本問(wèn)題可能是由多個(gè)因素共同導(dǎo)致的。建議綜合采取網(wǎng)絡(luò)優(yōu)化、參數(shù)調(diào)整以及優(yōu)化 update_by_query 操作的措施，同時(shí)增強(qiáng)監(jiān)控以便更準(zhǔn)確定位根本原因。

特別是對(duì)于高QPS的環(huán)境(10萬(wàn)/秒)，合理配置集群拓?fù)浣Y(jié)構(gòu)和網(wǎng)絡(luò)參數(shù)至關(guān)重要。最終解決方案可能需要結(jié)合多方面的調(diào)整，才能恢復(fù)集群的穩(wěn)定性。