5.1 Ceph概述

1 Ceph介绍

(1) 存储根据其类型，可分为块存储，对象存储和文件存储。在主流的分布式存储技术中，HDFS/GPFS/GFS属于文件存储，Swift属于对象存储，而
Ceph可支持块存储、对象存储和文件存储，故称为统一存储。
(2) Ceph是一个分布式存储系统，诞生于2004年，最早致力于开发下一代高性能分布式文件系统的项目。经过多年的发展之后，已得到众多云计算和
存储厂商的支持，成为应用最广泛的开源分布式存储平台。随着云计算的发展，ceph乘上了OpenStack的春风，进而成为了开源社区受关注较高的项目
之一。Ceph可以将多台服务器组成一个超大集群，把这些机器中的磁盘资源整合到一块儿，形成一个大的资源池（PB级别），然后按需分配给应用使用。
(3) Ceph根据场景可分为对象存储、块设备存储和文件存储。Ceph相比其它分布式存储技术，其优势点在于，它不单是存储，同时还充分利用了存储节
点上的计算能力，在存储每一个数据时，都会通过计算得出该数据存储的位置，尽量将数据分布均衡。同时，由于采用了CRUSH、HASH等算法，使得它不
存在传统的单点故障，且随着规模的扩大，性能并不会受到影响。

ceph图标:

2 Ceph架构

图示1: 图示2:

(1) Ceph的最底层是RADOS（分布式对象存储系统），它具有可靠、智能、分布式等特性，实现高可靠、高可拓展、高性能、高自动化等功能，并最终
存储用户数据。RADOS系统主要由两部分组成，分别是OSD和Monitor。
(2) RADOS之上是LIBRADOS，LIBRADOS是一个库，它允许应用程序通过访问该库来与RADOS系统进行交互，支持多种编程语言，比如C、C++、Python
等。
(3) 基于LIBRADOS层开发的有三种接口，分别是RADOSGW、librbd和MDS。
(4) RADOSGW是一套基于当前流行的RESTFUL协议的网关，支持对象存储，兼容S3和Swift。
(5) librbd提供分布式的块存储设备接口，支持块存储。
(6) MDS提供兼容POSIX的文件系统，支持文件存储。

3 Ceph的功能模块

图示1: 图示2:

Ceph的核心组件包括Client客户端、MON监控服务、MDS元数据服务、OSD存储服务，各组件功能如下:
(1) Client客户端
负责存储协议的接入，节点负载均衡。
(2) MON监控服务
负责监控整个集群，维护集群的健康状态，维护展示集群状态的各种图表，如OSD Map、Monitor Map、PG Map和CRUSH Map，我们将这些Map统称为
ClusterMap。
(3) MDS元数据服务
负责保存文件系统的元数据，管理目录结构，适用于CephFS文件存储。
(4) OSD存储服务
主要功能是存储数据、复制数据、平衡数据、恢复数据，以及与其它OSD间进行心跳检查等。一般情况下一块硬盘对应一个OSD。

4 Ceph的资源划分

Ceph资源划分示意图:

