Elastic Searchable snapshot功能初探

我在之前的博文《Elasticsearch引入可搜索快照（searchable snapshot）》中介绍过Searchable snapshot这个功能，简单来说，通过这个功能，我们能够解锁对象存储简单用作快照备份的功能，实现：

• 大幅降低存储成本
• 在Elastic Stack中摄取和保留更多数据
• 开启新的可能性和用例

当然，这里没有银弹，我们要做的是提供更多的方式，以帮助用户更有效地平衡性能、成本和数据留存之间的关系。

可搜索快照roadmap

可搜索快照这个功能在最新的7.11版本中已经GA（General Available）了，即代表着这个功能经历的beta版本的广泛使用和测试之后，目前官方已经推荐大家在生产环境上使用了。

和可搜索快照一起GA的是Cold Tier，这个新的分层架构，目前，在Cold Tier中可搜索快照的主要功能是：通过将数据的冗余副本搬移到低成本的对象存储中，可以降低您的存储成本高达50%，以此提高只读数据的本地存储密度。

而在未来的两个版本中（7.12以及7.13，预计会在三月下旬和5月下旬发布），我们将提供Frozen层，将对象存储的使用更进一步，远期数据将完全存储在低成本对象存储中，同时保持数据的完全可搜索性，并通过本地缓存对经常访问的数据进行快速查询。这个新功能将使您在Elastic中管理不断增长的数据量变得更加简单和便宜，使您能够以更高成本效益的方式满足您的数据保留要求，同时开辟新的用例，例如让您的团队能够在安全调查进行无限回溯，又或者是针对黑色星期五做跨年度的销售数据比较。

在今天这个博文中，我们将通过一个简答的操作，带大家了解7.11中GA的这个冷层和可搜索快照的功能。

可搜索快照演示

在Elastic cloud上创建集群

要尝试可搜索快照，我们首先要有一个对象存储的快照仓库，最快的方式是我们通过Elastic cloud提供的14天trial来进行体验，在Elastic cloud上，我们默认为每个集群都创建了基于S3的快照存储仓库，并且已经挂载到集群当中，可以参见博文 Elastic：在Elastic云上3分钟部署Elastic集群 开启您的探索之旅。

而在我们发布最新的7.11版本同时，Elastic Cloud也同步更新，我们可以看到Elastic Cloud也增加了新的冷层创建滑块：

在这里插入图片描述

通过这个新的cold data tier，我们直接可以拥有新的、标记为了冷层的节点，不需要自己手动去标记，并且ILM等工具会自动识别这个新的节点，在我们做数据的生命周期管理的时候，自动的根据策略往对应的数据层搬移数据，极大的简化了数据治理工作。

这里需要注意的是，在Elastic推出这个新的数据层时，我们之前用于标记节点的方式也稍有变化。（之前我们是通过类似机架感知的方式，通过标签来标记节点的，现在是通过elasticsearch.yml文件中的node_roles进行标记，具体可以查看文档）

在这里插入图片描述

在创建出来的集群中，我们会默认拥有一个快照仓库（AWS是S3，GCP是Google Cloud Storage，Azure是Blob Storage），可以直接在kibana中看到：

在这里插入图片描述

接下来，我们将通过这个found-snapshots仓库来进行可搜索快照的演示。

创建索引生命周期管理策略

我们可以调用通过API的方式去进行可搜索快照的管理，但通过ILM（索引生命周期管理）工具去确定索引是否使用可搜索快照是最方便的。

在最新的7.11版本中，我们也看到了一些新的变化，这些变化也是基于beta版本中大量的用户反馈而做出的。在我们之前的介绍中，可搜索快照和冷层概念是一起出现的，因为只有只读数据才可以通过可搜索快照的方式来提供故障自动恢复和搜索功能，通过可搜索快照，我们通过将数据的冗余副本搬移到低成本的对象存储中，可以节省冷层存储成本高达50%。但大多数客户不满足只在冷层中实现类似的提升，他们希望在热层、温层也有类似的提升（对于一些搜索并发量不大的运维监控、安全分析场景，这是非常重要的需求，用户的诉求是可以接受损失特定情况下的性能——故障恢复的性能，以换来存储成本的大幅下降）。

