ceph第一章

ceph整体架构：
RADOS是ceph的支撑组件，除了ceph当前的三大核心应用组件RBD、RGW、和cephFS之外（他们分别提供块、对象和文件访问接口）原则上，基于RADOS及其派生的librados标准库也可以开发任意类型的其他应用组件。侧重介绍RADOS及三大组件---RBD、RGW和CephFS。

第一章：

CRUSH是ceph两大核心设计之一。CRUSH良好的设计理念使其具有计算寻址、高并发、和动态数据均衡、可定制的副本策略等基本特性，进而能够非常方便地实现诸如去中心化、有效抵御物理结构变化并保证性能随着集群规模呈线性扩展、高可靠等高级特性，因而非常适合应用于ceph这类对可扩展性、性能和可靠性都具有严苛要求的大型分布式系统。

第二章

自jewel版本开始，社区引入了一种新型的高性能对象存储引擎-----bluestore，用于取代服役已经超过10年的filestore。BlueStore的引入毫无疑问是这两年来ceph最引人注目的特性之一。

第三章

ceph传统的三副本数据数据备份方式能够在取得高可靠性的情况下最小化前端请求的响应时延，因而特别适合对可靠性和性能都有一定要求的上层应用。这种目前使用最广泛的备份方式缺点在于会大量占用额外的存储空间，因而导致集群的实际空间利用率不高。与之相反，纠删码以条带为单位，通过数学变换，将采用任意K+M备份策略消耗的额外存储空间都控制在1倍以内，代价是计算资源消耗变大和前端请求响应时延变长，因而适合对时延不敏感的冷数据应用。在Kraken版本中，社区通过解决纠删码中最复杂的覆盖写难题，使得纠删码类型的存储池第一次见到迈向生产环境的曙光。

第四章

PG是ceph最核心和最复杂的念之一，这也使得学习和了解PG成ceph最富挑战性的工作之一。在PG为数众多的优秀特性之一，也许最重要也最引入注目的是它可以在osd之间自由进行迁移，这是ceph赖以实现自动数据恢复、自动数据平衡等高级特性的基础。

第五章

在虚拟化大行其道的今天，如何针对有限的资源进行集中管理并按需分配以最大化收益，一直是焦点议题之一。ceph通过积极引入Qos功能，有望对集群的IOPS、带宽等IO资源进行合理统筹，按需、定量分配，从而对外提供更加精细化的服务。

第六章

自07年sage A.Weil正式发布以来，ceph实际上已经存在并发展了10余年了。ceph在设计之初被定位为一个纯粹的分布式文件系统但随着虚拟化逐渐成为信息时代的主旋律和以openstack为代表的云计算技术的闪电崛起，社区果断调整重心，开始发展新型分布式块存储服务组件RBD，并使其逐渐成长为openstack等Iaas云计算环境中虚拟机、镜像、云盘等服务不可或缺的默认块存储设备后端。

第七章

当前，方兴未艾的云计算无疑代表了科技发展的下一波浪潮的到来，而率先基于AWS推出公有云服务并成为公有云事实标准的亚马逊公司无疑一只脚已经踏上了这波浪潮的浪潮之巅。自2006年以来，AWS当前存储的对象规模已经高达千亿级别，并已经累计为亚马逊创造了百亿美元的利润，由此可见云计算所蕴含的巨大商机。AWS要求存储系统能够提供传统块、文件、都不相同的对象存储，并采用自定义的S3协议通过互联网HTTp进行传输。在此背景下，为了赶上云计算为代表的这波科技浪潮，ceph兼容s3为代表的对象存储协议族的对象存储网关

第八章

文件系统伴随着操作系统一同诞生，是计算机科学中最基本和最经典的概念之一。ceph自诞生之日起便被定义为一个分布式文件系统。时至今日，在ceph的三大典型应用场景中，RBD和RGW先后乘着云计算东风后来居上，诞生起步最早的cephFS却一直未能有所建树。究其原因，一是文件系统采用树状结构管理数据（文件和目录），基于查表进行寻址的设计理念，与ceph采用扁平方式管理数据、基于计算进行寻址的设计理念格格不入；二是支持文件系统必然要求ceph引入集中的元数据管理服务器（作为树状结构的统一入口用于寻址），这又与ceph去中心化、追求近乎无限横向扩展能力的设计思想激烈冲突。