Ceph架构综述

1. 引言

Ceph是一款以对象存储技术（独立存储技术）为核心，并在此基础之上实现块存储、文件系统的一体化存储系统。

1.1 块存储

块存储负责提供裸磁盘空间给主机使用，大量的物理磁盘会以种种方式（RAID等）划分为若干逻辑硬盘在主机上挂载使用。操作系统无法分辨存储空间是逻辑硬盘还是物理硬盘。目前块存储的典型应用场景就是在云计算环境下向虚拟主机提供逻辑硬盘。

1.2分布式文件系统

分布式文件系统通过TCP网络协议，将不同主机上的文件系统进行互联，向用户提供更大的存储空间。对于每一个用户而言，他看到的是一个共享文件夹，操作的对象都也都是文件。

1.3 对象存储

对象存储是指按照KEY-VALUE的形式存储对象ID、对象数据，每一个对象又包含元数据以及存储数据。系统 完全扁平化，没有目录，直接根据对象ID定位位置，这一点类似SAN；而每个数据对象既包含元数据又包括存储数据，含有文件系统概念，又类似NAS。除此之外，用户不必关心数据对象的安全性，数据恢复，自动负载平衡等等问题，这些均由对象存储系统自动完成。面向对象存储还解决了SAN面临的有限扩充和NAS传输性能开销大的问题，很好地实现了海量数据存储。

有如下特点：

1. 存储数据类型：非结构化数据，如图片、音视频、文档；
2. 应用场景：一次写入多次读取；
3. 使用方式：对象存储采用bucket（桶）概念，以桶为单元存储数据（通过对象id）；

SAN有限扩充如何理解：

NAS传输性能开销大如何理解：

对象存储的意义在于克服块存储与文件存储各自的缺点，并继承优点。简单来说块存储读写快，不利于共享；而文件存储读写慢，利于共享。对象存储的意义就是达到快速读写的同时实现共享访问。

2.Ceph层次结构

Ceph存储系统的逻辑层次结构如下图所示：

自下向上，可以将Ceph系统分为四个层次： 2.1. 基础存储系统

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

该层是完整的存储系统，数据存储最终都由该层负责，Ceph的高可靠、高可扩展、高性能、高自动化等等特性也由该层保障；

2.2. 基础库librados

该层是RADOS访问库，用于向上层提供API，基于RADOS进行应用开发。应用调用librados API，再由库通过socket与RADOS集群中进行数据交互。

2.3.高层应用接口

该层包括三个部分：

RADOS GW（RADOS Gateway）： 提供与Amazon S3和Swift兼容的RESTful API的gateway，以供相应的对象存储应用开发使用，librados的进一步封装；

RBD（Reliable Block Device）：提供了一个标准的块设备接口，提供逻辑硬盘；

Ceph FS（Ceph File System）：提供POSIX兼容的分布式文件系统。可以像访问本地文件系统一样访问CephFS。

4.应用层

该层为顶层业务层，设计者可根据自身需求选择不用的应用接口，

1. 为云主机准备硬盘，可使用块存储；

2. 如果用于文件的存储以及共享访问，可使用分布式文件系统，或者对象存储；

.......

3.RADOS的逻辑结构

RADOS的系统逻辑结构如下图所示

OSD: Object Storage Device， 对象存储设备，直观理解硬盘+osd 守护进程，负责接受客户端的读写、osd间数据检验(srub)、数据恢复(recovery)、心跳检测等；

MON: 主要解决分布式系统的状态一致性问题，维护集群内各角色节点状态图(mon-map osd-map mds-map pg-map)的一致性，主要发生在OSD添加、删除的等操作上。

CLIENT：和MON通信，获取cluster map. 并通过cluster map进行计算，得到对象最终的存储位置OSD，最后和OSD进行通信，进行数据读写；

客户端主要动作为查找、读、写、删除，此处只以数据读写为例，说明读写过程中的时序：

写过程：

1. Client通过monitor获取集群当前的cluster map;

2. 在Client本地基于cluster map进行计算，得到对象最终存放的OSD节点信息；

3. 直接与OSD进行通信，完成对象的写入；

读过程：

读过程中对象位置查找与写过程类似，只是第三步由写操作改为读操作，将数据从集群中读到

本地的内存空间中；

