3. ES 集群部署：单机部署、多节点集群搭建、集群健康检查与监控

好，咱们进入第三章。这一章我打算聊聊 ES 集群怎么搭起来。

说实话，很多新手一上来就搞集群，结果连单机都没跑明白。我个人习惯是：先单机，再集群，最后才是监控。一步步来，稳得很。

3.1 单机部署：别小看这一步

单机部署听起来简单，但坑不少。我记得第一次部署 ES 时，直接解压就启动，结果报了一堆错。

为什么？因为 ES 对系统配置有要求。你想想看，一个搜索引擎，底层要操作文件、管理内存，系统不给权限怎么行？

核心步骤：

  1. 下载解压：从官网下载 tar 包，解压到指定目录。
  2. 配置 elasticsearch.yml：
# 单机模式关键配置
cluster.name: my-es-cluster
node.name: node-1
path.data: /var/data/elasticsearch
path.logs: /var/log/elasticsearch
network.host: 0.0.0.0
http.port: 9200
discovery.type: single-node

这里有个细节：discovery.type: single-node 一定要加。不加的话，ES 会尝试发现其他节点，单机模式下会一直报错。

⚠️ 注意： 千万别用 root 用户启动 ES！ES 出于安全考虑，禁止 root 直接运行。我当初就吃过这个亏，折腾了半天才发现是用户权限问题。

启动命令：

# 创建专用用户
useradd esuser
chown -R esuser:esuser /path/to/elasticsearch

# 切换用户启动
su esuser
./bin/elasticsearch -d -p pid

启动后，访问 http://localhost:9200，看到类似下面的 JSON 就说明成功了：

{
  "name" : "node-1",
  "cluster_name" : "my-es-cluster",
  "cluster_uuid" : "xxxx",
  "version" : { "number" : "7.17.0" }
}

3.2 多节点集群搭建：从单兵到军团

单机跑通了，接下来就是集群。说白了，就是把多个 ES 实例连起来，形成一个整体。

我建议至少 3 个节点。为什么？因为 ES 的选举机制要求半数以上节点在线才能选出 master。3 节点挂 1 个还能跑，2 节点挂 1 个就瘫了。

集群搭建步骤：

  1. 准备 3 台机器（或 3 个容器），IP 分别为 192.168.1.10、192.168.1.11、192.168.1.12。
  2. 每台机器上安装 ES，配置如下：
# 节点 1 配置 (node-1)
cluster.name: production-cluster
node.name: node-1
node.roles: [ master, data, ingest ]
network.host: 192.168.1.10
discovery.seed_hosts: ["192.168.1.10", "192.168.1.11", "192.168.1.12"]
cluster.initial_master_nodes: ["node-1", "node-2", "node-3"]

# 节点 2 配置 (node-2) - 只需改 node.name 和 network.host
node.name: node-2
network.host: 192.168.1.11

# 节点 3 配置 (node-3)
node.name: node-3
network.host: 192.168.1.12

这里有个关键点：cluster.initial_master_nodes 只在第一次启动时有用。它告诉集群：这几个节点是初始 master 候选。一旦集群形成，这个配置就没用了。

💡 我的经验： 生产环境建议把 master 和 data 角色分开。专门搞 3 个 master 节点（不存数据），再加几个 data 节点。这样集群更稳定。我曾经遇到 data 节点压力大导致 master 也跟着挂的情况，分开后就再没出过问题。

启动顺序： 先启动 master 节点，再启动 data 节点。每个节点启动后，看日志有没有报错。等所有节点都起来了，用下面命令检查：

curl -X GET "http://192.168.1.10:9200/_cat/nodes?v"

你会看到类似这样的输出：

ip             heap.percent ram.percent cpu load_1m load_5m load_15m node.role master name
192.168.1.10           23          89   2    0.12    0.15     0.18 mdi       *      node-1
192.168.1.11           21          87   1    0.08    0.10     0.12 mdi       -      node-2
192.168.1.12           22          88   3    0.15    0.18     0.20 mdi       -      node-3

看到 master 列有个 * 了吗？那就是当前的主节点。

3.3 集群健康检查：你的集群还好吗？

集群搭好了，怎么知道它健不健康？ES 提供了几个 API，我平时用得最多的是 _cluster/health。

curl -X GET "http://192.168.1.10:9200/_cluster/health?pretty"

返回结果：

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

状态解读：

状态 含义 怎么办？
green 所有主分片和副本分片都正常 啥也不用干，偷着乐吧
yellow 主分片正常，但有些副本分片没分配 检查节点数是否足够，或者磁盘空间
red 有主分片丢失 赶紧查！数据可能丢了
🔴 重点： 生产环境必须保持 green 状态。yellow 可以临时容忍，但 red 绝对不能接受。我见过有人 yellow 状态拖了一周，结果节点挂了直接变 red，数据恢复花了两天。

3.4 监控：别等出事了才想起来

集群跑起来了，监控必须跟上。我常用的监控手段有 3 种：

1. 命令行快速检查

# 查看节点状态
curl -s http://localhost:9200/_cat/nodes?v

# 查看索引健康
curl -s http://localhost:9200/_cat/indices?v

# 查看分片分配
curl -s http://localhost:9200/_cat/shards?v

2. 关键指标监控

我个人重点关注这几个指标：

  • JVM heap 使用率：超过 85% 就要警惕了，GC 会变得频繁
  • 磁盘使用率：超过 85% 时 ES 会自动禁止分配分片
  • 查询延迟：p99 超过 1 秒说明有问题
  • 线程池队列：search 或 write 线程池队列堆积，说明处理不过来了

3. 使用监控工具

小集群用 elasticsearch-head 就够了，浏览器里就能看。大集群我推荐 Prometheus + Grafana，ES 官方提供了 exporter。

💡 避坑指南： 我曾经遇到一个 case，集群状态一直是 green，但查询特别慢。后来发现是某个节点磁盘 I/O 打满了。所以光看集群状态不够，还得看每个节点的系统指标。建议把 CPU、内存、磁盘 I/O、网络都监控起来。

最后说一句：监控不是为了好看，是为了在出问题前发现苗头。我每天上班第一件事就是看监控大盘，花 5 分钟扫一眼，心里就有底了。

好了，这一章就到这里。下一章咱们聊聊 ES 的索引管理和分片策略，那可是调优的重头戏。

← 上一章 📖 返回目录 下一章 →