【Ceph浅析笔记】Ceph的逻辑结构

Ceph的结构

【Ceph浅析笔记】Ceph是什么.md里面我们介绍了Ceph的基本思想。下面我们先来介绍一下Ceph的基本结构。

image.png

  • 基础存储系统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就可以得到数据存放的地点。

image.png

对于传统的分布式存储,一般来说会有一个单独的元数据服务器,存放数据块与节点的映射关系,缺点是性能受限于此元数据服务器。而RADOS系统中,Client与OSD以及monitor交互获得Cluster Map,并存放于本地,然后可以在本地进行计算,获得对象存储位置。很显然避开了元数据服务器,不需要再进行查表操作了。

但是Cluster Map不是一成不变的,当OSD出现故障或者说有新的OSD加入的时候,Cluster Map应该进行更新,但是这种事件的频率远远低于Client对数据的访问频率。

image.png

posted @ 2018-03-05 12:06  dy2903  阅读(772)  评论(0编辑  收藏  举报