› › ›

节点

编辑

节点

编辑

每次启动 Elasticsearch 实例时，您都在启动一个节点。连接节点的集合称为集群。如果您正在运行一个 Elasticsearch 节点，那么您就拥有一个包含一个节点的集群。

默认情况下，集群中的每个节点都可以处理HTTP 和传输流量。传输层专门用于节点之间的通信；HTTP 层由 REST 客户端使用。

所有节点都知道集群中的所有其他节点，并且可以将客户端请求转发到相应的节点。

Elasticsearch 节点的性能通常受底层存储性能的限制。请查看我们针对优化存储以进行索引和搜索的建议。

节点角色

编辑

您可以通过在elasticsearch.yml中设置node.roles来定义节点的角色。如果您设置了node.roles，则节点仅被分配您指定的那些角色。如果您未设置node.roles，则节点将被分配以下角色

主节点
数据节点
数据内容节点
热数据节点
温数据节点
冷数据节点
冻结数据节点
摄取节点
机器学习节点
远程集群客户端节点
数据转换节点

如果您设置了node.roles，请确保您指定了集群所需的每个节点角色。每个集群都需要以下节点角色

主节点
data_content 和 data_hot
或
数据节点

某些 Elastic Stack 功能也需要特定的节点角色

跨集群搜索和跨集群复制需要remote_cluster_client角色。
Stack Monitoring 和摄取管道需要ingest角色。
Fleet、Elastic Security 应用和数据转换需要transform角色。remote_cluster_client角色也需要与这些功能一起使用跨集群搜索。
机器学习功能（如异常检测）需要ml角色。

随着集群的增长，特别是如果您有大型机器学习作业或连续转换，请考虑将专用的主节点候选节点与专用的数据节点、机器学习节点和转换节点分开。

主节点候选节点: 具有master角色的节点，这使得它有资格被选为主节点，该节点控制集群。
数据节点: 具有多个数据角色之一的节点。数据节点保存数据并执行与数据相关的操作，例如 CRUD、搜索和聚合。具有通用data角色的节点可以填充任何专门的数据节点角色。
摄取节点: 具有ingest角色的节点。摄取节点能够将摄取管道应用于文档，以便在索引之前转换和丰富文档。在摄取负载较重的情况下，使用专用的摄取节点并且不从具有master或data角色的节点中包含ingest角色是有意义的。
远程节点候选节点: 具有remote_cluster_client角色的节点，这使得它有资格充当远程客户端。
机器学习节点: 具有ml角色的节点。如果您想使用机器学习功能，则集群中必须至少有一个机器学习节点。有关更多信息，请参阅机器学习设置和Elastic Stack 中的机器学习。
数据转换节点: 具有transform角色的节点。如果您想使用数据转换，则集群中必须至少有一个数据转换节点。有关更多信息，请参阅数据转换设置和转换数据。

协调节点

诸如搜索请求或批量索引请求之类的请求可能涉及存储在不同数据节点上的数据。例如，搜索请求分两个阶段执行，这两个阶段由接收客户端请求的节点（协调节点）协调。

在散布阶段，协调节点将请求转发到保存数据的节点。每个数据节点在本地执行请求并将结果返回给协调节点。在收集阶段，协调节点将每个数据节点的结果缩减为单个全局结果集。

每个节点隐式地都是一个协调节点。这意味着通过node.roles具有显式空角色列表的节点将仅充当协调节点，而无法禁用。因此，此类节点需要有足够的内存和 CPU 来处理收集阶段。

主节点候选节点

编辑

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

任何不是仅投票节点的主节点候选节点都可能被主节点选举过程选为主节点。

主节点必须具有一个path.data目录，其内容在重启后保持不变，就像数据节点一样，因为这是存储集群元数据的位置。集群元数据描述了如何读取存储在数据节点上的数据，因此，如果它丢失，则无法读取存储在数据节点上的数据。

专用主节点候选节点

编辑

