分布式存储--------Ceph

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

分布式

分布式是指多个系统协同合作完成一个特定任务的系统。好比多个人一起做不同的事。

相当于在写mysql的时候，每个节点存储部分数据（分库分表），这就是分布式存储的由来。

存储一些非结构化数据：静态文件、图片、pdf、小视频 ... 这些也是分布式文件系统的由来。

集群

集群是指在几个服务器上部署相同的应用程序来分担客户端的请求。

好比多个人一起做同样的事。

集群主要的使用场景是为了分担请求的压力。

但是，当压力进一步增大的时候，可能在需要存储的部分

一、存储基础

1、传统存储

传统的存储类型

DAS设备

SAS、SATA、SCSI、IDE、USB

无论是哪种接口，都是存储设备下的磁盘设备，而磁盘设备其实就是一种存储，这种存储就是直接接入到主板总线上去的

NAS设备(只能使用远程存储的文件，但是不能进行管理，通讯方式基于文件方式实现)

NFS、CIFS

几乎所有的网络存储设备基本上都是以文件系统样式进行使用，无法进一步格式化操作

Nfs (将远程共享的文件挂载到本地目录上可以访问远程服务器上的资源，但是不能管理存储空间)。

SAN（存储区域网络）

SCSI协议、FCSAN、iSCSI

块设备存储

基于SAN方式提供给客户端操作系统的是一种块设备接口，这些设备主要通过SCSI协议来完成正常通信，SCSI的结构类似于TCP/IP协议，也有很多层，但是SCSI协议主要用来进行存储数据操作的，既然是分层方式实现的，那就是说有部分层可以被替代，比如将物理层基于FC方式来实现，就形成了FCSAN ，如果基于以太网方式来传递数据，就形成了iSCSI模式。

二、传统存储方式问题

1、存储处理能力不足

2、存储空间不足

单块磁盘的容量再大，也无法满足用户的正常访问所需的数据容量限制

3、单点问题

单主机存储数据存在SPOF（single point of failure）问题

三、文件系统简介

1、文件系统的组成

接口：文件系统接口

功能模块（管理、存储的工具）：对象管理里的软件集合

对象及属性：（使用此文件系统的消费者）

2、文件系统的作用

从系统角度来看，文件系统对文件存储设备的空间进行组织和分配，负责文件存储并对存入的文件进行保护和检索的系统

主要负责为用户建立文件、存入、读出、修改、转储文件，控制文件的存取

四、Ceph 简介

ceph是一个可无限伸缩的开源分布式存储系统，设计初衷是提供较好的性能、可靠性和可扩展性，它基于RADOS实现。在经过了数年的发展之后，目前已得到众多云计算厂商的支持并被广泛应用，RedHat及OpenStack（云操作系统）

都可与Ceph整合以支持虚拟机镜像的后端存储。

注：OpenStack就是为了云计算服务的。简单来说，它就是一个操作系统

其中（分布式对象存储系统RADOS是Ceph最为关键的技术，它是一个支持海量存储对象的分布式对象存储系统。RADOS层本身就是一个完整的对象存储系统，事实上，所有存储在Ceph系统中的用户数据最终都是由这一层来存储的。而Ceph的高可靠、高可扩展、高性能、高自动化等特性，本质上也是由这一层所提供的）

三、Ceph 特点

高性能：

1、摒弃了传统的集中式存储元数据寻址的方案，采用 CRUSH 算法，数据分布均衡，并行度高。

2、考虑了容灾域的隔离，能够实现各类负载的副本放置规则，例如跨机房、机架、感知等。

3、能够支持上千个存储节点的规模，支持 TB 到 PB 级的数据。

高可用性：

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

高扩展性：

1、去中心化。
2、扩展灵活。
3、随着节点增加而性能线性增长。

特性丰富

1、支持三种存储接口：块存储、文件存储、对象存储。

2、支持自定义接口，支持多种语言驱动。

缺点：

单机无法实现ceph

需要搭建集群，适合大型环境，成本高

四、ceph基础

ceph把每一个待管理的数据流切分为一个到多个固定大小（默认4M）的对象数据，并以原子单元完成数据的读写。

对象数据的底层存储服务是有多个主机组成的存储集群，该集群为RADOS，该集群的librados是存储集群的API（应用程序接口），支持c/c++/java/python/ruby/php/go

