Elasticsearch 节点角色

Posted 2023-05-09

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Elasticsearch 节点角色相关的知识，希望对你有一定的参考价值。

参考技术A

一个Elasticsearch实例代表了一个ES 节点，如果不通过 node.roles 设置节点的角色，一个ES节点默认的节点角色有：master 、data 、data_content、data_hot、data_warm、data_cold、ingest、ml、remote_cluster_client。

Master-eligible node
该节点拥有master 角色，能够在集群故障时被选举为master node，master node负责创建、删除索引，追踪集群中的节点，并确定每个node的shard分配。master node必须有data目录的权限，因为data目录存放了集群的状态信息。

Dedicated Master-eligible node
master node拥有足够的硬件资源去履行它的职责对于整个集群健康运行至关重要，索引和搜索数据是非常耗资源的操作，在大集群和高吞吐量的集群中，应该避免让Master-eligible nodes执行这类任务。为此可以创建三个专用节点，只有master角色，作为Master-eligible node，配置为：

Voting-only master-eligible node
Voting-only master-eligible node在master node的选举过程中参与投票，但是不会作为候选人被选为master node，如下配置该节点为voting-only master-eligible node,只有具有master角色的节点，才能被标记拥有voting-only角色。voting-only nodes不会被选举为master node并履行相应功能，所以对于内存和CPu要求较低，但是相比于集群中其他node,所有的master-eligible nodes也包括voting-only nodes都需要相当快速的磁盘以及可靠、低延迟的网络,以便于更新集群状态。

Data node
该节点拥有 data 角色，Data node保存索引数据，并且执行数据相关的操作：CRUD、search搜索、聚合搜索等，这些操作都比较耗费I/O、内存和CPU资源，在资源不够的情况下应该合理添加data node,一个拥有data角色的节点可以覆盖任何特定的data node细分角色。单独划分data node的好处是可以将master 和data角色区分开。

在多层级业务场景部署架构下，可以根据不同层级给data node分配更加细分的角色：data_content,data_hot, data_warm, data_cold。

Content data node
该角色的nodes会处理用户创建的文档内容，包括CRUD、数据搜索和聚合等。

Hot data node
该角色的nodes会根据数据进入ES的时间存储时序数据，hot层对数据读写要求较快，可以使用SSD。

Warm data node
该角色的nodes会存储不再被经常更新但是仍然被查询的索引数据，相比较于在hot层数据查询的频率要低。

Cold data node
该角色的nodes会存储很少被获取的只读索引，该层耗费资源少，可以搜索快照索引减少资源需求。

Ingest node
该节点拥有 ingest 角色，Ingest node可以在文档索引之前执行ingest pipeline，进行数据清洗、字段填充等工作，对于数据预处理较为复杂，负载较重的ingest来说，应该单独部署ingest node。

Remote-eligible node
改节点拥有remote_cluster_client角色，可以充当远程客户端，默认情况下，集群内任意节点都可以作为跨集群的客户端连接到远程集群。

Machine learning node
该节点拥有ml角色，并且 xpack.ml.enabled 开关打开，如果需要使用机器学习功能，集群内至少需要有一个机器学习节点。

Transform node
改节点拥有transform角色，如果想要使用transforms功能，集群中只是需要一个transform node。

Coordinating node
协调节点负责处理所有来自客户端的请求以及返回给客户端的响应结果，默认情况下每个node都是协调节点。如果将node按功能分配角色：master node处理主节点事务、data node保存数据、ingest node进行数据预处理，那么coordinating node则是 route 客户端请求、处理搜索数据整合阶段并且分配批量索引操作 bulk indexing。可以将node配置为 Coordinating only node ，让该节点作为一个负载均衡器。添加过多的Coordinating only node会给集群带来负担，因为master node需要等待集群state信息更新到了所有节点。其实，data node就可以很好的充当协调节点。

干货 | Elasticsearch 8.X 节点角色划分深入详解

0、问题引出

如果你的 Elasticsearch 集群是 7.9 之前的版本，在配置节点的时候，只会涉及节点类型的概念。我相信大家会对下面的概念比较熟悉：

主节点
数据节点
协调节点
Ingest 节点
冷热集群架构

......

Elasticsearch 7.9 版本引入了节点角色的概念。最近社群小伙伴关于节点角色提了不少问题，列举如下：

Q1：请问 Nginx + ES Coordinate + ES Master + ES Node 如何安装配置呢？是否安装一样，只需更改节点角色即可？
Q2：ES部署上，node.role都是mdi和 node.role区分m、d、i ,在部署上各有什么优势？更推荐用哪种？
Q3：有 ES 7.x 的集群角色如图，请问在写入海量数据时，应该连接什么角色的节点写入？专用协调节点还是数据节点？
Q4：role的配置，加上这些data_hot, data_warm, data_cold 和自定义的attr属性有区别吗？
Q5：谁能解释一下es的角色 data data_content data_hot/warm/cold他们直接的关系？
Q6：请问 ES 7.10 的 data_content 角色是个什么样的存在？和协调节点什么区别？

带着这些问题，我们开始 Elasticsearch 节点角色的解读。

