关于运维:浅析-GlusterFS-与-JuiceFS-的架构异同

在进行分布式文件存储解决方案的选型时，GlusterFS 无疑是一个不可漠视的思考对象。作为一款开源的软件定义分布式存储解决方案，GlusterFS 可能在单个集群中反对高达 PiB 级别的数据存储。自从首次公布以来，曾经有超过十年的倒退历程。目前，该我的项目次要由 Red Hat 负责保护，并且在寰球范畴内领有宏大的用户群体。本文旨在通过比照剖析的形式，介绍 GlusterFS 与 JuiceFS 的区别，为您的团队在技术选型过程中提供一些参考。

零碎架构比照

GlusterFS

GlusterFS 采纳的是全分布式的架构，没有中心化节点。GlusterFS 集群次要由服务端和客户端两大部分组成。其中服务端负责管理和存储数据，通常被称为 可信存储池（Trusted Storage Pool）。这个存储池由一系列对等的 Server 节点组成，个别会运行两类过程：

• glusterd：每个节点一个，负责配置管理和散发等。
• glusterfsd：每个 Brick 一个，负责解决数据申请和对接底层文件系统。

每个 Brick 上的所有文件能够看成是 GlusterFS 的一个子集，就文件内容而言，通过 Brick 间接拜访和通过 GlusterFS 客户端拜访看到的后果通常是统一的。因而，在 GlusterFS 异常情况下，用户通过整合多个 Bricks 内容就能肯定水平上复原出原有数据。另外在部署时，为了确保某台机器故障时，整个文件系统的拜访不受影响，通常会对数据做冗余爱护。在 GlusterFS 中，多个 Bricks 会组成一个冗余组，相互之间通过 正本 或纠删码 的形式实现数据保护。当某个节点故障时，只能在冗余组内做复原，复原的工夫会比拟长。在 GlusterFS 集群扩容时，须要以冗余组为单位整体扩容。

客户端是挂载了 GlusterFS 的节点，负责对应用程序展现对立的命名空间。其架构图如下（来自 https://docs.gluster.org/en/latest/Quick-Start-Guide/Architec…）：

JuiceFS

JuiceFS 采纳「数据 」与「 元数据」拆散存储的架构，文件数据自身会被切分保留在对象存储（如 Amazon S3）当中，而元数据则是会被保留在用户自行抉择的数据库里（如 Redis、MySQL）。通过共享同一个份数据库与对象存储，JuiceFS 实现了一个强一致性保障的分布式文件系统，同时还具备「POSIX 齐全兼容」、「高性能」等诸多个性。JuiceFS 的架构，在其文档有更具体的介绍。

元数据管理比照

GlusterFS 元数据是纯分布式的，没有集中的元数据服务。客户端通过对文件名哈希确定其所属的 Brick；当申请须要跨多个 Bricks 拜访（如 mv，ls 等）时，由客户端负责协调。这种设计架构上比较简单，但当零碎规模扩充时，往往会带来性能瓶颈。比方，ls 一个大目录时可能会须要拜访多个 Bricks 来取得残缺的后果，其中任何一个的卡顿都会导致整个申请变慢。另外，跨 Bricks 批改操作在途中遇到故障时，元数据一致性也比拟难保障。在重大故障时，还可能呈现脑裂，须要手动复原数据到对立版本。

JuiceFS 的元数据存储在一个独立的数据库（称为 元数据引擎）中，客户端会将文件元数据操作转换成此数据库的一个事务，借助数据库的事务能力来保障操作的原子性。这种设计使得 JuiceFS 的实现变得简略，但对元数据引擎提出了较高的要求。目前 JuiceFS 反对三大类 10 种事务型数据库，具体可参见元数据引擎文档。

数据管理比照

GlusterFS 通过整合多个服务端节点的 Bricks（个别构建在本地文件系统之上，如 XFS）来存储数据。因而，它自身提供了肯定的数据管理性能，如散布治理、冗余爱护、故障切换、静默谬误检测等。JuiceFS 则不间接应用硬盘，而是通过对接各种对象存储来治理数据，大部分个性都依赖于对象存储本身的实现。

大文件拆分

