加入收藏 | 设为首页 | 会员中心 | 我要投稿 云计算网_泰州站长网 (http://www.0523zz.com/)- 视觉智能、AI应用、CDN、行业物联网、智能数字人!
当前位置: 首页 > 综合聚焦 > 创业热点 > 经验 > 正文

PB 级大规模 Elasticsearch 集群运维与调优落地

发布时间:2021-05-31 19:53:54 所属栏目:经验 来源:互联网
导读:因为游戏业务本身的日志数据量非常大(写入峰值在 100w qps),在服务客户的几个月中,踩了不少坑,经过数次优化与调整,把客户的 ES 集群调整得比较稳定,避免了在业务高峰时客户集群的读写异常,并且降低了客户的资金成本和使用成本。 场景 1:与客户的初

因为游戏业务本身的日志数据量非常大(写入峰值在 100w qps),在服务客户的几个月中,踩了不少坑,经过数次优化与调整,把客户的 ES 集群调整得比较稳定,避免了在业务高峰时客户集群的读写异常,并且降低了客户的资金成本和使用成本。

场景 1:与客户的初次交锋

解决方案架构师 A: bellen, XX 要上线一款新游戏,日志存储决定用 ELK 架构,他们决定在 XX 云和我们之间二选一,我们首先去他们公司和他们交流一下,争取拿下!

bellen: 好,随时有空!

和架构师一起前往该公司,跟负责底层组件的运维部门的负责人进行沟通。

XX 公司运维老大:不要讲你们的 PPT 了,先告诉我你们能给我们带来什么!

bellen:呃,我们有很多优势,比如可以灵活扩缩容集群,还可以一键平滑升级集群版本,并且提供有跨机房容灾的集群从而实现高可用……

XX 公司运维老大:你说的这些别的厂商也有,我就问一个问题,我们现在要存储一年的游戏日志,不能删除数据,每天就按 10TB 的数据量算,一年也得有个 3PB 多的数据,这么大的数量,都放在 SSD 云盘上,成本太高了。你们有什么方案既能够满足我们存储这么大数据量的需求,同时能够降低我们的成本吗?

bellen: 我们本身提供的有冷热模式的集群,热节点采用 SSD 云硬盘,冷节点采用 SATA 盘,采用 ES 自带的 ILM 索引生命周期管理功能,定期把较老的索引从热节点迁移到冷节点上,这样从整体上可以降低成本。另外,也可以定期把更老的索引通过 snapshot 快照备份到 COS 对象存储中,然后删除索引,这样成本就更低了。

XX 公司运维老大:存储到 COS 就是冷存储呗,我们需要查询 COS 里的数据时,还得再把数据恢复到 ES 里?这样不行,速度太慢了,业务等不了那么长时间,我们的数据不能删除,只能放在 ES 里!你们能不能给我们提供一个 API, 让老的索引数据虽然存储在 COS 里,但是通过这个 API 依然可以查询到数据,而不是先恢复到 ES, 再进行查询?

bellen:呃,这个可以做,但是需要时间。是否可以采用 hadoop on COS 的架构,把存量的老的索引数据通过工具导入到 COS,通过 hive 去查询,这样成本会非常低,数据依然是随时可查的。

XX 公司运维老大:那不行,我们只想用成熟的 ELK 架构来做,再增加 hadoop 那一套东西,我们没那么多人力搞这个事!

bellen: 好吧,那可以先搞一个集群测试起来,看看性能怎么样。关于存量数据放在 COS 里但是也需要查询的问题,我们可以先制定方案,尽快实施起来。

XX 公司运维老大:行吧,我们现在按每天 10TB 数据量预估,先购买一个集群,能撑 3 个月的数据量就行,能给一个集群配置的建议吗?

bellen: 目前支持单节点磁盘最大 6TB, cpu 和内存的话可以放到 8 核 32G 单节点,单节点跑 2w qps 写入没有问题,后面也可以进行纵向扩容和横向扩容。

XX 公司运维老大:好,我们先测试一下。

场景 2:集群扛不住压力了

N 天后,架构师 A 直接在微信群里反馈:bellen, 客户反馈这边的 ES 集群性能不行啊,使用 logstash 消费 kafka 中的日志数据,跑了快一天了数据还没追平,这是线上的集群,麻烦紧急看一下吧。

我一看,一脸懵, 什么时候已经上线了啊,不是还在测试中吗?

XX 公司运维 B: 我们购买了 8 核 32G*10 节点的集群,单节点磁盘 6TB, 索引设置的 10 分片 1 副本,现在使用 logstash 消费 kafka 中的数据,一直没有追平,kafka 中还有很多数据积压,感觉是 ES 的写入性能有问题。

随后我立即查看了集群的监控数据,发现 cpu 和 load 都很高,jvm 堆内存使用率平均都到了 90%,节点 jvm gc 非常频繁了,部分节点因为响应缓慢,不停的离线又上线。

经过沟通,发现用户的使用姿势是 filebeat+kafka+logstash+elasticsearch, 当前已经在 kafka 中存储了有 10 天的日志数据,启动了 20 台 logstash 进行消费,logstash 的 batch size 也调到了 5000,性能瓶颈是在 ES 这一侧。客户 8 核 32G*10 节点的集群,理论上跑 10w qps 没有问题,但是 logstash 消费积压的数据往 ES 写入的 qps 远不止 10w,所以是 ES 扛不住写入压力了,只能对 ES 集群进行扩容,为了加快存量数据的消费速度,先纵向扩容单节点的配置到 32 核 64GB,之后再横向增加节点,以保证 ES 集群能够最大支持 100w qps 的写入(这里需要注意的是,增加节点后索引的分片数量也需要调整)。

(编辑:云计算网_泰州站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读