[转载] 中通 Elasticsearch 集群运维实践

背景

中通在 2015 年的时候已经开始预研并在生产环境使用 Elasticsearch 集群,发展到现在,线上已经有几十套 ES 集群,集群规模小到个位数的节点,大到上百个节点,依靠原来的纯人工的方式来做维护监控操作,已经难以为继,且容易出错,亟需一套系统来简化整个运维流程,统一监控,实时告警以及索引管理。

问题

分布式集群维护困难:搭建、集群节点间配置同步、日常维护(节点启停、服务启停、状态查看)

升级风险大:升级过程中、升级过程后、数据量大、持续时间长、影响范围大、业务影响大

故障定位复杂:大量服务状态需要检查、日志信息四散分布

故障恢复代价高:重新搭建故障节点或模块、重新恢复耗时、费力

目标

稳定:集群内不存在单点、数据保持完全同步(数据、配置、程序等)

高效:自动化部署、升级、恢复,快速故障定位(状态查看、日志定位)

安全:避免各个节点人工修改风险,验证后再发布到集群其他节点(灰度发布)

简单:不依赖于过多的外部资源,使用成熟工具避免引入外部故障

灵活:适用于多种分布式、非分布式软件,易于扩展,易于与其他产品结合

架构

基于现状问题,我们自研了一套ES的运维管理平台,经过调研,自动化运维工具决定采用 Ansible,开发语言采用 python,整体平台的架构设计如下:

整个平台的核心是灵活的配置和完善的 ansible 剧本能力,目前平台提供了以下常用的 ansbile 剧本:

  1. elasticsearch 安装剧本,包含集群的安装、节点的重启、停止功能
  2. elasticsearch 扩容剧本,包含集群的扩容
  3. 机器环境准备剧本,包含安装 ES 前的 java 环境准备、系统参数设置等
  4. elasticsearch 安全插件剧本,主要针对 elasticsearch 6.8 之前的版本
  5. es exporter 安装剧本,安装 ES 监控数据采集的 exporter
  6. kibana 安装剧本,安装对应 ES 集群的 kibana
  7. infinity 安装剧本(infinity 是内部的日志消费组件)

我们的ES管理运维平台界面-集群展示页面:

集群创建页面如下:

通过相对完善和灵活的控制台和剧本,目前我们已经能够很方便的在几分钟内创建一套大集群或者扩容集群。通过 ES 运维管理平台安装的 Elasticsearch,可以得到相对完善的管理以及监控:

目前我们的监控维度包含以下几个方面:

监控的展示页面采用成熟方便的 grafana。

同时,若集群发生故障,prometheus alertmanager 会通过钉钉实时告警,以及时排查问题,降低影响范围和时长。

使用问题&挑战

在使用 Elasticsearch 的实际过程中,我们遇到了不少的问题和挑战,也总结了一些实践经验:

1. 网络抖动引起集群 RED?

事故发生当天,查看集群状态为 RED,使用命令查看当前的节点情况,缺失部分节点,在缺失部分节点服务器上查看进程和日志的情况,发现服务器上的节点状态正常,使用命令查看当前节点的状态,发现是一个集群名称相同的 ES 集群,状态同样为 RED,如下图:

然后检查集群的配置,发现无论是配置文件还是 _cluster/settings 中都没有配置 discovery.zen.minimum_master_nodes ,而当天刚好机房网络有调整,于是确定集群发生了脑裂情况,重启部分节点后,集群恢复正常。ps:有的问题虽然发生概率不大,但却不应该轻视,7.0 版本后已经不需要设置,官方做了优化处理。

2. elasticsearch shard 的分配原则?副本?

shard 是 elasticsearch 的分片数量,且 index 创建后,不能动态调整,所以提前规划好 shard 的数量,变得尤为重要。shard 过多过少,都会影响集群的整体性能,过多会导致单 node 上分片数过多,查询性能问题;过少,会导致单 shard 过大,写入性能问题,且一旦故障恢复或者 rebalance,需要很长时间。建议单 shard 不超过30g,具体合适的 shard 数量,最好通过性能测试来确定。副本数建议设为 1即可。

3.个别节点负载超高是因为什么?

我们遇到节点负载超高的原因主要有两个:1)分片分布不均匀,导致查询写入不均匀2)机器配置不同,比如 hdd 和 ssd 混用,导致 hdd 机器节点负载高,拖累整个集群

4. 节点 heap 过高怎么办?

观察集群整体的 heap 和 gc 情况,如果 heap 占用长期维持在 80% 左右,则可能需要对集群进行优化或扩展:

  1. 关闭不需要的索引

  2. 针对不再更新的索引,force merge

  3. 排查是否有不合理的查询

  4. 集群扩容

未来规划

  • 运维管理平台优化
  • 智能分析实时监控

作者:科技中通
来源:微博
原文链接:weibo.com/ttarticle/p/show?id=2309...

讨论数量: 0
(= ̄ω ̄=)··· 暂无内容!

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!