对于集群的健康而言，选定的主节点拥有履行其职责所需的资源非常重要。如果选定的主节点因其他任务而过载，则集群将无法正常运行。避免主节点因其他任务而过载的最可靠方法是将所有主节点候选节点配置为专用主节点候选节点，这些节点仅具有master角色，从而使它们能够专注于管理集群。主节点候选节点仍将充当协调节点，将客户端的请求路由到集群中的其他节点，但您不应将专用主节点用于此目的。

如果主节点候选节点具有其他角色和职责，则小型或负载较轻的集群可能会正常运行，但是一旦集群包含超过少数几个节点，通常使用专用主节点候选节点是有意义的。

要创建专用主节点候选节点，请设置

node.roles: [ master ]

仅投票的主节点候选节点

编辑

仅投票的主节点候选节点是指参与主节点选举但不会充当集群选定主节点的节点。特别是，仅投票节点可以在选举中充当决定性因素。

使用“主节点候选”一词来描述仅投票节点可能看起来令人困惑，因为此类节点实际上根本没有资格成为主节点。这种术语是历史的产物：主节点候选节点是指参与选举并在集群状态发布期间执行某些任务的节点，而仅投票节点具有相同的职责，即使它们永远不可能成为选定的主节点。

要将主节点候选节点配置为仅投票节点，请在角色列表中包含master和voting_only。例如，要创建一个仅投票的数据节点

node.roles: [ data, master, voting_only ]

只有具有master角色的节点才能被标记为具有voting_only角色。

高可用性 (HA) 集群需要至少三个主节点候选节点，其中至少两个不是仅投票节点。即使其中一个节点发生故障，此类集群也能够选出一个主节点。

仅投票的主节点候选节点也可以在您的集群中填充其他角色。例如，一个节点可以同时是数据节点和仅投票的主节点候选节点。专用仅投票的主节点候选节点是指在集群中不填充任何其他角色的仅投票的主节点候选节点。要创建专用仅投票的主节点候选节点，请设置

node.roles: [ master, voting_only ]

由于专用仅投票节点永远不会充当集群的选定主节点，因此它们可能需要的堆内存和 CPU 性能比真正的主节点要低。但是，所有主节点候选节点（包括仅投票节点）都位于发布集群状态更新的关键路径上。集群状态更新通常独立于诸如索引或搜索之类的性能关键工作负载，但它们参与管理活动，例如索引创建和滚动、映射更新以及故障后的恢复。这些活动的性能特征是每个主节点候选节点存储速度以及选定主节点与集群中其他节点之间网络互连的可靠性和延迟的函数。因此，您必须确保集群中节点可用的存储和网络足够好，以满足您的性能目标。

数据节点

编辑

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

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

在多层部署体系结构中，您使用专门的数据角色将数据节点分配到特定层：data_content、data_hot、data_warm、data_cold或data_frozen。一个节点可以属于多个层。

如果您希望将节点包含在所有层中，或者如果您的集群不使用多层，则可以使用通用data角色。

集群分片限制防止每个节点创建超过 1000 个非冻结分片，每个专用冻结节点创建超过 3000 个冻结分片。确保集群中每种类型的节点数量足够，以处理您需要的分片数量。

如果您使用专门的数据角色将节点分配到特定层，则不应再为其分配通用data角色。通用data角色优先于专门的数据角色。

通用数据节点

编辑

通用数据节点包含在所有内容层中。

要创建专用通用数据节点，请设置

node.roles: [ data ]

内容数据节点

编辑

内容数据节点属于内容层。存储在内容层中的数据通常是一组项目，例如产品目录或文章档案。与时间序列数据不同，内容的值随时间推移保持相对恒定，因此将其移动到具有不同性能特征的层中没有意义。内容数据通常具有较长的数据保留要求，并且您希望能够快速检索项目，无论其有多旧。

内容层节点通常针对查询性能进行了优化——它们优先考虑处理能力而不是 IO 吞吐量，以便能够快速处理复杂的搜索和聚合并返回结果。虽然它们也负责索引，但内容数据的摄取率通常不如日志和指标等时间序列数据高。从弹性角度来看，此层中的索引应配置为使用一个或多个副本。

