Table of Contents

存储设备
#

DAS
#

直接附加存储

IDE，SATA，SCSI，SAS，USB

NAS
#

网络附加存储

NFS，CIFS

SAN
#

SCSI，FC SAN，iSCSI

HDFS
#

Hadoop Distributed FileSystem

存在元数据服务器，容易形成性能瓶颈

Ceph
#

统一的分布式存储系统，提供较好的性能、可靠性和可扩展性

Ceph 是一个对象式存储系统，它把每一个待管理的数据流（如一个文件）切分到一到多个固定大小的对象数据，并以其作为原子单元完成数据存取

对象数据的底层存储服务是由多个主机（host）组成的存储集群，该集群也被称之为 RADOS（Reliable Automatic Distributed Object Store）存储集群，即可靠、自动化、分布式对象存储系统

librados 是 RADOS 存储集群的 API

RadosGW、RBD、CephFS 都是 RADOS 存储服务的客户端，它们把 RADOS 的存储服务接口（librados）分别从不同的角度做了进一步抽象，因而各自适用于不同的应用场景。

CephFS 不依赖 librados，文件系统接口。需要守护进程 MDS 作为文件系统 server

RadowGW 提供 restful API 接口，可提供 http/https 访问

RBD 基于内核模块（librbd）由客户端主机进行分区格式化，使用最广泛

设计思想

采用具有计算能力的服务器作为存储系统的存储节点，即充分发挥节点的计算能力，以实现高可靠，高可扩展性等特性；
去除中心点，避免单点故障，同时避免扩展时的规模和性能瓶颈。

RADOS 对象存储系统是 Ceph 的基石。

对象存储和块存储，文件存储等存储形态不同，它有两个显著的特征：

（1）采用 K/V 方式的 Restful Web API 接口来进行数据的读写操作；

（2）扁平的数据组织结构。文件系统采用树状存储方式，比较直观，然而，随着云存储时代的到来，存储系统的规模不断扩大，树状存储方式难以大规模扩展的弊端便暴露了出来。对象存储放弃了目录树的组织结构，采用了扁平化的数据组织方式，使得存储系统可以无限扩容，更加符合云服务中的存储，归档和备份的需求。一般分为三级，账户/桶/对象。

所有对象都存储在同一个平面上，没有文件系统

存储被划分为多个分区，即存储池，存储池大小取决于底层的存储空间，每个存储池可进一步划分为名称空间。每个存储池内部会有 PG 存在。PG 是抽象的概念。数据应该存在哪里由 CRUSH 决定，即将对对象做一致性哈希计算，寻找对应的 PG。根据 PG 找到能够存放的 OSD 存储

Monitor 一个 Ceph 集群需要多个 Monitor 组成的小集群，它们通过 Paxos 同步数据，用来保存 OSD 的元数据。为整个存储集群提供全局的配置和系统信息
OSD 全称 Object Storage Device，也就是负责响应客户端请求返回具体数据的进程。一个 Ceph 集群一般都有很多个 OSD。
MDS 全称 Ceph Metadata Server，是 CephFS 服务依赖的元数据服务。
Object 最底层的存储单元是 Object 对象，每个 Object 包含元数据和原始数据。
PG 全称 Placement Grouops，归置组，是一个逻辑的概念，一个 PG 包含多个 OSD。引入 PG 这一层其实是为了更好的分配数据和定位数据。
RADOS 全称 Reliable Autonomic Distributed Object Store，是 Ceph 集群的精华，用户实现数据分配、Failover 等集群操作。
Libradio 是 Rados 提供库，因为RADOS是协议很难直接访问，因此上层的 RBD、RGW 和 CephFS 都是通过 librados 访问的，目前提供PHP、Ruby、Java、Python、C和C++支持。
CRUSH 是 Ceph 使用的数据分布算法，类似一致性哈希，让数据分配到预期的地方。
RBD 全称 RADOS block device，是 Ceph 对外提供的块设备服务。
RGW 全称 RADOS gateway，是Ceph 对外提供的对象存储服务，接口与S3和Swift兼容。
CephFS 全称 Ceph File System，是 Ceph 对外提供的文件系统服务。

存储类型
#

块存储
文件存储
对象存储

RADOS
#

