本文由于篇幅过长，分文上下两篇，此篇为上篇。
本文主要从架构简介使用场景，以及内部 IO 流程、心跳机制、通信框架、CRUSH 算法、QOS 等多个方面逐渐介绍分布式存储系统 Ceph 的特性。希望对你有所帮助。
阅读索引
Ceph 架构简介及使用场景介绍
1.1 Ceph 简介
1.2 Ceph 特点
1.3 Ceph 架构
1.4 Ceph 核心组件及概念介绍
1.5 三种存储类型-块存储
1.6 三种存储类型-文件存储
1.7 三种存储类型-对象存储
Ceph IO 流程及数据分布
2.1 正常 IO 流程图
2.2 新主 IO 流程图
2.3 Ceph IO 算法流程
2.4 Ceph IO 伪代码流程
2.5 Ceph RBD IO 流程
2.6 Ceph RBD IO 框架图
2.7 Ceph Pool 和 PG 分布情况
2.8 Ceph 数据扩容 PG 分布
Ceph 心跳机制
3.1 心跳介绍
3.2 Ceph 心跳检测
3.3 Ceph OSD 之间相互心跳检测
3.4 Ceph OSD 与 Mon 心跳检测
3.5 Ceph 心跳检测总结
Ceph 通信框架
4.1 Ceph 通信框架种类介绍
4.2 Ceph 通信框架设计模式
4.3 Ceph 通信框架流程图
4.4 Ceph 通信框架类图
4.5 Ceph 通信数据格式
Ceph CRUSH 算法
5.1 数据分布算法挑战
5.2 Ceph CRUSH 算法说明
5.3 Ceph CRUSH 算法原理
5.3.1 层级化的 Cluster Map
5.3.2 数据分布策略 Placement Rules
5.3.3 Bucket 随机算法类型
5.4 Ceph CRUSH 算法案例
定制化 Ceph RBD QOS
6.1 QOS 介绍
6.2 Ceph IO 操作类型
6.3 Ceph 官方 QOS 原理
6.4 定制化 QOS 原理
6.4.1 令牌桶算法介绍
6.4.2 RBD 令牌桶算法流程
6.4.3 RBD 令牌桶算法框架图
1. Ceph 架构简介及使用场景介绍
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 这一层其实是为了更好的分配数据和定位数据。
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 对外提供的文件系统服务。
1.5 三种存储类型-块存储
典型设备：
磁盘阵列，硬盘
主要是将裸磁盘空间映射给主机使用的。
优点：
a. 通过 Raid 与 LVM 等手段，对数据提供了保护。
b. 多块廉价的硬盘组合起来，提高容量。
c. 多块磁盘组合出来的逻辑盘，提升读写效率。
缺点：
a. 采用 SAN 架构组网时，光纤交换机，造价成本高。
b. 主机之间无法共享数据。
使用场景：
a. docker 容器、虚拟机磁盘存储分配。
b. 日志存储。
c. 文件存储。
d. …
1.6 三种存储类型-文件存储
典型设备：
FTP、NFS 服务器
为了克服块存储文件无法共享的问题，所以有了文件存储。
在服务器上架设 FTP 与 NFS 服务，就是文件存储。
优点：
a. 造价低，随便一台机器就可以了。
b. 方便文件共享。
缺点：
a. 读写速率低。
b. 传输速率慢。
使用场景：
a. 日志存储。
b. 有目录结构的文件存储。
c. …
1.7 三种存储类型-对象存储
典型设备：
内置大容量硬盘的分布式服务器(swift, s3)
多台服务器内置大容量硬盘，安装上对象存储管理软件，对外提供读写访问功能。
优点：
a. 具备块存储的读写高速。
b. 具备文件存储的共享等特性。
使用场景：
(适合更新变动较少的数据)
a. 图片存储。
b. 视频存储。
c. …
2. Ceph IO 流程
2.1 正常 IO 流程图
步骤：
client 创建 cluster handler。
client 读取配置文件。
client 连接上 monitor，获取集群 map 信息。
client 读写 io 根据 crshmap 算法请求对应的主 osd 数据节点。
主 osd 数据节点同时写入另外两个副本节点数据。
等待主节点以及另外两个副本节点写完数据状态。
主节点及副本节点写入状态都成功后，返回给 client，io 写入完成。
2.2 新主 IO 流程图
说明：
如果新加入的 OSD1 取代了原有的 OSD4 成为 Primary OSD, 由于 OSD1 上未创建 PG , 不存在数据，那么 PG 上的 I/O 无法进行，怎样工作的呢？
步骤：
client 连接 monitor 获取集群 map 信息。
同时新主 osd1 由于没有 pg 数据会主动上报 monitor 告知让 osd2 临时接替为主。
临时主 osd2 会把数据全量同步给新主 osd1。
client IO 读写直接连接临时主 osd2 进行读写。
osd2 收到读写 io，同时写入另外两副本节点。
等待 osd2 以及另外两副本写入成功。
osd2 三份数据都写入成功返回给 client, 此时 client io 读写完毕。
如果 osd1 数据同步完毕，临时主 osd2 会交出主角色。
osd1 成为主节点，osd2 变成副本。
2.3 Ceph IO 算法流程
1. File 用户需要读写的文件。File->Object 映射：
a. ino (File 的元数据，File 的唯一 id)。
b. ono(File 切分产生的某个 object 的序号，默认以 4M 切分一个块大小)。
c. oid(object id: ino + ono)。
2. Object 是 RADOS 需要的对象。Ceph 指定一个静态 hash 函数计算 oid 的值，将 oid 映射成一个近似均匀分布的伪随机值，然后和 mask 按位相与，得到 pgid。Object->PG 映射：
a) hash(oid) & mask-> pgid 。
b) mask = PG 总数 m(m 为 2 的整数幂)-1 。
3. PG(Placement Group),用途是对 object 的存储进行组织和位置映射, (类似于 redis cluster 里面的 slot 的概念) 一个 PG 里面会有很多 object。采用 CRUSH 算法，将 pgid 代入其中，然后得到一组 OSD。PG->OSD 映射：
a) CRUSH(pgid)->(osd1,osd2,osd3) 。
2.4 Ceph IO 伪代码流程
2.5 Ceph RBD IO 流程
数据组织：
步骤：
客户端创建一个 pool，需要为这个 pool 指定 pg 的数量。
创建 pool/image rbd 设备进行挂载。
用户写入的数据进行切块，每个块的大小默认为 4M，并且每个块都有一个名字，名字就是 object+序号。
将每个 object 通过 pg 进行副本位置的分配。
pg 根据 cursh 算法会寻找 3 个 osd，把这个 object 分别保存在这三个 osd 上。
osd 上实际是把底层的 disk 进行了格式化操作，一般部署工具会将它格式化为 xfs 文件系统。
object 的存储就变成了存储一个文 rbd0.object1.file。
2.6 Ceph RBD IO 框架图
客户端写数据 osd 过程：
采用的是 librbd 的形式，使用 librbd 创建一个块设备，向这个块设备中写入数据。
在客户端本地同过调用 librados 接口，然后经过 pool，rbd，object、pg 进行层层映射,在 PG 这一层中，可以知道数据保存在哪 3 个 OSD 上，这 3 个 OSD 分为主从的关系。
客户端与 primay OSD 建立 SOCKET 通信，将要写入的数据传给 primary OSD，由 primary OSD 再将数据发送给其他 replica OSD 数据节点。
2.7 Ceph Pool 和 PG 分布情况
说明：
a. pool 是 ceph 存储数据时的逻辑分区，它起到 namespace 的作用。
b. 每个 pool 包含一定数量(可配置)的 PG。
c. PG 里的对象被映射到不同的 OSD 上。
d. pool 是分布到整个集群的。
e. pool 可以做故障隔离域，根据不同的用户场景不一进行隔离。
2.8 Ceph 数据扩容 PG 分布
场景数据迁移流程：
a. 现状 3 个 OSD, 4 个 PG
b. 扩容到 4 个 OSD, 4 个 PG
现状：
扩容后：
说明：
每个 OSD 上分布很多 PG, 并且每个 PG 会自动散落在不同的 OSD 上。如果扩容那么相应的 PG 会进行迁移到新的 OSD 上，保证 PG 数量的均衡。
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论