文档章节

“CEPH浅析”系列之四——CEPH的结构

Yashin
 Yashin
发布于 2014/04/02 13:30
字数 2301
阅读 258
收藏 3

本文将从逻辑结构的角度对Ceph进行分析。

4.1    Ceph系统的层次结构

        Ceph存储系统的逻辑层次结构如下图所示[1]

Ceph系统逻辑层次结构
        自下向上,可以将Ceph系统分为四个层次:

        (1)基础存储系统RADOS(Reliable, Autonomic, Distributed Object Store,即可靠的、自动化的、分布式的对象存储)

        顾名思义,这一层本身就是一个完整的对象存储系统,所有存储在Ceph系统中的用户数据事实上最终都是由这一层来存储的。而Ceph的高可靠、高可扩展、高性能、高自动化等等特性本质上也是由这一层所提供的。因此,理解RADOS是理解Ceph的基础与关键。

        物理上,RADOS由大量的存储设备节点组层,每个节点拥有自己的硬件资源(CPU、内存、硬盘、网络),并运行着操作系统和文件系统。4.2、4.3节将对RADOS进行展开介绍。

        (2)基础库librados

        这一层的功能是对RADOS进行抽象和封装,并向上层提供API,以便直接基于RADOS(而不是整个Ceph)进行应用开发。特别要注意的是,RADOS是一个对象存储系统,因此,librados实现的API也只是针对对象存储功能的。

        RADOS采用C++开发,所提供的原生librados API包括C和C++两种,其文档参见[2]。物理上,librados和基于其上开发的应用位于同一台机器,因而也被称为本地API。应用调用本机上的librados 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,以供相应的对象存储应用开发使用。RADOS GW提供的API抽象层次更高,但功能则不如librados强大。因此,开发者应针对自己的需求选择使用。

        RBD则提供了一个标准的块设备接口,常用于在虚拟化的场景下为虚拟机创建volume。目前,Red Hat已经将RBD驱动集成在KVM/QEMU中,以提高虚拟机访问性能。

        Ceph FS是一个POSIX兼容的分布式文件系统。由于还处在开发状态,因而Ceph官网并不推荐将其用于生产环境中。

        (4)应用层

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

        在上文的介绍中,有一个地方可能容易引起困惑:RADOS自身既然已经是一个对象存储系统,并且也可以提供librados API,为何还要再单独开发一个RADOS GW?

        理解这个问题,事实上有助于理解RADOS的本质,因此有必要在此加以分析。粗看起来,librados和RADOS GW的区别在于,librados提供的是本地API,而RADOS GW提供的则是RESTful API,二者的编程模型和实际性能不同。而更进一步说,则和这两个不同抽象层次的目标应用场景差异有关。换言之,虽然RADOS和S3、Swift同属分布式对象存储系统,但RADOS提供的功能更为基础、也更为丰富。这一点可以通过对比看出。

        由于Swift和S3支持的API功能近似,这里以Swift举例说明。Swift提供的API功能主要包括:

  • 用户管理操作:用户认证、获取账户信息、列出容器列表等;
  • 容器管理操作:创建/删除容器、读取容器信息、列出容器内对象列表等;
  • 对象管理操作:对象的写入、读取、复制、更新、删除、访问许可设置、元数据读取或更新等。

        由此可见,Swift(以及S3)提供的API所操作的“对象”只有三个:用户账户、用户存储数据对象的容器、数据对象。并且,所有的操作均不涉及存储系统 的底层硬件或系统信息。不难看出,这样的API设计完全是针对对象存储应用开发者和对象存储应用用户的,并且假定其开发者和用户关心的内容更偏重于账户和数据的管理,而对底层存储系统细节不感兴趣,更不关心效率、性能等方面的深入优化。

        而librados API的设计思想则与此完全不同。一方面,librados中没有账户、容器这样的高层概念;另一方面,librados API向开发者开放了大量的RADOS状态信息与配置参数,允许开发者对RADOS系统以及其中存储的对象的状态进行观察,并强有力地对系统存储策略进行控制。换言之,通过调用librados API,应用不仅能够实现对数据对象的操作,还能够实现对RADOS系统的管理和配置。这对于S3和Swift的RESTful API设计是不可想像的,也是没有必要的。

        基于上述分析对比,不难看出,librados事实上更适合对于系统有着深刻理解,同时对于功能定制扩展和性能深度优化有着强烈需求的高级用户。基于librados的开发可能更适合于在私有Ceph系统上开发专用应用,或者为基于Ceph的公有存储系统开发后台数据管理、处理应用。而RADOS GW则更适合于常见的基于web的对象存储应用开发,例如公有云上的对象存储服务。

4.2    RADOS的逻辑结构

        RADOS的系统逻辑结构如下图所示[3]:

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

        在使用RADOS系统时,大量的客户端程序通过与OSD或者monitor的交互获取cluster map,然后直接在本地进行计算,得出对象的存储位置后,便直接与对应的OSD通信,完成数据的各种操作。可见,在此过程中,只要保证cluster map不频繁更新,则客户端显然可以不依赖于任何元数据服务器,不进行任何查表操作,便完成数据访问流程。在RADOS的运行过程中,cluster map的更新完全取决于系统的状态变化,而导致这一变化的常见事件只有两种:OSD出现故障,或者RADOS规模扩大。而正常应用场景下,这两种事件发生的频率显然远远低于客户端对数据进行访问的频率。

