CEPH存储介绍

一： 概要

ceph是一个开源项目，他是软件定义、统一的存储解决方案

ceph是一个可大规模扩展、高性能并且无单点故障的分布式存储系统

从一开始他就运行在通用的商用硬件上，具有高度的可伸缩性，容量可扩展至EB级别，甚至更大

备注：

1KB (Kilobyte 千字节)=1024B，
1MB (Megabyte 兆字节 简称“兆”)=1024KB，
1GB (Gigabyte 吉字节 又称“千兆”)=1024MB，
1TB (Trillionbyte 万亿字节 太字节)=1024GB，其中1024=2^10 ( 2 的10次方)，
1PB（Petabyte 千万亿字节 拍字节）=1024TB，
1EB（Exabyte 百亿亿字节 艾字节）=1024PB，
1ZB (Zettabyte 十万亿亿字节 泽字节)= 1024 EB,
1YB (Jottabyte 一亿亿亿字节 尧字节)= 1024 ZB,
1BB (Brontobyte 一千亿亿亿字节)= 1024 YB

CEPH应为开放、可扩展、分布式的本质在存储领域名声鹊起

如今公有云、私有云乃至混合云是提供大规模基础设施的主流方案

ceph的架构设计之初就包含如下特性：

• 所有的组件必须可以扩展
• 不能存在单点故障点
• 解决方案必须是软件定义的、开源的并且可以适配
• ceph软件应该可以运行在通用商用的硬件之上
• 所有的组件必须可以自我管理

ceph为企业提供了基础的性能，无限的扩展性，强大的并且灵活的存储产品

ceph官方网站：https://ceph.io/

产品学习网站：https://docs.ceph.org.cn/start/intro

[ceph]
name=Ceph packages for $basearch
baseurl=https://download.ceph.com/rpm-{ceph-release}/{distro}/$basearch
enabled=1
priority=2
gpgcheck=1
gpgkey=https://download.ceph.com/keys/release.asc

[ceph-noarch]
name=Ceph noarch packages
baseurl=https://download.ceph.com/rpm-{ceph-release}/{distro}/noarch
enabled=1
priority=2
gpgcheck=1
gpgkey=https://download.ceph.com/keys/release.asc

[ceph-source]
name=Ceph source packages
baseurl=https://download.ceph.com/rpm-{ceph-release}/{distro}/SRPMS
enabled=0
priority=2
gpgcheck=1
gpgkey=https://download.ceph.com/keys/release.asc  

二：ceph的历史和发展

• 2003年：

  ceph是圣克鲁兹加利福尼亚大学的sage weil在2003年开发的，也是他的博士学位项目的一部分

  初始的项目原型是大约4万行的C++代码的ceph文件系统

• 2006年：

  于2006年作为参考实现和研究平台遵循LGPL协议（Lesser GUN Public License）开源。

  美国劳伦斯利物莫国家实验室（Lawrence Livermore National Laboratory）资助了Sage的初始研究工作

• 2003-2007年：

​ 是CEPH的研究开发时期；在这期间，他的核心组件逐步形成，并且社区对项目的贡献也已经开始逐渐变大

​ ceph没有采用双重许可模式，也就不存在只针对企业版的特性

• 2007年年末：

​ ceph已经越来越成熟，并开始等待孵化

​ 此时，dreamhost（洛杉矶的一个虚拟主机和域名注册公司）参与进来

• 2007年到2011年：

​ 对ceph进行孵化

​ 在这期间ceph逐渐成形，已有的组件变得更加稳定，可靠；各种新特性也已经实现，未来的路线图也已设计好

​ 至此，ceph真正开始进入企业选择意向和路线图

​ 在这期间，多个有名的开发者开始参与到ceph项目中，他们中包括yehuda sadeh、weinraub、gregory farnum 、josh durgin、samuel just 、wido den hollander和lo

ceph这个词是宠物章鱼的一个常见绰号

