Ceph的整体架构介绍，这篇文章带入Ceph的大门
Ceph可以说是目前最为流行的分布式存储，没有之一。虽然目前开源分布式存储系统很多，但没有任何一个开源分布式存储能有Ceph这样流行和受欢迎。
本栏作者以为，Ceph之所以如此流行，其主要原因有三：
Ceph本身是一个统一存储，支持块、对象和文件等所有存储形态
开源，免费
对开源云计算项目的强力支持，例如OpenStack
好了，废话少说，我们还是从整体上认识一下Ceph吧，看看Ceph是怎样一种分布式存储。
1Ceph的整体架构
Ceph的整体采用分层架构，其最底层是一个集群，也就是RADOS集群。该集群实现了分布式的基本特征，比如数据可靠性保护（副本或者纠删码）、分布式一致性和故障检测与恢复等等。总之，通过RADOS集群，为上层提供了一个统一视图的，高可靠的分布式存储集群。
在RADOS集群之上，Ceph构建了块存储、文件存储和对象存储等存储形态。由于RADOS集群本身是以对象为粒度进行数据存储的，因此上述三种存储形态，在最终存储数据的时候都划分为对象，这部分内容我们后面详述。
同时，Ceph集群为客户端提供了丰富的访问形式，比如对于块存储可以通过动态库或者块设备的方式访问。所谓动态库，就是Ceph提供了一个API，用户通过该API可以访问块存储系统。比如用于虚拟化常见的qemu对Ceph的访问就是通过动态库（librbd）的方式访问的。
2Ceph的块存储
首先介绍一下底层的RADOS集群，集群从组建方面分为OSD、MON和客户端三类组件。其中OSD组件负责管理一个磁盘；MON组件形成一个集群，负责管理元数据；客户端则实现对集群的访问。对于RADOS来说，其客户端通常是一个动态库，也就是librados库。上层服务（块、对象和文件）通常依赖该动态库实现。
Ceph的块存储是基于对象存储来实现的，实现原理也非常简单。从我们普通用户的角度来看，块设备其实就是一个线性的存储空间，可以理解为一个大数组。由于是线性空间，其实这个块设备在集群层面完全可以以对象的方式存储。最简单的方式就是一个块设备对应一个对象。
但是如果一个块设备对应一个对象，那么会出现数据过于集中的情况。因此，在Ceph中将块设备切割为4MB大小的对象，并且将块数据分散在这些对象中。Ceph的处理方式也非常简单，对象名称通过块设备名称和LBA组合的方式生成，这样就可以保证对象名称的唯一性。而当用户访问块设备，根据访问的偏移就可以定位到具体的对象。
当然，上述是简单介绍了一下基本原理。其实Ceph的块设备有很多参数，比如分割对象大小，条带化等等。可以根据业务模式调整这些参数，从而提升块存储的性能。
3Ceph的文件系统
文件系统整体架构并没有太大的差异，其底层依赖的还是RADOS集群的对象存储。文件系统最大的特点在于对维护文件系统的目录结构，因此在Ceph中通过一个元数据集群（MDS）实现对文件元数据的管理。
为了比较清楚的理解文件系统的架构，我们给出如图所示的架构图。这里重点强调MDS集群的作用。当客户端访问文件系统的时候，需要先与MDS交互。以写数据为例，首先需要与MDS交互确认文件存在，并且获得访问权。
当然，如果文件不存在，则需要在MDS创建文件。同时在MDS上还维护这文件的元数据，包括文件创建时间、大小和扩展属性等等内容。
Ceph设计的时候是支持MDS多活的，并且考虑到由于热点的问题，可以实现多个MDS管理的元数据的动态迁移，这个概念称为动态子树。
所谓动态子树就是将文件系统的目录分解为几个子目录，然后根据热点情况进行动态调整。动态调整就是在多个MDS之间进行迁移。
为了方便用户使用，Cephfs在客户端有多种实现形态。最常见的是在Linux内核中实现了一个客户端文件系统。该文件系统类似NFS的客户端文件系统，其位于VFS之下。普通用户可以通过挂载（mount）的方式实现对Ceph文件系统的挂载，然后就像访问本地文件系统一样访问Ceph文件系统。
除此之外，用户还可以通过动态库或者fuse实现的文件系统对Ceph文件系统进行访问。
4Ceph的对象存储
虽然RADOS本身提供的是对象存储服务，但是其提供的只是基础的对象访问能力，而且只能通过Ceph客户端访问。为了提供类似AWS的S3的特性和Swift对象存储的特性，Ceph实现了一个对象存储网关。
对象存储网关（Rados Gateway，简称RGW）实际上实现的是一个接口协议的转换。通过RGW我们在客户端可以通过通用的http协议访问对象存储，而且在存储网关中实现了很多特性。比如对象的属性、ACL和多租户等等。
今天我们从整体上介绍Ceph存储系统及常见的存储形态，更多内容敬请关注本号，我们会更加详细的分析Ceph系统架构及具体实现细节。
如果大家对文件系统感兴趣，可以阅读一下本号的拙作《文件系统技术内幕》。