分布式文件系统选型

源自:

http://my.chinaunix.net/space.php?uid=16480950&do=blog&id=103952

 

 

1.针对目前的情况

业界在大数据量存储方面存在着两种解决方案：集中式存储和分布式存储。

集中式存储的代表厂商：NetApp，EMC，使用集中式存储的互联网代表企业Facebook；

分布式存储的代表厂商兼互联网企业：google。

集中式存储相比分布式存储最大的问题在于购置整个解决方案的成本太高。而分布式存储可以通过软件技术整合利用众多低廉的存储设备，来支撑海量的存储，最大的问题在于研发门槛和成本高。

2.原型选择
针对目前的文件系统业务场景虚拟机存储。多部分都是小文件存储，将来扩展也是往数据库、日志存储。符合这样的基础场景可以有如下的筛选条件：

1）可扩展性；

能动态扩展结点，单个存储结构支持上亿数量级的存储；最好能避免meta data的单点故障和存储限制问题；

2）高可用性；

支持replication，实现数据的自动复制和结点的failover；replication在高并发时也可分减单台存储设备IO；

3）可管理性；

能方便地管理存储结点的增删和配置策略更改，变更生效无需中断服务；（弱管理性可通过定制启动器来加强）

4）可维护性；

要有良好的社区支持和发展前景，最好有明确的Roadmap。

5）性能；

吞吐量越大越好。前提条件是要能够符合当前的业务需求。

6）成功案例；

是否有成功的商业案例，尤其是大型互联网公司的（国内大的互联网公司基本上都是自己实现小文件存储）；

7）可选：Stripe功能，适合于存储大文件；分布式计算，适合于日志分析；

3. 可选择的方案

 

从开源中国分布式文件存储列表的30多个项目中，用上述的标准进行了初步的分析和筛选。最后被保留下来进行进一步分析的候选项目有：

1）Hadoop+SeqFile（MapFile）；

2）SheepDog；

3）Lustre；4）Cassandra；

5）MooseFS；6）GlusterFS；

7）XtreemFS；8）KFS；

 

接下来，我们对以上的这几个项目分别进行了深入了解和分析，排除了以下一些项目：

1）Hadoop+SeqFile（MapFile）；

根据之前对Hadoop做的测试，NameNode是Hadoop最大的一个瓶颈，所以试图通过把小文集聚合存储的方式来解决NameNode的瓶颈问题。而在实验中发现Hadoop目前支持的append是有很大的局限性的，文件的append是建立在write once的基础上的，也就是说一个创建的文件被关闭后就不能再续写。所以Hadoop+SeqFile的方式走不通。

2）SheepDog；

一个非常雏形的项目，部署跟操作系统支持紧密结合，缺乏文档、社区支持和商业案例；

3）Lustre；

Lustre同样存在master单点，但使用nas/san来解决了metadata的单点问题，但是依赖于硬件，另外Lustre的部署需要往linux内核中增加许多自己的模块，安装部署过程过于复杂。其主要的应用场景也是实验室。缺乏成功的商业案例。

4）Cassandra；

增删结点会引起存储数据的移动；同时文件的replication需要被写入文件先完整缓存在内存中，在并发量大时有可能引起内存溢出。

5）MooseFS；

MooseFS的metadata使用内存加载整个文件系统的meta信息，使用镜像文件和editlog来持久化存储，跟Hadoop的metadata存储机制非常相似，Metadata存在扩展的瓶颈；

6）KFS；

Metadata存在瓶颈问题，文档极其稀缺，社区支持比较薄弱。目前在sourceforge上还是alpha版。未有显著的商业案例。

最后候选的项目剩下：

1） GlusterFS；

特点：无Metadata结点，不存在单点失败的问题，不存在容量扩展的瓶颈问题，可支持上PB级的数据；有较多的成功案例，社区支持和发展势头很好；

Replication、Stripe、DHT等功能模块化，能根据需要灵活配置、组合。

优点：下载的性能表现出色，文件大小从300K增长到3M对速度几乎没有影响；

缺点：

1）  GlusterFS跟JAVA的文件操作不是很兼容，在配置了备份功能的场景下，存在数据一致性的安全隐患。若客户端在使用JAVA删除文件时，某存储结点宕机，当宕机结点重新起来，被删除的数据会再次被生成；

2）  GlusterFS的可管理性很差，增删结点需要修改配置，同时客户端需要短暂中断服务进行目录的mount和umount

3）  文件上传不够稳定，存在间歇性停顿的问题，即使只是单线程访问；

4）  上传耗时跟备份数成正比，且在高并发下效率很差，如 300K文件200个并发下，上传需要27s。同一条件下FastDFS只需要2s；

2） XtreemFS；

特点：增加了一个角色DIR，与metedata数据存储角色（MRC）区分，用于管理结点的注册、剔除等。MRC可冗余可分割，DIR可冗余（当前版本未实现）。

如此一来既避免了Hadoop/MooseFS类存储系统的metadata瓶颈和单点问题，也避免了GlusterFS的可管理性差问题。

优点：提供了便捷详尽的服务器状态监控界面，提供了方便的配置策略操作命令。

缺点：

1）性能表现较差，且随着并发数增加或文件大小增加，上传下载速度有明显下降，举例，300K单线程上传需要450ms，而FastDFS只需要12ms；3m单线程上传需要接近6s，而2m单线程FastDFS只需要62ms。

2）多个备份，停止其中一个osd后，上传下载都不成功；

3）客户端操作命令常有死锁现象，死锁进程甚至有kill -9仍然无法停止，很不稳定；

 

综合 测试结论可以尝试一下：FastDFS 。