Ceph采用crush算法，在大规模集群下，实现数据的快速、准确存放，同时能够在硬件故障或扩展硬件设备时，做到尽可能小的数据迁移，其原理如下:
(1) 当用户要将数据存储到Ceph集群时，数据先被分割成多个object，(每个object一个object id，大小可设置，默认是4MB），object是Ceph存
储的最小存储单元。
(2) 由于object的数量很多，为了有效减少了Object到OSD的索引表、降低元数据的复杂度，使得写入和读取更加灵活，引入了pg(Placement Group
)，PG用来管理object，每个object通过Hash，映射到某个pg中，一个pg可以包含多个object。
(3) Pg再通过CRUSH计算，映射到osd中。如果是三副本的，则每个pg都会映射到三个osd，保证了数据的冗余。

5 Ceph的数据写入流程

(1) 数据通过负载均衡获得节点动态IP地址；
(2) 通过块、文件、对象协议将文件传输到节点上；
(3) 数据被分割成4M对象并取得对象ID；
(4) 对象ID通过HASH算法被分配到不同的PG；
(5) 不同的PG通过CRUSH算法被分配到不同的OSD

6 Ceph的特点

(1) Ceph优点
1) Ceph支持对象存储、块存储和文件存储服务，故称为统一存储。
2) 采用CRUSH算法，数据分布均衡，并行度高，不需要维护固定的元数据结构；
3) 数据具有强一致，确保所有副本写入完成才返回确认，适合读多写少场景；
4) 去中心化，MDS之间地位相同，无固定的中心节点。
​
(2) Ceph存在的一些缺点
1) 去中心化的分布式解决方案，需要提前做好规划设计，对技术团队的要求能力比较高。
2) Ceph扩容时，由于其数据分布均衡的特性，会导致整个存储系统性能的下降。
​
(3) Ceph相比于其他存储方案的优势
1) CRUSH算法
Crush算法是ceph的两大创新之一，简单来说，Ceph摒弃了传统的集中式存储元数据寻址的方案，转而使用CRUSH算法完成数据的寻址操作。CRUSH在一
致性哈希基础上很好的考虑了容灾域的隔离，能够实现各类负载的副本放置规则，例如跨机房、机架感知等。Crush算法有相当强大的扩展性，理论上支持
数千个存储节点。
2) 高可用
Ceph中的数据副本数量可以由管理员自行定义，并可以通过CRUSH算法指定副本的物理存储位置以分隔故障域，支持数据强一致性； Ceph可以忍受多种
故障场景并自动尝试并行修复；Ceph支持多份强一致性副本，副本能够垮主机、机架、机房、数据中心存放。所以安全可靠。Ceph存储节点可以自管理、
自动修复。无单点故障，容错性强。
3) 高性能
因为是多个副本，因此在读写操作时候能够做到高度并行化。理论上，节点越多，整个集群的IOPS和吞吐量越高。另外一点Ceph客户端读写数据直接与存
储设备(osd) 交互。在块存储和对象存储中无需元数据服务器。
4) 高扩展性
Ceph不同于Swift，客户端所有的读写操作都要经过代理节点。一旦集群并发量增大时，代理节点很容易成为单点瓶颈。Ceph本身并没有主控节点，扩展
起来比较容易，并且理论上，它的性能会随着磁盘数量的增加而线性增长。Ceph扩容方便、容量大。能够管理上千台服务器、EB级的容量。
5) 特性丰富
Ceph支持三种调用接口，分别是对象存储，块存储，文件系统挂载，三种方式可以一同使用。在国内一些公司的云环境中，通常会采用Ceph作openstack
的唯一后端存储来提升数据转发效率。Ceph是统一存储，虽然它底层是一个分布式文件系统，但由于在上层开发了支持对象和块的接口，所以在开源存储软
件中，优势很明显。
​
(4) 使用
Ceph提供3种存储方式分别是对象存储，块存储和文件系统，一般我们主要关心的还是块存储，推荐将虚拟机后端存储从SAN过渡到Ceph。Ceph 现在是云
计算、虚拟机部署的最火开源存储解决方案，据统计大概有20%的OpenStack部署存储用的都是Ceph的block storage。

7 Ceph之RADOS说明

(1) RADOS (Reliable, Autonomic Distributed Object Store) 是Ceph的核心之一，作为Ceph分布式文件系统的一个子项目，特别为Ceph
的需求设计，能够在动态变化和异质结构的存储设备机群之上提供一种稳定、可扩展、高性能的单一逻辑对象(Object)存储接口和能够实现节点的自适应
和自管理的存储系统。在传统分布式存储架构中，存储节点往往仅作为被动查询对象来使用，随着存储规模的增加，数据一致性的管理会出现很多问题。而
新型的存储架构倾向于将基本的块分配决策和安全保证等操作交给存储节点来做，然后通过提倡客户端和存储节点直接交互来简化数据布局并减小io瓶颈。
(2) RADOS就是这样一个可用于PB级规模数据存储集群的可伸缩的、可靠的对象存储服务。它包含两类节点：存储节点、管理节点。它通过利用存储设备
的智能性，将诸如一致性数据访问、冗余存储、错误检测、错误恢复分布到包含了上千存储节点的集群中，而不是仅仅依靠少数管理节点来处理。
(3) RADOS中的存储节点被称为OSD(object storage device)，它可以仅由很普通的组件来构成，只需要包含CPU、网卡、本地缓存和一个磁盘或
者RAID，并将传统的块存储方式替换成面向对象的存储。在PB级的存储规模下，存储系统一定是动态的，系统会随着新设备的部署和旧设备的淘汰而增长
或收缩，系统内的设备会持续地崩溃和恢复，大量的数据被创建或者删除。
(4) RADOS通过 cluster map 来实现这些，cluster map 会被复制到集群中的所有部分（存储节点、控制节点，甚至是客户端），并且通过怠惰地
传播小增量更新而更新。Cluster map 中存储了整个集群的数据的分布以及成员。通过在每个存储节点存储完整的 Cluster map，存储设备可以表现
的半自动化，通过peer-to-peer的方式（比如定义协议）来进行数据备份、更新，错误检测、数据迁移等等操作。这无疑减轻了占少数的monitor
cluster（管理节点组成的集群）的负担。
(5) 一个RADOS系统包含大量的OSD和很少的用于管理OSD集群成员的monitors。OSD的组成如简介所说。而monitor是一些独立的进程，以及少量的本
地存储，monitor之间通过一致性算法保证数据的一致性。