在数据读写过程中，只要cluster map不频繁更新，客户端完全可以不依赖任何元数据服务器，在client本地就可以完成对象位置的定位。在RADOS的运行过程中，cluster map的更新完全取决于系统的状态变化，而导致这一变化主要为：OSD出现故障、扩容。在正常使用场景下，这两种事件发生的频率较低，系统可以在一种较稳定的情况下工作。

Ceph的核心功能说明：

Ceph的功能核心为RADOS，此处的介绍也是针对RADOS进行。主要内容如下： 1.基于计算的对象寻址机制；

2.对象存取的工作流程；

3.RADOS集群维护的工作过程

4.最后结合Ceph的结构和原理对其技术优势加以回顾和剖析。

3.1 对象寻址

Ceph系统中的寻址流程如下图所示：

核心概念介绍：

1. File（文件）—— 此处的file是用户需要存储或者访问的文件。

2. Ojbect（对象）—— 此处的object是RADOS看到的“对象”。Object与上面提到的file的区别是，object的最大size由RADOS限定（通常为2MB或4MB），以便实现底层存储的组织管理。当上层应用向RADOS存入大文件时，需要对文件进行切片，形成统一大小的object list进行存储。

3.PG（Placement Group 归置组）—— PG的用途是对object的存储进行逻辑位置映射。

a.每个对象会被放置到唯一的PG中，而一个PG可以管理若干个对象；

b.一个PG会被映射到n个OSD上，用于冗余备份，一般生产环境下n为3；

c.每个OSD上都会承载大量的PG，即，PG和OSD之间是“多对多”映射关系；

4. OSD—— 即object storage device，用于实际数据的存储。OSD数量关系到数据分布的均匀性，因此其数量不应太少。

从上图可以看出，整个过程需要经历三次映射：

1. File -> object映射

该映射将file映射为RADOS能够处理的object。即对文件进行切片，按照指定size对file进行切分。

这种切分的好处有二：一是让大小不限的file变成最大size一致、RADOS便于管理；二是让对单一file实施的串行处理变为对多个object实施的并行化处理。

每一个切分后产生的object将获得唯一的oid，即object id。其产生方式也是线性映射，极其简单。图中，ino是待操作file的元数据，可以简单理解为该file的唯一id。ono则是由该file切分产生的某个object的序号。而oid就是将这个序号简单连缀在该file id之后得到的。举例而言，如果一个id为filename的file被切分成了三个object，则其object序号依次为0、1和2，而最终得到的oid就依次为ino0、ino1和ino2。

2. Object -> PG映射

在文件转object后需要将每个object映射到一个PG中去。

hash(oid) & mask -> pgid

该过程将oid映射成为一个近似均匀分布的伪随机值（通过与运算，将该值控制在pgnum之内），得到最终的PG序号（pgid）。根据RADOS的设计，给定PG的总数为m（m应该为2的整数幂），则mask的值为m-1。

该转换函数的意义是，从若干个pg中随机地选择一个pg为Object落户。当有大量object和大量PG时，RADOS能够保证object和PG之间的近似均匀映射。

又因为object是由file切分而来，大部分object的size相同，最终保证各PG中存储的object的总数据量近似均匀。

3. PG -> OSD映射

该映射将object的逻辑组织单元PG整体映射到物理存储单元OSD。如图所示，RADOS采用CRUSH算法，将pgid代入其中，得到一组OSD编号。这批OSD共同负责存储和维护该PG中的所有object。具体到每个OSD，则由OSD守护进程负责object在本地文件系统中的存储、访问、元数据维护等操作。

和“object -> PG”映射中采用的哈希算法不同，这个CRUSH算法的结果不是绝对不变的，而是受其他因素影响。主要有二：

a.当前系统状态，即cluster map。当系统中的OSD状态、数量发生变化时，cluster map可能发生变化，而这种变化将会影响到PG与OSD之间的映射；

b.存储策略配置,这里的策略主要与安全相关。利用策略配置，系统管理员可以指定承载同一个PG的3个OSD分别位于数据中心的不同服务器乃至机架上，从而进一步改善存储的可靠性；

因此，只有在系统状态（cluster map）和存储策略都不变化时，PG和OSD之间的映射关系才是保持固定不变。如果发生变化，因为映射关系变化，会导致数据迁移；

之所以在此次映射中使用CRUSH算法，而不是其他哈希算法，原因有二：

