分布式文件系统：GridFS vs. GlusterFS vs Ceph vs HekaFS 基准测试 [关闭]答案

【问题标题】：Distributed File Systems: GridFS vs. GlusterFS vs Ceph vs HekaFS Benchmarks [closed]分布式文件系统：GridFS vs. GlusterFS vs Ceph vs HekaFS 基准测试 [关闭]
【发布时间】：2013-06-29 19:04:48
【问题描述】：

我目前正在寻找一个好的分布式文件系统。

应该：

开源
可水平扩展（复制和分片）
没有单点故障
占用空间相对较小

以下是我认为最有前途的四个候选人：

GridFS（基于 MongoDB）
GlusterFS
Ceph
HekaFS

文件系统将主要用于媒体文件（图像和音频）。有非常小的和中等大小的文件（1 KB - 10 MB）。文件的数量应该在几百万左右。

是否有关于性能、CPU负载、内存消耗和可扩展性的基准？您使用这些或其他分布式文件系统有何经验？

【问题讨论】：

这不是购物问题吗？
不，这是关于选择一个好的开源工具
使用 weed-fs（或现在称为 seaweed-fs）。它是为存储这些文件而构建的，最初是作为 facebook 的 haystack paper 的实现。 github.com/chrislusf/weed-fs
我本来打算选择 seaweedfs，直到我注意到它不再被积极开发并且它还没有达到 1.0 的事实
好问题，有时，好问题会在 SE 中关闭。这是 SE 的问题之一。

标签： filesystems gridfs glusterfs ceph

【解决方案1】：

我不确定您的列表是否完全正确。这取决于文件系统的含义。

如果您的意思是一个可安装在操作系统中并且可供任何使用 POSIX 调用读写文件的应用程序使用的文件系统，那么 GridFS 并不真正符合条件。这就是 MongoDB 存储 BSON 格式对象的方式。它是一个Object system，而不是一个文件系统。

有a project 可以生成GridFS mountable，但这有点奇怪，因为GridFS 没有分层目录之类的概念，尽管允许使用路径。另外，我不确定 gridfs-fuse 上的分布式写入会如何。

GlusterFS 和 Ceph 具有可比性，并且是分布式、可复制的可挂载文件系统。你可以read a comparison between the two here（和followup update of comparison），但请记住，基准测试是由有点偏见的人完成的。也可以看this debate on the topic。

至于 HekaFS，它是为云计算而设置的 GlusterFS，添加了加密和多租户以及管理 UI。

【讨论】：

感谢您的精彩解释和 cmets。你是对的，我对文件系统这个术语不太正确。只要有办法直接从网络服务器传递文件，我就可以接受对象系统之类的东西。这就是nginx-gridfs 发挥作用的地方。对我很有用。我感觉 glusterfs 和 ceph 的设置和配置要困难得多
请注意，ceph 有几个方面：rados 是底层对象存储，对于大多数语言来说非常可靠和库； radosgw 是一个 S3/Swift 兼容系统； rbd 是一个共享块存储（类似于 iSCSI，由 KVM、OpenStack 等支持）； CephFS 是符合 POSIX 的可挂载文件系统。

【解决方案2】：

在与 Ceph 合作 11 个月后，我得出的结论是它非常糟糕，因此我建议避免使用它。我尝试了 XtreemFS、RozoFS 和 QuantcastFS，但发现它们也不够好。

我全心全意地推荐 LizardFS，它是 ~~现在专有~~ MooseFS 的一个分支。 LizardFS 具有数据完整性、监控和卓越性能，几乎没有依赖项。

2019 年更新：情况发生了变化，LizardFS 不再积极维护。
MooseFS 比以往任何时候都更强大，并且没有大多数 LizardFS 错误。 MooseFS 维护良好，比 LizardFS 快。

RozoFS 已经成熟，也许值得一试。
GfarmFS 有其利基，但今天我会为大多数应用程序选择 MooseFS。

