Ceph-设计思想及结构RADOS

Ceph-设计思想及结构

大规模的存储系统，有三个动态特性：

存储系统规模的变化：随着业务的不断发展，系统需要承载越来越大的数据容量。

存储系统中设备的变化：对于由成千上万个节点构成的系统，其节点的故障与替换必然是时长出现的情况，不能使业务受到这种频繁出现的硬件及底层软件问题的影响，同时应该智能化，并降低维护的成本。

存储系统中数据的变化：对于一个大规模，通常被应用于互联网应用中的存储系统，其中储存的变化很可能是高度频繁的。因此数据更新、移动乃至删除时常发生。

针对目标应用场景所提出的预期技术特性：

Ceph:高可靠性、高度自动化、高可扩展性。

针对预期技术特性所提出的设计思路：

充分发挥存储设备自身的计算能力，去除所有的中心点 

                  

(1)基础存储系统RADOS（Reliable,Autonomic,Distributed Object Store）可靠的自主的分布式对象存储

这一层本身就是一个完整的对象存储系统，所有存储在Ceph系统中的用户数据事实上最终都是由这一层来存储的。RADOS由大量的存储设备节点组成，每个节点拥有自己的硬件资源(CPU、内存、硬盘、网络)，并运行着操作系统和文件系统。

(2)基础库librados

这一层的功能是对RADOS进行抽象和封装，并向上层提供API，以便直接基于RADOS（而不是ceph）进行应用开发。物理上libradios和基于其上开发的应用位于同一台机器，因此也被成为本地API。应用调用本机上的libradios API，再由后者通过socket与RADIOS集群中的节点通信完成各种操作。

（3）高层应用接口

这一层包括了三个部分：RADOS GW(RADOS Gateway)、RBD(Reliable Block Device)和Ceph FS(Ceph File System),起作用时在librados库的基础上提供抽象层次更高、更便于应用或客户端使用的上层接口。

RADOS GW是一个提供Amazon S3 和Swift 兼容的RESTful API 的gateway,以供相应的对象存储应用开发使用。RAIDS GW 提供的API抽象层次更高，但功能不如librados强大。因此，开发者应针对自己的需求选择使用。

RBD则提供了一个标准的块设备接口，常用于在虚拟化的场景下创建volume。

Ceph FS 是一个POSIX兼容的分布式文件系统。目前还处于开发状态。

(4)应用层

这一层就是不同场景下对于Ceph各个应用接口的各种应用方式，例如基于librados直接开发的对象存储应用，基于RADOS GW 开发的对象存储应用，基于RBD实现的云硬盘等等。

疑问：

RADOS自身既然已经是一个对象存储系统，也可以提供librados API，为何还要再单独开发一个RADOS GW?

答：

粗看起来，librados和RADOS的区别在于，librados提供的是本地API，而RADOS GW 提供的则是RESTful API,二者的编程模型和实际性能不同。进一步说，二者抽象层次的目标应用场景差异有关。换言之，虽然RADOS和S3、Swift同属分布式对象存储系统，但RADOS提供的功能更为基础、丰富。

注：RESTful ：

一种软件架构风格，设计风格而不是标准，只是提供了一组设计原则和约束条件。它主要用于客户端和服务器交互类的软件。基于这个风格设计的软件可以更简洁，更有层次，更易于实现缓存等机制。

 

librados API向开发者开放了大量的RADOS状态信息与配置参数，允许开发者对RADOS系统以及其中存储对象的状态进行观察，并强有力地对系统存储策略进行控制。换言之，通过调用librados API,应用帛能够实现对数据对象的操作，还能够实现对RADOS系统的管理和配置。librados更适用于对系统有着深刻理解，同时对于功能定制扩展和性能深度优化有着强烈需求的高级用户。基于librados的开发更适合在私有Ceph系统上开发专用应用，或者为基于Ceph的公有存储系统开发后台数据管理、处理应用。而RADOS GW则更适用于常见的基于web的对象存储应用开打，例如公有云上的对象存储服务。

 

RADOS的逻辑结构

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

 

RADOS集群主要由两种节点组成。一种是为数众多的、负责完成数据存储和维护功能的OSD(Object Storage Device),另一种则是若干个负责完成系统状态监测和维护的monitor。OSD和monitor之间互相传输节点状态信息，共同得出系统的总体工作状态，并形成一个全局系统状态记录数据结构，即cluster map。这个数据结构与RADOS提供的特定算法相配合，以便实现了Ceph”无须查表，算算就好”的核心机制以及若干优秀特性。

在使用RADOS系统时，大量的客户端程序通过OSD或者monitor的交互获取cluster map,然后直接在本地进行计算，得出对象的存储位置后，便直接与对应的OSD通信，完成数据的各种操作。

在RADOS的运行过程中，cluster map的更新完全取决于系统的状态变化，而导致这一变化的常见时间只有两种：OSD出现故障、RADIOS规模扩大。

 

OSD的逻辑结构

由数目可变的大规模OSDs组成的集群，负责存储所有的Objects数据

OSD可以被抽象成两个组成部分，即系统部分和守护进程部分。

OSD的系统本质就是一台安装了操作系统和文件系统的计算机，其硬件部分至少包括一个单核的处理器，一定数量的内存、一块硬盘以及一张网卡。在实际应用中通常将多个OSD集中部署在一台更大规模的服务器上，

在上述平台上，每个OSD拥有一个自己的OSD deamon。这个deamon负责完成OSD的所有逻辑功能，包括与monitor和其他OSD(事实上是其他OSD的deamon)通信以维护更新系统状态，与其他OSD共同完成数据的存储和维护，与client通信完成各种数据对象操作等。

 

由少量Monitors组成的强耦合、小规模级去哪负责管理Cluster Map ,其中Cluster Map是真个RADOS系统的关键数据结构，管理寄去那种的所有成员、关系、属性等信息以及数据的分发。

Cluster Map：

管理cluster的核心数据结构

指定OSDs的数据分布信息

monitor上存有最新副本

依靠epoch增加来维护及时更新

增量信息

 

数据存放

1.Object到PG的映射。PG(Placement Group)是Objects的逻辑集合。相同PG里的Object会被系统分发到相同的OSDs集合中。由Object的名称通过Hash算法得到的结果结合其他一些参数可以得到Object所对应的PF。

2.RADOS系统根据Cluster Map将PGs分配到相应的OSDs。这组OSDs证实PG中的Objects数据的存储位置。

pools:

是一个存储对象的逻辑分区概念

所有权/访问对象

对象副本的数目

PG数目

以上三项决定ceph最后如何存储数据