关于后端:Ceph简介

Ceph 简介

什么是分布式存储

与集中式存储相同，分布式存储通常采纳存储单元集群的模式，并具备在集群节点之间进行数据同步和协调的机制。分布式存储最后是由 Google 提出的，其目标是通过便宜服务器解决大规模，高并发状况下的 Web 拜访问题。

分布式存储具备几个长处：

1. 可扩展性 - 反对通过在零碎中增加或删除存储单元来程度扩大存储系统。
2. 冗余 - 在多台服务器之间存储雷同数据的复制，以实现高可用性，备份和劫难复原目标。
3. 节省成本 - 能够应用更便宜的商品服务器以低成本存储大量 数据。
4. 性能 - 在某些状况下，性能比单个服务器更好，例如，它能够将数据存储在离其使用者更近的地位，或者容许大规模并行拜访大文件。

起源

Ceph 我的项目最早起源于 Sage 就读博士期间发表的，并随后奉献给开源社区。在通过了数年的倒退之后，目前已失去泛滥云计算厂商的反对并被广泛应用。RedHat 及 OpenStack 都可与 Ceph 整合以反对虚拟机镜像的后端存储。然而在 2014 年 OpenStack 火爆的时候、Ceph 并不被很多人所承受。过后 Ceph 并不稳固（Ceph 公布的第四个版本 Dumpling v0.67），而且架构新鲜，简单，过后人们对 Ceph 在生产落地如何保障数据的平安，数据的一致性存在狐疑。

随着 OpenStack 的疾速倒退，越来越多的人应用 Ceph 作为 OpenStack 的底层共享存储，Ceph 在中国的社区也蓬勃发展起来。近两年 OpenStack 火爆度不迭当年，借助于云原生尤其是 Kubernetes 技术的倒退，作为底层存储的基石，Ceph 再次发力，为 Kubernets 有状态化业务提供了存储机制的实现。

长处

1. 高性能
   a. 摒弃了传统的集中式存储元数据寻址的计划，采纳 CRUSH 算法，数据分布平衡，并行度高。
   b. 思考了容灾域的隔离，可能实现各类负载的正本搁置规定，例如跨机房、机架感知等。
   c. 可能反对上千个存储节点的规模，反对 TB 到 PB 级的数据。
2. 高可用性
   a. 正本数能够灵便管制。
   b. 反对故障域分隔，数据强一致性。
   c. 多种故障场景主动进行修复自愈。
   d. 没有单点故障，主动治理。
3. 高可扩展性
   a. 去中心化。
   b. 扩大灵便。
   c. 随着节点减少而线性增长。
4. 个性丰盛
   a. 反对三种存储接口：块存储、文件存储、对象存储。
   b. 反对自定义接口，反对多种语言驱动。

服务架构

一个 Ceph 存储集群至多须要一个 Ceph Monitor（监视器）、Ceph Manager（管理器）和 Ceph OSD（对象存储守护过程）。

Monitors

Ceph Monitor (ceph-mon) 通过保护包含监视器表 (MonMap)、治理表(MGRMap)、OSD 表(OSDMap) 等组件状态表的保障集群失常运行。ceph-osd 相互之间协调工作时，须要从 ceph-mon 中获取这些表的信息。ceph-mon 还负责管理 ceph-osd 和客户端之间的身份验证。一个 Ceph 集群为了保障冗余和高可用性通常须要至多三个监视器，它们之间通过 Paxos 同步数据。

Managers

Ceph Manager (ceph-mgr) 负责跟踪运行时指标和 Ceph 集群的以后状态，包含存储利用率、以后性能指标、集群报警和零碎负载等。ceph-mon 和 ceph-mgr 协调配合独特维持集群稳固。高可用性通常须要至多两个管理器。

OSDS

Ceph OSD（ceph-osd）全称是 Object Storage Device，负责包含解决数据复制、复原、从新均衡在内的理论数据存储工作，并且一个 OSD 查看能够通过查看其余 OSD 的心跳的形式将其余 OSD 的异样状态上报给 MON。一个 Ceph 集群个别都有很多个 OSD。

