跳转至

ELK生产集群运维

集群规划

单一角色:职责分离

  • Dedicated master eligible nodes:负责集群状态(cluster state)的管理
  • 使用低配置的CPU、RAM和磁盘
  • 从高可用&避免脑裂的角度出发(单独部署)
    • 一般生产环境中配置3台master节点
    • 一个集群只有一台活跃的主节点
    • 负责分片管理、索引创建、集群管理等操作
  • Dedicated data nodes:负责数据存储及处理客户端请求
  • 使用高配置的CPU、RAM和磁盘
  • Dedicated ingest nodes:负责数据处理
  • 使用高配置CPU;中等配置的RAM;低配置的磁盘
  • Dedicated Coording Only Node(Client Node)
  • 配置:将Master、Data、ingest都配置成False
    • 中高配置的CPU;中高配置的RAM和低配置的磁盘
  • 生产环境中,建议为一些大的集群配置Coording Only Nodes
    • 扮演Load Balancers,降低Master和Data Nodes的负载
    • 负责搜索结果的Gather/Reduce

Hot & Warm 架构

Hot节点使用高配置高性能磁盘

Warm节点使用低配置大容量磁盘

配置Hot & Warm Architecture

  • 使用Share Filtering,步骤分为以下几步
  • 标记节点(Tagging)
  • 配置索引到Hot Node
  • 配置索引到Warm节点

如何设计分片数

  • 当分片数 > 节点数时
  • 一旦集群中有新的数据节点加入,分片就可以自动进行分配
  • 分片在重新分配时,系统就不会有downtime
  • 多分片的好处:一个索引如何分布在不同的节点,多个节点可以并行执行
  • 查询可以并行执行
  • 数据写入可以分散到多个机器
  • 分片数过多带来的副作用
  • Shard是Elasticsearch实现集群水平扩展的最小单位
  • 过的设置分片数会带来一些潜在的问题
    • 每个分派你是一个lucene的索引,会使用机器的资源。过多的分派你会导致额外的性能开销
    • Lucene Indices/File descriptors /RAM/CPU
    • 每次搜索的请求,需要从每个分片上获取数据
    • 分片的Meta信息由Master节点维护。过多,会增加管理的负担。经验值,控制分片总数在10W以内

如何确定分片数

  • 从存储的物理角度看

  • 日志类应用,单个分片不要大于50G

  • 搜索类应用,单个分片不要超过20G

为什么控制分片存储的大小

  • 提高update的性能
  • merge时减少所需要的资源
  • 丢失节点后,更快的恢复速度

如何确定副本分片数

  • 副本是主分片的拷贝
  • 提高系统可用性:相应查询请求,避免数据丢失
  • 需要占用系统资源
  • 对性能的影响
  • 副本会降低数据的索引速度:有几分副本就会有几倍的CPU资源消耗在索引上
  • 会减缓对主分片的查询压力,但是会消耗同样的内存资源
    • 如果机器资源充足,提高副本数量,可以提高整体查询的QPS
  • 调整分片总数的设定,避免分配不均衡

集群容量规划

硬件配置

  • 合理的硬件,数据节点尽可能的使用SSD
  • 搜索等性能要求高的场景,建议SSD
  • 按照1:10的比例配置内存和硬盘
  • 日志类和查询并发低的场景,可以考虑使用机械硬盘存储
  • 按照1:50的比例配置内存和硬盘
  • 单节点数据建议控制在2TB以内,最大不建议超过5TB
  • JVM配置机器内存的一半,JVM内存配置不建议超过32G

集群部署最佳实践

网络

  • 单个集群不要跨数据中心进行部署(不要使用wlan)
  • 节点之间hops越少越好
  • 如果有多块网卡,最好将transport和http绑定到不同的网卡,并设置不同的防火墙规则
  • 按需为Coordinating Node 或 Ingrest Node配置负载均衡

内存

需要保留50%的内存作为全文检索使用

  • 内存大小要根据Node需要存储的数据来进行估算
  • 搜索类的比例建议:1:16
  • 日志类:1:48-1:96之间
  • 总数据量1T,设置一个副本=2T总数据量
  • 如果搜索类的项目,每个节点31*16=496G,加上预留空间。所以每个节点最多400G数据,至少需要5个数据节点
  • 如果是日志类项目,每个节点31*50=1550G,2个数据节点即可

存储

  • 推荐使用SSD,使用本地存储,避免使用SAN NFS/AWS/Azure filesystem
  • 可以在本地指定多个“path.data”,以支持多块磁盘
  • ES本身提供了很好的HA机制,无需使用RAID⅕/10
  • 可以在Warm节点上使用Spinning Disk,但是需要关闭Concurrent Merges
  • index.merge.scheduler.max_thread_count: 1
  • Trim你的SSD
  • https://www.elastic.co/blog/is-your-elasticsearch-trimmed

服务器硬件

  • 建议使用中等配置的机器,不建议使用过于强劲的硬件配置
  • Medium machine over large machine
  • 不建议在一台机器上运行多个节点

集群设置: Throttles 限流

  • 对Relocation和Recovery设置限流,避免过多任务对集群产生性能影响
  • Recovery
  • Cluster.routing.allocation.node_concurrent_recoveries: 2
  • Relocation
  • Cluster.routing.allocation.node_concurrent_rebalance: 2

