悉尼服务器 Elasticsearch 集群运维实战

Elasticsearch 是强大的搜索和分析引擎。本文分享悉尼服务器 ES 集群运维实战。

集群规划 1) 节点类型：Master、Data、Coordinating、Ingest 2) 节点数量：至少 3 个 Master，Data 节点按需 3) 内存：每节点 32G（JVM 16G + Lucene 16G） 4) 磁盘：SSD，每节点 1-2T 5) 网络：万兆内网

部署要点 1) JVM 内存不超过 32G，避免指针压缩失效 2) 关闭 swap，设置 mlockall 3) 文件描述符限制调高（65535+） 4) 内核参数调整：vm.max_map_count=262144 5) 集群名称统一，节点名称有意义

索引设计 1) 分片数：单分片 10-50GB，避免过多分片 2) 副本数：至少 1 副本，保证高可用 3) Mapping：合理设计字段类型，避免动态映射 4) 分词：选择合适的分词器（IK、smartcn） 5) 索引生命周期：热温冷架构，定期滚动

性能优化 1) 写入优化：refresh_interval 调大（30s），批量写入 2) 查询优化：避免深度分页，用 search_after 3) 路由优化：相同路由的文档到同一分片 4) 缓存：query cache、request cache 5) 合并：定期 optimize 减少段文件

高可用 1) 副本：每个索引至少 1 副本 2) 跨可用区：节点分布在不同 AZ 3) 快照：定期快照到 S3/OSS 4) 监控：集群健康、节点状态、索引状态 5) 告警：集群变红、节点掉线、磁盘告警

常见问题 问题一：集群健康变黄/红 排查：分片未分配；节点掉线；磁盘满。 修复：恢复节点；清理磁盘；重新分配分片。

问题二：查询慢 排查：慢查询日志；分片过多；缺乏索引。 修复：优化查询；减少分片；合理 Mapping。

问题三：写入慢 排查：refresh 频繁；磁盘 IO 满；单分片过大。 修复：调大 refresh_interval；用批量写入；增加分片。

问题四：JVM 内存不足 排查：fielddata 过大；聚合查询；内存泄漏。 修复：用 doc_values；优化聚合；调整 JVM。

问题五：节点掉线 排查：OOM；网络问题；磁盘故障。 修复：增加内存；修复网络；替换磁盘。

生产经验 1) 分片不要太多，每个索引 3-10 个分片 2) 单分片控制在 10-50GB 3) 不要在查询中用 * 4) 定期清理无用索引 5) 快照和恢复要测试

监控指标 - 集群状态（green/yellow/red） - 节点数、分片数 - JVM 内存使用和 GC - 磁盘使用率 - 查询和写入延迟 - 段文件数量和大小

总结：ES 集群运维要关注分片设计、索引生命周期、性能调优和监控告警。合理规划才能稳定支撑搜索业务。