本文借鉴了ceph官方资料，以及网络公开可查的技术文档或者图片，非绝对原创，向开源领域的贡献者和传播者致敬。

架构简单介绍

Ceph介绍

Ceph是一个分布式存储系统，提供对象，块和文件存储，是一个免费开源软件的存储解决方案，可以部署于普通的x86兼容服务器上，可用于解决统一存储的io问题。Ceph诞生于2004年，最早是SageWeil一项关于存储系统的PhD研究项目，致力于开发下一代高性能分布式文件系统的项目。随着云计算的发展，ceph乘上了OpenStack的春风，进而成为了开源社区受关注较高的项目之一。

该系统被设计成自动修复和智能管理，希望减低管理员和预算开销。

想达到的目标：没有单点故障的完全分布式存储系统，使数据能容错和无缝的复制，可扩展EB水平(EB,PB,TB,GB)。

Ceph同时支持块、文件、对象接口，支持PB级别扩展，规格上可部署到上千台通用服务器。对象S3和Swift写入的数据是相互可读取的。

Ceph逻辑架构图

Ceph特点和优势

1.  CRUSH算法

Crush算法是ceph的两大创新之一，简单来说，ceph摒弃了传统的集中式存储元数据寻址的方案，转而使用CRUSH算法完成数据的寻址操作。CRUSH在一致性哈希基础上很好的考虑了容灾域的隔离，能够实现各类负载的副本放置规则，例如跨机房、机架感知等。Crush算法有相当强大的扩展性，理论上支持数千个存储节点。

2. 高可用

Ceph中的数据副本数量可以由管理员自行定义，并可以通过CRUSH算法指定副本的物理存储位置以分隔故障域，支持数据强一致性； ceph可以忍受多种故障场景并自动尝试并行修复。

3. 高扩展性

Ceph不同于swift，客户端所有的读写操作都要经过代理节点。一旦集群并发量增大时，代理节点很容易成为单点瓶颈。Ceph本身并没有主控节点，扩展起来比较容易，并且理论上，它的性能会随着磁盘数量的增加而线性增长。

4. 特性丰富

Ceph支持三种调用接口：对象存储，块存储，文件系统挂载。三种方式可以一同使用。在国内一些公司的云环境中，通常会采用ceph作为openstack的唯一后端存储来提升数据转发效率。

Ceph整体组件介绍

从下面这张图来简单学习下，Ceph 的架构组件。

自下向上，可以将Ceph系统分为四个层次：

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

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

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

基础库librados

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

RADOS采用C++开发，所提供的原生librados API包括C和C++两种，其文档参见[2]。物理上，librados和基于其上开发的应用位于同一台机器，因而也被称为本地API。应用调用本机上的librados API，再由后者通过socket与RADOS集群中的节点通信并完成各种操作。

高层应用接口

这一层包括了三个部分：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官网并不推荐将其用于生产环境中。

应用层

这一层就是不同场景下对于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的对象存储应用开发，例如公有云上的对象存储服务。

Ceph对象存储特点

Ceph对象存储主要特点如下：

高性能

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

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

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

高可用性

副本数可以灵活控制。

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

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

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

高可扩展性

去中心化。

扩展灵活。

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

Ceph对象存储架构

对象存储系统架构图如下：

如上图所示，Ceph对象存储底层主要有两个基本组件实现

OSD

OSD，Ceph OSD 是由物理磁盘驱动器、在其之上的 Linux 文件系统以及 Ceph OSD 服务组成。Ceph OSD 将数据以对象的形式存储到集群中的每个节点的物理磁盘上，完成存储数据的工作绝大多数是由 OSD daemon 进程实现，用于集群中所有数据与对象的存储。处理集群数据的复制、恢复、回填、再均衡。并向其他osd守护进程发送心跳，然后向Mon提供一些监控信息。

当Ceph存储集群设定数据有两个副本时（一共存两份），则至少需要两个OSD守护进程即两个OSD节点，集群才能达到active+clean状态。

Monitor

