无论何时启动Elasticsearch的实例，实际上是在启动一个节点。一组连接的节点被称为一个集群。如果你运行的是Elasticsearch的单一节点，那么你就拥有一个只有一个节点的集群。
集群中的每个节点默认可以处理HTTP和传输层流量。传输层仅用于节点之间的通信，而HTTP层由REST客户端使用。
所有节点都知道集群中的其他所有节点，并且可以将客户端请求转发到适当的节点。
节点角色
通过在elasticsearch.yml中设置node.roles，可以定义节点的角色。如果设置了node.roles，则节点仅被分配您指定的角色。如果未设置node.roles，则节点将被分配以下角色：
- master
- data
- data_content
- data_hot
- data_warm
- data_cold
- data_frozen
- ingest
- ml
- remote_cluster_client
- transform
:::info
如果设置了node.roles，请确保指定集群所需的每个节点角色。每个集群都需要以下节点角色：
master
data_content和data_hot
或者
data
某些Elastic Stack功能还需要特定的节点角色：
跨集群搜索和跨集群复制需要remote_cluster_client角色。
Stack Monitoring和摄取管道需要ingest角色。
Fleet、Elastic Security应用程序和transforms需要transform角色。在使用这些功能时，还需要remote_cluster_client角色来进行跨集群搜索。
机器学习功能，例如异常检测，需要ml角色。
:::
随着集群规模的扩大，特别是在具有大型机器学习作业或持续转换的情况下，请考虑将具有专用主节点资格的节点与专用数据节点、机器学习节点和转换节点分开。
Master-eligible node
具有主节点角色的节点，使其有资格被选为控制集群的主节点。
Data node
具有数据角色的节点。数据节点保存数据并执行与数据相关的操作，如CRUD、搜索和聚合。具有数据角色的节点可以担任任何专门的数据节点角色。
Ingest node
具有摄取角色的节点。摄取节点能够在索引文档之前对文档应用摄取管道，以对文档进行转换和丰富。在有大量摄取的情况下，使用专用的摄取节点并避免在具有主节点或数据节点角色的节点上包含摄取角色是有意义的。
Remote-eligible node
具有remote_cluster_client角色的节点，使其有资格充当远程客户端。
机器学习节点
具有ml角色的节点。如果要使用机器学习功能，集群中必须至少有一个机器学习节点。有关详细信息，请参阅Elastic Stack中的机器学习设置和机器学习。
Transform node
具有transform角色的节点。如果要使用转换功能，集群中必须至少有一个转换节点。有关详细信息，请参阅转换设置和数据转换。
:::info
协调节点
诸如搜索请求或批量索引请求的请求可能涉及存储在不同数据节点上的数据。例如，搜索请求是在由接收客户端请求的节点——即协调节点——协调的两个阶段中执行的。
在分散阶段中，协调节点将请求转发给持有数据的数据节点。每个数据节点在本地执行请求，并将其结果返回给协调节点。在聚合阶段中，协调节点将每个数据节点的结果合并为单个全局结果集。
每个节点都隐式地是一个协调节点。这意味着通过node.roles设置了显式空角色列表的节点将仅充当协调节点，这是无法禁用的。因此，这样的节点需要具有足够的内存和CPU以处理聚合阶段。
:::
具备主节点资格的节点
主节点负责轻量级的集群范围操作，例如创建或删除索引，跟踪集群中的节点，以及决定将哪些分片分配给哪些节点。对于集群的健康而言，拥有一个稳定的主节点是很重要的。
通过主选举过程，任何具备主节点资格但不是仅投票节点的节点都有可能被选为主节点。
:::info
主节点必须具有一个 path.data 目录，其中的内容会在重新启动时持久存在，就像数据节点一样，因为这是存储集群元数据的地方。集群元数据描述了如何读取存储在数据节点上的数据，因此如果元数据丢失，那么存储在数据节点上的数据就无法被读取。
:::
专用的主节点候选节点
确保选举为主节点的节点具有满足其职责所需的资源对于集群的健康至关重要。如果选为主节点的节点负载过重，执行其他任务，那么集群的运行效果将不佳。避免将主节点过载其他任务的最可靠方法是配置所有主节点为专用的主节点候选节点，这些节点仅具有主节点角色，使它们专注于管理集群。主节点候选节点仍将充当协调节点的角色，路由来自客户端的请求到集群中的其他节点，但不应将专用主节点用于此目的。
如果主节点候选节点具有其他角色和职责，那么小型或轻载的集群可能会运行良好，但一旦您的集群包含超过少数节点，通常最好使用专用的主节点候选节点。
要创建专用的主节点候选节点，请设置：
node.roles: [master]
仅投票的主节点候选节点
仅投票的主节点候选节点是参与主节点选举但不会充当集群选定的主节点的节点。特别地，仅投票的节点可以在选举中充当决定性因素。
使用术语“主节点候选节点”来描述仅投票的节点可能会令人困惑，因为这样的节点根本就没有资格成为主节点。这种术语是历史的不幸结果：主节点候选节点是参与选举并在群集状态发布期间执行某些任务的节点，即使它们永远无法成为选定的主节点，投票仅节点具有相同的职责。
要将主节点候选节点配置为仅投票节点，请在角色列表中包含 master 和 voting_only。例如，要创建仅投票的数据节点：
node.roles: [data, master, voting_only]
:::info
Only nodes with the master role can be marked as having the voting_only role.
:::
高可用性（HA）集群至少需要三个主节点候选节点，其中至少有两个不是仅投票节点。这样的集群即使其中一个节点失败，仍将能够选举出主节点。
仅投票的主节点候选节点也可以充当集群中的其他角色。例如，一个节点可以既是数据节点又是仅投票的主节点候选节点。专用的仅投票的主节点候选节点是一个仅投票的主节点候选节点，在集群中不充当其他角色。要创建专用的仅投票的主节点候选节点，请设置：
node.roles: [master, voting_only]
由于专用的仅投票节点永远不会充当集群选定的主节点，因此它们可能需要比真正的主节点更少的堆内存和较弱的CPU。但是，所有主节点候选节点，包括仅投票节点，都处于发布集群状态更新的关键路径上。集群状态更新通常与性能关键的工作负载（如索引或搜索）无关，但它们涉及管理活动，如索引创建和滚动、映射更新以及故障后的恢复。这些活动的性能特性取决于每个主节点候选节点上存储的速度，以及选定的主节点与集群中其他节点之间的网络互连的可靠性和延迟。因此，您必须确保集群中的节点可用的存储和网络足够好，以满足性能目标。
数据节点
数据节点保存包含已索引文档的分片。数据节点处理与数据相关的操作，如CRUD、搜索和聚合。这些操作对I/O、内存和CPU要求较高。重要的是要监控这些资源，并在它们负载过重时添加更多的数据节点。
专用数据节点的主要好处是主节点和数据角色的分离。
要创建专用数据节点，请设置：
node.roles: [data]
在多层部署架构中，您可以使用专用数据角色将数据节点分配给特定的层次：data_content、data_hot、data_warm、data_cold或data_frozen。一个节点可以属于多个层次，但具有专用数据角色之一的节点不能具有通用数据角色。
内容数据节点
内容数据节点是内容层的一部分。存储在内容层的数据通常是一组项，例如产品目录或文章存档。与时间序列数据不同，内容的值随时间的推移保持相对恒定，因此将其移动到具有不同性能特征的层次不是明智的选择。内容数据通常具有较长的数据保留要求，并且您希望能够快速检索项目，而不考虑其年龄。
内容层的节点通常针对查询性能进行优化，它们优先处理处理能力而不是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]
仅协调节点
如果去除了处理主要职责、保存数据和预处理文档的能力，那么剩下的就是一个只能路由请求、处理搜索减少阶段并分发批量索引的协调节点。从本质上讲，仅协调节点的行为类似于智能负载平衡器。
对于大型集群，通过从数据和主节点候选节点卸载协调节点角色，仅协调节点可以带来好处。它们加入集群并接收完整的集群状态，与其他节点一样，并使用集群状态直接将请求路由到适当的位置。
:::info
向集群添加太多的仅协调节点可能会增加整个集群的负担，因为选举出的主节点必须等待来自每个节点对集群状态更新的确认！不应夸大仅协调节点的好处 — 数据节点可以很好地执行相同的任务。
:::
要创建专用的协调节点，请设置：
node.roles: [ ]
远程可连接节点
远程可连接节点充当跨集群客户端，并连接到远程集群。一旦连接，您可以使用跨集群搜索在远程集群中搜索。您还可以使用跨集群复制在集群之间同步数据。
node.roles: [ remote_cluster_client ]
机器学习节点
机器学习节点运行作业并处理机器学习 API 请求。
node.roles: [ ml, remote_cluster_client]
transform 节点
transform 节点运行 transform 并处理 transform API 请求。
node.roles: [ transform, remote_cluster_client ]
更改节点角色
每个数据节点在磁盘上维护以下数据：
- 为分配给该节点的每个分片的分片数据，
- 与为该节点分配的每个分片相对应的索引元数据，
- 集群范围的元数据，例如设置和索引模板。
同样，每个有资格成为主节点的节点在磁盘上维护以下数据：
- 集群中每个索引的索引元数据，
- 集群范围的元数据，例如设置和索引模板。
每个节点在启动时都会检查其数据路径的内容。如果发现意外的数据，则将拒绝启动。这是为了避免导入不需要的悬挂索引，这可能导致集群健康状况不佳。更准确地说，没有数据角色的节点会拒绝启动，如果它们在启动时在磁盘上找到任何分片数据，则没有主数据角色的节点会拒绝启动。
可以通过调整其 elasticsearch.yml 文件并重新启动节点来更改节点的角色。这称为重新定位节点。为满足上述检查意外数据的要求，当启动不带数据或主节点角色的节点时，必须执行一些额外的步骤来准备节点进行重新定位。
- 如果要通过删除数据角色重新定位数据节点，应首先使用分配过滤器将所有分片数据安全地迁移到集群中的其他节点。
- 如果要重新定位节点，使其既没有数据角色也没有主角色，那么最简单的方法是使用空数据路径和所需的角色启动全新的节点。在执行这些额外步骤之前，最安全的方式可能是使用分配过滤器将分片数据迁移到集群中的其他位置。
- 如果无法执行这些额外的步骤，则可能可以使用 elasticsearch-node repurpose 工具删除阻止节点启动的任何多余数据。
节点数据路径设置
path.data
每个数据和有资格成为主节点的节点都需要访问一个数据目录，其中将存储分片以及索引和集群元数据。path.data 默认为 ES_HOME 的路径，如下所示：
path.data: /var/elasticsearch/data
与所有节点设置一样，也可以在命令行上指定它，如下所示：
./bin/elasticsearch -Epath.data=/var/elasticsearch/data
path.data 目录的内容必须在重新启动后持续存在，因为这是您的数据存储的位置。Elasticsearch 要求文件系统表现得好像它是由本地磁盘支持的，但这意味着它将在 properly-configured 远程块设备（例如 SAN）和远程文件系统（例如 NFS）上正确运行。可以在同一文件系统上运行多个 Elasticsearch 节点，但是每个 Elasticsearch 节点必须有自己的数据路径。
Elasticsearch 集群的性能通常受到底层存储性能的限制，因此必须确保存储支持可接受的性能。某些远程存储的性能非常差，特别是在 Elasticsearch 施加的负载下，因此在承诺采用特定存储体系结构之前，请务必在系统上仔细进行基准测试。
:::info
在使用 .zip 或 .tar.gz 发行版时，应配置 path.data 设置以定位数据目录到 Elasticsearch 主目录之外，以便可以删除主目录而不删除数据！RPM 和 Debian 发行版已为您执行此操作。
请勿修改数据目录中的任何内容，也不要运行可能干扰其内容的进程。如果除 Elasticsearch 之外的其他内容修改了数据目录的内容，那么 Elasticsearch 可能会失败，报告损坏或其他数据不一致，或者可能表面上正常工作，但实际上已经悄悄地丢失了一些数据。请勿尝试对数据目录进行文件系统备份；没有受支持的方法来还原这样的备份。相反，请使用快照和还原来安全地进行备份。请勿在数据目录上运行病毒扫描程序。病毒扫描程序可能会阻止 Elasticsearch 正常工作，并可能修改数据目录的内容。数据目录不包含可执行文件，因此病毒扫描只会产生误报。
:::
网友评论