在分布式系统中，将大文件拆分成多个小块散列存储在不同节点中是一种常见的优化伎俩。这往往能让利用在拜访此文件时有更高的并发度和整体带宽。

• GlusterFS：不拆分（曾有过 Striped Volume 会拆分大文件，现已不再反对）。
• JuiceFS：文件先按大小拆成 64 MiB 的 Chunks，每个 Chunk 再依据写入模式进一步拆成默认 4 MiB 的 Blocks；具体可参见架构文档。

冗余爱护

• GlusterFS：反对 正本（Replicated Volume）和 纠删码（Dispersed Volume）两种类型。
• JuiceFS：依赖于应用的对象存储。

数据压缩

• GlusterFS：

  • 仅反对 传输层压缩，文件由客户端执行压缩，传输到服务端后再由 Brick 负责解压缩。
  • 不间接实现 存储层压缩，而是依赖于 Brick 应用的底层文件系统，如 ZFS。
• JuiceFS：同时反对 传输层压缩 和存储层压缩，数据的压缩和解压缩都在客户端执行。

数据加密

• GlusterFS：

  • 仅反对 传输层加密，依赖于 SSL/TLS。
  • 曾反对过 存储层加密，但现已不再反对。
• JuiceFS：同时反对 传输层加密 和存储层加密，数据的加密和解密都在客户端进行。

拜访协定

POSIX 兼容性

• GlusterFS：兼容。
• JuiceFS：兼容。

NFS 协定

• GlusterFS：曾有内嵌服务来反对 NFSv3，但现已不再举荐应用，而是倡议用 NFS server 将挂载点导出。
• JuiceFS：不间接反对，须要挂载后通过其余 NFS server 导出。

CIFS 协定

• GlusterFS：内嵌反对 Windows，Linux Samba client 和 macOS 的 CLI 拜访，不反对 macOS Finder。然而，文档中倡议用通过 Samba 将挂载点导出的形式应用。
• JuiceFS：不间接反对，须要挂载后通过 Samba 导出。

S3 协定

• GlusterFS：通过 gluster-swift 我的项目反对，但其最近更新停留在 2017 年 11 月。
• JuiceFS：通过联合 MinIO S3 网关反对。

HDFS 兼容性

• GlusterFS：通过 glusterfs-hadoop 我的项目反对，但其最近更新停留在 2015 年 5 月。
• JuiceFS：残缺兼容 HDFS API。

CSI 驱动

• GlusterFS：曾反对过，但最近版本公布于 2018 年 11 月，且仓库已被标记 DEPRECATED。
• JuiceFS：反对，具体可参见 JuiceFS CSI 驱动文档。

扩大性能

POSIX ACLs

Linux 下对文件的拜访权限管制个别有三类实体，即文件拥有者（owner）、领有组（group）和其余（other）。当咱们有更简单的需要，比方要给本属于 other 的某个特定用户独自赋予权限时，这套机制就做不到了。POSIX Access Control Lists (ACLs) 提供加强的权限治理性能，可用来为任意用户 / 用户组指定权限。

• GlusterFS：反对，且反对 access ACLs 和 default ACLs。
• JuiceFS：不反对。

跨域复制

跨域复制 是指在两套独立的集群间进行数据复制，个别被用来实现异地灾备。

• GlusterFS：反对单向的异步增量复制，但须要两边是同版本的 Gluster 集群。
• JuiceFS：依赖元数据引擎和对象存储本身的复制能力，能够做单向复制。

目录配额

• GlusterFS：反对，且反对限度容量和 / 或文件数。
• JuiceFS：反对，且反对限度容量和 / 或文件数。

快照

• GlusterFS：仅反对存储卷级别的快照，而且须要所有 Bricks 部署在 LVM 精简卷（Thinly-Provisioned LVM）上。
• JuiceFS：不反对快照，但反对目录级别的克隆。

回收站

• GlusterFS：反对，且默认敞开。
• JuiceFS：反对，且默认关上。

比照清单

更多浏览

• 浅析 SeaweedFS 与 JuiceFS 架构异同
• 云上大数据存储：探索 JuiceFS 与 HDFS 的异同
• 浅析三款大规模分布式文件系统架构设计：GFS、Tectonic、JuiceFS