1.1 Ceph简介

Ceph是一个统一的分布式存储系统，设计初衷是提供较好的性能、可靠性和可扩展性。

Ceph项目最早起源于Sage就读博士期间的工作（最早的成果于2004年发表），并随后贡献给开源社区。在经过了数年的发展之后，目前已得到众多云计算厂商的支持并被广泛应用。RedHat及OpenStack都可与Ceph整合以支持虚拟机镜像的后端存储。

1.2 Ceph特点

高性能

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

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

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

高可用性

a. 副本数可以灵活控制。

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

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

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

高可扩展性

a. 去中心化。

b. 扩展灵活。

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

特性丰富

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

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

1.3 Ceph架构

支持三种接口：

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

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

File：Posix接口，支持快照。
1.4 Ceph核心组件及概念介绍

Monitor

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

OSD

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

MDS

MDS全称Ceph Metadata Server，是CephFS服务依赖的元数据服务。

Object

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

PG

PG全称Placement Grouops，是一个逻辑的概念，一个PG包含多个OSD。引入PG这一层其实是为了更好的分配数据和定位数据。. 客户端创建一个pool，需要为这个pool指定pg的数量。

2. 创建pool/image rbd设备进行挂载。

3. 用户写入的数据进行切块，每个块的大小默认为4M，并且每个块都有一个名字，名字就是object+序号。

4. 将每个object通过pg进行副本位置的分配。

5. pg根据cursh算法会寻找3个osd，把这个object分别保存在这三个osd上。

6. osd上实际是把底层的disk进行了格式化操作，一般部署工具会将它格式化为xfs文件系统。

7. object的存储就变成了存储一个文rbd0.object1.file

RADOS

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

Libradio

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

1. 采用的是librbd的形式，使用librbd创建一个块设备，向这个块设备中写入数据。

2. 在客户端本地同过调用librados接口，然后经过pool，rbd，object、pg进行层层映射,在PG这一层中，可以知道数据保存在哪3个OSD上，这3个OSD分为主从的关系。

3. 客户端与primay OSD建立SOCKET 通信，将要写入的数据传给primary OSD，由primary OSD再将数据发送给其他replica OSD数据节点。

CRUSH

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

RBD

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

RGW

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

CephFS

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

pool是ceph存储数据时的逻辑分区，它起到namespace的作用。

每个pool包含一定数量(可配置)的PG。

PG里的对象被映射到不同的Object上。

pool是分布到整个集群的。

pool可以做故障隔离域，根据不同的用户场景不一进行隔离。

2.8 Ceph 数据扩容PG分布

场景数据迁移流程：

现状3个OSD, 4个PG

扩容到4个OSD, 4个PG

现状：

ceph_recory_1

扩容后：

ceph_io_recry2

说明

每个OSD上分布很多PG, 并且每个PG会自动散落在不同的OSD上。如果扩容那么相应的PG会进行迁移到新的OSD上，保证PG数量的均衡。

3. Ceph心跳机制

3.1 心跳介绍

心跳是用于节点间检测对方是否故障的，以便及时发现故障节点进入相应的故障处理流程。

问题：

故障检测时间和心跳报文带来的负载之间做权衡。

心跳频率太高则过多的心跳报文会影响系统性能。

心跳频率过低则会延长发现故障节点的时间，从而影响系统的可用性。

故障检测策略应该能够做到：

及时：节点发生异常如宕机或网络中断时，集群可以在可接受的时间范围内感知。

适当的压力：包括对节点的压力，和对网络的压力。

容忍网络抖动：网络偶尔延迟。

扩散机制：节点存活状态改变导致的元信息变化需要通过某种机制扩散到整个集群

OSD节点会监听public、cluster、front和back四个端口

public端口：监听来自Monitor和Client的连接。SD报告给Monitor：

OSD有事件发生时（比如故障、PG变更）。

自身启动5秒内。

OSD周期性的上报给Monito

