0、问题引出

最近陆续收到三个问题：

  • 问题 1：

elasticsearch master 节点报错:

java.lang.Exception: java.lang.OutOfMemoryError: Java heap space

master jvm 配置的 24G 内存都报错, 主节点和协调节点混在一个节点，没有独立协调节点。

  • 问题 2：

我这边后来的业务都是直接数据、协调、主节点混用在一个节点。

有比较大的风险吗？

  • 问题 3：

打扰下，请教一个问题

Elasticsearch 7.10版本，16个数据节点，没有区分角色，16C64G，节点分片均匀。

现象是3天前开始，每到21点开始，其中一个es节点读io比较其他节点高一倍，到凌晨2点又自己恢复了。

看机器带宽也没有明显增加，机器iowait很高，有啥排查思路不？

这三个问题本质都和节点角色划分以及集群规模大了应该独立协调节点、独立主节点有关系。

咱们之前文章专门介绍过集群节点角色划分。今天有必要再结合最新官网 9.X 版本的描述，重新梳理一下。

之前文章和《一本书讲透 Elasticsearch》都有过详细阐述： 

  1. Elasticsearch 8.X 节点角色划分深入详解 

  2. 牛逼！Elasticsearch 集群更换节点角色有了更快的方式 

  3. 刨根问底| Elasticsearch 5.X集群多节点角色配置深入详解

本文带大家一起深入了解Elasticsearch中的不同节点角色及其职责。

这里先简单介绍一下节点的概念：一个节点是Elasticsearch的一个运行实例，可以看作一台服务器（物理或虚拟），负责存储数据并参与集群的各种操作（比如搜索、索引、数据处理等）。

在实际的 Elasticsearch 部署中，节点并不是“一视同仁”的。根据分配的角色，节点可能负责协调集群、存储数据或预处理数据。理解这些节点角色对于设计一个可扩展、高性能且容错的 Elasticsearch 集群至关重要。

在这篇文章中，我们将详细讲解五种节点角色及其职责，并通过通俗易懂的例子帮助大家快速掌握这些概念。

文章内容包括：

  1. 主节点（Master Node）
  2. 数据节点（Data Node）
  3. 协调节点（Coordinating Only Node）
  4. 摄入节点（Ingest Node）
  5. 投票节点（Voting Node）

好了，废话不多说，让我们直接进入正题！

1. 主节点（Master Node）

主节点就 像Elasticsearch 集群的“大脑”或“管理者”。它的主要职责是维护整个集群的健康和组织，而不是直接存储数据或处理搜索查询（除非它同时被配置为其他角色）。

1.1 主节点做什么？——用途

  • 跟踪节点：知道集群中有哪些节点在运行。
  • 管理索引：负责创建或删除索引。
  • 分配数据分片：决定数据（分片）存储在哪些节点上。
  • 处理集群变化：当有节点加入或退出时，更新集群状态。

1.2 主节点示例

假设我们的Elasticsearch集群有3个节点：

  • 节点A
  • 节点B
  • 节点C

其中节点A是主节点。

1.2.1 场景1：创建新索引