Monitor， 维护集群的cluster MAP二进制表，保证集群数据 的一致性。ClusterMAP描述了对象块存储的物理位置，以及一个将设备聚合到物理位置的桶列表，信息由维护集群成员的守护程序来提供各节点之间的状态、集群配置信息。Ceph monitor map主要包括OSD map、PG map、MDS map 和 CRUSH 等，这些 map 被统称为集群 Map。ceph monitor 不存储任何数据。下面分别开始介绍这些map的功能：

Monitor map：包括有关monitor 节点端到端的信息，其中包括 Ceph 集群ID，监控主机名和IP以及端口。并且存储当前版本信息以及最新更改信息，通过 "ceph mon dump" 查看 monitor map。

OSD map：包括一些常用的信息，如集群ID、创建OSD map的 版本信息和最后修改信息，以及pool相关信息，主要包括pool 名字、pool的ID、类型，副本数目以及PGP等，还包括数量、状态、权重、最新的清洁间隔和OSD主机信息。

PG map：包括当前PG版本、时间戳、最新的OSD Map的版本信息、空间使用比例，以及接近占满比例信息，同事，也包括每个PG ID、对象数目、状态、OSD 的状态以及深度清理的详细信息。

CRUSH map： CRUSH map 包括集群存储设备信息，故障域层次结构和存储数据时定义失败域规则信息。通过 命令 "ceph osd crush map" 查看。

MDS map：MDS Map 包括存储当前 MDS map 的版本信息、创建当前的Map的信息、修改时间、数据和元数据POOL ID、集群MDS数目和MDS状态。

Crush

简单说下CRUSH，Controlled Replication Under Scalable Hashing，它表示数据存储的分布式选择算法， ceph 的高性能/高可用就是采用这种算法实现。CRUSH 算法取代了在元数据表中为每个客户端请求进行查找，它通过计算系统中数据应该被写入或读出的位置。CRUSH能够感知基础架构，能够理解基础设施各个部件之间的关系。并且CRUSH保存数据的多个副本，这样即使一个故障域的几个组件都出现故障，数据依然可用。CRUSH 算是使得 ceph 实现了自我管理和自我修复。

高性能索引和分布均匀性

CRUSH算法介绍

Crush算法是一种伪随机算法，通过权重决定数据存放（如跨机房、机架感知等），通常采用基于容量的权重。Crush算法支持副本和EC两种数据冗余方式，还提供了四种不同类型的Bucket(Uniform、List、Tree、Straw)，大多数情况下的都采用Straw。

在说明CRUSH算法的基本原理之前，先介绍几个概念和它们之间的关系。

File —— 此处的file就是用户需要存储或者访问的文件。对于一个基于Ceph开发的对象存储应用而言，这个file也就对应于应用中的“对象”，也就是用户直接操作的“对象”。

Ojbect —— 此处的object是RADOS所看到的“对象”。Object与上面提到的file的区别是，object的最大size由RADOS限定（通常为2MB或4MB），以便实现底层存储的组织管理。因此，当上层应用向RADOS存入size很大的file时，需要将file切分成统一大小的一系列object（最后一个的大小可以不同）进行存储。为避免混淆，在本文中将尽量避免使用中文的“对象”这一名词，而直接使用file或object进行说明。

PG（Placement Group）—— 顾名思义，PG的用途是对object的存储进行组织和位置映射。具体而言，一个PG负责组织若干个object（可以为数千个甚至更多），但一个object只能被映射到一个PG中，即，PG和object之间是“一对多”映射关系。同时，一个PG会被映射到n个OSD上，而每个OSD上都会承载大量的PG，即，PG和OSD之间是“多对多”映射关系。在实践当中，n至少为2，如果用于生产环境，则至少为3。一个OSD上的PG则可达到数百个。事实上，PG数量的设置牵扯到数据分布的均匀性问题。关于这一点，下文还将有所展开。

OSD —— 即object storage device，前文已经详细介绍，此处不再展开。唯一需要说明的是，OSD的数量事实上也关系到系统的数据分布均匀性，因此其数量不应太少。在实践当中，至少也应该是数十上百个的量级才有助于Ceph系统的设计发挥其应有的优势。

