=============================== (接上文《架构设计:系统存储(29)——分布式文件系统 Ceph(管理)》)
此图来源于官网,很多网络上的资料也引用了这张图,但是并没有讲清楚出现在图中的和没有出现在图中的(但同样重要的)几个名词到底是什么含义,例如,RADOS、LIBRADOS、RADOSGW、RDB、CEPH FS、MON、OSD、MDS 等等。读者要搞清楚 Ceph 的顶层架构,就首先要搞清楚这些名词代表的技术意义,以及这些技术的在 Ceph 顶层架构中所占据的地位。
请看以下这张图对 Ceph 顶层架构抽象名词的功能细化:
是不是这样看就要亲切多了。实际上我们一直讲的 Ceph 分布式对象存储系统只是上图中的 RADOS 部分(Reliable Autonomic Distributed Object Store),其中就包括了 MON 和 OSD 两大角色。至于 MON 和 OSD 中又包括了什么,本文后续将进行介绍。
这里要特别说明以下,请注意上图中 MDS 角色所在位置。我们先来回想一下在前文介绍 Ceph 文件系统安装的时候,当我们还没有创建 MDS 角色时,查看 Ceph 的状态同样可以看到 "HEALTH_OK" 的提示信息,如下所示:
- [ceph@vmnode1~] $ sudo ceph - w cluster d05f71b6 - 0d52 - 4cde - a010 - 582f410eb84d health HEALTH_OK monmap e1: 3 mons at {......
- }
- election epoch 6,
- quorum 0,
- 1,
- 2 vmnode1,
- vmnode2,
- vmnode3 osdmap e13: 3 osds: 3 up,
- 3 in pgmap v19: 64 pgs,
- 1 pools,
- 0 bytes data,
- 0 objects 15458 MB used,
- 584 GB / 599 GB avail 64 active + clean
只是这时我们还看不到 mdsmap 的信息,也就是说 MDS 角色并不是 Ceph 文件系统 RADOS 核心部分的必备元素。实际上 MDS 角色是专门为 Ceph FS 子系统服务的角色,其上记录了元数据信息说明了 Ceph FS 子系统中文件目录、文件路径和 OSD PG 的对应关系。所以当我们创建 MDS 角色,并使用以下命令创建了 Ceph FS 文件系统后,才能看到 Ceph 文件系统上的 MDS 角色信息,如下所示:
- [ceph@vmnode1~] $ sudo ceph fs new cephfs cephfs_metadata cephfs_data new fs with metadata pool 2 and data pool 1[ceph@vmnode1~] $ sudo ceph mds stat e7: 1 / 1 / 1 up {
- 0 = vmnode2 = up: active
- },
- 2 up: standby[ceph@vmnode1~] $ sudo ceph - s cluster d05f71b6 - 0d52 - 4cde - a010 - 582f410eb84d health HEALTH_OK monmap e1: 3 mons at {......
- }
- election epoch 6,
- quorum 0,
- 1,
- 2 vmnode1,
- vmnode2,
- vmnode3 mdsmap e7: 1 / 1 / 1 up {
- 0 = vmnode2 = up: active
- },
- 2 up: standby osdmap e18: 3 osds: 3 up,
- 3 in pgmap v32: 128 pgs,
- 3 pools,
- 1962 bytes data,
- 20 objects 15459 MB used,
- 584 GB / 599 GB avail 128 active + clean client io 2484 B / s wr,
- 9 op / s
RADOS 之上有一个访问协议层,任何对分布式对象存储系统(RADOS)进行读写的各类型客户端,都需要通过这个访问协议层来完成操作。而这个访问协议层的具体体现就是编程语言库称为 LIBRADOS,如果您使用 Ceph-deploy 安装助理进行 Ceph 文件系统的部署的话,那么 LIBRADOS 在部署 RADOS 的同时就安装好了,默认是 C++ 版本的。您也可以独立安装其它版本的 LIBRADOS,例如 Python 版本或者 Java 版本。以下命令可以安装访问协议层对 Java 语言的支持库:
- yum install jna
- // 安装好以后相关的jar文件默认存放在/usr/share/java目录下
至此技术人员就可以使用 LIBRADOS 直接操作 RADOS 中的 MON、OSD 角色了。但问题是,这样的调用方式并不适用于各种类型的客户端,因为毕竟只是一套访问协议层的具体实现代码。为了便于需要使用 Ceph 文件系统的各种客户端,在各类情况下都能进行简便的操作,Ceph 官方还建立了多种子项目,产生了建立在 LIBRADOS 之上的多种访问方式。
CEPH FS 就是我们最熟悉的一个子项目,它的目的是基于 LIBRADOS,遵循 POSIX 规范提供给各种 Linux 操作系统将 Ceph 文件系统作为本地文件系统进行挂载使用的能力,同时也提供对 FUSE 的支持。在本专题之前的文章中,我们专门用整整一片文章的篇幅来介绍 Ceph FS 的挂载过程,请参见《架构设计:系统存储(28)——分布式文件系统 Ceph(挂载)》
RADOSGW 的全称是 RADOS Gateway,中文名 Ceph 对象网关。客户端可以通过它,使用 HTTP restful 形态的结构访问 RADOS。官网上对它的解释是:
RADOSGW is an HTTP REST gateway for the RADOS object store, a part of the Ceph distributed storage system. It is implemented as a FastCGI module using libfcgi, and can be used in conjunction with any FastCGI capable web server.
那么 RDB 又是什么呢?RDB 全称 RADOS Block Devices,初看名字就和块存储有一定关系。是的,这是基于 RADOS 建立的块存储软件设备。关于块存储的技术概念在本专题之前的文章中已经详细介绍过(可参见《架构设计:系统存储(1)——块存储方案(1)》),这里就不再进行赘述了。那么我们要回答的一个问题是,为什么需要把一个分布式对象存储系统通过 RDB 向上模拟成一个块存储设备呢?这是因为需要对诸如 KVM 这样的客户端访问提供支持。
举一个浅显易懂的例子,VMware 的虚拟机产品相信大家都用过,VMware 在创建一个虚拟机时需要设置这台虚拟机的 CPU 数量、内存数量等内容,而设置的存储设备时都必须是基于块存储技术的设备,例如一个物理磁盘分区、一个真实存在的光驱设备等。如果要让虚拟机能够使用 Ceph 文件系统,就必须在上层将 Ceph 文件系统模拟成一个块存储设备。实际上 Ceph 文件系统上层的 RDB 子项目,是 OpenStack 生态中能够集成 Ceph 文件系统的基本条件。Glance 或者 Cinder 本质上是将 Ceph 文件系统看成和 NAS 一样的块存储设备并将其集成进来。
关于 RADOS 上层的访问协议层功能,以及之上的各种子项目的介绍本文只是点到为止,相关的知识点就不再做扩展讲解了。既然 Ceph 分布对象存储系统中最重要的就是 RADOS 部分,那么我们还是要将介绍的重点收回来。
那么一个文件从请求进入 Ceph RADOS 到最终存储下来的过程过程中,到底发生了什么?这里我们直接通过原生命令操作 RADOS,来测试一下这个过程:
- [root@vmnode1~]# echo"yinwenjie ceph test info">file[root@vmnode1~]# rados put ceph-object1 ./file--pool=cephfs_data
我们直接通过 RADOS 进行操作,就可以避免 RADOS 上层各个子系统对我们分析问题造成的影响。首先第一条命令我们给一个名为 "file" 的文件取了一个对象名,对象名为 ceph-object1,并使用一个名叫 datapool 的 OSD Pool 保存这个对象。请注意这里有一个曾经解释过的概念,即 OSD Pool 是存在于多个 OSD 上 PG 块的集合,它是 Ceph 文件系统中存储对若干 Object 信息的管理单元。
在这个命令之下 RADOS 完成了几件事情:
- [root@vmnode1~]# rados -p cephfs_data ls......
- ceph-object1
- ......
其中 Total_number_of_OSD 表示目前 Ceph 文件系统中 OSD 角色的个数,max_replication_count 表示设置的最大副本数量,pool_count 表示计划设定的 Ceph 文件系统中的总的 pool 数量。举个例子来说,当 Ceph 文件系统中 OSD 角色的数量为 20、最大副本数量为 3、计划设定的 Pool 数量为 3 时,带入公式就可以得到 PG 数量应设定为 222。但是关于 PG 的设定还有一个建议,就是建议设定为 2 的 N 次方,那么离 222 最近的数值就是 256.Pool 中 PG 的数量是可以调整,但是 Ceph 文件系统只允许调大 PG 的数量,不允许调减——原因很简单,因为这些 PG 已经存储信息了。并且调整前,最好向 Ceph 文件系统中加入新的 OSD 角色,否则调整意义就不大。 那么 Ceph 文件系统是怎么确定和一个 Object 存放到哪个 PG 上的呢?首先 Ceph 知道 Pool 中总的 PG 数量,也知道当前 Object 的 oid 编号。那么这个问题使用一致性 Hash 算法就很好解决了——基于 Objec 的 oid 进行 Hash 计算。我们可以通过以下命令,查看某个 Object 所在的 PG 位置;
- Total PGs = ((Total_number_of_OSD * 100) / max_replication_count) / pool_count
- [root@vmnode1~]# ceph osd map cephfs_data ceph-object1osdmap e18 pool'cephfs_data' (1) object'ceph-object1' ->pg1.adfc9c54(1.14)->up ([1,2], p1) acting([1,2], p1)
- [root@vmnode1~]# ceph osd crush dump{"devices":[
- {"id": 0,"name": "osd.0"},
- ......
- ],"types":[
- ......
- {"type_id": 2,"name": "chassis"},
- {"type_id": 3,"name": "rack"},
- ......
- ],"buckets":[
- ......
- {"id":-2,"name": "vmnode1","type_id": 1,"type_name": "host","weight": 13107,"alg": "straw","hash": "rjenkins1","items":[
- {"id": 0,"weight": 13107,"pos": 0}
- ]
- },
- ......
- ],"rules":[
- {"rule_id": 0,"rule_name": "replicated_ruleset","ruleset": 0,"type": 1,"min_size": 1,"max_size": 10,"steps":[
- {"op": "take","item":-1,"item_name": "default"},
- ......
- ]
- }
- ],"tunables":{"choose_local_tries": 0,"choose_local_fallback_tries": 0,
- ......."has_v2_rules": 0,"has_v3_rules": 0,"has_v4_buckets": 0}
- }
===================== (接下文)
来源: http://blog.csdn.net/yinwenjie/article/details/70379479