探索Ceph：开源分布式存储系统的魅力

前言
本文档基于红帽（Red Hat）的 CL260 课程（使用红帽 Ceph 存储的云存储）撰写，旨在分享关于 Ceph 的具体内容、架构以及应用场景。该文章为学习笔记，仅为学习使用。
一、Ceph 概述
Ceph 是一个开源的分布式存储系统，由 Sage Weil 于 2004 年发起，是在圣塔克鲁兹加利福尼亚大学（University of California, Santa Cruz，UCSC）的一个研究项目，由此可见云端存储从这个概念自从很久以前就已经被提出，自从 AWS（Amazon Web Services）平台被亚马逊推出，成为专为企业提供远程存储和计算的资源平台时，“云端”就进入了计算机行业的视野。
Ceph 存储设计最初是 Sage Weil 作为 Ph.D 论文的一部分，他提出的 CRUSH（Controlled Replication Under Scalable Hashing）数据分布算法确保了数据分配和负载均衡，提高了系统的可用性和稳定性。后来不断通过企业支持、DreamHost 的持续孵化，Ceph 逐渐稳定可靠，并快速引用到了 Linux kernel 中。这天生支持扩展、无单点故障且弹性的存储概念注定改变未来的云存储走向，2017年 Ceph 实施团队被 Red Hat 收购后，成为 OpenStack 后端存储的标配。前两年 IBM（International Business Machines Corporation）将 Ceph 实施团队从 Red Hat 中提走，由 IBM 直接管理，也就是说 IBM 和 Red Hat 的存储基础架构均基于 Ceph。
Ceph 的目标是提供一个可靠、可扩展、高性能的存储解决方案，适用于各种规模的数据存储需求。它支持块存储、对象存储和文件存储三种接口，能够满足不同的应用场景。
二、Ceph 对象存储概念
Ceph 本身是对象存储，这里就不得不提到对象存储与传统存储的区别。简单来说，传统的文件系统存储不仅有一个数据，还有对数据的描述，例如：文件名、权限、大小、时间戳等。而对象存储也同样有一个数据，以及对该数据的描述，每个对象包含数据本身、元数据和一个全局唯一的标识符，使得数据可以在分布式系统中被存储和检索，或是以键值对的方式来描述，而键值对就使得扩容更加容易，更加灵活。文件系统存储对一个数据的描述是有限的，定死的，而对象存储是开放的、可扩容的。文件系统存储结构为树形结构（根目录->一级子目录->二级子目录…），对象存储为扁平式，具体体现为将所有数据放在一个存储池中，根据元数据与数据本身的关系、键值对来定义，又因为键值对存在灵活性，可以模拟出数据之间的树形存储结构，这就是 Ceph 可以提供 Ceph File System 存储结构的原因，是元数据提供对于传统文件系统存储的仿真模拟。
三、Ceph 的架构
Ceph 的架构设计使其能够处理海量数据，同时保证数据的可靠性和性能。以下是 Ceph 的主要组件：
RADOS（Reliable Autonomic Distributed Object Store）：
Ceph 的核心存储引擎，负责管理数据的存储、复制和分布。Reliable（可信赖的）体现在Ceph 存储结构含有三个副本。Autonomic（自主的）体现在可进行自我愈合，三个副本其中一个损坏可通过剩余两个副本进行自我恢复，将恢复的数据存放在一个新的硬盘中，全程无需人工介入。 Distributed（分布式的）三个副本分布在三个存储节点，因为 RADOS 默认以存储节点作为故障域。一个大文件也会拆分成多个小的对象文件均匀分布在存储集群中的所有集群上，用户调用时再从所有的存储集群中将被调用的文件的所有的小的对象文件找出来拼成一个完整的文件供用户使用。读与写都是多个存储节点同时进行，并发 IO，速度快，数据吞吐量大，但缺点是延迟可能较高，可能来源于网络延迟或数据的拆分与拼装等。

图 3.1 RADOS架构图

MON（Monitor）
Monitor 提供整个集群的映射关系表，整个架构、逻辑关系一切信息都存放在此处，Monitor 通常一个存储集群建议部署奇数个 Monitor ，一般来说三个，因为奇数个 Monitor 可以形成仲裁机制，在生产环境下随时间推移，OSD 每次进行对数据进行 IO 后会向其最近的 Monitor 汇报工作，然后 Monitor 会对这些数据关系映射进行版本的更新，当 Monitor 之间的版本出现不一致时会触发仲裁机制，通过少数服从多数的仲裁机制统一 Monitor 之间的版本以维持整个存储系统的健壮性。

