fastdfs和ceph对比

原创内容,转载请注明出处

Posted by Weakyon Blog on August 16, 2016

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

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

一 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可以做成强一致性的方式,这在整体架构上是没有影响的。

16 Aug 2016