Elasticsearch 集群中节点角色的介绍

默认情况，一个节点 Node 包含下面所有的类型： master-eligible, data, ingest, and machine learning (if available) 。

随着群集的增长，尤其是如果您有大量机器学习工作，需要考虑将具有主机资格（ master-eligible ）的节点专用，将它与专用数据的节点（ data nodes ）和专用机器学习的节点（ machine learning nodes ）分开。

我理解，这里的专用（ dedicated ）一词就是表示，将一个节点的角色不要设置那么多，主节点资格的节点就是用于当主节点，而不是同时具有着数据节点的角色！

本文 ES 是 7.3.0 版本，查看官方文档，发现 ES 7.9.0 的配置就有点区别了。

master-eligible node

master-eligible node ：默认值就是 true 。具有该角色的节点表示它有资格被选举为 mater node 。备注： eligible 一词表示符合条件的含义。

主节点负责集群范围内的轻量级操作，例如创建或删除索引，跟踪哪些节点是集群的一部分以及确定将哪些分片分配给哪些节点。 拥有稳定的主节点对于群集健康非常重要。

在 主节点选举过程中 ，任何一个非 voting-only 的 master-eligible 节点都可能被选为主节点。

很好理解，如果已经是「仅是选举」用途的节点，它怎么能称为主节点呢？

索引和搜索数据是占用大量CPU，内存和 I/O 的工作，这可能给节点的资源带来压力。为了确保主节点稳定且不受压力，在较大的群集中，最好将符合角色的专用主节点和专用数据节点分开。

尽管主节点还可以充当协调节点（ coordinating nodes ），将搜索和索引请求从客户端路由到数据节点，但最好不要为此目的使用专用的主节点。对于符合主节点要求的节点，其工作量应尽可能少，这对于群集的稳定性很重要。

概括来讲就是，主节点的机器不要身兼数职，不要给主节点配置其他节点角色，以免影响主节点的稳定性！

# 可选为主节点（默认是 true）
node.master: true
# voting_only 角色不启用（默认也是 false） 
node.voting_only: false
# data 角色不启用 （默认是 true） 
node.data: false 
# inges 角色不启用（默认是 true）
node.ingest: false 
# ml 角色不启用（默认是 true）
node.ml: false 
# xpack.ml.enabled 默认是启用的
xpack.ml.enabled: true 
# 默认是 true
cluster.remote.connect: false

xpack 功能时付费功能，因此，一般情况下，可以忽略 xpack 的设置。

Voting-only master-eligible node

一个具有 voting-only master-eligible 两种角色的节点，它是参与主节点的选举但不会充当主节点的节点。特别指出， voting-only 可以在选举中为决胜局服务。

要配置一个具有主机资格的节点为 voting-only 节点，需要如下配置

# 默认是 false
node.voting_only: true

注意：OSS-only 分布式版本不支持 voting-only 角色。 只有 master-eligible 的节点才能标记为 voting-only 角色！这里虽然有点难理解，但是由于历史原因造成的。

一个高可用的集群（HA —— High Avaliablity clusters）至少需要 3 个 master-eligible 角色的节点、至少 2 个不是 voting-only 节点。这样的集群将能够在一个主节点故障时选出一个主节点。

一个具有 voting-only master-eligible 两种角色的节点同样也可以赋予其他的角色。例如，一个节点可以同时赋予 voting-only master-eligible data 3 种角色。专用于 voting-only master-eligible 的节点配置如下：

node.master: true
# 默认不启用，需要设置为 false 
node.voting_only: true 
node.data: false 
node.ingest: false 
node.ml: false 
xpack.ml.enabled: true 
cluster.remote.connect: false

Data Node

数据节点包含包含您已建立索引的文档的分片。数据节点处理与数据相关的操作，例如 CRUD，搜索和聚合。这些操作是 I/O，内存和 CPU 密集型的。 监视这些资源并在过载时添加更多数据节点非常重要。

具有专用数据节点的主要好处是将主节点角色和数据节点角色分开。 参考如下配置：

# 默认是 true
node.master: false 
# 默认是 false
node.voting_only: false 
# 默认是 true
node.data: true 
# 默认是 true
node.ingest: false 
# 默认是 true
node.ml: false 
# 默认是 true
cluster.remote.connect: false

Ingest Node

接收节点（ Ingest nodes ）可以执行由一个或多个接收处理器组成的预处理管道。根据摄取处理器执行的操作类型和所需的资源，拥有专用的摄取节点可能会很有意义，这些节点仅会执行此特定任务。

node.master: false 
node.voting_only: false 
node.data: false 
node.ingest: true 
node.ml: false 
cluster.remote.connect: false

Coordinating only nodes

如果您不具备处理主节点职责、保存数据和预处理文档的能力，那么你就剩下一个仅可路由请求的协调节点角色（coordinating only nodes），处理搜索缩减阶段、分配批量索引的。本质上，coordinating only nodes 可充当智能负载平衡器。

在集群中添加过多的仅协调节点可能会增加整个集群的负担，因为选择的主节点必须等待每个节点的集群状态更新确认！仅协调节点的好处不应被夸大 —— 数据节点可以很好地达到相同的目的。

为了创建一个仅协调节点（coordinating only node），可以如下配置：

node.master: false 
node.voting_only: false 
node.data: false 
node.ingest: false 
node.ml: false 
cluster.remote.connect: false