ES 索引的生命周期管理

简介

ES最早在6.8版本在X-pack套件中引入了索引生命周期管理功能。在此之前，索引的生命周期管理往往是利用定时任务加脚本，或者是第三方方案进行实时的。

与其他方案相比，x-pack的索引生命周期管理（ILM）模块具有支持功能全面（支持索引的创建，关闭，删除，更新配置，aliased-rotate等功能）在不需要其他工具支持下具备定时任务，高可用和跨集群管理等能力，并且支持全部ES版本的索引。此外，在使用kibana的情况下，拥有图形化的管理界面。

最重要的一点是，该方案是包含在免费的x-pack基本授权内的。

制定ILM规则

用户可以使用Kibana的图形界面，或者使用ES的ILM API定义多套规则。

PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_size": "25GB" 
          }
        }
      },
      "delete": {
        "min_age": "30d",
        "actions": {
          "delete": {} 
        }
      }
    }
  }
}

上面这段来自ES官方网站的文档，使用了PUTAPI定义了一条ILM规则，这个规则中定义了2个阶段：hot和delete：

在hot阶段，会在索引大小达到25GB时对索引做rollover操作。
当索引的存在时间达到30天时，索引进入delete阶段，在此阶段，索引会被删除。

在ILM规则被指定后，需要将ILM规则和索引模板相关联：

PUT _template/my_template
{
  "index_patterns": ["test-*"], 
  "settings": {
    "number_of_shards": 1,
    "number_of_replicas": 1,
    "index.lifecycle.name": "my_policy", 
    "index.lifecycle.allocation.require.box_type": "hot",
    "index.lifecycle.rollover_alias": "test-alias"
  }
}

如上：

该模板适用于所有前缀为"test-"的索引。
使用index.lifecycle.name设置规则名称为"my_policy"。
设置该索引需要分配在拥有box_type为hot的节点上。
使用index.lifecycle.rollover_alias设置进行rollover的索引别名为"test-alias"。

在设置完成后，创建一个索引开始生命周期管理。

PUT test-000001
{
  "aliases": {
    "test-alias":{
      "is_write_index": true 
    }
  }
}

需要注意的是，在创建这个索引时，我们将这个索引的alias设成了"test-alias"，并将其写入属性"is_write_index"置为true。

ILM的4个阶段

image-20200309205748714.png

如图所示，ILM拥有4个阶段：

Hot：索引写入和查询阶段。

Warm：索引不再被写入，但是会被查询阶段。

Cold：索引不再被写入，并且查询量也很少的阶段。

Delete：索引生命周期的完结，可以被从磁盘删除。

其中，Hot阶段是设置ILM规则必备的，而其他几个阶段属于可选。在规则的设置中，每个阶段都有一个"min_age"来控制每个阶段的进入时间点，如果不做设置，这个值默认为0ms。

ILM规则检测周期由集群的配置indices.lifecycle.poll_interval进行设置，默认值是10分钟。设置方法：

PUT _cluster/settings
{
  "persistent": {
    "indices.lifecycle.poll_interval":"10s"
  }
}

这里将检测周期设置成了10秒钟。

几个重要的操作

ES的运行对内存和硬盘IO的较为敏感，而内存及SSD也往往是成本较高的硬件部件。在实际运维中，可以通过给节点打上hot，warm等标签来进行冷热节点设置。为hot节点提供较高的内存配置并配备SSD，而在warm节点用大容量的机械硬盘用来存储大量不常使用的数据。在数据的生命周期结束时，删除索引以节省硬盘空间。

ILM在这几个阶段提供了一些操作，来完成索引生命阶段的重要行为。

rollover：在hot阶段防止单个索引体积过大，文档数量过高，或者写入事件过长。

allocate：在warm或者cold阶段，将索引转移到cold节点上，并更改其备份数。

shrink: 在warm阶段对分片进行合并，减少体积。

delete：在delete阶段，即索引的生命终点将其删除。

本文只讨论单个集群中的行为。

rollover

ES的索引API提供了rollover功能，而ILM的Hot阶段中的rollover操作的功能与之完全一致。由于索引的API只能由外部程序主动触发，需要另外编写定时任务或者脚本执行，因此ILM中的rollover操作在使用方面更加便利。

PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover" : {
            "max_age": "7d",
            "max_size": "100GB"
          }
        }
      }
    }
  }
}

Rollover Action拥有3个可选参数：

max_size：索引的最大容量

max_docs：索引中包含的最大文档数

max_age：索引存在时间

配置Rollover 操作时，需要设置上面三个参数中的一个或多个。

allocate

allocate操作允许ILM在索引进入Warm或者Cold阶段时，指定其节点以及备份个数。

number_of_replicas: 指定索引备份个数。

require: 分配的节点必须包含的属性标签。

exclude: 分配的节点不能拥有的属性标签。

include: 分配的节点需要拥有include指定的属性标签之一。

这4个属性必须指定一个，否则规则设置会失败。

PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "warm": {
        "actions": {
          "allocate" : {
            "number_of_replicas": 1,
            "require" : {
              "box_type": "cold"
            }
        }
        }
      }
    }
  }
}

上述操作，将索引的备份数设为1，并且将其分配到cold节点上。

Shrink

Shrink操作能够减少索引的分片数，与索引操作的同名操作一样，源索引的分片数需要是目标索引的分片数的整数倍，比如说，在Hot阶段，索引有6个分片，那么在Warm阶段，只能指定将其缩减为3，2或者1个分片。同时，目标节点需要拥有足够的磁盘空间。缩减后的索引的单个分片要满足单个索引分片数的文档数限制。

number_of_shards:指定分片数，该属性必须被设置。

在该操作被运行时，该索引会被设为read-only。

example:

PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "warm": {
        "actions": {
          "shrink" : {
            "number_of_shards": 1
          }
        }
      }
    }
  }
}

Delete

在索引生命的终点将其删除，只能在Delete阶段被执行。该操作没有额外的参数。

example：

PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "delete": {
        "actions": {
          "delete" : { }
        }
      }
    }
  }
}

启动/关闭以及检查ILM的状态

ILM的提供了API对其状态进行检查：

检查状态

GET _ilm/status

ILM会拥有三个状态：running,stopping,stopped。

其中stopping表明ILM已经接收到了停止的指令，但还有一些请求未执行完成。

关闭ILM的API：

POST _ilm/stop

启动ILM的API：

POST _ilm/start

小结

ES x-pack的生命周期管理功能提供了一种优雅的方式对集群的索引进行管理，并且完美地适配了冷热节点的设置，在将来一定会逐渐取代当前的索引管理方式。

本文样例均来自ElasticSearch官方文档：https://www.elastic.co/guide/en/elasticsearch/reference/7.1/index-lifecycle-management.html
有少量改动。