ceph存储集群提供的基本存储服务，使ceph能够在一个联合文件系统中独一无二的实现对象存储(object storage)、块存储(block storage)以及文件存储(file storage)。依赖于RADOS，你可以直接通过librados API来访问ceph存储集群。

对象存储：

也就是通常意义的键值存储，其接口就是简单的 GET、PUT、DEL 和其他扩展，代表主要有 Swift 、S3、Gluster 等。

块存储：

Ceph 的 RBD（RBD 是 Ceph 面向块存储的接口）。在常见的存储中 DAS、SAN 提供的也是块存储。

文件系统存储：

分布式存储提供了并行化的能力，如 Ceph 的 CephFS（CephFS 是 Ceph 面向文件存储的接口），但是有时候又会把 GlusterFS，HDFS 这种非 POSIX 接口的类文件存储接口归入此类。当然 NFS、NAS 也是属于文件系统存储。

也就是说，ceph 将三种存储类型统一在一个平台中，从而实现了更强大的适用性

五、Ceph 核心组件

1、Monitors（核心）

监视器，维护集群状态的多种映射，同时提供认证和日志记录服务，包括有关 monitor 节点端到端的信息，其中包括 Ceph 集群 ID，监控主机名和 IP 以及端口。并且存储当前版本信息以及最新更改信息，监视器负责管理守护进程和客户端之间的身份验证，通常至少需要三个监视器才能实现冗余和高可用。

2、Managers（状态跟踪)

Ceph的Managers（Ceph Manager），守护进程（ceph-mgr）负责跟踪运行时间指标和Ceph群集的当前状态，包括存储利用率，当前性能指标和系统负载。 Ceph Manager守护程序还托管基于python的插件来管理和公开Ceph集群信息，包括基于Web的仪表板和REST API。通常，至少有两名Manager需要高可用性。

3、OSD（对象存储服务器）

Ceph的OSD（Object Storage Device）守护进程。主要功能包括：存储数据、副本数据处理、数据恢复、数据回补、平衡数据分布，并将数据相关的一些监控信息提供给Ceph Moniter,以便Ceph Moniter来检查其他OSD的心跳状态。一个Ceph OSD存储集群，要求至少两个Ceph OSD,才能有效的保存两份数据。注意，这里的两个Ceph OSD是指运行在两台物理服务器上，并不是在一台物理服务器上运行两个Ceph OSD的守护进程。通常，冗余和高可用性至少需要3个Ceph OSD。

4、MDS（Metadata Server）

Ceph 元数据，主要保存的是 Ceph 文件系统的元数据。注意：ceph 的块存储和 ceph 对象存储都不需要 MDS。

5、RADOS

RADOS（Reliable Autonomic Distributed Object Store）是 ceph 存储集群的基础。在 ceph 中，所有数据都以对象的形式存储，并且无论什么数据类型，RADOS 对象存储都将负责保存这些对象。RADOS 层可以确保数据始终保持一致。

6、librados

librados 库，为应用程度提供访问接口。同时也为块存储、对象存储、文件系统提供原生的接口。

7、RADOSGW

网关接口，提供对象存储服务。它使用 librgw 和 librados 来实现允许应用程序与 Ceph 对象存储建立连接。并且提供 S3 和 Swift 兼容的 RESTful API 接口。

8、RBD

块设备，它能够自动精简配置并可调整大小，而且将数据分散存储在多个 OSD 上。

9、CephFS

Ceph 文件系统，与 POSIX 兼容的文件系统，基于 librados 封装原生接口。

六、Ceph 存储系统的逻辑层次结构

Ceph存储系统的逻辑结构在分布式，大致分为4个部分：

1、基于存储系统RADOS、

2、基于RADOS实现的CephFS、

3、基于RADOS的LIBRADOS层应用接口、

4、基于LIBRADOS的应用接口RBD和RADOSGW。

①、基础存储系统RADOS：Reliable Autonomic Distributed Object Store。RADOS是ceph存储集群的基础。在ceph中，所有数据都以对象的形式存储。在物理上，RADOS由大量的存储设备节点组成，每个节点拥有自己的硬件资源，并运行着操作系统和文件系统。

