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

摘要

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

  • GlusterFS 在单目录下文件众多时,ls命令速度很慢;
  • 受疫情期间机器采购周期的制约,无法灵活地根据实际需求弹性扩缩容,存储成本控制困难;
  • 磁盘损坏等故障带来的机器替换和扩缩容操作,使得运维成本居高不下。

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

  • POSIX 接口,对应用无侵入
  • 强一致性,文件修改立刻可见,为同一个 volume 被多台机器挂载的场景提供 了close-to-open 保证
  • 支持了主流的公有云对象存储,支持开源软件作为元数据引擎(Redis、TiKV)等
  • 支持云原生,能够将volume以 CSI 的方式挂载到Pod上
  • 社区活跃,代码更新快

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

欢迎在评论区写下你对这篇文章的看法。

评论

ホーム - Wiki
Copyright © 2011-2024 iteam. Current version is 2.132.0. UTC+08:00, 2024-09-21 17:35
浙ICP备14020137号-1 $お客様$