Failure domain —— 这个概念在论文中并没有进行定义，好在对分布式存储系统有一定概念的读者应该能够了解其大意。

存储数据与object的关系：

当用户要将数据存储到Ceph集群时，存储数据都会被分割成多个object，每个object都有一个object id，每个object的大小是可以设置的，默认是4MB，object可以看成是Ceph存储的最小存储单元。

object与pg的关系：

由于object的数量很多，所以Ceph引入了pg的概念用于管理object，每个object最后都会通过CRUSH计算映射到某个pg中，一个pg可以包含多个object。

pg与osd的关系：

pg也需要通过CRUSH计算映射到osd中去存储，如果是二副本的，则每个pg都会映射到二个osd，比如[osd.1,osd.2]，那么osd.1是存放该pg的主副本，osd.2是存放该pg的从副本，保证了数据的冗余。

Ceph通过Crush算法，将若干个object映射到PG上，形成一个object与PG的逻辑集合，并以此作为object与OSD的中间层，将PG根据所在POOL的副本数，复制到多个OSD上。PG的用途是将某些东西进行逻辑归组，从而达到统一管理，提升效率的作用。相对整体集群规模来说，如果存储池设置的PG较少，那么在每个PG上Ceph将会存储大量的数据；如果存储池设置的PG过大，那么Ceph OSD将会消耗更多的CPU与内存。

pg和pgp的关系：

pg是用来存放object的，pgp相当于是pg存放osd的一种排列组合，我举个例子，比如有3个osd，osd.1、osd.2和osd.3，副本数是2，如果pgp的数目为1，那么pg存放的osd组合就只有一种，可能是[osd.1,osd.2]，那么所有的pg主从副本分别存放到osd.1和osd.2，如果pgp设为2，那么其osd组合可以两种，可能是[osd.1,osd.2]和[osd.1,osd.3]，是不是很像我们高中数学学过的排列组合，pgp就是代表这个意思。一般来说应该将pg和pgp的数量设置为相等。

CRUSH算法寻址流程

在Ceph存储系统中，数据存储分三个映射过程，首先要将用户要操作的file，映射为RADOS能够处理的object。就是简单的按照object的size对file进行切分，相当于RAID中的条带化过程。接着把Object映射到PG，在file被映射为一个或多个object之后，就需要将每个object独立地映射到一个PG中去，计算object的Hash值并将结果和PG数目取余，以得到object对应的PG编号。第三次映射就是使用CRUSH算法将作为object的逻辑组织单元的PG映射到数据的实际存储单元OSD。

文件存入时，首先把File切分为RADOS层面的Object，每个Object一般为2MB或4MB(大小可设置)。每个Object通过哈希算法映射到唯一的PG。每个PG通过Crush算法映射到实际存储单元OSD，PG和OSD间是多对多的映射关系。OSD在物理上可划分到多个故障域中，故障域可以跨机柜和服务器，通过策略配置使PG的不同副本位于不同的故障域中。

在PG通过Crush算法映射到数据的实际存储单元OSD时，需求通过Crush Map、Crush Rules和Crush算法配合才能完成。

Cluster Map用来记录全局系统状态记数据结构，由Crush Map和OSD Map两部分组成。 Crush Map包含当前磁盘、服务器、机架的层级结构，OSD Map包含当前所有Pool的状态和所有OSD的状态。

Crush Rules就是数据映射的策略，决定了每个数据对象有多少个副本，这些副本如何存储。

CRUSH算法因子

CRUSH算法的全称为：Controlled Scalable Decentralized Placement of Replicated Data，可控的、可扩展的、分布式的副本数据放置算法。

pg到OSD的映射的过程算法叫做CRUSH 算法。(如一个Object需要保存三个副本，也就是需要保存在三个osd上)。

CRUSH算法是一个伪随机的过程，他可以从所有的OSD中，随机性选择一个OSD集合，但是同一个PG每次随机选择的结果是不变的，也就是映射的OSD集合是固定的。

