未解决
此帖子已超过 5 年
605 消息
2
15133
分布式文件系统发展史(动态图片,点击就能看到动态模拟)
分布式存储在大数据、云计算、虚拟化场景都有用武之地,在大部分场景还至关重要。
对于一个IT从业人员,学习分布式存储相关基础知识必不可少。
今天给大家简要介绍*nix平台下分布式文件系统的发展历史。
1、单机文件系统
用于操作系统和应用程序的本地存储。
缺点:数据无法再服务器之间共享。
典型代表:Ext2、Ext3、Ex4、NTFS、FAT、FAT32、XFS、JFS...
IO模型:
2、网络文件系统(简称:NAS)
基于现有以太网架构,实现不同服务器之间传统文件系统数据共享。
缺点:两台服务器不能同时访问修改,性能有限。
典型代表:NFS、CIFS
IO模型:
3、集群文件系统
在共享存储基础上,通过集群锁,实现不同服务器能够共用一个传统文件系统。
缺点:性能一般,扩展性很有限(小于16台服务器)。
典型代表:GFS(Redhat)、GFS2(Redhat)、OCFS(Oracle)
IO模型:
GFS、GFS2模型如下:
默认上面三种文件系统模块都位于内核里面,NFS over Inifiband可以使用kernel bypass绕开内核。
4、分布式文件系统
在传统文件系统上,通过额外模块实现数据跨服务器分布,并且自身集成raid保护功能,可以保证多台服务器同时访问、修改同一个文件系统。性能优越,扩展性很好,成本低廉。
缺点:适用场景单一,部分类型存在单点故障风险。
典型代表:lustre(Oracle)、HDFS(ASF)、gluster(Redhat)
IO模型:
主要分两大类型:一种是元数据集中管理模型;另一种是元数据分散管理模型
lustre(Oracle)
HDFS(ASF)
lustre和HDFS是元数据集中管理典型代表。实际数据分布存放在数据服务器上,元数据服务器负责IO请求调配,空间分配;非常适用于大文件存储。
元数据服务器可能成为系统扩展的瓶颈。
gluster(Redhat)
gluster是元数据分散管理模型典型代表,元数据被分散放置到所有服务器上,不存在元数据单点故障。非常适用于小文件存储。
参考资料:
http://www.stalker.com/notes/SFS.html
Jason_Zhou
1.2K 消息
0
2012年8月20日 02:00
很赞的整理和分享!
SteveZhou
136 消息
0
2012年8月20日 02:00
好东西,收下!
Yanhong1
1.6K 消息
0
2012年8月20日 02:00
深入学习一下,谢谢楼主的总结分享
liulei_it
2 Intern
2 Intern
•
3.2K 消息
0
2012年8月20日 06:00
太好了 受益匪浅
不过想请教一下,那么以block为基准的SAN storage 应该归属于什么类型的呢?
Asadeer
290 消息
0
2012年8月20日 18:00
好好拜读一下,对IT人员转型到云计算、大数据很有帮助。
Jun_Tan
605 消息
0
2012年8月20日 18:00
通过SAN给主机分配的是一个或者多个block设备。
在主机IO模型里面,block和文件系统不在一个层面上,文件系统在block之上,基于block而创建。我们可以在从SAN分配过来的设备上面创建任何类型的文件系统。
注意:如果需要创建集群文件系统,必须在共享的block设备上面创建。(可以是SAN,iscsi SAN,DRBD)
liulei_it
2 Intern
2 Intern
•
3.2K 消息
0
2012年8月21日 06:00
谢谢
leecoool
89 消息
0
2012年8月21日 18:00
谢谢楼主的分享。。。不过无论是从原理还是实际测试使用结果,glusterfs都非常“不”适合小文件的存储。。。。
Jun_Tan
605 消息
0
2012年8月21日 20:00
个人认为gluster适用于小文件原因是gluster通过在原生文件系统上面添加扩展属性来标识文件,不需要集中的元数据文件服务器。
看上去楼上对gluster经验丰富,不如给大家分享下。
leecoool
89 消息
0
2012年8月21日 20:00
简单讲讲吧。。。献丑了,呵呵,先发一段以前写的介绍,很久没更新了。
GlusterF 是一个能够提供全局名字空间,分布式的前端,能够方便的扩展到PB级别的开源集群文件系统。本文主要介绍GlusterFs的架构原理和它们如何实现
一个存储架构的核心是它所有的新观点是应该做些什么。显然,这个系统应该是能够线性扩展的,高弹性,能够提供很好的性能。在这之上,GlusterFs引入了可以在通用廉价硬件上实施、水平扩展和高性能高容量。
下面我们来简要说明GlusterFs的几个特性
=线性扩展=
一个观念的转变!
通常意义上来讲,一个存储如果要做到真正的线性扩展,需要解决三个根本问题:
1:消除元数据(metadata)的同步和更新。
2:有效地数据分布从而达到高扩展性和高可靠性。
3:并发执行来达到高性能。
让我们来想象下这些重大的改变:当能够弹性维护的时候达到高扩展性,甚至更好。平衡的系统也能够增强系统的性能。
为了能够理解这些这是怎么实现的,我们下面来分析一下
=元数据的处理=
GlusterFs的很大的优点就是元数据从各种依赖里解放。很多商业性的存储里都包含有各种各样的元数据。不过是我们常见的netapp,还是emc,都有很多的元数据。很多文件系统都是以元数据为中心的。显而易见,有了元数据,那么存方元数据的节点就显得格外重要。而GlusterFs是通过“no-metadata server”架构来消除瓶颈,从而达到高扩展,高可靠性和高性能。
Jun_Tan
605 消息
0
2012年8月21日 20:00
楼上
期待你的下文
leecoool
89 消息
0
2012年8月21日 20:00
下面再来说说为什么从理论上分析小文件不适合呢?
首先,小文件需要什么呢?这个跟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都有,比较反应实际情况的。
饿了,吃饭去了。。
leecoool
89 消息
0
2012年8月21日 22:00
还有个很容模拟的到的场景,如果在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,就变成单点系统了。这种架构下,数据中转次数更多,性能就更差了。。
Jun_Tan
605 消息
0
2012年8月21日 23:00
其实ls性能问题跟gluster本身取消了元数据服务器有关系。由于没有元数据服务器,所有相关信息需要去每台服务器上面查询,性能自然就慢了。
详细参考这篇文章:http://gluster.org/community/documentation//index.php/GlusterFS_Technical_FAQ
另外我很赞同你关于单一层级的目录或文件数量应该有效限制的观点,其实这是所有文件系统的通病。(这个只能是通过规划设计来尽量避免这个问题)。
绝大多数分布式文件系统都是基于用户态实现,架构也是一种松耦合的模型。要想分布式文件系统获得最好性能,系统架构设计也至关重要。比如:限定业务需求,后端连接采用更优秀的网络(10G、40G的以太网、Inifiniband)。
Yanhong1
1.6K 消息
0
2012年8月21日 23:00
leecoool,我建议你把三个帖子整理成一个,可以创建个文档分享给大家 是很不错的经验总结啊