卢梭

人生而自由，又无往不在枷锁之中。

Filecoin 的测试正在如火如荼的进行。面对即将到来的第二期测试，各路玩家都使出了浑身解数。 到本文发布为止, Lotus 测试网全网算力已经达到 1.3 PB，头部矿工的算力已经有 500 多TB。 有不少同学在 Slack 上问我，说他们是怎么存储这么多数据的，即使把48盘位的矿机满盘位做 raid5 也不可能有这么大的存储空间。

要实现这种超大数据盘，就得使用分布式存储系统了，比如我们接下来要说的 Ceph。

Ceph 简介

Ceph 是一个开源的分布式存储系统，设计初衷是提供较好的性能、可靠性和可扩展性。 Ceph 独一无二地在一个统一的系统中同时提供了对象、块、和文件存储功能。 Ceph 消除了对系统单一中心节点的依赖，实现了无中心结构的设计思想。

Ceph 特点

高性能

1. 摒弃了传统的集中式存储元数据寻址的方案，采用CRUSH算法，数据分布均衡，并行度高。
2. 考虑了容灾域的隔离，能够实现各类负载的副本放置规则，例如跨机房、机架感知等。
3. 能够支持上千个存储节点的规模，支持 PB 甚至 EB 级的数据。

高可用性

1. 副本数可以灵活控制。
2. 支持故障域分隔，数据强一致性。
3. 多种故障场景自动进行修复自愈。
4. 没有单点故障，自动管理。

高可扩展性

1. 没有中心节点
2. 扩展灵活，可以很方便的扩容，缩容。
3. 随着节点增加而线性增长。

特性丰富

1. 支持三种存储接口：块存储、文件存储、对象存储。
2. 支持自定义接口，支持多种语言驱动。

Ceph 架构

Ceph 的架构哲学：

1. 每个组件必须是可扩展的。
2. 不存在单点故障。
3. 解决方案必须是基于软件的、开源的、适应力强的。
4. 可以运行在常规的硬件上。
5. 任何组件都是必须自我管理。

下面是 Ceph 的整体架构图：

RADOS

RADOS 全称 Reliable Autonomic Distributed Object Store，是Ceph底层核心，提供了一个可靠、自动、智能的分布式存储。 RADOS 本身就是一个完整的对象存储系统 ，实际上所有存储在Ceph中的用户数据都是由这一层来存储的。 Ceph 的高可高、高扩展、高性能、自动化等特性实际上也是这一层来提供的。 RADOS 在物理上由大量存储设备节点组成，每个节点拥有自己的CPU、内存、磁盘、网络等硬件资源，并运行着自己的操作系统和文件系统。 在逻辑上 RADOS 由少量 MON 和大规模 OSD 组成。

MON

即 Monitor, 是Ceph集群的监控器，负责维护整个集群的健康状态，提供一致性决策。

Object

Ceph 最底层的存储单元是 Object 对象， 大小一般默认为 4MB ，你也可以在创建块设备或者 pool 的时候根据需求设置自定义大小。 Ceph OSD 在扁平的命名空间内把所有数据存储为对象（也就是没有目录层次）。

对象的结构：

1. 对象标志（ID）：唯一标识一个对象。
2. 对象的数据：其在本地文件系统中对应一个文件，对象的数据就保存在文件中。
3. 对象的元数据：以 Key-Value（键值对）的形式，可以保存在文件对应的扩展属性中。

Note: 一个对象 ID 不止在本地唯一 ，它在整个集群内都是唯一的。

OSD(Object Storage Device)

对象存储设备，主要功能是存储数据、处理数据的复制、回复、平衡数据分布。 一个Ceph存储集群至少需要两个 OSD 以达到 active+clean 的健康状态、并默认为数据保存两份副本。 Ceph 集群节点上的每个磁盘、分区都可以成为一个OSD。

关系说明:

1. 一个OSD上可以分布多个 PG
2. OSD设备是存储 Object 的载体

PG (placement group)

PG 是 OSD之上的一层逻辑，可视其为一个逻辑概念。Ceph 把对象映射到 PG 中。 从名字可理解 PG 是一个放置策略组，很多个对象一起组团，然后再存入 OSD 中，用来方便定位和追踪对象。 因为一个拥有数百万对象的系统，不可能在对象这一级追踪位置。

可以把 PG 看做一个对象集合，该集合里的所有对象都具有相同的放置策略：对象的副本都分布在相同的 OSD 列表上。

PG 减少了各对象存入对应 OSD 时的元数据数量，更多的 PG 使得均衡更好。

