Elasticsearch 5.x 版本中的冷热数据架构

最新推荐文章于 2024-08-06 11:43:58 发布

安正勋

最新推荐文章于 2024-08-06 11:43:58 发布

阅读量2.3k

点赞数 2

文章标签： Elasticsearch 5.x 冷热数据架构 hot-warm

译文那些事儿专栏收录该内容

51 篇文章 3 订阅

订阅专栏

文章目录

主节点
热节点
冷节点

当使用 Elasticsearch 进行更大的时间数据分析用例时，我们建议使用基于时间（time-based）的索引和具有 3 种不同类型节点（主节点、热节点和冷节点）的分层架构，我们称之为Hot-Warm架构。每个节点都有自己的特性，如下所述。

主节点

我们建议每个集群运行 3 个专用的主节点（master nodes），以提供最大的弹性。使用这些功能时，还应将discovery.zen.minimum_master_nodes设置为2，以防止出现“脑裂”的情况。利用专用的主节点，只负责处理集群管理和状态，增强了整体稳定性。因为它们不包含数据，也不参与搜索和索引操作，所以它们对 JVM 的要求与在大量索引或长时间、昂贵的搜索中可能出现的要求不同。因此，不太可能受到长时间垃圾收集暂停的影响。因此，可以为它们提供比数据节点所需配置低得多的 CPU、RAM 和磁盘配置。

热节点

这个专门的数据节点执行集群中的所有索引。它们还持有最新的索引，因为这些索引通常最常被查询的。由于索引是一种 CPU 和 IO 密集型操作，因此这些服务器需要强大的功能并由连接的 SSD 存储进行支持。我们建议至少运行 3 个热节点（hot node）以实现高可用性。不过，根据你希望收集和查询的最新数据量，你很可能需要增加这个数字以实现性能目标。

冷节点

这种类型的数据节点被设计用来处理大量的只读索引，这些索引不太可能被频繁查询。由于这些索引是只读的，所以冷节点（warm node，译者注：冷热节点是相对的概念）倾向于使用大型附加磁盘（通常是旋转磁盘）而不是 SSD。与热节点一样，我们建议至少 3 个冷节点以实现高可用性。和以前一样，需要注意的是，大量的数据可能需要额外的节点来满足性能要求。还要注意，CPU 和内存配置通常需要镜像那些热节点。这只能通过使用类似于在生产环境中体验的查询进行测试来确定。

Elasticsearch 集群需要知道哪些服务器包含热节点，哪些服务器包含冷节点。这可以通过为每个服务器分配任意「属性」来实现。

例如，可以在elasticsearch.yml中使用node.attr.box_type: hot标记热节点，或者使用./bin/elasticsearch -Enode.attr.box_type=hot启动热节点。

类似的，冷节点也需要在elasticsearch.yml中使用node.attr.box_type: warm进行标记，或者使用./bin/elasticsearch -Enode.attr.box_type=warm启动冷节点。

box_type属性是完全任意的，你可以随意命名它（译者注，正如hot和warm仅是概念上的名称而已，我们完全可以用black和white来代替）。这些任意值将用于告诉 Elasticsearch 在何处分配索引。

我们可以通过使用以下设置创建热节点，从而确保今天的索引位于使用 SSD 的热节点上：

PUT /logs_2016-12-26
{
  "settings": {
    "index.routing.allocation.require.box_type": "hot"
  }
}

几天后，如果索引不再需要在性能最高的硬件上运行，我们可以通过更新其索引设置将其移动到标记为warm的节点上：

PUT /logs_2016-12-26/_settings 
{ 
  "settings": { 
    "index.routing.allocation.require.box_type": "warm"
  } 
}

现在，我们如何使用logstash或beats来实现这一点：

如果在logstash或beats级别管理索引模板（index template），则应更新索引模板以包括分配筛选。"index.routing.allocation.require.box_type" : "hot"设置将导致在热节点上创建任何新索引。例如，

{
  "template" : "indexname-*",
  "version" : 50001,
  "settings" : {
             "index.routing.allocation.require.box_type": "hot"
 ...

另一种策略是为集群中的任何索引添加一个通用模板，"template": "*"，它在热节点中创建新的索引。例如，

{
  "template" : "*",
  "version" : 50001,
  "settings" : {
           "index.routing.allocation.require.box_type": "hot"
 ...

当你确定一个索引没有被写入，也没有被频繁搜索时，它可以从热节点迁移到冷节点。这可以通过更新其索引设置来完成："index.routing.allocation.require.box_type" : "warm"。Elasticsearch 将自动将索引迁移到冷节点。

最后，通过在elasticsearch.yml中设置index.codec: best_compression，我们还可以在所有冷数据节点上实现更好的压缩。当数据移动到冷节点时，我们可以调用_forcemerge API 来合并段：它不仅通过具有较少的段来节省内存、磁盘空间和文件句柄，而且还具有使用这种新的最佳压缩（best_compression）编解码器重写索引的能力。

在索引仍被分配给大盒子（strong boxes）的时候，强制合并索引是一个坏主意，因为优化过程将淹没这些节点上的 I/O，并影响当前日志的索引速度。但是中等大小的盒子（medium boxes）做的不多，所以强制合并它们是安全的。

既然我们已经了解了如何手动更改索引的分片分配，那么让我们来看看如何使用我们的一个叫做「Curator」的工具来自动化这个过程。

在下面的示例中，我们使用 Curator 4.2 在 3 天后将索引从热节点移动到冷节点：

actions:
  1:
    action: allocation
    description: "Apply shard allocation filtering rules to the specified indices"
    options:
      key: box_type
      value: warm
      allocation_type: require
      wait_for_completion: true
      timeout_override:
      continue_if_exception: false
      disable_action: false
    filters:
    - filtertype: pattern
      kind: prefix
      value: logstash-
    - filtertype: age
      source: name
      direction: older
      timestring: '%Y.%m.%d'
      unit: days
      unit_count: 3

最后，我们可以使用 Curator 强制合并索引。在运行优化之前，请确保等待足够长的时间以完成重新分配。你可以通过在操作1中设置wait-for-completion或更改unit_count来选择操作2中大于4天的索引，这样它们就有机会在索引强制合并之前完全迁移。

 2:
    action: forcemerge
    description: "Perform a forceMerge on selected indices to 'max_num_segments' per shard"
    options:
      max_num_segments: 1
      delay:
      timeout_override: 21600 
      continue_if_exception: false
      disable_action: false
    filters:
    - filtertype: pattern
      kind: prefix
      value: logstash-
    - filtertype: age
      source: name
      direction: older
      timestring: '%Y.%m.%d'
      unit: days
      unit_count: 3