(Pool, PG) → OSD set 的映射由四个因素决定：

CRUSH算法：一种伪随机算法。

OSD MAP：包含当前所有Pool的状态和所有OSD的状态。

CRUSH MAP：包含当前磁盘、服务器、机架的层级结构。

CRUSH Rules：数据映射的策略。

层级化的Cluster Map

反映了存储系统层级的物理拓扑结构。定义了OSD集群具有层级关系的 静态拓扑结构。OSD层级使得 CRUSH算法在选择OSD时实现了机架感知能力，也就是通过规则定义， 使得副本可以分布在不同的机 架、不同的机房中、提供数据的安全性 。

层级化的Cluster Map

CRUSH Map是一个树形结构，OSDMap更多记录的是OSDMap的属性(epoch/fsid/pool信息以及osd的ip等等)。

叶子节点是device（也就是osd），其他的节点称为bucket节点，这些bucket都是虚构的节点，可以根据物理结构进行抽象，当然树形结构只有一个最终的根节点称之为root节点，中间虚拟的bucket节点可以是数据中心抽象、机房抽象、机架抽象、主机抽象等。

Cluster map的实际内容包括：

Epoch，即版本号。Cluster map的epoch是一个单调递增序列。Epoch越大，则cluster map版本越新。因此，持有不同版本cluster map的OSD或client可以简单地通过比较epoch决定应该遵从谁手中的版本。而monitor手中必定有epoch最大、版本最新的cluster map。当任意两方在通信时发现彼此epoch值不同时，将默认先将cluster map同步至高版本一方的状态，再进行后续操作。

各个OSD的网络地址。

各个OSD的状态。OSD状态的描述分为两个维度：up或者down（表明OSD是否正常工作），in或者out（表明OSD是否在至少一个PG中）。因此，对于任意一个OSD，共有四种可能的状态：

—— Up且in：说明该OSD正常运行，且已经承载至少一个PG的数据。这是一个OSD的标准工作状态；

—— Up且out：说明该OSD正常运行，但并未承载任何PG，其中也没有数据。一个新的OSD刚刚被加入Ceph集群后，便会处于这一状态。而一个出现故障的OSD被修复后，重新加入Ceph集群时，也是处于这一状态；

—— Down且in：说明该OSD发生异常，但仍然承载着至少一个PG，其中仍然存储着数据。这种状态下的OSD刚刚被发现存在异常，可能仍能恢复正常，也可能会彻底无法工作；

—— Down且out：说明该OSD已经彻底发生故障，且已经不再承载任何PG。

CRUSH算法配置参数。表明了Ceph集群的物理层级关系（cluster hierarchy），位置映射规则（placement rules）。

数据分布策略Placement Rules

数据分布策略Placement Rules主要有特点：

a. 从CRUSH Map中的哪个节点开始查找

b. 使用那个节点作为故障隔离域

c. 定位副本的搜索模式（广度优先 or 深度优先）

Bucket随机算法类型

一般的buckets：适合所有子节点权重相同，而且很少添加删除item。

list buckets：适用于集群扩展类型。增加item，产生最优的数据移动，查找item，时间复杂度O(n)。

tree buckets：查找负责度是O (log n), 添加删除叶子节点时，其他节点node_id不变。

straw buckets：允许所有项通过类似抽签的方式来与其他项公平“竞争”。定位副本时，bucket中的每一项都对应一个随机长度的straw，且拥有最长长度的straw会获得胜利（被选中），添加或者重新计算，子树之间的数据移动提供最优的解决方案。

CRUSH算法案例

说明：

集群中有部分sas和ssd磁盘，现在有个业务线性能及可用性优先级高于其他业务线，能否让这个高优业务线的数据都存放在ssd磁盘上。

普通用户：

高优用户：

配置规则：

 总结

crush算法良好的设计理念，使其具有计算寻址，高并发和动态数据均衡，可定制的副本策略等基本特性，进而能够非常方便的实现诸如去中心化，有效抵御物理结构变化，并保证性能随着集群规模呈线性扩展，高可靠等特性，因而非常适合ceph这类可扩展，性能和可靠性都有严苛要求的大型分布式存储系统。

