Ceph项目最早起源于Sage就读博士期间的作业（最早的成果于2004年宣告），并随后贡献给开源社区。在通过了数年的发展之后，现在已得到众多云计算厂商的支撑并被广泛应用,也是目前流行的开源的分布式存储，之后红帽 1.75 亿美元收购 Ceph，2022年10月10月4日，IBM 10月4号宣布将Ceph及红帽所有存储产品、团队将转入IBM。
Ceph之所以如此这么受欢迎,是因为Ceph 独一无二地用统一的系统提供了对象、块、和文件存储功能，Ceph 可提供极大的伸缩性——供成千用户访问 PB 乃至 EB 级的数据。 CEPH节点以普通硬件和智能守护进程作为支撑点， CEPH存储集群组织起了大量节点，它们之间靠相互通讯来复制数据、并动态地重分布数据。
Ceph的整体架构
Ceph的整体采用分层架构，其最底层是一个集群，也就是RADOS集群。该集群实现了分布式的基本特征，比如数据可靠性保护（副本或者纠删码）、分布式一致性和故障检测与恢复等等。总之，通过RADOS集群，为上层提供了一个统一视图的，高可靠的分布式存储集群。
在RADOS集群之上，Ceph构建了块存储、文件存储和对象存储等存储形态。由于RADOS集群本身是以对象为粒度进行数据存储的，因此上述三种存储形态，在最终存储数据的时候都划分为对象，这部分内容我们后面详述。
同时，Ceph集群为客户端提供了丰富的访问形式，比如对于块存储可以通过动态库或者块设备的方式访问。所谓动态库，就是Ceph提供了一个API，用户通过该API可以访问块存储系统。比如用于虚拟化常见的qemu对Ceph的访问就是通过动态库（librbd）的方式访问的。
Ceph的块存储
首先介绍一下底层的RADOS集群，集群从组建方面分为OSD、MON和客户端三类组件。其中OSD组件负责管理一个磁盘；MON组件形成一个集群，负责管理元数据；客户端则实现对集群的访问。对于RADOS来说，其客户端通常是一个动态库，也就是librados库。上层服务（块、对象和文件）通常依赖该动态库实现。
Ceph的块存储是基于对象存储来实现的，实现原理也非常简单。从我们普通用户的角度来看，块设备其实就是一个线性的存储空间，可以理解为一个大数组。由于是线性空间，其实这个块设备在集群层面完全可以以对象的方式存储。最简单的方式就是一个块设备对应一个对象。
但是如果一个块设备对应一个对象，那么会出现数据过于集中的情况。因此，在Ceph中将块设备切割为4MB大小的对象，并且将块数据分散在这些对象中。Ceph的处理方式也非常简单，对象名称通过块设备名称和LBA组合的方式生成，这样就可以保证对象名称的唯一性。而当用户访问块设备是，根据访问的偏移就可以定位到具体的对象。
当然，上述是简单介绍了一下基本原理。其实Ceph的块设备有很多参数，比如分割对象大小，条带化等等。可以根据业务模式调整这些参数，从而提升块存储的性能。
Ceph的文件系统
文件系统整体架构并没有太大的差异，其底层依赖的还是RADOS集群的对象存储。文件系统最大的特点在于对维护文件系统的目录结构，因此在Ceph中通过一个元数据集群（MDS）实现对文件元数据的管理。
为了比较清楚的理解文件系统的架构，我们给出如图所示的架构图。这里重点强调MDS集群的作用。当客户端访问文件系统的时候，需要先与MDS交互。以写数据为例，首先需要与MDS交互确认文件存在，并且获得访问权。
当然，如果文件不存在，则需要在MDS创建文件。同时再MDS上还维护这文件的元数据，包括文件创建时间、大小和扩展属性等等内容。
Ceph设计的时候是支持MDS多活的，并且考虑到由于热点的问题，可以实现多个MDS管理的元数据的动态迁移，这个概念称为动态子树。
所谓动态子树就是将文件系统的目录分解为几个子目录，然后根据热点情况进行动态调整。动态调整就是在多个MDS之间进行迁移。
为了方便用户使用，Cephfs在客户端有多中实现形态。最常见的是在Linux内核中实现了一个客户端文件系统。该文件系统类似NFS的客户端文件系统，其位于VFS之下。普通用户可以通过挂载（mount）的方式实现对Ceph文件系统的挂载，然后就像访问本地文件系统一样访问Ceph文件系统。
除此之外，用户该可以通过动态库或者fuse实现的文件系统对Ceph文件系统进行访问。
Ceph的对象存储
虽然RADOS本身提供的是对象存储服务，但是其提供的只是基础的对象访问能力，而且只能通过Ceph客户端访问。为了提供类似AWS的S3的特性和Swift对象存储的特性，Ceph实现了一个对象存储网关。
对象存储网关（Rados Gateway，简称RGW）实际上实现的是一个接口协议的转换。通过RGW我们在客户端可以通过通用的http协议访问对象存储，而且在存储网关中实现了很多特性。比如对象的属性、ACL和多租户等等。
想了解更多，请关注我：