关系说明：

1. PG有主从之分，对于多副本而言，一个PG的主从副本分布在不同的OSD上；
2. 一个对象只能属于一个PG，一个PG包含很多个对象
3. 一个PG对应于一个OSD列表，PG的所有对象对存放在对应的OSD列表上

Pool

Pool 是一个抽象的存储池，它是 PG 之上的一层逻辑。所有的对象都必须存在存储池中。 存储池管理着归置组数量、副本数量、和存储池规则集。要往存储池里存数据，用户必须通过认证、且权限合适，存储池可做快照。

你可以这样粗略的理解：如果把整个 Ceph 存储系统看做是一个数据库的话，那么 Pool 的角色可以看做是数据表。用户可能需要根据不同的 需求把对象存储在不同的存储池中。

关系说明：

1. 一个 Pool 由多个 PG 构成，一个 PG 只能属于一个 Pool。
2. 同一个 Pool 中的 PG 具有相同的类型，比如，如 Pool 为副本类型，则 Pool 中所有的 PG 都是多副本的。

PGP (Placement Group for Placemen)

PG 的归置组:

1. PGP 起到对 PG 进行归置的作用；
2. PGP的取值应该与PG相同，在PG的值增大的同时，也要增大PGP的值以保持二者的值相同；
3. 当一个 Pool 的 PG 增大后，Ceph 并不会开始进行 rebalancing，只有在 PGP 的值增大后， PG才会开始迁移至其他的OSD上，并且开始 rebalancing。

MDS

全称 MetaData Server，保存Ceph 文件系统的元数据，为基于POSIX文件系统的用户提供了一些基础命令如ls等。 如果需要使用 CephFS, 则必须启动 MDS 服务。 整个 CephFS 的元数据都是实时同步的，所以能否很方便的实现 CephFS 的共享挂载，弥补了Ceph 的块设备接口在共享性方面的不足。

Librados

Librados是Rados提供库，因为RADOS是协议很难直接访问，因此上层的RBD、RGW和CephFS都是通过librados访问的，目前提供PHP、Ruby、Java、Python、C和C++支持。

CRUSH

CRUSH是Ceph使用的数据分布算法，类似一致性哈希，让数据分配到预期的地方。 CRUSH 算法通过计算数据存储位置来确定如何存储和检索。 CRUSH 授权 Ceph 客户端直接连接 OSD ，而非通过一个中央服务器或经纪人。 数据存储、检索算法的使用，使 Ceph 避免了单点故障、性能瓶颈、和伸缩的物理限制。

RBD

通过 Linux 内核客户端或QEMU/KVM驱动提供一个完全的分布式块设备。

RBD 镜像是基于存储池构建的逻辑存储系统，RBD 镜像通过librbd及RADOS映射到对象(rados对象)，然后利用Crush计算来定位在存储设备中的位置。

RGW

基于HTTP REST协议的网关，兼容Amazon S3 API和OpenStack Swift API。

Ceph FS

通过 Linux 内核客户端或 FUSE 提供一个兼容POSIX的文件系统。

ceph 文件系统是基于元数据存储池和数据存储池构建的逻辑系统， 文件系统中的文件会通过 libcephfs 及 RADOS 映射到对象(rados对象)，然后利用 Crush 计算来定位在存储设备中的位置。

Ceph 与传统存储的对比

下面我们把 Ceph 跟我们上篇文章讲的 DAS,NAS,SAN 几种传统存储方案进行对比。

存储结构	特点	建设成本，使用维护，应用场景，性能
DAS	磁盘利用率低，性能低， 延迟率低，不易扩展	适合性能要求不高，容量低的场景 维护简单 性能低 成本最低
SAN	具有高带宽，低延时的优势 价格较高，且可扩展性差	适合性能要求高和延时低的场景。 不适合存储规模不断扩大的场景，例如公有云，私有云以及大数据应用。 维护最复杂，成本最高。
NAS	文件级存储，带宽最低，延时最大	适合对带宽要求不高，延时高的场景，比如部门级文件共享 维护简单，成本较低。
Ceph	带宽高，延时位于 DAS 和 SAN 之间	适用于对延时要求不是特别高的场景 适用于云环境以及大数据场景 维护成本较低 成本高于 DAS 低于 SAN，IOPS 随着存储容量线性增长。

参考文献

• http://docs.ceph.org.cn/architecture/ (opens new window)
• https://blog.frognew.com/2017/02/intro-ceph.html (opens new window)
• https://www.jianshu.com/p/cc3ece850433 (opens new window)