Ceph企业分布式存储——概述篇
英语文化交流 > 技术博客 > Ceph企业分布式存储——概述篇
Ceph企业分布式存储——概述篇
时间: 分类:技术博客

一、概述

             Ceph是可靠的、可扩展的、统一的、开源分布式的存储系统。可以同时提供对象存RADOSGW(Reliable、Autonomic、Distributed、Object Storage Gateway)、块存储RBD(Rados Block Device)、文件系统存储Ceph FS(Ceph Filesystem)3种功能。  

  Ceph是一个开源的分布式文件系统。因为它还支持块存储、对象存储,所以很自然的被用做云计算框架openstack或cloudstack整个存储后端。当然也可以单独作为存储,例如部署一套集群作为对象存储、SAN存储、NAS存储等。

         ceph官方文档 http://****/

  ceph中文开源社区 http://****/

linux中硬盘的分类

查看下Linux环境中的设备:

            [root@seph ~] ls /dev/
    /dev/sda/ dev/sda1 /dev/sda2 /dev/sdb /dev/sdb1 /dev/hda 
    /dev/rbd1 /dev/rbd2 …

上面的/dev/sda、/dev/sdb和/dev/hda都是块设备文件,这些文件是怎么出现的呢?

            当给计算机连接块设备(硬盘)后,系统检测的有新的块设备,该类型块设备的驱动程序就在/dev/下创建个对应的块设备设备文件,用户就可以通过设备文件使用该块设备了。

sda?sdb?hda?

            以sd开头的块设备文件对应的是SATA接口的硬盘,而以hd开头的块设备文件对应的是IDE接口的硬盘。那SATA接口的硬盘跟IDE接口的硬盘有啥区别?你只需要知道,IDE接口硬盘已经很少见到了,逐渐被淘汰中,而SATA接口的硬盘是目前的主流。而sda和sdb的区别呢?当系统检测到多个SATA硬盘时,会根据检测到的顺序对硬盘设备进行字母顺序的命名。PS:系统按检测顺序命名硬盘会导致了**盘符漂移**的问题

rbd1 和 rbd2

            rbd*就是由Ceph集群提供出来的块设备。可以这样理解,sda和hda都是通过数据线连接到了真实的硬盘,而rbd是通过网络连接到了Ceph集群中的一块存储区域,往rbd设备文件写入数据,最终会被存储到Ceph集群的这块区域中。

那么块设备怎么用呢?这里举个例子

            打个比方,一个块设备是一个粮仓,数据就是粮食。农民伯伯可以存粮食(写数据)了,需要存100斤玉米,粮仓(块设备)这么大放哪里呢,就挨着放(顺序写)吧。又需要存1000斤花生,还是挨着放吧。又需要存……

后来,农民伯伯来提粮食(读数据)了,他当时存了1000斤小麦,哎呀妈呀,粮仓这么大,小麦在哪里啊?仓库管理员找啊找,然后哭晕在了厕所……

新管理员到任后,想了个法子来解决这个问题,用油漆把仓库划分成了方格状,并且编了号,在仓库门口的方格那挂了个黑板,当农民伯伯来存粮食时,管理员在黑板记录,张三存了1000斤小麦在xx方格处。后来,农民伯伯张三来取粮食时,仓库管理员根据小黑板的记录很快提取了粮食。
故事到此为止了,没有方格和黑板的仓库(块设备)称为裸设备。由上例可见,裸设备对于用户使用是很不友好的,直接导致了旧仓库管理员的狗带。例子中划分方格和挂黑板的过程其实是在块设备上构建文件系统的过程,文件系统可以帮助块设备对存储空间进行条理的组织和管理,于是新管理员通过文件系统(格子和黑板)迅速找到了用户(农民伯伯张三)存储的数据(1000斤小麦)。针对多种多样的使用场景,衍生出了很多的文件系统。有的文件系统能够提供更好的读性能,有的文件系统能提供更好的写性能。我们平时常用的文件系统如xfs、ext4是读写性能等各方面比较均衡的通用文件系统。

能否直接使用不含有文件系统块设备呢?

            可以的,xfs和ext4等通用的文件系统旨在满足大多数用户的存储需求,所以在数据存储的各方面的性能比较均衡。然而,很多应用往往并不需要这种均衡,而需要突出某一方面的性能,如小文件的存储性能。此时,xfs、ext4等通用文件系统如果不能满足应用的需求,应用往往会在裸设备上实现自己的数据组织和管理方式。简单的说,就是应用为了强化某种存储特性而实现自己定制的数据组织和管理方式,而不使用通用的文件系统。

