[译] Elasticsearch 5.x 版本中的冷热节点架构

标签: dev | 发表时间:2017-11-20 08:00 | 作者:
出处:http://itindex.net/relian

原文链接

Elasticsearch 5.x 版本中的冷热节点架构

当elasticsearch用于大量实时数据分析的场景时,我们推荐使用基于时间的索引然后使用三种不同类型的节点(Master, Hot-Node 和 Warm-Node)进行结构分层,这就是所谓的"Hot-Warm"架构。每种节点有自己的任务,下面会进行介绍。

Master 节点

我们推荐每个集群运行三个专用的master节点来提供最好的弹性。使用时,你还得把 discovery.zen.minimum_master_nodes setting 设置为2,以免出现脑裂的情况。使用三个专用的master节点,专门负责处理集群的管理以及加强状态的整体稳定性。因为这三个master节点不包含数据也不会实际参与搜索以及索引操作,在JVM上它们不用做相同的事,例如处于繁重的索引或者耗时,资源耗费很大的搜索中。因此不太可能会因为垃圾回收而导致停顿。因此,我们可以配置比data节点少很多的CPU,内存以及磁盘。

Hot 节点

指定的data节点会完成集群内所有的索引工作。这些节点同时还会保存近期的一些频繁被查询的索引。由于进行索引非常耗费CPU和IO,因此这些服务器需要强大的SSD存储来支撑。我们推荐部署最小化的三个Hot节点来保证高可用性。根据近期需要收集以及查询的数据量,可以增加服务器数量来获得想要的性能。

Warm 节点

这种类型的节点是为了处理大量的而且不经常访问的只读索引而设计的。由于这些索引是只读的,warm 节点倾向于挂载大量磁盘(普通磁盘)来替代SSD。跟hot节点一样,我们建议部署最小化的三个warn节点来保证高可用性。然后跟之前一样地,数据量大的话还是需要额外的节点来达到性能要求。而且还需注意的是CPU和内存配置跟hot节点保持一致。通过测试一些类似生产环境中耗费比较大的查询可以确认这些东西。

Elasticsearch集群需要知道哪些服务器有hot节点以及哪些服务器有warm节点。这个可以通过分配所需的 属性给服务器来实现。

例如,你可以在 elasticsearch.yml 这个配置文件中通过 node.attr.box_type: hot 把节点设置为hot,或者你也可以在启动节点时使用 ./bin/elasticsearch -Enode.attr.box_type=hot 参数指定。

box_type 这个属性字段你完全可以自定义成你要的。这些自定义的值用于告知 Elasticsearch 从哪里分配索引。

通过以下配置创建索引,我们可以确保今天的索引落在使用SSD的ho节点上:

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.routing.allocation.require.box_type" : "hot" 这个配置会使新的索引创建在hot节点上。
例如:

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

另外一个策略是给集群中的所有索引添加一个普通模板,在hot节点上 "template": "*" 模板可以生成新的索引。
例如:

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

当你确认一个所以不再承担写入以及不需要频繁搜索时,它可以从hot节点中合并到warm节点。这个可以通过更新它的索引配置:"index.routing.allocation.require.box_type" : "warm" 轻而易举地完成这个操作。
Elasticsearch 会自动合并索引到warm节点。

最后,我们还可以在所有warm数据节点上开启更好的压缩配置,在elasticsearch.yml配置文件中的 index.codec: best_compression 的这个配置项可以配置。
当数据移动到warm节点后,我们可以调用 _forcemerge API 来合并分段: 虽然可以节约内存, 磁盘空间以及更少的文件句柄, 也有使用新的best_compression编码进行索引重写所带来的副作用.

当还需要分配到strong boxes时强制合并索引不是什么好办法,这些节点上的进程会优先进行I/O操作然后影响到正在进行索引的当天日志。但是medium boxes则不会有太多操作,所以这是安全的。
现在我们已经看到如何手动修改索引的分片分配,接下来让我们来看下如何使用 Curator这个工具来自动处理这些事情。

下面的例子中我们使用curator 4.2从hot节点移动三天前的索引到warm节点:

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:truetimeout_override:continue_if_exception:falsedisable_action:falsefilters:-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,或者修改操作2中的 unit_count 来选择4天前的索引.这样就有机会在强制合并之前完全合并。

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

注意 timeout_override 要比默认值 21600 秒大,不过它可能会更快或者慢一点,这取决于你的配置。

