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

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

存储发展史

企业中应用存储依照其性能，应用场景，始终在继续倒退和迭代，大体上能够分为四个阶段：

•DAS：Direct Attached Storage，即直连存储，第一代存储系统，通过 SCSI 总线扩大至一个内部的存储，磁带整列，作为服务器扩大的一部分；
•NAS：Network Attached Storage，即网络附加存储，通过网络协议如 NFS 近程获取后端文件服务器共享的存储空间，将文件存储独自分离出来；
•SAN：Storage Area Network，即存储区域网络，分为 IP-SAN 和 FC-SAN，即通过 TCP/IP 协定和 FC(Fiber Channel)光纤协定连贯到存储服务器；
•Object Storage：即对象存储，随着大数据的倒退，越来越多的图片，视频，音频动态文件存储需要，动仄 PB 以上的存储空间，需有限扩大。

存储的倒退，依据不同的阶段诞生了不同的存储解决方案，每一种存储都有它过后的历史诞生的环境以及利用场景，解决的问题和优缺点。

区别如下：

DAS 直连存储服务器应用 SCSI 或 FC 协定连贯到存储阵列、通过 SCSI 总线和 FC 光纤协定类型进行数据传输；例如一块有空间大小的裸磁盘：/dev/sdb。DAS 存储尽管组网简略、老本低廉然而可扩展性无限、无奈多主机实现共享、目前曾经很少应用了。

NAS 网络存储服务器应用 TCP 网络协议连贯至文件共享存储、常见的有 NFS、CIFS 协定等；通过网络的形式映射存储中的一个目录到指标主机，如 /data。NAS 网络存储应用简略，通过 IP 协定实现相互拜访，多台主机能够同时共享同一个存储。然而 NAS 网络存储的性能无限，可靠性不是很高。

SAN 存储区域网络服务器应用一个存储区域网络 IP 或 FC 连贯到存储阵列、常见的 SAN 协定类型有 IP-SAN 和 FC-SAN。SAN 存储区域网络的性能十分好、可扩展性强；然而老本特地高、尤其是 FC 存储网络：因为须要用到 HBA 卡、FC 交换机和反对 FC 接口的存储。

Object Storage 对象存储通过网络应用 API 拜访一个有限扩大的分布式存储系统、兼容于 S3 格调、原生 PUT/GET 等协定类型。表现形式就是能够有限应用存储空间，通过 PUT/GET 有限上传和下载。可扩展性极强、应用简略，然而只应用于动态不可编辑文件，无奈为服务器提供块级别存储。

综上、企业中不同场景应用的存储，应用表现形式无非是这三种：磁盘（块存储设备），挂载至目录像本地文件一样应用（文件共享存储），通过 API 向存储系统中上传 PUT 和下载 GET 文件（对象存储）。

什么是 Ceph？

接下来咱们要讲讲 Ceph，那么到底什么是 Ceph 呢？Ceph 可能提供企业中三种常见的存储需要：块存储、文件存储和对象存储，正如 Ceph 官网所定义的一样“Ceph uniquely delivers object, block, and file storage in one unified system.”，Ceph 在一个对立的存储系统中同时提供了对象存储、块存储和文件存储，即 Ceph 是一个对立存储，可能将企业企业中的三种存储需要对立汇总到一个存储系统中，并提供分布式、横向扩大，高度可靠性的存储系统，Ceph 存储提供的三大存储接口：

上图详见官网文档：http://docs.ceph.org.cn/

1、CEPH OBJECT STORE 对象存储，蕴含性能，个性如下：

•RESTful Interface RESTful 格调接口；
•S3- and Swift-compliant APIs 提供兼容于 S3 和 Swfit 格调 API；
•S3-style subdomains S3 格调的目录格调；
•Unified S3/Swift namespace 对立扁平的 S3/Swift 命名空间，即所有的对象寄存在同一个立体上；
•User management 提供用户治理认证接入；
•Usage tracking 应用状况追踪；
•Striped objects 对象切割，将一个大文件切割为多个小文件（objects）；
•Cloud solution integration 云计算解决方案即成，能够与 Swfit 对象存储即成；
•Multi-site deployment 多站点部署，保障可靠性；
•Multi-site replication 多站点复制，提供容灾计划。

2、CEPH BLOCK DEVICE 块存储，蕴含性能，个性如下：

