叢集升配,叢集擴容,叢集升級配置,叢集變更配置 - Elasticsearch

當Elasticsearch（ES）叢集的CPU、記憶體、磁碟等資源使用率持續處於高位，或查詢與寫入效能無法滿足業務需求時，可通過擴充節點數量、提升節點規格、增加磁碟空間、新增節點類型等方式升級叢集配置，恢複服務穩定性。

升配前須知

重要

升配操作可能引發服務延遲、配置衝突及費用變更，請務必提前完整閱讀以下須知內容。

服務穩定性

叢集變更期間服務穩定性規則：

叢集	服務狀態	應對措施
正常負載+有副本正常負載：CPU≤60%、堆記憶體≤50% 、load<核心數	持續服務，效能可能輕微下降	無需額外操作
高負載+無副本高負載：升配時高並發寫入或者查詢，CPU>60%、堆記憶體>50%	偶發訪問逾時	用戶端啟用重試機制升配前增加索引複本數
高負載+狀態異常	偶發訪問逾時或者抖動	修複叢集狀態後再變更

操作視窗：業務低峰期進行。

容量規劃
合理評估叢集所需容量。
配置約束
- 升配不支援版本升級。
- 一次升配操作僅支援變更一種類型的節點。
- V3 架構（雲原生新管控）執行個體不支援關閉智能變更開關：調用更新執行個體配置的 API 時，即使將 intelligent 參數設定為 false，系統也會將其覆蓋為 true；控制台變更配置頁面也不提供智能變更開關，節點規格或磁碟類型升配始終走藍綠變更路徑。
成本影響
提交升配訂單後，系統將按照更新後的配置單計費。計費規則請參見隨用隨付、訂用帳戶。

常見情境推薦規格

根據叢集當前的效能瓶頸，參考以下情境選擇合適的節點規格類型系列：

情境類型	規格類型系列	樣本規格	適用情境
CPU/寫入密集型	1:2 計算型（CPU:記憶體 = 1:2）	8 核 16 GiB	CPU 利用率持續偏高，或寫入輸送量較大的業務。建議在 1:2 規格類型系列內縱向提升核心數（如升至 16 核 32 GiB），以直接擴充 CPU 資源。
均衡型	1:4 通用型（CPU:記憶體 = 1:4）	8 核 32 GiB	CPU 利用率適中、同時需要更大的 JVM 堆記憶體或堆外記憶體（page cache）的情境。
記憶體密集型	1:8 記憶體型（CPU:記憶體 = 1:8）	8 核 64 GiB	深度彙總分析、大型索引緩衝，或 JVM 堆記憶體使用量率長期偏高的情境。

說明

記憶體升級對寫入速度有一定的間接提升（更大的 JVM 堆記憶體可減少 GC 停頓，更多的堆外記憶體可減少磁碟 I/O），但實際效果因業務負載和資料量而異，建議先在測試環境驗證後再做決策。如需完整評估叢集容量需求，請參見評估叢集所需容量。

說明

生產環境不建議使用 ≤2C4G 的小規格節點：在無業務負載的情況下，系統進程和監控索引維護會佔用不成比例的基礎資源，可能導致 CPU 使用率異常飆升甚至節點失聯。建議生產環境最低選用 4C8G 規格的節點。

升配前檢查

重要

未完成以下檢查直接升配可能導致叢集崩潰、資料丟失或服務不可用，請逐項檢查驗證。

叢集健康
執行GET _cluster/health 確保叢集為狀態為GREEN。如遇叢集狀態不健康，請參照叢集變更報錯-叢集狀態不健康進行解決。
負載安全
執行GET _cat/nodes?v ，建議CPU ≤ 60%，如果超出，用戶端啟用重試機制，同時增加索引複本數。
索引就緒
- 執行GET /_cat/indices?v檢查是否存在狀態為CLOSE的索引。如果存在，需執行POST /<index_name>/_open臨時開啟這些索引，否則配置變更可能失敗，原因說明：
  - 存在CLOSE狀態的索引時，叢集狀態無法達到GREEN。ES在執行某些敏感配置變更（如分區分配規則調整）前會強制要求叢集狀態為GREEN。
  - 變更配置過程中叢集會重新分配分區：
    - 關閉索引的分區無法參與重分配。
    - 導致依賴GREEN狀態的操作失敗。
    - 導致叢集狀態無法達到GREEN（最高只能達到YELLOW）。