OSD（Object Storage Daemon）
每个硬盘上都有一个 OSD ，负责实际存储数据的进程、IO服务等，每个 OSD 管理一个或多个磁盘。在2017年时 OSD 通过文件系统将数据写入到硬盘中，效率较低。现在则直接将数据写入硬盘中。

RBD（RADOS Block Device）
RDB 是 Ceph 提供的一种块存储服务，允许用户像用本地硬盘一样使用 Ceph 集群中的存储资源。RBD 将 Ceph 集群的存储空间虚拟化为块设备，可以被挂载到物理服务器或虚拟机中，用于存储数据。RBD 可以被Linux、KVM、OpenStack、Kubernetes 等多种平台和工具集成，广泛应用于虚拟化和云计算环境。

实例
在 Linux 系统中可以通过一下命令创建 RDB 设备并挂载使用：

#创建一个大小为1G的 RDB 镜像
rbd create [pool name]/[image name] --size 1024

#映射RBD镜像到本地设备
rbd map [pool name]/[image name]

# 格式化并挂载
mkfs.ext4 /dev/rbd/[pool name]/[image name]
mount /dev/rbd/[pool name]/[image name] /mnt
mount -a
#注：此方式为非永久挂载

RBD 是 Ceph 中非常重要的块存储服务，它将分布式存储资源虚拟化为块设备，提供高性能、高可用性和灵活的存储解决方案，广泛应用于虚拟化、云计算和容器化环境中。

图 3.2 三种存储方式的结构

Logical groups（逻辑组）
Logical container 将 object 以特定的分类进行分组，分类可以是文件类型、磁盘类型等，Ceph 称之为存储池。
如图3.3所示，其中两个不同的存储池一个名为 FLOWERS ，一个名为 VEGETABLES ，属于 FLOWERS 类型的对象文件则存储在 FLOWERS 存储池中，属于 VEGETABLES 类型的对象文件存储在 VEGETABLES 存储池中，有点像目录的概念，但是这是一种逻辑概念。不同的存储池被分配在不同的 OSD 所对应的硬盘上。

图 3.3 两种不同的存储池

四、CRUSH算法(Controlled Replication Under Scalable Hashing)
“ CRUSH 算法，Ceph storage cluster 皇冠上的宝石 ”
数据在每次被存储时，究竟是谁来决定每一个对象文件到底应该被存放在哪个 OSD 上？CRUSH 算法的决策会给出最满意的答案。
也许通过具体的例子讲解会更为生动：
现有10000个对象文件需要被存放在一个存储池中，一个存储池又会被分成数个 PG（placement groups），假设该存储池中有32个 PG ，每一个 PG 会对应3个 OSD ，其中一个 OSD 为 primary OSD ，其余两个为 secondary OSD ，这就是Ceph的三副本特性。这三个 OSD 必须分别来自不同的故障域，也就是主机。primary OSD 主要负责 IO ，在数据被存储后可通过 Monitor 中的映射关系所见。primary OSD 写入完成后会向其余两个 secondary OSD 都写入相同的数据用以备份。通常在生产环境下为节约成本 primary OSD 使用固态硬盘而 secondary OSD 使用机械硬盘。在 primary OSD 损坏后会从其余两个secondary OSD 中选一个出来提权成为新的 primary OSD ，并且 Ceph 将 PG 重新映射到不同的 OSD ，同时再寻找一个新的 OSD 作为缺失的 secondary OSD 。这是 CRUSH 算法的用处所在。
CRUSH 算法的核心是对每一个对象文件的对象名进行哈希处理，所得的数字除以 PG 的数量，得出的余数为一个十六进制数，该十六进制数所对应的十进制数为该对象文件被存进的 OSD 的编号。再加上该对象文件所在的存储池的 ID 就形成了该对象文件的唯一标识。如果一个对象文件被哈希处理后所得的十六进制数为 AB ，所在存储池的 ID 为 C ，则该对象文件的唯一标识为 C.AB 。再通过 Monitor 服务中的 CRUSH 映射表可知该对象文件所在的三个 OSD 所对应的硬盘位置，下次用户在调取该对象文件的数据时客户端直接通过 Monitor 中的映射表找到该对象文件的存储位置直接读取。因为采用哈希算法，故该查找方法计算量低，对 CPU 基本无占用。

图 4.1 CRUSH算法图

五、总结
Ceph，这个在存储界堪称“瑞士军刀”的技术，凭借其分布式、高可靠和可扩展的特性，成为了存储领域的明星。虽然它有一定的复杂性，但它的灵活性和可靠性使其在存储领域独树一帜。无论是企业还是开发者，Ceph都是一个值得信赖的存储解决方案。