Ceph的结构
在【Ceph浅析笔记】Ceph是什么.md里面我们介绍了Ceph的基本思想。下面我们先来介绍一下Ceph的基本结构。
基础存储系统RADOS
最底层是数据真正存放的地方，物理上由大量的节点所构成，然后在上面加了一个中间层，可以实现Ceph的可靠性、自动化、可扩展等特性，所有我们将之称为RADOS(Reliable,Autonomic,Distributed Object Store)
librados
然后我们希望能对客户透明，也就是用户不需要关心底层如何实现的，只需要直接在Ceph上进行开发。所以又加了一堆库函数librados。这些库函数与应用一般来说在同一台节点上，所以也被称为本地API
Restful API
由于Ceph是基于C++开发的，那么librados提供的结构也是C或者C++的。
而且我们也希望Ceph能于Amazon S3和Swift这些分布式系统所兼容，所以可以再在上面加一个中间层，比如RADOS GW, RDD,Ceph FS。
比如说RADOS GW，本质就是一个网关，也就是可以提供协议的转换，这样对外就可以兼容S3和Swift的了。
RBD，全称是Reliable Block Device，也就是一个块设备接口，这样上层的操作系统看到的其实就是裸硬盘。
有了块存储接口，当然也有文件系统接口，Ceph FS就是一个POSIX兼容的分布式文件系统。
那么librados API和RADOS GW有啥区别呢？
抽象程度不一样，也就是对应的场景不同而已。librados更偏底层，允许开发者对存储的对象的状态进行提取，这样用户可以进行深度定制。
而RADOS GW屏蔽了很多细节，它主要是针对于应用开发者的，所以有用户账户、存储数据的容器、数据对象的概念，适合于常见的WEb对象存储应用开发。
RADOS 的逻辑结构
上一章主要介绍了Ceph的分层架构，那么里面最重要最底层的RADOS是我们接下来介绍的重点。
首先我们来介绍一下RADOS里面的几个角色
Clients
顾名思义，就是客户端，它可以是一个程序，也可能是命令行，反正用户必须通过Clients程序与存储节点打交道。
OSD(对象存储设备)
我们把存储数据的节点叫OSD，实际上OSD是一台安装了操作系统和文件系统的Server，一般来说，一个OSD至少包含了单核CPU、内存、一块硬盘、一张网卡等。但是事实上一台这么小的Server几乎找不到，所以我们可以把若干OSD部署在更大的服务器上。
每个OSD都有一个deamon，它的作用是介绍Client的访问连接，与monitor以及其他的OSD通信，与其他的OSD工程进行数据存储维护等。也就是说deamon完成了OSD的逻辑功能
monitor：
主要用来进行系统状态检测和维护。OSD会与monitor交互节点状态信息，形成全局的元数据，也即Cluster map。使用这个Cluter map就可以得到数据存放的地点。
对于传统的分布式存储，一般来说会有一个单独的元数据服务器，存放数据块与节点的映射关系，缺点是性能受限于此元数据服务器。而RADOS系统中，Client与OSD以及monitor交互获得Cluster Map，并存放于本地，然后可以在本地进行计算，获得对象存储位置。很显然避开了元数据服务器，不需要再进行查表操作了。
但是Cluster Map不是一成不变的，当OSD出现故障或者说有新的OSD加入的时候，Cluster Map应该进行更新，但是这种事件的频率远远低于Client对数据的访问频率。
