当前位置: 首页 > 科技观察

分布式文件系统JuiceFS测试总结

时间:2023-03-13 20:40:39 科技观察

前言2021年开始,开源社区出现了一个名为JuiceFS的云原生分布式文件系统。这是国内某公司开源的分布式文件系统。2021年1月在GitHub上开源,支持k8s原生适配和各种应用场景。本文通过一系列测试,评估分布式文件系统JuiceFS是否满足G线应用场景的需求。一、主流分布式文件系统技术参数对比分布式文件系统首先是文件系统,其应具备的基本要素包括:①遵循POSIX标准,提供标准的文件系统API接口;②强数据一致性和元数据组织形式的可靠性和性能;③支持的文件存储和访问级别。结合以上几点,简单对比一下NAS、CephFS、GlusterFS、JuiceFS分布式文件系统的技术参数:图1主流分布式技术对比从上表可以看出GlusterFS和JuiceFS的技术参数很好。GlusterFS是由Gluster在GPL下开源的POSIX分布式文件系统。它于2007年发布第一个公共版本,2011年被RedHat收购。实现的基本思路是通过无状态中间件将多个单机文件系统组合成一个统一的命名空间供用户使用。图2GlusterFS示意图GlusterFS中间件由一组转换器实现,每个转换器实现一个功能,如:锁、缓存、复制、分发数据等。用户可以根据应用场景灵活配置。最大的好处是:文件最终保存在具有相同目录结构的单机文件系统上,这样即使GlusterFS本身出现故障,数据也不会不可读。这种结构最大的缺点是缺乏独立的元数据节点,需要所有存储节点都有完整的数据目录结构,导致整个文件系统的可扩展性有限。数据一致性问题比较复杂,文件目录遍历操作效率低下,缺乏全局监控管理功能。现在,对象存储作为一种低成本、高耐久性的海量存储服务被广泛应用于云时代。如果分布式文件系统能够与对象存储相结合,无论是成本还是使用门槛都会大大降低。原生GlusterFS不支持对象存储,后来集成了Swift对象存储技术,使用Gluster文件系统(Volume)作为Swift的后端文件存储系统,用于管理磁盘级数据存储,并提供基于对象存储的REST访问接口。相比之下,JuiceFS的核心思想是在对象存储的基础上实现一个独立的基于内存的元数据引擎来组织和管理文件,而对象存储本身就是用来存储文件数据的。该实现兼容POSIX、HDFS、S3API访问接口,对应用程序透明,不需要对应用程序进行大的修改,简单易用。可能的问题是元数据引擎的可靠性。理论上存在元数据引擎损坏导致无法读取数据的场景。所以在生产环境中一定要做好高可用和自下而上的设计。图3JuiceFS架构图2.JuiceFS分布式文件系统研究方案从文档介绍来看,JuiceFS除了支持文件共享场景,还支持非结构化数据存储、管理和分析场景。但是是否适合LineG的使用场景和技术要求呢?(1)研究目标:文件共享场景1)一次写入多次读取(非事务性数据),如日志、备份等2)针对文件多次读写的场景(非事务性数据)),区分以下两种情况:①一个writer多次写入同一个文件,没有并发,没有写锁。writer按照open-write-close进行操作。②有多个writer并发写入同一个文件,即多个文件先抢占锁文件,获得锁后打开-写入-关闭数据文件。这种方式有风险,JuiceFS进程在每个client上都会在打开文件的fd中预留文件长度。在极端情况下,有可能被覆盖(Bug或不正常的操作)。这种场景不推荐使用分布式文件系统。(2)测试方案设计测试方案设计基于社区版JuiceFS0.17.1+redis元数据引擎,针对标准化的功能、性能和运维需求,从元数据备份、引擎宕机、引擎恢复、引擎迁移、POSIX规范、解压文件、生成海量小文件、并行读写、并发读写、网络异常、后端对象存储异常等测试。由于G行强一致性要求,测试没有开启JuiceFS缓存功能。JuiceFS对接对象存储obj桶并挂载到本地/mnt/juicefs-load目录。所有的测试验证操作都在juicefs-load目录下进行。1)元数据备份2)标准POSIX文件系统压力测试方法一:LinuxTestProject是一个社区标准的Linux操作系统测试套件,对相应的接口、定义和实现进行验证和压力测试。提取文件系统相关的测试用例进行测试。方法二:Pjdfstest,一个精简的POSIX文件系统测试套件,用于测试POSIX兼容性。3)引擎宕机4)引擎恢复、引擎迁移5)网络异常6)后端对象存储异常测试(3)测试详细数据1)LTPPOSIX文件系统压力测试Pjdtest精简POSIX测试套件全部通过。2)解压文件3)并行读写场景多个协程并行写入不同文件4)并发读写场景多个进程并发读写同一个文件,对读取没有特殊要求;测试结果符合预期。并发写入需要先锁定lockfile,严格遵循open-write-close流程。写的内容可以被其他客户看到,测试结果符合预期。5)海量小文件6)异常场景7)与现有对象存储FIO性能数据对比(4)初步研究结论1)POSIX压测失败有两个:ftest04,fs_fill;2)存在不稳定现象(延迟波动,3)并行读性能落后于本地fs和NAS;4)并行写入性能落后于本地fs和NAS;5)海量文件场景下,跨不同类型引擎的备份恢复时间较长。(5)展望当前版本的JuiceFS在整体并发、文件读写性能等方面暂时无法满足G线对共享存储的需求,但在本次构建的对象存储方面,兼容的对象存储接口提供了基于FUSE标准的POSIX文件系统接口,还实现了元数据引擎以确保数据的强一致性。它的设计理念值得点赞。虽然目前还不能完全兼容G线的应用场景,但总体来说,分布式文件系统是一个值得长期跟进的技术。期待在元数据安全、数据强一致性下的读写性能等方面出现适合G线应用场景的分布式文件系统。