ceph学习小结

              最近部署ceph，硬是在工作之外挤时间研究了下ceph的相关的内部的东西，下面主要是通过看别人的文章以及自己工作用到的的知识总结而成。这可以算是ceph的笔记吧。     

            

ceph使用C++语言开发,主要是考虑到性能因素。

Ceph是一种为优秀的性能,可靠性和可扩展性而设计的统一的、分布式的存储系统。

Ceph提供对象存储（对应openstack里的Swift）、块存储和文件系统存储三种功能。

ceph分布式实现了真正无中心结构。

设计思路：1、发挥存储设备的计算能力。2、去除所有的中心点

传统的分布式存储系统是以查表的数据存储方式，每个数据对应着一个地址，对数据操作就去找他的地址。

标准说法就是，引入专用的服务器节点，在其中存储维护数据存储空间映射关系的数据结构。用户访问数据，首先连接此服务器查找数据实际存储位置，再连接对应节点进行后续操作。这种存储方式会导致操作延迟，性能瓶颈，单点故障。

ceph是基于计算的数据存储方式。即任何一个ceph存储系统的客户端程序，使用不定期更新的少量本地元数据，简单计算，就可得到一个数据的ID决定其存储位置。

Ceph存储系统的逻辑层次结构4层：

1、基础存储系统RADOS（Reliable,Autonomic,Distributed objectStore,即可靠的，自动化的，分布式的对象存储系统）。采用C++开发。存储ceph系统中的用户数据。RADOS由很多存储设备节点组成。

2、基础库librados，是对RADOS抽象和封装，并向上提供API，以便直接基于RADOS进行应用开发。实现的API是只针对对象存储系统。不是针对整个ceph。物理上，librados和基于其上开发的应用是在同一台机器，所以也叫本地API。应用调用本地API，再由API通过socket和RADOS集群中的节点通信完成各种操作。

3、高层应用接口。包括三个部分：RADOS GW(RADOS Gateway)、RBD(Reliable Block Device)和ceph FS（ceph file system）。这是librados库的基础上提供抽象层次更高，更便于应用或客户端使用的上层接口。  RADOS GW提供与amazon S3 和Swift 兼容的 restful api gateway，供相应对象存储应用开发使用。 RBD提供标准块设备接口，用于虚拟化场景下为虚拟机创建volume。 ceph FS是一个posix（可移植操作系统接口）兼容的分布式文件系统。

4、应用层。不同场景下对于ceph各个应用接口的各种应用。如基于RBD的云硬盘。

swift 提供的API功能包括：

用户管理操作：用户认证、获取账户信息、列出容器列表等；

容器管理操作：创建/删除容器、读取容器信息、列出容器内对象列表等；

对象管理操作：对象的写入、读取、复制、更新、删除、访问许可设置、元数据读取或更新等。

Swift选择了Python语言进行开发。

swift不涉及存储系统的底层硬件或系统信息，针对对账户和数据的管理感兴趣的人。librados针对对系统有深刻理解，并对功能定制扩展和性能深度优化有需求的人。基于librados开发适合基于ceph共有存储系统开发后台数据管理，处理应用。RADOS GW适合基于web的对象存储应用开发，如公有云上的对象存储服务。

 RADOS的系统逻辑结构如下图所示：

过程：新osd上线，配置信息与monitor通信，monitor将其加入到cluster map，设置up且out状态（osd正常，未承载PG）。将最新版cluster map 发给新osd，收到monitor发的cluster map后，新osd计算所承载的PG，和自己承载同一个PG的其他osd。新的osd和其他osd联系，若新osd处于degrade，（即承载的osd个数少于正常值，正常是三个）。则其他osd将把这个PG内的所有对象和元数据复制给新osd。复制结束，新osd被置为up且in状态。而cluster map内容页更新。事实是一个自动化的failure recovery。（这里osd和monitor之间的cluster map有点类似ospf协议里的动态对象状态库构建过程）

Ceph对cluster map 信息扩散机制的优化：cluster map（全局系统状态记录数据结构）信息以增量形式扩散，达到cluster map的一致；以异步且lazy扩散。

 

总结：ceph是基于cluster map机制，由monitor，osd和client共同配合完成集群状态的维护和数据访问的。

RADOS集群

由两种节点组成:OSD(数据存储和维护功能)：object storage device。Monitor（系统状态检测盒维护）。Osd和monitor之间相互传递状态信息，得出全局系统状态记录数据结构，即cluster map，这个数据结构和rados的特定算法配合，计算数据的ID得出存储位置，与对应的OSD通信，完成数据各种操作。

Ceph系统中的寻址流程

File：用户直接操作的对象（文件）。Object：RADOS看到的对象。最大的size由RADOS限定，为了方便实现底层存储的组织和管理。当file很大，需要切分成统一大小的object(最后一个object除外)。PG（placement Group），对object存储进行组织和位置映射。PG和object是一对多映射，PG和OSD是多对多关系。

File和object映射：将用户操作的file切分变为RADOS可处理的object。每一个object获得唯一oid即object id。Ino为file ID，ono为切分的序号，oid即为序号两者连接而成。

Object和PG映射：hash(oid)&mask->pgid。哈希算法。

PG->osd映射：将作为object逻辑组织单元的PG映射到数据实际存储单元osd。CRUSH（pgid）->(osd1,osd2，…osdn),n个osd存储维护一个对应的PG中的object（osd一般为3个）。Deamon负责执行映射到本地的object在本地文件系统中的存储，访问，元数据维护等操作。Crush算法结果可变，受系统状态和存储策略影响。

引入PG好处：1、实现了object和osd之间动态映射，为ceph的可靠性，自动化等特性实现留下空间。2、简化了数据存储组织，大大降低了系统的维护管理开销。

OSD使用cluster map进行数据的维护，而client使用clustermap进行数据的寻址。

Up且out，该osd正常运行，为承载pg。down且in，osd故障，不能承载osd。

 

OSD使用cluster map进行数据的维护，而client使用clustermap进行数据的寻址。

 

对于一个IaaS系统，涉及到存储的部分主要是块存储服务模块、对象存储服务模块、镜像管理模块和计算服务模块。具体针对OpenStack而言，则分别对应为其中的Cinder、Swift、Glance和Nova四个项目

 

Swift和ceph的选择：

如果需要一个纯粹的对象存储系统，则选择Swift；

        如果需要一个纯粹的块存储系统，则只能选择Ceph；

        如果是一个小规模的、希望控制系统复杂度的OpenStack部署方案，则选择Ceph；

        如果是一个规模较大的系统，块存储和对象存储分别有较大的业务需求，则可以考虑将二者分离，分别采用Ceph和Swift。

 

常用到的单词：

Deamon：守护进程。

最后感谢以下介绍ceph的文章，讲的很详细：

Ceph浅析：http://www.infoq.com/cn/news/2014/01/ceph-overview

官网：http://ceph.com/