文档

规格容量评估

在购买或升缩配阿里云Elasticsearch集群前,您可以根据本文提供的相对通用的评估方法,初步评估集群所需资源的规格容量,包括节点规格、节点存储空间和节点数量。创建索引前或遇到节点间磁盘使用率差距很大、节点CPU使用率呈现明显的负载不均衡等现象时,评估索引的shard存储量和数量。

注意事项

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

评估集群存储空间

影响ES集群存储空间大小的因素主要包括:

  • 源数据的大小。

  • 索引的副本数量:每个索引至少需要1个副本。

  • 索引开销:通常比源数据大10%,默认不开启_all参数的索引。

    例如,存储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
说明

以上计算以副本数量为1为例,如果调整副本数量,请重新计算。

开启_all参数的索引后,索引存储空间的开销也会随之增大。根据测试结果和使用经验,建议将集群存储空间增加至原来的1.5倍,即:

节点存储空间总大小 = 源数据 *(1 + 副本数量)* 1.7 *1.5
                 = 源数据 *(1 + 副本数量)* 2.55
说明

如果不需要在业务上使用_all参数,通常建议您禁止或者有选择性地添加_all参数。

评估节点规格和节点数量

  • 最大节点数量 = 单节点CPU大小 * 5。

  • 业务场景不同,单节点最大承载数据量也不同:

    • 通用场景:单节点最大存储空间 = 单节点内存大小(GiB)* 30。

    • 搜索场景(数据库加速、查询聚合等):单节点最大存储空间 = 单节点内存大小(GiB)* 10。

    • 日志分析场景(日志写入、离线分析等):单节点最大存储空间 = 单节点内存大小(GiB)* 50。

根据以上计算方式,得到部分节点规格的最大节点数量和单节点最大存储空间。

节点规格

最大节点数量

单节点最大存储空间

通用场景

搜索场景

日志分析场景

2核4 GiB

10

120 GiB

40 GiB

200 GiB

2核8 GiB

10

240 GiB

80 GiB

400 GiB

4核16 GiB

20

480 GiB

160 GiB

800 GiB

8核32 GiB

40

960 GiB

320 GiB

1.5 TiB

16核64 GiB

80

1.9 TiB

640 GiB

3 TiB

集群存储空间=单节点存储空间*节点数量,您可以根据单节点最大存储空间和最大节点数量选择满足业务要求的节点规格。

  • 聚合查询(Agg查询)场景数据节点规格建议选择1:2规格族,并开启协调节点。

  • 如果开启协调节点,建议协调节点与数据节点个数的比例为1:5(协调节点2个起购),协调节点建议选择1:4或1:8规格族。例如,10个8核32 GiB的数据节点,建议配置2个8核32 GiB的协调节点。

说明
  • 使用独立的协调节点,可以对最终的结果进行reduce操作,这样即使reduce阶段出现GC严重的现象,也不会影响数据节点。

  • 数据节点数量会影响Shard总数量,在确定实例规格前您还需要评估索引的Shard。

评估Shard

Shard存储量和数量是影响阿里云ES集群稳定性和性能的重要因素之一。ES集群中任何一个索引都需要进行合理的Shard规划,防止因业务不明确导致分片庞大消耗ES本身性能,或导致负载不均衡,例如节点间磁盘使用率差距很大,节点CPU使用率呈现明显的负载不均衡。

说明

Shard是索引在ES中的分布式存储单元,包括主分片和副本分片。详细信息,请参见分片和副本

在进行Shard规划前,需要先考虑以下几个问题:

  • 当前单个索引的数据多大?

  • 数据是否会持续增长?

  • 购买的实例规格多大?

  • 是否会定期删除索引或合并临时索引?

基于以上问题,下文对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 API脚本删除过期的索引。

  • 建议及时清理小索引,小索引同样会占用ES堆内存。

  • 本页导读 (1)
文档反馈