MooseFS使用总结

MooseFS使用总结2010-12-08 12:55 阿炯流行的开源分布式文件系统比较我现在有海量的数据文件(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服务器有单点依赖，用c编写，性能相对较好，国内用的人比较多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用在生产环境中。

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

最后我选择了缺点和优点同样明显的mooseFS。

虽然它有单点依赖，它的master非常占内存。

但是根据我的需求，mooseFS已经足够满足我的存储需求。

国内mooseFS的人比较多，并且有很多人用在了生产环境，更加坚定了我的选择。

一、MFS介绍：Distinctive features of MooseFS are:MooseFS优越特性如下：- higher reliability (data can be stored in several copies on separate computers)高可用性(数据可以存储在多个机器上的多个副本)- dynamically expanding disk space by attaching new computers/disks可动态扩展随时新增加机器或者是磁盘- possibility of storing deleted files for a defined period of time ("trash bin" service on a file system level) 可回收在指定时间内删除的文件(“垃圾回收站”是一个系统级别的服务)- possibility of creating snapshot of a file, which means coherent copy of the whole file, even while the file is being written.可以对整个文件甚至在正在写入的文件创建文件的快照。

MFS文件系统结构: 包含4种角色:管理服务器managing server (master) ：负责各个数据存储服务器的管理，文件读写调度，文件空间回收以及恢复.多节点拷贝。

single computer managing the whole filesystem,storing metadata for every file (information on size, attributes and file localisation(s), including all information about non-regular files, i.e.directories, sockets, pipes and devices).单个机器管理整个文件系统，用来存储记录每一个文件的Metadata(记录文件的大小、文件的属性、文件的位置，也包括非规则文件的系统，如目录、sockets、管道和设备)元数据日志服务器Metalogger server(Metalogger)：负责备份master服务器的变化日志文件，文件类型为changelog_ml.*.mfs，以便于在master server出问题的时候接替其进行工作。

数据存储服务器data servers (chunkservers) ：负责连接管理服务器,听从管理服务器调度，提供存储空间，并为客户提供数据传输。

客户机挂载使用client computers ：通过fuse内核接口挂接远程管理服务器上所管理的数据存储服务器,.看起来共享的文件系统和本地unix文件系统使用一样的效果。

说说mfs优势：一)、Free(GPL)0. 通用文件系统，不需要修改上层应用就可以使用(支持fuse)。

1. 可以在线扩容，体系架构可伸缩性极强。

2. 部署简单。

3. 体系架构高可用，除开master组件无单点故障。

4. 文件对象高可用，可设置任意的文件冗余程度，而绝对不会影响读或者写的性能。

5. 提供Windows回收站的功能。

6. 提供类似Java语言的GC(垃圾回收)。

7. 提供netapp，emc，ibm等商业存储的snapshot特性。

8. google filesystem的一个c实现。

9. 提供web gui监控接口。

10. 提高随机读或写的效率。

11. 提高海量小文件的读写效率。

可能的瓶颈：0). master本身的性能瓶颈。

mfs系统master存在单点故障如何解决？网上有人提供moosefs+drbd+heartbeat 来保证master单点问题？不过在使用过程中不可能完全不关机和间歇性的网络中断！短期对策：按业务切分1). 体系架构存储文件总数的可遇见的上限。

(mfs把文件系统的结构缓存到master的内存中，个人认为文件越多，master的内存消耗越大，8g对应2500kw的文件数，2亿文件就得64GB内存)。

短期对策：按业务切分2). 单点故障解决方案的健壮性。

二、mfs各元素主要配置文件1、master主服务器Metadata is stored in memory of the managing server and simultaneously is being saved on disk (as aperiodically updated binary file and immediately updated incremental logs). The main binary file as well as the logs are replicated to metaloggers (if present).Metadata元数据存储在master服务器的内存中，同时也保存在磁盘上(作为一个定期更新的二进制文件，并实时的更新changelog日志)。

如果存在metaloggers的话，主要的二进制文件以及日志也复制到metaloggers中。

How much CPU/RAM resources are used?消耗多少CPU和内存资源In our environment (ca. 500 TiB, 25 million files, 2 million folders distributed on 26 million chunks on 70 machines) the usage of chunkserver CPU (by constant file transfer) is about 15-20% and chunkserver RAM usually consumes about 100MiB (independent of amount of data).在我们的测试环境中(大约500 TiB的数据，250万份文件，200万文件夹，分成260万块分布在70机器上)，chunkserver的CPU使用情况为(持续的文件传输)约为15-20％同时chunkserver内存使用100MiB(和数据量的多少无关)。

The master server consumes about 30% of CPU (ca. 1500 operations per second) and 8GiB RAM. CPU load depends on amount of operations and RAM on number of files and folders.master服务器消耗约30％的CPU(每秒钟约1500次操作)和8G的内存。