Elasticsearch 节点与集群的原理、类型、配置、运维与最佳实践

原创已于 2025-08-17 02:50:23 修改 · 1.2k 阅读

24 ·

CC 4.0 BY-SA版权

文章标签：

#elasticsearch #节点 #集群 #学习

于 2025-08-17 02:49:41 首次发布

搜索引擎专栏收录该内容

55 篇文章

订阅专栏

在 Elasticsearch 中，节点（Node） 和 集群（Cluster） 是其分布式架构的基石。理解它们的组成、角色、通信机制与管理方式，是构建稳定、高性能搜索系统的前提。

本文将全面详解 Elasticsearch 节点与集群的原理、类型、配置、运维与最佳实践。

一、什么是集群（Cluster）？

集群（Cluster） 是由一个或多个 Elasticsearch 节点组成的逻辑整体，共同存储数据、提供搜索服务。

所有节点通过 集群名称（cluster.name） 识别是否属于同一集群；
集群对外表现为一个整体，客户端无需关心数据在哪个节点；
集群自动管理数据分布、故障转移、负载均衡。

# elasticsearch.yml
cluster.name: my-prod-cluster

✅ 一个集群中可以有多个索引，每个索引的数据分布在多个节点上。

二、什么是节点（Node）？

节点（Node） 是一个运行 Elasticsearch 服务的实例，是集群的物理组成单元。

每个节点启动时加入指定名称的集群；
节点通过 发现机制（Discovery） 找到其他节点并组成集群；
节点可以承担不同角色（如主节点、数据节点等）。

# elasticsearch.yml
node.name: es-data-01

三、节点类型（Node Roles）

从 7.0 开始，Elasticsearch 使用 显式角色划分（替代旧的 node.master, node.data 等配置）：

角色	配置项	说明
主节点候选（master-eligible）	`node.roles: [ master ]`	参与主节点选举，管理集群状态
数据节点（data）	`node.roles: [ data ]`	存储分片，执行 CRUD、聚合等操作
协调节点（coordinating）	默认开启	接收请求，转发到其他节点，合并结果
ingest 节点	`node.roles: [ ingest ]`	执行 `ingest pipeline` 预处理数据
远程客户端节点（remote_cluster_client）	`node.roles: [ remote_cluster_client ]`	用于跨集群搜索
ml 节点	`node.roles: [ ml ]`	运行机器学习任务
transform 节点	`node.roles: [ transform ]`	执行 transform 作业

✅ 一个节点可拥有多个角色，但生产环境建议角色分离。

1. 主节点候选节点（Master-Eligible Node）

负责管理集群范围的状态：如索引创建、删除、分片分配；
不存储数据（建议）；
必须有奇数个（3、5）以避免脑裂；

配置示例：

node.roles: [ master ]
node.master: true  # 7.x 仍兼容

2. 数据节点（Data Node）

存储主分片和副本分片；
承担搜索、聚合、写入等重负载操作；
需要大容量磁盘、高内存、高性能 CPU；
配置示例：
```
node.roles: [ data ]
```

3. 协调节点（Coordinating Node）

不显式配置，所有节点默认都是协调节点；
接收客户端请求，将查询广播到相关分片，合并结果；
高并发场景可部署专用协调节点，减轻数据节点压力；
特点：低 CPU、低内存、无磁盘。

4. Ingest 节点

在索引前执行 pipeline 处理数据（如 grok 解析、字段重命名）；
减轻客户端或数据节点压力；
配置：
```
node.roles: [ ingest ]
```

5. 专用节点组合示例（生产推荐）

节点类型	数量	配置建议
Master-Eligible	3	16GB RAM, 4CPU, SSD, 仅运行 master 角色
Data Node	N	64GB+ RAM, 多核 CPU, 大容量磁盘
Coordinating Only	M	16GB RAM, 4CPU, 无磁盘，仅协调
Ingest Node	K	32GB RAM, 高 CPU，用于日志解析

四、集群发现与通信

1. 发现机制（Discovery）

节点启动时通过 seed hosts 发现集群：

# elasticsearch.yml
discovery.seed_hosts: ["es-node1:9300", "es-node2:9300"]
cluster.initial_master_nodes: ["es-node1", "es-node2", "es-node3"]

