图解计算机基础

Appearance

Elasticsearch 集群部署怎么做？ ​

这篇讲 ES 集群部署的基础思路。不同版本的配置项会有差异，实际部署时要以当前版本官方文档为准，但核心原则是稳定的：节点角色清晰、发现配置正确、内存和磁盘合理、不要把 ES 暴露在不安全网络里。

单机和集群有什么区别？ ​

单机 ES 适合本地学习和开发测试：

text
一个节点 = 一个 ES 进程

生产环境通常是多节点集群：

text
多个节点 -> 一个 cluster
index -> 多个 shard -> 分布在多个 node

多节点的好处是：

  • 数据可以分散到多台机器。
  • 节点故障时副本可以接管。
  • 搜索和聚合可以并行执行。
  • 可以按角色拆分 master、data、ingest、coordinating 节点。

节点角色有哪些？ ​

常见角色：

  • master：参与 master 选举，管理集群状态。
  • data：存储分片数据，处理搜索、聚合、写入。
  • ingest：执行 ingest pipeline，做写入前预处理。
  • coordinating：协调节点，负责转发请求和合并结果。所有节点默认都能协调。
  • data_hot、data_warm、data_cold：冷热数据分层角色。

小集群可以混合角色，比如 3 个节点都兼任 master 和 data。

大一些的生产集群建议拆出专用 master 节点，避免数据节点高负载影响集群管理。

最小生产集群建议 ​

如果是有可用性要求的生产环境，至少 3 个 master-eligible 节点。

原因是 master 选举需要多数派。3 个节点允许坏 1 个还能选出 master；2 个节点很容易出现脑裂或无法选主的问题。

小型集群示意：

text
node-1: master + data + ingest
node-2: master + data + ingest
node-3: master + data + ingest

中大型集群示意：

text
master-1: master
master-2: master
master-3: master
data-1: data_hot
data-2: data_hot
data-3: data_warm
coordinating-1: coordinating only

关键配置示例 ​

一个简化的 elasticsearch.yml：

yaml
cluster.name: cs-es
node.name: node-1
node.roles: [ master, data, ingest ]

path.data: /data/elasticsearch
path.logs: /var/log/elasticsearch

network.host: 10.0.0.11
http.port: 9200
transport.port: 9300

discovery.seed_hosts: ["10.0.0.11:9300", "10.0.0.12:9300", "10.0.0.13:9300"]
cluster.initial_master_nodes: ["node-1", "node-2", "node-3"]

几个点要注意：

  • cluster.name 相同的节点才会加入同一集群。
  • node.name 每个节点要唯一。
  • network.host 不要随便写 0.0.0.0 暴露到不安全网络。
  • discovery.seed_hosts 写候选节点地址。
  • cluster.initial_master_nodes 只用于首次启动集群引导，集群形成后不要随意修改。

JVM 堆内存怎么配？ ​

ES 很依赖文件系统缓存，所以 JVM heap 不是越大越好。

常见建议：

  • heap 设置为机器内存的一半左右。
  • 不超过压缩对象指针阈值，通常不要超过 31GB。
  • -Xms 和 -Xmx 设置相同。

示例：

text
-Xms16g
-Xmx16g

如果机器 32GB 内存，给 ES heap 16GB，剩下留给文件系统缓存，通常比把 heap 撑满更好。

系统参数要调什么？ ​

Linux 上常见调整：

bash
sysctl -w vm.max_map_count=262144

文件句柄和进程限制也要足够：

text
nofile 65535
nproc 4096

还要注意：

  • 关闭 swap，或者至少避免 ES 使用 swap。
  • 数据盘优先使用 SSD。
  • 数据目录和日志目录放在容量充足的磁盘。
  • 时间同步要正常，避免节点时间漂移。

分片和副本怎么规划？ ​

创建索引时要规划主分片和副本：

http
PUT /articles
{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 1
  }
}

主分片创建后不能直接修改，副本数可以动态调整。

分片规划要看：

  • 数据总量。
  • 每日增长量。
  • 查询并发。
  • 节点数量。
  • 是否按时间滚动索引。

不要为了“并行”盲目创建大量分片。分片太多会让集群状态、内存、文件句柄、查询 fan-out 成本都变高。

安全配置不能忽略 ​

生产环境至少要做到：

  • ES HTTP 端口不暴露公网。
  • 开启认证。
  • 开启 TLS，尤其是跨机器通信和公网访问场景。
  • 使用最小权限账号。
  • 禁止应用使用超级管理员账号。
  • 备份脚本和同步程序不要硬编码长期高权限密码。

如果是 Elastic Stack 新版本，安全能力通常默认可用。部署后要为 Kibana、应用服务、同步任务分别创建权限合适的账号或 API Key。

部署后怎么检查？ ​

查看集群健康：

http
GET /_cluster/health

查看节点：

http
GET /_cat/nodes?v

查看分片：

http
GET /_cat/shards?v

查看索引：

http
GET /_cat/indices?v

健康状态含义：

  • green：主分片和副本分片都正常。
  • yellow：主分片正常，至少有副本未分配。
  • red：至少有主分片未分配，部分数据不可用。

单节点且设置 1 个副本时，yellow 是正常现象，因为副本不能和主分片放在同一个节点上。

常见部署坑 ​

  1. 单节点生产还设置副本，长期 yellow 却不知道原因。
  2. 两节点集群没有合理选主配置，故障时不可用。
  3. 主分片数量随手设置很大，后面集群状态膨胀。
  4. JVM heap 设置过大，文件系统缓存不足，查询反而慢。
  5. 数据盘快满才处理，导致分片无法分配。
  6. ES 暴露公网且没有认证。
  7. 所有应用都连 data 节点做大查询，协调压力影响数据节点。
  8. 没有快照备份，误删索引后无法恢复。

滚动重启怎么做？ ​

集群升级配置或重启节点时，尽量滚动操作：

  1. 暂停或降低分片自动迁移，避免节点刚停就大量搬分片。
  2. 停一个节点。
  3. 升级或修改配置。
  4. 启动节点，等待它加入集群。
  5. 确认集群状态恢复。
  6. 再处理下一个节点。

具体 API 会随版本变化，操作前要查当前版本文档，并准备回滚方案。

小结 ​

ES 集群部署的关键不是把进程跑起来，而是让它长期稳定运行：

  • 至少 3 个 master-eligible 节点承载生产可用性。
  • 根据规模决定是否拆分专用 master、data、coordinating 节点。
  • heap 留一半内存给文件系统缓存。
  • 分片数量提前规划，不要过度分片。
  • 安全、备份、监控和磁盘水位要从第一天就配置。

部署前把这些基础打好，后面查询优化和数据增长才有空间。