首页 -> 新闻中心 -> 云计算 -> 正文
Ceph中国社区工程师 张磊:Ceph运维实践及业务场景分析
2017-04-25

W020170419616339662262

非常感谢大家过来听Ceph的分享。今天看了一下Ceph的分享蛮多的,尤其是在存储这边。我这边还是有五年大规模运维开发经验来给大家介绍一下Ceph的运维。我们讲Ceph其实我们讲的是它的一些新的特点和特性。讲到Ceph我们就必须得讲到存储的发展,早期的存储单机的存储,单机存储是没办法进行网络共享的,到了第二个阶段就是共享数据的阶段,像NFS之类的。其实第二个阶段解决不了的问题,是数据安全性的问题,以Google为代表我们衍生出了社区的Ceph,与此同时在这个阶段可以来进行一些,因为数据可以分布式存放,我们可以进行分布式计算。我今天要讲第四个阶段,就是数据整个存储的动态性,我们讲到SDS。我们现在的存储规模也是越来越大,同时面临的问题数据的价值也越来越高,从传统的数据存储已经到基于数据的计算已经出来了。

今天主要讲的是四块,第一块是初步介绍一下Ceph,第二讲CephFS的运维实践,第三讲一下业务场景分析,第四回归一下主题讲一下自己对开源的理解,跟大家一块分享一下。

Ceph是统一的分布式存储,提供了统一的存储解决方案,同时它有优秀的性能和高可用以及非常强的可拓展性。同时Ceph是对象存储,但是面对于用户测试使用来说提供了三种方式的存储,第一种是对象的存储,第二种是快设备的存储,第三种是文件系统的存储。Ceph在设计之初其实是以文件系统为发源来做的,做着做着在对象存储上面做得非常到位、非常好,尤其是结合云计算相关的组件OpenStack这块的东西也衍生出来快设备方面的优势。因为这些集群我这边是总共搭了有五个集群,最大规模的也有单集群,有170多个OSD的规模。

我们今天来分享最不靠谱的系统就是文件系统。我们使用Ceph之后,这也是我向大家推荐Ceph的原因,我们使用Ceph之后,我们的大资源和小资源都有统一的存储方案。第二,Ceph的底层是对象存储,减少了文件系统。第三部分完全去中心化,任何过程中我的设备宕掉以后或者小的网络都是可以自愈的。第三个分布式的存储里面,在Ceph存储上是没有这种瓶颈的。第四块是部署的成本以及运维的成本,就已经非常非常低了,同时可以支撑PB级别的横向扩容,同时可以提供非常庞大规模的小资源的存储。

这是Ceph的整体架构,下面这一块,它的对象存储的基础组件,上面依托于这个组件衍生出来的三个存储方式,一个是对系存储,第二是快设备,第三个是FS。当然我们可以直接调LIBRADOS库里实现操作。我们今天讲的就是CephFS。

RADOS是非常高可用可扩展的能够自愈对象的存储,它的底层,在这一块区域,这个是以主机为主画的图,每个框是单个的磁盘,我们的数据存储过程,文件系统过来之后进行PG选择,从PG经过Ceph本身的算法映射到具体的磁盘。在整个过程中,它把上面的虚框里面,是一些逻辑层的,更多的引入了一些逻辑层的东西,对于用户屏蔽了硬件对整个存储系统的影响。同时我们要有整个集群的监控状态,所以Ceph自身有一些管理的节点,管理节点采用选举的方式,管理节点可以管理集群自身的,比如选举谁是主、谁是从,做健康检查以及做认证相关的工作。另外能够管理数据相关的信息,比如说数据存放在哪,刚才我们看到的,在这一层里面其实我们有好几次映射,在Ceph里面也有自身的集群的运行图。

同时还有数据的删除追加的操作,同时需要更新自己的日志。我们在用CephFS的时候其实有一个MDS的模块,类似于漏洞的模块,因为Ceph本身是对象存储,它在OSD里面把对象信息已经有了,OSD模块最多做数据的汇总以及修正,这张图是官方图,首先是两种挂载方式,挂载之后就可以获取到服务器信息,通过MDS可以知道我的数据是存在哪的,可以从哪取,所以Clients直接跟远端取数据,MDS再跟Clients这块来更新,这样有MDS很大程度上也降低了Ceph集群存储的压力,尤其是在便利的时候。