RADOS（Reliable,Autonomic Distributed Object Store）在动态变化和异质结构的存储设备机群之上提供一种稳定、可扩展、高性能的单一逻辑对象(Object)存储接口和能够实现节点的自适应和自管理的存储系统

事实上，RADOS也可以单独作为一种分布式数据存储系统，给适合相应需求的分布式文件系统提供数据存储服务。

主要包括两个部分：

由数目可变的大规模 OSDs（Object Storage Devices）组成的机群，负责存储所有的 Objects 数据；
由少量 Monitors 组成的强耦合、小规模机群，负责管理 Cluster Map，其中 Cluster Map 是整个 RADOS 系统的关键数据结构，管理机群中的所有成员、关系、属性等信息以及数据的分发。

OSD
#

对象存储设备（每个磁盘相当于一个 OSD ）

集群的存储节点，用于数据存储和维护。实际上OSD就是一台安装了操作系统的服务器

每个 OSD 都具有一定的计算能力。每个 OSD 的系统上都有一个守护进程 OSD Daemon。

Daemon 负责与 Monitors 集群，其他 OSD 进行通信，维护系统状态，与其他 OSD 共同完成数据存储与维护；与客户端 Clients 通信完成各种数据对象操作。

一般 OSD 上的对象存储以 4MB 大小为一个单元，由标识符，二进制数和元数据组成。

一般至少存在三个 OSD 做冗余和高可用

Clients
#

ceph 的客户端，提供 RBD（块存储）, CephFS（文件存储）RadosGW（对象存储）三种接口，即包含这三种的客户端。其中 RadosGW 提供了兼容 S3 和 Swift 的对象存储接口。客户端通过这几种接口都可以向 RADOS 集群发送数据，RADOS 将这些数据存储为对象，每个对象是文件系统的一个文件，存储在 OSD 的存储设备上。OSD Daemon 负责处理存储设备上的读写操作。

Monitors
#

RADOS 的监视器集群，提供集群的元数据。Monitor 是一个独立部署的守护进程，一个 Monitor 可以监视一个 Ceph 存储集群，但是为了避免 Monitor 单点故障，通过组成 Monitors 集群来保证高可用。Monitors 集群通过 Paxos 分布式一致性算法来保证数据同步。Monitors 用于记录存储集群中所有的 OSD 状态，形成集群运行图的主副本，包括集群成员，状态，变更等。集群运行图会被发送至全体 OSD 节点和客户端，OSD 依据集群运行图进行数据存储和维护；客户端根据集群运行图进行数据寻址。

Monitor 并不会主动轮询 OSD 的状态，而是 OSD 主动上报，比如新 OSD 加入集群，或者 OSD 本身发生异常。收到上报信息后 Monitor 更新集群运行图并重新向 OSD 和客户端分发。OSD 的状态影响着数据的分配，所以监控 OSD 的状态是 Monitor 的主要工作之一。

负责认证，维护集群的认证信息（协议 CephX）

Manager
#

L 版引入，无状态。跟踪运行时的指标数据、集群当前状态（包括存储空间利用率，性能指标，系统负载），一般至少存在两个 Mgr

Cluster Map
#

存储机群的管理，唯一的途径是 Cluster Map 通过对 Monitor Cluster 操作完成。

Cluster Map 是整个 RADOS 系统的核心数据结构，其中指定了机群中的 OSDs 信息和所有数据的分布情况。所有涉及到 RADOS 系统的 Storage 节点和 Clients 都有最新 epoch 的 Cluster Map 副本。因为 Cluster Map 的特殊性，Client 向上提供了非常简单的接口实现将整个存储机群抽象为单一的逻辑对象存储结构。

Cluster Map 的更新由 OSD 的状态变化或者其他事件造成数据层的变化驱动，每一次 Cluster Map 更新都需要将 map epoch 增加，map epoch 使 Cluster Map 在所有节点上的副本都保持同步，同时，map epoch 可以使一些过期的 Cluster Map 能够通过通信对等节点及时更新。

在大规模的分布式系统中，OSDs 的 failures/recoveries 是常见的，所以，ClusterMap 的更新就比较频繁，如果将整个 ClusterMap 进行分发或广播显然会造成资源的浪费，RADOS 采用分发 incremental map 的策略避免资源浪费，其中 incremental map 仅包含了两个连续 epoch 之间 ClusterMap 的增量信息。