集群设置:关闭Dynamic Indexes

  • 可以考虑关闭动态索引创建功能
  • 或者通过模板设置白名单

集群优化

监控Elasticsearch集群

诊断集群的潜在问题

解决集群Yellow和Red的问题

分片没有被分配的一些原因

  • INDEX_CREATE:创建索引导致,在索引的全部分片分配完成之前,会有短暂的Red,不一定代表有问题
  • CLUSTER_RECOVER:集群重启阶段,会有这个问题
  • INDEX_REOPEN:Open一个之前Close的索引
  • DANGLING_INDEX_IMPORTED:一个节点离开集群期间,有索引删除。这个节点重新返回时,会导致Dangling的问题,重新执行删除操作即可解决

常见集群问题与解决方法

  • 集群变红,需要检查是否有节点离线。如果有,通常通过重启离线的节点可以解决问题
  • 由于配置导致的问题,需要修复相关配置
  • 如果是测试索引,可以直接 删除
  • 因为磁盘空间限制,分片规则引发的,需要调整规则或者增加节点
  • 对于节点返回集群,导致的dangling变红,可直接删除dangling索引

集群Red & Yellow 问题总结

  • Red & Yellow是集群运维中常见的问题
  • 除了集群故障,一些创建,增加副本等操作,都会导致集群短暂Red和Yellow,所以监控和报警时需要设置一定的延时
  • 通过检查节点数,使用ES提供的相关API,找到真正的原因
  • 可以指定Move或者Reallocate分片

提升集群写性能

提高写性能优化的目标:增大写吞吐量,越高越好

客户端

  • 多线程,批量写
  • 可以通过性能测试,确定最佳文档数量
  • 多线程:需要观察是否有HTTP429返回,实现Retry以及线程数量的自动调节

服务端

  • 单个性能问题,往往时多个因素造成的。需要先分解问题,在单个节点上进行调整并且结合测试,尽可能压榨硬件资源,以达到最高吞吐量

  • 使用更好的硬件,观察CPU/IO Block

  • 线程切换/堆栈状况

  • 减低IO操作

  • 使用ES自动生成的文档ID/一些相关的ES配置,如:Refresh intreval

  • 降低CPU和存储的开销

  • 减少不必要的分词/避免不需要的dec_values/文档的字段尽量保证相同的顺序,可以提高文档的压缩率

  • 尽可能做到写入和分片的均衡负载,实现水平扩展

  • Shard Filtering/Write Load Balancer

  • 调整Bulk线程池和队列

文档建模的最佳实践

  • 只需要聚合不需要搜索,index设置成false
  • 不需要算分,Norms设置成false
  • 不要对字符串使用默认的dynamic mapping。字段数量过多,会对性能产生比较大的影响
  • Index_options控制在创建倒排索引时,那些内容会被添加到倒排索引中。优化这些设置,一定程度可以节约CPU
  • 关闭_source,减少IO操作;(适合指标性数据)

提升集群读性能

尽量使用Denormalize数据

  • Elasticsearch !=关系型数据库
  • 尽可能Denormalize数据,从而获取最佳的性能
  • 使用Nested类性的数据。查询速度会慢几倍
  • 使用Parent/Child关系。查询速度会慢几百倍

数据建模

  • 尽量将数据先行计算,然后保存到Elasticsearch中。尽量避免查询时的Script计算
  • 尽量使用Fileter Context,利用缓存机制,减少不必要的算分
  • 结合profile,explain API分析慢查询的问题,持续优化数据模型
  • 严谨使用*开头通配符Terms查询

集群压力测试

测试方法及步骤

  • 测试方法步骤
  • 测试计划
  • 脚本开发
  • 测试环境搭建
  • 分析比较结果

测试目标&测试数据

  • 测试目标
  • 测试集群的读写性能/做集群容量的规划
  • 对ES配置参数进行修改,评估优化效果
  • 修改Mapping和Setting,对数据建模进行优化,并测试评估性能改进
  • 测试ES新版本,结合实际场景和老版本进行比较,评估是否进行升级
  • 测试数据
  • 数据量/数据分布

测试脚本

  • ES本身提供了REST API,所以,可以通过很多传统的性能测试工具

  • Load Runner(商业软件,支持录制+重放+DSL)

  • JMeter(Apache开源,Record&Play)
  • Gatling(开源,支持Scala代码+DSL)

  • 专门为Elasticsearch设计的工具

  • ES Pref & Elasticsearch-stress-test

  • Elastic Rally

运维建议

集群的生命周期管理

  • 预上线
  • 评估用户的需求及使用场景/数据建模/容量规划/选择合适的部署架构/性能测试
  • 上线
  • 监控流量/定期检查潜在问题(防患于未然,发现错误的使用方式,及时增加机器)
  • 对索引进行优化,检测是否存在不均衡而导致有部分节点过热
  • 定期数据备份/滚动升级
  • 下架前监控流量,实现Stage Decomminssion

部署建议

  • 根据实际场景,选择合适的部署方式,选择合理的硬件配置
  • 搜索类
  • 日志/指标
  • 部署要考虑,反亲和性
  • 尽量将机器分散在不同的机架上,例如,3台master节点必须分散在不同的机架上
  • 善用Shard Filtering进行配置

  • 设置Slowlogs,发现一些性能不好,甚至是错误使用的Pattern

  • 集群备份,定期对集群数据进行备份
  • 定期更新ES版本