分布式文件系统发展史（动态图片，点击就能看到动态模拟）

很赞的整理和分享！

好东西，收下！

深入学习一下，谢谢楼主的总结分享

太好了 受益匪浅

不过想请教一下，那么以block为基准的SAN storage 应该归属于什么类型的呢？

好好拜读一下，对IT人员转型到云计算、大数据很有帮助。

通过SAN给主机分配的是一个或者多个block设备。

在主机IO模型里面，block和文件系统不在一个层面上，文件系统在block之上，基于block而创建。我们可以在从SAN分配过来的设备上面创建任何类型的文件系统。

注意：如果需要创建集群文件系统，必须在共享的block设备上面创建。（可以是SAN，iscsi SAN，DRBD）

谢谢

谢谢楼主的分享。。。不过无论是从原理还是实际测试使用结果，glusterfs都非常“不”适合小文件的存储。。。。

个人认为gluster适用于小文件原因是gluster通过在原生文件系统上面添加扩展属性来标识文件，不需要集中的元数据文件服务器。

看上去楼上对gluster经验丰富，不如给大家分享下。

简单讲讲吧。。。献丑了，呵呵，先发一段以前写的介绍，很久没更新了。

GlusterF 是一个能够提供全局名字空间，分布式的前端，能够方便的扩展到PB级别的开源集群文件系统。本文主要介绍GlusterFs的架构原理和它们如何实现

一个存储架构的核心是它所有的新观点是应该做些什么。显然，这个系统应该是能够线性扩展的，高弹性，能够提供很好的性能。在这之上，GlusterFs引入了可以在通用廉价硬件上实施、水平扩展和高性能高容量。

下面我们来简要说明GlusterFs的几个特性

=线性扩展=

一个观念的转变！

通常意义上来讲，一个存储如果要做到真正的线性扩展，需要解决三个根本问题：

1：消除元数据（metadata）的同步和更新。

2：有效地数据分布从而达到高扩展性和高可靠性。

3：并发执行来达到高性能。

让我们来想象下这些重大的改变：当能够弹性维护的时候达到高扩展性，甚至更好。平衡的系统也能够增强系统的性能。

为了能够理解这些这是怎么实现的，我们下面来分析一下

=元数据的处理=

GlusterFs的很大的优点就是元数据从各种依赖里解放。很多商业性的存储里都包含有各种各样的元数据。不过是我们常见的netapp，还是emc，都有很多的元数据。很多文件系统都是以元数据为中心的。显而易见，有了元数据，那么存方元数据的节点就显得格外重要。而GlusterFs是通过“no-metadata server”架构来消除瓶颈，从而达到高扩展，高可靠性和高性能。

楼上

期待你的下文

下面再来说说为什么从理论上分析小文件不适合呢？

首先，小文件需要什么呢？这个跟OLTP在块设备上类似，需要较高的QPS（query per second），当然吞吐量也是有一定要求的，吞吐量仍然需要基于高QPS的性能。

而glusterfs的弹性hash，虽然没有元数据的问题，但是hash这一层需要一定的性能损耗。此其一；glusterfs基于后端的文件系统和网络交互，没有个高效的文件系统支撑和cache策略，没有较好的网络传输环境，因此在通常的linux+sas+千兆的环境下，性能是非常差的。他原生支持infinitband也是希望解决这个问题。这个和isilon有类似的情况，此其二。glusterfs的原生client实现是基于FUSE的，作为用户空间的实现，效率不高。

读取的时候glusterfs默认从第一个配置的第一个brick读取数据，其他的copy用不了，导致所有的copy不能负载均衡。这个倒是可以更改配置完成。

三个方面还是非常直接的决定了小文件的性能，不过glusterfs也在3+版本中不断的优化小文件性能，包括很多cache策略等等，当然硬伤我觉得是无法回避的。

至于测试报告等等，详细内容由于公司政策，不确定是否能公开，请见谅。。。测试报告表明，对于不追求效率的大文件，glusterfs性能还是不错的。

我搭的glusterfs集群，从几十T到几百T，SAS和SATA都有，比较反应实际情况的。

饿了，吃饭去了。。

还有个很容模拟的到的场景，如果在glusterfs的目录下，创建很多，比如1000个文件或者目录，然后对这个目录简单操作一下，比如ls -al，那么你会发现你的命令hang住了n秒，然后才能返回。你可以看到，在这个过程中，网卡流量很大，glustefs其实要去各个节点上把数据取回来。由于千兆网的速度限制，返回结果很慢。1000个其实并不算多。往往在小文件的场景下，都是亿级的，在路径写入策略上无论怎么做hash，都很难避免两个：1路径层级过深2单一目录下文件数过多。所有应用场景有类似需求的，必慢无疑。

在NetApp和EMC的NAS，对单一层级的目录或文件数都是有限制的，也是考虑到性能。不过这个是文件存储的通病，不特针对glusterfs

除了glusterfs原生客户端，glusterfs还原生支持nfs server。其实这个nfs server，就是把自己当做glusterfs client，再把文件系统共享出去。这个简单方便，但是缺少HA，如果这个server挂了，所有对应的client都无法访问glusterfs，就变成单点系统了。这种架构下，数据中转次数更多，性能就更差了。。

其实ls性能问题跟gluster本身取消了元数据服务器有关系。由于没有元数据服务器，所有相关信息需要去每台服务器上面查询，性能自然就慢了。

详细参考这篇文章：http://gluster.org/community/documentation//index.php/GlusterFS_Technical_FAQ

另外我很赞同你关于单一层级的目录或文件数量应该有效限制的观点，其实这是所有文件系统的通病。（这个只能是通过规划设计来尽量避免这个问题）。

绝大多数分布式文件系统都是基于用户态实现，架构也是一种松耦合的模型。要想分布式文件系统获得最好性能，系统架构设计也至关重要。比如：限定业务需求，后端连接采用更优秀的网络（10G、40G的以太网、Inifiniband）。

leecoool，我建议你把三个帖子整理成一个，可以创建个文档分享给大家 是很不错的经验总结啊