1、什么是 Elasticsearch 节点角色？

Elasticsearch 7.9 之前的版本中的节点类型：数据节点、协调节点、候选主节点、ingest 节点，在 Elasticsearch 7.9 以及之后版本中有了升级，升级了什么呢？

节点类型升级为节点角色（Node roles）。节点角色分的很细：数据节点角色、主节点角色、ingest节点角色、热节点角色等。

在 Elasticsearch 集群中，每个启动的 Elasticsearch 进程都可以叫做一个节点。集群中只有一个节点的时候，以 Elasticsearch 8.1.3 版本单节点集群为例，如果我们不手动设置节点角色，默认节点角色如下“红框”所示：

GET _cat/nodes?v

# 返回结果
ip          heap.percent ram.percent cpu load_1m load_5m load_15m node.role   master name
172.21.0.14           70          96   0    0.03    0.03     0.05 cdfhilmrstw *      VM-0-14-centos

当集群中有多个节点角色的时候，就需要手动设定、配置节点的角色。

节点角色划分的目的在于：不同角色的节点各司其职，共同确保集群的功能的稳定和性能的高可用。

如上截图中的 “cdfhilmrstw”，我第一次看到这个串也是一脸懵逼，解释一下，你就“豁然开朗”。

角色缩写	英文释义	中文释义
c	cold node	冷数据节点
d	data node	数据节点
f	frozen node	冷冻数据节点
h	hot node	热数据节点
i	ingest node	数据预处理节点
l	machine learning node	机器学习节点
m	master-eligible node	候选主节点
r	remote cluster client node	远程节点
s	content node	内容数据节点
t	transform node	转换节点
v	voting-only node	仅投票节点
w	warm node	温数据节点
空	coordinating node only	仅协调节点

2、为什么引入节点角色？节点类型不香吗？

https://github.com/elastic/elasticsearch/pull/54998

一个新功能的诞生必然是基于早期版本存在bug或者至少用户体验差。

节点角色就是基于节点类型配置复杂和用户体验差应运而生的。

早期版本如果需要配置仅候选主节点类型，需要的配置（极端情况）如下：

node.data: false
node.ingest: false
node.remote_cluster_client: false
node.ml: false
node.master: true
node.transform: false
node.voting_only: false

这是非常繁琐的配置，类似我要说我自己是主节点，需要我先说明我不是数据节点、不是 Ingest 预处理节点、不是机器学习节点、不是XXX各种节点.....

而节点角色的出现“革命性”的结局了这个问题，如下所示，只需要说明我是某某某，而不需要费劲巴拉的解释我不是某某某。

node.roles: [ data, master ]

3、不同角色节点的功能详解

3.1 主节点（Master-eligible node）

主节点的核心用途：集群层面的管理，例如创建或删除索引、跟踪哪些节点是集群的一部分，以及决定将哪些分片分配给哪些节点。主节点的path.data 用于存储集群元数据信息，不可缺少。
主节点的重要性：拥有稳定的主节点对于集群健康非常重要。

和早期版本不同，节点角色划分后，主节点又被细分为：候选主节点和仅投票主节点。

主节点存储数据：集群中每个索引的索引元数据，集群层面的元数据。

3.1.1 专用候选主节点（Dedicated master-eligible node）

如果集群规模大、节点多之后，有必要独立设置专用候选主节点。

专用候选主节点配置：

node.roles: [ master ]

3.1.2 仅投票主节点（Voting-only master-eligible node）

用途：仅投票，不会被选为主节点。

硬件配置可以较专用候选主节点低一些。

仅投票主节点配置：

node.roles: [ master, voting_only ]

注意：master 必不可少。

关于集群主节点配置，要强调说明如下：

高可用性 (HA) 集群需要至少三个符合主节点资格的节点；其中至少两个不是仅投票节点。
即使其中一个节点发生故障，这样的集群也将能够选举一个主节点。

3.2 数据节点（Data node）

数据节点用途：数据落地存储、数据增、删、改、查、搜索、聚合操作等处理操作。

数据节点硬件配置：CPU 要求高、内存要求高、磁盘要求高。

专属数据节点好处：主节点和数据节点分离，各司其职。

数据节点存储内容：

分片数据。
每个分片对应的元数据。
集群层面的元数据，如：setting 和索引模板。

拥有专用数据节点的主要好处是主角色和数据角色的分离。

数据节点的配置：

node.roles: [ data ]

在 Elastic 多层（tires）冷热集群架构体系下，数据节点又可以细分为：

内容数据节点（Content data node）
热数据节点（Hot data node）
温数据节点（Warm data node）
冷数据节点（Cold data node）
冷冻数据节点（Frozen data node）

图片来自：Elastic 官方博客

3.2.1 内容数据节点

用途：处理写入和查询负载，具有较长的数据保留要求。

建议至少设置一个副本，以保证数据的高可用。

不属于数据流的系统索引或其他索引会自动分配到内容数据节点。

node.roles: [ data_content ]

3.2.2 热数据节点

用途：保存最近、最常访问的时序数据。

推荐使用：SSD 磁盘，至少设置一个副本。

