如何优雅的控制ES集群上的大索引?

前言|

实际生产工作中，我们经常会遇到集群日志索引特别大、日志分片特别多、近而导致集群数据索引、检索经常出现问题，比如：写入数据出现拒绝、查询超时、甚至出现分片丢失等情况，那么今天我们就以一个实际列子来讲讲这类问题的处理过程：

一、企业实际日志环境介绍

1，通过celebro截图查看索引大小，截图如下：

用户日志celebro截图

2，截图情况分析：

<1>这是日志收集的环境，索引属于时间序列，每个索引270主分片，索引大小从17T-27T左右不等;

<2>日志环境的索引分片应按照每个分片30G的大小进行分片，而我们发现这个环境中的分片有的达到来100G甚至200G的大小,索引的分片太大导致集群管理出现来问题；

<3> 集群读写出现reject现象，集群经常出现分片丢失的情况。符合文章开始提到的问题预期。

3，索引分片总结

ES的索引本身没有大小限制一说，索引与分片的大小有关，索引分片的数量与ES集群的硬件配置有关。每个分片的数量根据业务场景来分，日志场景按照40G/分片，搜索场景按照20G/分片来定。而每个节点分片的数量我们一般按照1：20比列来定，也就是1G的堆内存对应20个主分片的设定，比如我这个节点是32G的堆内存，那么这个节点所能承担的最大的分片应该是32*20个分片。

二、那么如何有效管理企业生产环境中的大的索引呢？

在ES早期版本中，比如ES5我们可以通过Curator+Rollover实现大索引的自动化创建、管理，在ES6.6以后版本中提供了一个叫ilm<索引生命周期>功能，它可以结合rollover实现企业生产环境中大索引的自动滚动更新生成新索引的方式，这样就解决了单个索引过大造成的各种集群管理问题，本节我们将使用ILM+rollover实现大索引的滚动更新;

1,Rollover 与 时间序列的索引的实际场景

Rollover自动滚动更新索引

2，Rollover API 特点

<1> 当满足一系列的条件，Rollover API支持将一个 alias指向一个新的索引，它具有以下3个条件

A：存活的时间

B： 最大文档数

C： 最大文件尺寸

<2> 应用场景：当一个索引数据量过大

3，索引生命周期管理策略 Index Lifecle Management Policies

索引生命周期管理策略除了有冷热场景得使用外，在索引管理方面也有着非常大的实际应用。其支持基于大小和时间周期滚动，还支持定期删除，不用像老版本那样需要用户自己定义任务计划，非常好用。那么我们今天就以这个方法来解决这类大型索引的管理问题：那么我首先看一下大致的数据流程吧：

数据流向+索引生命周期策略流程图

通过上图我们可以确定执行这个过程只需要3步：

第一步：创建索引生命周期策略，这个策略是基于rollover进行设置，

第二步：创建模板，匹配特定的索引并指定别名

第三步： logstash Output设置ILM;

三、实战演示解决生产集群大索引的管理难题

鉴于企业ES生产环境索引数据比较大，我们可以设置当集群索引达到800G的时候滚动更新到下一个索引，按照上面的三步走策略：

第一步：创建ilm 策略：

创建ILM策略

第二步：定义模板，设置如下：

创建ES模板

第三步：修改Logstash的输出设置，在output中添加如下参数：

output设置

logstash配置

只需要以上3步这么设置，就可以实现从Logstash写入文件到index alias别名，然后索引根据策略自动按照规则滚动到下一个索引中。这里要注意：Rollover是针对索引别名进行管理的，通过对别名的写入管理自动滚动更新索引，做到了索引自动切换的作用。有效规避了大索引带来的管理问题，这样就保证了集群节点分片数据量的均匀分布。

在实际生产测试中，要注意模板索引别名跟Logstash Output配置别名的一致性。当然，可以在前期测试阶段使用手动滚动更新测试无误后再上生产环境。这里就不一一介绍。ES官网有详细的各个组建的文档介绍。

大致的流向就是这样，通过别名的形式实现数据索引的动态切换，如下图：

数据流向分析

四、总结

那么本节我们从一个实际生产环境的列子引出本节的重点，如何通过rollover+ilm的形式实现大型索引的规范化管理，保证ES集群的健壮稳定，此方法经过多套生产环境验证测试，测试无误，实为经验贴，希望能对有类似问题的朋友提供参考建议。因为本节并不属于基础知识的讲解。大家可以自行去ELasticsearch官方补齐相关知识。

通过本文你要了解：

1，ilm是ES6.6以后推出的新功能，可以在多种场景下使用。与冷热无关；

2，Rollover是对别名进行管理，与具体索引无关;

3, logstash本身CPU占用比较严重，这个现象可以值得关注、后续优化;

4,多种API的结合能有效管理集群中的大索引;