前言

说到elasticsearch，大家第一反应就是他是一款NOSQL数据库，既然是NOSQL数据库，则生产环境上必定是集群，由很多台服务器共同搭建而成。按照常理，分布式集群从搭建模式上分为中心化模式，即有主节点和从节点之分，即部分节点有成为主节点的资格，其余节点则只能是从节点，如Hadoop，HBase；另外一种模式是去中心化模式，即所有节点的角色都一样，任何一个节点都有可能成为主节点，如Zookeeper，Cassandra，而Elasticsearch显然属于前者，每个节点都有属于自己的角色，说到这里，就引出了本文的论题，elasticsearch中node的角色有哪些？不同的角色起到的作用都是什么？

下面先通过kibana看下不同版本的elasticsearch集群上节点的角色：

使用如下命令：

GET _cat/nodes?v

得到如下的返回值：

elasticsearch6.0版本：

elasticsearch7.9版本：

这里需要说明下，由于elasticsearch版本迭代速度比较快，加上X-PACK的影响，所以elasticsearch在6和7版本的node的角色变化很大，大家以自己版本的elasticsearch为准来进行配置。由于使用的是测试环境，所以都是单机部署，且都是默认配置，所以该节点上的node的role即是当前版本所有的role。如图所示，elasticsearch6.0上的角色是mdi，而elasticsearch7.9上的角色是dilmrt，下面就详细说说这些角色所代表的的意义和使用方法：

正文

elasticsearch的节点有下面几种角色：

• master
• data
• ingest
• ml
• remote_cluster_client
• transform

根据版本不同，这几种节点是否存在需要根据具体版本的elasticsearch来确定。上面的例子中，mdi，即master、data以及ingest三种角色，这要是elasticsearch自从6.X以来最基础的三种角色；而7.9的dilmrt就是对应着上面的六种全部的角色。而额外的三种角色是ml以及transform是因为X-pack插件的引入而带来的，remote_cluster_client则是跨集群连接时需要用到的client节点。X-pack从6.3版本开始逐步的开源和免费部分功能，所以lrt三个特性在不同版本的elasticsearch中可能有所不同，建议大家根据elasticsearch的版本自行确认。

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

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

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

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

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: [ ]

Machine learning node（X-pack专用角色）

X-pack笔者用的不多，这里就直接从官网翻译完拿过来直接用了，感兴趣的小伙伴可以自己研究下。

机器学习节点提供了机器学习功能，该节点运行作业并处理机器学习 API 请求。 如果 xpack.ml.enabled 设置为 true，并且该节点不具有 ml 角色，则该节点可以处理 API 请求，但不能运行作业。

如果要在群集中使用机器学习功能，则必须在所有master-eligible的节点上启用机器学习（将 xpack.ml.enabled 设置为true）。 如果要在客户端（包括 Kibana）中使用机器学习功能，则还必须在所有协调节点上启用它。 如果你只有 OSS 发行版，请不要使用这些设置。

要在默认发布中创建专用的机器学习节点，请设置：

node.roles: [ ml ]
xpack.ml.enabled: true 

Transform node（X-pack专用角色）

转换节点运行转换并处理转换 API 请求。 如果你只有 OSS 发行版，请不要使用这些设置。 

要在默认分发中创建专用的变换节点，请设置：

node.roles: [ transform ]

总结

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. 协调节点是把双刃剑，用好了可以分担压力负载均衡，用不好可能就会成为性能瓶颈，所以建议非大型或者并发特别大的集群可以不配置专门的协调节点，在这种场景下数据节点也可以很好的处理好协调的问题；对于使用了专属协调节点的集群，建议对协调节点做好监控，当整体集群的性能陷入瓶颈的时候，协调节点的负载和状态也是需要排查的一个方向
4. 最重要的，一定要根据自己的elasticsearch版本来确认哪些节点角色以及如何配置，不能一概而论