本地英文版地址: ../en/modules-node.html
任何时候启动一个 Elasticsearch 实例，都是在启动一个节点 (node)。 连接的节点的集合称为集群 (cluster)。 如果你运行的是 Elasticsearch 的单个节点，那么你有一个包含一个节点的集群。
默认情况下，集群中的每个节点都可以处理HTTP 和 传输 (Transport)流量。 传输层专门用于节点之间的通信；HTTP 层被 REST 客户端使用。
所有节点都知道集群中的所有其他节点，并且可以将客户端请求转发到适当的节点。
默认情况下，节点包含以下所有类型: 符合主节点条件的节点(master-eligible)、数据节点(data)、预处理节点(ingest) 以及 机器学习(machine learning)(如果可用) 和 转换(transform)节点。
随着集群的增长，特别是如果你有大型机器学习作业或连续转换，请考虑将专用的符合主机条件的节点与专用的数据节点、机器学习节点和转换节点分开。
- 符合主节点条件的节点 (Master-eligible node)
-
node.master设置为true(默认值)的节点，这使它有资格 被选为主 (master)节点，主节点可以控制集群。 - 数据节点 (Data node)
-
node.data设置为true(默认值)的节点。数据节点保存数据并执行与数据相关的操作，如 CRUD、搜索和聚合。 - 预处理节点 (Ingest node)
-
node.ingest设置为true(默认值)的节点。 预处理节点能够将 预处理管道 (ingest pipeline) 应用于文档，以便在索引之前转换并丰富文档。 当预处理负载很大时，使用专用的预处理节点并将主节点和数据节点标记为node.ingest: false是有意义的。 - 机器学习节点 (Machine learning node)
-
xpack.ml.enabled和node.ml设置为true的节点，这是 Elasticsearch 默认发行版中的默认行为。 如果要使用机器学习功能，集群中必须至少有一个机器学习节点。 有关机器学习功能的更多信息，请参考 Elastic Stack 中的机器学习.如果是 OSS-only 的发行版，请不要设置
node.ml。 否则，节点会启动失败。 - 转换节点 (Transform node)
-
xpack.transform.enabled和node.transform设置为true的节点。 如果要使用转换，集群中必须至少有一个转换节点。 更多信息想参考 转换设置 and 数据转换.
协调节点 (Coordinating node)
像搜索请求或批量索引请求这样的请求可能涉及保存在不同数据节点上的数据。 例如，搜索请求分两个阶段执行，这两个阶段由接收客户端请求的节点协调 - 协调节点 (coordinating node).
在scatter阶段，协调节点将请求转发给保存数据的数据节点。 每个数据节点在本地执行请求，并将结果返回给协调节点。 在gather阶段，协调节点将每个数据节点的结果缩减为一个全局结果集。
含蓄地说，每个节点都是一个协调节点。
这意味着所有三个设置node.master、node.data 和 node.ingest都是false的节点将仅充当协调节点，不能禁用。
因此，这样的节点需要有足够的内存和 CPU 来处理gather阶段的数据。
主节点负责轻量级的集群范围的操作，例如创建或删除索引、跟踪哪些节点是集群的一部分，以及决定将哪些分片分配给哪些节点。拥有一个稳定的主节点对于集群的健康非常重要。
任何符合主节点条件的节点，但不是仅可以投票(vote-only)的节点，都可以被主节点选举过程选为主节点。
主节点必须能够访问data/木兰路(就像数据(data)节点一样)，因为这是节点重新启动之间集群状态的保存位置。
当选的主节点拥有履行其职责所需的资源，这对集群的健康非常重要。
如果选出的主节点因其他任务而过载，那么集群可能无法正常运行。
特别是，索引和搜索数据会占用大量资源，因此在大型或高吞吐集群中，最好避免使用符合主节点条件的节点来执行索引和搜索等任务。
为此，你可以将三个节点配置为专用的符合主节点条件的节点。
专用的符合主节点条件的节点仅具有master角色，这使得它们可以专注于管理集群。
虽然主节点也可以充当协调节点，并将搜索和索引请求从客户端路由到数据节点，但最好不要为此使用专用主节点。
要在默认发行版中创建专用的符合主节点条件的节点，请设置：
node.master: true node.voting_only: false node.data: false node.ingest: false node.ml: false xpack.ml.enabled: true node.transform: false xpack.transform.enabled: true node.remote_cluster_client: false
|
默认启动 |
|
|
默认禁用 |
|
|
禁用 |
|
|
禁用 |
|
|
禁用 |
|
|
|
|
|
禁用 |
|
|
|
|
|
禁用远端集群连接 (默认是启用的) |
要在 OSS-only 的发行版中创建专用的符合主节点条件的节点，请设置：
只有投票资格的符合主节点条件的节点是指参与主节点选举 (master elections)，但不会充当集群的当选主节点的节点。 特别是，只有投票资格的节点可以在选举中发挥决定性作用。
用术语 “符合主节点条件的节点(master-eligible)” 来描述 只有投票资格(voting-only) 的节点可能会令人困惑，因为这样的节点实际上根本没有资格成为主节点。 这个术语是历史造成的一个不幸的结果：符合主节点条件的(master-eligible) 的节点是那些参与选举并在集群状态发布期间执行特定任务的节点，而 只有投票资格(voting-only) 的节点具有相同的责任，即使它们永远无法成为被选举的主节点。
要将符合主节点条件的节点配置为只有投票资格的节点，请看以下设置：
voting_only角色需要 Elasticsearch 的默认发行版，在 OSS-only 的发行版中不受支持。
如果使用 OSS-only 的发行版并设置node.voting_only，则节点将无法启动。
另请注意，只有符合主节点条件的节点才能标记为voting_only节点。
高可用性(HA)集群需要至少三个 符合主节点条件 的节点，其中至少两个不是 只有投票资格的节点。即使其中一个节点出现故障，这样的集群也能够选出一个主节点。
由于 只有投票资格的节点 从不充当集群的当选主节点，因此与真正的主节点相比，它们可能需要更少的堆和更弱的CPU。 然而，所有符合主节点条件的节点，包括只有投票资格的节点，都需要相当快的持久存储及与集群其余节点的可靠、低延迟的网络连接，因为它们处于 发布集群状态更新的关键路径上。
只有投票资格的符合主节点条件的节点也可以担任集群中的其他角色。 例如，一个节点既可以是数据节点，也可以是只有投票资格的符合主节点条件的节点。 一个专用的只有投票资格的符合主节点条件的节点 是一个 只有投票资格的符合主节点条件的节点，它不担任集群中的任何其他角色。 要在默认的发行版中创建只有投票资格的符合主节点条件的节点，设置：
数据节点保存包含已建立索引的文档的分片。 数据节点处理与数据相关的操作，如CRUD、搜索和聚合。 这些操作对I/O、内存、CPU是敏感的。 监视这些资源并在它们过载时添加更多的数据节点是很重要的。
拥有专用数据节点的主要好处是主角色和数据角色的分离。
要在默认发行版中创建专用数据节点，请设置：
node.master: false node.voting_only: false node.data: true node.ingest: false node.ml: false node.transform: false xpack.transform.enabled: true node.remote_cluster_client: false
|
禁用 |
|
|
|
|
|
|
|
|
禁用 |
|
|
禁用 |
|
|
禁用 |
|
|
|
|
|
禁用远端集群连接 (默认是启用的) |
要在 OSS-only 的发行版中创建专用数据节点，请设置：
预处理节点可以执行 预处理管道(pre-processing pipelines)，由一个或多个预处理处理器组成。 根据预处理处理器执行的操作类型和所需的资源，拥有专用预处理节点可能是有意义的，这些节点将只执行此特定任务。
要在默认发行版中创建专用预处理节点，请设置：
node.master: false node.voting_only: false node.data: false node.ingest: true node.ml: false node.transform: false node.remote_cluster_client: false
|
禁用 |
|
|
|
|
|
禁用 |
|
|
The |
|
|
Disable the |
|
|
禁用 |
|
|
禁用远端集群连接 (默认是启用的) |
要在 OSS-only 的发行版中创建专用预处理节点，请设置：
如果失去了处理主任务、保存数据和预处理文档的能力，那么只剩下一个协调 (coordinating)节点，它只能路由请求、处理搜索 reduce 阶段及分发批量索引。
本质上，只负责协调的节点就像智能负载均衡器一样。
通过将协调节点角色从数据和符合主节点条件的节点上卸载下来，只负责协调的节点可以使大型集群受益。 它们加入集群并接收完整的集群状态，就像所有其他节点一样，它们使用集群状态将请求直接路由到适当的位置。
向集群添加太多 只负责协调的节点 会增加整个集群的负担，因为选出的主节点必须等待来自每个节点的集群状态更新的确认！ 不应夸大 只负责协调的节点 的好处——数据节点可以很好地服务于相同的目的。
要在默认发行版中创建专用协调节点，请设置：
node.master: false node.voting_only: false node.data: false node.ingest: false node.ml: false xpack.ml.enabled: true node.transform: false xpack.transform.enabled: true node.remote_cluster_client: false
|
禁用 |
|
|
The |
|
|
禁用 |
|
|
禁用 |
|
|
Disable the |
|
|
The |
|
|
禁用 |
|
|
The |
|
|
禁用远端集群连接 (默认是启用的) |
要在 OSS-only 的发行版中创建专用协调节点，请设置：
机器学习功能提供机器学习节点，这些节点运行作业并处理机器学习API请求。
如果xpack.ml.enabled设置为true，node.ml设置为false，则节点可以为 API 请求提供服务，但不能运行作业。
如果要在集群中使用机器学习功能，必须在所有符合主节点条件的节点上启用机器学习(将xpack.ml.enabled设置为true)。
如果想要在客户端(包括Kibana)中使用机器学习功能，还必须在所有协调节点上启用它。
如果用的是 OSS-only 发行版，请不要使用这些设置。
关于这些设置的更多信息，参考 机器学习设置.
要在默认发行版中创建专用的机器学习节点，请设置：
转换节点运行转换并处理转换API请求。
如果要在集群中使用转换，必须在所有符合主节点条件的节点和所有数据节点上将xpack.transform.enabled设置为true。
如果要在客户端(包括Kibana)中使用转换，还必须在所有协调节点上启用它。
还必须在至少一个节点上将node.transform设置为true。
这是默认行为。
如果你用的是 OSS-only 发行版，请不要使用这些设置。更多信息请参考 转换设置.
要在默认发行版中创建专用的转换节点，请设置：
每个数据节点在磁盘上维护以下数据：
- 分配给该节点的每个分片的分片数据，
- 对应于分配给该节点的每个分片的索引的元数据，
- 集群范围的元数据，如设置和索引模板。
同样，每个符合主节点条件的节点在磁盘上维护以下数据：
- 集群中每个索引的索引元数据，
- 集群范围的元数据，如设置和索引模板。
每个节点在启动时检查其数据路径的内容。
如果发现意外的数据，将拒绝启动。
这是为了避免导入不需要的僵尸索引 (dangling indices)，因为这会导致集群运行状况为红色。
更准确地说，如果node.data: false的节点在启动时在磁盘上发现任何分片数据，它们将拒绝启动；如果node.master: false和node.data: false的节点在启动时在磁盘上有任何索引元数据，它们将拒绝启动。
通过调整节点的elasticsearch.yml文件并重新启动，可以更改节点的角色。
这被称为 重新调整节点的用途(repurposing)。
为了满足上述对意外数据的检查，当将节点的node.data或node.master角色设置为false时，必须执行一些额外的步骤来准备重新调整节点的用途:
-
如果你想通过将
node.data更改为false来重新调整数据节点的用途，那么你应该首先使用 分配过滤器 (allocation filter) 将所有分片数据安全地迁移到集群中的其他节点上。 -
如果你想重新调整一个节点的用途，使其同时具有
node.master: false和node.data: false，那么最简单的方法是用一个空的数据目录和所需的角色启动一个全新的节点。 您可能会发现首先使用分配过滤器 (allocation filter)将分片数据迁移到集群中的其他地方是最安全的。
如果无法遵循这些额外的步骤，那么你可以使用节点更改用途工具删除任何阻止节点启动的多余数据。
节点数据路径设置 (Node data path settings)
每个数据和符合主节点条件的节点都需要访问存储分片、索引和集群元数据的数据目录。
path.data默认为$ES_HOME/data，但可以在elasticsearch.yml配置文件中配置为绝对路径或相对于$ES_HOME的路径，如下所示:
path.data: /var/elasticsearch/data
像所有节点设置一样，它也可以在命令行上这样指定：
./bin/elasticsearch -Epath.data=/var/elasticsearch/data
使用.zip或.tar.gz发行版时，path.data设置应该配置为将数据目录定位在 Elasticsearch 主目录之外，这样就可以在不删除您的数据的情况下删除主目录！
RPM和Debian发行版已经帮你做到了。
node.max_local_storage_nodesedit
数据路径 (data path)可以由多个节点共享，甚至可以被来自不同集群的节点共享。 但是，建议使用相同的数据路径只运行一个 Elasticsearch 节点。 此设置在 7.x 中已废弃，将在 8.0 版中删除。
默认情况下，Elasticsearch 被配置为防止多个节点共享同一数据路径。
要允许多个节点(例如，在你的开发电脑上)，请使用node.max_local_storage_nodes设置，并将其设置为大于 1 的正整数。
永远不要从同一数据目录运行不同的节点类型(比如：主节点、数据节点)。 这可能会导致意外的数据丢失。
节点的其他设置
更多关于节点的设置可以在 配置 Elasticsearch 及 Elasticsearch 的重要配置找到, 包含：