node.roles: [ data_hot ]

3.2.3 温数据节点

用途：保存访问频次低且很少更新的时序数据。

node.roles: [ data_warm ]

3.2.4 冷数据节点

用途：保存不经常访问且通常不更新的时序数据。可存储可搜索快照。

node.roles: [ data_cold ]

3.2.5 冷冻数据节点

用途：保存很少访问且从不更新的时序数据。

node.roles: [ data_frozen ]

在冷热集群架构时序数据 ILM 索引生命周期管理的实战演练环节，验证发现：

在配置节点角色时，data_hot、data_warm、data_cold 要和 data_content 要一起配置。且 data_hot、data_warm、data_cold 不要和原有的data 节点一起配置了。

如果仅data_hot 不设置 data_content 会导致集群数据写入后无法落地。

我的理解：data_hot, data_warm, data_cold 是标识性的节点，实际落地存储还得靠 data_content 角色。

3.3 数据预处理节点（ingest node）

用途：执行由预处理管道组成的预处理任务。

关于啥是数据的预处理？之前有多篇文章解读过：

Elasticsearch 预处理没有奇技淫巧，请先用好这一招！

Elasticsearch的ETL利器——Ingest节点

node.roles: [ ingest ]

3.4 仅协调节点（Coordinating only node）

用途：类似智能负载均衡器，负责：路由分发请求、聚集搜索或聚合结果。

注意事项：在一个集群中添加太多的仅协调节点会增加整个集群的负担，因为当选的主节点必须等待来自每个节点的集群状态更新的确认。

node.roles: [ ]

空即是“色”，不对，这里空即是“仅协调节点”。

3.5 远程节点（Remote-eligible node）

用途：跨集群检索或跨集群复制。

node.roles: [ remote_cluster_client ]

3.6 机器学习节点（Machine learning node）

用途：机器学习，系收费功能。

node.roles: [ ml, remote_cluster_client]

3.7 转换节点（Transform node）

用途：运行转换并处理转换 API 请求。这块，咱们之前文章没有涉及。

4、回答开篇问题

4.1 Q1：请问 Nginx + ES Coordinate + ES Master + ES Node 如何安装配置呢？是否安装一样，只需更改节点角色即可？

答案：先划分节点角色。节点不多的话手动one by one 部署（部署好了一个，其他的拷贝后修改角色、ip等就可以），节点非常多的话可以借助：ansible 等脚本工具快速部署。

4.2 Q2：ES部署上，node.role都是mdi和 node.role区分m、d、i ,在部署上各有什么优势？更推荐用哪种？

答案：本文已介绍。m 代表主节点 master， d 代表数据节点 data， i 代表数据预处理节点 ingest。

4.3 Q3：有 ES 7.x 的集群角色如图，请问在写入海量数据时，应该连接什么角色的节点写入？专用协调节点还是数据节点？

答案：看节点规模和节点角色划分，如果已经有了独立协调节点，连接独立协调节点。如果没有，连接硬件配置高的节点。

4.4 Q4：role的配置，加上这些data_hot, data_warm, data_cold 和自定义的attr属性有区别吗？

答案：新版本新特性，有区别，新的方式配置更为简洁，可读性强、用户体验优。

4.5 Q5：谁能解释一下es的角色 data data_content data_hot/warm/cold他们直接的关系？

答案：系冷热集群架构的数据节点的分层处理机制。相当于早期版本冷热集群架构的手动配置节点属性的部分，高版本做了精细切分，使得数据冷热集群管理更为高效。尤其默认迁移（migrate ）自动实现机制，之前版本的分片分配策略手动配置变得不再必须：

"allocate" : 
            "include" : 
              "box_type": "hot,warm"

4.6 Q6：请问 ES 7.10 的 data_content 角色是个什么样的存在？和协调节点什么区别？

答案：两种完全不同的节点。data_content 属于数据节点，永久存储数据的地方。而协调节点是用来请求路由分发、结果汇聚处理的。

5、小结

有了节点角色划分之后，老版本的节点类型配置还是支持的。最早使用节点角色做 ILM 索引生命周期管理还有点不适应，摸索了一小段时间。

但，我们得拥抱 Elasticsearch 的变化。

节点角色的划分是用户体验层面、功能层面的改进，有了它，我们节点划分会更加明晰，节点用途会更加聚焦、具体。

关于节点角色和硬件配置的关系，也是经常被提问的问题，推荐配置参考：

角色	描述	存储	内存	计算	网络
数据节点	存储和检索数据	极高	高	高	中
主节点	管理集群状态	低	低	低	低
Ingest 节点	转换输入数据	低	中	高	中
机器学习节点	机器学习	低	极高	极高	中
协调节点	请求转发和合并检索结果	低	中	中	中

你的生产环境使用了什么版本的集群？如何做的节点角色的划分？欢迎留言讨论。

参考

https://www.elastic.co/guide/en/elasticsearch/reference/current/data-tiers.html
https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-node.html
https://www.elastic.co/cn/blog/whats-new-elasticsearch-7-11-0-schema-on-read-is-here
探究 | Elasticsearch集群规模和容量规划的底层逻辑