OSD检查failure_queue中的伙伴OSD失败信息。

向Monitor发送失效报告，并将失败信息加入failure_pending队列，然后将其从failure_queue移除。

收到来自failure_queue或者failure_pending中的OSD的心跳时，将其从两个队列中移除，并告知Monitor取消之前的失效报告。

当发生与Monitor网络重连时，会将failure_pending中的错误报告加回到failure_queue中，并再次发送给Monitor。

Monitor统计下线OSD

Monitor收集来自OSD的伙伴失效报告。

当错误报告指向的OSD失效超过一定阈值，且有足够多的OSD报告其失效时，将该OSD下线。

3.5 Ceph心跳检测总结

Ceph通过伙伴OSD汇报失效节点和Monitor统计来自OSD的心跳两种方式判定OSD节点失效。

及时：伙伴OSD可以在秒级发现节点失效并汇报Monitor，并在几分钟内由Monitor将失效OSD下线。

适当的压力：由于有伙伴OSD汇报机制，Monitor与OSD之间的心跳统计更像是一种保险措施，因此OSD向Monitor发送心跳的间隔可以长达600秒，Monitor的检测阈值也可以长达900秒。Ceph实际上是将故障检测过程中中心节点的压力分散到所有的OSD上，以此提高中心节点Monitor的可靠性，进而提高整个集群的可扩展性。

容忍网络抖动：Monitor收到OSD对其伙伴OSD的汇报后，并没有马上将目标OSD下线，而是周期性的等待几个条件：

目标OSD的失效时间大于通过固定量osd_heartbeat_grace和历史网络条件动态确定的阈值。

来自不同主机的汇报达到mon_osd_min_down_reporters。

满足前两个条件前失效汇报没有被源OSD取消。
Ceph通信框架

4.1 Ceph通信框架种类介绍

网络通信框架三种不同的实现方式：

Simple线程模式

特点：每一个网络链接，都会创建两个线程，一个用于接收，一个用于发送。

缺点：大量的链接会产生大量的线程，会消耗CPU资源，影响性能。

Async事件的I/O多路复用模式

特点：这种是目前网络通信中广泛采用的方式。k版默认已经使用Asnyc了。

XIO方式使用了开源的网络通信库accelio来实现

特点：这种方式需要依赖第三方的库accelio稳定性，目前处于试验阶段。

4.2 Ceph通信框架设计模式

设计模式(Subscribe/Publish)：

订阅发布模式又名观察者模式，它意图是“定义对象间的一种一对多的依赖关系，

当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新”。
扩散：作为中心节点的Monitor并没有在更新OSDMap后尝试广播通知所有的OSD和Client，而是惰性的等待OSD和Client来获取。以此来减少Monitor压力并简化交互逻辑。

cluster端口：监听来自OSD Peer的连接。

front端口：供客户端连接集群使用的网卡, 这里临时给集群内部之间进行心跳。

back端口：供客集群内部使用的网卡。集群内部之间进行心跳。

hbclient：发送ping心跳的messenger。

1 数据分布算法挑战

数据分布和负载均衡：

a. 数据分布均衡，使数据能均匀的分布到各个节点上。

b. 负载均衡，使数据访问读写操作的负载在各个节点和磁盘的负载均衡。

灵活应对集群伸缩

a. 系统可以方便的增加或者删除节点设备，并且对节点失效进行处理。

b. 增加或者删除节点设备后，能自动实现数据的均衡，并且尽可能少的迁移数据。

支持大规模集群

a. 要求数据分布算法维护的元数据相对较小，并且计算量不能太大。随着集群规模的增 加，数据分布算法开销相对比较小。

5.2 Ceph CRUSH算法说明

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

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

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

5.3 Ceph CRUSH算法原理

CRUSH算法因子：

层次化的Cluster Map

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

Placement Rules

决定了一个PG的对象副本如何选择的规则，通过这些可以自己设定规则，用户可以自定义设置副本在集群中的分布。