8 Ceph之Cluster Map

存储节点集群通过monitor集群操作cluster map来实现成员的管理。cluster map描述了哪些OSD被包含进存储集群以及所有数据在存储集群中的分布。cluster map不仅存储在monitor节点，它被复制到集群中的每一个存储节点，以及和集群交互的client。当因为一些原因，比如设备崩溃、数据
迁移等，cluster map的内容需要改变时，cluster map的版本号被增加，map的版本号可以使通信的双方确认自己的map是否是最新的，版本旧的一
方会先将map更新成对方的map，然后才会进行后续操作。

9 Ceph之Data Placement

(1) RADOS的存储层次
RADOS中基本的存储单位是对象，一般为2MB或4MB，当一个文件要存入RADOS时，首先会被切分成大小固定的对象（最后一个对象大小可能不同），然后
将对象分配到一个PG（Placement Group）中，然后PG会复制几份，会随机地派给不同的存储节点。当新的存储节点被加入集群，会在已有数据中随机
抽取一部分数据迁移到新节点。这种概率平衡的分布方式可以保证设备在潜在的高负载下正常工作。更重要的是，数据的分布过程仅需要做几次随机映射，
不需要大型的集中式分配表。
​
(2) 对于每个层次的详细说明
1) File
用户需要存储或者访问的文件。
2) Object
RADOS的基本存储单元。Object与上面提到的file的区别是，object的最大size由RADOS限定（通常为2MB或4MB），以便实现底层存储的组织管理。
因此，当上层应用向RADOS存入size很大的file时，需要将file切分成统一大小的一系列object（最后一个的大小可以不同）进行存储。
3) PG（Placement Group）
对object的存储进行组织和位置映射。具体而言，一个PG负责组织若干个object（可以为数千个甚至更多），但一个object只能被映射到一个PG中，
即，PG和object之间是“一对多”映射关系。同时，一个PG会被映射到n个OSD上，而每个OSD上都会承载大量的PG，即，PG和OSD之间是“多对多”映射关
系。在实践当中，n至少为3。一个OSD上的PG则可达到数百个。事实上，PG数量的设置牵扯到数据分布的均匀性问题。PG是一个逻辑概念，我们linux系
统中可以直接看到对象，但是无法直接看到PG。它在数据寻址时类似于数据库中的索引，PG的数量是固定的，不会随着OSD的增加或者删除而改变，每个
对象都会固定映射进一个PG中，所以当我们要寻找一个对象时，只需要先找到对象所属的PG，然后遍历这个PG就可以了，无需遍历所有对象。而且在数据
迁移时，也是以PG作为基本单位进行迁移，ceph不会直接操作对象。
4) OSD
即object storage device，前文已经详细介绍，此处不再展开。唯一需要说明的是，OSD的数量事实上也关系到系统的数据分布均匀性，因此其数量
不应太少。在实践当中，至少也应该是数十上百个的量级才有助于Ceph系统的设计发挥其应有的优势。
​
(3) 各层次之间的映射关系
1) file -> object
object的最大size是由RADOS配置的，当用户要存储一个file，需要将file切分成几个object。
2) object -> PG
每个object都会被映射到一个PG中，然后以PG为单位进行备份以及进一步映射到具体的OSD上。
3) PG -> OSD
根据用户设置的冗余存储的个数r，PG会最终存储到r个OSD上，这个映射是通过一种伪随机的映射算法 CRUSH 来实现的，这个算法的特点是可以进行配
置。第一个osd节点即为主节点，其余均为从节点。

10 Ceph集群维护

