并行文件系统近期的一些研究

作者:朱赛凡



近期对并行文件系统做一些一些研究,主要阅读了GPFS、ceph论文,同时查找了一些行业使用并行文件系统的应用场景。总结如下:

1 并行文件在性能方面主要优势是通过“条带”来提高传输带宽,而相反随机小IO效率低下。

2 并行文件系统更多用在高性能计算中,这样场景一般包括:(1) 多个分析进程并行读写一个非常大文件; (2) 单个进程能够以非常大的带宽读写一个文件;(3) 方便数据在进程间共享。

3 共享磁盘架构的一个缺点是多个计算节点之间存在干扰导致高并发环境下效率低下。

4 目前并行文件系统等主要通过副本(经典是3副本)机制来解决数据存储可靠性问题,基于纠删码的目前不多(HDFS目前好像是有一个hdfs-raid版本,采用纠删码技术来解决数据可靠性)。

基于以上几点:并行文件系统不适合高并发环境,而更适合并行计算,也就是高性能计算环境。

 

一 并行文件系统随机io效率低下

1.1 理论分析

并行文件系统中每个读写,客户端都要先向元数据服务器和锁服务器进行联系,读取元信息和取得相应锁,然后根据元信息和IO位置来计算和定位和哪个存储设备进行通讯。如果每次读的IO量大,此部分开销也许可以忽略。但对随机IO,每次读取IO量很小,此时此部分开销(通讯开销和计算开销)将非常大。

例如ceph 读写流程(根据ceph论文):

1) client打开一个file时,client与某个MDS通讯,MDS通过遍历树结构来将文件名翻译成file inode, 该file inode包含一个唯一的inode number,文件所有者,大小以及其他元信息

2) 如果文件存在且被允许访问,则MDS将inode number,文件大小以及用于将文件数据映射为对象的分片策略等返回给客户端。同时MDS发布一个capacity给client,告知client允许的操作类型,目前capacity包括:read ,cacheread ,write ,write buffer.

3) 客户端根据返回信息采用一定算法来计算该文件包含对象以及对象的位置。

4 ) client在执行文件关闭操作时,将capacity返还给MDS,并更新文件的size.

 

    例如GPFS每次打开文件时都需要向锁管理服务器申请tocken

  

1.2 实际测试数据

在查找并行文件系统使用场景时,找到一篇文章。作者对并行文件系统性能进行测试。

 

测试环境:

 

小文件随机读测试结果:


      在安装了并行文件系统后,随机io性能从157下降到34

 

作者结论:


有人曾把全文检索放在GPFS上,经过他们优化,性能也只能到本地文件系统70%。

 

1.3 其他一些相关资料

1  GPFS 官方资料

     可以看出GPFS设计初衷是提高数据读写带宽。

 

 

2 国外并行文件系统相关PPT

 

 (1) 首页

 

(1) 并行文件系统不适合数据库或者邮件服务器

二 并行文件系统适用场景和相应技术

并行文件系统更多用在高性能计算中,这样场景一般包括:(1) 多个分析进程并行读写一个非常大文件的不同部分; (2) 单个进程能够以非常大的带宽读写一个文件;(3) 方便数据在进程间共享。

在GPFS和Lustre中,为了满足多个进程可以并行读写一个文件的不同部分,这两个文件系统都提供了“范围锁”。例如:进程1 可以要求获取文件A的从[0~1kb]的锁,进程2可以要求获取文件A的[2kb~3Kb]的锁,这样通过这种细粒度锁来满足上述需求。

与之相对应的是HDFS锁粒度是整个文件,也就是一个进程在写一个文件,则其他进程无法写该文件,因此HDFS也不适合高性能计算。HDFS适合是数据密集型的场景,而高性能计算一般是计算密集型。

而redhat公司的Global File system ,锁粒度更细,粒度为每个底层块设备的每个“block”。但由于粒度太细,规模无法做大。

为满足单个进程在顺序读单个文件情况下也能实现多个设备聚合带宽,GPFS采用让多个存储设备会并行把数据读取到内存中策略实现上述需求,类似RAID通过预读机制。

 

三 共享磁盘架构的干扰问题

共享磁盘架构下的干扰问题,主要分为两类:一是顺序IO之间干扰、二是随机IO之间冲突。

顺序io之间的干扰可以简单解释如下:

非共享方案:

10个文件,放在10个盘上,每个盘一个线程读取。

共享方案:

10个文件,条带化后每个文件都被分散在10个硬盘上(例如11块盘raid5),10线程同时读该RAID。(条带化的优点是在并发度不高情况下能提高单进程单个大文件的顺序读写的速度,并且是条带化+并行读+预读)

在共享方案下,磁盘会因为同时需要应付10个读线程,因此变成了随机读。

目前这种干扰,可以通过RAID和单盘队比测试来验证。相应测试结果:

 

同时国外也有研究人员认识到该问题,并试图优化和解决这些问题,但总体还是很复杂:

 

论文1:研究HADOOP平台下,共享IO干扰.


论文2:研究如何改进和优化共享IO的干扰问题 ,大概思路是增加一个中间层来优化。

 

 

磁盘干扰

 

缓存干扰:

 

二是随机IO之间冲突。

随机IO之间冲突,导致RAID无法发挥所有硬盘的随机IO性能。这种情况下效率低下的原因,个人分析主要是虽然可能有多块盘,但是如果调度不好则存在同时在工作的盘可能只有少数几块盘。这个问题应该和数据条带化没有太大关系,而且对顺序IO也有影响,只是由于随机IO每次都比较小,影响会更严重一些。

因此在淘宝TFS的设计方案中,原始TFS采用RAID来存储,后来也是发现该问题,将RAID变成单盘,由应用层通过复制来保证数据存储安全,并且采用一个进程管理一个磁盘的模式来解决该问题。

四 存储虚拟化、纠删码、绿色存储

为解决海量存储管理问题,应该需要再仔细研究下存储虚拟化技术。但是从目前来看存储虚拟化更多的是在企业存储环境下,存储容量不是很大。(云存储采用三副本的备份来确保存储安全,但是面临的主要问题是IO速度太差,在网络上反应阿里云云服务器主要的缺点是IO性能太差,目前为解决云服务器的存储IO太差,这些大公司都打算推出基于SSD的云存储,但成本太高)

目前也在各大云存储的底层架构,在infoq上,找到一个七牛存储一个视频。从这个视频里了解了纠删码技术,同时也感觉他们底层也不是架构在一个开源或者商用并行文件系统之上。纠删码目前是云存储中一个比较热的技术。在业类目前也有提供这种解决方案,例如celversafe公司,提供私有云存储解决方案。

 

 

 

绿色存储目前也是一个热点,但是从前研究来看,互联网公司一般的方法是对部门满足以下要求的服务器采用服务器方式来降低能耗:IO到100%时,CPU利用率不高。例如CDN服务器。方法是使用低功能,性能低一些CPU。这块有能将文件存储服务器,采用该思路来减低能耗。

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值