从Elasticsearch 5.0开始我们还可以使用 Rollover 和 shrink api 来减少分片数量,可以以更简单高效的方式来管理基于时间的索引。你可以在这个 博客中找到更多细节。

相关 [elasticsearch 版本 节点] 推荐:

[译] Elasticsearch 5.x 版本中的冷热节点架构

- - IT瘾-dev
Elasticsearch 5.x 版本中的冷热节点架构. 当elasticsearch用于大量实时数据分析的场景时,我们推荐使用基于时间的索引然后使用三种不同类型的节点(Master, Hot-Node 和 Warm-Node)进行结构分层,这就是所谓的"Hot-Warm"架构. 每种节点有自己的任务,下面会进行介绍.

ElasticSearch 2 的节点调优(ElasticSearch性能)

- - 行业应用 - ITeye博客
一个ElasticSearch集群需要多少个节点很难用一种明确的方式回答,但是,我们可以将问题细化成一下几个,以便帮助我们更好的了解,如何去设计ElasticSearch节点的数目:. 打算建立多少索引,支持多少应用. elasticsearch版本: elasticsearch-2.x. 需要回答的问题远不止以上这些,但是第五个问题往往是容易被我们忽视的,因为单个ElasticSearch集群有能力支持多索引,也就能支持多个不同应用的使用.

elasticsearch如何安全重启节点

- - 开源软件 - ITeye博客
elasticsearch集群,有时候可能需要修改配置,增加硬盘,扩展内存等操作,需要对节点进行维护升级. 但是业务不能停,如果直接kill掉节 点,可能导致数据丢失. 而且集群会认为该节点挂掉了,就开始转移数据,当重启之后,它又会恢复数据,如果你当前的数据量已经很大了,这是很耗费机器和网络 资源的.

[译]elasticsearch mapping

- - an74520的专栏
es的mapping设置很关键,mapping设置不到位可能导致索引重建. 请看下面各个类型介绍^_^. 每一个JSON字段可以被映射到一个特定的核心类型. JSON本身已经为我们提供了一些输入,支持 string,  integer/ long,  float/ double,  boolean, and  null..

Elasticsearch as Database - taowen - SegmentFault

- -
【北京上地】滴滴出行基础平台部招聘 Elasticsearch 与 Mysql binlog databus 开发工程师. 内推简历投递给: [email protected] 推销Elasticsearch. 时间序列数据库的秘密(1)—— 介绍. 时间序列数据库的秘密(2)——索引.

elasticsearch的javaAPI之query

- - CSDN博客云计算推荐文章
elasticsearch的javaAPI之query API. the Search API允许执行一个搜索查询,返回一个与查询匹配的结果(hits). 它可以在跨一个或多个index上执行, 或者一个或多个types. 查询可以使用提供的 query Java API 或filter Java API.

Elasticsearch基础教程

- - 开源软件 - ITeye博客
转自:http://blog.csdn.net/cnweike/article/details/33736429.     Elasticsearch有几个核心概念. 从一开始理解这些概念会对整个学习过程有莫大的帮助.     接近实时(NRT).         Elasticsearch是一个接近实时的搜索平台.

ElasticSearch索引优化

- - 行业应用 - ITeye博客
ES索引的过程到相对Lucene的索引过程多了分布式数据的扩展,而这ES主要是用tranlog进行各节点之间的数据平衡. 所以从上我可以通过索引的settings进行第一优化:. 这两个参数第一是到tranlog数据达到多少条进行平衡,默认为5000,而这个过程相对而言是比较浪费时间和资源的. 所以我们可以将这个值调大一些还是设为-1关闭,进而手动进行tranlog平衡.

elasticsearch集群搭建

- - zzm
之前对于CDN的日志处理模型是从 . logstash agent==>>redis==>>logstash index==>>elasticsearch==>>kibana3,对于elasticsearch集群搭建,可以把索引进行分片存储,一个索引可以分成若干个片,分别存储到集群里面,而对于集群里面的负载均衡,副本分配,索引动态均衡(根据节点的增加或者减少)都是elasticsearch自己内部完成的,一有情况就会重新进行分配.

Elasticsearch集群入门

- - 编程语言 - ITeye博客
欢迎来到Elasticsearch的奇妙世界,它是优秀的全文检索和分析引擎. 不管你对Elasticsearch和全文检索有没有经验,都不要紧. 我们希望你可以通过这本书,学习并扩展Elasticsearch的知识. 由于这本书也是为初学者准备的,我们决定先简单介绍一般性的全文检索概念,接着再简要概述Elasticsearch.