Glusterfs 分布式文件系统模块和优缺点说明

2019-08-05 0 By admin

Glusterfs是根据fuse提供的接口实现的一个用户态的文件系统,主要包括gluster、glusterd、glusterfs和glusterfsd四大模块组成。

gluster

cli命令执行工具,主要功能是解析命令行参数,然后把命令发送给glusterd模块执行。

glusterd

一个管理模块,处理gluster发过来的命令,处理集群管理、存储池管理、brick管理、负载均衡、快照管理等。集群信息、存储池信息和快照信息等都是以配置文件的形式存放在服务器中,当客户端挂载存储时,glusterd会把存储池的配置文件发送给客户端。

glusterfsd

服务端模块,存储池中的每个brick都会启动一个glusterfsd进程。此模块主要是处理客户端的读写请求,从关联的brick所在磁盘中读写数据,然后返回给客户端。

glusterfs

客户端模块,负责通过mount挂载集群中某台服务器的存储池,以目录的形式呈现给用户。当用户从此目录读写数据时,客户端根据从glusterd模块获取的存储池的配置文件信息,通过DHT算法计算文件所在服务器的brick位置,然后通过Infiniband RDMA 或Tcp/Ip 方式把数据发送给brick,等brick处理完,给用户返回结果。存储池的副本、条带、hash、EC等逻辑都在客户端处理。

Glusterfs 文件访问过程

在使用glusterfs提供的存储服务之前,需要先挂载存储池,向挂载点写数据,会经过fuse内核模块传给客户端,客户端检查存储池的类型,然后计算数据所在服务器 ,最后通过socket或rdma与服务器通信,如图所示:

Glusterfs作为一款开源的分布式文件系统,在开源社区的活跃度很高,目前已经被红帽收购,国内外也有大量的用户在研究和应用,相关技术文档很丰富。它并不完美,为了支持线性扩展和高性能,而在小文件性能和元数据性能上做了让步,但却可以满足一定的场景,如大数据应用和视频存储等。

一、优点

1.1、无元数据节点性能瓶颈

采用无中心对称式架构,没有专用的元数据服务器,也就不存在元数据服务器瓶颈。元数据存在于文件的属性和扩展属性中。当需要访问某文件时,客户端使用DHT算法,根据文件的路径和文件名计算出文件所在brick,然后由客户端从此brick获取数据,省去了同元数据服务器通信的过程。

1.2、良好的可扩展性

使用弹性hash算法代替传统的有元数据节点服务,获得了接近线性的高扩展性。

1.3、高可用

采用副本、EC等冗余设计,保证在冗余范围内的节点掉线时,仍然可以从其它服务节点获取数据,保证高可用性。采用弱一致性的设计,当向副本中文件写入数据时,客户端计算出文件所在brick,然后通过网络把数据传给所在brick,当其中有一个成功返回,就认为数据成功写入,不必等待其它brick返回,就会避免当某个节点网络异常或磁盘损坏时因为一个brick没有成功写入而导致写操作等待。

服务器端还会随着存储池的启动,而开启一个glustershd进程,这个进程会定期检查副本和EC卷中各个brick之间数据的一致性,并恢复。

1.4、存储池类型丰富

包括粗粒度、条带、副本、条带副本和EC,可以根据用户的需求,满足不同程度的冗余。粗粒度卷不带任何冗余,文件不进行切片,是完整的存放在某个brick上。

条带卷不带任何冗余,文件会切片存储(默认大小为128kB)在不同的brick上。这些切片可以并发读写(并发粒度是条带块),可以明显提高读写性能。该模式一般只适合用于处理超大型文件和多节点性能要求高的情况。

副本卷冗余度高,副本数量可以灵活配置,可以保证数据的安全性。

条带副本卷是条带卷和副本卷的结合。

EC卷使用EC校验算法,提供了低于副本卷的冗余度,冗余度小于100%,满足比较低的数据安全性,例如可以使2+1(冗余度为50%)、5+3(冗余度为60%)等。这个可以满足安全性要求不高的数据。

1.5、高性能

采用弱一致性的设计,向副本中写数据时,只要有一个brick成功返回,就认为写入成功,不必等待其它brick返回,这样的方式比强一致性要快。

还提供了I/O并发、write-behind、read-ahead、io-cache、条带等提高读写性能的技术。并且这些都还可以根据实际需求进行开启/关闭,i/o并发数量,cache大小都可以调整。

二、缺点

2.1、扩容、缩容时影响的服务器较多

Glusterfs对逻辑卷中的存储单元brick划分hash分布空间(会以brick所在磁盘大小作为权重,空间总范围为0至232-1),一个brick占一份空间,当访问某文件时,使用Davies-Meyer算法根据文件名计算出hash值,比较hash值落在哪个范围内,即可确定文件所在的brick,这样定位文件会很快。但是在向逻辑卷中添加或移除brick时,hash分布空间会重新计算,每个brick的hash范围都会变化,文件定位就会失败,因此需要遍历文件,把文件移动到正确的hash分布范围对应的brick上,移动的文件可能会很多,加重系统负载,影响到正常的文件访问操作。

2.2、遍历目录下文件耗时

Glusterfs没有元数据节点,而是根据hash算法来确定文件的分布,目录利用扩展属性记录子卷的中brick的hash分布范围,每个brick的范围均不重叠。遍历目录时,需要readdir子卷中每个brick中的目录,获取每个文件的属性和扩展属性,然后进行聚合,相对于有专门元数据节点的分布式存储,遍历效率会差很多,当目录下有大量文件时,遍历会非常缓慢。

删除目录也会遇到同样的问题。

目前提供的解决方法是合理组织目录结构,目录层级不要太深,目录下文件数量不要太多,增大glusterfs目录缓存。另外,还可以设计把元数据和数据分离,把元数据放到内存数据库中(如redis、memcache),并在ssd上持久保存。

2.3、小文件性能较差

Glusterfs主要是为大文件设计,如io-cache、read-ahead、write-behind和条带等都是为优化大文件访问,对小文件的优化很少。

Glusterfs采用无元数据节点的设计,文件的元数据和数据一起保存在文件中,访问元数据和数据的速率相同,访问元数据的时间与访问数据的时间比例会较大,而有元数据中心的分布式存储系统,对元数据服务器可以采用更快速的ssd盘,可以采用更大的元数据缓存等优化措施来减小访问元数据时间与访问数据时间的比值,来提高小文件性能。

Glusterfs在客户端采用了元数据缓存md-cache来提高小文件性能,但是md-cache大小有限,但在海量小文件场景下,缓存命中率会严重下降,优化效果会减小,这就需要增大元数据缓存。

针对小文件性能差的问题,也可以参考TFS的做法, TFS会将大量的小文件合并成一个大文件,这个大文件称为Block,每个Block拥有在集群内唯一的编号(Block Id),Block Id在NameServer创建Block时分配,NameServer维护block与DataServer(存储Block的实际数据)的关系。