- 若 CLOSE 索引因業務原因無法開啟也無法刪除，升配校正仍可能提示“叢集狀態不健康，不能執行當前操作”。即使執行GET _cluster/health看到叢集狀態正常，該提示也可能由 CLOSE 索引觸發，屬於預期的校正行為。此時可在變更配置頁面關閉智能變更，手動將變更方式指定為原地變更後繼續升配：原地變更採用變換節點、無需拷貝資料，節點 IP 位址不變，耗時相對較短，適用於存在大量 CLOSE 索引且無法處理的情境。
  說明
  該方案僅適用於可關閉智能變更的 V2 架構執行個體。V3 架構（雲原生新管控）執行個體不支援關閉智能變更開關，節點規格或磁碟類型升配始終走藍綠變更路徑，架構版本判斷方式請參見本文「判斷叢集架構版本」小節。若當前叢集水位較高（如 CPU>60%），選擇原地變更時請謹慎評估。
- 執行GET _cat/indices?v檢查索引複本數是否至少為1。
  對於多可用性區域執行個體，在變更時需確保叢集中任意一個索引的副本數小於可用性區域數，建議副本數設定為1，變更完成後，手動增加副本數。
分區均衡
執行GET _cat/shards?v檢查是否存在不均衡的分區。
重要
升配前檢查分區分布是否均衡，是預防升配過程中或完成後叢集效能惡化甚至崩潰的關鍵措施。
- prirep：副本分區（r）是否未分配（UNASSIGNED）。
- state：是否存在長期遷移卡住（RELOCATING）。
上述問題會阻止新節點正常接收分區，導致升配後叢集狀態持續YELLOW/RED，如存在上述問題，請參見叢集負載不均解決方案進行解決。

判斷叢集架構版本

ES 叢集存在 v2、v3 兩種管控部署架構，架構不同，可選的升配方式與預估耗時也不同（詳見本文「方式一：通過控制台升配」中的變更方式耗時說明）。升配前請先確認當前叢集的架構版本。

方式一：通過控制台查看

登入 ES 控制台，在執行個體基本資料頁面，查看管控部署模式欄位的取值，即為當前叢集的架構版本。

方式二：通過 ES 版本號碼判斷

架構版本	對應 ES 版本號碼
v2	5.5.3、5.6.16、6.3.2、部分 6.7.0、6.8.6、7.4.0、7.7.1、部分 7.10.0、部分 7.16.2
v3	部分 6.7.0、6.8.23、部分 7.10.0、部分 7.16.2、8.x 及以上

說明

6.7.0、7.10.0、7.16.2 這三個版本號碼下同時存在 v2 與 v3 架構的執行個體，無法僅憑版本號碼唯一判定，請以控制台基本資料頁面的管控部署模式欄位為準。

方式一：通過控制台升配

在執行個體列表，單擊升配。
更多操作入口：在基本資料頁面，單擊配置變更 > 節點擴容

在變配頁面，根據業務需要調整配置項參數。

重要

可調整的配置項參數因叢集類型和版本不同而有所出入，以升配頁面為準。

可用性區域數量變更配置規則如下，如遇可用性區域規格庫存不足時，需遷移可用性區域下的節點後再升配。
擴增：支援從 1 個可用性區域擴增至 2 個或 3 個可用性區域。
縮減：暫不支援將多可用性區域執行個體縮減為單可用性區域。如需此操作，請重新購買滿足需求可用性區域的執行個體，進行資料移轉，待遷移完成後釋放原執行個體。
支援節點規格（節點儲存類型）升級，按效能從低到高排序：
1. 上一代雲端硬碟：雲端硬碟（普通雲端硬碟）-> 高效雲端硬碟->SSD雲端硬碟。
  說明
  已在部分地區及可用性區域逐步停止售賣，您在選擇雲端硬碟時，建議選用ESSD雲端硬碟。