(1) 前面已经介绍了，由若干个monitor共同负责整个RADOS集群中所有OSD状态的发现与记录，并且共同形成cluster map的master版本，然后扩散
至全体OSD以及client。OSD使用Cluster map进行数据的维护，而client使用Cluster map进行数据的寻址。monitor并不主动轮询各个OSD的当前
状态。相反，OSD需要向monitor上报状态信息。常见的上报有两种情况，一是新的OSD被加入集群，二是某个OSD发现自身或者其他OSD发生异常。在收到
这些上报信息后，monitor将更新cluster map信息并加以扩散。
​
(2) Cluster map的实际内容包括
1) Epoch，即版本号
cluster map的epoch是一个单调递增序列。epoch越大，则cluster map版本越新。因此，持有不同版本cluster map的OSD或client可以简单地
通过比较epoch决定应该遵从谁手中的版本。而monitor手中必定有epoch最大、版本最新的cluster map。当任意两方在通信时发现彼此epoch值不
同时，将默认先将cluster map同步至高版本一方的状态，再进行后续操作。
2) 各个OSD的网络地址
3) 各个OSD的状态
OSD状态的描述分为两个维度，up或者down来表明OSD是否正常工作，in或者out来表明OSD是否在至少一个PG中。因此，对于任意一个OSD，共有四种如
下可能的状态:
A、up且in   # 说明该OSD正常运行，且已经承载至少一个PG的数据。这是一个OSD的标准工作状态。
B、up且out   # 说明该OSD正常运行，但并未承载任何PG，其中也没有数据。一个新的OSD刚刚被加入Ceph集群后，便会处于这一状态。而一个出现故
障的OSD被修复后，重新加入Ceph集群时，也是处于这一状态。
C、down且in  # 说明该OSD发生异常，但仍然承载着至少一个PG，其中仍然存储着数据。这种状态下的OSD刚刚被发现存在异常，可能仍能恢复正常，
也可能会彻底无法工作。
D、down且out # 说明该OSD已经彻底发生故障，且已经不再承载任何PG。
4) CRUSH算法配置参数
表明了Ceph集群的物理层级关系（cluster hierarchy），位置映射规则（placement rules）。
根据cluster map的定义可以看出，其版本变化通常只会由"3)"和"4)"两项信息的变化触发。而这两者相比，"3"发生变化的概率更高一些。
​
(3) 一个新的OSD上线后，首先根据配置信息与monitor通信。Monitor将其加入cluster map，并设置为up且out状态，再将最新版本的cluster map
发给这个新OSD。收到monitor发来的cluster map之后，这个新OSD计算出自己所承载的PG（为简化讨论，此处我们假定这个新的OSD开始只承载一个
PG），以及和自己承载同一个PG的其他OSD。然后，新OSD将与这些OSD取得联系。如果这个PG目前处于降级状态（即承载该PG的OSD个数少于正常值，如正
常应该是3个，此时只有2个或1个。这种情况通常是OSD故障所致），则其他OSD将把这个PG内的所有对象和元数据复制给新OSD。数据复制完成后，新OSD
被置为up且in状态。而cluster map内容也将据此更新。这事实上是一个自动化的failure recovery过程。当然，即便没有新的OSD加入，降级的PG也
将计算出其他OSD实现failure recovery。
​
(4) 如果该PG目前一切正常，则这个新OSD将替换掉现有OSD中的一个（PG内将重新选出Primary OSD），并承担其数据。在数据复制完成后，新OSD被
置为up且in状态，而被替换的OSD将退出该PG（但状态通常仍然为up且in，因为还要承载其他PG）。而cluster map内容也将据此更新。这事实上是一
个自动化的数据re-balancing过程。如果一个OSD发现和自己共同承载一个PG的另一个OSD无法联通，则会将这一情况上报monitor。此外，如果一个OSD
deamon发现自身工作状态异常，也将把异常情况主动上报给monitor。在上述情况下，monitor将把出现问题的OSD的状态设为down且in。如果超过某一
预订时间期限，该OSD仍然无法恢复正常，则其状态将被设置为down且out。反之，如果该OSD能够恢复正常，则其状态会恢复为up且in。在上述这些状态
变化发生之后，monitor都将更新cluster map并进行扩散。这事实上是自动化的failure detection过程。
​
(5) 对于一个RADOS集群而言，即便由数千个甚至更多OSD组成，cluster map的数据结构大小也并不惊人。同时，cluster map的状态更新并不会频繁
发生。即便如此，Ceph依然对cluster map信息的扩散机制进行了优化，以便减轻相关计算和通信压力，首先，cluster map信息是以增量形式扩散的。
如果任意一次通信的双方发现其epoch不一致，则版本更新的一方将把二者所拥有的cluster map的差异发送给另外一方。其次，cluster map信息是以
异步且lazy的形式扩散的。也即，monitor并不会在每一次cluster map版本更新后都将新版本广播至全体OSD，而是在有OSD向自己上报信息时，将更
新回复给对方。类似的，各个OSD也是在和其他OSD通信时，将更新发送给版本低于自己的对方。
​
(6) 基于上述机制，Ceph避免了由于cluster map版本更新而引起的广播风暴。这虽然是一种异步且lazy的机制，但对于一个由n个OSD组成的Ceph集
群，任何一次版本更新能够在O(log(n))时间复杂度内扩散到集群中的任何一个OSD上。
​
(7) 一个可能被问到的问题
既然这是一种异步和lazy的扩散机制，则在版本扩散过程中，系统必定出现各个OSD看到的cluster map不一致的情况，这是否会导致问题？答案是：不
会。事实上，如果一个client和它要访问的PG内部的各个OSD看到的cluster map状态一致，则访问操作就可以正确进行。而如果这个client或者PG中的
某个OSD和其他几方的cluster map不一致，则根据Ceph的机制设计，这几方将首先同步cluster map至最新状态，并进行必要的数据re-balancing操
作，然后即可继续正常访问。

