ES: Node角色以及使用方法

一文详解Elasticsearch中的Node角色以及使用方法_梦回从前的博客-CSDN博客_node.roles

查看node的角色:

GET _cat/nodes?v

 

 

下面具体来说一下各个角色：

master

其实这个是master准确的来说是具有成为master节点资格的节点，即master-eligible node，具体哪个节点会成为master node则由master选举算法选举出来的，其中6版本的es使用的是Bully算法进行选举；7版本的es使用的定制版本的Raft算法进行选举，具体两者的实现机制和差异改天换篇文章单独说。

    主节点负责集群范围内的元数据（即Cluster State）相关的操作，例如创建或删除索引，跟踪哪些节点是集群的一部分以及确定将哪些 shard 分配给哪些节点。 拥有稳定的主节点对于群集健康非常重要。

    对于大规模的elasticsearch集群配置专用的master节点的必要且有效的，能够提升系统的稳定性，配置方法如下

6.X：

node.master: true 
node.data: false 
node.ingest: false 
search.remote.connect: false

7.X：

node.roles: [ master ]

 在高版本的elasticsearch中master节点可以配置为voting_only角色，此类节点是具有master的选举权，但是不具备master的被选举权，即单纯的选民，大多数场景下此种配置不太必要，建议可以不配置。另外该角色只能是具有master角色的节点才可以配置，配置方式如下:
 

node.roles: [ master, voting_only ]

data

数据节点包含包含已建立索引的文档的分片。 数据节点处理与数据相关的操作，例如 CRUD，搜索和聚合

通用部署
在通用部署的场景下，data节点仅有一个角色data，所有的数据存储和操作都在这个统一的角色下进行。另外为了保证系统的稳定性以及高可用性，配置单独的data节点是必须的，尤其对于大型的elasticsearch集群而言，专用的data节点可以有效的降低节点压力，提升数据处理的稳定性和实时性。配置方式如下：

6.X：

node.master: false 
node.data: true 
node.ingest: false 
search.remote.connect: false

7.X：

node.roles: [ data ]

多层部署

在高版本的elasticsearch中，elasticsearch的data节点可以采用多层部署。在这种部署模式下，data节点被细分成data_content，data_hot，data_warm 或 data_cold四类角色，用来存储和处理不同的数据，常常配置elasticsearch的ilm(索引生命周期管理)来共同管理数据。

Content data node

Content data 节点容纳用户创建的内容。 它们启用 CRUD，搜索和聚合之类的操作。此节点的存在对应着通用部署中的data角色，笔者理解是用来存储在多层部署结构中不需要进行冷热数据分离的索引数据，可以理解为通用数据处理角色。按照官网上“一个节点可以属于多个层，但是具有专用数据角色之一的节点不能具有通用数据角色。”这句话的理解，当你按照多层部署时，应该就不可以配置data这种数据角色，而data_content就是data角色在多层部署中的“别名”。

要创建专用的 content 节点，请设置：
 

node.roles: [ data_content ]

Hot data node

Hot data 数据节点在处理某些种类的ElasticSearch数据，如时序数据这种明显具有时间属性的数据时可以将新数据写入到Hot Data节点中。 Hot Data必须能够快速进行读写操作，并且需要更多的硬件资源（例如 SSD 驱动器）。

要创建专用的 hot 节点，请设置：
 

node.roles: [ data_hot ]

Warm data node

Warm data 节点存储的索引不再定期更新，但仍在查询中。 查询量通常比索引处于热层时的频率低。 性能较低的硬件通常可用于此层中的节点。

要创建专用的 Warm 节点，请设置：

node.roles: [ data_warm ]

Cold data node

Cold data 节点存储只读索引，该索引的访问频率较低。 该层使用性能较低的硬件，并且可能会利用可搜索的快照索引来最大程度地减少所需的资源。

要创建专用的 cold 节点，请设置：

node.roles: [ data_cold ]

 

ingest

摄取节点可以执行由一个或多个ingest processor组成的预处理pipeline。用于对写入或者查询的数据进行预处理，即可以将部分client需要预处理的工作放到了server端，如常见的格式转换，空值处理以及时间处理。可以通过

GET _ingest/pipeline

来查看所有的ingest processor，并在查询或者写入数据时配置相关的processor来进行数据预处理。

要创建专用的 ingest 节点，请设置：

 6.X：

node.master: false 
node.data: false 
node.ingest: true 
search.remote.connect: false 

7.X：

node.roles: [ ingest ]

Remote-eligible node

默认情况下，集群中的任何节点都可以充当跨集群客户端并连接到其他集群。 连接后，你可以使用跨集群搜索来搜索远程集群。 你还可以使用跨集群复制在集群之间同步数据。这些操作实现的基础就是远程连接节点。

6.X：

node.master: false 
node.data: false 
node.ingest: false 
search.remote.connect: true

7.X：

node.roles: [ remote_cluster_client ]

Coordinating only node

 如果一个节点不担任 master 节点的职责，不保存数据，也不预处理文档，那么这个节点将拥有一个仅可路由请求，处理搜索缩减阶段并分配批量索引的协调节点。 本质上，仅协调节点可充当智能负载平衡器。默认elasticsearch的所有节点都可以作为协调节点去路由和分发请求。

    对于大型elasticsearch集群，配置单独的协调节点可以使elasticsearch集群通过从 data 和 master-eligible 节点上分担大量的路由和协调的工作量和资源而提升整个系统效率与稳定性。 他们加入群集并像其他所有节点一样接收完整的群集状态，并且使用群集状态将请求直接路由到适当的位置。

     但是也不能过分夸大协调节点的作用，在集群中添加过多的仅协调节点会增加整个集群的负担，因为主节点每次发布新的Cluster State必须等待每个节点的集群状态更新确认！ 仅协调节点的好处不应被夸大，因为数据节点可以很好地达到相同的目的，而且在某些情况下，协调节点的不合理设置会成为整个集群的性能瓶颈。

6.X：

node.master: false 
node.data: false 
node.ingest: false 
search.remote.connect: false 

7.X：

node.roles: [ ]

总结

1>  对于大型集群来说，专用的master-eligible节点是必要的，建议初始分配三个节点作为master-eligible节点，后续如果有需求进行扩展，对于6.X版本的elasticsearch，注意需要同步修改discovery.zen.ping.unicast.hosts以及discovery.zen.minimum_master_nodes属性；对于7.X版本的elasticsearch，注意需要修改discovery.seed_hosts相关的属性，建议将discovery.seed_providers配置为外部文件的方式，这样可以做到配置热更新的方式，也方便管理。

2> 如果有时序数据以及冷热数据分离的需求，建议data节点使用多层部署的方式，配合elasticsearch的ilm进行数据管理；否则使用通用部署方式即可。

3> 协调节点是把双刃剑，用好了可以分担压力负载均衡，用不好可能就会成为性能瓶颈，所以建议非大型或者并发特别大的集群可以不配置专门的协调节点，在这种场景下数据节点也可以很好的处理好协调的问题；对于使用了专属协调节点的集群，建议对协调节点做好监控，当整体集群的性能陷入瓶颈的时候，协调节点的负载和状态也是需要排查的一个方向