你可能已经知道 Elasticsearch 集群由一个或多个节点组成。 每个节点将数据存储在分片上，每个分片存储在一个节点上。 到目前为止，你看到的每个节点都至少存储了一个分片，但值得注意的是，节点并不总是必须存储分片。
这是因为每个节点可能具有一个或多个角色，这些角色决定了节点的用途。 这些角色决定了节点做什么以及如何做。 并且，基于集群设置，我们可以为每个节点分配不同的角色。 如果我们不为节点定义角色，Elasticsearch 会默认为它分配所有角色。 顺便说一句，所有版本的 Elasticsearch 都是如此。
节点角色类型：
- 主节点角色
- 数据节点角色
- 协调节点角色
- 摄取节点角色
- 机器学习节点角色
- 远程合格节点角色
- 转换节点角色
让我们来看看可用的角色。
主节点 - Master node
现在，让我们谈谈 Elasticsearch 集群中的最重要的节点：主节点。 这个节点是负责管理整个集群的节点，所以你知道这非常重要。 它处理所有集群范围的功能，例如构建和删除索引、监控节点和分发分片。 并得到这个：如果主节点发生故障或变得不可用，任何具有 master 资质（master eligible）的节点都可以接管。 因此，需要共同努力才能使集群像运转良好的机器一样工作。
主节点充当操作的大脑。 它控制描述索引的所有元数据，例如索引名称、分片数量和主分片位置。 这个元数据告诉集群索引的存在和位置。 它还管理节点操作，例如分片之间的数据分布以及执行集群级别的设置和策略。 这就是所有节点无缝协作的方式。
但是等等，还有更多！ 主节点还监视所有节点的健康状况。 它保证他们响应查询并有足够的存储空间来存储数据。 如果一个节点出现故障或空间不足，主节点可以将分片移动到另一个节点。 这确保集群即使在高峰使用期间也能保持稳定和响应。
主节点被构建为具有容错性和高可用性。 它就像一个超人，即使在其他一切都失败的情况下也能使集群继续运行。 如果主节点发生故障，另一个节点可以接管而不会中断集群的其余部分。 根据可用节点的数量和要存储的数据量等参数，主节点选择哪些分片去哪里。 这保证了数据在整个集群中有效分布。
但是等等，仅仅因为一个节点具有主节点角色并不会自动使其成为主节点。 集群的主节点是通过投票程序选出的，因此即使一个或多个节点发生故障，它也始终可以确保正常运行。 这种投票机制确保集群即使在极端压力下也能保持稳定和有效。
在大型集群中，拥有只负责特定任务的专用主节点是个好主意。 这允许主节点在保持集群稳定性的同时专注于关键任务。 如果主节点试图执行太多任务，例如提供搜索查询，集群可能会变得不稳定。 因此，请确保主节点不会因新任务而负担过重。
在配置 Elasticsearch 集群时考虑如何配置主节点。 对于大型集群，与数据节点隔离的专用主节点可能是最佳选择。 但是，对于需求较低的较小集群，具有主节点角色的单个节点可能就足够了。 这一切都归结为找到性能和稳定性之间的适当平衡。
如果您发现主节点正在消耗大量 CPU 内存和 I/O，请尝试安装另一个主节点来专门处理该任务。 以这种方式，工作负载可以分布在多个节点上，确保集群在高峰使用期间保持稳定和响应。
要分配节点角色，请修改节点的 elasticsearch.yml 文件并添加以下行：
node.roles: ["master"]数据节点 - data node
Elasticsearch 中的数据节点用于在其内部存储数据，类似于数据仓库，当客户端向集群发送查询时，该请求被路由到包含必要数据的数据节点，然后执行查询，并且结果交付给客户。
当数据被添加到集群时，它被索引并存储在一个或多个数据节点上。 Elasticsearch 使用前面提到的分片技术将数据分布在多个节点上，增强了性能和可扩展性。
在 Elasticsearch 中使用专用数据节点可为用户提供众多优势。 最重要的优势之一是速度。 通过对数据和搜索请求进行分类，Elasticsearch 可以处理更多的并发查询，并通过将数据和搜索请求划分到多个节点来提供更快的搜索结果。 当单个节点可能被需求淹没时，这在大型集群中尤为重要。
数据节点的另一个优点是它们使扩展更容易。 Elasticsearch 旨在水平扩展，这意味着你可以向集群添加更多节点以提高其性能。 用户可以通过使用数据节点单独增加集群的存储和搜索能力。 这样可以更有效地利用资源并减少出现瓶颈的可能性。
当然，利用数据节点并不全是彩虹和阳光。 涉及到一定的困难。 最困难的挑战之一是管理所有这些数据。 随着集群变大，管理节点上的所有数据变得更加困难。 在具有许多分片或高搜索请求率的集群中尤其如此。 用户可能需要考虑增加更多的数据节点或优化他们的数据管理策略来克服这个困难。
数据节点面临的另一个问题是资源利用率。 为了正常运行，数据节点需要大量资源，例如内存、磁盘空间和 CPU。 在资源有限的集群中，数据节点可能成为瓶颈，导致集群难以高效运行。 用户可能需要优化他们的硬件配置或建立一个专门的主节点来从数据节点卸载部分处理任务来避免这种情况。
要设置节点角色，请编辑节点的 elasticsearch.yml 并添加以下行：
node.roles: ["data"]因此，当你进行多层部署架构时，你必须使用这些奇特的数据角色，如 data_content、data_hot、data_warm、data_cold 和 data_frozen 将数据节点放入特定层。 一个节点可以在多个层中，但如果它具有这些奇特的数据角色之一，那么它就不能具有普通的数据角色。 如果你想查看有关这些层的更多信息，只需点击 Elasticsearch 文档即可。
协调节点 - coordination node
协调角色负责在整个 Elasticsearch 集群中分发查询。 换句话说，它处理处理请求所需的工作委派。 与数据节点不同，协调节点不会自行搜索数据，而是将该任务分配给数据节点。
要使节点专门用作协调节点，必须从中删除所有其他角色。 这可以通过定义节点的设置以排除所有其他角色来实现。 因此，专用协调节点可以处理 Elasticsearch 集群内的查询协调和委托活动。
协调节点的一个潜在应用是大规模搜索操作，例如电子商务网站或数据仓库中的搜索操作。 在这些情况下，大量查询同时运行，因此在集群中均匀分布负载以避免任何一个节点过载至关重要。 通过使用专用的协调节点可以平均分配负载，确保快速有效地处理查询。
协调节点的另一个潜在用例是处理复杂查询。 在这些场景中，协调节点可以将查询分解为更小的子查询，并将它们分布在集群中进行处理。 这种方法可以大大提高复杂查询的性能，因为每个子查询都可以由集群内的不同节点并行处理。
协调节点角色不是一个独立的解决方案。 为了获得最佳性能，集群中的所有角色都必须进行适当的优化和配置。 这包括适当的节点大小调整、网络配置和查询调整。
要设置节点角色，请编辑节点的 elasticsearch.yml 并添加以下行：
node.roles: []请注意：如果你向集群中添加过多的仅协调节点，就会出现问题。 因为主节点必须等待来自每个节点的更新，这使得整个集群更加努力地工作。 不要误会我的意思：协调节点很有用，但应谨慎使用。 数据节点可以执行相同的功能并且对此感到高兴！
摄取节点 - ingest node
Elasticsearch 的摄取角色允许节点运行用于使用 Elasticsearch 文档的管道。 但究竟什么是摄取管道？ 本质上，它是将文档上传到 Elasticsearch 时必须遵循的一系列过程。 这些进程有时称为处理器，可用于在索引文档之前对其进行微调。如果你想了解更多，请详细阅读文章 “Elastic：开发者上手指南” 中的 Ingest pipeline 部分。
假设你有一个 Web 服务器访问日志，你希望将其提取到 Elasticsearch 中。 日志中的每个请求都保存为单独的文档，但你可能希望通过添加基于访问者 IP 地址的地理信息来增加趣味性。 你可以使用处理器使用输入管道将 IP 地址转换为纬度和经度坐标以及 IP 是属于哪个国家的。
摄取管道可以根据需要简单或复杂。 Logstash 是 Elastic Stack 中的另一个组件，可用于极其复杂的数据转换。 但是，如果您只需要对数据进行最少的更改，则摄取管道是一个方便的工具。
但是，当你摄取大量数据时，通过摄取管道运行所有文档可能会拖累你的硬件。 这就是专用摄取节点派上用场的地方。 通过为每个节点启用或禁用摄取管道，你可以分散工作负载并避免任何一个节点陷入困境。
请记住，某些 Elastic Stack 产品（例如 Beats 和 Logstash）提供了自己的摄取管道。 这些管道能够收集和转换来自各种来源的数据，包括日志、指标和网络流量。
为了在 Elasticsearch 中使用摄取角色，你必须首先设置一个摄取管道。 你可以通过定义一组处理器并使用 Ingest API 配置它们应用于你的数据的方式来实现这一点。 构建管道后，你可以使用 Index API 将数据提取到 Elasticsearch 中。
Ingest API 有许多数据处理器，允许你添加、删除或重命名字段、划分或合并字段、转换数据类型以及执行条件操作。 第三方处理器也可用于扩展摄取管道的能力。
在设计摄取管道时，考虑每个处理器的性能影响至关重要。 一些处理器非常耗费资源，使用太多或顺序错误会严重降低 Elasticsearch 集群的性能。
在将数据发布到你的生产环境之前，在有意义的数据样本上测试你的摄取管道，以确保最佳性能。 你还可以使用 Elasticsearch Monitoring API 监控管道的性能，该 API 提供有关 Elasticsearch 集群的实时指标和统计信息。
要为节点分配角色，请更新其“elasticsearch.yml”文件并添加以下行：
node.roles: ["ingest"]机器学习节点 - machine learning node
Elasticsearch 有一个很棒的机器学习节点，非常适合处理机器学习 API 调用。
这一切都归结为利用尖端算法和统计模型来分析数据并发现模式和见解，而借助 Elasticsearch 的机器学习功能，这一切都归结为利用尖端算法和统计模型来分析数据并揭示模式和见解 .
你可以利用 Elasticsearch 的机器学习功能来分析海量数据集、发现异常，甚至生成预测！ 这不是很神奇吗？
但这里有问题。 你的 CPU 必须能够处理 SSE4.2 指令才能使用机器学习算法。 所以，如果你的 CPU 不支持这个指令集，那你就不走运了。
但是等等，还有更多！ 设置机器学习节点非常简单。 你所要做的就是将此配置添加到 elasticsearch.yml 文件中：
node.roles: [“ml”]这指示 Elasticsearch 建立一个超棒的机器学习节点，它可以像老板一样处理你所有的机器学习 API 调用，之后你可以像专业人士一样开始在你的 Elasticsearch 集群上执行机器学习算法。
哦，如果你正在利用 remote_cluster_client 功能进行机器学习，请确保也为机器学习节点提供 remote_cluster_client 角色。 这确保所有节点都准备好像老板一样处理远程集群请求。
node.roles: ["ml", "remote_cluster_client"]顺便说一句，利用专用主节点或协调节点作为机器学习节点并不总是最佳选择。 如果你在未针对机器学习算法进行优化的节点上运行机器学习算法，它们会消耗大量资源并导致性能问题。
让我们看看你可以使用机器学习节点做的其他一些有趣的事情。 例如，它包含用于生成和管理机器学习作业的 API，以及用于监控机器学习模型性能和实时识别异常的工具。
Elasticsearch 中的机器学习节点还支持广泛的机器学习算法和模型，包括监督和非监督学习、回归、聚类和异常检测。 这意味着你可以为你的特定用例和数据集选择最佳算法。
Elasticsearch 机器学习功能的一大优点是，它使你能够快速轻松地分析大型数据集并提取有意义的见解。 例如，企业可以使用机器学习算法来分析客户数据并识别可以为营销和产品开发策略提供信息的模式和趋势。
Elasticsearch 的机器学习节点的另一个好处是它可以帮助企业实时检测和预防欺诈。 通过分析交易数据并识别模式和异常，企业可以在欺诈活动造成重大损害之前快速检测和预防欺诈活动。
远程支持节点 - remote eligible node
Elasticsearch 可以支持远程集群，这是它最吸引人的特性之一。 这意味着你可以在不同的位置拥有集群，这些集群可以复制索引并使用跨集群搜索进行搜索。
为此，你需要使用一个名为 remote_cluster_client 的特殊节点角色。 此角色允许节点与远程集群通信并执行跨集群复制和搜索操作。
要将节点设置为远程支持节点，你只需将此配置添加到 elasticsearch.yml 文件中：
node.roles: [“remote_cluster_client”]但这仅仅是个开始。 你还需要配置集群和索引，以便可以跨多个节点访问和搜索它们。
remote_cluster_client 节点角色对于拥有许多数据中心或地理区域的大型组织特别有益。 这使他们能够跨多个站点复制数据以实现冗余和灾难恢复。 通过跨集群复制，数据可以实时或近乎实时地复制到远程集群，因此即使主集群出现故障，数据也始终可用。
此外，符合条件的远程节点可用于跨集群搜索，这对于拥有许多团队或部门从事不同项目的大型组织来说非常棒。 他们都可以搜索正在生成的所有数据。
从本质上讲，remote_cluster_client 节点角色是需要配置跨集群复制和搜索活动的组织的重要工具。 你可以确保数据被复制到多个位置，并且可以通过使节点远程符合条件从集群中的任何节点进行搜索。
关于远程搜索（CCS）及远程复制（CCR），请阅读文章 “Elastic：开发者上手指南” 中的 “跨集群操作及备份” 部分。
变换节点 - transform node
转换节点是 Elasticsearch 中用于创建新索引和获得有用的分析见解的绝佳工具。 你可以简单地汇总大量数据并使用这些节点优化你的转换 API 请求，以获得更快、更高效的结果。
此外，转换节点的优势超出了简单的汇总作业。 凭借其强大的功能，你还可以执行数据规范化和过滤，这对于确保你的分析合法可靠至关重要。
简而言之，转换节点对于每个试图充分利用其数据的 Elasticsearch 用户来说都是至关重要的。 如果没有它们，Elasticsearch 将无法构建汇总索引，并且你的 Transform API 请求将变得无效。
但是，你如何验证转换节点是否已正确配置以获得最佳性能？ 解决方案是在 elasticsearch.yml 文件中包含必要的配置。 只需插入这一行：
node.roles: [“transform”, “remote_cluster_client”]你可以确保你的转换节点也是 remote_cluster_client 节点。 如果你在多个集群中处理数据，这一点尤其重要，因为它可以确保你的转换节点完全具备处理手头任务的能力。
你还可以通过更改分片和副本数量等设置来微调转换节点。 这使你能够优化它们的性能并确保它们能够处理最复杂的数据转换。
另一方面，转换节点不应用作协调节点或主节点。 这些节点针对特定任务进行了优化，但你希望转换节点只专注于数据转换。 通过遵循此类准则，你可以确保充分利用转换节点并为数据创建最佳索引。
获取集群的节点角色
那么，我们节点的实际作用是什么？ 你以前见过它，但我没有告诉你。 让我们去 Kibana 看看我们集群中的节点：
GET /_cat/nodes?v
我们对两列特别感兴趣：“node.role” 和 “master”。 第一列描述了每个节点的角色。 因为角色是缩写的，所以 dim 代表 “data”、“ingest” 和 “master”。
这三个角色是我们所有节点的默认角色，除非你修改它们。 因此，可以选择三个节点中的任何一个作为主节点。 在这种情况下，第一个节点被选为主节点，因为它是第一个启动的节点，并且当时没有其他节点可访问。
但是，更改节点角色通常适用于较大的集群，而不是较小的集群。 如果你需要扩大集群吞吐量，例如当消耗量很高时，你也应该这样做。
但是，你通常应该从调整分片和节点的数量开始。
在大型集群中改变角色的另一个原因是更容易了解硬件资源的使用情况并相应地优化集群。
作为一般准则，如果你不知道自己在做什么或没有充分理由，请避免更换角色。 你可以稍后更改你的角色，因此请坚持使用默认设置，直到你需要为止。
只是想让你知道，我给你看这个不是为了让你可以改变角色。 这只是为了让你知道你可以随时修改它们。