fastdfs 和 ceph 对比

发表于 更新于 分类于 阅读次数： 487 本文字数： 1.9k 阅读时长 ≈ 2 分钟

需求是图片，视频等文件的存储

属于少写多读的场合，修改操作较少。文件粒度是大小文件都有。

fastdfs

先谈谈 fastdfs，我在公司已经应用了两年了，对他的基本特性比较熟悉，在这种场合下有这些优缺点

优点：

1 机器配置要求低。毕竟号称 “穷人的解决方案不是白来的”。不管是上传下载，同步恢复，都对机器的负载要求非常低。

2 上传速度快。因为是弱一致性模型，上传不需要强写副本才能返回。（强一致性模型对网络和机器要求都不会低）

3 已知的大规模成功案例较多，公司内部运维时间长

缺点：

1 小文件的故障恢复时间长，100GB/hour。

2 存在上传成功但丢失文件的可能性。弱一致性模型是双刃剑，如果在刚上传文件后，副本文件尚未产生，此时文件是单点状态。

该状态有两种情况：

一种是文件在磁盘中，等待被同步到其他机器，该情况下宕机，文件还存在（磁盘损毁就不存在了）；

一种是文件还在系统内存中尚未被写入磁盘，此时宕机会导致数据彻底无法恢复

3 没有元数据管理。这一部分我写的 fastdfs 网关已经解决了。

4 大文件直接存储不进行分片，从而分布在整个集群中，当大文件存在热点数据时，压力会出现再整个集群的某组机器上。

这个问题在 fastdfs 网关上加上切片上传的 API 可以缓解

ceph

ceph 在某种角度上和 fastdfs 相当接近，都是想通过文件名，直接算出文件的所属位置。

优点：

1 强一致性模型保证数据可靠性

ceph 的上传成功，是在数据被写入所有副本后返回的，这保证了数据不会在刚上传主节点后就丢失。

2 有元数据管理，甚至有现成的 ceph 网关来提供对象存储

3 大文件进行文件分片，默认 4MB，对用户透明

缺点：

1 已知的大规模成功案例较少。

2 机器配置要求较高，参见官方文档硬件配置

摘抄其中原话 “OSD 的日常运行不需要那么多内存（如每进程 500MB ）差不多了；然而在恢复期间它们占用内存比较大（如每进程每 TB 数据需要约 1GB 内存）。通常内存越多越好。”

携程的配置（携程在 2015/10/18 SH Ceph Day 上的分享）：硬件：CPU (2 channels & 32 Core)、Mem128GB、disk（123TB/SATA disk +2256GB raid1 SSD）、NIC(4*Gigabit LAN, bond 2 in 1 pair)

3 无法充分发挥硬件性能

1）数据双倍写入。Ceph 本地存储接口（FileStore）为了支持事务，引入了日志（Journal）机制。所有的写入操作都需要先写入日志（XFS 模式下），然后再写入本地文件系统。

如果一份数据是三副本，那么客户端每上传 1MB 的数据，会产生 4MB 的磁盘流（网上有测试结果，3 副本 + 日志一共 4 份数据），才算写入成功，如果对时延敏感，那么对网络和磁盘要求都高

2）IO 路径过长。这个问题在 Ceph 的客户端和服务器端都存在。以 osd 为例，一个 IO 需要经过 message、OSD、FileJournal、FileStore 多个模块才能完成，每个模块之间都涉及到队列和线程切换，部分模块在对 IO 进行处理时还要进行内存拷贝，导致整体性能不高。

4 扩容需要迁移文件，小文件迁移时间长

由于 crush 算法是变种哈希，因此当集群扩容后，需要迁移文件，迁移文件时间很长。

扩容的灾难 - CEPH 对象存储海量小文件

原文表述 “文件平均大小 100KB。”“一个 OSD 加入之后，迁移的 IO 压力几乎全部在这一个磁盘上，由于文件小，平均吞吐在 2MByte/s，一个 OSD 需要迁移约 1.5TB 数据，耗时约一个星期，只想说 F U C K。”

5 小文件的故障恢复时间长

这部分我没有做测试，但是 ceph 对小文件是没有合并存储的优化的，这部分和 fastdfs 在一个水平线，甚至由于他的复杂性，可能实际效率比 fastdfs 还要低。

故障恢复的速度和迁移文件的速度一致。

总结

总的来说，个人认为，直接用 ceph 上 PB 级别的数据，有点步子太大的感觉。很多地方感觉都 hold 不住。另外由于 ceph 代码的复杂性，出 BUG 以后是无法立刻解决的。

而 fastdfs 的两个主要问题：

1 恢复时间长，这部分 ceph 也存在。只要恢复时期不是单点，个人认为影响没有那么大。

2 可能丢失刚上传的数据。

可以在上传到 fastdfs 前，先缓存在一个 cache 池中，用于可能的故障恢复。

也可以把 fastdfs 做成强一致性的方案，在 fastdfs 这一层彻底根除这个问题

题外话

fastdfs 和 ceph 方案是相当接近的，有些地方可以参考 ceph。

例如把 tracker 做成 ceph montior 的结构，只有当缩扩容时，才通知客户端节点变化，而不是每次上传客户端都需要连 tracker

另外 fastdfs 可以做成强一致性的方式，这在整体架构上是没有影响的。