Ceph块设备接口怎么使用?

            在Ceph集群中创建块设备:
            // 保证/etc/ceph目录下有Ceph集群的配置文件ceph.conf和ceph.client.admin.keyring
            rbd create -s 1G myrbd
            在用户机上挂载该Ceph块设备,可以理解为往用户机上插入硬盘:
            rbdmap myrbd
            // 输出:
            /dev/rbd1

            将Ceph块设备格式化成文件系统并挂载:
            mkfs.xfs /dev/rbd1
            mkdir -p /mnt/ceph_rbd
            mount /dev/rbd1 /mnt/ceph_rbd

Ceph的文件系统存储接口

            **什么是Ceph的文件系统接口?**
            用户可以在块设备上创建xfs文件系统,也可以创建ext4等其他文件系统。如图,Ceph集群实现了自己的文件系统来组织管理集群的存储空间,用户可以直接将Ceph集群的文件系统挂载到用户机上使用。

            ![](https://s1.51cto.com/images/blog/201905/13/6aa30eef6c5f48993ef76d6605906a74.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=)

        **  Ceph有了块设备接口,在块设备上完全可以构建一个文件系统,那么Ceph为什么还需要文件系统接口呢?**
            主要是因为应用场景的不同,Ceph的块设备具有优异的读写性能,但不能多处挂载同时读写,目前主要用在OpenStack上作为虚拟磁盘,而Ceph的文件系统接口读写性能较块设备接口差,但具有优异的共享性。

            **为什么Ceph的块设备接口不具有共享性,而Ceph的文件系统接口具有呢?**
            对于Ceph的块设备接口,如图2,文件系统的结构状态是维护在**各用户机内存**中的,假设Ceph块设备同时挂载到了用户机1和用户机2,当在用户机1上的文件系统中写入数据后,更新了用户机1的内存中文件系统状态,最终数据存储到了Ceph集群中,但是此时用户机2内存中的文件系统并不能得知底层Ceph集群数据已经变化而维持数据结构不变,因此用户无法从用户机2上读取用户机1上新写入的数据

            对于Ceph的文件系统接口,如图,文件系统的结构状态是维护在远端Ceph集群中的,Ceph文件系统同时挂载到了用户机1和用户机2,当往用户机1的挂载点写入数据后,远端Ceph集群中的文件系统状态结构随之更新,当从用户机2的挂载点访问数据时会去远端Ceph集群取数据,由于远端Ceph集群已更新,所有用户机2能够获取最新的数据。

            ![](https://s1.51cto.com/images/blog/201905/13/59c9230ac02a194f62cbd334f0268270.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=)

            ![](https://s1.51cto.com/images/blog/201905/13/1af8462ebf7c4e3adfae5c6b9fc8cefa.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=)

            **Ceph的文件系统接口使用方式?**

            将Ceph的文件系统挂载到用户机目录
            /* 保证/etc/ceph目录下有Ceph集群的配置文件ceph.conf和ceph.client.admin.keyring */

mkdir -p /mnt/ceph_fuse
ceph-fuse /mnt/ceph_fuse
大功告成,在/mnt/ceph_fuse下读写数据,都是读写远程Ceph集群

            总结一下,Ceph的文件系统接口弥补了Ceph的块设备接口在共享性方面的不足,Ceph的文件系统接口符合POSIX标准,用户可以像使用本地存储目录一样使用Ceph的文件系统的挂载目录。还是不懂?这样理解吧,无需修改你的程序,就可以将程序的底层存储换成空间无限并可多处共享读写的Ceph集群文件系统。

Ceph的对象存储接口

            **首先,通过图4来看下对象存储接口是怎么用的?**

            简单了说,使用方式就是通过http协议上传下载删除对象(文件即对象)

            ![](https://s1.51cto.com/images/blog/201905/13/e19b64f2d7d067dcaa4fb2723d28f6ab.jpg?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=)

            问题来了,有了块设备接口存储和文件系统接口存储,为什么还整个对象存储呢?
            往简单了说,Ceph的块设备存储具有优异的存储性能但不具有共享性,而Ceph的文件系统具有共享性然而性能较块设备存储差,为什么不权衡一下存储性能和共享性,整个具有共享性而存储性能好于文件系统存储的存储呢,对象存储就这样出现了。

            **对象存储为什么性能会比文件系统好?**

            原因是多方面的,主要原因是对象存储组织数据的方式相对简单,只有bucket和对象两个层次(对象存储在bucket中),对对象的操作也相对简单。而文件系统存储具有复杂的数据组织方式,目录和文件层次可具有无限深度,对目录和文件的操作也复杂的多,因此文件系统存储在维护文件系统的结构数据时会更加繁杂,从而导致文件系统的存储性能偏低。

            存储空间(Bucket)所谓的桶

存储空间是您用于存储对象(Object)的容器,所有的对象都必须隶属于某个存储空间。您可以设置和修改存储空间属性用来控制地域、访问权限、生命周期等,这些属性设置直接作用于该存储空间内所有对象,因此您可以通过灵活创建不同的存储空间来完成不同的管理功能。

同一个存储空间的内部是扁平的,没有文件系统的目录等概念,所有的对象都直接隶属于其对应的存储空间。
每个用户可以拥有多个存储空间
存储空间的名称在 OSS 范围内必须是全局唯一的,一旦创建之后无法修改名称。
存储空间内部的对象数目没有限制。

存储空间的命名规范如下:
只能包括小写字母、数字和短横线(-)。
必须以小写字母或者数字开头和结尾。
长度必须在3-63字节之间

            **Ceph的对象存储接口怎么用呢?**

            Ceph的对象接口符合亚马逊S3接口标准和OpenStack的Swift接口标准,可以自行学习这两种接口。

总结一下,文件系统存储具有复杂的数据组织结构,能够提供给用户更加丰富的数据操作接口,而对象存储精简了数据组织结构,提供给用户有限的数据操作接口,以换取更好的存储性能。对象接口提供了REST API,非常适用于作为web应用的存储。

Ceph 优点

            1、统一存储

    虽然ceph底层是一个分布式文件系统,但由于在上层开发了支持对象和块的接口。所以在开源存储软件中,能够一统江湖。至于能不能千秋万代,就不知了。

  2、高扩展性
    扩容方便、容量大。能够管理上千台服务器、EB级的容量。

  3、可靠性强
    支持多份强一致性副本,EC。副本能够垮主机、机架、机房、数据中心存放。所以安全可靠。存储节点可以自管理、自动修复。无单点故障,容错性强。

  4、高性能
    因为是多个副本,因此在读写操作时候能够做到高度并行化。理论上,节点越多,整个集群的IOPS和吞吐量越高。另外一点ceph客户端读写数据直接与存储设备(osd) 交互。

Ceph应用场景

            Ceph可以提供对象存储、块设备存储和文件系统服务,其对象存储可以对接网盘(owncloud)应用业务等;其块设备存储可以对接(IaaS),当前主流的IaaS运平台软件,如:OpenStack、CloudStack、Zstack、Eucalyptus等以及kvm等。

ceph功能组件

            ![](https://s1.51cto.com/images/blog/201905/13/e2972edc0d22c73a2aa97562860f3c4a.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=)

Ceph各组件介绍

            OSD(Object Storage Device):** Ceph OSD 守护进程( Ceph OSD )的功能是存储数据,处理数据的复制、恢复、回填、再均衡,并通过检查其他OSD 守护进程的心跳来向 Ceph Monitors 提供一些监控信息。当 Ceph 存储集群设定为有2个副本时,至少需要2个 OSD 守护进程,集群才能达到 active+clean 状态( Ceph 默认有3个副本,但你可以调整副本数)。

Monitor: Ceph Monitor维护着展示集群状态的各种图表,包括监视器图、 OSD 图、归置组( PG )图、和 CRUSH 图。 Ceph 保存着发生在Monitors 、 OSD 和 PG上的每一次状态变更的历史信息(称为 epoch )。
MDS(Metadata Server):Ceph 元数据服务器( MDS )为 Ceph 文件系统存储元数据(也就是说,Ceph 块设备和 Ceph 对象存储不使用MDS )。元数据服务器使得 POSIX 文件系统的用户们,可以在不对 Ceph 存储集群造成负担的前提下,执行诸如 ls、find 等基本命令。

Ceph架构

            ![](https://s1.51cto.com/images/blog/201905/13/c53e41c7a4cec5de8b84d67229aad36d.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=)

            1)基础存储系统 RADOS

RADOS:可靠自主分布式对象存储。它是ceph存储的基础,保证一切都以对象形式存储。
2) 基础库LIBRADOS
LIBADOS:功能是对RADOS进行抽象和封装,并向上层提供API,以便直接基于RADOS进行应用开发。

随机阅读

Copyright © 2017 英语文化交流 All Rights Reserved.