Ceph分布式存储

一、存储分类

1.1 本地文件系统

常见的本地文件系统有EXT系列、NTFS、XFS等。ext2不带日志，ext3和ext4带有日志：文件系统的日志作用（防止机器突然断电）：所有的数据在给磁盘存数据之前会先给文件系统的日志里面存一份，防止机器突然断电之后数据没有存完，这样它还可以从日志里面重新将数据拷贝到磁盘。

1.2 网络文件系统

1.2.1 分布式

常见的分布式文件系统有：Ceph、Gluster、 Swift 、HDFS等，它们 都属于分布式集群文件系统 。“分布式”它指代了一种独特的系统架构类型，这种系统架构是由一组通过网络进行通信，为了完成共同的任务而协调工作的计算机节点组成。简单的说，“分布式” 就是将数据分散存储到多个数据存储节点上 ，它的特点就是利用更多的机器，处理更多的数据，如下图所示：

1.2.2 非分布式

而对于“非分布式”来说，常见的有FTP、NFS（网络文件系统，又称为nas存储）。“非分布式”的存储就是将整个数据存储到后端存储服务器中。

1.2.3 非分布式文件系统特点

为了克服块存储文件无法共享的问题，所以有了文件存储。在服务器上安装FTP与NFS服务，就是文件存储。

优点：

• 造价低，随便一台机器就可以了；
• 方便文件共享。

缺点：

• 读写速率低；
• 传输速率慢。

1.3 分布式文件系统存储

分布式存储系统可以扩展到几百台甚至几千台的集群规模，而且随着集群规模的增长，系统整体性能表现为线性增长。

1.3.1 分布式文件系统存储使用架构

首先客户端（Client）会先去访问元数据服务器（Metadata）查找数据，然后元数据服务器会“告诉”客户端（Client）数据的存放位置，最后客户端就会直接去后端数据节点取数据。在这里为什么元数据服务器（Metadata）会告知客户端（Client）客户端数据的存储位置呢？那是因为这个元数据服务器（Metadata）存储的是文件的数据存放的位置信息。

说明：

Client：代表客户端。

Metadate：代表元数据服务器（管理服务器）。

DataNode：代表存储数据的数据节点。

1.3.2 分布式文件系统存储特点

• 共享的是文件系统，共享的最小单位是文件，可实现PB级别的存储；

• 可扩展性强：分布式存储的水平扩展有以下几个特性：

  • 节点扩展后，旧数据会自动迁移到新节点，实现负载均衡，避免单点故障的情况出现；
  • 水平扩展只需要将新节点和原有集群连接到同一网络，整个过程不会对业务造成影响。

• 低成本：分布式存储系统的自动容错、自动负载均衡机制使其可以构建在普通的PC机之上；

• 易管理：可通过一个简单的WEB界面就可以对整个系统进行配置管理，运维简便，极低的管理成本。

1.4 块存储

1.4.1 什么是块存储？

块存储最典型的就是SAN（storage area network）(存储区域网)----有一个局域网里面有一个交换机，交换机上面连着服务器，所有服务器都是专业存储的设备，他们组成一个存储区域网，当我们用的时候只需要在这个区域网里面拿空间使用。

1.4.2 块存储的特点

优点：

• 通过Raid与LVM等手段，对数据提供了保护；
• 多块廉价的硬盘组合起来，提高容量；
• 多块磁盘组合出来的逻辑盘，提升读写效率。

缺点：

• 采用SAN架构组网时，光纤交换机，造价成本高；
• 主机之间无法共享数据。

1.5 对象存储

1.5.1 对象存储使用架构

首先得明确一点：文件都包含哪些东西？一个文件包含了属性（术语叫metadata，元数据，例如该文件的大小、修改时间、存储路径等）以及内容。

对象存储则将元数据独立了出来，控制节点叫元数据服务器（服务器+对象存储管理软件），里面主要负责存储对象的属性（主要是对象的数据被打散存放到了那几台分布式服务器中的信息），而其他负责存储数据的分布式服务器叫做OSD，主要负责存储文件的数据部分。当用户访问对象，会先访问元数据服务器，元数据服务器只负责反馈对象存储在哪些OSD，假设反馈文件A存储在B、C、D三台OSD，那么用户就会再次直接访问3台OSD服务器去读取数据。

1.5.2 对象存储特点

由于是3台OSD同时对外传输数据，所以传输的速度就加快了。当OSD服务器数量越多，这种读写速度的提升就越大，通过此种方式，实现了读写快的目的。

另一方面，对象存储软件是有专门的文件系统的，所以OSD对外又相当于文件服务器，那么就不存在文件共享方面的困难了，也解决了文件共享方面的问题。

所以对象存储的出现，很好地结合了块存储与文件存储的优点，简单总结如下：

• 具备块存储的读写高速；
• 具备文件存储的共享等特性。

二、Ceph详解

2.1 Ceph简介

Ceph可用于对象存储、块设备存储和文件系统存储。

Ceph使用C++语言开发，Sage Weil（Ceph论文发表者）于2011年创立了以Inktank公司主导Ceph的开发和社区维护。2014年Redhat收购inktank公司，并发布Inktank Ceph企业版（ICE）软件，业务场景聚焦云、备份和归档，支持对象存储和块存储以及文件系统存储应用。出现Ceph开源社区版本和Redhat企业版。

Ceph主要设计的初衷是变成一个可避免单节点故障的统一的分布式文件系统，提供较好的性能、可靠性和PB级别的扩展能力，而且是一种开源自由软件，许多融合的分布式文件系统都是基于Ceph开发的。

2.2 Ceph特性

