文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

JuiceFS 在携程海量冷数据场景下的实践

2024-12-01 17:29

关注

一、摘要

携程的冷数据规模在 10PB+,包括备份数据、图片语音训练数据和日志数据等,存储方案主要是本地磁盘和GlusterFS。在实际使用中这些方案遇到了不少痛点:

随着云计算技术的发展,公有云厂商为混合云客户提供了海量冷数据的廉价存储方案,经过严谨的成本计算,我们发现使用公有云的对象存储可以显著降低存储和运维成本。为了减少迁移成本,我们一直在寻找后端存储能支持各类公有云对象存储、高性能的文件系统,直到JuiceFS 出现在我们的视野中。JuiceFS有以下优势:

经过大半年的测试和使用,我们已经对接了数据库备份和 ElasticSearch 冷数据存储,将2PB+的数据迁移到了JuiceFS,预计后续还会有10PB+的数据接入。目前JuiceFS系统稳定,在降低运维成本和存储成本方面取得了良好的效果。本文将对JuiceFS原理以及我们在使用中所遇到的问题和采取的优化方案进行简单介绍。

二、JuiceFS 架构与POC 测试

2.1 架构简介

JuiceFS 将元数据信息和真实数据块分开管理,通过 FUSE 实现 POSIX 接口,允许用户像本地文件系统一样使用。用户将文件写入JuiceFS挂载的目录后,文件数据会存储到对象存储,相应的元数据(文件名、文件大小、权限组、创建修改时间和目录结构等)会存到元数据引擎中。在该架构下,ls、数据删除等操作只是对元数据引擎的操作,不受到对象存储的速度限制,性能上会有较好的保证。

2.2 元数据引擎选型与测试

JuiceFS 的元数据引擎有很多选择,包括开源的Redis、TiKV以及官方提供的闭源的企业版元数据引擎。考虑到携程的数据规模较大并且后续会有更多的数据接入,元数据引擎需要能够支持TB 级元数据的存储并且能横向扩容。因此TiKV和官方的企业版元数据引擎成了我们的备选方案。

为了验证TiKV的性能,我们使用 go-ycsb做了一些性能测试。

机器

CPU

Memory

Storage

Network

Node1

2 Socket / 20 Core / 40 Thread

128G

1.9T SSD

bond0 25G

Node2

2 Socket / 20 Core / 40 Thread

128G

960G SSD

bond0 25G

Node3

2 Socket / 20 Core / 40 Thread

128G

1.2T SSD

bond0 25G

测试结果:

1)Write 事务写入操作,随着客户端线程数增加,TPS上升,峰值超过30000

2)Get事务读取操作, 随着客户端线程数增加,QPS上升,单节点峰值接近70000

从测试结果看,TiKV有较高的读写吞吐量,并且单次操作的响应时间P99<10ms,在冷数据场景中性能表现可满足业务需求。

官方的企业版元数据引擎比TiKV有更好的性能表现,但是考虑到冷数据存储对性能要求并不苛刻,而且相比于对象存储20~200ms的访问速度,元数据引擎并不会明显降低整个系统响应的速度。为了减少技术黑箱,我们选择了TiKV作为元数据引擎。

2.3 JuiceFS 整体POC测试

在交付生产之前,为了明确SLA指标和最佳使用场景,我们使用mdtest对以TiKV为元数据引擎的JuiceFS进行了整体POC 测试,部署使用如下架构:

1)单线程写入,测试文件大小与吞吐量的关系

测试结果表明随着文件大小增大,吞吐量也随之增大。在单文件为 128MB~256MB 左右时,原先的吞吐量与文件大小的增长曲线明显放缓。可以理解为当文件较小时,JuiceFS客户端与元数据引擎和对象存储的交互成本与有效数据传输成本相比,占比较高,限制了吞吐量;当文件较大时,交互成本占比降低,吞吐量上升。为了发挥充分JuiceFS的吞吐能力,建议存储128MB以上的文件。

2)目录深度与 JuiceFS IOPS 的关系

测试结果表明目录深度与 JuiceFS IOPS 没有明显关系。研究JuiceFS代码可知,虽然深度越深,文件路径变长,但 JuiceFS在创建文件/目录时在TiKV里的Key是父目录 inode + 新条目的名字,所以目录深度不影响TiKV里的键值对大小,就不影响TiKV的查询性能,符合测试结果。

3)目录大小与 ls速度的关系

单目录下文件个数

ls耗时(ms)

1025

25

24269

31

测试结果表明目录下文件个数对ls几乎没有影响。

2.4 元数据引擎故障测试

理论上TiKV 节点中 Region 通过 Raft 保证一致性,即非 Leader Region 故障完全不影响上层应用,Leader Region 故障则会在该 Region 的副本中重新选举出一个 Leader Region,选举需要时间,并且需要上报 PD 节点进行处理,因此会影响到上层应用的部分请求。

