上一篇【第58篇】Elasticsearch生产集群监控——系统指标与告警配置
下一篇【第60篇】Elasticsearch从入门到精通——系列总结与学习路径推荐
摘要
高可用是生产环境Elasticsearch集群的核心要求。单节点部署无法满足数据可靠性和服务连续性的需求，多节点集群的正确规划和配置是保障系统稳定运行的基础。本文将从节点角色规划入手，讲解专用Master节点、Data节点和Coordinating节点的职责划分与资源分配策略，然后深入介绍跨可用区部署的配置方法、索引生命周期管理（ILM）的完整实践、数据快照备份与恢复的操作流程，以及滚动重启集群的标准化步骤。掌握这些实践，你将能够设计和运维一套满足企业级高可用要求的Elasticsearch集群。
生产级节点角色规划
Elasticsearch节点角色
Elasticsearch集群中的节点可以承担不同的角色，每个角色有不同的职责和资源需求：
| 角色 | 职责 | 资源需求 | 数量建议 |
|---|---|---|---|
| Master-eligible | 维护集群状态、管理分片分配、处理节点加入/退出 | CPU中等、内存低（堆2-4GB）、磁盘低 | 至少3台（奇数） |
| Data | 存储数据、执行CRUD和搜索操作 | CPU高、内存高（堆30GB）、磁盘大 | 按数据量规划 |
| Coordinating | 分发搜索请求、合并结果、不存储数据 | CPU高、内存中等（堆8-16GB）、磁盘低 | 可选，1-3台 |
| Ingest | 预处理文档（Pipeline） | CPU高、内存中等 | 可选 |
推荐集群拓扑
对于生产环境，推荐以下最小高可用拓扑：
┌─────────────────┐ │ Load Balancer │ └────────┬────────┘ │ ┌─────────────────┼─────────────────┐ │ │ │ ┌──────▼──────┐ ┌─────▼──────┐ ┌───────▼──────┐ │Coordinating │ │Coordinating│ │ Coordinating │ │ Node-1 │ │ Node-2 │ │ Node-3 │ └─────────────┘ └────────────┘ └──────────────┘ │ │ │ ┌──────▼──────┐ ┌─────▼──────┐ ┌───────▼──────┐ │ Master │ │ Master │ │ Master │ │ Node-1 │ │ Node-2 │ │ Node-3 │ └─────────────┘ └────────────┘ └──────────────┘ │ │ │ ┌──────▼──────┐ ┌─────▼──────┐ ┌───────▼──────┐ │ Data │ │ Data │ │ Data │ │ Node-1 │ │ Node-2 │ │ Node-3 │ └─────────────┘ └────────────┘ └──────────────┘节点角色配置
# Master专用节点配置（elasticsearch.yml）node.roles:[master]node.name:master-1cluster.name:my-clusterdiscovery.seed_hosts:["master-2","master-3"]cluster.initial_master_nodes:["master-1","master-2","master-3"]# Master节点不需要大数据盘path.data:/data/es/masterpath.logs:/var/log/elasticsearch# 堆内存不宜过大# -Xms4g -Xmx4g# Data专用节点配置（elasticsearch.yml）node.roles:[data,data_content]node.name:data-1cluster.name:my-clusterdiscovery.seed_hosts:["master-1","master-2","master-3"]# Data节点需要大磁盘path.data:/data/es/datapath.logs:/var/log/elasticsearch# 堆内存建议不超过30GB# -Xms30g -Xmx30g# Coordinating专用节点配置（elasticsearch.yml）node.roles:[]node.name:coord-1cluster.name:my-clusterdiscovery.seed_hosts:["master-1","master-2","master-3"]# Coordinating节点需要较多CPU# -Xms8g -Xmx8g混合角色 vs 专用角色
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 全部混合 | 部署简单，节省资源 | Master不稳定影响数据 | 开发/测试环境 |
| Master专用 | 集群状态稳定 | 多3个节点（资源开销小） | 生产环境必须 |
| Data专用 | 数据节点可独立扩缩 | 部署稍复杂 | 生产环境推荐 |
| 全角色分离 | 各节点各司其职 | 节点数多，部署复杂 | 大规模生产集群 |
跨可用区部署
可用区感知配置
跨可用区（Availability Zone）部署可以防止单个机房或可用区故障导致整个集群不可用。Elasticsearch通过cluster.routing.allocation.awareness.attributes实现可用区感知。
// 设置感知属性PUT_cluster/settings{"persistent":{"cluster.routing.allocation.awareness.attributes":"zone"}}# 每个节点的elasticsearch.yml中添加zone属性# Zone A 的节点node.attr.zone:zone-a# Zone B 的节点node.attr.zone:zone-b# Zone C 的节点node.attr.zone:zone-c可用区感知的分片分配
启用可用区感知后，Elasticsearch会确保每个分片的主分片和副本分布在不同可用区：
Zone-A Zone-B Zone-C ├── master-1 ├── master-2 ├── master-3 ├──>强制感知配置默认情况下，如果某个可用区的节点全部故障，Elasticsearch会将其分片重新分配到其他可用区。如果希望严格执行分片分布（即使某个可用区不可用也不重新分配），可以使用force配置：
PUT_cluster/settings{"persistent":{"cluster.routing.allocation.awareness.attributes":"zone","cluster.routing.allocation.awareness.force.zone.values":"zone-a,zone-b,zone-c"}}
注意：使用force配置后，如果某个可用区完全不可用，对应的主分片将无法被恢复，集群状态会变为RED。仅在极端高可用场景下使用。
索引生命周期管理 ILM
ILM 四阶段策略
索引生命周期管理（Index Lifecycle Management, ILM）是Elasticsearch内置的自动化索引管理工具，定义了索引从创建到删除的完整生命周期。
┌─────────┐ 时间/大小/文档数 ┌─────────┐ 时间/大小/文档数 ┌─────────┐ 时间/大小/文档数 ┌─────────┐ │ HOT │ ─────────────────────→│ WARM │ ─────────────────────→│ COLD │ ─────────────────────→│ DELETE │ │ │ rollover触发 │ │ 迁移触发 │ │ 迁移触发 │ │ │高频读写 │ │低频读 │ │极低频读 │ │删除数据 │ │全副本 │ │缩减副本 │ │无副本 │ │释放空间 │ │高性能SSD│ │标准SSD │ │HDD/S3 │ │ │ └─────────┘ └─────────┘ └─────────┘ └─────────┘
完整ILM策略配置
// 创建ILM策略PUT_ilm/policy/logs_policy{"policy":{"phases":{"hot":{"min_age":"0ms","actions":{"rollover":{"max_primary_shard_size":"50gb","max_age":"7d","max_docs":50000000},"set_priority":{"priority":100}}},"warm":{"min_age":"30d","actions":{"allocate":{"number_of_replicas":1,"require":{"data_tier":"warm"}},"shrink":{"number_of_shards":1},"forcemerge":{"max_num_segments":1},"set_priority":{"priority":50}}},"cold":{"min_age":"90d","actions":{"allocate":{"number_of_replicas":0,"require":{"data_tier":"cold"}},"set_priority":{"priority":0},"searchable_snapshot":{"snapshot_repository":"my_backup_repo"}}},"delete":{"min_age":"365d","actions":{"delete":{"delete_searchable_snapshot":true}}}}}}
ILM与索引模板关联
// 创建使用ILM策略的索引模板PUT_index_template/logs_template{"index_patterns":["logs-*"],"template":{"settings":{"index.lifecycle.name":"logs_policy","index.lifecycle.rollover_alias":"logs","index.number_of_shards":3,"index.number_of_replicas":1,"number_of_routing_shards":30}}}// 创建初始索引和别名PUTlogs-000001{"aliases":{"logs":{"is_write_index":true}}}
ILM阶段配置详解
阶段 触发条件 可执行Action 说明 Hot 索引创建时进入 rollover, set_priority, allocate 高频读写阶段 Warm min_age时间到 allocate, shrink, forcemerge, readonly, set_priority 数据频率降低 Cold min_age时间到 allocate, searchable_snapshot, set_priority 冷数据存储 Delete min_age时间到 delete, delete_searchable_snapshot 数据清理
监控ILM状态
# 查看所有ILM策略curl-XGET"localhost:9200/_ilm/policy?pretty"# 查看特定索引的ILM状态curl-XGET"localhost:9200/logs-000001/_ilm?pretty"# 查看ILM执行历史curl-XGET"localhost:9200/_ilm/explain/logs-*?pretty"
数据快照备份
快照仓库配置
// 共享文件系统仓库（所有节点都可访问的共享存储）PUT_snapshot/my_backup_repo{"type":"fs","settings":{"location":"/mnt/shared/backup/elasticsearch","compress":true,"max_snapshot_bytes_per_sec":"100mb","max_restore_bytes_per_sec":"200mb"}}
# 在所有节点的elasticsearch.yml中注册仓库路径path.repo:["/mnt/shared/backup/elasticsearch"]
// S3仓库配置（推荐用于云端部署）PUT_snapshot/s3_backup_repo{"type":"s3","settings":{"bucket":"my-es-backups","region":"us-east-1","access_key":"YOUR_ACCESS_KEY","secret_key":"YOUR_SECRET_KEY","compress":true,"server_side_encryption":true}}// HDFS仓库配置PUT_snapshot/hdfs_backup_repo{"type":"hdfs","settings":{"uri":"hdfs://namenode:8020/es_backup","path":"snapshots","compress":true}}
快照仓库对比
仓库类型 适用场景 优点 缺点 fs（文件系统） 本地/共享存储 简单、成本低 需要共享文件系统 S3 AWS云环境 高可靠、无限容量 需要网络带宽 HDFS 大数据生态集成 高吞吐 HDFS运维复杂 Azure Blob Azure云环境 云原生集成 仅Azure GCS GCP云环境 云原生集成 仅GCP
创建和管理快照
// 创建快照（备份所有索引）PUT_snapshot/my_backup_repo/snapshot_20260522{"indices":"*","ignore_unavailable":true,"include_global_state":false}// 备份特定索引PUT_snapshot/my_backup_repo/partial_snapshot{"indices":"logs-2026-05-*,events-2026-05-*","ignore_unavailable":true,"include_global_state":false}// 查看快照状态GET_snapshot/my_backup_repo/snapshot_20260522/_status// 查看仓库中所有快照GET_snapshot/my_backup_repo/_all// 删除旧快照DELETE_snapshot/my_backup_repo/snapshot_old
定时快照策略
// 使用SLM（Snapshot Lifecycle Management）自动管理快照PUT_slm/policy/daily_snapshot{"schedule":"0 30 2 * * ?","name":"<daily-snapshot-{now/d}>","repository":"my_backup_repo","config":{"indices":["*"],"ignore_unavailable":true,"include_global_state":false},"retention":{"expire_after":"30d","min_count":5,"max_count":50}}// 查看SLM策略执行状态GET_slm/policyGET_slm/stats
快照恢复操作
// 恢复快照到新索引POST_snapshot/my_backup_repo/snapshot_20260522/_restore{"indices":"logs-2026-05-*","ignore_unavailable":true,"include_global_state":false,"rename_pattern":"logs-(.+)","rename_replacement":"restored_logs-$1","index_settings":{"index.number_of_replicas":0},"ignore_index_settings":["index.lifecycle.name","index.lifecycle.rollover_alias"]}// 查看恢复状态GET_recovery/restored_logs-*// 取消恢复DELETErestored_logs-*
恢复操作注意事项
注意点 说明 副本数设为0 恢复时先不创建副本，完成后手动增加 磁盘空间检查 确保目标节点有足够空间 版本兼容性 旧版本快照可在新版本恢复（不可逆） 关闭ILM 恢复的索引需要关闭ILM策略或重新关联 网络限速 使用max_restore_bytes_per_sec限制带宽占用
滚动重启集群
滚动重启操作步骤
滚动重启是在不中断服务的情况下逐台重启节点的标准操作，适用于版本升级、配置变更等场景。
# ====== 步骤1：禁用分片分配 ======curl-XPUT"localhost:9200/_cluster/settings"-H'Content-Type: application/json'-d' { "persistent": { "cluster.routing.allocation.enable": "primaries" } } '# 验证：确认没有分片正在重新分配curl-XGET"localhost:9200/_cat/recovery?v&active_only=true"# ====== 步骤2：执行同步刷新（可选但推荐） ======curl-XPOST"localhost:9200/_flush/synced"# ====== 步骤3：停止第一个节点 ======systemctl stop elasticsearch# 或kill-SIGTERM$(pidofjava)# ====== 步骤4：启动第一个节点 ======systemctl start elasticsearch# ====== 步骤5：等待节点恢复 ======# 确认节点加入集群curl-XGET"localhost:9200/_cat/nodes?v"# 确认所有分片恢复完成curl-XGET"localhost:9200/_cat/shards?v"|grep-vSTARTED# ====== 步骤6：对每个节点重复步骤3-5 ======# ====== 步骤7：重新启用分片分配 ======curl-XPUT"localhost:9200/_cluster/settings"-H'Content-Type: application/json'-d' { "persistent": { "cluster.routing.allocation.enable": "all" } } '# ====== 步骤8：等待所有分片恢复 ======curl-XGET"localhost:9200/_cluster/health?wait_for_status=green&timeout=60s"
滚动重启注意事项
注意点 说明 禁用分片分配 只允许主分片分配，防止重启时分片迁移 synced flush 使索引数据同步到磁盘，加速重启恢复 逐台重启 一次只停一个节点，等待其完全恢复后再停下一个 等待恢复 确认所有分片都恢复为STARTED后再进行下一步 恢复分配 最后一步一定要重新启用分片分配 超时处理 如果恢复超过timeout，检查_cat/recovery排查问题
总结与最佳实践
高可用部署最佳实践清单
类别 最佳实践 优先级 节点角色 生产环境必须使用专用Master节点（至少3台） P0 副本数 生产索引至少1个副本，关键数据2个副本 P0 可用区 跨可用区部署，防止单机房故障 P0 ILM 使用ILM管理索引生命周期，自动化数据迁移 P1 快照 配置定时快照，保留至少7天数据备份 P0 JVM堆 不超过30GB，启用G1GC P1 磁盘 不超过85%，配置watermark告警 P1 监控 配置完整的监控和告警体系 P0
高可用架构检查清单
集群高可用检查： ✓ 至少3个专用Master节点 ✓ 至少2个Data节点 ✓ 所有索引至少1个副本 ✓ 跨可用区部署 ✓ 定时快照备份（SLM配置） ✓ 快照恢复测试通过 ✓ 滚动重启流程文档化 ✓ 监控告警覆盖核心指标 ✓ ILM策略覆盖所有时间序列索引 ✓ 磁盘watermark阈值已配置
通过遵循以上高可用部署实践，你可以确保Elasticsearch集群在面对节点故障、网络分区、磁盘满等常见问题时，依然能够提供稳定可靠的数据服务。
上一篇【第58篇】Elasticsearch生产集群监控——系统指标与告警配置
下一篇【第60篇】Elasticsearch从入门到精通——系列总结与学习路径推荐
