Ceph源码分析.html.pdf
《Ceph源码分析.html.pdf》由会员分享,可在线阅读,更多相关《Ceph源码分析.html.pdf(29页珍藏版)》请在三一文库上搜索。
1、序言 自从2013年加入Ceph社区以来,我一直想写一本分析Ceph源码的书,但是两年多来提交了数万行的代码后,我渐渐放下了这个事情。Ceph每个月、每周都会发生巨大变化,我总是想让Ceph源码爱好者 看到最新最棒的设计和实现,社区一线的模块维护和每周数十个代码提交集的阅读,让我很难有时间回顾和把握其他Ceph爱好者的疑问和需求点。 今天看到这本书让我非常意外,作者常涛把整个Ceph源码树肢解得恰到好处,如庖丁解牛般将Ceph的核心思想和实现展露出来。虽然目前Ceph分分钟都有新的变化,但无论是新的模块设计,还是重构 已有逻辑,都是已有思想的翻新和延续,这些才是众多Ceph开发者能十年如一日改
2、进的秘密! 我跟作者常涛虽然只有一面之缘,但是在开源社区中的交流已经足够成为彼此的相知。他对于分布式存储的设计和实现都有独到见解,其代码阅读和理解灵感更是超群。我在年前看到他一些对Ceph核 心模块的创新性理解,相信这些都通过这本书展现出来了。 这本书是目前我所看到的从代码角度解读Ceph的最好作品,即使在全球范围内,都没有类似的书籍能够与之媲美。相信每个Ceph爱好者都能从这本书中找到自己心中某些疑问的解答途径。 作为Ceph社区的主要开发者,我也想在这里强调Ceph的魅力,希望每个读者都能充分感受到Ceph社区生机勃勃的态势。Ceph是开源世界中存储领域的一个里程碑!在过去很难想像,从IT
3、巨无霸们组成 的巨大存储壁垒中能够诞生一个真正被大量用户使用并投入生产环境的开源存储项目,而Ceph这个开源存储项目已经成为全球众多海量存储项目的主要选择。 众所周知,在过去十年里,IT技术领域中巨大的创新项目很多来自于开源世界,从垄断大数据的Hadoop、Spark,到风靡全球的Docker,都证明了开源力量推动了新技术的产生与发展。而再往以前看十 年,从Unix到Linux,从Oracle到MySQL/PostgreSQL,从VMWare到KVM,开源世界从传统商业技术继承并给用户带来更多的选择。处于开源社区一线的我欣喜地看到,在IT基础设施领域,越来越多的创业 公司从创立之初就以开源为基
4、石,而越来越多的商业技术公司也受益于开源,大量的复杂商业软件基于开源分布式数据库、缓存存储、中间件构建。相信开源的Ceph也将成为IT创新的驱动力。正如Sage Weil在2016 Ceph Next会议上所说,Ceph将成为存储里的Linux! 王豪迈,XSKY公司CTO 2016年9月8日 前言 随着云计算技术的兴起和普及,云计算基石:分布式共享存储系统受到业界的重视。Ceph以其稳定、高可用、可扩展的特性,乘着开源云计算管理系统OpenStack的东风,迅速成为最热门的开源分布式 存储系统。 Ceph作为一个开源的分布式存储系统,人人都可以免费获得其源代码,并能够安装部署,但是并不等于人
5、人都能用起来,人人都能用好。用好一个开源分布式存储系统,首先要对其架构、功能原理等 方面有比较好的了解,其次要有修复漏洞的能力。这些都是在采用开源分布式存储系统时所面临的挑战。 要用好Ceph,就必须深入了解和掌握Ceph源代码。Ceph源代码的实现被公认为比较复杂,阅读难度较大。阅读Ceph源代码,不但需要对C+语言以及boost库和STL库非常熟悉,还需要有分布式存储系 统相关的基础知识以及对实现原理的深刻理解,最后还需要对Ceph框架和设计原理以及具体的实现细节有很好的把握。所以Ceph源代码的阅读是相当有挑战性的。 本着对Ceph源代码的浓厚兴趣以及实践工作的需要,需要对Ceph在源代
6、码层级有比较深入的了解。当时笔者尽可能地搜索有关Ceph源代码的介绍,发现这方面的资料比较少,笔者只能自己对着Ceph源 代码开始了比较艰辛的阅读之旅。在这个过程中,每一个小的进步都来之不易,理解一些实现细节,都需要对源代码进行反复地推敲和琢磨。自己在阅读的过程中,特别希望有人能够帮助理清整体代码的 思路,能够解答一下关键的实现细节。本书就是秉承这样一个简单的目标,希望指引和帮助广大Ceph爱好者更好地理解和掌握Ceph源代码。 本书面向热爱Ceph的开发者,想深入了解Ceph原理的高级运维人员,想基于Ceph做优化和定制的开发人员,以及想对社区提交代码的研究人员。官网上有比较详细的介绍Cep
7、h安装部署以及操作相关的 知识,希望阅读本书的人能够自己动手实践,对Ceph进一步了解。本书基于目前最新的Ceph 10.2.1版本进行分析。 本书着重介绍Ceph的整体框架和各个实现模块的实现原理,对核心源代码进行分析,包括一些关键的实现细节。存储系统的实现都是围绕数据以及对数据的操作来展开,只要理解核心的数据结构,以 及数据结构的相关操作就可以大致了解核心的实现和功能。本书的写作思路是先介绍框架和原理,其次介绍相关的数据结构,最后基于数据结构,介绍相关的操作实现流程。 最后感谢一起工作过的同事们,同他们在Ceph技术上进行交流沟通并加以验证实践,使我受益匪浅。感谢机械工业出版社的编辑吴怡对
8、本书出版所做的努力,以及不断提出的宝贵意见。感谢我的妻子 孙盛南女士在我写作期间默默的付出,对本书的写作提供了坚强的后盾。 由于Ceph源代码比较多,也比较复杂,写作的时间比较紧,加上个人的水平有限,错误和疏漏在所难免,恳请读者批评指正。有任何的意见和建议都可发送到我的邮箱,欢迎读者 与我交流Ceph相关的任何问题。 常涛 2016年6月于北京 第1章 Ceph整体架构 本章从比较高的层次对Ceph的发展历史、Ceph的设计目标、整体架构进行简要介绍。其次介绍Ceph的三种对外接口:块存储、对象存储、文件存储。还介绍Ceph的存储基石RADOS系统的一些基本概 念、各个模块组成和功能。最后介绍
9、了对象的寻址过程和数据读写的原理,以及RADOS实现的数据服务等。 1.1 Ceph的发展历程 Ceph项目起源于其创始人Sage Weil在加州大学Santa Cruz分校攻读博士期间的研究课题。项目的起始时间为2004年,在2006年基于开源协议开源了Ceph的源代码。Sage Weil也相应成立了 Inktank公司专注于Ceph的研发。在2014年5月,该公司被Red Hat收购。Ceph项目的发展历程如图1-1所示。 2012年,Ceph发布了第一个稳定版本。2014年10月,Ceph开发团队发布了Ceph的第七个稳定版本Giant。到目前为止,社区平均每三个月发布一个稳定版本,目前
10、的最新版本为10.2.1。 图1-1 Ceph的发展历程 1.2 Ceph的设计目标 Ceph的设计目标是采用商用硬件(Commodity Hardware)来构建大规模的、具有高可用性、高可扩展性、高性能的分布式存储系统。 商用硬件一般指标准的x86服务器,相对于专用硬件,性能和可靠性较差,但由于价格相对低廉,可以通过集群优势来发挥高性能,通过软件的设计解决高可用性和可扩展性。标准化的硬件可以极大地 方便管理,且集群的灵活性可以应对多种应用场景。 系统的高可用性指的是系统某个部件失效后,系统依然可以提供正常服务的能力。一般用设备部件和数据的冗余来提高可用性。Ceph通过数据多副本、纠删码来提
11、供数据的冗余。 高可扩展性是指系统可以灵活地应对集群的伸缩。一般指两个方面,一方面指集群的容量可以伸缩,集群可以任意地添加和删除存储节点和存储设备;另一方面指系统的性能随集群的增加而线性增 加。 大规模集群环境下,要求Ceph存储系统的规模可以扩展到成千上万个节点。当集群规模达到一定程度时,系统在数据恢复、数据迁移、节点监测等方面会产生一系列富有挑战性的问题。 1.3 Ceph基本架构图 Ceph的整体架构由三个层次组成:最底层也是最核心的部分是RADOS对象存储系统。第二层是librados库层;最上层对应着Ceph不同形式的存储接口实现,架构如图1-2所示。 图1-2 Ceph基本架构图
12、Ceph的整体架构大致如下: 最底层基于RADOS(reliable,autonomous,distributed object store),它是一个可靠的、自组织的、可自动修复、自我管理的分布式对象存储系统。其内部包括ceph-osd后台服务进程和ceph-mon监控进 程。 中间层librados库用于本地或者远程通过网络访问RADOS对象存储系统。它支持多种语言,目前支持C/C+语言、Java、Python、Ruby和PHP语言的接口。 最上层面向应用提供3种不同的存储接口: 块存储接口,通过librbd库提供了块存储访问接口。它可以为虚拟机提供虚拟磁盘,或者通过内核映射为物理主机提供
13、磁盘空间。 对象存储接口,目前提供了两种类型的API,一种是和AWS的S3接口兼容的API,另一种是和OpenStack的Swift对象接口兼容的API。 文件系统接口,目前提供两种接口,一种是标准的posix接口,另一种通过libcephfs库提供文件系统访问接口。文件系统的元数据服务器MDS用于提供元数据访问。数据直接通过librados库访问。 1.4 Ceph客户端接口 Ceph的设计初衷是成为一个分布式文件系统,但随着云计算的大量应用,最终变成支持三种形式的存储:块存储、对象存储、文件系统,下面介绍它们之间的区别。 1.5 RADOS RADOS是Ceph存储系统的基石,是一个可扩展
14、的、稳定的、自我管理的、自我修复的对象存储系统,是Ceph存储系统的核心。它完成了一个存储系统的核心功能,包括:Monitor模块为整个存储集 群提供全局的配置和系统信息;通过CRUSH算法实现对象的寻址过程;完成对象的读写以及其他数据功能;提供了数据均衡功能;通过Peering过程完成一个PG内存达成数据一致性的过程;提供数据自动 恢复的功能;提供克隆和快照功能;实现了对象分层存储的功能;实现了数据一致性检查工具Scrub。下面分别对上述基本功能做简要的介绍。 1.6 本章小结 本章介绍了Ceph的系统架构,通过本章,可以对Ceph的基本架构和各个模块的组件有了整体的了解,并对一些基本概念及
15、读写的原理、各个数据功能模块有了大致了解。 本章介绍的Ceph客户端的基本概念,在第5章会详细介绍到。本章介绍的对象寻址的CRUSH算法将会在第4章详细介绍到。在本章介绍的本地对象存储将会在第7章详细介绍到。本章介绍的数据读写流 程,将会在第6章详细介绍。本章介绍的纠删码将在第8章中详细介绍。本章介绍的快照和克隆将在第9章详细介绍。本章介绍的Ceph Peering的过程将会在第10章详细介绍。本章介绍的数据恢复和回填将会 在第11章介绍到。本章介绍的Ceph Srcub机制将会在第12章详细介绍。本章介绍的Cache Tier将在第13章详细介绍。 第2章 Ceph通用模块 本章介绍Ceph
16、源代码通用库中的一些比较关键而又比较复杂的数据结构。Object和Buffer相关的数据结构是普遍使用的。线程池ThreadPool可以提高消息处理的并发能力。Finisher提供了异步操作时来执 行回调函数。Throttle在系统的各个模块各个环节都可以看到,它用来限制系统的请求,避免瞬时大量突发请求对系统的冲击。SafteTimer提供了定时器,为超时和定时任务等提供了相应的机制。理解这些数 据结构,能够更好理解后面章节的相关内容。 2.1 Object 对象Object是默认为4MB大小的数据块。一个对象就对应本地文件系统中的一个文件。在代码实现中,有object、sobject、hob
17、ject、ghobject等不同的类。 结构object_t对应本地文件系统的一个文件,name就是对象名: struct object_t string name; http:/ sobject_t在object_t之上增加了snapshot信息,用于标识是否是快照对象。数据成员snap为快照对象的对应的快照序号。如果一个对象不是快照对象(也就是head对象),那么snap字段就被设置为 CEPH_NOSNAP值。 struct sobject_t object_t oid; snapid_t snap; http:/ hobject_t是名字应该是hash object的缩写。 struc
18、t hobject_t object_t oid; snapid_t snap; private: uint32_t hash; bool max; uint32_t nibblewise_key_cache; uint32_t hash_reverse_bits; public: int64_t pool; string nspace; private: string key; http:/ 其在sobject_t的基础上增加了一些字段: int64_t pool:所在的pool的id。 string nspace:nspace一般为空,它用于标识特殊的对象。 string key:对象的特
19、殊标记。 string hash:hash和key不能同时设置,hash值一般设置为就是pg的id值。 ghobject_t在对象hobject_t的基础上,添加了generation字段和shard_id字段,这个用于ErasureCode模式下的PG: shard_id用于标识对象所在的osd在EC类型的PG中的序号,对应EC来说,每个osd在PG中的序号在数据恢复时非常关键。如果是Replicate类型的PG,那么字段就设置为NO_SHARD(-1),该字段对于 replicate是没用。 generation用于记录对象的版本号。当PG为EC时,写操作需要区分写前后两个版本的objec
20、t,写操作保存对象的上一个版本(generation)的对象,当EC写失败时,可以rollback到上一个版本。 struct ghobject_t hobject_t hobj; gen_t generation; shard_id_t shard_id; bool max; public: static const gen_t NO_GEN = UINT64_MAX; http:/ 2.2 Buffer Buffer就是一个命名空间,在这个命名空间下定义了Buffer相关的数据结构,这些数据结构在Ceph的源代码中广泛使用。下面介绍的buffer:raw类是基础类,其子类完成了Buffer
21、数据空间的分 配,buffer:ptr类实现了Buffer内部的一段数据,buffer:list封装了多个数据段。 2.3 线程池 线程池(ThreadPool)在分布式存储系统的实现中是必不可少的,在Ceph的代码中广泛用到。Ceph中线程池的实现也比较复杂,结构如下: class ThreadPool : public md_config_obs_t CephContext *cct; string name; /线程池的名字 string lockname; /锁的名字 Mutex _lock; /线程互斥的锁,也是工作队列访问互斥的锁 Cond _cond; /锁对应的条件变量 boo
22、l _stop; /线程池是否停止的标志 int _pause; /暂时中止线程池的标志 int _draining; Cond _wait_cond; int ioprio_class, ioprio_priority; vector work_queues; /工作队列 int last_work_queue; /最后访问的工作队列 set _threads; /线程池中的工作线程 list _old_threads; /等待进joined操作的线程 int processing; 类ThreadPool里包函一些比较重要的数据成员: 工作线程集合_threads。 等待Join操作的旧线
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Ceph 源码 分析 html
链接地址:https://www.31doc.com/p-5519049.html