11 Ceph基本进程说明

(1) Ceph主要有四个基本进程
1) OSD
用于集群中所有数据与对象的存储。处理集群数据的复制、恢复、回填、再均衡。并向其他osd守护进程发送心跳，然后向Mon提供一些监控信息。当Ceph
存储集群设定数据有两个副本时（一共存两份），则至少需要两个OSD守护进程即两个OSD节点，集群才能达到active+clean状态。
2) MDS(可选)
为Ceph文件系统提供元数据计算、缓存与同步。在ceph中，元数据也是存储在osd节点中的，mds类似于元数据的代理缓存服务器。MDS进程并不是必须的进程，只有需要使用CEPHFS时，才需要配置MDS节点。
3) Monitor
监控整个集群Cluster map的状态，维护集群的cluster MAP二进制表，保证集群数据的一致性。ClusterMAP描述了对象块存储的物理位置，以及一个
将设备聚合到物理位置的桶列表。
4) MGR
MGR是Ceph L版本新增加的组件，主要作用是分担和扩展monitor的部分功能，减轻monitor的负担。建议每台monitor节点都部署一个mgr，以实现相
同级别的高可用。
​
(2) 进程说明
1) OSD
通常来说，一块磁盘和该磁盘对应的守护进程称为一个OSD。守护进程的作用是从该磁盘读取和写入数据。该磁盘可以是一个硬盘或者SSD盘或者RAID，总
之是一个逻辑磁盘。如果一个节点只有一个守护进程和对应的磁盘，那么该OSD就成了一个节点。通常一个节点有多个OSD守护进程和多个磁盘，所以通常
来说OSD不是一个节点。
2) MDS(可选)
MDS是可选的，只有需要使用Ceph FS的时候才需要配置MDS节点。在Ceph中，元数据也是存放在OSD中的，MDS只相当于元数据的缓存服务器。
3) Monitor
Ceph要求必须是奇数个Monitor监控节点，一般建议至少是3个（如果是自己私下测试玩玩的话，可以是1个，但是生产环境绝不建议1个）用于维护和监
控整个集群的状态，每个Monitor都有一个Cluster Map，只要有这个Map，就能够清楚知道每个对象存储在什么位置了。客户端会先tcp连接Monitor，
从中获取Cluster Map，并在客户端进行计算，当知道对象的位置后，再直接与OSD通信（去中心化的思想）。OSD节点平常会向Monitor节点发送简单
心跳，只有当添加、删除或者出现异常状况时，才会自动上报信息给Monitor。
4) MGR
主要作用是分担和扩展monitor的部分功能，减轻monitor的负担。
​
(3) 数据一致性
在Ceph中，如果要写数据，只能向主OSD写，然后再由主OSD向从OSD同步地写，只有当从OSD返回结果给主OSD后，主OSD才会向客户端报告写入完成的
消息。如果要读数据，不会使用读写分离，而是也需要先向主OSD发请求，以保证数据的强一致性。

12 Ceph三种存储类型

