FastDFS与Ceph的比较

研究分布式存储只看Ceph是不够的,想有个横向对比,看看各有什么优缺点,从而深入对Ceph和分布式存储的理解。我司图片存储使用的是FastDFS,所以从它看起。 因为没有真正使用过,只是为了了解概念,所以浅尝辄止,参考资料比较单一,可能存在误解,里面甚至有我的很多猜测、思考和问题,请想了解FastDFS的同学绕道。 本质差别 FastDFS和Ceph的本质区别:FastDFS不是一个对象存储,是个分布式的文件存储,虽然和传统的NAS有差别,但其本质还是文件存储。所以这个对比其实不是那么横向,差别太大了: FastDFS以文件为单位,Ceph以Object为存储单位 FastDFS没有strip文件,而Ceph(fs)把文件分成object分布在OSD中,read时可以并发,FastDFS没有这样的功能,性能受限于单机 FastDFS节点 FastDFS的节点有两种:tracker和storage。 Tracker节点负责协调集群运作,storage上报心跳、记录storage所属group等,角色有点类似于Ceph中的MON。这些信息很少,且都可以通过storage上报获得无需持久化,所以都存储在内存中,也使得tracker的集群佷容易扩展,每个tracker是平等的。 这里我有一个疑问,既然是平等的,如何保障一致性?是几个节点同步的,还是storage上报时要多写? 我的猜测是靠同步的,因为下面介绍了写流程之后,你会发现其实一致性并不是很重要。一会儿我们再回到这个问题。 Storage就是存储节点了。 Storage以group为单位,一个group内的storage互为备份。每个storage可以挂不同的盘到不同的*path*。 这种备份是简单的镜像,所以一个group的总容量是最低的那个server决定的,没有Ceph CRUSH map的自动依据硬盘大小的weight功能。 文件上传后以hash为依据分布在storage的文件夹中。 FastDFS上传过程 上传文件时,tracker会选择一个group,可以配置以下方式: - RR,轮询 - Specified,指定一个group - Load balance,剩余空间多的优先 选定group之后选择一个storage。规则是: RR Order by IP Order by priority,优先级排序 问题:既然group内的storage是镜像的,为什么还要选择一个上传呢,随机一个不都可以吗? 然后选定path,也就是同一台storage上不同的数据盘: RR 剩余空间多优先 Storage生成fileid:base64({storage IP}{create time}{file size}{file crc32}{random number})。 接着选定两级子目录,这个不重要且很简单,只是为了避免同个目录下的文件过多。 生成文件名,包含: - group - 目录 - 两级子目录 - fileid - 文件后缀(客户端指定,区分类型) 一个文件名的例子:group1/M00/00/0C/wKjRbExx2K0AAAAAAAANiSQUgyg37275.h。 FastDFS文件同步 文件写入上文规则选出的一个storage server即返回成功,再由后台线程同步到其他节点。而Ceph的要求是写入主primary OSD之后所有副本比如第二第三OSD完成之后才返回成功,数据安全性更高。 只primary写完就返回,那其它同group的storage什么时候能提供服务?这个要靠是否同步完成来判断。同步的进度靠primary storage的binlog记录,binlog会同步到tracker,读请求时tracker根据同步进度选择可读的storage。
Read more...