讲到这块给大家的感觉其实这个还是蛮OK的,是不是真实的情况就是这样子?其实在我们使用过程中就发现了不是这样,从Ceph的社区里面是不推荐大家使用的,我们就使用了。有一些问题,首先我们是使用类模块的方式来挂载,运用挂载方式,所以很多节点都是直接来进行挂载,当它的数量非常多的时候,这个性能就比较明显了。第三个,当带宽数据同步的时候或者在备份的时候,或者集群内部,带宽经常比较满,其实读写性能是非常差的,在这个过程中有可能对我们的服务会有一些影响。包括它的MDS的故障,还有PG延迟,确实没有办法,我们的业务侧需要一个能够通用一点的存储方案,我们也有用过其他的一些存储,都各有各的缺点,Ceph在社区的支持非常活跃,于是我们也跟很多人进行沟通和交流,之后就觉得既然别人在用,当然其他人更多用的是对象的存储,我们也在尝试自己用一下。由于我们不熟悉功能性测试和验证不足,包括盲目跟风,导致了我们出过很多问题。

首先集群的部署和升级这一块,很多公司自身会针对自己的内核做一些定制化,我们其实这边也有一些定制化,我们的系统当我们使用CephFS的时候,挂载的时候,发现Clients端的内核模块性能比较差,或者说经常出现一些问题,我们要升级它,要升级它的时候就会发现,我们升级几次之后我们需要升级的是Ceph的版本,所以我们就来来回回这样做,升级的过程也是很痛苦的。另外LIBCeph通过大规模检测,把Kernel crash问题,当要卸载的时候卸载不掉,设备要重启,这也是非常头大的。我们也是把这种问题经过压测,测出来之后进行解决。这种慢查询和MDS响应慢,因为每个Clients直接和SDG进行交互的,我们的数据被改了之后,OSD会通知MDS说数据变更,MDS这块会变更,它变更之后会通知Clients这端来更新数据,Clients更新不了,我们也做了一些优化。前两次做完优化之后,当数量非常多的时候,我们没办法监控住整个集群,尤其是当我们没有规范的时候,业务使用上,我们不知道哪些地方出了问题,所以说我们也在探索FU的方式来进行监控数据的上报,另外上面这种挂载的方式是把问题暴露出来,新生的话管理是非常麻烦的,我们尝试用Fuser这块来做一个优化,这块也在探索过程中。

我们知道当你存数据的时候其实是这样,我们有很大量的数据,但是只有一些,比如说今天存的数据,今天从网页上扒的数据今天使用的用户比较多一些,因为是热点数据,过一段时间可能就是很一般的数据,尤其是像很好的视频,或者是其他的一些图片,就是一些冷数据。我这边把它分了三层,我们Ceph其实做的后面两层,第一层当我是hot的时候是放内存里,我们的业务资源以及检索图片,中等的我们使用SSD,尤其是在线的这种图片,冷的数据我们做归档。对应的延迟,当我们需要秒级以及秒级以下的时候我们必须要放内存的,当然这个延迟是我们这边结合我们自身的业务来制定的,大概是这样一个存储。