(1) 块存储 (RBD)
1) 优点
通过Raid与LVM等手段，对数据提供了保护；多块廉价的硬盘组合起来，提高容量；多块磁盘组合出来的逻辑盘，存储速度较快
2) 缺点
采用SAN架构组网时，光纤交换机，造价成本高，不支持共享存储
3) 应用场景
docker容器、虚拟机磁盘存储分配；
4) 典型设备
硬盘、Raid
​
(2) 文件存储(CephFS)
1) 优点
支持共享存储
2) 缺点
需要经过操作系统处理再转为块存储，读写速率低，传输速率慢
3) 应用场景
文件共享，多台服务器共享使用同一个存储
4) 典型设备
FTP、NFS，其它有目录结构的文件存储
​
(3) 对象存储(Object 适合更新变动较少的数据)
1) 优点
具备块存储的读写性能和文件存储的共享特性
2) 缺点
操作系统不能直接访问，只能通过应用程序级别的API访问
3) 应用场景
图片存储，视频存储
4) 典型设备
阿里云OSS，腾讯云COS，aws云S3

13 小结

(1) Ceph核心概念
1) RADOS
全称Reliable Autonomic Distributed Object Store，即可靠的、自动化的、分布式对象存储系统。RADOS是Ceph集群的精华，用户实现数据
分配、Failover等集群操作。
2) Librados
Rados提供库，因为RADOS是协议很难直接访问，因此上层的RBD、RGW和CephFS都是通过librados访问的，目前提供PHP、Ruby、Java、Python、
C和C++支持。
3) Crush
Crush算法是Ceph的两大创新之一，通过Crush算法的寻址操作，Ceph得以摒弃了传统的集中式存储元数据寻址方案。而Crush算法在一致性哈希基础
上很好的考虑了容灾域的隔离，使得Ceph能够实现各类负载的副本放置规则，例如跨机房、机架感知等。同时，Crush算法有相当强大的扩展性，理论
上可以支持数千个存储节点，这为Ceph在大规模云环境中的应用提供了先天的便利。
4) Pool
Pool是存储对象的逻辑分区，它规定了数据冗余的类型和对应的副本分布策略，支持两种类型，副本（replicated）和 纠删码（ Erasure Code）。
5) PG
PG（placement group）是一个放置策略组，它是对象的集合，该集合里的所有对象都具有相同的放置策略，简单点说就是相同PG内的对象都会放到
相同的硬盘上，PG是ceph的逻辑概念，服务端数据均衡和恢复的最小粒度就是PG，一个PG包含多个OSD。引入PG这一层其实是为了更好的分配数据和
定位数据。
6) Object
简单来说块存储读写快，不利于共享，文件存储读写慢，利于共享。能否弄一个读写快，利于共享的出来呢。于是就有了对象存储。最底层的存储单元，包
含元数据和原始数据。
​
(2) Ceph核心组件
1) OSD
OSD是负责物理存储的进程，一般配置成和磁盘一 一对应，一块磁盘启动一个OSD进程。主要功能是存储数据、复制数据、平衡数据、恢复数据，以及与其
它OSD间进行心跳检查，负责响应客户端请求返回具体数据的进程等。
2) pool、object、PG、OSD之间的关系
一个Pool里有很多PG。
一个PG里包含一堆对象，一个对象只能属于一个PG。
PG有主从之分，一个PG分布在不同的OSD上(针对三副本类型)。
3) Monitor
一个Ceph集群需要多个Monitor组成的小集群，它们通过Paxos同步数据，用来保存OSD的元数据。负责坚实整个Ceph集群运行的Map视图（如OSD Map
、Monitor Map、PG Map和CRUSH Map），维护集群的健康状态，维护展示集群状态的各种图表，管理集群客户端认证与授权。
4) MDS
MDS全称Ceph Metadata Server，是CephFS服务依赖的元数据服务。负责保存文件系统的元数据，管理目录结构。对象存储和块设备存储不需要元数
据服务。
5) Mgr
ceph 官方开发了 ceph-mgr，主要目标实现 ceph 集群的管理，为外界提供统一的入口。例如cephmetrics、zabbix、calamari、promethus。
6) RGW
RGW全称RADOS gateway，是Ceph对外提供的对象存储服务，接口与S3和Swift兼容。
7) Admin
Ceph常用管理接口通常都是命令行工具，如rados、ceph、rbd等命令，另外Ceph还有可以有一个专用的管理节点，在此节点上面部署专用的管理工具
来实现近乎集群的一些管理工作，如集群部署，集群组件管理等。 

pool、object、pg、osd的关系图: