Total Pageviews

Wednesday, 6 April 2016

当前比较适用的海量小文件系统的架构方案

现在的网站越做越大了,存储的东西越来越多,如何解决这些文件存储也成了新的难题。如果把这些文件都完全采用大硬盘存储来解决,并不是一个好主意,因为数据量越大风险就越高,虽然文件能存得下,但是故障率相应会较高,另外重建耗费时间也比较长。所以最好的办法是尽可能考虑分布式存储,把文件想办法利用网络分散到多个机器上。

从我所了解的存储结构来看,分布式存储大致可以分为几种:

1、类googlefs的分布式文件系统

因为目前googlefs没有开源,所以网上出现的分布式文件系统都是利用google的方案自行实现的。这个方案的优点是可用性比较高,基本上基于硬盘的应用都可以处理,可用范围就比较广泛。我看了gfs、gfs2、ocfs2、FastDFS、MogileFS的一些相关介绍,大致有一些认识
https://sourceforge.net/projects/e2fsprogs/ ,The Ext2 Filesystem Utilities (e2fsprogs) contain all of the standard utilities for creating, fixing, configuring , and debugging ext2 filesystems.

首先是文档比较少而出现的问题倒不少;然后是目前这些还没有一个能称得上是稳定版本,如果有的话,估计也就是其中一些收费的版本。因为磁盘存储乃是致关重要,所以目前建议还是不要轻易把这些东西部署到重要的地方。假如非常想使用的话,最好是做好充分测试,确保它的功能完全能够满足需要;然后还要想办法在传统的文件系统中做好完全的备份,以免造成损失。

另外可以提的一个东西是memcached,这个东西实现了内存的分布式共享,稳定度貌似比以上这些分布式文件系统要稳定。不过是完全基于内存的,如果数据量不是很大,可以一试。

2、手工使用文件路径分散存储

这个结构通常使用在web静态文件中,就以这种情形作为例子。

如果这些文件数量比较大,可以通过分散文件路径,把某个文件的访问指定到特定的一台或几台服务器上。例如:

1)采用域名的分散策略

例如使用a.xxx.com/b.xxx.com...来区分标记为a或b的一系列文件,这些文件存储的时候,依然按照标记,存到a或b的服务器上。这个策略将区分机器的任务交由dns服务器来执行,扩容时会相应轻松。这需要web项目初期就规划好这些东东,后期才转用域名策略的成本比较高甚至不可以实现。

2)采用目录的分散策略

假如域名初期并没有规划使用域名策略,那么可以采用代理服务器来进行目录级的划分。比如一般存储大量文件时,因为文件系统的限制以及效率问题,都会按照一定规则划分了很多级的目录,按这些目录拆分机器也并不是困难的事情。这种架构的问题在于代理服务器的性能和可靠性问题,需要在这点上稍下一点功夫。

以上这两个方案,都要自行制定策略实现分散同步传输,传输一般可以归纳为推送和抓取两种办法,同步的话可以采用日志同步(把要同步的数据记入日志,通过日志记录来传输相应文件)、比较同步(使用rsync等同步软件)或即时同步(有新的修改就立刻传输);另外要实现单点故障剔除的话,首先找一个策略把文件存储到多个节点上,例如,a.xxx.com或目录a的文件相应也存到b和c节点;然后在环境中使用故障剔除技术(lvs或nginx等),就可以解决问题,例如:采用域名的话,可以采用lvs,缺点是使用的机器就会成倍增加;亦可再用一级代理服务器,缺点是会牺牲性能。采用目录的话,因为本身就用到了代理服务器,所以只要存储得当,实现比较容易。