文本介紹購買Elasticsearch(ES)執行個體時如何配置各節點參數,同時介紹各類型節點的功能特點。
資料節點
資料節點是儲存索引資料的節點,主要對文檔進行增刪改查、彙總等操作。資料節點對CPU、記憶體和IO要求較高,在最佳化叢集效能時需要監控資料節點的狀態。當資源不足時,建議在叢集中添加新的資料節點。
如果執行個體中有專有主節點,資料節點只作為資料節點。
如果執行個體中沒有專有主節點,則資料節點既作為資料節點,又作為專有主節點。
ES擴容在老架構(v2)沒有專有主節點的情況會觸發叢集重啟,新架構(v3)則不會。如果叢集整體負載不高且索引存在副本分區,重啟過程中仍可對外持續提供服務。然而,在某些特定情境下,重啟過程中可能會出現訪問逾時的情況,例如在重啟或強制重啟過程中存在大量寫入和查詢操作等。因此,建議在業務低峰期進行處理。
參數 | 說明 |
資料節點規格 | 2核4 GiB規格執行個體建議在測試環境中使用,生產環境建議您使用更高規格。 |
資料節點儲存類型 |
說明
|
資料節點儲存效能層級 | 資料節點儲存類型為ESSD雲端硬碟時,支援配置該參數。 |
資料節點雲端硬碟加密 |
說明
|
資料單節點儲存空間 | 資料單節點儲存空間與資料節點儲存類型有關:
說明 2 TiB以上的高效雲端硬碟通過磁碟陣列及RAID 0的方式提供服務,擴容時僅支援藍綠變更方式。 |
資料節點數量 | 購買的節點數量需要是可用性區域的整數倍。 重要 叢集僅配置2個資料節點會有腦裂等風險,低版本叢集(如6.x/5.x)在需要節點重啟的變更情境有無法選主風險,可能引發服務不可用,穩定性低,生產上請謹慎選擇。 |
Kibana節點
預設為啟用狀態,不可更改。
免費贈送1核2 GiB規格的Kibana節點,但僅建議在測試情境中使用。
受規格效能及穩定性影響,推薦購買2核4 GiB及以上規格的Kibana節點。
專有主節點
專有主節點的主要功能是對叢集進行操作,例如建立或刪除索引,跟蹤哪些節點是叢集的一部分,並決定哪些分區分配給相關的節點。穩定的主節點對叢集的健康非常重要,預設情況下叢集中的任一節點都可能被選為主節點。索引資料和搜尋查詢等操作會佔用大量的CPU、記憶體和IO資源,為了確保叢集的穩定性,建議您購買專有主節點,分離主節點和資料節點。
升配叢集時,如果之前的專有主節點是系統贈送的,在升配後將變為計費模式。
在使用基礎管控(V2)時,無專有主節點的叢集進行藍綠變更後,下次進行變更時,資料節點將會重啟,因此建議您考慮購買專有主節點。
參數 | 說明 |
專有主節點 |
說明
|
專有主節點規格 | 支援的規格以購買頁為準。 |
專有主節點儲存類型 |
支援的儲存類型以購買頁為準。 |
專有主節點儲存空間 | 預設為20 GiB,不可更改。 |
專有主節點數量 | 預設為3個,不可更改。 |
冷資料節點
如果您的業務中同時存在以下2種類型的資料索引,建議購買冷資料節點分離冷熱資料。冷熱叢集架構可以提高叢集的處理效能和服務穩定性。
查詢頻率高或寫入壓力大的索引。
查詢頻率低基本無寫入的索引(通常為歷史資料索引)。
更多資訊,請參見Elasticsearch Hot Warm Architecture。
如果執行個體中有專有主節點,則冷資料節點只作為資料節點。
如果執行個體中沒有專有主節點,則冷資料節點既作為資料節點,又作為專有主節點。
參數 | 說明 |
冷資料節點(也稱為warm節點) | 已購買的冷資料節點支援關閉。若關閉過程中叢集出現卡住,請參考關閉冷資料節點導致叢集卡住文檔進行問題修複。 |
冷資料節點規格 | 支援的規格請以購買頁為準。 I/O需求高、儲存需求大的情境,也可使用性價比較高的本地碟機型,其規格為
說明
|
冷資料節點儲存類型 | 支援高效雲端硬碟、ESSD雲端硬碟。 |
冷資料節點雲端硬碟加密 |
說明
|
冷資料節點儲存空間 | 最小儲存空間為500 GiB。 |
冷資料節點數量 | 購買的節點數量需要是可用性區域的整數倍。 |
購買冷資料節點後,系統會在節點啟動參數中加入-Enode.attr.box_type,如下所示。
節點類型 | 啟動參數 |
資料節點 | -Enode.attr.box_type=hot |
冷資料節點 | -Enode.attr.box_type=warm |
協調節點
協調節點可以分擔資料節點的CPU開銷,提高處理效能和服務穩定性。如果您的業務是CPU密集型的業務,建議購買協調節點,例如需要進行較多的彙總查詢之類的操作。
參數 | 說明 |
協調節點 | 雲端式原生管控架構部署的執行個體(7.16及以上版本執行個體),暫不支援取消已購買的協調節點,實際以購買頁為準。 |
協調節點規格 | 支援的規格以購買頁為準。 |
協調節點儲存類型 | 目前僅支援高效雲端硬碟。 |
協調節點儲存空間 | 預設為20 GiB,不可更改。 |
協調節點數量 | 購買的節點數量需要是可用性區域的整數倍。 |
相關文檔
購買ES執行個體,請參見建立Elasticsearch執行個體。
各節點的官方說明文檔,請參見Node | Elasticsearch Guide。
各節點規格的價格,請參見產品定價。
常見問題
關閉冷資料節點導致叢集卡住,應如何解決?
1、檢查叢集中是否主動配置了基於 box_type 的節點分配規則(即索引是否被強制分配到標記為 warm 的節點)
GET */_settings/index.routing.allocation.require.box_type查詢所有現有索引的
index.routing.allocation.require.box_type設定值。若返回
{"index.routing.allocation.require.box_type": "warm"},表示該索引必須分配到box_type=warm的節點。GET _template/?filter_path=.settings.index.routing.allocation.require.box_type查詢所有索引模板中是否配置了
box_type分配規則,若模板返回"index.routing.allocation.require.box_type": "warm",則所有新索引預設分配到冷資料節點。新索引建立時會繼承模板中的配置。若模板中設定了該值,所有後續建立的索引都會自動應用此規則。
GET _ilm/policy?filter_path=*.policy.phases.warm.actions.allocate.require.box_type查詢所有 ILM(Index Lifecycle Management)策略中,warm階段的節點分配配置。
若上述檢查結果中存在索引被分配到warm節點,此時通過降配操作關閉冷資料節點,叢集會出現變更卡住:

2、修複方法
從策略中移除box_type配置
# 建議先暫停 ilm POST _ilm/stop # 先查看具體的 ILM 策略 GET _ilm/policy/your_policy_name # 更新 ILM 策略,移除 warm 階段的 box_type配置 PUT _ilm/policy/your_policy_name { "policy": { "phases": { "warm": { "actions": { "allocate": { "require": { "box_type": null # 移除此配置 } } } }, "hot": { "actions": { "allocate": { "require": { "box_type": null # 如果有,也要移除 } } } } } } } # 如果 allocate 下的 require 為空白,建議刪除整個 allocate action # 或只保留其他必要的分配規則(如副本數等)從索引模板中移除box_type配置
# 先查看具體的模板名稱 GET _template/?filter_path=*.settings.index.routing.allocation.require.box_type # 更新模板,移除 box_type 配置 PUT _template/your_template_name { "settings": { "index.routing.allocation.require.box_type": null } } # 或者重新提交完整的模板定義(不包含 box_type 欄位)從索引中移除box_type配置
# 移除特定索引的 box_type 配置 PUT /your_index_name/_settings { "index.routing.allocation.require.box_type": null } # 大量移除所有索引的配置 { "index.routing.allocation.require.box_type": null }