非常感谢大家过来听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办公，希望运维人员以及开发会在这样的基础架构比较稳固的情况下，更好地做自己的工作，有更多的想法来进行实践。谢谢大家!
热门专题