由于篇幅有限，未能从代码实现层面详解straw算法实现，后续专题讲解。

存储容量及可扩展性（extendibility）

存储容量及可扩展性

Ceph 的性能和存储容量随 OSD 的扩展几乎是线性增加。

CRUSH 通过一种伪随机的方式将数据进行分布，因此 OSD 的利用就能够准确地通过二项式建模或者常规方式分配。无论哪一个都可以取得完美的随机过程。随着 PG 的增加，差异就下降：对于每个 OSD 100 个 PG的情况下，标准差是 10%；对于1000 个的情况下为 3%。线性的分布策略极好地将负载在集群中平衡。但是简单的哈希函数无法处理设备失效以及 OSD 变动的情况。因为数据通过 CRUSH 来进行分配，如果哈希比较乱，那么在 PGs 较少的情况下，其吞吐会有所下降：因为 OSD 使用的差异变化大，那么会导致请求队列的长度会在我们客户端的散乱的负载下发生抖动（飘移）。因为设备有可能变得过满或者使用过度，从而拖累性能，CRUSH 通过卸载所有的分配碎片到一个特定的 OSD 上从而来修正这样的问题。与哈希以及线性策略不同，CRUSH 同时也最小化了数据在集群扩展产生的迁移，同时又保证了负载的平衡。CRUSH 的计算复杂度为 O（log(n)）（对于有 n 个 OSD 的集群），因此只需要 10 几个微秒就可以使集群增长到好几千个 OSDs。

Ceph不同于swift，客户端所有的读写操作都要经过代理节点。一旦集群并发量增大时，代理节点很容易成为单点瓶颈。Ceph本身并没有主控节点，扩展起来比较容易，并且理论上，它的性能会随着磁盘数量的增加而线性增长。

综上，ceph的扩展性具备以下特点：

高度并行。没有单个中心控制组件。所有负载都能动态的划分到各个服务器上。把更多的功能放到OSD上，让OSD更智能。

自管理。容易扩展、升级、替换。当组件发生故障时，自动进行数据的重新复制。当组件发生变化时(添加/删除)，自动进行数据的重分布。

由于Monitor和OSD节点都具备平行扩展的条件，因此存储容量理论上可以达到EB，PB级别。

系统可用性（Availability）

系统可用性保证

在分布式系统中，常见的故障有网络中断、掉电、服务器宕机、硬盘故障等，Ceph能够容忍这些故障，并进行自动修复，保证数据的可靠性和系统可用性。

Monitors是Ceph管家，维护着Ceph的全局状态。Monitors的功能和zookeeper类似，它们使用Quorum和Paxos算法去建立全局状态的共识。

OSDs可以进行自动修复，而且是并行修复。

故障检测：

