规格容量评估

注意事项

本文根据实际测试结果和用户使用经验提供评估方法。由于不同用户在数据结构、查询复杂度、数据量大小、性能及数据变化等方面的需求不同，本文的评估不一定适用于所有用户。建议您在条件允许的情况下，通过实际的数据和使用场景测试出适合自己的集群规格容量规划。

评估集群存储空间

影响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堆内存。