a. CRUSH满足可配置性，可以根据管理员的配置参数决定OSD的物理位置映射策略；

b. CRUSH具有特殊的“稳定性”，当系统状态发生变化，可以保持大部分PG与OSD之间的映射关系不会发生改变，只有少部分PG的映射关系会发生变化并引发数据迁移。减少reblance导致的数据迁移量；

通过三次映射，完成了从File->object、 Object->PG PG->OSD整个映射过程。整个过程没有任何的全局性查表操作需求。只需要进行hash计算即可。

3.2 数据操作流程

此处将首先以file写入过程为例，对数据操作流程进行说明。

为简化说明，便于理解，此处进行若干假定。首先，假定待写入的file较小，无需切分，仅被映射为一个object。其次，假定系统中一个PG被映射到3个OSD上。

基于上述假定，则file写入流程可以被下图表示：

1. 找到Object最终映射到的三个osd；

2. 数据写入主osd;

3. 主osd将数据同步到2个备用osd;

4. 结果返回；

在正常情况下，client可以独立完成OSD寻址操作，而不必依赖于其他系统模块。因此，大量的client可以同时和大量的OSD进行并行操作。同时，如果一个file被切分成多个object，这多个object也可被并行发送至多个OSD。因此，其工作压力可以被尽可能均匀分担，从而避免单个OSD变成性能瓶颈。

如果需要读取数据，client只需完成同样的寻址过程，并直接和Primary OSD联系。目前的Ceph设计中，被读取的数据仅由Primary OSD提供。但目前也有分散读取压力以提高性能的讨论。

3.3 集群状态维护

若干个monitor共同负责整个Ceph集群中所有OSD状态的发现与记录，并且共同形成cluster map的master版本，然后扩散至全体OSD以及client。OSD使用cluster map进行数据的维护，而client使用cluster map进行数据的寻址。集群中各monitor的功能总体上是一样的，其相互间的关系可以被简单理解为主从备份关系,之间通过Paxos协议进行选举。

略显出乎意料的是，monitor并不主动轮询各OSD当前状态。而是OSD主动向monitor上报自身状态信息。常见的上报有两种情况：

1. 新OSD加入集群；

2. 某个OSD发现自身或者其他OSD发生异常；

monitor收到这些信息后主动更新cluster map并在集群中扩散。其细节将在下文中加以介绍。

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，共有四种可能的状态：

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

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

—— down+in： 该OSD发生异常，但仍然承载着至少一个PG，其中仍然存储着数据。这种状态一般是OSD刚刚被发现存在异常；

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

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

根据cluster map的定义可以看出，其版本变化通常只会由（3）和（4）两项信息的变化触发。而这两者相比，（3）发生变化的概率更高一些。这可以通过下面对OSD工作状态变化过程的介绍加以反映。

新节点加入主要会导致如下变化：

1. 先根据配置信息与monitor通信。Monitor将其加入cluster map，并设置为up且out状态，再将最新版本的cluster map发给这个新OSD；

2. OSD收到monitor发来的cluster map之后，计算自己应承载的PG以及和自己承载同一个PG的其他OSD。

3. 新OSD与计算出承载同一PG的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过程。

由之前介绍可以看出，对于一个Ceph集群而言，即便由数千个甚至更多OSD组成，cluster map的数据结构大小也并不惊人。同时，cluster map的状态更新并不会频繁发生。即便如此，Ceph依然对cluster map信息的扩散机制进行了优化，以便减轻相关计算和通信压力。

a. cluster map以增量形式进行扩散，如果任意一次通信的双方发现其epoch不一致，则版本更新的一方将把二者所拥有的cluster map的差异发送给另外一方；

b. cluster map信息是以异步且lazy的形式扩散的。monitor并不会在cluster map版本更新后广播全体，而是在有OSD向自己上报信息时，将更新回复给对方。类似的，各个OSD也是在和其他OSD通信时，将更新发送给版本低于自己的对方；

c. 基于上述机制，Ceph避免了cluster map版本更新引起的广播风暴。这虽然是一种异步且lazy的机制，但根据Sage论文中的结论，对于一个由n个OSD组成的Ceph集群，任何一次版本更新能够在O(log(n))时间复杂度内扩散到集群中的任何一个OSD上;

4.结束语

本文从ceph整体介绍了它的架构以及基本的运作机理，后续会进一步完善的CRUSH算法工作机理。