2011-10-12 15:18:26
来 源
中存储网
文件系统
海量的数据文件(1000万个文件)需要存储,我开始寻找一个真正的分布式文件系统,来解决我的存储难题。

我现在有海量的数据文件(1000万个文件)需要存储,需要让其他计算机可以很容易地访问,数据无价,我还希望这个文件系统带冗余功能。

我首先注意到的是Ubuntu Enterprise Cloud的提供者:Eucalyptus。它提供了和AWS(Amazon Web Service)几乎完全兼容的云计算接口。看起来似乎是个云存储的靠谱解决方案。

Eucalyptus模仿Amazon的S3服务,提供了一个叫做Walrus的存储服务组件。

可是,经过一番探索,我发现Eucalyptus想说爱你不容易。

一方面是因为Eucalyptus配置起来很麻烦,缺乏文档,网上几乎找不到任何相关帮助,

另一方面,虽然理论上Eucalyptus和AWS的EC2/S3兼容,但实际上并非如此,很多在AWS上可以用的工具,在Eucalyptus上就无法使用

最关键是,直到最后我把Walrus配置完成之后,才发现Walrus根本不像我想的那样,是一个带冗余的云存储系统。而只是一个实现了S3接口的单机软件而已。

实际上Walrus和Eucalyptus的另一个组件sc(storage controller)没有任何关联,Walrus只是提供了和S3一致的接口,而它的实现方式,既不带冗余,也不能分开部署在多台服务器上。

于是我开始寻找一个真正的分布式文件系统,来解决我的存储难题。一找才发现,市面上各种分布式文件系统品种繁多,层出不穷。列举几个主要的:

mogileFS:Key-Value型元文件系统,不支持FUSE,应用程序访问它时需要API,主要用在web领域处理海量小图片,效率相比mooseFS高很多。

fastDFS:国人在mogileFS的基础上进行改进的key-value型文件系统,同样不支持FUSE,提供比mogileFS更好的性能。

mooseFS:支持FUSE,相对比较轻量级,对master服务器有单点依赖,用perl编写,性能相对较差,国内用的人比较多

glusterFS:支持FUSE,比mooseFS庞大

ceph:支持FUSE,客户端已经进入了linux-2.6.34内核,也就是说可以像ext3/rasierFS一样,选择ceph为文件系统。彻底的分布式,没有单点依赖,用C编写,性能较好。基于不成熟的btrfs,其本身也非常不成熟。

lustre:Oracle公司的企业级产品,非常庞大,对内核和ext3深度依赖

NFS:老牌网络文件系统,具体不了解,反正NFS最近几年没发展,肯定不能用。

本来我打算用mogileFS,因为它用的人最多,而且我的主要需求都是在web方面。

但是研究了它的api之后发现,Key-Value型文件系统没有目录结构,导致不能用list某个子目录的所有文件,不能直接像本地文件系统一样操作,干什么事情都需要一个api,让人十分不爽。

mogileFs这种做法,可能是受同一个开发团队的另一个大名鼎鼎的产品memcached的侦听端口+api模式影响,也有可能是mogileFS刚开始设计的时候,FUSE还没有开始流行。

总之我决心要找一个支持FUSE的分布式文件系统,最后就在mooseFS, glusterFS, ceph中选择。从技术上来看,ceph肯定是最棒的,用c编写,进入linux-2.6.34内核,基于btrfs文件系统,保证了它的高性能,而多台master的结构彻底解决了单点依赖问题,从而实现了高可用。可是ceph太不成熟了,它基于的btrfs本身就不成熟,它的官方网站上也明确指出不要把ceph用在生产环境中。

而且国内用的人较少,linux发行版中,ubuntu10.04的内核版本是2.6.32,仍然不能直接使用ceph。

而glusterFS比较适合大型应用,口碑相对较差,因此也不考虑。

最后我选择了缺点和优点同样明显的mooseFS。虽然它有单点依赖,它的master非常占内存。但是根据我的需求,mooseFS已经足够满足我的存储需求。国内mooseFS的人比较多,并且有很多人用在了生产环境,更加坚定了我的选择。

打算用一台高性能服务器(双路至强5500, 24GB内存)作为为master,两台HP DL360G4(6块SCSI 146GB)作为chunk服务器,搭建一个冗余度为2的分布式文件系统,提供给web服务中的每一台服务器使用。

本文转自沈二铺子博客,原文链接:流行的开源分布式文件系统比较

 

声明: 此文观点不代表本站立场;转载须要保留原文链接;版权疑问请联系我们。