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版本