OSD之间有心跳检测，当OSD A检测到OSD B没有回应时，会报告给Monitors说OSD B无法连接，则Monitors给OSD B标记为down状态，并更新OSD Map。当过了M秒之后还是无法连接到OSD B，则Monitors给OSD B标记为out状态(表明OSD B不能工作），并更新OSD Map。

备注：可以在Ceph中配置M的值。

故障恢复：

当某个PG对应的OSD set中有一个OSD被标记为down时(假如是Primary被标记为down，则某个Replica会成为新的Primary，并处理所有读写 object请求)，则该PG处于active+degraded状态，也就是当前PG有效的副本数是N-1。

过了M秒之后，假如还是无法连接该OSD，则它被标记为out，Ceph会重新计算PG到OSD set的映射(当有新的OSD加入到集群时，也会重新计算所有PG到OSD set的映射)，以此保证PG的有效副本数是N。

新OSD set的Primary先从旧的OSD set中收集PG log，得到一份Authoritative History(完整的、全序的操作序列)，并让其他Replicas同意这份Authoritative History(也就是其他Replicas对PG的所有objects的状态达成一致)，这个过程叫做Peering。

当Peering过程完成之后，PG进 入active+recoverying状态，Primary会迁移和同步那些降级的objects到所有的replicas上，保证这些objects 的副本数为N。

数据同步机制

PG同步机制介绍

在可扩展的情形下，为了保证系统的可用性以及数据的安全，RADOS 通过可变的主复本复制技术来管理自己的数据复本，同时利用多个步骤来保证对性能的影响最小化。

数据是根据 PGs 来复制的，每个 PG 都影射到一个有序 n 路 OSD中（对于 n 路复制）。客户端将所有的写发送到第一个未失效的 OSD 的对象 PG 中（主），然后赋给对象以及 PG 一个版本号，然后将写转发到所有其他复本 OSDs 中。当所有的复本都已经应用并且更新回得到了主复本，则主复本在本地应用更新，然后将写确认发送到客户端。读则将被定向到主复本。这样的方式使用客户端不要关心数据在不同版本之间序列化以及同步的复杂性，这些复杂性会在其他的写者到来或者失效恢复情况下更加严重。同时，这也将由复本所消耗的带宽由客户端移到了 OSD 集群的内部网络，这样我们可以期望整个资源的最大可用性。

数据一致性保证（Consistency）

最终一致性

如图所示Ceph的读写操作采用Primary-Replica模型，Client只向Object所对应OSD set的Primary发起读写请求，这保证了数据的强一致性。

由于每个Object都只有一个Primary OSD，因此对Object的更新都是顺序的，不存在同步问题。

当Primary收到Object的写请求时，它负责把数据发送给其他Replicas，只要这个数据被保存在所有的OSD上时，Primary才应答Object的写请求，这保证了副本的一致性。另外client不需要负责副本的复制(由primary负责),这降低了client的网络消耗。

故障迁移及恢复

故障迁移及恢复说明

由于 OSD 的失效，恢复以及部署新存储设备，OSD 集群影射是会变化的。

Ceph 对这些变化的处理方式都是一样的。为了快速恢复，OSDs对每一个 PG 的每一个对象以及最新的更新日志（名字以及更新版本，或者删除的对象）都维护了一个版本号。当活动的 OSD 收到更新影射的消息，它将遍历所有的存储在本地的 PG，并计算 CRUSH 影射来确定其对哪一个负责，是作为主还是做复本。

如果 PG 的成员有了变化，或者 OSD 刚刚启动，那个这个 OSD 必须与 PG 中的其他 OSD 建立连接端点。对于作为复本的 PGs，OSD 向主复本提供当前PG 的版本号。如果主复本没有最近的 PG 状态，为了确定正确 PG 的正确内容（最近的）则从当前的或者前一个 PG 的 OSD 中取得 PG 变更的日志（如果必要的话，也取得完整的内容）。主复本将数据的增量更新日志（如果必要，连同完整的内容）发送给其他的复本设备，这样每一部份都将取得 PG 的内容，就算它们本地的内容是有差异的。只有在主复本确认的正确的 PG 状态，并且将其共享给了其他的复本设备后，针对 PG 中对象的 IO才会被放行。之后，OSDs 将独立负责从其他对端中取回丢失的数据以及更新过时的数据。

如果某个 OSD 收到一个空白或者丢失的对象的请求，则会延迟处理，并将这个对像的恢复移动到处理队列的前部。例如，如果 osd1 崩溃了，并且被标记为 Down 状态，osd2 成为 pgA 的主复本。这时如果 osd1 恢复了，在启动后它会请求最新的影射信息，监控器也将其标记为启动状态。当 osd2 收到了最终的更新信息，则它会意识到自己不再是 pgA 的主复本，并发送 pgA 版本号到 osd1。此时 osd1 将从 osd2 中取回 pgA 最新的更新日志记录，并告诉 osd2 它的内容才是最新的，当所有对象的恢复完成后，osd1 才会处理其他的请求。

由于失效恢复完全由个个的 OSDs 来驱动，每个受失效 OSD 影响的 PG 对于替换的OSD 来讲都是并行恢复。这种基于FaRM（Fast Revovery   Mechanism） 的方式，减少了恢复的时间，提高了数据的整体安全性。

OSD新增或者故障迁移中，cluster map的关键作用

一个新的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。

如果该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过程。

数据持久及可靠性（Durability）

数据持久及可靠性保证

数据多副本。可配置的per-pool副本策略和故障域布局，支持强一致性。

没有单点故障。可以忍受许多种故障场景；防止脑裂；单个组件可以滚动升级并在线替换。

所有故障的检测和自动恢复。恢复不需要人工介入，在恢复期间，可以保持正常的数据访问。

并行恢复。并行的恢复机制极大的降低了数据恢复时间，提高数据的可靠性。

高性能传输

高性能传输特性

Client和OSD直接通信，不需要代理和转发。

多个OSD带来的高并发度。objects是分布在所有OSD上。

负载均衡。每个OSD都有权重值(现在以容量为权重)。

client不需要负责副本的复制(由primary负责),这降低了client的网络消耗。

高性能存储(包括元数据存储机制)

ceph后端支持多种存储引擎，以插件式的方式来进行管理使用，目前支持filestore，kvstore，memstore以及最新的bluestore，目前默认使用的filestore，但是因为filestore在写数据前需要先写journal，会有一倍的写放大，并且filestore一开始只是对于机械盘进行设计的，没有专门针对ssd做优化考虑，因此诞生的bluestore初衷就是为了减少写放大，并针对ssd做优化，而且直接管理裸盘，从理论上进一步减少文件系统如ext4/xfs等部分的开销.

BlueStore最早在Jewel版本中引入，用于取代传统的fileStore，作为新一代高性能对象存储后端。BlueStore在设计中充分考虑了对下一代全SSD以及全NVMe SSD闪存阵列的适配，例如将一直沿用至今，用于高效索引元数据的DB引擎由levelDB替换为RocksDB，（RocksDB基于LevelDB发展而来，并针对直接使用SSD作为后端存储介质的场景做了大量优化）。FileStore因为仍然需要通过操作系统自带的本地文件系统间接管理磁盘，所以所有针对RADOS层的对象操作，都需要预先转换为能够被本地文件系统识别，符合POSIX语义的文件操作，这个转换过程极其繁琐，效率低下。

针对FileStore的上述缺陷，BlueStore选择绕过本地文件系统，由自身接管裸设备（例如磁盘），直接进行对象操作，这是BlueStore能够提升性能的根本原因。除此之外，考虑到元数据的索引效率对于性能有着致命影响，BlueStore在设计中将元数据和用户数据严格分离，因此BlueStore中的元数据可以单独采用高速固态存储涉笔，例如使用NVMe SSD进行存储，能够起到性能加速的作用，另外Ceph支持通过xattrs扩展属性的方式保存元数据。

跨地域支持

       Ceph对象存储中的OSDs 可以分布在不同地域的数据中心，但是由于系统对文件对象存储强一致性的要求，副本在不同地域的OSDs之间同步，存在延时，因此，跨地域的响应实时性方面，较swift差，更适合在同一个数据中心的大型集群。

成熟稳定度

可以看到国内ceph用户如：中国移动、腾讯、阿里、网易、乐视、携程、今日头条、中国电信、中兴、恒丰银行、平安科技、YY、B站、360等。正是由于众多用户的使用验证了它的稳定性和可靠性的同时也促进了Ceph的进步，使其出现了很多新东西，如 SPDK、BlueStore、RDMA等等这些高性能底层技术。（摘抄自腾讯云网站的公开文章），另外据公开资料显示，国外的雅虎，Intel等公司均使用ceph作为共有或者私有云存储的基础组建。

其他特性

Ceph对象存储还支持纠删码机制，替代多副本机制，实现数据的一致性保证，和存储可靠性。

Ceph提供基于dmClock算法的存储服务质量QoS机制，来实现平衡后端I/O资源的调度策略

由于篇幅有限，后续可专题介绍。

可维护性

Ceph由于支持特性较多，代码和功能较swift更丰富，因此学习和维护成本更高。