Skip to main content

技术架构

JuiceFS 文件系统由三个部分组成:

JuiceFS 客户端(Client):所有文件读写,乃至于碎片合并、回收站文件过期删除等后台任务,均在客户端中发生。可想而知,客户端需要同时与对象存储和元数据存储服务打交道。客户端支持众多接入方式:

  • 通过 FUSE,JuiceFS 文件系统能够以 POSIX 兼容的方式挂载到服务器,将海量云端存储直接当做本地存储来使用。
  • 通过 Hadoop Java SDK,JuiceFS 文件系统能够直接替代 HDFS,为 Hadoop 提供低成本的海量存储。
  • 通过 Kubernetes CSI 驱动,JuiceFS 文件系统能够直接为 Kubernetes 提供海量存储。
  • 通过 S3 网关,使用 S3 作为存储层的应用可直接接入,同时可使用 AWS CLI、s3cmd、MinIO client 等工具访问 JuiceFS 文件系统。
  • 通过 WebDAV 服务,使用 HTTP 协议接入 JuiceFS 并直接操作其中的文件。

数据存储(Data Storage):文件将会切分上传保存在对象存储服务,既可以使用公有云的对象存储,也可以接入私有部署的自建对象存储。JuiceFS 支持几乎所有的公有云对象存储,同时也支持 OpenStack Swift、Ceph、MinIO 等私有化的对象存储。

元数据引擎(Metadata Engine):Juicedata 自研的高性能元数据服务,用于存储文件元数据(metadata),包含以下内容:

  • 常规文件系统的元数据:文件名、文件大小、权限信息、创建修改时间、目录结构、文件属性、符号链接、文件锁等。
  • JuiceFS 独有的元数据:文件 inode,chunk 及 slice 映射关系、客户端 session 等。

Juicedata 已经在大多数公有云都部署了元数据服务,供云服务用户使用。JuiceFS 客户端默认通过公网直接访问同区域的元数据服务,但在对网络延迟有着更高要求的大规模场景下,也可以通过内网打通的方式来进一步优化元数据服务的访问延迟,详情请咨询 Juicedata 团队。

JuiceFS 如何存储文件

文件系统作为用户和硬盘之间交互的媒介,它让文件可以妥善的被存储在硬盘上。众所周知,Windows 常用的文件系统有 FAT32、NTFS,Linux 常用的文件系统有 Ext4、XFS、Btrfs 等,每一种文件系统都有其独特的组织和管理文件的方式,它决定了文件系统的存储能力和性能等特征。JuiceFS 作为一个文件系统也不例外,它的强一致性、高性能等特征离不开它独特的文件管理模式。

与传统文件系统只能使用本地磁盘存储数据和对应的元数据的模式不同,JuiceFS 会将数据格式化以后存储在对象存储(云存储),同时会将文件的元数据存储在专门的元数据服务中。

任何存入 JuiceFS 的文件都会被拆分成固定大小的 "Chunk",默认的容量上限是 64 MiB。每个 Chunk 由一个或多个 "Slice" 组成,Slice 的长度不固定,取决于文件写入的方式。每个 Slice 又会被进一步拆分成固定大小的 "Block",默认为 4 MiB。最后,这些 Block 会被存储到对象存储。与此同时,JuiceFS 会将每个文件以及它的 Chunks、Slices、Blocks 等元数据信息存储在元数据引擎中。

使用 JuiceFS,文件最终会被拆分成 Chunks 并上传至对象存储。因此,你会发现在对象存储平台的文件浏览器中找不到存入 JuiceFS 的源文件,存储桶中只有一个 chunks 目录和一堆数字编号的目录和文件。不要惊慌,这正是 JuiceFS 文件系统高性能运作的秘诀!