内容层是必需的，并且通常部署在与热层相同的节点组中。系统索引和其他不属于数据流的索引会自动分配到内容层。

要创建专用的内容节点，请设置

node.roles: [ data_content ]

热数据节点

编辑

热数据节点属于热层。热层是 Elasticsearch 时间序列数据的入口点，并保存您最新、最常搜索的时间序列数据。热层中的节点需要在读取和写入方面都很快，这需要更多硬件资源和更快的存储（SSD）。为了提高弹性，热层中的索引应配置为使用一个或多个副本。

热层是必需的。属于数据流的新索引会自动分配到热层。

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

node.roles: [ data_hot ]

温数据节点

编辑

温数据节点属于温层。时间序列数据在查询频率低于热层中最近索引的数据后，可以移动到温层。温层通常保存最近几周的数据。仍然允许更新，但可能不频繁。温层中的节点通常不需要像热层中的节点那样快。为了提高弹性，温层中的索引应配置为使用一个或多个副本。

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

node.roles: [ data_warm ]

冷数据节点

编辑

冷数据节点属于冷层。当您不再需要定期搜索时间序列数据时，它可以从温层移动到冷层。虽然仍然可搜索，但此层通常针对更低的存储成本而不是搜索速度进行了优化。

为了获得更好的存储节省，您可以在冷层上保留完全挂载的索引的可搜索快照。与常规索引不同，这些完全挂载的索引不需要副本即可保证可靠性。如果发生故障，它们可以从底层快照中恢复数据。这可能会将数据所需的本地存储量减少一半。使用冷层中的完全挂载索引需要快照存储库。完全挂载的索引是只读的。

或者，您可以使用冷层来存储具有副本的常规索引，而不是使用可搜索快照。这使您可以在价格较低的硬件上存储较旧的数据，但与温层相比，不会减少所需的磁盘空间。

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

node.roles: [ data_cold ]

冻结数据节点

编辑

冻结数据节点属于冻结层。一旦数据不再被查询或很少被查询，它可能会从冷层移动到冻结层，并在那里停留到其生命周期结束。

冻结层需要一个快照存储库。冻结层使用部分挂载的索引来存储和加载来自快照存储库的数据。这减少了本地存储和运营成本，同时仍然允许您搜索冻结数据。由于 Elasticsearch 有时必须从快照存储库中获取冻结数据，因此冻结层上的搜索通常比冷层上的搜索慢。

要创建专用的冻结节点，请设置

node.roles: [ data_frozen ]

摄取节点

编辑

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

要创建专用的摄取节点，请设置

node.roles: [ ingest ]

仅协调节点

编辑

如果您取消处理主节点职责、保存数据和预处理文档的能力，那么您将剩下一个协调节点，它只能路由请求、处理搜索归约阶段并分发批量索引。本质上，仅协调节点的行为类似于智能负载均衡器。

仅协调节点可以通过从数据和主节点候选节点卸载协调节点角色来使大型集群受益。它们加入集群并接收完整的集群状态，就像其他每个节点一样，并且它们使用集群状态将请求直接路由到适当的位置。

向集群添加过多的仅协调节点可能会增加整个集群的负担，因为选定的主节点必须等待来自每个节点的集群状态更新确认！仅协调节点的好处不应被夸大——数据节点可以轻松地服务于相同目的。

要创建专用的协调节点，请设置

node.roles: [ ]

远程节点候选

编辑

远程节点候选充当跨集群客户端，并连接到远程集群。连接后，您可以使用跨集群搜索搜索远程集群。您还可以使用跨集群复制在集群之间同步数据。

node.roles: [ remote_cluster_client ]

机器学习节点

编辑

机器学习节点运行作业并处理机器学习 API 请求。有关更多信息，请参阅Elasticsearch 中的机器学习设置。

要创建专用的机器学习节点，请设置

node.roles: [ ml, remote_cluster_client]

remote_cluster_client 角色是可选的，但强烈建议使用。否则，在机器学习作业或数据馈送中使用跨集群搜索时，会失败。如果您在异常检测作业中使用跨集群搜索，则所有主节点候选节点也需要 remote_cluster_client 角色。否则，数据馈送将无法启动。请参阅远程节点候选。

