Ceph系统基础服务架构
Ceph的底层实现是RADOS，它向外界暴露了调用接口，即Librados,应用程序只需要调用Librados的接口,便可操纵Ceph。Ceph对象存储网关允许你通过Swift及S3 API访问Ceph。他将这些API请求转化为librados请求。
1、基础存储系统Rados
本身是一个完整的对象存储系统，Ceph系统用户数据最终由这一层存储，高可靠性、高扩展性、高自动化等特性本质由这一层提供。RADOS由大量的存储设备节点组成，每个节点拥有自己的硬件资源（CPU、内存、硬盘、网络），并运行着操作系统和文件系统。特点是CRUSH算法维护存储对象与存储服务器的对应关系，实现对象的寻址过程。
2、基础库Librados
对Rados进行抽象和封装，向上层提供API，方便基于RADOS进行应用开发。Librados实现的API也只是针对对象存储功能。本地API，通过Socket与RADOS集群中的节点通信并完成各种操作。(对象,块及文件三种访问接口，它们都通过底层的librados与后端的OSD交互)
3、高层应用接口
包含三部分：Radosgw、Rbd、CephFS，作用Librados库的基础上提供抽象层次更高、更便于应用或客户端使用的上层接口。基于RADOS实现了一个且兼容Swift和S3的存储系统radosgw。以及一个块设备驱动RBD。
4、应用层
基于Librados直接开发的对象存储应用，基于RADOS GW开发的对象存储应用，基于RBD实现的云硬盘等等。
Librados和radosgw的区别
Librados和Radosgw的区别在于，Librados提供的是本地API，而Radosgw 提供的则是RESTful API。
Radosgw针对对象存储应用开发者和对象存储应用用户；Librados中没有账户、容器这样的高层概念，向开发者开放了大量的Rados状态信息与配置参数，对系统存储策略进行控制。
Ceph数据存储过程
1. File —— 此处的file就是用户需要存储或者访问的文件。对于一个基于Ceph开发的对象存储应用而言，这个file也就对应于应用中的“对象”，也就是用户直接操作的“对象”。
2. Ojbect —— 此处的object是RADOS所看到的“对象”。Object与上面提到的file的区别是，object的最大size由RADOS限定（通常为2MB或4MB），以便实现底层存储的组织管理。当上层应用向RADOS存入size很大的file时，需要将file切分成统一大小的一系列object（最后一个的大小可以不同）进行存储。
3. PG（Placement Group）—— PG的用途是对object的存储进行组织和位置映射。具体而言，一个PG负责组织若干个object（可以为数千个甚至更多），但一个object只能被映射到一个PG中，即，PG和object之间是“一对多”映射关系。同时，一个PG会被映射到n个OSD上，而每个OSD上都会承载大量的PG，即，PG和OSD之间是“多对多”映射关系(副本关系)。在实践当中，n至少为2，如果用于生产环境，则至少为3。一个OSD上的PG则可达到数百个。事实上，PG数量的设置牵扯到数据分布的均匀性问题。
4. OSD —— 即object storage device，OSD的数量事实上也关系到系统的数据分布均匀性，因此其数量不应太少。在实践当中，至少也应该是数十上百个的量级才有助于Ceph系统的设计发挥其应有的优势。
Ceph中的寻址至少要经历以下三次映射：(File---->Rados层面object--->PG---->Osd)
1. File -> object映射
将用户要操作的file，映射为RADOS能够处理的object。本质上就是按照object的最大size对file进行切分。这种切分的好处有二：一是让大小不限的file变成最大size一致、可以被RADOS高效管理的object；二是让对单一file实施的串行处理变为对多个object实施的并行化处理。
2. Object -> PG映射
在file被映射为一个或多个object之后，需要将每个object独立地映射到一个PG中去。
3. PG -> OSD映射
第三次映射就是将作为object的逻辑组织单元的PG映射到数据的实际存储单元OSD。