一、Ceph支持文件系统服务、对象存储、块存储

文件存储：

文件系统存储是实现持久存储数据的最普遍的方法，一些常用的文件系统包括NFS和NTFS等。在云平台中，虚机或容器可以通过LVM的方式加载存储，这种普通主机持久性引起的主要问题是，它完全破坏了容器的可移植性，存储不易实现迁移。容器友好型的文件存储系统，通常需要通过跨多个服务器分布文件系统来实现。

文件存储主要操作对象是文件和文件夹。以 NFS 为例，文件相关的接口包括：LOOKUP/ACCESS/READ/WRITE/CREATE/REMOVE/RENAME 等等，文件夹相关的接口包括：MKDIR/RMDIR/READDIR 等等。同时也会有 FSSTAT/FSINFO 等接口用于提供文件系统级别的信息。POSIX，SAMBA 等也是文件存储协议。协议更注重接口的灵活，以及访问权限控制。

对象存储：

对象存储与文件系统存储或块存储不同。它不是通过块地址或文件名引用数据，而是将数据存储为对象并由对象ID引用。对象存储的优点在于它具有很强的伸缩性，并且在将属性与对象相关联方面具有高度的灵活性。由于依赖于REST调用，对象存储可能更复杂。

对象存储主要操作对象是对象（Object）。以 S3 为例，主要接口有PUT/GET/DELETE 等。和文件和对象存储相比，没有随机读写的接口。和文件存储相比，没有目录树的概念。协议更注重简洁。

块存储：

块存储存中的数据块仅通过其地址识别。块没有文件名，也没有自己的元数据。只有当块与其他块组合形成完整的数据块时，它们才具有意义。

块存储主要操作对象是磁盘，以 SCSI 为例，主要接口有 Read/Write/Read Capacity/Inquiry 等等。FC，iSCSI也是块存储协议。和文件存储相比，没有文件和目录树的概念，一般协议也不会定义磁盘的创建和删除操作。协议更注重传输控制。

Ceph是一个可靠地、自动重均衡、自动恢复的分布式存储系统，可以支持对象存储、块设备存储和文件系统服务。

1. 最底层是RADOS，RADOS自身是一个完整的分布式对象存储系统，Ceph的高可靠、高可拓展、高性能、高自动化都是由这一层来提供的，用户数据的存储最终也都是通过这一层来进行存储的，RADOS是Ceph的核心。

2. 基于RADOS层的上一层是LIBRADOS，LIBRADOS是一个库，它允许应用程序通过访问该库来与RADOS系统进行交互，支持多种编程语言，比如C、C++、Python等。

3. 基于LIBRADOS层开发的又可以看到有三层，分别是RADOSGW、RBD和CEPH FS。

• RADOSGW：RADOSGW是一套基于当前流行的RESTFUL协议的网关，并且兼容S3和Swift。
• RBD：RBD通过Linux内核客户端和QEMU/KVM驱动来提供一个分布式的块设备。
• CEPH FS：CEPH FS通过Linux内核客户端和FUSE来提供一个兼容POSIX的文件系统。

二、Ceph数据存储架构及流程

1. 几个重要组件及功能：

前面我们已经大概知道Ceph可以支持3种数据管理的方式，那么Ceph又是如何管理数据的呢？如上图所示，大的架构上可以一分为二: 访问控制及数据存储，访问控制是数据IO的访问方式及流程定义，数据存储则涉及以下的几个重要组件：OSD、MON、MDS。

MON：

Ceph Monitor负责监视Ceph集群，维护Ceph集群的健康状态，同时维护着Ceph集群中的各种Map图，比如OSD Map、Monitor Map、PG Map和CRUSH Map，这些Map统称为Cluster Map，Cluster Map是RADOS的关键数据结构，管理集群中的所有成员、关系、属性等信息以及数据的分发，比如当用户需要存储数据到Ceph集群时，OSD需要先通过Monitor获取最新的Map图，然后根据Map图和object id等计算出数据最终存储的位置。

OSD：

OSD的英文全称是Object Storage Device，它的主要功能是存储数据、复制数据、平衡数据、恢复数据等，与其它OSD间进行心跳检查等，并将一些变化情况上报给Ceph Monitor。一般情况下一块硬盘对应一个OSD，由OSD来对硬盘存储进行管理，当然一个分区也可以成为一个OSD。

Ceph OSD的架构实现由物理磁盘驱动器、Linux文件系统和Ceph OSD服务组成，伴随OSD的还有一个概念叫做Journal盘，Journal盘都是采用SSD，一般写数据到Ceph集群时，都是先将数据写入到Journal盘中，然后每隔一段时间比如5秒再将Journal盘中的数据刷新到文件系统中。

MDS：

全称是Ceph MetaData Server，主要保存的文件系统服务的元数据，但对象存储和块存储设备是不需要使用该服务的。

2. Ceph 数据管理结构：

• pool是ceph存储数据时的逻辑分区，它起到namespace的作用。
• 每个pool包含一定数量(可配置)的PG。

*pg的全称是placement group（放置组），是用于放置object的一个载体，pg的创建是在创建ceph存储池的时候指定的，同时跟指定的副本数也有关系，比如是3副本的则会有3个相同的pg存在于3个不同的osd上，pg其实在osd的存在形式就是一个目录。

*pgp: pg是用来存放object的，pgp相当于是pg存放osd的一种排列组合。比如有3个osd：osd.1、osd.2、osd.3，副本数是2，如果pgp的数目为1，那么pg存放的osd组合就只有一种，可能是[osd.1,osd.2]，那么所有的pg主从副本分别存放到osd.1和osd.2，如果pgp设为2，那么其osd组合可以两种，可能是[osd.1,osd.2]和[osd.1,osd.3]。

• PG里的对象被映射到不同的OSD上。

3. OSD读取和写入流程

1. client 读写io 根据crushmap 算法请求对应的主osd数据节点。
2. 主osd数据节点读取数据，如写入则：同时写入另外两个副本节点数据。
3. 如写入则：等待主节点以及另外两个副本节点写完数据状态。
4. 如写入则：主节点及副本节点写入状态都成功后，返回给client，io写入完成。

三、Ceph把一份数据存到一群 Server 中？

Ceph中数据会分为若干个Object，这些Object会存储到不同的PG中（每个存储池的PG数目是配置项设定的），PG按副本配置又存储到不同的OSD中。所以这个过程中会涉及2个选择：

• 选择1：Object选择PG?
• 选择2：PG选择OSD?

如上图所示：

选择1是通过HASH算法解决；

选择2是通过Crush算法解决；

注意一下：选择2不能通过Hash解决，主要是多副本（不是1对1，是1对多输出）以及OSD节点异常、动态扩容的考虑。

*crush算法有空可以再另文讲解。

参考：

1. 《Ceph基础知识和基础架构认识》https://www.cnblogs.com/luohaixian/p/8087591.html
2. 《块存储、对象存储和文件系统 它们对容器而言意味着什么？》https://blog.csdn.net/RancherLabs/article/details/76128497
3. 《理解 OpenStack + Ceph》https://www.cnblogs.com/sammyliu/p/4804037.html
4. 《Ceph:针对云工作负载性能测试及优化浅析》http://cloud.chinabyte.com/vertical/473/13490973.shtml
5. 《 大话 Ceph 》 之 CRUSH 那点事儿 https://segmentfault.com/p/1210000012193316