4.3    OSD的逻辑结构

        根据定义,OSD可以被抽象为两个组成部分,即系统部分和守护进程(OSD deamon)部分。

        OSD的系统部分本质上就是一台安装了操作系统和文件系统的计算机,其硬件部分至少包括一个单核的处理器、一定数量的内存、一块硬盘以及一张网卡。

        由于这么小规模的x86架构服务器并不实用(事实上也见不到),因而实际应用中通常将多个OSD集中部署在一台更大规模的服务器上。在选择系统配置时,应当能够保证每个OSD占用一定的计算能力、一定量的内存和一块硬盘。同时,应当保证该服务器具备足够的网络带宽。具体的硬件配置选择可以参考[4]。

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

        Ceph系统的逻辑结构就介绍到这里。下篇文章将着重说明Ceph(主要是RADOS)的工作原理和操作流程。

 

说明:  转载请注明出处。谢谢。

本文转载自:http://yizhaolingyan.net/?p=55

Yashin

Yashin

粉丝 257
博文 55
码字总数 5378
作品 1
深圳
高级程序员
私信 提问
加载中

评论(9)

老叮当猫
老叮当猫

引用来自“oscfox”的评论

mon集群会通过Paxos算法选主,看我新的转载 http://my.oschina.net/oscfox/blog/307499

引用来自“老叮当猫”的评论

那我客户端挂载mon时是需要指定固定ip的,该ip的mon挂了,其他的mon也能透明接管么?

引用来自“oscfox”的评论

这个问题我遇到过,没能接管,我测测应该有策略接管才对。那时忙其他的事情没解决,接下来去研究研究。如果兄台有办法也请不吝赐教
我才刚刚开始研究,不知道添加一个类似ctdb中间件,客户端挂载虚拟IP,由这个中间件接管IP好不好使。
Yashin
Yashin 博主

引用来自“oscfox”的评论

mon集群会通过Paxos算法选主,看我新的转载 http://my.oschina.net/oscfox/blog/307499

引用来自“老叮当猫”的评论

那我客户端挂载mon时是需要指定固定ip的,该ip的mon挂了,其他的mon也能透明接管么?
这个问题我遇到过,没能接管,我测测应该有策略接管才对。那时忙其他的事情没解决,接下来去研究研究。如果兄台有办法也请不吝赐教
老叮当猫
老叮当猫

引用来自“oscfox”的评论

mon集群会通过Paxos算法选主,看我新的转载 http://my.oschina.net/oscfox/blog/307499
那我客户端挂载mon时是需要指定固定ip的,该ip的mon挂了,其他的mon也能透明接管么?
Yashin
Yashin 博主
mon集群会通过Paxos算法选主,看我新的转载 http://my.oschina.net/oscfox/blog/307499
老叮当猫
老叮当猫

引用来自“oscfox”的评论

引用来自“老叮当猫”的评论

好东西,客户端获取cluster map 后进行计算的话,mon进程本身计算压力就很小了,一个集群部署时,几个mon就可以了,可以这么理解么?

是的,具体看集群的数量以及可靠性要求高不高了。ceph比较有趣的地方是可靠性和性能此消彼长。

引用来自“老叮当猫”的评论

谢谢,还有几个疑问,客户端计算处osd的位置是直接与osd通信么?ceph是支持内外网划分的,ceph是如何划分内外网呢?客户端是不是必须由mon进程转发与osd的通信?mon理论上会不会成为性能瓶颈啊? 刚刚接触ceph,看到你写的文章不错,麻烦大神了

引用来自“oscfox”的评论

mon只是管理集群而已,不会参与数据的转发,client是算出数据放哪里后直接与osd通讯的,只要集群稳定,我的理解是不会成为性能瓶颈。对于如何内外网划分,这个我没研究过。澄清一下,这些文章几乎都是转载的,我也只是初学而已,大神愧不敢当,很高兴相互学习。
太谦虚了,客户端通过mon获取cluster map后,若该mon宕机后其他mon会自动接管该mon么?或者客户端能主动尝试与其他up的mon建立连接么?
Yashin
Yashin 博主

引用来自“oscfox”的评论

引用来自“老叮当猫”的评论

好东西,客户端获取cluster map 后进行计算的话,mon进程本身计算压力就很小了,一个集群部署时,几个mon就可以了,可以这么理解么?

是的,具体看集群的数量以及可靠性要求高不高了。ceph比较有趣的地方是可靠性和性能此消彼长。

引用来自“老叮当猫”的评论

谢谢,还有几个疑问,客户端计算处osd的位置是直接与osd通信么?ceph是支持内外网划分的,ceph是如何划分内外网呢?客户端是不是必须由mon进程转发与osd的通信?mon理论上会不会成为性能瓶颈啊? 刚刚接触ceph,看到你写的文章不错,麻烦大神了
mon只是管理集群而已,不会参与数据的转发,client是算出数据放哪里后直接与osd通讯的,只要集群稳定,我的理解是不会成为性能瓶颈。对于如何内外网划分,这个我没研究过。澄清一下,这些文章几乎都是转载的,我也只是初学而已,大神愧不敢当,很高兴相互学习。
老叮当猫
老叮当猫