这个想法对应到Ceph里面我们怎么做的,Ceph提供了一个Cache Pool功能,其实我的热点数据是需要让用户很快地感知到,我的冷数据其实是需要过一分钟左右的时间来访问到就OK,所以有了这种想法,Client来进行对象的存储,首先要交互Cache Pool存储,存储这一块的容量非常大,我们就进行选型,所有的交互都是跟Cache来做交互,优先是写SSD这块,如果Cache数据里面数据不是热点就下面移到下一层,如果经常有人访问或者过期周期数据量到达一定的时候,我们会把它的数据上移。整体的概念相当于我们在这一层里面加了Cache层,第一个功能是Cache Tier有一个数据的淘汰机制,其实我们看到Cache Tier解决的问题,我的大部分数据是冷数据,我只有少量的数据是热数据,如果说我整合进去,其实有很大量的图片的展示,或者说其他的时候,我们发现不停地在淘汰或者其他的,这种场景是没办法解决掉的,而且在反问发射盘的时候很多存储就响应非常慢。另外一种主副本的存储机制,在上面里面我们把它进行了分组,我们把SSD的盘组成一个组,把SATA盘变成另外一个组,SATA盘更多存一些副本。这样的好处,我们整个SSD就非常好。但是它的应用场景,比如说当我的类似于图片资源非常小,存储空间占用太多,这样SSD的使用设备是比较局限的,这种方式是合理的方式。

下面说一个带宽的问题,当我们在扩容集群或者出现网络故障的时候,其实是整个带宽会比较满一些,这个时候比如说我要扩容3台机器,同时扩容之后,这3台机器上没有数据的,原来10台机器上是有数据的,这些数据我都会动态来挪,但是在动态挪动的时候,就产生了一些问题。我的这块带宽很满,就会导致读写的速度就有问题。我们的解决方法设备的升级以及网络故障时设置恢复,同时设置优先级之类的。

基本上在做完这些事的时候,我们的整个集群是OK的。但是我们说它OK,它真的OK吗?其实也不是这样的,我们还要有一定的验证的功能测试的步骤。我们通常会进行SSD和HDD盘的性能测试,还有整个集群全是SATA的设备存储性能测试,还有故障的数据迁移进度,比如我用千兆机器一台机器单盘2T,我用千兆机器来同步需要28个小时甚至更长的时间,但是我用万兆机器可能就8个小时左右。我们的测试方法其实和其他的都是很类似就是FIO和DD侧,FIO会好很多,更加专业一些,因为有深度还有定义的其他的参数变量来更加OK,DD更加偏向于单个测盘的速度。同时测完之后还是需要线上流量的拷贝来进行验证,我们就是复制线上流量来测,因为尤其是对MDS而言,当它的文件数量非常多的时候,它其实整个集群是MDS的性能是更加出现问题的。

这个是我们的运维和Troubleshooting的东西,还有其他的工具,我们用的最多是S3的工具。

这是相关的优化,相关的优化是这样,很多人尤其是在硬件这一块,官方的文档说的是我们要使用双网卡的集群,实际上很多公司都没有太好的环境的,我们也使用的是单千兆网卡,其实单千兆网卡只要保证数据量同步没有达到标准就好了,我这边定的标准是说,比如说我的集群规模有20台,我只要20台的带宽日常水平只要不超过5G也就是1/4就可以了,当然还有其他的参数。我需要说的是第四点,业务这一块一定要进行合理的规划,因为任何系统都是有自己的局限性的,我们在这个地方就踩过很多坑,我们没有规划好业务,存储挂上之后业务上就当成硬盘来使用,这样不停地进行IO,这时候很多重复的IO来操作,集群压力非常大,还有用户权限之类的。

我们整个运营思路,对存储这一块整理了一下这九点,通用的一般运营思路,我们要确认核心的需求,结合场景分析,进行资源整合,然后是技术的选型和预研,最终的目标是服务化、平台化。当然走的录用很漫长,而且不同的人会有不同的理解。

第三个是业务场景的分析,这是Ceph中国社区里面的文档,还有对应的英文的,为了简单一点,就给大家放了中文的。大概会有这三种方式,各自有各自的优劣势。直接就直接过了。

我们的需求和我们的场景这一块,需求其实我们需要的对象、块、文件存储,I/O密集型存储,大规模可扩展性,以及会不会用到基于Ceph存储一些应用场景之类的,无非是快、慢存储还有主备存储。

再跟大家分享两个case,第一个case是CDN,我们需要数据的持久化以及部分数据需要更新。第二我们需要进行带宽的拆分之类的。第三个我们需要很强的用户的权限控制和用户管理。对象存储,RGW这块在选型的时候选这一块就好。它的优势对象存储非常成熟,包括很多方案都会有,同时这部分数据支撑版本的管理,如果这部分数据不用就可以置为Ceph状态,这个数据不可得。传统我们直接把这个数据删掉,这样是不合理的。