2. ESSD雲端硬碟：ESSD（Enterprise SSD）雲端硬碟結合25 GE網路和RDMA技術，為您提供單盤高達100萬的隨機讀寫能力和單路低時延效能。
3. 本地碟。
  說明
  本地碟是ECS執行個體所在物理機上的本地硬碟裝置，為ECS執行個體提供本機存放區訪問能力，適用於對儲存I/O效能、海量儲存性價比有極高要求的業務情境。
SSD 雲端硬碟升級為 ESSD 雲端硬碟
當叢集磁碟 IOUtil 使用率較高且經常打滿時，建議將磁碟類型從 SSD 雲端硬碟升級為 ESSD 雲端硬碟，以提升 I/O 效能。
儲存升配約束
- ESSD PL0 限制：已有 SSD 雲端硬碟執行個體升配到 ESSD 雲端硬碟時，PL0 不可選，只能選擇 PL1 及以上效能層級。建立 ESSD 執行個體時 PL0 仍可選。
- 強制變更：磁碟已打滿導致叢集狀態異常時，需先刪除不必要的索引或降低副本數恢複 GREEN 狀態，否則可在升配頁面勾選該選項進行強制擴配（會跳過叢集健全狀態檢查，可能導致服務在重啟階段不穩定）。升配頁面同時提供智能變更選項（預設開啟），系統會根據變更類型自動選擇合適的變更方式。
- 本地碟：本地碟儲存空間與執行個體節點規格物理綁定，無法獨立調整；升配本地碟儲存空間需依賴整體節點規格的升配。當前建立執行個體僅支援“新一代雲端硬碟型”規格類型系列，本地碟僅適用於存量執行個體。
- 儲存自動擴容：ES 不支援類似雲資料庫 RDS 的儲存自動擴容功能，磁碟空間不足時需手動執行升配操作。
組合變更注意事項：若需同時進行規格升配、磁碟類型變更及擴容，請注意修改磁碟類型不支援原地變更，僅支援藍綠變更。為避免多次資料移轉，建議分步操作：
1. 先進行執行個體規格變更和擴容（可使用智能變更或原地變更），待服務恢複後再執行下一步。
2. 單獨進行磁碟類型變更（藍綠變更）。藍綠變更僅在資料同步完成切換節點時可能有閃斷，對業務影響較小。

智能變更（預設開啟）：系統根據變更配置項自動選擇最優變更方式。可手動關閉並指定變更方式：

變更方式	原理	耗時	服務影響和使用情境
藍綠變更	添加新節點→拷貝資料→無縫切換	較長	節點IP會發生變化、叢集效能可能出現短暫波動。適用於對變更時間長度不敏感，對叢集可用性要求較高的情境。
原地變更	變換節點（無需資料拷貝）	較短	節點IP無變化、叢集效能可能出現短暫波動。適用於叢集遇到效能瓶頸，期望快速完成變更的情境。重要如果水位較高（如CPU>60%），謹慎選擇原地變更。

V2 架構執行個體預估耗時（藍綠變更）

V2 架構叢集進行資料節點規格升配或 ES 版本升級時走藍綠變更，可按以下方式預估耗時：

總耗時 = 管控側耗時 + 資料移轉耗時

管控側耗時 = 節點數 × 10 分鐘 × 2。藍綠變更需要先新增一批新節點、再下線一批老節點，因此每個節點按兩輪、每輪約 10 分鐘計算。
資料移轉耗時（單位：小時）= 單資料節點最巨量資料量 / indices.recovery.max_bytes_per_sec / 3600。其中 indices.recovery.max_bytes_per_sec 的預設值為 40 MB/s，可通過 GET /_cluster/settings 查看當前值並按需調整。

例如，V2 架構叢集有 3 個資料節點做規格升配，管控側耗時約為 3 × 10 × 2 = 60 分鐘（約 1 小時），再加上按上述公式計算出的資料移轉耗時，即為預計總耗時。

V3 架構執行個體預估耗時（藍綠變更）

V3 架構叢集走藍綠變更時，可按以下方式預估耗時：

總耗時 = 管控側耗時 + 資料移轉耗時