•Thin-provisioned 瘦调配，即先调配特定存储大小，随着应用理论应用空间的增长而占用存储空间，防止空间占用；
•Images up to 16 exabytes 耽误现象最大能反对 16EB；
•Configurable striping 可配置的切片，默认是 4M；
•In-memory caching 内存缓存；
•Snapshots 反对快照，将过后某个状态记录下载；
•Copy-on-write cloning Copy-on-write 克隆复制性能，即制作某个镜像实现疾速克隆，子镜像依赖于母镜像；
•Kernel driver support 内核驱动反对，即 rbd 内核模块；
•KVM/libvirt support 反对 KVM/libvirt，实现与云平台如 openstack，cloudstack 集成的根底；
•Back-end for cloud solutions 云计算多后端解决方案，即为 openstack，kubernetes 提供后端存储；
•Incremental backup 增量备份；
•Disaster recovery (multisite asynchronous replication) 劫难复原，通过多站点异步复制，实现数据镜像拷贝。

3、CEPH FILE SYSTEM 文件存储，蕴含性能，个性如下：

•POSIX-compliant semantics POSIX 格调接口；
•Separates metadata from data 元数据 metadata 和数据 data 离开存储；
•Dynamic rebalancing 动态数据平衡；
•Subdirectory snapshots 子目录快照；
•Configurable striping 可配置切割大小；
•Kernel driver support 内核驱动反对，即 CephFS；
•FUSE support 反对 FUSE 格调；
•NFS/CIFS deployable 反对 NFS/CIFS 模式部署；
•Use with Hadoop (replace HDFS) 可反对与 Hadoop 继承，替换 HDFS 存储。

艰深点讲：Ceph 提供了三种存储接口：块存储 RBD，对象存储 RGW 和文件存储 CephFS，每种存储都有其相应的性能和个性。

Ceph 存储架构

Ceph 举世无双地用对立的零碎提供了对象、块、和文件存储性能，它可靠性高、治理简便、并且是自由软件。Ceph 的弱小足以扭转贵公司的 IT 基础架构、和治理海量数据的能力。Ceph 可提供极大的伸缩性——供成千用户拜访 PB 乃至 EB 级的数据。Ceph 节点以一般硬件和智能守护过程作为支撑点，Ceph 存储集群组织起了大量节点，它们之间靠互相通信来复制数据、并动静地重散布数据。

什么是 Ceph 分布式存储？
接下来，咱们先来看一下 Ceph 的存储架构，理解 Ceph 的分布式架构，性能组件和波及相干概念。Ceph 分布式集群是建设在 RADOS 算法之上的，RADOS 是一个可扩展性，高牢靠的存储服务算法，是 Ceph 的实现的根底。Ceph 有两个重要的组件组成：Ceph Monitors（Ceph 监视器）和 Ceph OSDs（Ceph OSD 守护过程）。

其中 Ceph Monitor 作为集群中的控制中心，领有整个集群的状态信息，各个组件如 OSDs 将本人的状态信息报告给 Ceph Monitor 这个总司令，由此能够可知，Ceph Monitor 这个总司令肩负起整个集群协调工作；同时 Ceph Monitor 还负责将集群的指挥工作，将集群的状态同步给客户端，客户端依据 Ceph Monitor 发送的集群状态信息能够获取到集群的状态，当集群状态有变动如 OSD 减少或故障时，Ceph Monitor 会负责更新集群状态并下发给客户端。Ceph Monitor 的重要显而易见，为了保障集群的可用性，须要部署高可用，个别须要部署 2n+ 1 个节点，如 3 个或 5 个 Ceph Monitor 节点。

什么是集群的状态呢？Ceph Monitor 中保留的集群状态依据其性能角色的不同，分为以下几个 map 状态表：

•Monitor Maps，集群 Ceph Monitor 集群的节点状态，通过 ceph mon dump 能够获取；
•OSD Maps，集群数据存储节点的状态表，记录集群中 OSD 状态变动，通过 ceph osd dump 能够获取；
•PGs Maps，PGs 即 placement group，示意在 OSD 中的分布式形式，通过 ceph pg dump 能够获取；
•Crush Maps，Crush 蕴含资源池 pool 在存储中的映射门路形式，即数据是如何散布的；
•MDS Maps，CephFS 依赖的 MDS 治理组件，可通过 ceph mds dump 获取，用于追踪 MDS 状态。

除了 Ceph Monitor 之外，还有一个重要的组件是 OSD，集群中通常有多个 OSD 组成，OSD 即 Object Storage Daemon，负责 Ceph 集群中真正数据存储的性能，也就是咱们的数据最终都会写入到 OSD 中。除了 Monitor 之外，依据 Ceph 提供的不同性能，还有其余组件，包含：

