ceph工作原理及安装

一、概述

Ceph是一个分布式存储系统，诞生于2004年，最早致力于开发下一代高性能分布式文件系统的项目。随着云计算的发展，ceph乘上了OpenStack的春风，进而成为了开源社区受关注较高的项目之一。
Ceph有以下优势：

1. CRUSH算法

Crush算法是ceph的两大创新之一，简单来说，ceph摒弃了传统的集中式存储元数据寻址的方案，转而使用CRUSH算法完成数据的寻址操作。CRUSH在一致性哈希基础上很好的考虑了容灾域的隔离，能够实现各类负载的副本放置规则，例如跨机房、机架感知等。Crush算法有相当强大的扩展性，理论上支持数千个存储节点。

2. 高可用

Ceph中的数据副本数量可以由管理员自行定义，并可以通过CRUSH算法指定副本的物理存储位置以分隔故障域，支持数据强一致性； ceph可以忍受多种故障场景并自动尝试并行修复。

3. 高扩展性

Ceph不同于swift，客户端所有的读写操作都要经过代理节点。一旦集群并发量增大时，代理节点很容易成为单点瓶颈。Ceph本身并没有主控节点，扩展起来比较容易，并且理论上，它的性能会随着磁盘数量的增加而线性增长。

4. 特性丰富

Ceph支持三种调用接口：对象存储，块存储，文件系统挂载。三种方式可以一同使用。在国内一些公司的云环境中，通常会采用ceph作为openstack的唯一后端存储来提升数据转发效率。

二、CEPH的基本结构

Ceph的基本组成结构如下图：

Ceph的底层是RADOS，RADOS本身也是分布式存储系统，CEPH所有的存储功能都是基于RADOS实现。RADOS采用C++开发，所提供的原生Librados API包括C和C++两种。Ceph的上层应用调用本机上的librados API，再由后者通过socket与RADOS集群中的其他节点通信并完成各种操作。

RADOS GateWay、RBD其作用是在librados库的基础上提供抽象层次更高、更便于应用或客户端使用的上层接口。其中，RADOS GW是一个提供与Amazon S3和Swift兼容的RESTful API的gateway，以供相应的对象存储应用开发使用。RBD则提供了一个标准的块设备接口，常用于在虚拟化的场景下为虚拟机创建volume。目前，Red Hat已经将RBD驱动集成在KVM/QEMU中，以提高虚拟机访问性能。这两种方式目前在云计算中应用的比较多。

CEPHFS则提供了POSIX接口，用户可直接通过客户端挂载使用。它是内核态的程序，所以无需调用用户空间的librados库。它通过内核中的net模块来与Rados进行交互。

三、Ceph的基本组件

如上图所示，Ceph主要有三个基本进程

Osd

用于集群中所有数据与对象的存储。处理集群数据的复制、恢复、回填、再均衡。并向其他osd守护进程发送心跳，然后向Mon提供一些监控信息。
当Ceph存储集群设定数据有两个副本时（一共存两份），则至少需要两个OSD守护进程即两个OSD节点，集群才能达到active+clean状态。
MDS(可选)

为Ceph文件系统提供元数据计算、缓存与同步。在ceph中，元数据也是存储在osd节点中的，mds类似于元数据的代理缓存服务器。MDS进程并不是必须的进程，只有需要使用CEPHFS时，才需要配置MDS节点。
Monitor

监控整个集群的状态，维护集群的cluster MAP二进制表，保证集群数据的一致性。ClusterMAP描述了对象块存储的物理位置，以及一个将设备聚合到物理位置的桶列表。

四、OSD

首先描述一下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的数量多寡直接决定了数据分布的均匀性，所以合理设置的PG数量可以很好的提升CEPH集群的性能并使数据均匀分布。

最后PG会根据管理员设置的副本数量进行复制，然后通过crush算法存储到不同的OSD节点上（其实是把PG中的所有对象存储到节点上），第一个osd节点即为主节点，其余均为从节点。