第二个场景,就是OpenStack这块,主要讲的云主机这块,包括硬盘,我们要单独再买一个云盘,这样的场景,它的需求场景我需要快速创建和导入clone镜像,同时系统盘或者买的云盘需要是高性能的。

第三个,我需要做快动的,另外需要快速扩容和缩容,对象这块就能完全解决这个问题,对象存储也可以解决主副本的存储机制。

当然我们现在有一个很好的项目,我们在把数据放在机器训练的场景,现在正在起步,因为没有出来,所以也没有跟大家分享。我最终的规划,我们从用CephFS来做数据共享,我们的计算或者训练任务放在Docker里面,我只要我的Docker挂载的时候有这样的存储就好了,就可以进行存储。

最后一部分介绍一下,我们Ceph主备模式会需要升级到集群模式,它对高性能的计算的支持很差。有人测出来的性能说是差30%。第三部分是数据生命周期的管理,包括过期,其实我们看见很多存储,我们其实是需要存一段时间就OK了,而不是长久的存,比如一个数据有效生命周期是3个月,3个月之后会不会自动过期,现在很多还是做不到。第三个,我们需要一些数据类的服务,我们把它跑在Ceph上,现有模式都是用SSD来做,备份也是非常大的问题,我们后面会尝试Lifecycle测试一下,没有人敢正式放在生产环节上,我们也在讨论这一块。第三个延迟这一块,尤其是读写延迟,还有网络上的耗时,包括时钟这一块,后面应该有更加灵活的配置。这是我这边的想法。

讲了这么多,道理大家都懂,我们也各有各的做法,不见得谁做的就是最好,或者说谁做的就差。我们怎么样来维护好Ceph集群?因为存储已经是整个云计算非常底层的组件,如果当我们的存储不稳定,其实我们发现我们的调度Docker没有数据,只有运算没有数据,其实是没有用的。所以说我们其实是想有一种更加好的方法来把大家的集群都管理好,这样就有更多的实践和交流。

开源的一些想法和认知,社区社用代码是第一次参加开源大会的时候提出这个想法非常好,我们需要有一个社区来维护这个东西,而不是单个的个人或者单个公司,其实我们发现像Google这么牛逼的公司其实在维护这些功能组件的时候都非常痛苦,比如报表之前是没有开源的,他现在已经做开源了。欢迎大家加入我们的开源社区。

第二,我们国内的技术目前是很乐观的,昨天一个好消息,我们的Docker大会,国内的开发组有一名我刚好认识,已经挤入了前四的贡献了,非常非常了不起的。另外,我认识的有几个哥们也在单独提KYS一些组件,包括Docker也有。

第三个,code这块现在Ceph的情况,还有这么多是Open,审核工作都很繁琐,尤其是在国内,大家对存储特别热衷,有很多地方来支持。这是技术层面我们要做的东西。

第三,如果没有技术,我是不是不能开源了,我们的个人理解,我们做一些问和翻译,也是属于代码的一部分,这样把自己的东西弄出来给别人更多分享出来是非常好的。

第四,一些经验分享和创意的分享。

第五,我们在做一些技术的公益,所有的技术,我们认为技术很重要,但是很多公司用着用着只是偏向于个人的东西,比如说我们知道的检索,大家认为检索的技术都很牛逼,确实很牛逼,但是用着用着大家会讨厌这样的东西,为什么?它没有回归到本质,我们的本质能够更好地反馈社区社会,把这些东西更好的东西提供给大家。

我个人的想法,我们技术人员能够SOHO办公,希望运维人员以及开发会在这样的基础架构比较稳固的情况下,更好地做自己的工作,有更多的想法来进行实践。谢谢大家!

新闻搜索

覆盖全国各省会城市及海外城市的网速测试
→选择要测试的地区
→选择目标测试点