ceph可以靠左cephalopod的缩写，他属于海洋软体类动物家族

ceph以章鱼作为自己的吉祥物，表达了ceph跟章鱼一样的并行行为

inktank这个词与章鱼有一定关系，渔民有时候也把章鱼称为墨鱼，因为他们可以喷涂墨汁，这就解释了为什么章鱼（ceph）跟墨鱼（inktank）有一定关系

同样，ceph和inktank有很多共同点，你可以认为inktank就是ceph的智库

sage weil是dreamhost的联合创始人之一

2007年年末ceph项目启动时，他最先由dreamhost孵化

2008年5月7日，sage发布了ceph 0.2版本，之后开发进展逐渐加快

版本发布时间间隔缩短并且现在每隔一个月都会有新版本的更新。

2012年7月3日，sage宣布到目前为止最重要的一个版本Argonaut（0.48版本）发布

下面列出了ceph发布的主要版本，包括long term support （LTS）版本。

更多的信息请访问https://ceph.com/category/releases/

• 各个版本发布的时间如下：

版本名	时间
Nautilus	2019年3月（v14.2.0 Nautilus released changelog）
mimic	2018年5月
Luminous	2017年10月
Kraken	2017年10月（引入bluestore）
Jewel	2016年4月
Infernalis（Stable November）	2015 - June 2016
Hammer（LTS April）	2015 - November 2016
Giant（Stable October）	2014 - April 2015
Firefly（0.80版本(LTS））	2014年5月
Emperor（0.72版本）	2013年11月9日
Dumpling（0.67版本(LTS））	2013年8月14日
Cuttlefish（0.61版本）	2013年5月7日
Bobtail（0.56版本(LTS)）	2013年1月1日
Argonaut（0.48版本(LTS)）	2012年6月3日

备注：

服务器装系统的三种方式

• USB装系统
• I2000、IPMI口，PXE装系统，又可以装系统，又可以发布业务
• IPMI口，WEB页面装系统

三：CEPH的优缺点

ceph起源于2004年sage 的博士论文，最早致力于开发下一代高性能分布式文件系统的项目，现在也成为了开源社区众人皆知的明星项目

特别是随着云计算的发展，ceph搭上了openstack的春风，受到各大厂商的认可，intel、dreamhost、SanDisk、cisco、yahoo等公司都或多或少的参与其中

redhat更是一掷千金，直接以1.75亿美金将sage创建的inktank公司及其ceph团队收入囊中，将其作为iaas三大组件计算、网络、存储之一

在这一期间的发展过程中，ceph似乎越来越向着云计算的方向靠拢，最先的cephfs文件系统已不再是开发重点，甚至开发已经陷入了停滞状态

而与虚拟化相关的RBD、RGW则成了开发重点，成为发展最快的模块

但是从代码中仍然能够开到各种痕迹，似乎在告诉后来人这段绕了一个大弯的历史

3.1 优势

3.1.1 crush算法

• 摒弃了传统的集中式存储元数据寻址的方案，采用CRUSH算法，数据分布均衡，并行度高。

• 考虑了容灾域的隔离，能够实现各类负载的副本放置规则，例如跨机房、机架感知等。

• 能够支持上千个存储节点的规模，支持TB到PB级的数据。

crush算法是ceph最初的两大创新之一（另一个是基于动态子树分区的元数据集群），也是整个RADOS（ceph集群）的基石，是ceph最引以为豪的地方

crush在一致性哈希基础上很好的考虑了容灾域的隔离，能够实现各类负载的副本放置规则，例如跨机房、机架感知等。

同时，crush算法支持副本和EC两种数据冗余方式，还提供了四种不同类型的bucket（存储空间）（uniform，list，tree，straw），充分考虑了实际生产过程中硬件的迭代式部署方式，虽然实际生产中大多数情况下的都只用了一种straw

另外根据sage的论文，crush算法具有相当好的可扩展性，在数千OSD的情况下仍然能保证良好的负载平衡

但这更多是理论层面的，目前还没有人给出在数PB规模的生产环境中的测试结果

总的来看，crush算法仍然是目前经过实践检验的最好的数据分布算法之一

3.1.2 统一存储架构

• 副本数可以灵活控制。

• 支持故障域分隔，数据强一致性。

• 多种故障场景自动进行修复自愈。

• 没有单点故障，自动管理。

• 去中心化。

• 扩 展灵活。

• 随着节点增加而线性增长。

ceph最初设计的RADOS是为其实现一个高性能的文件系统服务，并未有考虑对于块设备、对象存储的支持，也就没有什么RBD、RADOS Gateway，更别提openstack和qemu之类的了

但谁想无心插柳柳成荫，由于RADOS出色的设计和独立简洁的访问接口，再加上sage敏锐的眼光，ceph社区果断推出了用于支持云计算的分布式块存储RBD和分布式对象储存RADOS gateway，并将开发中心全面转向云计算领域

不得不说，raods的设计还是非常的优秀。从架构上看，RBD和 RADOS Gateway实际上都只是rados的客户端而已，但得益于rados的优秀设计，RBD和RADOS Gateway的设计和实现都很简单，不需要考虑横向扩展、冗余、容灾、负载平衡的等复杂的分布式系统问题，同时能够提供足够多的特性和足够优秀的性能，因此迅速得到了社区的认可

另一方面，ceph为openstack提供了良好的支持，成为了目前最火的openstack底层存储系统

3.1.3 丰富的特性

• 支持三种存储接口：块存储、文件存储、对象存储。

• 支持自定义接口，支持多种语言驱动。

ceph的特性不可谓不多，从分布式系统最基本的横向扩展、动态伸缩、冗余容灾、负载平衡等，到生产环境中非常实用的滚动升级、多存储池、延迟删除等，再到高大上的cephFS集群、快照、纠删码、跨存储池缓存等，不额可谓不强大

但就像大多数开源系统一样，ceph的基本特性，或者说真正在生产环境中用得上的特性还是非常靠谱的，但其他高级特性就只能打一个问号了

特别是在ceph模块，由于ceph社区目前的开发重点主要还是与云计算相关的部分，即RBD和RADOS Gateaway，导致cephFS的开发停滞了很久，相关的特性，例如元数据集群、快照等，目前都不满足生产环境的要求

3.2 缺点

3.2.1 代码质量

代码质量的问题，实际上是个见仁见智的问题

ceph主要使用C/C++语言编写，同时外围的很多脚本和工具用了Python。之所以要说明ceph的语言构成，是因为代码质量实际上是和语言有密切的关系

不否认用C++也能写出优雅的代码，但相比于更加“现代”的语言，要想写入具备同样可读性、结构良好、条理清晰代码，C++要困难很多

但是，由于存储作为底层系统，对效率的追求是无止境的，因此不太可能舍弃对于内存等底层系统资源的控制，而使用java/python这类的语言；而作为一个开源项目，期望所有的贡献者都是C++的高手，未免有些强人所难，这似乎成了一个死结

另一方面，Ceph广泛使用了STL，在部分核心代码中还使用了BOOST，这两者在底层核心系统代码中的可用性也一直存在争议，这更加结局了代码质量的挑战性

最关键的是，ceph似已经背负了太多的历史包袱，比如最核心的OSD模块，最初的设计包含OSD和PG类，其中PG类负责PG的通用逻辑，OSD负责管理所有的PG（placement group ，一个PG就是一组对象的集合）。然后PG的子类Peplicated PG实现了一副本作为冗余模式的PG。这里就存在了两个半类：OSD、PG及其子类ReplicatedPG，这两个半类实现了OSD模块99%的逻辑，可以想象这两个半类会有多大

在目前的master分支上，相关文件的大小分别是

OSD.h+OSD.cc = 2383行+8604行 = 10987行

PG.h+PG.cc = 2256行+7611行 = 9867行

ReplicatedPG.h+ReplicatedPG.cc = 1487行+12665行 = 14152行

需要特别注意的是，从C++继承的角度上，理解一个类，必须理解他的父类，也就是说，如果你想理解ReplicatedPG，理论上你必须同时理解PG，也就是说，要同时理解20000+行代码！

更加丧心病狂的是，这两个半类之间存在密切而复杂的调用关系，相互之间直接使用整个类，而没有什么实际上的接口隔离。严重加剧了理解代码的难度。

在EC功能以一种奇葩的方式加入到osd中之后，整个场面更加混乱。按照最初的设计，实现EC应该增加PG的一个子类，类似ErasureCodePG。但是由于ReplicatedPG包含了太多通用的代码，实际上已经和PG合二为一了，所以EC只能在ReplicatedPG的基础上改造。于是又出现了PGBackend的概念和相关的实现，这只能说是挑战人脑的极限了。

Ceph社区也曾试着梳理代码，比如添加OSDService类，作为PG与OSD通讯的接口。这样所有的PG全部调用OSDService而非OSD，相当于做了OSD与PG之间的隔离。但是似乎并没有起到足够的效果，现在已经名存实亡了。

Ceph在这样的代码质量下，还能向前走多久，委实是一件令人担忧的事情。

3.2.2 性能

Ceph性能总的来说还是不错的，基本上能发挥出物理硬件的性能，但是存在以下几个隐患：

1 数据双倍写入

Ceph本地存储接口（FileStore）为了支持事务，引入了日志（Journal）机制。所有的写入操作都需要先写入日志（XFS模式下），然后再写入本地文件系统。简单来说就是一份数据需要写两遍，日志+本地文件系统。这就造成了在大规模连续IO的情况下，实际上磁盘输出的吞吐量只有其物理性能的一半。

2 IO路径过长

这个问题在Ceph的客户端和服务器端都存在。以osd为例，一个IO需要经过message、OSD、FileJournal、FileStore多个模块才能完成，每个模块之间都涉及到队列和线程切换，部分模块在对IO进行处理时还要进行内存拷贝，导致整体性能不高。

3 对高性能硬件的支持有待改进

Ceph最开始是为HDD设计的，没有充分考虑全SSD，甚至更先进的PCIe SSD和NVRAM的情况NVRAM。导致这些硬件的物理性能在Ceph中无法充分发挥出来，特别是延迟和IOPS，受比较大的影响。

3.2.3 CephFS

CephFS现在在整个Ceph系统中处于一个较为尴尬的情况，因为POSIX这种接口似乎在云计算中没有用武之地，导致了社区对这个模块的关注不足，也就没有什么进展。

CephFS作为最初Ceph的设计目标，Sage投入了巨大的精力，几乎实现了所有需要的特性，并且进行了大量工程层面的优化。

正所谓成也萧何败萧何，Ceph想把CephFS模块做到足够强大，甚至是最强大，但强大的同时也意味着不菲的代价。元数据动态子树分区、目录分片、快照、权限控制、IOPS优化、故障恢复、分布式缓存、强弱一致性控制，这些高大上的名词背后都意味着复杂的工程性任务，更不要说将这些叠加在一起。很多时候，叠加不是想加，而是相乘的关系。最终的结果就是整个MDS的工程难度已经超过了可以掌控的程度，无法做出足够成熟、稳定的系统。

目前CephFS宣称其单MDS的模式是稳定的，MDS的集群的模式是不稳定的。而快照功能默认关闭，今后也够呛会有开启的可能了。

3.2.4 业务连续性

Ceph中的RADOS采用强一致性设计，即Write-All-Read-One，这种模式的好处在于读取效率较高，而且工程难度较低，比较适合与读多写少的系统。

Write-All-Read-One的特点：

必须等待所有的副本全部写入完毕才算是写入成功，这实际上对系统硬件的可靠性要求较高，因为如果在写入过程中存在任意硬件故障，则写入过程都要受影响。通常表现为卡顿，一般在数秒级别，时间长短和判断故障的机制以及故障恢复过程中IO的处理策略相关。

但是当集群非常非常大时，Write-All-Read-One对于硬件可靠性的要求几乎是无法满足的。想象一下一个10PB的系统，按照最大4TB每块盘的计算，就有2500块磁盘。按照我们以往的运维经验，每周存在一块磁盘故障是完全正常的。这种场景下，如果数据分布足够分散，实际上一块磁盘可能涉及到很多数据块，也就是说一块磁盘故障会影响很多IO，而这种情况每周发生一次。这对业务连续性的影响是已经是不可忽略的。

生产环境中的场景比这个更加复杂，因为磁盘或者硬件的故障可能不仅表现为不可写，还有可能是慢或者不稳定。这些情况对于业务连续性的影响也更加严重。

3.2.5 社区

Ceph社区现在已经有很多厂商实际上或者号称参入进来，其中不乏Intel、Dreamhost、SanDisk这样的大厂，也不乏UnitedStack这样的Start-Up公司，还有电信、大学、研究所这类非存储领域的公司或单位。

但实际上整个Ceph还是掌握在Inktank或者说RedHat的手中，绝大多数核心代码由他们贡献，也是他们Review和Merge。总的来说还是一个集权组织。

更加重要的是，Ceph相比OpenStack这种成熟完善的开源社区，缺乏足够的基础设施，例如成熟的单元测试、集成测试、测试环境、Reivew流程、贡献指引、代码规范等。导致整个社区仍然是人治、而非法制的过程，代码和系统的发展方向本质是由RedHat公司控制的。

对于以上这些问题，Ceph社区也非常清楚，并且正在或者将要改进。例如为了增加了对于SSD的支持，改进数据双倍写入问题以及更完善的社区建设和基础设施等。这些都增加了人们对Ceph的信心。

总的来说，Ceph瑕不掩瑜，仍然是一个优秀，甚至出色的开源存储系统。如果说分布式存储在云计算时代是风口上的猪，那么Ceph也是一直优秀的猪。未来是什么样子，我们拭目以待。

四：ceph存储架构

分布式存储是相对于集中式存储来说的，在介绍分布式存储之前，我们先看看什么是集中式存储。

4.1 集中式存储架构

以前，企业级的存储设备都是集中式存储。所谓集中式存储，从概念上可以看出来是具有集中性的，也就是整个存储是集中在一个系统中的。但集中式存储并不是一个单独的设备，是集中在一套系统当中的多个设备。整个存储系统可能需要几个机柜来存放.

在这个存储系统中包含很多组件，除了核心的

机头（控制器）、

磁盘阵列（JBOD）

交换机

等设备外，还有管理设备等辅助设备。如图2是一个集中式存储的基本逻辑示意图。

机头（控制器）：

在集中式存储中通常包含一个机头，这个是存储系统中最为核心的部件。通常在机头中有包含两个控制器，这两个控制器实现互备的作用，避免硬件故障导致整个存储系统的不可用。在该机头中通常包含前端端口和后端端口，前端端口用户为服务器提供存储服务，而后端端口用于扩充存储系统的容量。通过后端端口机头可以连接更多的存储设备，从而形成一个非常大的存储资源池。

机头中是整个存储系统的核心部件，整个存储系统的高级功能都在其中实现。控制器中的软件实现对磁盘的管理，将磁盘抽象化为存储资源池，然后划分为LUN提供给服务器使用。

这里的LUN其实就是在服务器上看到的磁盘。当然，一些集中式存储本身也是文件服务器，可以为服务器提供共享文件服务。无论如何，从上面我们可以看出集中式存储最大的特点是有一个统一的入口，所有数据都要经过这个入口，这个入口就是存储系统的机头。

分布式存储是一个大的概念，其包含的种类繁多，除了传统意义上的分布式文件系统、分布式块存储和分布式对象存储外，还包括分布式数据库和分布式缓存等。本文局限在分布式文件系统等传统意义上的存储架构，对于数据库等不做介绍。

4.2 中间控制节点架构（HDFS）

分布式存储最早是由谷歌提出的，其目的是通过廉价的服务器来提供使用与大规模，高并发场景下的Web访问问题。如图3是谷歌分布式存储（HDFS）的简化的模型。

4.2.1 在该系统的整个架构中将服务器分为两种类型

一种名为namenode，这种类型的节点负责管理管理数据（元数据）

一种名为datanode，这种类型的服务器负责实际数据的管理。

4.2.2 工作流程

上图分布式存储中，如果客户端需要从某个文件读取数据

• 首先从namenode获取该文件的位置（具体在哪个datanode）
• 然后从该位置获取具体的数据

在该架构中namenode通常是主备部署，而datanode则是由大量节点构成一个集群。

由于元数据的访问频度和访问量相对数据都要小很多，因此namenode通常不会成为性能瓶颈，而datanode集群可以分散客户端的请求。

因此，通过这种分布式存储架构可以通过横向扩展datanode的数量来增加承载能力，也即实现了动态横向扩展的能力。

4.3 完全无中心架构—一致性哈希（Swift）

与Ceph的通过计算方式获得数据位置的方式不同，另外一种方式是通过一致性哈希方式获得数据位置。

一致性哈希的方式就是将设备做成一个哈希环，然后根据数据名称计算出的哈希值映射到哈希环的某个位置，从而实现数据定位。

工作原理

上图一致性哈希的基本原理，为了绘制简单，以一个服务器上的一个磁盘为例进行介绍。

为了保证数据分配的均匀性及出现设备故障时数据迁移的均匀性，一致性哈希将磁盘划分为比较多的虚拟分区，每个虚拟分区是哈希环上的一个节点。

整个环是一个从0到32位最大值的一个区间，并且首尾相接。

当计算出数据（或者数据名称）的哈希值后，必然落到哈希环的某个区间

然后以顺时针，必然能够找到一个节点。那么，这个节点就是存储数据的位置。

Swift存储的整个数据定位算法就是基于上述一致性哈希实现

在Swift对象存储中，通过账户名/容器名/对象名三个名称组成一个位置的标识，通过该唯一标识可以计算出一个整型数来。

而在存储设备方面，Swift构建一个虚拟分区表，表的大小在创建集群是确定（通常为几十万），这个表其实就是一个数组。

这样，根据上面计算的整数值，以及这个数组，通过一致性哈希算法就可以确定该整数在数组的位置。而数组中的每项内容是数据3个副本（也可以是其它副本数量）的设备信息（包含服务器和磁盘等信息）。也就是经过上述计算，可以确定一个数据存储的具体位置。这样，Swift可以将请求重新定向到该设备进行处理。

​ 上述计算过程是在一个名为Proxy的服务中进行的，该服务可以集群化部署。因此可以分摊请求的负载，不会成为性能瓶颈

4.4 完全无中心架构—计算模式（Ceph）

下图是Ceph存储系统的架构，在该架构中与HDFS不同的地方在于该架构中没有中心节点。客户端是通过一个设备映射关系计算出来其写入数据的位置，这样客户端可以直接与存储节点通信，从而避免中心节点的性能瓶颈。

在Ceph存储系统架构中核心组件有Mon服务、OSD服务和MDS服务等。

对于块存储类型只需要Mon服务、OSD服务和客户端的软件即可。

其中Mon服务用于维护存储系统的硬件逻辑关系，主要是服务器和硬盘等在线信息。

Mon服务通过集群的方式保证其服务的可用性。

OSD服务用于实现对磁盘的管理，实现真正的数据读写，通常一个磁盘对应一个OSD服务。

客户端访问存储的大致流程

• 客户端在启动后会首先从Mon服务拉取存储资源布局信息

• 根据该布局信息和写入数据的名称等信息计算出期望数据的位置（包含具体的物理服务器信息和磁盘信息）

• 与该位置信息直接通信，读取或者写入数据。

五：ceph基础架构

5.1 简述

ceph 是一种开源存储软件。底层实现了对象存储，并以此为基础

对外提供对象存储接口、块存储接口、文件级存储接口。

• Object：有原生的API，而且也兼容Swift和S3的API。

• Block：支持精简配置、快照、克隆。

• File：Posix接口，支持快照，不过默认关闭

5.2 环境

CEPH版本：Nautilus

5.3 架构图

官方架构图

地址链接：https://docs.ceph.com/docs/master/architecture/

简化版

RADOS：Reliable Autonomic Distributed Object Store（可靠的，自主的，分布式的对象存储）。在 ceph 中这个名词经常出现，有时会以 R 表示 RADOS。实际上这个词仅仅是对 ceph 的一个修饰词，并不代表 ceph 的组件什么的。简单的理解， RADOS = ceph 对象存储集群 即可。

RGW、RBD、CEPH FS： 这三个就是 ceph clients访问RADOS的方式
RGW：对象存储网关，也就是对象存储接口。
RBD：块设备，也就是块存储接口。
CEPH FS：ceph 文件系统，也就是文件级存储接口。

5.4 ceph基础架构

CEPH组件主要分分为两部分：

Ceph Node:构成Ceph集群的基础组件

Ceph Client:对外提供多种方式使用Ceph存储的组件

5.5 ceph基础组件

此部分介绍构成Ceph集群的基础组件，其中包含OSD、Manager、MSD、Monitor

OSD（ceph-osd）

object storage daemon，对象存储进程。ceph 管理物理硬盘时，引入了OSD概念，每一块盘都会针对的运行一个OSD进程。换句话说，ceph 集群通过管理 OSD 来管理物理硬盘。OSD 一般功能为：存储数据、维护数据副本、数据恢复、数据再平衡以及对ceph monitor组件提供相关监控信息.

也就是负责响应客户端请求返回具体数据的进程。一个Ceph集群一般都有很多个OSD。

Manager（ceph-mgr）

用于收集ceph集群状态、运行指标，比如存储利用率、当前性能指标和系统负载。对外提供 ceph dashboard（ceph ui）和 resetful api。Manager组件开启高可用时，至少2个。

MDS（ceph-mds）

Ceph Metadata Server，元数据服务。为ceph 文件系统（cephFS）提供元数据服务（ceph 对象存储和块存储不需要MDS）。为 posix 文件系统用户提供性能良好的基础命令（ls，find等）。

Monitor（ceph-mon）

一个Ceph集群需要多个Monitor组成的小集群，它们通过Paxos同步数据，用来保存OSD的元数据。

维护集群的状态，包含monitor组件信息，manger 组件信息，osd组件信息，mds组件信息，crush 算法信息。还负责ceph集群的身份验证功能，client在连接ceph集群时通过此组件进行验证。Monitor组件开启高可用时，至少3个。

Object

Ceph最底层的存储单元是Object对象，每个Object包含元数据和原始数据。

PG

PG全称Placement Grouops，是一个逻辑的概念，一个PG包含多个OSD。引入PG这一层其实是为了更好的分配数据和定位数据。

RADOS

RADOS全称Reliable Autonomic Distributed Object Store，是Ceph集群的精华，用户实现数据分配、Failover等集群操作。

Libradio

Librados是Rados提供库，因为RADOS是协议很难直接访问，因此上层的RBD、RGW和CephFS都是通过librados访问的，目前提供PHP、Ruby、Java、Python、C和C++支持。

CRUSH

CRUSH是Ceph使用的数据分布算法，类似一致性哈希，让数据分配到预期的地方。

RBD

RBD全称RADOS block device，是Ceph对外提供的块设备服务。

RGW

RGW全称RADOS gateway，是Ceph对外提供的对象存储服务，接口与S3和Swift兼容。

CephFS

CephFS全称Ceph File System，是Ceph对外提供的文件系统服务。

5.6 Ceph Clients

此部分介绍 ceph 对外提供各种功能的组件。其中包含：Block Device、Object Storage、Filesystem。

• Block Device：块存储设备，RBD。

• Object Storage： 对象存储，RGW。对外可提供 swift 、s3 接口类型restful api

• Filesystem：文件系统，CephFS。提供一个兼容POSIX的文件系统。

5.7 ceph存储过程

前面介绍Ceph的一些组件及对外提供的功能，这部分主要介绍Ceph的逻辑存储，这部分主要介绍Ceph的存储逻辑。在对象存储中，一切都是扁平化的，并且存储的最小单元为对象（OBJ）

ceph 在对象存储的基础上提供了更加高级的思想。当对象数量达到了百万级以上，原生的对象存储在索引对象时消耗的性能非常大。ceph因此引入了 placement group （pg）的概念。一个PG就是一组对象的集合。

obj和pg之间的映射由ceph client计算得出。

讨论 pg 时，不得不提的另外一个名词：pgp。pgp决定了pg和osd 之间的映射关系。一般将 pgp_num 设置成和 pg_num 一样大小。这里还有一个名词需要提一下，在ceph中会经常见到crush算法。简单来说，crush 算法就是指 ceph 中数据如何存储、读取的过程。由于ceph集群面对许多的独立项目，因此ceph还引入了ceph pool的概念用于划分不同的项目。
ceph pool 是对 ceph 对象的逻辑划分，并不是物理划分。

pg和ceph pool的区别：

• pg对于用户来说是透明的，只是底层的一种优化方案。

• ceph pool对于用户来说，就像mysql中的database。

像大多数集群软件一样，ceph 也提供了缓存的概念。称之为 Cache Tier（缓存层，在具体使用时有时会称之为缓存池）。缓存池对用户来说是透明的，因此不会改变用户的原有使用逻辑。

以下缓存池的介绍，均为底层逻辑。在没有缓存池时，ceph client 直接指向存储池。在添加缓存池后，ceph client 指向缓存池，缓存池再指向存储池。

5.8 三种存储类型

5.8.1 块存储rbd

典型设备：

磁盘阵列，硬盘

主要是将裸磁盘空间映射给主机使用的。

优点：

通过Raid与LVM等手段，对数据提供了保护。

多块廉价的硬盘组合起来，提高容量。

多块磁盘组合出来的逻辑盘，提升读写效率。

缺点：

采用SAN架构组网时，光纤交换机，造价成本高。

主机之间无法共享数据。

使用场景：

docker容器、虚拟机磁盘存储分配。

日志存储。

文件存储。

5.8.2 文件存储fs

典型设备：

FTP、NFS服务器

为了克服块存储文件无法共享的问题，所以有了文件存储。

在服务器上架设FTP与NFS服务，就是文件存储。

优点：

造价低，随便一台机器就可以了。

方便文件共享。

缺点：

读写速率低。

传输速率慢。

使用场景：

日志存储。

有目录结构的文件存储。

5.8.3 对象存储swift ，rgw

典型设备：

内置大容量硬盘的分布式服务器(swift, s3)

多台服务器内置大容量硬盘，安装上对象存储管理软件，对外提供读写访问功能。

优点：

具备块存储的读写高速。

具备文件存储的共享等特性。

使用场景：

(适合更新变动较少的数据)

图片存储。

视频存储。