管控側耗時：約 10~20 分鐘（涉及新節點啟動、下掉老節點）。
資料移轉耗時（單位：小時）= 單資料節點最巨量資料量 / indices.recovery.max_bytes_per_sec / 3600。

indices.recovery.max_bytes_per_sec 的預設值為 40 MB/s，可通過 GET /_cluster/settings 查看當前值並按需調整。

例如，叢集有 3 個資料節點、總資料量 3 TB（單資料節點最巨量資料量約 1 TB），indices.recovery.max_bytes_per_sec 設定為 100 MB/s 時，資料移轉耗時約為 1 TB / 100 MB/s / 3600 ≈ 2.8 小時。

說明

原地變更並非所有操作都會觸發滾動重啟：

節點規格變更（如升級 CPU、記憶體）會逐個重啟節點完成變更。
V3 架構叢集各升配情境的服務影響如下：
- 儲存空間升配：僅執行線上擴容，無需重啟節點，不影響變更期間的任務運行。
- 橫向擴容（增加資料節點）：老資料節點不重啟，變更完成後系統自動進行分區均衡，資料搬遷會佔用部分叢集資源。
- 節點規格或磁碟類型升配：預設走藍綠變更，新增節點完成資料移轉後下線老節點，變更結束時業務側可能出現少量異常，請提前評估影響。

強制變更：跳過健全狀態檢查，但會觸發叢集強制重啟，可能導致服務長時間中斷（恢復取決於資料量），僅用於緊急擴容且叢集已不可用情境。

單擊查看产品服务协议、服务等级协议，無異議後，單擊立即购买，系統按照付費方式收取費用。
變更期間，叢集狀態變為生效中，叢集效能可能出現短暫波動，可能出現請求閃斷；變更完成後，叢集狀態更新為正常。

方式二：調用API升配

叢集升配API文檔：UpdateInstance

進度監控與升配後驗證

升配開始後查看進度：通過控制台->Elasticsearch執行個體->執行個體基本資料，單擊展開詳情：
升配完成後通過叢集基本資料頁確認配置是否生效：
- 叢集狀態恢複為正常表示配置已生效。
- 可用性區域是否與預期一致。
- 節點數和儲存規格：確認新節點已加入叢集、儲存規格是否正確。
- 分區均衡：GET _cat/allocation?v 檢查分區分布，如遇分區不均衡，請參考叢集負載不均解決方案進行解決。

升配狀態長時間處於“生效中”的排查方法

升配開始後，叢集狀態會變為生效中；如果該狀態期間超出預期，可按以下方法排查：

正常耗時參考：ESSD 雲端硬碟擴容通常需要 30 分鐘至 1 小時完成，如果超過 2 小時仍未恢複，需要進一步排查。
V2 架構叢集分區分配檢查：部分 V2 架構叢集在擴容過程中會自動禁用分區分配（cluster.routing.allocation.enable 被設定為 none）以避免擴容期間分區抖動，如果擴容完成後該設定未自動回復，會導致狀態長時間卡在生效中。可在 Kibana Dev Tools 中執行以下命令重新啟用分區分配：
```
PUT /_cluster/settings
{
  "transient" : {
    "cluster.routing.allocation.enable" : "all"
  }
}
```
遷移加速：如果資料搬遷速度較慢導致耗時變長，可在控制台將節點資料傳輸頻寬調整至 80 以加速資料移轉。
Business Connectivity逾時說明：升級過程中執行個體重啟會導致Business Connectivity短暫逾時，這屬於正常現象，建議業務端增加重試機制以降低影響。

常見問題

升配與效能指標

Q：升配一定能解決我的ES叢集效能問題嗎？

A：不一定。升配（增加CPU、記憶體、磁碟等資源）並非萬能解決方案。在決定升配前，請先分析具體瓶頸：

CPU瓶頸：持續長時間超過80%的CPU使用率（非短暫峰值）
記憶體瓶頸：頻繁出現GC時間過長、記憶體交換（swap）或OOM錯誤
磁碟瓶頸：關注實際I/O輸送量而非僅看%util指標（詳見下文）
網路瓶頸：網路頻寬持續打滿，延遲明顯增加

升配前請先確認實際瓶頸所在，避免不必要的資源浪費。有時通過索引最佳化、查詢最佳化或調整配置可能比單純升配更有效。

Q：為什麼我的%util指標經常達到100%，但系統似乎運行正常？

A：iostat中的%util指標表示裝置有I/O（即非空閑）的時間比率，不考慮I/O請求量有多少，只考慮有沒有I/O活動。由於現代硬碟裝置具備平行處理多個I/O請求的能力，即使%util達到100%，也不意味著裝置已飽和：

例如：某硬碟處理單個I/O需要0.1秒，有能力同時處理10個I/O請求
- 當10個I/O請求依次提交時，需要1秒完成，此時%util為100%
- 若10個I/O請求一次性提交，0.1秒就完成，此時%util只有10%

重要提示：%util指標在現代儲存系統中已基本失去參考意義，不應僅憑此指標判斷是否需要升配。

Q：應該關注哪些指標來判斷磁碟效能瓶頸？

A：應重點關注以下指標而非僅看%util：

I/O輸送量：實際讀寫資料的速率（MB/s），與您的業務需求對比
回應時間：I/O請求的延遲時間，直接影響查詢效能
IOPS：每秒I/O運算元量，與業務模式比對
隊列深度：反映I/O請求等待情況

建議：非長時間（持續數小時）達到100%的%util指標無需特別關注。真正的效能瓶頸應通過fio等專業工具進行壓測，擷取實際的極限頻寬和IOPS值來判斷。

Q：如何正確評估磁碟是否達到效能瓶頸？

A：請按以下步驟進行評估：

分析業務模式：瞭解您的讀寫比例、I/O大小等特徵
關注實際輸送量：與業務需求對比，而非僅看%util
使用專業工具測試：通過fio等工具類比實際業務負載，測試磁碟在真實情境下的效能
評估查詢延遲：ES查詢回應時間是否滿足業務要求
監控關鍵計量：如indexing latency、search latency等ES內部指標

如需確認是否需要升配，請提供完整的效能監控資料，包括但不限於：CPU使用率、記憶體使用量情況、I/O輸送量、查詢延遲等，而非僅基於單一指標做決策。

升配操作影響

Q：升配或磁碟擴容是否支援設定執行時間或立即生效？

A：升配和磁碟擴容均不支援定時執行。無論是升配（如提升節點規格、擴節點）還是磁碟擴容，配置提交並支付後，系統會立即生效並觸發變更與重啟流程，無法指定具體的執行時間或重啟時間。如果希望在特定時間點（如業務低峰期淩晨 3 點）執行變更，需在該時間點手動完成支付和提交操作。

Q：增加資料節點後是否需要重建索引？

A：不需要。增加資料節點是線上操作，叢集會自動處理資料的重新分配（Rebalance），現有的索引、資料和業務查詢都不會中斷。

Q：小規格（≤2C4G）ES 節點在無業務負載時 CPU 飆升至 90% 以上並導致節點失聯，是什麼原因？如何處理？

A：出現該現象通常由以下原因導致：

資源規格不足：≤2C4G 規格下，系統進程本身會佔用一部分基礎資源，官方不建議在生產環境使用 ≤2C4G 規格的節點。
JVM 堆記憶體水位過高：堆記憶體使用量率長期處於 85% 以上時，輕微的負載波動即可將堆記憶體打滿，從而頻繁觸發 Full GC，導致 CPU 出現峰值。
監控開銷放大：在低規格節點上，監控索引的維護開銷相對於節點總資源佔比更高，容易造成資源消耗不成比例地上升。

解決方案：

緊急處理：重啟異常節點，釋放被佔用的資源，此方式僅為臨時緩解措施。
根本處理：將節點規格升配至 4C8G 或更高規格，升配操作請參見本文「方式一：通過控制台升配」章節。

Q：升配期間如何保障商務持續性？

A：建議採取以下措施：

確保每個索引至少有 1 個副本，並使叢集資源使用率保持在正常水平。
升配期間可能出現請求閃斷，需在應用端配置重試機制。
升配期間如發生故障，請及時切流。

Elasticsearch：升配叢集