分布式文件系统的比较,115网盘用了fastdfs
- 分布式文件系统
|
|
|
|
|
|
|
|
分布式文件系统,作为网盘的基础,应用底层文件管理。而分布式文件系统之上,用户文件的权限,用户目录管理都是由非分布式文件系统管理。
分布式文件系统需要关心的主要内容:
- 文件分布/数据分布:文件是否分片,文件存储按照什么算法来存储(DHT)
- 冗余保护/副本:是否有缀于,缀于是否可以回复。
- 数据可靠性:当数据出现问题,是否可以发现,如何回复。
- 备份:如何提供被被封工作。
- 故障恢复:出现问题是否可以回复。
- 扩展性:当容量不够时,是否可以无限增加容量。
- 安装/部署:是否需要修改内核,部署是否方便。
- 开发语言:是否使用常用开发语言。
- 适合场景:对不同文件大小有常用的支持。
除了一下文件系统,还有HDFS等分布式文件存储系统,MongoDB的GridFs等文件系统。
|
MooseFS(MFS) |
Ceph(Swfit) |
GlusterFS(类似的有FastDFS) |
Lustre |
Metadata server |
单个MDS。存在单点故障和瓶颈。 |
多个MDS,不存在单点故障和瓶颈。MDS可以扩展,不存在瓶颈。 |
无,不存在单点故障。靠运行在各个节点上的动态算法来代替MDS,不需同步元数据,无硬盘I/O瓶颈。 |
双MDS(互相备份)。MDS不可以扩展,存在瓶颈。 |
FUSE(用户态文件访问) |
支持 |
支持 |
支持 |
支持 |
访问接口 |
POSIX |
POSIX |
POSIX |
POSIX/MPI |
文件分布/数据分布 |
文件被分片,数据块保存在不同的存储服务器上。 |
文件被分片,每个数据块是一个对象。对象保存在不同的存储服务器上。 |
Cluster Translators(GlusterFS集群存储的核心)包括AFR、DHT(和Stripe三种类型。 AFR相当于RAID1,每个文件都被复制到多个存储节点上。Stripe相当于RAID0,文件被分片,数据被条带化到各个存储节点上。 Translators可以组合,即AFR和stripe可以组成RAID10,实现高性能和高可用。 |
可以把大文件分片并以类似RAID0的方式分散存储在多个存储节点上。 |
冗余保护/副本 |
多副本 |
多副本 |
镜像 |
无 |
数据可靠性 |
由数据的多副本提供可靠性。 |
由数据的多副本提供可靠性。 |
由镜像提供可靠性。 |
由存储节点上的RAID1或RAID5/6提供可靠性。假如存储节点失效,则数据不可用。 |
备份 |
|
|
|
提供备份工具。支持远程备份。 |
故障恢复 |
手动恢复 |
当节点失效时,自动迁移数据、重新复制副本。 |
当节点、硬件、磁盘、网络发生故障时,系统会自动处理这些故障,管理员不需介入。 |
无 |
扩展性 |
增加存储服务器,可以提高容量和文件操作性能。但是由于不能增加MDS,因此元数据操作性能不能提高,是整个系统的瓶颈。 |
可以增加元数据服务器和存储节点。容量可扩展。文件操作性能可扩展。元数据操作性能可扩展。 |
容量可扩展。 |
可增加存储节点,提高容量可文件操作性能,但是由于不能增加MDS,因此元数据操作性能不能提高,是整个系统的瓶颈。 |
安装/部署 |
简单 |
简单 |
简单 |
复杂。而且Lustre严重依赖内核,需要重新编译内核。 |
开发语言 |
C |
C++ |
C |
C |
适合场景 |
大量小文件读写 |
小文件 |
适合大文件。 对于小文件,无元数据服务设计解决了元数据的问题。但GlusterFS并没有在I/O方面作优化,在存储服务器底层文件系统上仍然是大量小文件,本地文件系统元数据访问是瓶颈,数据分布和并行性也无法充分发挥作用。因此,GlusterFS的小文件性能还存在很大优化空间。 |
大文件读写 |
产品级别 |
小型 |
中型 |
中型 |
重型 |
应用 |
国内较多 |
无 |
较多用户使用 |
HPC领域。 |
优缺点 |
实施简单,但是存在单点故障。 |
不稳定,目前还在实验阶段,不适合于生产环境。 |
无元数据服务器,堆栈式架构(基本功能模块可以进行堆栈式组合,实现强大功能)。具有线性横向扩展能力。
由于没有元数据服务器,因此增加了客户端的负载,占用相当的CPU和内存。 但遍历文件目录时,则实现较为复杂和低效,需要搜索所有的存储节点。因此不建议使用较深的路径。 |
很成熟、很庞大。 |
- 云存储平台学习
- Seafile
包含:群组功能,用户可以创建和加入群组, 在群组中共享文件。这对团队协作很有用。
文件组织成资料库。每个资料库可以单独同步和共享。
在线文件协作,包括文件在线预览、评论、推荐等等。 Markdown, text,源代码等文本格式可以直接在线编辑。
SeaFile主要是“文件属性、路径管理系统”。底层存储系统可以采用Swift和Cept。
- 360等网盘底层
lustre更加适合分布式运算方面的,比如高性能计算节点什么的,在网盘业务这块,个人觉得mooseFS、glusterfs更加靠谱一些吧。Lustre不适合做类似网盘的使用。首先Lustre没有磁盘容错功能;即使实现服务容错也需要交叉互连的盘阵,构建成本较高。其次我认为在网盘服务中,对于存储系统不需要有太强的一致性语义;而lustre采用的是POSIX强一致性语义。lustre靠的数据分条来提高IO性能的,不知道这个和网盘的IO访问模式是否兼容。还有就是lustre是内核态系统,比较复杂,维护较困难。
115网盘用了fastdfs
http://blog.csdn.net/wugeiswuge/article/details/19159055