Elasticsearch集群负载不均

概述

本文主要介绍Elasticsearch中集群负载不均的分析思路和解决方法。

详细信息

以下是集群负载不均的场景描述、问题原因、分析思路和解决方法。

场景描述

关于Elasticsearch中集群出现负载不均的情况,有以下两种问题场景:

  • 节点间磁盘使用率差距不大,监控中节点CPU使用率或load_1m参数呈现明显的负载不均衡现象。
  • 节点间磁盘使用率差距很大,监控中节点CPU使用率或load_1m参数呈现明显的负载不均衡现象。

说明:关于集群监控各指标说明,请参见集群监控指标说明

原因

可能存在的部分原因有以下几种:

  • Shard设置不合理。
    说明:大多数负载不均问题是由于shard设置不合理导致,建议优先排查。
  • Segment大小不均。
  • 存在典型的冷热数据需求场景。
    说明:例如查询中添加了routing或查询频率较高的热点数据,则必然导致数据出现负载不均。
  • 没有释放长连接,导致流量不均。
    说明:该问题时常暴露于采用负载均衡及多可用区架构部署时。

分析思路和解决方法

请根据不同问题原因,定位以下分析思路和解决方法。

Shard设置不合理

  1. 检查查询期间的网络及ECS实例情况,确认ECS环境正常。
  2. 调取网络监控,重点观察监控结果的异常时间段,结合查询策略,确认负载高的节点主要承担了查询请求。
  3. 请参见快速入门访问实例章节,登录Kibana控制台,在Console中执行以下命令,查看索引的shard信息,确认索引的shard在负载高的节点上呈现的数量较多,说明shard分配不均。
    GET _cat/shards?v
    说明:关于如何使用命令查看其他集群指标信息,请参见运维命令概览
  4. 查看磁盘使用率监控图,确认负载高的节点使用率比其他节点高。出现该情况说明shard分配不均衡导致存储不均。
    说明:在业务查询或写入中,存储高的节点承担主要的查询和写入。
  5. 登录Kibana控制台,在Console中执行以下命令,查看索引信息。结合集群配置,确认存在节点shard分配不均的现象。
    说明:Elasticsearch在检索过程中也会检索.del文件,然后过滤标记有.del的文档,这会降低检索效率,耗费规格资源,建议在业务低峰期进行强制合并操作,具体请参见force merge
    GET _cat/indices?v
  6. 查看主日志及searching慢日志,确认请求皆为普通的term查询,同时确认主日志状态正常,排除Elasticsearch集群本身的问题以及存在消耗CPU的查询语句的情况。
  7. 重新分配分片,合理规划shard,确保主shard数与副shard数之和是集群数据节点的整数倍。
    说明:在规划shard时,请参考更多信息

Segment大小不均

  1. 在查询body中添加"profile": true,检查test索引是否存在某个shard查询时间比其他shard长。
  2. 查询中分别指定preference=_primarypreference=_replica,在body中添加"profile": true,分别查看主副shard查询消耗的时间。检查较耗时的shard主要体现在主shard上还是副shard上。
  3. 登录Kibana控制台,在Console中执行以下命令,查看shard,并根据其中segment信息分析问题所在,确认负载不均与segment大小不均有关。
    GET _cat/segments/index?v&h=shard,segment,size,size.momery,ip
    GET _cat/shards?v
    说明:关于造成主副shard的doc数量不一致的原因,具体场景请参考更多信息
  4. 参考以下两种方法其中一种解决问题:
    • 在业务低峰期进行强制合并操作,具体请参见force merge,将缓存中的delete.doc彻底删除,将小segment合并成大segment。
    • 重启主shard所在节点,触发副shard升级为主shard。并且重新生成副shard,副shard复制新的主shard中的数据,保持主副shard的segment一致。

多可用区架构部署

在使用Elasticsearch集群跨区域容灾部署时,若某区域负载明显比其他区域高,则可能与长连接有关,请参考以下内容解决问题:

  1. 观察近4天所有区域节点的CPU监控,确认区域节点的CPU出现较大负载变动。
  2. 观察所有节点TCP连接数状态。若所有区域下连接数相差很大,判定与网络不均有关。
  3. 排查客户端的连接情况。客户端使用长连接,新建连接比较少,恰恰命中了多可用区网络独立调度的风险。Elasticsearch的协调节点对于请求的转发是同区域优先,即Elasticsearch将请求转到其他区域的可能性较小,于是导致了当前区域出现负载不均的问题。
    说明:网络服务是基于连接数独立调度的,每个调度单元会选择自己认为最优的节点进行创建,独立调度的性能会更高,但独立调度的风险是当新连接比较少的时候,有一定概率出现大部分调度单元都选择相同的节点去建立连接。
  4. 参考以下两种方法其中一种解决问题:
    • 使用单独的协调节点,通过工作职责划分来降低风险。使用协调节点转发复杂流量,即使负载高,也不会影响到后面的数据节点。
    • 配置2套独立的域名,分别在客户端配置这2个域名,从而使客户端侧尽量保证区域的流量均等。该方案存在一定的风险,即高可用性会有一定的损失,后续进行集群升配时,由于节点不会从SLB移除,因此可能会出现访问失败的问题。

更多信息

shard规划建议

Shard大小和数量是影响Elasticsearch集群稳定性和性能的重要因素之一。Elasticsearch集群中任何一个索引都需要有一个合理的shard规划。合理的shard规划能够防止因业务不明确,导致分片庞大消耗Elasticsearch本身性能的问题。以下是shard规划时的几个建议:
说明:Elasticsearch 7.x以下版本的索引默认包含5个主shard,1个副shard。Elasticsearch 7.x及以上版本的索引默认包含1个主shard,1个副shard。
  • 建议在小规格节点下,单个shard大小不要超过30GB。对于更高规格的节点,单个shard大小不要超过50GB。
  • 对于日志分析或者超大索引场景,建议单个shard大小不要超过100GB。
  • 建议shard的个数(包括副本)要尽可能等于数据节点数,或者是数据节点数的整数倍。
    说明:主分片不是越多越好,因为主分片越多,Elasticsearch性能开销也会越大。
  • 建议单节点shard总数按照单节点内存*30进行评估,如果shard数量太多,极易引起文件句柄耗尽,导致集群故障。
  • 建议单个节点上同一索引的shard个数不要超5个。

主副shard的doc数量不一致的原因

造成主副shard的doc数量不一致的原因有很多,例如以下两种情况:

  • 如果一直有doc写入shard,由于主副数据同步有一定延迟,会导致数据不一致。但一般停止写入后,主副doc数量是一致的。
  • 如果使用自动生成docid的方式写入doc,由于主shard写入完成后会转发请求到副shard,因此在此期间,如果执行了删除操作,例如并行发送Delete by Query请求删除了主分片上刚写完的doc,那么副shard也会执行此删除请求;然后主shard又转发写入请求到副shard上,对于自动生成的id,doc将直接写入副shard,不进行检查,最终导致主副shard的doc数量不一致,同时在doc.delete中也可以看到主shard中存在大量的删除文档。

适用于

  • Elasticsearch