逻辑架构

Ceph 将数据作为对象存储在逻辑存储池中。应用 CRUSH 算法，Ceph 计算出哪个归置组应该蕴含该对象，并进一步计算出哪个 Ceph OSD Daemon 应该存储该归置组。CRUSH 算法使 Ceph 存储集群可能动静扩大、从新均衡和复原。

RADOS：由自我修复、自我管理、智能存储节点组成的牢靠、自主、分布式对象存储。

LIBRADOS：Ceph 供的内部拜访的对象存储 API，容许客户端通过此 API 拜访 Ceph 集群实现文件的读写工作，反对 C、C++、Java、Python、Ruby 和 PHP 等多种语言。

用户能够基于本人的业务须要间接 LIBRADOS API 的根底上，开发本人须要的存储业务。社区在 LIBRADOS API 开发了三种成熟的存储产品：块存储、分布式文件存储系统、对象存储。

RADOSGW(Rados Gateway)

基于 LIBRADOS API 构建的兼容了 s3 和 Swift 协定的 RESTful 网关。

RBD(Rados Block Device)

基于 LIBRADOS API 构建的，应用了 Linux 内核 client 和 QEMU/KVM 驱动程序的分布式块存储设备。

CEPHFS(Ceph FileSystem)

基于 LIBRADOS API 构建的，合乎 POSIX 规范的分布式文件系统。Ceph 文件系统 须要至多指定一个 metadata 存储池和一个 data 存储池，并且 Ceph 文件系统 须要集群至多有一个 Metadata 服务。

Ceph 逻辑组件

Object

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

PG

PG 全称 Placement Grouops，是一个逻辑的概念，一个 PG 蕴含多个 OSD。引入 PG 这一层其实是为了更好的调配数据和定位数据。

CRUSH

CRUSH 是 Ceph 应用的数据分布算法，相似一致性哈希，让数据调配到预期的中央。

文件存储

不论是来自 Ceph 块设施、Ceph 对象存储、Ceph 文件系统、还是基于 librados 的自定义存储，将数据存储到 Ceph 集群上的步骤大致相同，大略能够演绎为 Ceph 客户端将数据寄存在存储对象中，存储对象通过 Ceph 集群解决被发送给了 OSD，由 OSD 将对象长久化到磁盘上。

Ceph OSD 在扁平的命名空间内把所有数据存储为对象（也就是没有目录档次）。对象蕴含一个标识符、二进制数据、和由名字 / 值对组成的元数据，元数据语义齐全取决于 Ceph 客户端。例如，CephFS 用元数据存储文件属性，如文件所有者、创立日期、最初批改日期等等。

IO 流程

1. client 创立 cluster handler。
2. client 读取配置文件。
3. client 连贯上 monitor，获取集群 map 信息。
4. client 读写 io 依据 crshmap 算法申请对应的主 osd 数据节点。
5. 主 osd 数据节点同时写入另外两个正本节点数据。
6. 期待主节点以及另外两个正本节点写完数据状态。
7. 主节点及正本节点写入状态都胜利后，返回给 client，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)。

Ceph 编排工具

Ceph 社区开发了多种编排工具，不便你疾速构建一个 Ceph 集群。
如果你想在物理机上以传统后盾服务的形式运行你的集群，能够应用基于 ansible 框架开发的 ceph-ansible。
https://docs.ceph.com/project…

如果你心愿你的集群运行在物理机上的 docker 容器中，能够应用 cephadm 工具。
https://docs.ceph.com/en/quin…

如果你心愿你的集群运行在 Kubernetes 中，运行在云服务器上，能够应用 rook-ceph。
https://rook.io/docs/rook/v1….

更多技术分享浏览我的博客：

https://thierryzhou.github.io

参考

• [1] Ceph 官网文档
• [2] 分布式存储 Ceph 介绍及原理架构分享

本文由 mdnice 多平台公布