我现在有海量的数据文件(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服务中的每一台服务器使用。

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

Lustre集群文件系统介绍及Lustre I/O性能特点与最佳实践

Lustre集群文件系统最大特征是高扩展性和高性能，能够支持数万客户端系统、PB级存储容量、数百GB的聚合I/O吞吐量。Scale-Out存储架构。

Lustre,集群文件系统,文件系统