因此，在7.11版本的ILM中的，我们为Hot phase添加了searchable snapshot的配置：

在这里插入图片描述

这里需要注意几点：

• 仍然是只有只读索引才可以开启可搜索快照功能，即必须启动Rollover功能滚动切分索引之后，切分出来的索引变为只读索引之后才会开启可搜索快照功能
• 如果开启可搜索快照功能，为了保证本地存储和对象存储中索引数据的一致，这个只读索引将不能再进行force merge, shrink, freeze等操作
• 该索引在索引生命周期流转的过程中（hot phase -> warm phase -> cold phase），都一直是支持可搜索快照，因此，一旦在hot phase中启动了searchable snapshot，cold phase中的searchable snapshot滑块将自动disable
  

  在这里插入图片描述

但为了让我们的演示更加简单。我将在ILM中创建一个cold phase的searchable snapshot的索引生命周期管理策略。

在这里插入图片描述

其类似如下API配置：

PUT _ilm/policy/kibana_sample_data_logs
{
  "policy": {
    "phases": {
      "cold": {
        "min_age": "30d",
        "actions": {
          "searchable_snapshot" :{
            "snapshot_repository": "found-snapshot"
          }
        }
      }
    }
  }
}

创建索引模板

接下来，我们将创建索引模板，通过索引模板，让索引对接我们之前创建的生命周期管理策略

PUT _template/kibana_sample_data_logs
{
  "index_patterns": ["kibana_sample_data_logs"],
  "settings": {
    "index.lifecycle.name": "kibana_sample_data_logs"
  }
}

到目前为止，我们创建了一个生命周期管理策略，名为kibana_sample_data_logs；一个索引模板，也名为

kibana_sample_data_logs，在这个模板中，我们匹配名为kibana_sample_data_logs的索引，让其对接我们的生命周期管理策略，该策略会让索引在rollover 30天之后，搬移到冷层，并启动searchable snapshot功能

写入数据

添加Elastic自带的样本数据

在这里插入图片描述

可以先查看该数据集的情况，一主一副本，14074个文档，占用20mb的存储空间：

在这里插入图片描述

触发生命周期管理的action

我们在策略中定义的触发条件是"min_age": "30d"，即需要让这个索引的age超过30天才可触发对应的动作（启动可搜索快照）。

这里有一个小tips，我们可以通过修改索引settings的方式来提前触发这个动作：

在这里插入图片描述

• 界面上点击该索引
• 在弹出的窗口中选择Edit settings
• 添加index.lifecycle.origination_date, 将时间戳改为30天之前（可通过https://www.epochconverter.com/获取当前的epoch time）
• 保存
• roload一下索引状态

我们将看到如下变化：

在这里插入图片描述

• 索引名变为restored-kibana_sample_data_logs
• 自动添加了alias，kibana_sample_data_logs
  

  在这里插入图片描述
• 索引变为一主零副本，仍然14074个文档，但占用的存储空间由20mb变为了8.2mb。

总结

通过以上演示，我们发现，通过配合新的node_roles，我们可以快速将节点标记为冷层（cold tier），在ILM中，这个新的冷层，会自动成为cold phase搬移数据的目的节点。而通过ILM，我们可以快速的通过策略指定索引该什么时候打开可搜索快照功能，并自动帮我们完成对接快照，配置别名的动作。而可搜索快照可以在hot phase就打开，在整个数据生命周期中为我们节省成本。

通过这个演示，我们也能发现，这些新的功能是非常容易上手的，不需要复杂的配置，只需要几次简单的点击，即可在界面上完成所有的配置。

目前这个功能已经GA，所以大家赶紧来开启您的探索之旅吧~