引用来自“oscfox”的评论

引用来自“老叮当猫”的评论

好东西,客户端获取cluster map 后进行计算的话,mon进程本身计算压力就很小了,一个集群部署时,几个mon就可以了,可以这么理解么?

是的,具体看集群的数量以及可靠性要求高不高了。ceph比较有趣的地方是可靠性和性能此消彼长。
谢谢,还有几个疑问,客户端计算处osd的位置是直接与osd通信么?ceph是支持内外网划分的,ceph是如何划分内外网呢?客户端是不是必须由mon进程转发与osd的通信?mon理论上会不会成为性能瓶颈啊? 刚刚接触ceph,看到你写的文章不错,麻烦大神了
Yashin
Yashin 博主

引用来自“老叮当猫”的评论

好东西,客户端获取cluster map 后进行计算的话,mon进程本身计算压力就很小了,一个集群部署时,几个mon就可以了,可以这么理解么?

是的,具体看集群的数量以及可靠性要求高不高了。ceph比较有趣的地方是可靠性和性能此消彼长。
老叮当猫
老叮当猫
好东西,客户端获取cluster map 后进行计算的话,mon进程本身计算压力就很小了,一个集群部署时,几个mon就可以了,可以这么理解么?
“Ceph浅析”系列之四——Ceph的结构

本文将从逻辑结构的角度对Ceph进行分析。 4.1 Ceph系统的层次结构 Ceph存储系统的逻辑层次结构如下图所示[1]。 自下向上,可以将Ceph系统分为四个层次: (1)基础存储系统RADOS(Reliable,...

红薯
2014/04/01
1K
0
Ceph 浅析(上):概况与设计思想

摘要:其命名和UCSC(Ceph 的诞生地)的吉祥物有关,这个吉祥物是 “Sammy”,一个香蕉色的蛞蝓,就是头足类中无壳的软体动物。这些有多触角的头足类动物,是对一个分布式文件系统高度并行的...

红薯
2014/04/01
2.2K
3
“Ceph浅析”系列之五——Ceph的工作原理及流程

本 文将对Ceph的工作原理和若干关键工作流程进行扼要介绍。如前所述,由于Ceph的功能实现本质上依托于RADOS,因而,此处的介绍事实上也是针对 RADOS进行。对于上层的部分,特别是RADOS GW和R...

红薯
2014/04/01
2.9K
2
“CEPH浅析”系列之三——CEPH的设计思想

分析开源项目,时常遇到的一个问题就是资料不足。有时间写代码的大牛们通常是都是没有时间或者根本不屑于写文档的。而不多的文档通常又是使用手册之类的东西。即便偶尔有设计文档通常也是语焉...

Yason_Luo
2014/04/02
304
0
Ceph浅析(中):结构、工作原理及流程

Ceph的结构 Ceph系统的层次结构 Ceph存储系统的逻辑层次结构如下图所示: 自下向上,可以将Ceph系统分为四个层次: (1)基础存储系统RADOS(Reliable, Autonomic, Distributed Object Store...

wangdy
2016/07/10
141
0

没有更多内容

加载失败,请刷新页面

加载更多

手持式人证核验设备助力国家安全系统

手持式人证核验设备,是针对公共安全领域的移动化身份核验、追逃等需求推出的手持式一体化设备。其特点是具备人员信息采集、存储和比对功能,将采集到的人脸信息与居民身份证芯片中的人脸信息...

非思丸智能FaceTo
11分钟前
2
0
好程序员web前端教程分享JavaScript简写方法

今天好程序员web前端教程为大家分享JavaScript简写方法,小伙伴们快来看一看吧。 1.三元操作符 当想写if...else语句时,使用三元操作符来代替。 constx =20; let answer; if(x >10) { answer...

好程序员官网
15分钟前
3
0
PHP面试题2019年小米工程师面试题和答案解析

一、单选题(共29题,每题5分) 1.PHP面向对象方法重写描述错误的是? A、子类必须继承父类 B、子类可以重写父类已有方法 C、重写之后子类会调用父类方法 D、子类也可以具有与父类同名的属性...

一个PHP程序媛
18分钟前
2
0
K8s 从懵圈到熟练 – 镜像拉取这件小事

导读:相比 K8s 集群的其他功能,私有镜像的自动拉取,看起来可能是比较简单的。而镜像拉取失败,大多数情况下都和权限有关。所以,在处理相关问题的时候,我们往往会轻松的说:这问题很简单...

Mr_zebra
19分钟前
3
0
分布式锁简单入门以及实现方法

学过Java多线程的应该都知道什么是锁,没学过的也不用担心,Java中的锁可以简单的理解为多线程情况下访问临界资源的一种线程同步机制。 在学习或者使用Java的过程中进程会遇到各种各样的锁的...

yanlijun_java
21分钟前
2
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部