②、基础库LIBRADOS：LIBRADOS层的功能是对RADOS进行抽象和封装，并向上层提供API（应用程序接口）以便直接基于RADOS进行应用开发。应用程序通过访问LIBRADOS库来与RADOS系统进行交互，支持多种编程语言，比如C、C++、Python等。物理上，LIBRADOS与基于其上开发的应用在同一台机器，也称为本地API。

③、上层应用接口：Ceph上层应用接口包括对象存储RADOSGW、块存储RBD和文件系统存储CephFS。RADOSGW提供与Amazon S3和Swift兼容的RESTful API网关，供相应的对象存储应用开发使用；RBD提供标准的块设备接口，常用于虚拟化场景下为虚拟机创建volume。

④、应用层：Ceph各应用接口在不同应用场景下的使用，例如基于LIBRADOS直接开发的对象存储应用、基于RADOSGW开发的对象存储应用、基于RBD实现的云主机硬盘等。

七、Ceph 数据存储过程

Ceph中一切皆对象，不管是RBD块存储接口，RGW对象存储接口还是文件存储CephFS接口，其存储如到Ceph中的数据均可以看作是一个对象，一个文件需要切割为多个对象（object），然后将object存储到OSD中。

切割后的对象怎么选择到对应的OSD存储节点，需要依赖于Ceph的智能调度算法CRUSH，通过CRUSH算法将对象调度到合适的OSD节点上，不管是客户端还是OSD，均使用CRUSH算法来计算对象在集群中OSD的位置信息，同时保障object的副本能落到合适的OSD节点上。

简单来说：

无论使用哪种存储方式（对象、块、文件系统），存储的数据都会被切分成 Objects（对象）。Objects size 大小可以由管理员调整，通常为 2M 或 4M。每个对象都会有一个唯一的 OID，OID是由 ino 与 ono 生成。

ino：即是文件的 File ID，用于在全局唯一标识每一个文件。

ono：则是分片的编号。

比如：一个文件 FileID 为 A，它被切成了两个对象，一个对象编号 0，另一个编号 1，那么这两个文件的 oid 则为 A0 与 A1。

①、File：此处的 file 就是用户需要存储或者访问的文件。对于一个基于 Ceph 开发的对象存储应用而言，这个 file 也就对应于应用中的 “对象”，也就是用户直接操作的 “对象”。

②、Ojbect：此处的 object 是 RADOS 所看到的 “对象”。Object 与上面提到的 file 的区别是，object 的最大 size 由 RADOS 限定（通常为 2MB 或 4MB），以便实现底层存储的组织管理。因此，当上层应用向 RADOS 存入 size 很大的 file 时，需要将 file 切分成统一大小的一系列 object（最后一个的大小可以不同）进行存储。

③、PG（Placement Group 放置组）：PG 的用途是对 object 的存储进行组织和位置映射。具体而言，一个 PG 负责组织若干个 object（可以为数千个甚至更多），但一个 object 只能被映射到一个 PG 中，即 PG 和 object 之间是 “一对多” 映射关系。同时，一个 PG 会被映射到 n 个 OSD 上，而每个 OSD 上都会承载大量的 PG，即 PG 和 OSD 之间是多对多映射关系。在实践当中，n 至少为 2，如果用于生产环境，则至少为 3。一个 OSD 上的 PG 则可达到数百个。事实上，PG 数量的设置牵扯到数据分布的均匀性问题。

④、OSD（object storage device对象存储设备）：OSD 的数量事实上也关系到系统的数据分布均匀性，因此其数量不应太少。在实践当中，至少也应该是数十上百个的量级才有助于 Ceph 系统的设计发挥其应有的优势。

Ceph 中的寻址至少要经历以下三次映射：

File（文件）-------> object(对象) 映射

Object -------> PG(组)映射，hash(oid) & mask -----> pgid

PG ------->OSD 映射，CRUSH 算法

CRUSH（Controlled Replication Under Scalable Hashing）：通过计算系统中数据应该被写入或读出的位置。CRUSH 能够感知基础架构，能够理解基础设施各个部件之间的关系。并且 CRUSH 保存数据的多个副本，这样即使一个故障域的几个组件都出现故障，数据依然可用。CRUSH 使得 ceph 实现了自我管理和自我修复。