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