•Ceph Monitors（ceph-mon）；
•Ceph OSDs（ceph-osd）；
•Ceph MDS（ceph-mds），用于提供 CephFS 文件存储，提供文件存储所需元数据管理；
•Ceph RGW（ceph-rgw），用于提供 Ceph 对象存储网关，提供存储网关接入；
•Ceph Manager（ceph-mgr），提供集群状态监控和性能监控。

注：Ceph Monitor 监视器保护着集群运行图的主正本。一个监视器集群确保了当某个监视器生效时的高可用性。存储集群客户端向 Ceph Monitor 监视器索取集群运行图的最新正本。而 Ceph OSD 守护过程查看本身状态、以及其它 OSD 的状态，并报告给监视器们。存储集群的客户端和各个 Ceph OSD 守护过程应用 CRUSH 算法高效地计算数据地位，而不是依赖于一个中心化的查问表。它的高级性能包含：基于 librados 的原生存储接口、和多种基于 librados 的服务接口。

Ceph 数据的存储

理解完 Ceph 的架构后，咱们先来理解一下 Ceph 的读写流程，期间会波及到 CRUSH，PGs 等这些概念，咱们从一个最根本的的概念动手：Ceph 中所有皆对象，不论是 RBD 块存储接口，RGW 对象存储接口还是文件存储 CephFS 接口，其存储如到 Ceph 中的数据均能够看作是一个对象，一个文件须要切割为多个对象（object），而后将 object 存储到 OSD 中，如下图：

注：Ceph 存储集群从 Ceph 客户端接收数据——不论是来自 Ceph 块设施、Ceph 对象存储、Ceph 文件系统、还是基于 librados 的自定义实现——并存储为对象。每个对象是文件系统中的一个文件，它们存储在对象存储设备上。由 Ceph OSD 守护过程解决存储设备上的读 / 写操作。

那么，这些切割后的 object 怎么抉择到对应的 OSD 存储节点呢，这须要依赖于 Ceph 的智能调度算法 CRUSH，通过 CRUSH 算法将 object 调度到适合的 OSD 节点上，不论是客户端还是 OSD，均应用 CRUSH 算法来计算 object 在集群中 OSD 的地位信息，同时保障 object 的副本能落到适合的 OSD 节点上，对于 CRUSH 算法的实现比较复杂，详情能够参考：CRUSH: Controlled, Scalable, Decentralized Placement of Replicated Data。

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

object 调度到 OSD 节点上，如果一个文件产生了变动或 OSD 呈现了异样，以一个 100G 的文件为例，每个 object 默认为 4M，将会切割为 25600 个 object，如果 Ceph 集群须要正对每个 object 都进行调度的话，可想而知，在一个大规模集群中，crush 的调度将会变得异样的沉重。因而，Ceph 引入了另外一个概念 PG，PG 是 Place Group 即搁置组，能够简略了解为一个装载 object 的容器，object 将映射到 PG 中，PG 最终会调度到某个具体的 OSD 上，因而 CRUSH 由 object 调度转为 PG 的调度，而 PG 的数量是绝对固定的，因而集群散布时调度绝对没有那么沉重，同时，当某个 OSD 异样时，CRUSH 调度算法只需将其上的 PG 调度至其余 OSD 上（而不是将其上的 object 进行调度）。Ceph 的整个数据调度写入流程如下图：

•一个文件将会切割为多个 object（如 1G 文件每个 object 为 4M 将切割为 256 个），每个 object 会由一个由 innode(ino)和 object 编号 (ono) 组成 oid，即 object id，oid 是真个集群惟一，惟一标识 object 对象；
•针对 object id 做 hash 并做取模运算，从而获取到 pgid，即 place group id，通过 hash+mask 获取到 PGs ID，PG 是存储 object 的容器；
•Ceph 通过 CRUSH 算法，将 pgid 进行运算，找到以后集群最适宜存储 PG 的 OSD 节点，如 osd1 和 osd2（假如为 2 个正本）；
•PG 的数据最终写入到 OSD 节点，实现数据的写入过程，当然这里会波及到多正本，一份数据写多正本。

好了，当初咱们对 Ceph 有了根本意识了。前面咱们讲持续理解 Ceph 伸缩性和高可用性；动静集群治理；纠删编码；缓存分级等内容。当然、咱们也会具体理解到如纠删编码中对于读出和写入编码块，被中断的齐全写等更细的内容。

本文由博客群发一文多发等经营工具平台 OpenWrite 公布