【讨论】：

哇，这么多我没听说过的名字
GfarmFS 是另一个不错的文件系统。
我在 20 台服务器上使用 XtreemFS 进行生产，每台服务器都有 5x2TB 硬盘。我可以说我对此感到非常高兴。为什么你特别不喜欢它？
因为我测试了XtreemFS，发现效果不好。存在数据损坏（#359）、降级模式读取错误（#357/#235）、只读模式残缺（#358）等问题；构建系统是一团糟，加上 XtreemFS 依赖于旧的（自 2007 年以来未更新）非免费 JAR（#309、#173），因此 XtreemFS 违反了 DFSG 并且不能在 Debian 中分发。此外，我对开发人员如何应对错误感到不满意。最后，XtreemFS 是用低效的内存管理而臭名昭著的糟糕语言编写的，因此 XtreemFS 在性能比较中自然无法与 GfarmFS 和 LizardFS 抗衡......

【解决方案3】：

OrangeFS，有人吗？

我正在寻找 HPC DFS 并在此处找到此讨论： http://forums.gentoo.org/viewtopic-t-901744-start-0.html

很多很好的数据和比较:)

经过一番讨论，OP 决定使用 OrangeFS，引用： “OrangeFS。它不支持配额也不支持文件锁（尽管所有 i/o 操作都是原子的，而这方式保持一致性没有锁）。但它有效，并且运作良好且稳定。此外这是不是面向通用文件存储的系统，而是 HPC 专用系统，针对并行 I/O，包括 ROMIO 支持。所有测试都是针对条带数据分布进行的。 a) 没有配额——地狱配额。无论如何我都放弃了，即使 glusterfs 支持也不常见基于 uid/gid 的配额，但目录大小限制，更像 LVM 的作品。 b) 支持多个活动的元数据服务器并且稳定。与专用元数据相比存储（单节点）这在小文件上提供了 +50% 的性能，并且在小文件上没有显着差异大的。 c) 在大数据块（dd bs=1M）上表现出色。它受本地硬盘总和的限制（不要忘记每个节点也作为数据服务器参与）速度和可用网络带宽。这种负载下的 CPU 消耗是不错的，大约是客户端节点上单核的 50%，大约其他数据服务器节点上的 10%。 d) 在大量小文件上表现公平。为了测试，我解压了 linux 内核 3.1。花了5分钟在 OrangeFS（调整参数）和 NFSv4（也调整）上将近 2 分钟进行比较。 CPU负载约为客户端单核的50％（当然，它实际上是分布在内核之间）和每个节点上大约百分之几。 e) 支持 ROMIO MPI I/O API。这是 MPI 感知应用程序的甜蜜美味，它允许使用 PVFS2/OrangeFS 并行输入输出特性直接来自应用程序。 f) 不支持特殊文件（套接字、fifo、块设备）。因此不能安全地用作 /home 而我使用 NFSv4 用于为用户提供受配额限制的小型家庭空间的任务。虽然分布最广文件系统无论如何都不支持特殊文件。 "

【讨论】：

OrangeFS 很有趣，但是……它是 FTBFS (v2.9.0)；它还没有数据完整性检查（待实施）；它的错误跟踪器已关闭，因此我无法提交错误报告... :(
对你来说太晚了，我敢肯定，但 OrangeFS（以及之前的 PVFS）是老派。向邮件列表发送电子邮件以报告错误。
顺便说一句...我正在测试 FhGFS (FraunhoferFS) 并决定使用它。宣传不多，但很扎实。

【解决方案4】：

我不知道您发布的其他系统，但我对本地存储与 GlusterFS 上的 3 个 PHP CMS/框架进行了比较，看看它在实际测试中是否比原始基准测试更好。可惜没有。

http://blog.lavoie.sl/2013/12/glusterfs-performance-on-different-frameworks.html

【讨论】：