• 高扩展性：使用普通x86服务器，支持10~1000台服务器，支持TB到EB级的扩展。
• 高可靠性：没有单点故障，多数据副本，自动管理，自动修复。
• 高性能：数据分布均衡。

2.3 Ceph架构

2.3.1 基础存储系统RADOS

Reliable, Autonomic, Distributed Object Store，即可靠的、自动化的、分布式的对象存储。所有存储在Ceph系统中的用户数据事实上最终都是由这一层来存储的。Ceph的高可靠、高可扩展、高性能、高自动化等等特性本质上也是由这一层所提供的。

2.3.2 基础库librados

这一层的功能是对RADOS进行抽象和封装，并向上层提供API，以便直接基于RADOS进行应用开发。由于RADOS是一个对象存储系统，因此，librados实现的API也只是针对对象存储功能的。

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

2.3.3 高层应用接口

其作用是在librados库的基础上提供抽象层次更高、更便于应用或客户端使用的上层接口。

• radosgw：对象网关接口(对象存储)
• rbd：块存储
• cephfs：文件系统存储

2.4 Ceph基本组件

Ceph主要有三个基本组件，分别是OSD、MDS、Monitor。

2.4.1 OSD

OSD全称Object Storage Device，也就是负责响应客户端请求返回具体数据的进程。一个Ceph集群一般都有很多个OSD。用于集群中所有数据与对象的存储。处理集群数据的复制、恢复、回填、再均衡。并向其他osd守护进程发送心跳，然后向Mon提供一些监控信息。当Ceph存储集群设定数据有两个副本时（一共存两份），则至少需要两个OSD守护进程即两个OSD节点，集群才能达到active+clean状态.

2.4.2 MDS

MDS全称Ceph Metadata Server，是CephFS服务依赖的元数据服务。为Ceph文件系统提供元数据计算、缓存与同步（也就是说，Ceph 块设备和 Ceph 对象存储不使用MDS ）。在ceph中，元数据也是存储在osd节点中的，mds类似于元数据的代理缓存服务器。只有需要使用CEPHFS时，才需要配置MDS节点。

2.4.3 Monitor

监控整个集群的状态，保证集群数据的一致性。

2.5 Ceph相关组件介绍

• Object

  Ceph最底层的存储最小单位是Object–对象，每个Object包含元数据和原始数据。

• PG

  PG全称Placement Groups，是一个逻辑的概念，一个PG包含多个OSD。引入PG这一层其实是为了更好的分配数据和定位数据。

• CRUSH

  CRUSH是Ceph使用的数据分布算法，类似一致性哈希，让数据分配到预期的地方。

• RBD

  RBD全称RADOS block device，是Ceph对外提供的块设备服务。

• RGW

  RGW全称RADOS gateway，是Ceph对外提供的对象存储服务，接口与S3和Swift兼容。

• CephFS 文件存储

  CephFS全称Ceph File System，是Ceph对外提供的分布式文件存储服务。

• Ceph对象存储

  使用Ceph对象网关守护进程（radosgw），它是用于与Ceph存储群集进行交互的HTTP服务器。由于它提供与OpenStack Swift和Amazon S3兼容的接口，Ceph对象网关可以将数据存储在用于存储来自Ceph文件系统客户端或Ceph块设备客户端的数据的同一Ceph存储群集中。S3和Swift API共享一个公共的名称空间，因此您可以使用一个API编写数据，而使用另一个API检索数据。

• CEPH 块存储

  Ceph 块设备是精简配置的、大小可调且将数据条带化存储到集群内的多个 OSD 。 Ceph 块设备利用 RADOS 的多种能力，如快照、复制和一致性。 Ceph 的 RADOS 块设备（ RBD ）使用内核模块或 librbd 库与 OSD 交互。

2.6 Ceph数据的存储过程

无论使用哪种存储方式（对象、块、挂载），存储的数据都会被切分成对象（Objects）。Objects size大小可以由管理员调整，通常为2M或4M。每个对象都会有一个唯一的OID，由ino与ono生成，ino即是文件的File ID，用于在全局唯一标示每一个文件，而ono则是分片的编号。比如：一个文件FileID为A，它被切成了两个对象，一个对象编号0，另一个编号1，那么这两个文件的oid则为A0与A1。Oid的好处是可以唯一标示每个不同的对象，并且存储了对象与文件的从属关系。由于ceph的所有数据都虚拟成了整齐划一的对象，所以在读写时效率都会比较高。

但是对象并不会直接存储进OSD中，因为对象的size很小，在一个大规模的集群中可能有几百到几千万个对象。这么多对象光是遍历寻址，速度都是很缓慢的；并且如果将对象直接通过某种固定映射的哈希算法映射到osd上，当这个osd损坏时，对象无法自动迁移至其他osd上面。为了解决这些问题，ceph引入了归置组的概念，即PG。

PG是一个逻辑概念，我们linux系统中可以直接看到对象，但是无法直接看到PG。它在数据寻址时类似于数据库中的索引：每个对象都会固定映射进一个PG中，所以当我们要寻找一个对象时，只需要先找到对象所属的PG，然后遍历这个PG就可以了，无需遍历所有对象。而且在数据迁移时，也是以PG作为基本单位进行迁移，ceph不会直接操作对象。

对象时如何映射进PG的？还记得OID么？首先使用静态hash函数对OID做hash取出特征码，用特征码与PG的数量去模，得到的序号则是PGID。最后PG会根据管理员设置的副本数量进行复制，然后通过crush算法存储到不同的OSD节点上（其实是把PG中的所有对象存储到节点上），第一个osd节点即为主节点，其余均为从节点。