转换节点

编辑

转换节点运行转换并处理转换 API 请求。有关更多信息，请参阅Elasticsearch 中的转换设置。

要创建专用的转换节点，请设置

node.roles: [ transform, remote_cluster_client ]

remote_cluster_client 角色是可选的，但强烈建议使用。否则，在转换中使用跨集群搜索时，会失败。请参阅远程节点候选。

更改节点的角色

编辑

每个数据节点在磁盘上维护以下数据

分配到该节点的每个分片的分片数据，
与分配到该节点的每个分片相对应的索引元数据，以及
集群范围的元数据，例如设置和索引模板。

类似地，每个主节点候选节点在磁盘上维护以下数据

集群中每个索引的索引元数据，以及
集群范围的元数据，例如设置和索引模板。

每个节点在启动时检查其数据路径的内容。如果它发现意外数据，则它将拒绝启动。这是为了避免导入可能导致集群健康状况变为红色的不需要的悬空索引。更准确地说，如果在启动时在磁盘上找到任何分片数据，则没有 data 角色的节点将拒绝启动；如果在启动时在磁盘上找到任何索引元数据，则没有 master 和 data 角色的节点将拒绝启动。

可以通过调整其 elasticsearch.yml 文件并重新启动它来更改节点的角色。这称为重新利用节点。为了满足上面描述的意外数据检查，在没有 data 或 master 角色的情况下启动节点时，您必须执行一些额外的步骤来准备节点以进行重新利用。

如果您想通过删除 data 角色来重新利用数据节点，则应首先使用分配过滤器安全地将所有分片数据迁移到集群中的其他节点上。
如果您想重新利用节点使其既没有 data 也没有 master 角色，则最简单的方法是使用空数据路径和所需角色启动一个全新的节点。您可能会发现，最好首先使用分配过滤器将分片数据迁移到集群中的其他位置。

如果无法遵循这些额外步骤，则您可以使用elasticsearch-node repurpose工具删除阻止节点启动的任何多余数据。

节点数据路径设置

编辑

`path.data`

编辑

每个数据节点和主节点候选节点都需要访问一个数据目录，在该目录中将存储分片以及索引和集群元数据。 path.data 默认为 $ES_HOME/data，但可以在 elasticsearch.yml 配置文件中配置为绝对路径或相对于 $ES_HOME 的路径，如下所示

path.data:  /var/elasticsearch/data

与所有节点设置一样，它也可以在命令行上指定为

./bin/elasticsearch -Epath.data=/var/elasticsearch/data

path.data 目录的内容必须在重新启动时保持持久性，因为这是您的数据存储位置。Elasticsearch 要求文件系统表现得好像它由本地磁盘支持一样，但这意味着它将在正确配置的远程块设备（例如 SAN）和远程文件系统（例如 NFS）上正常工作，只要远程存储的行为与本地存储没有区别。您可以在同一文件系统上运行多个 Elasticsearch 节点，但每个 Elasticsearch 节点必须有自己的数据路径。

当使用.zip或.tar.gz分发版时，应将path.data设置配置为在Elasticsearch主目录之外定位数据目录，以便可以删除主目录而不会删除您的数据！RPM和Debian分发版已为您执行此操作。

不要修改数据目录中的任何内容，也不要运行可能干扰其内容的进程。如果除Elasticsearch之外的其他内容修改了数据目录的内容，则Elasticsearch可能会失败，报告损坏或其他数据不一致，或者可能看起来工作正常，但已静默丢失了一些数据。不要尝试对数据目录进行文件系统备份；没有支持的方法来恢复此类备份。相反，请使用快照和恢复安全地进行备份。不要在数据目录上运行病毒扫描程序。病毒扫描程序可能会阻止Elasticsearch正常工作，并可能修改数据目录的内容。数据目录不包含任何可执行文件，因此病毒扫描只会找到误报。

其他节点设置

编辑

更多节点设置可以在配置Elasticsearch和重要的Elasticsearch配置中找到，包括

« Elasticsearch 中的监控设置网络 »