9300 是 transport port（节点间通信）；
cluster.initial_master_nodes 仅在首次启动时使用，防止脑裂。

2. 主节点选举

使用 Zen Discovery（7.x） 或 Coordination Layer（8.x）；
通过投票选出主节点；
主节点负责维护集群状态（Cluster State）；
集群状态包括：索引元数据、分片分配、节点信息等。

3. 集群状态（Cluster State）

存储在内存中，不持久化到磁盘；
由主节点管理，变更时广播给所有节点；
过大的集群状态（如太多索引/字段）会导致性能下降。

五、集群健康状态

通过 _cluster/health 查看集群整体状态：

GET /_cluster/health

返回示例：

{
  "cluster_name": "my-prod-cluster",
  "status": "green",
  "timed_out": false,
  "number_of_nodes": 5,
  "number_of_data_nodes": 3,
  "active_primary_shards": 10,
  "active_shards": 20,
  "relocating_shards": 0,
  "initializing_shards": 0,
  "unassigned_shards": 0,
  "delayed_unassigned_shards": 0
}

状态含义：

状态	说明
🟢 `green`	所有主分片和副本都正常分配
🟡 `yellow`	主分片正常，副本未全部分配（常见于副本数 > 节点数）
🔴 `red`	有主分片未分配，部分数据不可用

✅ 生产环境应尽量保持 green。

六、节点管理命令

1. 查看节点信息

GET /_cat/nodes?v
GET /_nodes
GET /_nodes/stats

输出示例：

ip          heap.percent ram.percent cpu load_1m node.role   master name
10.0.1.101  45           70          8   0.15    dilm        *      es-data-01
10.0.1.102  12           50          2   0.05    m           -      es-master-01

2. 关闭节点（滚动升级）

PUT /_cluster/settings
{
  "transient": {
    "cluster.routing.allocation.enable": "primaries"
  }
}

然后安全关闭节点。

七、常见问题与解决方案

Q1：脑裂（Split Brain）如何避免？

现象：两个主节点同时存在，导致数据不一致。

解决方案：

使用奇数个 master-eligible 节点（3、5）；
设置 discovery.zen.minimum_master_nodes（7.x）或使用默认协调层（8.x）；
避免网络分区。

Q2：节点离线怎么办？

检查网络、防火墙、JVM 是否 OOM；
查看日志：logs/elasticsearch.log；
使用 GET /_cluster/allocation/explain 分析分片未分配原因。

Q3：如何扩容？

增加数据节点：

配置新节点的 cluster.name 和 discovery.seed_hosts；
启动，自动加入集群；
集群自动重新平衡分片。

增加主节点：

修改 cluster.initial_master_nodes（仅首次）；
建议提前规划，避免频繁变更。

Q4：节点负载过高？

检查 GET /_nodes/stats 中的 CPU、内存、磁盘、线程池；
优化查询（避免 wildcard、nested 查询）；
增加副本分片提升读吞吐；
拆分大索引。

八、集群安全配置

1. 启用安全功能

xpack.security.enabled: true
xpack.security.transport.ssl.enabled: true

2. 用户与角色

创建专用用户：

POST /_security/user/analytics_user
{
  "password": "pass",
  "roles": [ "kibana_reader", "viewer" ]
}

九、监控与运维建议

工具	用途
Kibana Stack Monitoring	可视化集群状态、节点负载、索引性能
Prometheus + Grafana	自定义监控大盘
Elastic Agent + Metricbeat	采集节点指标
Slow Log	定位慢查询
_cluster/allocation/explain	排查分片分配问题

十、最佳实践总结 ✅

项目	建议
主节点	3 个专用节点，奇数，不存储数据
数据节点	根据容量规划，SSD + 大内存
角色分离	生产环境避免“全能节点”
发现配置	正确设置 `seed_hosts` 和 `initial_master_nodes`
集群名称	不同环境使用不同名称（prod/staging/dev）
监控	必须监控节点健康、磁盘、JVM
备份	定期 snapshot 到共享存储或云存储

十一、扩展建议

场景	建议方案
多可用区部署	使用 `node.attr.zone` 实现机架感知
跨集群搜索（CCS）	配置 `remote clusters`
热温架构	数据节点分 hot/warm 角色
Serverless / 云托管	使用 Elastic Cloud、AWS OpenSearch