PD 集群用来管理 TiKV 集群,PD 的非 Leader 节点故障完全不影响上层应用,Leader 节点故障则需要重新选举新 PD Leader,选举过程 JuiceFS 客户端的请求无法得到响应,新 Leader 节点确立后 JuiceFS 重新建立连接也需要一定耗时,该时间段内会对上层应用的请求产生影响。

据此我们模拟节点故障的场景,测试实际应用过程中元数据引擎故障后恢复所需时间,计算正常场景中读写一定数量文件与异常情况下的耗时差异。结果表明故障影响时间可以控制在秒级。

1)TiKV 故障

File size/count

正常

异常

Diff(ms)

单线程写 4MiB/1024

237035.52

249333.76

12298.24

单线程读 4MiB/1024

360222.72

362577.92

2355.2

2)PD 故障

File size/count

正常

异常

Diff(ms)

单线程写4MiB/1024

237035.52

247531.52

10496

单线程读 4MiB/1024

362332.16

362577.92

245.76

三、JuiceFS原理解析

3.1 文件写入

JuiceFS 接收到写请求会先将数据写入 Buffer,并按照 Chunk、Slice、Block 的规则进行数据块管理,最后以 Slice 为维度Flush到对象存储。一次 Flush 实质上是对 Slice 中的每个 Block 进行 PUT 操作,将数据写到对象存储,并完成元数据修改。如下图:

3.2 文件读取

读取流程数据处理方式与写入流程类似,读取请求被 JuiceFS 进程接收到后会先访问元数据引擎,找到需要读取的 Block,向对象存储并发发出 GET 请求。由于 Block 数据不变性,读取出的 4M 的 Block 会写到本地的缓存目录中。读取过程中按照 4M(Block) 的方式实现了一定程度的预读,可以通过调整 prefetch 参数,将预读窗口设置的更大,默认 prefetch = 1。如下图:

四、故障处理与性能优化

4.1 TiKV CPU使用率过高,导致拒绝服务

现象:TiKV kv_scan请求数突然上升,unified_read_po 线程池CPU使用率被打满

分析:客户端运行cleanTrash任务导致的。Beta 1版本的客户端会同时进行该任务,当同一个volume挂载的客户端较多,并且trash中的数据量非常多的时候,该任务会对元数据引擎造成突发的压力。

解决方案:

4.2 TiKV 数据泄露

现象:文件数目和OSS中的数据量没有增加的情况下,region数目不断增加,store size不断增加

分析:通过tikv-ctl查看TiKV里的数据,发现MVCC的修改和删除记录没有被清除。完整的TiDB部署会10min触发一次数据GC。但是单独部署TiKV,数据GC需要由其他程序触发。另一方面5.0.1版本的TiKV有bug,数据GC没有清理删除记录,相关issue。

解决方案:

4.3 CSI 挂载场景中,PV 清理后数据 OSS 中数据无法回收

现象:k8s中的ElasticSearch 所有Pod、PVC、PV 下线一天后 OSS 数据仍没被清理。

分析:PV 被清理时 CSI 执行了 JuiceFS rmr 指令,将 volume 数据全部放到回收站,根据默认配置 trash-day=1,即一天后开始回收数据。由于环境中的 JuiceFS mount Pod 已经全部下线,即没有 JuiceFS 进程挂载了 CSI 的 volume,于是出现了没有清理回收站的情况。

解决方案:由于 CSI 模式使用 JuiceFS 是模拟了 subdir 的过程,即整个 CSI 管理 Pod 挂载的 volume 是同一个,通过写到子目录的方式进行数据隔离。我们停止了mount pod的所有后台任务,另外找了一台机器挂载该 volume来完成自动清理回收站数据等后台任务,该方法也消除了后台任务带来的客户端性能抖动。

4.4 客户端使用内存过高

现象:部分使用 JuiceFS 的机器占用内存过高,达到了 20GB+。

分析:

解决方案:将客户端的启动参数backup-meta默认值改为0,元数据备份参考官方的实现思路通过另外的组件统一实现,客户端不执行元数据备份任务。

4.5 优化后架构

生产实践过程中涉及数PB级的数据,业务场景相差巨大,经过规划与调优,最终演进成如下架构。

五、总结与展望

通过 JuiceFS 将冷数据上公有云, Elasticsearch 实现了一定程度的存算分离,去除了副本带来的内存需求,提升整体集群数据存储能力。DBA 备份数据从 GlusterFS 迁移到 JuiceFS 后 ls 等行为的性能大幅提高,不仅运维人员不再需要投入精力进行磁盘扩容维修,大大降低了运维成本,而且用户还能够按照保留时间快速地控制存储成本。

目前已有2PB 来自 ElasticSearch、DBA 备份的数据存储到JuiceFS,后续我们会推动更多的数据上JuiceFS,当然后续也很多需要进一步探索和优化的地方,例如:

来源:携程技术内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-后端开发
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