当我们发送请求创建一个新索引（比如“products”）时：

  1. 主节点A接收请求。

  2. 主节点决定：

  • 创建多少个分片（shards）。
  • 将这些分片分配到哪些节点（比如，主分片放在节点B，副本分片放在节点C）。

  • 主节点A通知其他节点关于新索引和分片的信息。

  • 主节点A本身并不存储数据（除非它也被配置为数据节点），只是负责指挥。

    • 1.2.2 场景2：节点故障

    如果节点B宕机：

    1. 主节点A检测到节点B不可用。

    2. 主节点重新分配节点B上的分片到其他节点（比如节点C）。

    3. 通知集群中所有节点更新状态，确保集群保持平衡和可用。

    1.3 如何配置主节点？

    在elasticsearch.yml配置文件中，设置如下：

    node:
      name:master-node-1# 节点名称
    master:true         # 设置为true，表示这是主节点
    data:false          # 不存储数据
    ingest:false        # 不处理数据摄入
    cluster:
    name:my-cluster
    initial_master_nodes:["node-A"]# 集群首次启动时指定的主节点
    discovery:
    seed_hosts:["node-A","node-B","node-C"]# 用于发现其他节点的列表

    如果想让主节点同时作为数据节点，只需将data: true即可。但大规模多节点集群务必慎重，最好独立节点角色。

    2. 数据节点（Data Node）

    数据节点是 Elasticsearch 的“存储主力”。它负责存储索引中的数据（以分片的形式），并处理数据的搜索和索引操作。

    2.1 举个例子

    举个餐厅的例子，厨师就是数据节点。

    服务员（协调节点）把订单交给厨师，厨师负责烹饪（存储和处理数据），然后把成品菜（查询结果）交给服务员。

    2.2 如何配置数据节点？

    在elasticsearch.yml中，设置：

    node:
      data: true

    2.3 一个常见问题

    如果集群只有一个节点，且只配置为数据节点，它能处理用户搜索请求吗？🤔

    答案是：不能。

    如果只有一个节点，且只配置为数据节点，它无法处理用户请求，因为协调工作需要其他角色。

    如果是单节点集群，建议使用默认配置（不显式设置任何角色），这样节点会同时承担所有角色（协调、主节点、数据节点等）。

    3. 协调节点（Coordinating Only Node）

    协调节点就像 Elasticsearch 集群中的“交通指挥员”。

    Elasticsearch 集群直接数据、协调、主节点混用在一个节点，有比较大的风险吗？

    它不存储数据，也不是主节点，而是负责接收用户的请求（比如搜索或索引），并将这些请求分发到正确的节点。

    3.1 协调节点做什么？

    1. 接收用户请求（比如搜索或存储数据）。

    2. 将请求转发给相关的数据节点。

    3. 收集数据节点的响应。

    4. 将结果汇总后返回给用户。

    协调节点不执行存储或搜索的“重（读音 zhong）活”，只负责管理和分发任务。

    3.2 举个例子

    想象我们在一家餐厅：

    1. 我们向服务员（协调节点）点单，点了三道菜。

    2. 服务员把订单分发给厨房的三个厨师（数据节点），每个厨师负责一道菜。

    3. 厨师做好菜后，服务员把三道菜收集起来，端到我们面前。

    服务员并不自己做菜，只是负责沟通。这就是协调节点的角色。

    3.3 如何配置协调节点？

    默认情况下，如果以下配置都设置为false，节点就是协调节点：

    node:
      master: false
      data: false
      ingest: false

    4. 摄入节点（Ingest Node）

    摄入节点是 Elasticsearch 中的“数据预处理器”。

    它在数据被索引（类似插入数据库）之前，对数据进行清洗、转换或丰富处理。

    4.1 有点抽象？来看个例子

    假设我们去餐厅点菜，但我们说得很快，还夹杂了不同的语言。

    餐厅经理（摄入节点）会：

    1. 听清楚我们的订单。

    2. 修正拼写或语言错误。

    3. 确认订单内容，添加下单时间等信息。

    4. 将整理好的订单交给厨房（数据节点）。

    同样，在 Elasticsearch 中，摄入节点会处理原始数据，比如清洗、格式化或添加额外信息，然后将处理后的数据发送到索引存储。

    4.2 工作流程

    1. 用户发送请求到Elasticsearch，请求先到达协调节点。

    2. 如果请求中包含管道（pipeline）属性，协调节点将数据转发到摄入节点。

    3. 摄入节点根据管道规则处理数据（比如格式化、添加字段）。

    4. 处理后的数据返回给协调节点，再由协调节点发送到数据节点存储。

    4.3 如何配置摄入节点？

    在elasticsearch.yml中，设置：

    node:
      ingest: true

    关于管道（pipeline）的具体配置，比如如何定义数据转换规则，可以参考咱们之前的公众号文章。

    5. 投票节点（Voting Node）

    投票节点参与主节点的选举过程，帮助维持集群的稳定性。仅投票主节点候选是参与主节点选举但永远不会成为主节点的节点。它们的角色是在选举过程中提供投票，特别是在需要打破平局（tiebreaker）时非常有用。

    Elasticsearch 通过多数投票机制选择主节点。

    实话说，这个咱们用的真不太多。

    • 一方面原因，早期版本没有这种类型节点角色；

    • 另一方面原因，集群规模还远没有那么大。

    https://www./docs/deploy-manage/distributed-architecture/clusters-nodes-shards/node-roles

    5.1 为什么需要投票节点？

    在一个大型集群中，我们可能不希望所有节点都参与主节点选举（会增加复杂性）。

    投票节点专门负责投票，确保主节点选举顺利进行。

    5.2 如何配置投票节点？

    在elasticsearch.yml中，设置：

    node:
      roles: [master, voting_only]

    5.3 投票过程示例

    假设集群有 7 个节点，其中 3 个是主节点候选（Node-A、Node-B、Node-C）， 4 个是投票节点（Node-D、Node-E、Node-F、Node-H）：

    1. 投票节点投票：

    • Node-D、Node-E投给Node-A。
    • Node-F投给Node-B。
    • Node-H投给Node-C。

  • Node-A获得最多票（2票），成为主节点。

    • 5.4 投票依据是什么？

    投票节点会根据以下因素选择主节点：

    • 响应速度：哪个节点响应最快。
    • 健康状态：节点是否过载或断连。
    • 网络稳定性：连接是否可靠。

    5.5 什么时候触发主节点选举？

    • 集群启动时。
    • 当前主节点失败。
    • 有新节点加入集群。

    6、总结

    以读者问题引出，让大家提前关注到 Elasticsearch 角色划分的重要性。

    通过这篇文章，我们详细介绍了Elasticsearch的五种节点角色及其职责：

    1. 主节点：管理集群，协调分片分配。
    2. 数据节点：存储和处理数据。
    3. 协调节点：处理用户请求，分发任务并汇总结果。
    4. 摄入节点：预处理数据，清洗或丰富数据。
    5. 投票节点：参与主节点选举，确保集群稳定。

    如果有任何疑问，欢迎留言讨论。

    感谢大家的阅读，期待在下一篇文章中继续探讨Elasticsearch的更多奥秘！