下面是一段ceph中的伪代码,简要描述了ceph的数据存储流程


locator = object_name
obj_hash =  hash(locator)
pg = obj_hash % num_pg
osds_for_pg = crush(pg)    # returns a list of osds
primary = osds_for_pg[0]
replicas = osds_for_pg[1:]

上图中更好的诠释了ceph数据流的存储过程，数据无论是从三中接口哪一种写入的，最终都要切分成对象存储到底层的RADOS中。逻辑上通过算法先映射到PG上，最终存储近OSD节点里。图中除了之前介绍过的概念之外多了一个pools的概念。

Pool是管理员自定义的命名空间，像其他的命名空间一样，用来隔离对象与PG。我们在调用API存储即使用对象存储时，需要指定对象要存储进哪一个POOL中。除了隔离数据，我们也可以分别对不同的POOL设置不同的优化策略，比如副本数、数据清洗次数、数据块及对象大小等。

OSD是强一致性的分布式存储，它的读写流程如下图

　　Ceph的读写操作采用主从模型，客户端要读写数据时，只能向对象所对应的主osd节点发起请求。主节点在接受到写请求时，会同步的向从OSD中写入数据。当所有的OSD节点都写入完成后，主节点才会向客户端报告写入完成的信息。因此保证了主从节点数据的高度一致性。而读取的时候，客户端也只会向主osd节点发起读请求，并不会有类似于数据库中的读写分离的情况出现，这也是出于强一致性的考虑。由于所有写操作都要交给主osd节点来处理，所以在数据量很大时，性能可能会比较慢，为了克服这个问题以及让ceph能支持事物，每个osd节点都包含了一个journal文件，稍后介绍。

数据流向介绍到这里就告一段落了，现在终于回到正题：osd进程。在ceph中，每一个osd进程都可称作是一个osd节点，也就是说，每台存储服务器上可能包含了众多的osd节点，每个osd节点监听不同的端口，类似于在同一台服务器上跑多个mysql或redis。每个osd节点可以设置一个目录作为实际存储区域，也可以是一个分区，一整块硬盘。如下图，当前这台机器上跑了两个osd进程，每个osd监听4个端口，分别用于接收客户请求、传输数据、发送心跳、同步数据等操作。

如上图所示，osd节点默认监听tcp的6800到6803端口，如果同一台服务器上有多个osd节点，则依次往后排序。

在生产环境中的osd最少可能都有上百个，所以每个osd都有一个全局的编号，类似osd0，osd1，osd2........序号根据osd诞生的顺序排列，并且是全局唯一的。存储了相同PG的osd节点除了向mon节点发送心跳外，还会互相发送心跳信息以检测pg数据副本是否正常。

之前在介绍数据流向时说过，每个osd节点都包含一个journal文件，如下图：

　　默认大小为5G，也就说每创建一个osd节点，还没使用就要被journal占走5G的空间。这个值是可以调整的，具体大小要依osd的总大小而定。

Journal的作用类似于mysql innodb引擎中的事物日志系统。当有突发的大量写入操作时，ceph可以先把一些零散的，随机的IO请求保存到缓存中进行合并，然后再统一向内核发起IO请求。这样做效率会比较高，但是一旦osd节点崩溃，缓存中的数据就会丢失，所以数据在还未写进硬盘中时，都会记录到journal中，当osd崩溃后重新启动时，会自动尝试从journal恢复因崩溃丢失的缓存数据。因此journal的io是非常密集的，而且由于一个数据要io两次，很大程度上也损耗了硬件的io性能，所以通常在生产环境中，使用ssd来单独存储journal文件以提高ceph读写性能。

五、monitor节点

