扫一扫微信二维码

海量“小文件”优化秘籍:GlusterFS 发布时间:2016-07-06


前言
互联网的触角已融入到生活细节,人们习惯将越来越多的照片、短视频等上传至服务器存储、调用。在互联网(尤其是移动互联网)、物联网、云计算、大数据等高速发展的大背景下,数据呈现爆炸式地增长。“小文件”,特别是海量小文件的存储越来越被人们所需要。
业界也有很多文件系统专门针对小文件进行优化的分布式文件系统。例如国外的Facebook专门推出的Haystack,国内淘宝的开源TFS等。针对GlusterFS,作者谈谈如何在Gluster上对海量小文件场景进行优化。
问题概述
海量小文件,当文件数量达到千万级、亿级、十亿级甚至百亿等,在元数据读写、存储效率等要求越来越高,海量小文件通常是业界的一大难题。
通常我们认为文件大小小于1MB的文件为小文件,GlusterFS文件系统他的设计在海量小文件场景有他的优劣,后面将细致分析GlusterFS在这种用户场景下的优劣势,已经如何扬长避短,对小文件进行优化。
1.问题分析
衡量存储性能主要用两个关键指标,即IOPS和吞吐量(bandwidth)。IOPS(Input/Output per Second)即每秒读写次数,是随机读写主要需要关注的指标;吞吐量指每秒读写的数据量,是顺序大文件读写主要关注的指标。
一般文件系统对文件的读写操作分成几个阶段,查询(lookup),打开/创建(open/create),读写(read/write),关闭(close)。查询,创建和读写基本上是对磁盘操作,其他操作基本上在内核就OK。而小文件读写,在磁盘表现上基本上是随机读写。
2.GlusterFS在小文件操作上的优劣势
主要是针对GlusterFS本身特点分析在小文件操作上的优劣势。
GlusterFS在架构设计上,有一个特色就是metadata跟数据在一起,没有集中式的metadata服务。这个跟业界其他分布式存储上有很大的差别。其他分布式存储,像ceph、hdfs等,都是有独立的metadata服务,管理整个集群中的metadata。这个特点造成GlusterFS有自己的优势,也有劣势。
(1) 优势
·在查找工作时候,在server端会有entry(关于最后落盘文件的元数据和分布)的缓存,这样在open操作时候不需要再操作一次磁盘。而metadata分离的文件系统,查询工作是在metadata服务上进行,要实际open或者读写时候,需要额外去读取一次disk查找落盘文件的元数据和分布情况。
·由于metadata和数据结合紧密,理论上,scale out更为线性。添加节点,该节点的所有metadata都在那个节点上。
(2) 劣势
·在进行目录遍历相关操作时候,由于没有集中式的metadata服务,遍历目录,需要遍历所有brick服务相应的目前取出相关的文件列表。并且,由于Gluster默认会使用readdirp操作(readdirp是对readdir扩展操作,在返回时候,会将文件的相关的metadata同时返回,readdir与readdirp区别类似ls与ls -l),这样每次可以返回的entry数量少,交互次数相应更多,导致ls或者find等遍历操作会变成非常慢(这个问题在gluster brick数量多或者文件数量多时候回比较严重)。
·Gluster在每一个brick节点都有隐藏目录.glusterfs,这个目录是含本机所有的一般文件的硬链接,和目录等文件的软连接。使得对于后端文件系统的inode数量翻倍。
3.优化建议
从Gluster本身,以及使用方式上来描述如何针对GlusterFS的海量小文件场景进行性能优化。
(1)Gluster方面
·Gluster Feature
Gluster在3.7 planning中计划实现对小文件的优化Feature(http://www.gluster.org/community/documentation/index.php/Features/Feature_Smallfile_Perf )。但是,这个是要DHT 4.0实现,这里DHT 4.0在设计实现阶段。需要在gluster v4上实现的Feature。期待Gluster官方实现这个Feature。
·撤销lookup-unhash
Lookup-unhash配置是在dht上生效的,是指在查找时候,如果在hash所在节点上没有找到相应文件的话,去所有节点上查找一遍。
撤销这个配置项,通过如下命令:
gluster volume set lookup-unhashed off
·开启write-behind和flush-behind
这两个配置可以开启异步写模式,对于io来说,上层不需要等待太多时间。
·关闭io-cache,readahead等xlator
这些xlator主要是为了大文件设计的,在小文件场景上会有一些性能损耗,需要关闭。
·Brick数量设置
这一块对于Gluster来说是很重要的事情。Gluster客户端会跟所有brick进程建立链接,当brick数量多了以后,对于客户端连接上会变慢,需要等所有brick连接回应后采用响应。
另外,brick数量太少的话,每个brick数据太多,io延时会相应变长。这里需要平衡一下。笔者没有细测,这里需要有一定测试。
(1)底层文件系统
·底层文件系统推荐使用xfs,这里红帽的测试基本上是基于xfs上测试。另外,xfs的特性更适合小文件系统。
·另外,如果热数据不多的场景,关闭文件系统的cache,使用cache在海量文件时候,在内存满时候,查找内存是否命中,以及内存的释放上对io性能造成额外的开销。
·这里,底层文件系统上,可以做一些加速。
例如,在明显有热流量的场景下,可以使用flashcache方式,指定合适的策略,对底层文件系统进行加速。
(2)使用方式
·目录层级设计
目录层级每多一级,对于一次文件的Open行为很可能会多查找一次磁盘。但是目录层级太少,会导致一个目录底下过多的文件,使得同一个目录下面查找相应文件的时间变长。
这里建议使用256*256方式,即在底下ab/cd/file。其中ab和cd是指两个两位16进制的数。
这里可以在创建好volume以后预先创建好目录结构。
另外,在这种情况下,如果要改代码,可以在brick进程即(glusterfsd)上缓存这个目录结构的信息,使得对这个目录结构的查找时候不需要对硬盘过多的操作。
·不使用遍历操作
理由前文已经说过,对于gluster目前版本的架构来说ls这种遍历操作会对整个文件系统造成很大的开销,以及本身性能很慢。看社区的planning,可以期待在4.0版本上这个有所改善。但是目前情况上还是避免这类型操作。
·小文件聚合
存储业界对于海量小文件性能调优上,还是将小文件聚合这种方案更为有效。这里需要注意几个限制:这里小文件聚合后上层需要记录好聚合后所在的file和offset等信息,以及这里小文件聚合场景中文件是一次写,后面不做变更,要不然实现起来会有很多劣势。
由于gluster尚未实现这种Feature,需要上层应用来实现,或者自己修改gluster代码。

© 2012-2018 九州云信息科技有限公司 99Cloud 版权所有 咨询热线:400 006 0472 售后服务热线:400 670 7810 培训咨询热线:400 826 0070   ICP证:浙ICP备12032350号-1

网站建设:信达互联

北京网站建设公司