注意事項

本文根據實際測試結果和用戶使用經驗提供評估方法。由于不同用戶在數據結構、查詢復雜度、數據量大小、性能及數據變化等方面的需求不同，本文的評估不一定適用于所有用戶。建議您在條件允許的情況下，通過實際的數據和使用場景測試出適合自己的集群規格容量規劃。

評估集群存儲空間

影響ES集群存儲空間大小的因素主要包括：

• 源數據的大小。

• 索引的副本數量：每個索引至少需要1個副本。

• 索引開銷：通常比源數據大10%。

  例如，存儲X-Pack組件用于異常分析的監控類索引，主要包含：

  • .monitoring-es-6-*：占用空間相對比較大，默認保留最近7天的索引數據。

  • .monitoring-kibana-6-*：索引數越大占用空間也越大，默認保留最近7天的索引數據。

  • .watcher-history-3-*：占用空間相對比較小，如果開啟，需要您手動刪除。

• ES實例內部開銷：段合并、日志等內部操作，預留20%。

  存儲集群日志（包括運行日志、訪問日志和慢日志）隨著查詢或推送訪問量的增加，空間占比不斷增大，默認保留最近7天的日志，不支持修改。

• 操作系統預留空間：默認操作系統會保留5%的文件系統供您處理關鍵流程、系統恢復以及磁盤碎片等。

• 安全閾值：通常至少預留15%的安全閾值。

根據以上因素得到建議集群存儲空間：

集群存儲空間 = 源數據 *（1 + 副本數量）* 索引開銷 /（1 - 操作系統預留空間）/（1 - ES實例內部開銷）/（1 - 安全閾值）
             = 源數據 *（1 + 副本數量）* 1.7
             = 源數據 * 3.4

評估節點規格和節點數量

數據節點

• 最大節點數量 = 單節點CPU大小 * 5。

• 業務場景不同，單節點最大承載數據量也不同：

  • 通用場景：單節點最大存儲空間 = 單節點內存大小（GiB）* 30。

  • 搜索場景（數據庫加速、查詢聚合等）：單節點最大存儲空間 = 單節點內存大小（GiB）* 10。

  • 日志分析場景（日志寫入、離線分析等）：單節點最大存儲空間 = 單節點內存大小（GiB）* 50。

根據以上計算方式，得到部分節點規格的最大節點數量和單節點最大存儲空間：

集群存儲空間=單節點存儲空間*節點數量，您可以根據單節點最大存儲空間和最大節點數量選擇滿足業務要求的節點規格。

專有主節點

如果集群的數據節點較多，建議您開啟專有主節點，以保證集群穩定性。

專有主節點規格選擇：

• 初始規格：2 核8 GiB

• 超過10個數據節點：4 核16 GiB

• 超過30個數據節點：8 核32 GiB

• 超過50個數據節點：16 核64 GiB

協調節點

使用獨立的協調節點，可以對最終的結果進行reduce操作，這樣即使reduce階段出現GC嚴重的現象，也不會影響數據節點。

如果開啟協調節點，建議協調節點與數據節點個數的比例為1:5（協調節點2個起購），協調節點建議選擇1:4或1:8規格族。例如，10個8核32 GiB的數據節點，建議配置2個8核32 GiB的協調節點。

評估Shard

Shard存儲量和數量是影響阿里云ES集群穩定性和性能的重要因素之一。ES集群中任何一個索引都需要進行合理的Shard規劃，防止因業務不明確導致分片龐大消耗ES本身性能，或導致負載不均衡，例如節點間磁盤使用率差距很大，節點CPU使用率呈現明顯的負載不均衡。

基于以上問題，下文對Shard規劃提供了一些建議。這些建議僅供參考，實際業務中還需根據需求進行調整：

• Shard存儲量

  • 建議單個Shard存儲量保持在30 GiB以內（最優），特殊情況下可以提升到50 GiB以內。

  • 對于日志分析或者超大索引場景，建議單個Shard存儲量不要超過100 GiB。

• Shard數量

  • 在分配Shard前，建議對ES進行數據測試。

    • 數據量很大時，需要減少寫入量的大小，降低ES壓力，建議選擇多主1副本。

    • 數據量較小，且寫入量也較小時，建議使用單主多副本或者單主1副本。

    說明

    • 7.x及以上版本實例默認一個索引創建1個主分片和1個副本分片。7.x以下版本實例默認一個索引創建5個主分片，并分別為每個主分片創建1個副本分片。

    • Shard存儲量低于30 GiB的業務，可以使用單主多副本的策略進行負載均衡。例如，20 GiB的單索引，分布在5個數據節點中，可以考慮單主4副本的Shard規劃。

  • 建議Shard個數（包括主分片和副本分片）盡可能等于數據節點數，或者是數據節點數的整數倍。

  • 建議單個節點上同一索引的Shard個數不要超過5個。

  • 建議按照以下說明，評估單個節點上全部索引的Shard數量。

    • 小規格實例參考：單個數據節點的Shard數量 = 當前節點的內存大小 * 30

    • 大規格實例參考：單個數據節點的Shard數量 = 當前節點的內存大小 * 50

    說明

    • 評估Shard數量時，還需結合數據量進行分析，建議TiB級別以下的數據量參考小規格實例進行評估。

    • 7.x版本ES實例默認的單節點Shard上限為1000個（官方不建議調整），您可以通過增加或擴容節點數量來調整單節點的Shard數量。

    • Shard個數不是越多越好。主分片越多ES性能開銷也會越大，shard數量太多極易引起文件句柄耗盡，導致集群故障。

關于評估Shard的更多信息，請參見How to size your shards。

相關文檔

• 了解不同地域和版本支持的節點規格或購買ES實例，請參見購買頁。

• 了解不同節點規格的性能，可以參考阿里云ES實例不同規格和版本的壓測實驗結果，請參見產品性能。

• 如果您對選擇實例類型（通用商業版、內核增強型）或實例版本有疑問，請參見版本特性。

• 對于已存在的集群，您可以根據評估結果調整節點規格、節點存儲空間、節點數量等。具體操作和限制，請參見升配集群和降配集群。

• 主分片的數量只能在創建索引時指定，并且創建索引后不能更改。創建索引，請參見創建索引。

• 對于已存在的索引，如果Shard超過推薦存儲量，建議通過reindex重建索引。具體操作，請參見阿里云ES間跨集群reindex。

  說明

  reindex能保證不停機，但是比較耗時。

• 集群負載不均問題的分析方法及解決方案。

• 通過手動遷移shard均勻分布熱點數據的解決方案。

• 如果開啟了自動創建索引功能，建議啟用索引生命周期管理，或者通過ES API腳本刪除過期的索引。

• 建議及時清理小索引，小索引同樣會占用ES堆內存。