Mon节点监控着整个ceph集群的状态信息，监听于tcp的6789端口。每一个ceph集群中至少要有一个Mon节点，官方推荐每个集群至少部署三台。Mon节点中保存了最新的版本集群数据分布图（cluster map）的主副本。客户端在使用时，需要挂载mon节点的6789端口，下载最新的cluster map，通过crush算法获得集群中各osd的IP地址，然后再与osd节点直接建立连接来传输数据。所以对于ceph来说，并不需要有集中式的主节点用于计算与寻址，客户端分摊了这部分工作。而且客户端也可以直接和osd通信，省去了中间代理服务器的额外开销。

Mon节点之间使用Paxos算法来保持各节点cluster map的一致性；各mon节点的功能总体上是一样的，相互间的关系可以被简单理解为主备关系。如果主mon节点损坏，其他mon存活节点超过半数时，集群还可以正常运行。当故障mon节点恢复时，会主动向其他mon节点拉取最新的cluster map。

Mon节点并不会主动轮询各个osd的当前状态，相反，osd只有在一些特殊情况才会上报自己的信息，平常只会简单的发送心跳。特殊情况包括：1、新的OSD被加入集群；2、某个OSD发现自身或其他OSD发生异常。Mon节点在收到这些上报信息时，则会更新cluster map信息并加以扩散。

cluster map信息是以异步且lazy的形式扩散的。monitor并不会在每一次cluster map版本更新后都将新版本广播至全体OSD，而是在有OSD向自己上报信息时，将更新回复给对方。类似的，各个OSD也是在和其他OSD通信时，如果发现对方的osd中持有的cluster map版本较低，则把自己更新的版本发送给对方。

六、MDS

Mds是ceph集群中的元数据服务器，而通常它都不是必须的，因为只有在使用cephfs的时候才需要它，而目在云计算中用的更广泛的是另外两种存储方式。

Mds虽然是元数据服务器，但是它不负责存储元数据，元数据也是被切成对象存在各个osd节点中的，如下图：

在创建CEPHFS时，要至少创建两个POOL，一个用于存放数据，另一个用于存放元数据。Mds只是负责接受用户的元数据查询请求，然后从osd中把数据取出来映射进自己的内存中供客户访问。所以mds其实类似一个代理缓存服务器，替osd分担了用户的访问压力,如下图：

七、cephfs的简易安装

在安装ceph之前推荐把所有的ceph节点设置成无需密码ssh互访，配置hosts支持主机名互访，同步好时间，并关闭iptables和selinux。

１、实验环境说明：

当前实验环境使用了4台主机node1~node4，node1为管理节点。

2、部署工具：

Ceph官方推出了一个用python写的工具 cpeh-deploy，可以很大的简化ceph集群的配置过程，建议大家用用。它的yum仓库地址，下载地址如下：


http://download.ceph.com/rpm-firefly/el6/noarch/

3、安装步骤

在管理主机上安装工具（通常是跳板机）
```
yum install -y ceph-deploy
```
创建工作目录，用于存放生成的配置文件和秘钥等信息
```
Mkdir /ceph；cd /ceph
```

下载yum源,下载地址如下

http://download.ceph.com/rpm-firefly/el6/noarch/

```

在node1~4上把上面的网址设置为yum源
```
yum install –y ceph
```

到管理主机上的/ceph目录操作,创建一个新集群，并设置node1为mon节点

ceph-deploy new node1

执行完毕后，可以看到/ceph目录中生成了三个文件，其中有一个配置文件可以做各种参数优化，据说ceph的优化参数接近1000项。（注意，在osd进程生成并挂载使用后，想修改配置需要使用命令行工具，修改配置文件是无效的，所以需要提前规划好优化的参数。）

在ceph.conf中添加四个最基本的设置


 echo "osd pool default size = 4" >> ceph.conf
 echo "osd_pool_default_min_size = 3" >> ceph.conf
 echo "public network = 192.168.120.0/24" >> ceph.conf
 echo "cluster network =  10.0.0.0/8" >> ceph.conf

 设置每个pool默认的副本数是两个（所有文件一共存四份，如果不设置此项则默认为三份副本）；设置最小副本数为3，也就是说，4份副本的环境下有一个副本损坏了，其他osd可以照常相应用户的读写请求；设置公共网络地址段，即用于相应客户读写的网段；设置集群工作网段，用于集群同步数据、发送心跳等使用的网段。

激活监控节点
```
 ceph-deploy mon create-initial
