leecoool
2 Iron

Re: 分布式文件系统发展史(动态图片,点击就能看到动态模拟)

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

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

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

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

=线性扩展=

一个观念的转变!

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

1:消除元数据(metadata)的同步和更新。

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

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

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

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

=元数据的处理=

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

0 项奖励
Jun_Tan
3 Zinc

Re: 分布式文件系统发展史(动态图片,点击就能看到动态模拟)

楼上

期待你的下文

0 项奖励
leecoool
2 Iron

Re: 分布式文件系统发展史(动态图片,点击就能看到动态模拟)

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

首先,小文件需要什么呢?这个跟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都有,比较反应实际情况的。

饿了,吃饭去了。。

0 项奖励
leecoool
2 Iron

Re: 分布式文件系统发展史(动态图片,点击就能看到动态模拟)

还有个很容模拟的到的场景,如果在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,就变成单点系统了。这种架构下,数据中转次数更多,性能就更差了。。

0 项奖励
Yanhong1
4 Beryllium

Re: 分布式文件系统发展史(动态图片,点击就能看到动态模拟)

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

0 项奖励
Jun_Tan
3 Zinc

Re: 分布式文件系统发展史(动态图片,点击就能看到动态模拟)

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

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

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

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

0 项奖励
leecoool
2 Iron

Re: 分布式文件系统发展史(动态图片,点击就能看到动态模拟)

关于FUSE的问题,说的没错。分布式系统就是要减少系统的耦合。。。。。。。个人愚见:分布式系统所谓的性能,其实是“拿规模换性能”,只有满足一定的规模,才会有性能之说。

glusterfs确实是很依赖于网络的,所以isilon也是用infinitband互联的。。。没记错的话,EMC刚收购的xtreamio貌似也是。

低延迟,高带宽是这类系统的主流。

0 项奖励
leecoool
2 Iron

Re: 分布式文件系统发展史(动态图片,点击就能看到动态模拟)

我把三个合起来了,可能格式上不是很工整。。。。。

0 项奖励
Jun_Tan
3 Zinc

Re: 分布式文件系统发展史(动态图片,点击就能看到动态模拟)

刚才说到infiniband作为分布式文件系统互连网络,可以参考下这里。

Linux + X86 + Infiniband做成的HPC。

用于分布式文件系统的服务器都是采用4x DDR或者QDR做级联。两层网络架构,最大延迟不超过5μ秒

System TypeLatencyBandwidth
TLCC Clusters with DDR Voltaire/Mellanox (Juno, Eos, Hera)~3-5 us~2.4 GB/sec
Intel Xeon Clusters with QDR QLogic (Muir, Sierra, Ansel)~1-2 us~4.1 GB/sec
Intel Xeon Clusters with QDR QLogic (TLCC2)~1 us~5.0 GB/sec

https://computing.llnl.gov/tutorials/lc_resources/

最后说到底,性能也是用钱烧出来的。 

一般企业谁舍得花钱搭建个1000多个节点的infiniband的网络。

0 项奖励
liulei_it
4 Ruthenium

Re: 分布式文件系统发展史(动态图片,点击就能看到动态模拟)

哈哈 EMC可以单独成立一个子公司专门给有需要的客户提供高性能的云存储。

0 项奖励