搜索
当前位置: sk彩票 > 对象引用 >

杉岩数据梁欣鑫:使用Ceph存储海量小文件的实践

gecimao 发表于 2019-05-08 23:54 | 查看: | 回复:

  4月23日,在由DOIT主办的首届软件定义存储峰会在深圳举办。杉岩数据梁欣鑫在“使用Ceph存储海量小文件的实践”的主题演讲中,谈到了小文件、解决小文件问题的几点想法以及Sandstone Mos海量小文件的方案。

  本次大会,以“软件定义存储未来”为主题,DOIT主办,中国开源云联盟、中国超融合产业联盟、Ceph中国社区和腾讯云+社区提供支持,吸引了来自全国各地的数百位专业观众参与。大会探讨了SDS业内最热门的六大话题,包括SDS趋势与实践、开源云存储、超融合、Ceph、互联网云服务等等。数十位国内外专家、学者和用户亲临现场,结合软件定义存储技术、应用、现状及趋势进行了深入交流。

  各位下午好!我来自杉岩数据,下面跟大家分享使用Ceph存储海量小文件的实践,今天要讲的是小文件,解决小文件问题的几点想法以及Sandstone Mos海量小文件的方案,最后是总结。

  1、海量数据的性能问题。这是64K写的性能测试,一开始的1万到4亿个对象,这个时候会发现写入的性能逐步下降,从开始有15K的oes到下降到2.5,实际上下滑比例已经达到了80%多,海量小文件的冲击是非常大的。

  究其原因,如果用的是Fd,底下的文件是要从Fd到dentry再到inode,superblock,1亿的文件,256B,它已经占了24G,小文件带来的是要直接操作磁盘,直接操作磁盘会导致性能下降,海量的小文件会破坏空间的连续性,会产生大量的随即读写。海量小文件会有大量源数据,性能还是不能得到流畅。

  2、数据恢复效率问题, 数据在做恢复的过程中效率的问题,海量场景下恢复的速度,后者是前者的10倍,海量的小文件场景下,数据恢复的速度比较缓慢,而且效率很低,在此期间如果刚好不巧有业务请求过来,有可能会看到Slow Requses或是blocked,是存在风险的。

  3、扩容、恢复以后集群的性能还会出现骤降的情况。如果做了扩容或是故障恢复,这个时候大量的小文件可能会被删除,可能会出现大量的碎片,这个碎片可能出现在磁盘上,如果不进行碎片的回收,里面系统的性能会出现骤降的情况,这是我们测的一组数据,前面很平稳,一旦扩容等恢复以后,这个比例会变大。

  4、海量小文件的场景,数据的迁移效率比较低。可能想用数据冷热分层的方式把热数据移到冷的存储池,这个时候有大量的小文件在这个过程中会产生迁移,而且这个迁移的过程中前面也会有,迁移以后数据可能进行大量的删除操作。之前测试的4000万的小文件迁移消耗时间大于72个小时,算下来要两天多的时间。这种情况下迁移的效率太低了。

  海量小文件,是不是可以做合并?合并之后的文件,不是体积很小的文件,空间的使用效率是比较高的,对磁盘还是比较友好的。合并以后是不是可以提高读写的性能?

  我们都知道,现在流数据,而且是写在对象里,源数据是不是可以独立?为什么做独立?源数据独立有两个好处,源数据可以更加灵活的做选择存储,可以对这些源数据做一些其他的操作,比如说源数据是不是可以做其他方面的管理、检索,都很方便的做。是不是可以把源数据部分抽出来?

  同步和删除的流程是不是可以改进?如果做到第一点,文件做了合并的话,传输也是可以做合并的,而且删除操作的时候,批量删除是可以提升效率的。

  第一步我们把源数据从Data pool抽出来进行分离,源数据存在index pool,部署方式是不是和其他的部署方式不一样,没必要和Data pool绑在一起。每个对象把源数据抽出来以后,放在BI,源数据有它的BI,会有对应的Data pool数据实体。我们去到ID里的Index,多个对象放在一起管理,这个时候很方便的能实现多个版本的数据管理。

  这方面我们也需要一些数据,简化整体的数据结构。比如说读写数据有非常重要的结构,在应用数据结构的时候发现有很多数据,这些数据不好的地方是没怎么用、没什么用,放在这里很占空间。里面有RGW很占空间,读写数据的时候其实没必要关心这个对象是什么样的,我们也去掉一部分的冗余数据简化数据结构。

  在这上面我们也做了文件合并的工作。开始的想法是不同的对象可以写到一个大项里,实际上这里会有几个问题,对象写进来以后应该朝哪个地方写?后面会讲一下大概的流程,处理小文件写入的时候可不可以给一些因素简化流程?不同的bucke的小文件合并到不同的大文件里,如果对象是同一个bucket会写到同一个大对象里。我们都知道用的是shard的思想,BI分了不同的shard,为了简化处理流程,,不同bucket的小文件存到不同的大文件。

  文件合并以后要读的时候应该怎么读?小文件的读取比较简单,存进去改一下加上offs和lenght就可以了,所有的对象指向的数据实体只有一个,对象读的时候知道开始位置就可以得到对应小文件的数据。还是会有问题,简单的话是合并就完了,问题是这个东西进来以后,应该写到哪个对象上?所以对象进来以后可能好几层,这里就会有一个问题,假设两个对象是写到同一个大对象上,这个大对象的空间分配会是一个关键的问题,对象的空间分配一定要统一一个来源,可以避免写同一个对象,保证区间不会相互交集。我们在Bucket使用omap_key存储大对象元数据,可以起到空间分配的作用,对象写进来以后,最后是不是要确定对象放在哪个Bucket shard上,可以看到需要用哪个merged object,可能第一个写0到24,第二个会记一个状态,会把他的状态记为已经使用,下一次线程过来就不会用空间。会把空闲的空间分配给他,我每个线程写的时候拿到的空间分配信息之后,就可以写相应的偏移。我们每个对象在上面都做了空间的管理。

  删除操作可能会出现几个问题,删除的空间怎么进行回收?可能删了几个小对象后大对象整体会出现空洞的情况,什么时候进行整体的回收?进行整体回收的时候这些小文件要怎么进行适度的迁移?前面说的空间管理情况下有条目的状态,既可以在空间分配中用到,也可以在删除小文件的时候用到,删除小文件的时候是异步删除的方式,可以在这个大对象上做个状态的更改,里面会涉及到两个操作,不单只是删除小文件的时候要删原来的小文件BI,还要改大BI的状态。

  我们有两个对象可能被删除会标deleted的状态,删除的时候如果数据不进行立刻的回收,空间是存在一定的浪费。这个时候要灵活运用object的接口,这个时候空间做了一定的回收,所以这个接口是比较友好的,对于快速释放空间,提高空间的利用率,有可能大对象的区间被删除,当空间使用率达到一定程度的时候,我们要进行整体的回收,大对象可以反向索引到每个小对象上,小对象也需要记录自己所处的大对象,这两个操作是为了后面铺垫的,要做删除操作的时候,小对象必须自己清楚,我是属于哪个大对象的?删除的时候可以在上面记这个状态,大对象有要记自己被哪些小对象引用,为什么这样处理?如果说空间使用率低到一定程度的时候,要进行整体的回收,这个时候还在使用小文件怎么办?大对象必须反向索引到有哪些小对象在用它?这个时候我们把小文件的数据挪出来,迁移到其他大对象里。整体的机器操作是完全的异步方式,如果你在删除对象的时候会进行res的,为了处理其他的问题,把整个过程变成异步的,包括BI的删除和数据的删除都变成异步的方式。

  同步和数据迁移原理是一样的,无非是把大量的数据从一个站点,从一个存储池迁到另一个存储池,这一点是最为头疼的,会涉及到非常多逻辑的问题,比如说合并后的文件是怎么进行同步的?小文件的元数据,合并以后的文件进行同步,元数据怎么同步,是不是会存在先后顺序的问题?

  大家如果了解的话,多站点的同步分为两部分,一个是全量同步,一个是增量同步,两个同步的方式和base的实际结构是不太一样的。如果你是全量投入的情况下,AB两个站点是进行全量同步的,我做全量同步的时候会把里面的对象都拿过来,增量同步就不一样。先分场景做,我第一步是先把这些合并之后的文件、数据整体的拉过去,包括前面提到的大对象,实际上也有自己的BI,这个时候对我来说也是一个对象,我会把这些数据统一丢过去,小文件的元数据还是维持。

  增量同步的情况比较复杂,这个大对象是写到100,这个时候怎么把它同步过来?这里面有点取巧,像这种情况下,我们要处理这个逻辑,前面全量可能把这个拉过去,根据多个BI,如果发现是多条边、是写在同一个同类项上,这个时候会把数据做合并类似于前面同步的方式,把数据合并丢过去。最后源数据还是通过BI的方式,把源数据拉过来,每次请求的效率会比以前高一些。

  两个数据池迁移的时候,跟全量同步的场景是一样的,全量同步的情况下和存储数据池的迁移是一样的场景,这个时候没有单列存储池的场景。

  1.海量小文件的性能。我们在做完文件合并以后,文件数是能明显下降的,解决海量数据场景下的性能问题,文件合并以后,对于磁盘来说是比较友好的,合并以后可能是比较大的文件,比如说我们合并至少都是4M的文件,合并以后文件的数据量会明显下降。

  2.恢复效率。文件合并以后效率也可以得到巨大的支撑,原来都是32K的文件,有100个32K的文件,合并以后是3M多的文件,每次请求要恢复的文件数目明显减少了。

  3.扩容后的性能骤降的问题,合并后的文件对于空间的使用率更高,就算会出现大量的数据删除情况,这个时候对于磁盘的使用也是更加友好的,因为这个时候磁盘也不会出现过度的空洞碎片。

  4.数据迁移的整体做了优化,数据合并之后迁移的效率也会明显的提高,前面可能分了100个小文件,可能是请求100次的32K文件,可能是100次32K的请求,合并之后只需要一次移过量就可以了,后面的所有操作都是不需要再跨两个Pool。

  最后介绍一下杉岩数据,杉岩数据2014年成立,创始人都是来自于500强企业,今年已经获得了深圳中小担集团跟投的B轮融资,针对目前Ceph遇到的问题我们也在做一些积极的投入。这是我们当前的客户(见PPT),今天就讲到这里,谢谢。

  报名倒计时3天 来清华参加SpringCamp,与大咖一起“智见AI”下一篇

本文链接:http://moodyjews.net/duixiangyinyong/313.html
随机为您推荐歌词

联系我们 | 关于我们 | 网友投稿 | 版权声明 | 广告服务 | 站点统计 | 网站地图

版权声明:本站资源均来自互联网,如果侵犯了您的权益请与我们联系,我们将在24小时内删除。

Copyright @ 2012-2013 织梦猫 版权所有  Powered by Dedecms 5.7
渝ICP备10013703号  

回顶部