```

接下来创建osd节点，本例中使用整个分区作为osd节点的物理存储区域


ceph-deploy osd prepare node2:/dev/sdb1 node3:/dev/sdb1 node4:/dev/sdb1
ceph-deploy osd prepare node2:/dev/sdb1 node3:/dev/sdb1 node4:/dev/sdb1

将管理节点上的配置文件同步到其他节点上
```
ceph-deploy --overwrite-conf admin node{1..4}
```
建立元数据服务器
```
ceph-deploy mds create node1
```

创建两个池，最后的数字是PG的数量

ceph osd pool create test1 256
ceph osd pool create test2 256

创建cephfs文件系统，注意一个ceph只能创建一个cephfs


ceph fs new cephfs test2 test1

默认第一个池会存储元数据

到此一个简单的cephfs集群就诞生了，可以使用`ceph –s`查看，如果是`HEALTH_OK`状态说明配置成功

八、cephfs的删除

remove所有节点上的ceph
```
ceph-deploy purge node{1..4}
```
清除所有数据


ceph-deploy purgedata node{1..4}

清除所有秘钥文件
```
ceph-deploy forgetkeys
```

九、结语

目前来说，ceph在开源社区还是比较热门的，但是更多的是应用于云计算的后端存储。官方推荐使用ceph的对象式存储，速度和效率都比较高，而cephfs官方并不推荐直接在生产中使用。以上介绍的只是ceph的沧海一粟，ceph远比上面介绍的要复杂，而且支持很多特性，比如使用纠删码就行寻址，所以大多数在生产环境中使用ceph的公司都会有专门的团队对ceph进行二次开发，ceph的运维难度也比较大。但是经过合理的优化之后，ceph的性能和稳定性都是值得期待的。

ceph工作原理及安装

一、概述

1. CRUSH算法

2. 高可用

3. 高扩展性

4. 特性丰富

二、CEPH的基本结构

Ceph的基本组成结构如下图：

三、Ceph的基本组件

如上图所示，Ceph主要有三个基本进程

Osd

MDS(可选)

Monitor

四、OSD

首先描述一下ceph数据的存储过程，如下图：

下面是一段ceph中的伪代码,简要描述了ceph的数据存储流程

OSD是强一致性的分布式存储，它的读写流程如下图

之前在介绍数据流向时说过，每个osd节点都包含一个journal文件，如下图：

五、monitor节点

推荐使用以下的架构

六、MDS

七、cephfs的简易安装

１、实验环境说明：

2、部署工具：

3、安装步骤

在管理主机上安装工具（通常是跳板机）

创建工作目录，用于存放生成的配置文件和秘钥等信息

下载yum源,下载地址如下

在node1~4上把上面的网址设置为yum源

到管理主机上的/ceph目录操作,创建一个新集群，并设置node1为mon节点

在ceph.conf中添加四个最基本的设置

激活监控节点

接下来创建osd节点，本例中使用整个分区作为osd节点的物理存储区域

将管理节点上的配置文件同步到其他节点上

建立元数据服务器

创建两个池，最后的数字是PG的数量

创建cephfs文件系统，注意一个ceph只能创建一个cephfs

到此一个简单的cephfs集群就诞生了，可以使用ceph –s查看，如果是HEALTH_OK状态说明配置成功

八、cephfs的删除

remove所有节点上的ceph

清除所有数据

清除所有秘钥文件

九、结语

你可能感兴趣的:(ceph工作原理及安装)

到此一个简单的cephfs集群就诞生了，可以使用`ceph –s`查看，如果是`HEALTH_OK`状态说明配置成功