Ceph 存储介绍
文章目录
- 一、Ceph 简介
- 二、Ceph 特点
- 三、Ceph 应用场景
- 四、Ceph 核心组件
- 五、Ceph 存储系统的逻辑层次结构
- 六、RADOS 的系统逻辑结构
- 七、Ceph 数据存储过程
- 八、Ceph IO 流程及数据分布
-
- 1. 正常 IO 流程图
- 2. 新主 IO 流程图
- 九、Ceph Pool 和 PG 分布情况
一、Ceph 简介
ceph 是一种统一的分布式文件系统，具有优秀的性能、高可用性和可扩展性。ceph 的统一体现在可以提供文件系统、块存储和对象存储，分布式体现在可以动态扩展。在国内一些公司的云环境中，通常会采用 ceph 作为 openstack 的唯一后端存储来提高数据转发效率。
- 官网：https://ceph.com/
- 官方文档：http://docs.ceph.com/docs/master/#
二、Ceph 特点
高性能：
- 摒弃了传统的集中式存储元数据寻址的方案，采用 CRUSH 算法，数据分布均衡，并行度高。
- 考虑了容灾域的隔离，能够实现各类负载的副本放置规则，例如跨机房、机架、感知等。
- 能够支持上千个存储节点的规模，支持 TB 到 PB 级的数据。
高可用性：
- 副本数可以灵活控制。
- 支持故障域分隔，数据强一致性。
- 多种故障场景自动进行修复自愈。
- 没有单点故障，自动管理。
高可扩展性：
- 去中心化。
- 扩展灵活。
- 随着节点增加而线性增长。
特性丰富：
- 支持三种存储接口：块存储、文件存储、对象存储。
- 支持自定义接口，支持多种语言驱动。
三、Ceph 应用场景
ceph 可以提供对象存储、块设备存储和文件系统服务，其对象存储可以对接网盘（owncloud）应用业务等；其块设备存储可以对接（Iaas）。当前主流的 Iaas 软件运行平台有：OpenStack、CloudStack、Zstack、Eucalyptus、kvm。
ceph 提供三大功能：
- 对象存储（RADOSGW）：提供 RESTful 接口，也提供多种编程语言绑定。兼容 S3、Swift。
- 块存储（RDB）：由 RBD 提供，可以直接作为磁盘挂载，内置了容灾机制。
- 文件系统（CephFS）：提供 POSIX 兼容的网络文件系统 CephFS，专注于高性能、大容量存储。
什么是块存储/对象存储/文件系统存储？
对象存储：
也就是通常意义的键值存储，其接口就是简单的 GET、PUT、DEL 和其他扩展，代表主要有 Swift 、S3、Gluster 等。
块存储：
这种接口通常以 QEMU Driver 或者 Kernel Module 的方式存在，这种接口需要实现 Linux 的 Block Device 的接口或者 QEMU 提供的 Block Driver 接口，如 Sheepdog，AWS 的 EBS，青云的云硬盘和阿里云的盘古系统，还有 Ceph 的 RBD（RBD 是 Ceph 面向块存储的接口）。在常见的存储中 DAS、SAN 提供的也是块存储。
文件系统存储：
通常意义是支持 POSIX 接口，它跟传统的文件系统如 Ext4 是一个类型的，但区别在于分布式存储提供了并行化的能力，如 Ceph 的 CephFS（CephFS 是 Ceph 面向文件存储的接口），但是有时候又会把 GlusterFS，HDFS 这种非 POSIX 接口的类文件存储接口归入此类。当然 NFS、NAS 也是属于文件系统存储。
四、Ceph 核心组件
Monitors
监视器，维护集群状态的多种映射，同时提供认证和日志记录服务，包括有关 monitor 节点端到端的信息，其中包括 Ceph 集群 ID，监控主机名和 IP 以及端口。并且存储当前版本信息以及最新更改信息，通过 ceph mon dump 查看 monitor map。
MDS（Metadata Server）
Ceph 元数据，主要保存的是 Ceph 文件系统的元数据。注意：ceph 的块存储和 ceph 对象存储都不需要 MDS。
OSD
即对象存储守护程序，但是它并非针对对象存储。是物理磁盘驱动器，将数据以对象的形式存储到集群中的每个节点的物理磁盘上。OSD 负责存储数据、处理数据复制、恢复、回（Backfilling）、再平衡。完成存储数据的工作绝大多数是由 OSD daemon 进程实现。在构建 Ceph OSD 的时候，建议采用 SSD 磁盘以及 xfs 文件系统来格式化分区。此外 OSD 还对其它 OSD 进行心跳检测，检测结果汇报给 Monitor。
RADOS
Reliable Autonomic Distributed Object Store。RADOS 是 ceph 存储集群的基础。在 ceph 中，所有数据都以对象的形式存储，并且无论什么数据类型，RADOS 对象存储都将负责保存这些对象。RADOS 层可以确保数据始终保持一致。
librados
librados 库，为应用程度提供访问接口。同时也为块存储、对象存储、文件系统提供原生的接口。
RADOSGW
网关接口，提供对象存储服务。它使用 librgw 和 librados 来实现允许应用程序与 Ceph 对象存储建立连接。并且提供 S3 和 Swift 兼容的 RESTful API 接口。
RBD
块设备，它能够自动精简配置并可调整大小，而且将数据分散存储在多个 OSD 上。
CephFS
Ceph 文件系统，与 POSIX 兼容的文件系统，基于 librados 封装原生接口。
五、Ceph 存储系统的逻辑层次结构
六、RADOS 的系统逻辑结构
七、Ceph 数据存储过程
无论使用哪种存储方式（对象、块、文件系统），存储的数据都会被切分成 Objects。Objects size 大小可以由管理员调整，通常为 2M 或 4M。每个对象都会有一个唯一的 OID，由 ino 与 ono 生成，虽然这些名词看上去很复杂，其实相当简单。
- ino：即是文件的 File ID，用于在全局唯一标识每一个文件。
- ono：则是分片的编号。
比如：一个文件 FileID 为 A，它被切成了两个对象，一个对象编号 0，另一个编号 1，那么这两个文件的 oid 则为 A0 与 A1。
File：此处的 file 就是用户需要存储或者访问的文件。对于一个基于 Ceph 开发的对象存储应用而言，这个 file 也就对应于应用中的 “对象”，也就是用户直接操作的 “对象”。
Ojbect：此处的 object 是 RADOS 所看到的 “对象”。Object 与上面提到的 file 的区别是，object 的最大 size 由 RADOS 限定（通常为 2MB 或 4MB），以便实现底层存储的组织管理。因此，当上层应用向 RADOS 存入 size 很大的 file 时，需要将 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 系统的设计发挥其应有的优势。
基于上述定义，便可以对寻址流程进行解释了。具体而言，Ceph 中的寻址至少要经历以下三次映射：
- File -》object 映射
- Object -》PG映射，hash(oid) & mask -》pgid
- PG -》OSD 映射，CRUSH 算法
CRUSH（Controlled Replication Under Scalable Hashing）：通过计算系统中数据应该被写入或读出的位置。CRUSH 能够感知基础架构，能够理解基础设施各个部件之间的关系。并且 CRUSH 保存数据的多个副本，这样即使一个故障域的几个组件都出现故障，数据依然可用。CRUSH 使得 ceph 实现了自我管理和自我修复。
RADOS 分布式存储相较于传统分布式存储的优势在于：
-
将文件映射到 object 后，利用 Cluster Map 通过 CRUSH 计算而不是查找表方式定位文件数据存储到存储设备的具体位置。优化了传统文件到块的映射和 Block MAP 的管理。
-
RADOS 充分利用 OSD 的智能特点，将部分任务授权给 OSD，最大程度地实现可扩展。
八、Ceph IO 流程及数据分布
1. 正常 IO 流程图
步骤：
client 创建 cluster handler。
client 读取配置文件。
client 连接上 monitor，获取集群 map 信息。
client 读写 io 根据 crshmap 算法请求对应的主 osd 数据节点。
主 osd 数据节点同时写入另外两个副本节点数据。
等待主节点以及另外两个副本节点写完数据状态。
主节点及副本节点写入状态都成功后，返回给 client，io 写入完成。
2. 新主 IO 流程图
说明：如果新加入的 OSD1 取代了原有的 OSD4 成为 Primary OSD，由于 OSD1 上未创建 PG，不存在数据，那么 PG 上的 I/O 无法进行，怎样工作的呢？
新主 IO 流程步骤：
client 连接 monitor 获取集群 map 信息。
同时新主 osd1 由于没有 pg 数据会主动上报 monitor 告知让 osd2 临时接替为主。
临时主 osd2 会把数据全量同步给 osd1。
client IO 读写直接连接临时主 osd2 进行读写。
osd2 收到读写 io，同时写入另外两副本节点。
等待 osd2 以及另外两副本写入成功。
osd2 三份数据都写入成功返回给 client, 此时 client io 读写完毕。
如果 osd1 数据同步完毕，临时主 osd2 会交出主角色。
osd1 成为主节点，osd2 变成副本。
九、Ceph Pool 和 PG 分布情况
pool：是 ceph 存储数据时的逻辑分区，它起到 namespace 的作用。每个 pool 包含一定数量的 PG。PG 里的对象被映射到不同的 Object 上。pool 是分布到整个集群的。pool 可以做故障隔离域，根据不同的用户场景不统一进行隔离。
参考：
玩转 Ceph 的正确姿势
Ceph 源码解析：CRUSH 算法
我所了解的各公司使用的 Ceph 存储集群 (携程、乐视、有云、宝德云、联通等)