作为虚拟币行业人士而言，我们经常都会说到ceph集群时有很多细节是需要注意的。你知道ceph集群部署？今天就让小编跟你们说说吧！

本教程用官网最近的cephadm来搭建ceph集群。

第一周作业：1.ceph的组件和功能2.ceph的数据读写流程3.使用ceph-deploy安装一个最少三个节点的ceph集群 推荐3个或以上的磁盘作为专用osd 4.测试ceph的rbd使用

1·Ceph组件和功能

组件

Ceph OSDs : ( Ceph OSD ）object storage daemon的功能是存储数据，处理数据的复制、恢复、回填、再均衡，并通过检查其他OSD 守护进程的心跳来向 Ceph Monitors 提供一些监控信息。当 Ceph 存储集群设定为有2个副本时，至少需要2个 OSD 守护进程，集群才能达到 active+clean 状态（ Ceph 默认有3个副本，但你可以调整副本数）。

Monitors : 维护着展示集群状态的各种图表，包括监视器图、 OSD 图、归置组（ PG ）图、和 CRUSH 图。 Ceph 保存着发生在Monitors 、 OSD 和 PG上的每一次状态变更的历史信息（称为 epoch ）。

MDSs : Ceph 元数据服务器为 Ceph 文件系统存储元数据（也就是说，Ceph 块设备和 Ceph 对象存储不使用MDS ）。元数据服务器使得 POSIX 文件系统的用户们，可以在不对 Ceph 存储集群造成负担的前提下，执行诸如 ls、find 等基本命令。

CephMgr ：在一个主机上的守护进程，负责运行指标，运行状态，性能负载，

其他术语：

RADOS：多个主机组成的存储集群，即可靠，自动化，分布式的对象存储系统。

File:? 就是普通文件，ObjectRADOS看到的对象，Object与File的区别是， Object的最大尺寸由RADOS限定(通常为2MB或4MB) ，以便实现底层存储的组织管理。因此，当上层应用向RADOS存入尺寸很大的File时，需要将File切分成统一大小的一系列Objet (最后一个的大小可以不同)进行存储。

librados：RADOS集群的API，支持大部分主流语言。

Pool：存储池，大小取决于底层的存储空间。

PG：placeholder group，一个pool（存储池）内可以有多个PG，pool个pg都是抽象的逻辑概念，可以通过公示计算。PG的用途是对Object的存储进行组织和位置映射的。具体而言，一个PG负责组织若干个Object，但一个Obiect只能被映射到一个PG中，即PG和Object之间是“一对多”的映射关系。同时，一个PG会被映射到n个OSD上，而每个OSD上都会承载大量的PG，即PG和OSD之间是“多对多”的映射关系。在实践当中，n至少为2，如果用于生产环境，则至少为3。一个OSD上的PG可达到数百个。事实上， PG数量的设置关系到数据分布的均匀性问题。

OSD daemon：默认每2秒发送状态数据给monitor，（同时监控组内其他OSD的状态）（up 可以提供IO，down不能提供，in有数据，out没有数据）

PG和OSD之间的关系通过CRUSH算法得出的。常规这三个 OSD daemon 可以在一台机器上，也可以在不同机器上；那么根据 CRUSH 算法会尽可能的保证一个平衡，就是不在同一个机器上；毕竟Ceph中的数据是一个为平衡的状态，一切都是通过CRUSH 算法来实现的数据平衡，而 PG 本身是个有序列表，位于第一的位置是 master；这个列表的产生是由 monitor 来产生的；

寻址流程

File-Object映射 这次映射的目的是，将用户要操作的File映射为RADOS能够处理的Object，其十分简单，本质上就是按照Object的最大尺寸（默认4M）对File进行切分，相当于磁盘阵列中的条带化过程。这种切分的好处有两个:一是让大小不限的File变成具有一致的最大尺寸、可以被RADOS高效管理的Object;二是让对单一File实施的串行处理变为对多个Object实施的并行化处理。每一个切分后产生的Object将获得唯一的oid,即Object ID,其产生方式也是线性映射,极其简单。 Object →PG映射 在File被映射为1个或多个Object之后,就需要将每个Object独立地映射到1个PG中去。这个映射过程也很简单,如图所示,其计算公式如下:Hash(oid) mask – pgid由此可见,其计算由两步组成。首先,使用Ceph系统指定的一个静态哈希算法计算oid的哈希值,将oid映射为一个近似均匀分布的伪随机值。然后,将这个伪随机值和mask按位相与,得到最终的PG序号(pgid) 。根据RADOS的设计,给定PG的总数为m(m应该为2的整数幂),则mask的值为m-1。因此,哈希值计算和按位与操作的整体结果事实上是从所有m个PG中近似均匀地随机选择1个。基于这一机制,当有大量Object和大量PG时, RADOS能够保证Object和PG之间的近似均匀映射。又因为Object是由File切分而来的,大部分Object的尺寸相同,因此,这一映射最终保证了各个PG中存储的Object的总数据量近似均匀。这里反复强调了“大量” ,意思是只有当Object和PG的数量较多时,这种伪随机关系的近似均匀性才能成立, Ceph的数据存储均匀性才有保证。为保证“大量”的成立,一方面, Object的最大尺寸应该被合理配置,以使得同样数量的File能够被切分成更多的Object;另一方面, Ceph也推荐PG总数应该为OSD总数的数百倍,以保证有足够数量的PG可供映射。 PG→ OSD映射 第3次映射就是将作为Object的逻辑组织单元的PG映射到数据的实际存储单元OSD上。RADOS采用一个名为CRUSH的算法,将pgid代入其中,然后得到一组共n个OSD。这n个OSD共同负责存储和维护一个PG中的所有Objecto前面提到过, n的数值可以根据实际应用中对于可靠性的需求而配置,在生产环境下通常为3。具体到每个OSD,则由其上运行的OSD Daemon负责执行映射到本地的Object在本地文件系统中的存储、访问、元数据维护等操作。和“Object →PG”映射中采用的哈希算法不同, CRUSH算法的结果不是绝对不变的,而会受到其他因素的影响。其影响因素主要有两个。一是当前系统状态,也就是在前面有所提及的集群运行图。当系统中的OSD状态、数量发生变化时,集群运行图也可能发生变化,而这种变化将会影响到PG与OSD之间的映射关系。二是存储策略配置。这里的策略主要与安全相关。利用策略配置,系统管理员可以指定承载同一个PG的3个OSD分别位于数据中心的不同服务器或机架上,从而进一步改善存储的可靠性。因此,只有在系统状态和存储策略都不发生变化的时候, PG和OSD之间的映射关系才是固定不变的。在实际使用中,策略一经配置通常不会改变。而系统状态的改变或是因为设备损坏,或是因为存储集群规模扩大。好在Ceph本身提供了对这种变化的自动化支持,因而,即便PG与OSD之间的映射关系发生了变化,也并不会对应用产生影响。事实上, Ceph正是利用了CRUSH算法的动态特性,可以将一个PG根据需要动态迁移到不同的OSD组合上,从而自动化地实现高可靠性、数据分布再平衡等特性。之所以在此次映射中使用CRUSH算法,而不使用其他哈希算法,一方面原因是CRUSH算法具有上述可配置特性,可以根据管理员的配置参数决定OSD的物理位置映射策略;另一方面原因是CRUSH算法具有特殊的“稳定性” ,也即,当系统中加入新的OSD,导致系统规模增大时,大部分PG与OSD之间的映射关系不会发生改变,只有少部分PG的映射关系会发生变化并引发数据迁移。这种可配置性和稳定性都不是普通哈希算法所能提供的。因此, CRUSH算法的设计也是Ceph的核心内容之一。 至此为止, Ceph通过3次映射,完成了从File到Object. Object到PG,PG再到OSD的整个映射过程。从整个过程可以看到,这里没有任何的全局性查表操作需求。至于唯一的全局性数据结构:集群运行图。它的维护和操作都是轻量级的,不会对系统的可扩展性、性能等因素造成影响 。

存储过程总结：

1.计算文件到对象的映射

2.通过哈希算法计算计算出文件对应的pool的PG

3.通过CRUSH把对象映射到PG中的OSD

4.PG种的OSD将对象写入到磁盘

5.主OSD将数据同步到备份OSD，待备份OSD返回确认

6.主OSD的到备份OSD写完操作以后给客户的返回写入成功

2. ceph的读写流程

当某个客户端需要向Ceph集群写入一个File时，首先需要在本地完成寻址流程，将File变为一个Object，然后找出存储该Object的一组共3个OSD，这3个OSD具有各自不同的序号，序号最靠前的那个OSD就是这一组中的Primary OSD，而后两个则依次Secondary OSD和Tertiary OSD。找出3个OSD后，客户端将直接和Primary OSD进行通信，发起写入操作(步骤1)。 Primary OSD收到请求后，分别向Secondary OSD和Tertiary OSD发起写人操作(步骤2和步骤3)。当Secondary OSD和Tertiary OSD各自完成写入操作后，将分别向Primary OSD发送确认信息(步骤4和步骤5)。当Primary OSD确认其他两个OSD的写入完成后，则自己也完成数据写入，并向客户端确认Object写入操作完成(步骤6)。之所以采用这样的写入流程，本质上是为了保证写入过程中的可靠性，尽可能避免出现数据丢失的情况。同时，由于客户端只需要向Primary OSD发送数据，因此在互联网使用场景下的外网带宽和整体访问延迟又得到了一定程度的优化。当然，这种可靠性机制必然导致较长的延迟，特别是，如果等到所有的OSD都将数据写入磁盘后再向客户端发送确认信号，则整体延迟可能难以忍受。因此， Ceph可以分两次向客户端进行确认。当各个OSD都将数据写入内存缓冲区后，就先向客户端发送一次确认，此时客户端即可以向下执行。待各个OSD都将数据写入磁盘后，会向客户端发送一个最终确认信号，此时客户端可以根据需要删除本地数据。分析上述流程可以看出，在正常情况下，客户端可以独立完成OSD寻址操作，而不必依赖于其他系统模块。因此，大量的客户端可以同时和大量的OSD进行并行操作。同时，如果一个File被切分成多个Object，这多个Object也可被并行发送至多个OSD上。从OSD的角度来看，由于同一个OSD在不同的PG中的角色不同，因此，其工作压力也可以被尽可能均匀地分担，从而避免单个OSD变成性能瓶颈。

问：为什么要设计三层映射而不是一层？

答：如果将object直接映射到一组OSD上，如果这种算法是固定的哈希算法，则意味着一个object被固定映射在一组OSD上，当其中一个OSD损坏时，object也无法部署到新的OSD上(因为映射函数不允许)。

如果设计一个动态算法(例如CRUSH算法)来完成这一映射，结果将是各个OSD所处理的本地元数据暴增，由此带来的计算复杂度和维护工作量也是难以承受的。

综上所诉，引入PG的好处至少有二：一方面试下呢object和OSD之间的动态映射，从而为Ceph的可靠性、自动化等特性的实现留下了空间；另一方面也有效简化了数据的存储组织，大大降低了系统的维护管理开销。

1.准备工作

时间同步`

安装ntpdate（时间同步工具）

# apt install ntpate

0* * * * ntpdate time1.aliyun.com

echo’0 * * * * ntpdate time1.aliyun.com’ /var/spool/cron/crontabs/root

或者 可以通过

ansible all-mshell-a”echo? ‘0 * * * * ntpdate time1.aliyun.com’ /var/spool/cron/crontabs/root”

关闭 selinux 和防火墙

root@node1:~# sudo ufw status? ##查看状态

Status: inactive

root@node1:~# sudo ufw disable

Firewall stopped and disabled on system startup##禁用

root@node1:~#

配置域名解析或通过 DNS 解析

root@node1:~# cat /etc/hosts

127.0.0.1 localhost

root@node1:~# hostnamectl set-hostname 对应的名称

## 以下是新增的 可以按照自己的习惯配置

192.168.106.101? node1

192.168.106.102? node2

192.168.106.103? node3

安装python

root@node1:~# apt install python? ##python2

源修改成国内源? — 具体步骤自行百度

阿里云镜像仓库

网易镜像仓库

清华大学镜像源

ceph用到的端口 (防火墙和安全中记得放开)

Ceph Monitor：启用 Ceph MON 服务或端口 6789 (TCP)。

Ceph OSD 或元数据服务器：启用 Ceph OSD/MDS 服务或端口 6800-7300 (TCP)。

iSCSI 网关：打开端口 3260 (TCP)。

对象网关：打开对象网关通讯所用的端口。此端口在 /etc/ceph.conf 内以 rgw frontends = 开头的行中设置。HTTP 的默认端口为 80，HTTPS (TCP) 的默认端口为 443。

NFS Ganesha：默认情况下，NFS Ganesha 使用端口 2049（NFS 服务、TCP）和 875 （rquota 支持、TCP）。

SSH：打开端口 22 (TCP)。

NTP：打开端口 123 (UDP)。

2.搭建ceph集群

安装cephadm

root@node1:~#? wget ## node1 管理节点上执行

root@node1:~#? chmod +x cephadm

root@node1:~# add-repo –release pacific? ##设置要安装的版本

root@node1:~#? which cephadm ? ##确认是否安装成功

初始化集群

root@node1:~# cephadm bootstrap –mon-ip 192.168.106.101 ? ##ceph集群第一个节点的ip

初始化完了以后就可以访问dashboard了 地址 ： 访问用户密码上一步生成

添加其他节点和其他组件

root@node1:~# ssh-keygen

## 配置免密通信

root@node1:~#? ssh-copy-id -f -i /etc/ceph/ceph.pub root@node2

root@node1:~#? ssh-copy-id -f -i /etc/ceph/ceph.pub root@node3

## 添加node

root@node1:~#? ceph orch host add node2 192.168.106.102

root@node1:~#? ceph orch host add node3 192.168.106.103

## 添加osd

root@node1:~#? ceph orch daemon add osd node1:/dev/sdb

root@node1:~#? ceph orch daemon add osd node1:/dev/sdb

root@node1:~#? ceph orch daemon add osd node3:/dev/sdb

测试

root@node1:~#? ceph fs volume create testfs? ##添加测试fs

root@node1:~#? ceph orch apply mds testfs –placement=”3″ ##设置备份数

root@node1:~# ? ceph orch daemon add mds testfs node1

root@node1:~# ? ceph mds stat

## 在集群之外的或者任意机器上操作

root@node4:~#? apt install ceph-common -y

node1初始化集群的节点操作

root@node1:~#? scp /etc/ceph/ceph.client.admin.keyring user@node4:/etc/ceph

##? 集群之外的clinet或者测试节点执行

root@node4:~#? mount -t ceph node1:/ /mnt/testfs -o name=admin,secret=AQAoJjBh7OPVNhAAQZyzLhDfgSj+KPmeU5RVlA==,fs=testfs ?

root@node4:~#? mount -t ceph node2:/ /mnt/cephfs -o name=admin,secret=AQAoJjBh7OPVNhAAQZyzLhDfgSj+KPmeU5RVlA==,fs=testfs

root@node4:~#? df -h

Filesystem ? ? ? ? ? ? ? ?? Size? Used Avail Use% Mounted on

udev1.4G01.4G0% /dev

tmpfs ? ? ? ? ? ? ? ? ? ? ? 293M1.2M? 292M1% /run

….

192.168.106.101:/ ? ? ? ? ?? 18G 1000M ? 17G6% /mnt/testfs

192.168.106.102:/ ? ? ? ? ?? 18G 1000M ? 17G6% /mnt/cephfs

root@node4:~#? cd /mnt/cephfs

root@node4:/mnt/cephfs#? dd if=/dev/zero of=test bs=1M count=100 ##生成文件

这时候文件是直接写在ceph集群上看了， 可以通过dashboard观察?。

目前ceph 12、14版本官方建议使用ansible代替ceph-deploy进行组件部署。

用户管理

用户创建

执行下面的命令新建一个用户 (S3 接口):

实例如下:

获取用户信息

要获取一个用户的信息，你必须使用user info子命令并且制定一个用户ID(—uid={username}) .

修改用户信息

要修改一个用户的信息，你必须指定用户的ID (—uid={username})，还有 你想要修改的属性值。典型的修改项主要是access和secret密钥，邮件地址，显示名称和访问级别。举例如下:

用户启用/停用

当你创建了一个用户，用户默认情况下是处于启用状态的。然而，你可以暂停用户权限并在以后随时重新启用它们。暂停一个用户，使用user suspend子命令然后指定用户的 ID:

要重新启用已经被停用的用户，使用 user enable 子命令并指明用户的 ID.

新建一个密钥

要为用户新建一个密钥，你需要使用key create子命令。对于用户来说，需要指明用户的ID以及新建的密钥类型为s3。要为子用户新建一个密钥，则需要指明子用户的 ID以及密钥类型为swift。实例如下:

新建/删除 ACCESS 密钥

用户和子用户要能使用S3和Swift接口，必须有access密钥。在你新建用户或者子用户的时候，如果没有指明access和secret密钥，这两个密钥会自动生成。你可能需要新建access和/或secret密钥，不管是手动指定还是自动生成的方式。你也可能需要删除一个access和secret。可用的选项有：

删除用户

删除用户时，这个用户以及他的子用户都会被删除。当然，如果你愿意的话可以只删除子用户。要删除用户（及其子用户），可使用user rm子命令并指明用户ID：

只想删除子用户时，可使用 subuser rm 子命令并指明子用户ID。

添加/删除管理权限

Ceph存储集群提供了一个管理API，它允许用户通过REST API执行管理功能。默认情况下，用户没有访问这个API的权限。要启用用户的管理功能，需要为用户提供管理权限。

执行下面的命令为一个用户添加管理权限:

你可以给一个用户添加对用户、bucket、元数据和用量(存储使用信息)等数据的 读、写或者所有权限。举例如下:

实例如下:

要删除某用户的管理权限，可用下面的命令：

展示用户列表

radosgw-admin user list

配额管理

设置用户配额

在你启用用户的配额前 ，你需要先设置配额参数。例如:

实例如下:

最大对象数和最大存储用量的值是负数则表示不启用指定的配额参数。

设置 BUCKET 配额

Bucket 配额作用于用户的某一个 bucket，通过 uid 指定用户。这些配额设置是独立于用户之外的。:

最大对象数和最大存储用量的值是负数则表示不启用指定的配额参数。

启用/禁用用户配额

在你设置了用户配额之后，你可以启用这个配额。实例如下:

你也可以禁用已经启用了配额的用户的配额。举例如下:

读取/写入全局配额

你可以在period配置中读取或写入全局配额设置，查看全局配额配置可以用：

全局配额选项可以用global quota系列命令修改，如quota set、quota enable和quota disable命令。

需要重启集群才能生效

部署方法

本文档使用 ceph nautilus 作环境。

使用ansible部署

1.复制group_vars目录下的rgw.yml.sample到该目录下，并修改名字为rgw.yml。

2.rgw.yml中rgw_create_pools项取消注释，ansible会根据配置文件创建对应的池，ceph集群若缺少当中某一个池，rgw进程将无法正常运行。

3.修改池的副本模式、pg_num、size。

1.修改all.yml文件，增加以下条目：

2.修改ini部署文件，增加[rgws]项

这样就能在192.168.216.145、192.168.215.178上部署rgw。

结束语

从上述步骤可以看出ansible部署方法仅需要修改ini文件以及yml即可，部署流程比使用ceph-deploy简单。

以上就是关于今天的全部内容，下期将给大家带来《关于XFS文件系统的简单概述》，敬请期待~

Linux里面ceph

Ceph是一个可靠地、自动重均衡、自动恢复的分布式存储系统，根据场景划分可以将Ceph分为三大块，分别是对象存储、块设备存储和文件系统服务。在虚拟化领域里，比较常用到的是Ceph的块设备存储，比如在OpenStack项目里，Ceph的块设备存储可以对接OpenStack的cinder后端存储、Glance的镜像存储和虚拟机的数据存储，比较直观的是Ceph集群可以提供一个raw格式的块存储来作为虚拟机实例的硬盘。

Ceph相比其它存储的优势点在于它不单单是存储，同时还充分利用了存储节点上的计算能力，在存储每一个数据时，都会通过计算得出该数据存储的位置，尽量将数据分布均衡，同时由于Ceph的良好设计，采用了CRUSH算法、HASH环等方法，使得它不存在传统的单点故障的问题，且随着规模的扩大性能并不会受到影响。

Ceph 是一个开源项目，它提供软件定义的、统一的存储解决方案 。Ceph 是一个具有高性能、高度可伸缩性、可大规模扩展并且无单点故障的分布式存储系统 。

Ceph 是软件定义存储解决方案

Ceph 是统一存储解决方案

Ceph 是云存储解决方案

高可用性

高扩展性

特性丰富

Ceph独一无二地统一的系统提供了对象存储、块存储和文件存储功能。Ceph存储集群由几个不同的软件守护进程组成（比较重要的两个是MON和OSD），每个守护进程负责Ceph的一个独特功能并将值添加到相应的组件中。

RADOS是CEPH存储系统的核心,也称为Ceph 存储集群。Ceph的数据访问方法(如RBD,CephFS,RADOSGW，librados)的所有操作都是在RADOS层之上构建的。当Ceph 集群接收到来自客户端的请求时,CRUSH算法首先计算出存储位置,最后将这些对象存储在OSD中,当配置的复制数大于1时,RADOS负责的形式将数据分发到集群内的所有节点,最后将这些对象存储在OSD中。当配置的复制数大于1时,RADOS负责数据的可靠性,它复制对象，创建副本并将它们存储在不同的故障区域中。

RADOS包含两个核心组件: OSD和MON

OSD 是Ceph 存储集群中最重要的一个基础组件，他负责将实际的数据以对象的形式存储在每一个集群节点的物理磁盘中。对于任何读写操作，客户端首先向MON请求集群MAP，然后客户端旧可以直接和OSD进行I/O操作。

一个Ceph 集群包含多个OSD。一个典型的Ceph集群方案会为集群节点上的每个物理磁盘创建一个ODS守护进程,这个是推荐的做法。OSD上的每个对象都有一个主副本和几个辅副本,辅副本分散在其他OSD。一个OSD对于一些对象是主副本，同时对于其他对象可能是辅副本，存放辅副本的OSD主副本OSD控制,如果主副本OSD异常(或者对应的磁盘故障),辅副本OSD可以成为主副本OSD。

OSD是有一个已经存在的Linux文件系统的物理磁盘驱动器和OSD服务组成。Ceph 推荐OSD使用的文件系统是XFS。OSD的所有写都是先存到日志,再到存储.

MON 负责监控整个集群的健康状况。它以守护进程的形式存在,一个MON为每一个组件维护一个独立的MAP,如OSD，MON,PG,CRUSH 和MDS map。这些map 统称为集群的MAP。MON 不为客户端存储和提供数据,它为客户端以及集群内其他节点提供更新集群MAP的服务。客户端和集群内其他节点定期与MON确认自己持有的是否是集群最新的MAP.一个Ceph集群通常包含多个MON节点,但是同一时间只有一个MON。

librados是一个本地的C语言库，通过它应用程序可以直接和RADOS通信，提高性能

Ceph 块存储，简称 RBD，是基于 librados 之上的块存储服务接口。RBD 的驱动程序已经被集成到 Linux 内核（2.6.39 或更高版本）中，也已经被 QEMU/KVM Hypervisor 支持，它们都能够无缝地访问 Ceph 块设备。Linux 内核 RBD（KRBD）通过 librados 映射 Ceph 块设备，然后 RADOS 将 Ceph 块设备的数据对象以分布式的方式存储在集群节点中

RGW，Ceph对象网关，也称做RADOS网关，它是一个代理，可以将HTTP请求转换为RADOS，也可以把RADOS转换为HTTP请求，从而提供restful接口，兼容S3和Swift。Ceph对象网关使用Ceph对象网关守护进程(RGW)与librgw、librados交互。Ceph对象网关支持三类接口：S3、Swift、管理API（通过restful接口管理Ceph集群）。RGW有自己的用户管理体系

Ceph 元数据服务器服务进程，简称 MDS。只有在启用了 Ceph 文件存储（CephFS）的集群中才需要启用 MDS，它负责跟踪文件层次结构，存储和管理 CephFS 的元数据。MDS 的元数据也是以 Obejct 的形式存储在 OSD 上。除此之外，MDS 提供了一个带智能缓存层的共享型连续文件系统，可以大大减少 OSD 读写操作频率。

CephFS在RADOS层之上提供了一个兼容POSIX的文件系统。它使用MDS作为守护进程，负责管理其元数据并将它和其他数据分开。CephFS使用cephfuse模块（FUSE）扩展其在用户空间文件系统方面的支持（就是将CephFS挂载到客户端机器上）。它还允许直接与应用程序交互，使用libcephfs库直接访问RADOS集群。

Ceph管理器软件，可以收集整个集群的所有状态。有仪表板插件

一个对象通常包含绑定在一起的数据和元数据，并且用一个全局唯一的标识符标识。这个唯一的标识符确保在整个存储集群中没有其他对象使用相同的对象ID，保证对象唯一性。基于文件的存储中，文件大小是有限制的，与此不同的是，对象的大小是可以随着大小可变的元数据而变得很大。对象不使用一个目录层次结构或树结构来存储，相反，它存储在一个包含数十亿对象且没有任何复杂性的线性地址空间中。对象可以存储在本地，也可以存放在地理上分开的线性地址空间中，也就是说，在一个连续的存储空间中。任何应用程序都可以基于对象ID通过调用restful API从对象中获取数据。这个URL可以以同样的方式工作在因特网上，一个对象ID作为一个唯一的指针指向对象。这些对象都以复制的方式存储在OSD中，因为能提供高可用性。

对于Ceph集群的一次读写操作，客户端首先联系MON获取一个集群map副本，然后使用对象和池名/ID将数据转换为对象。接着将对象和PG数一起经过散列来生成其在Ceph池中最终存放的那一个PG。然后前面计算好的PG经过CRUSH查找来确定存储或获取数据所需的主OSD的位置。得到准确的OSD ID之后，客户端直接联系这个OSD来存取数据。所有这些计算操作都由客户端来执行，因此它不会影响Ceph集群的性能。一旦数据被写入主OSD，主OSD所在节点将执行CRUSH查找辅助PG和OSD的位置来实现数据复制，进而实现高可用。

??简单地说，首先基于池ID将对象名和集群PG数应用散列函数得到一个PG ID，然后，针对这个PG ID执行CRUSH查找得到主OSD和辅助OSD，最后写入数据。

PG是一组对象地逻辑集合，通过复制它到不同的OSD上来提供存储系统的可靠性。根据Ceph池的复制级别，每个PG的数据会被复制并分发到Ceph集群的多个OSD上。可以将PG看成一个逻辑容器，这个容器包含多个对象，同时这个逻辑容器被映射到多个OSD。

??计算正确的PG数对一个Ceph存储集群来说是至关重要的一步。PG数计算公式如下

Ceph池是一个用来存储对象的逻辑分区，每个池都包含一定数量的PG，进而实现把一定数量的对象映射到集群内部不同OSD上的目的。每一个池都是交叉分布在集群所有节点上的，这样就能提供足够的弹性。池可以通过创建需要的副本数来保障数据的高可用性。

??Ceph的池还支持快照功能，我们可以使用ceph osd pool mksnap命令来给特定的池制作快照。此外，Ceph池还允许我们为对象设置所有者和访问权限。

数据管理始于客户端向Ceph池中写数据。一旦客户端准备写数据到Ceph池中，数据首先写入基于池副本数的主OSD中。主OSD再复制相同的数据到每个辅助OSD中，并等待它们确认写入完成。只要辅助OSD完成数据写入，就会发送一个应答信号给主OSD。最后主OSD再返回一个应答信号给客户端，以确认完成整个写入操作。

系统的开始使用一个 ceph 集群。

本文将系统的介绍如何使用一个 ceph 集群。

涉及： crush、osd、pool、cache

ceph 版本：nautilus

ceph-deploy 版本：2.0.1

在基本使用需求下，一般需要存储集群提供高性能存储（SSD）和普通存储（hdd）。

在 ceph 中，具体表现为某些池使用高性能存储，某些池使用普通存储。而这种需求在 ceph 中由 crush 规则实现。

ceph 提供了缓存的概念。在普通的存储池之上架设一层高性能的缓存池，外部访问首先到达缓存池，如果发生未命中等情况再去访问存储池。这里需要提一点，并不是任何情况都需要缓存。

针对不同的场景，ceph 的使用方式多种多样，这里的介绍只能一切从简，但是会尽量全面。

一个标准的场景：一个存储池加一个缓存池，存储池使用普通设备，缓存池使用高性能设备。

首先添加一块高性能硬盘（我这里是虚拟环境，只能用普通硬盘充数）

然后需要利用 crush 让不同池使用不同的存储设备

这里只能拿普通的虚拟硬盘来做测试。

在 ceph02 虚拟机上增加一块 30G 的虚拟硬盘。

在 ceph03 虚拟机上增加一块 30G 的虚拟硬盘。

现在到部署节点进行操作：

如图 ceph02 出现了 osd.6，ceph03 出现了 osd.7。

这里涉及到 root （根）的概念，在文章末尾【扩展】中会介绍。这里可以直接先使用。

将 osd.6 osd.7 加入名称为 cache 的根中（根名称会自动创建，注意，由于默认情况下 osd 在启动时读取的是 hostname，因此该方法只是临时生效，在文章末尾【扩展】中会介绍永久生效办法）

“高性能”存储盘现在已经有了，并且将其置于 cache 根下，这么做的意义在下一步中有体现。

现在可以进行下一步了。

当前环境下已经有一个默认的 crush 规则。

具体属性解释参考：

如上图划线处，当前规则只会使用 default 根的 osd。

前面创建高性能设备时，将其设置根为 cache。我们现在就可以创建一个只使用 cache 根中的 osd 的规则，从而实现缓存池和存储池使用不同的设备。

创建缓存池使用的规则：

其中：

replicated_cache 指该规则的名字。

cache 指该规则使用的根。

host 指故障域级别。

再次查看所有规则：

现在我们有了一个只使用高性能存储设备的规则了。下面就可以开始创建使用不同规则的池了。

创建存储池：

查看池：

查看该池的规则：

存储池至此已经好了。

缓存池在 ceph 中常以 hot 标识。

普通存储池在 ceph 中常以 cold 标识。

缓存有多种形式（官方文档列出以下几种，实际更多）：

缓存参考：

创建缓存池

缓存池创建好以后，要将这个缓存池与对应存储池联系起来。这个联系的概念叫做 cache tiering，可以称之为缓存层，缓存代理。

参考：

对于 test_storage 池，我们有一个只读的缓存池了。只要我们读取 test_storage 中的某个对象，这个对象就应该自动的置于缓存池中一段时间。

可以发现，将对象上传回写模式的缓存池，存储池中也出现了对应的数据。

osd 的大小可能不相同，因此其上的数据量也不应该相同，因此引入权重来影响数据分布。

比如100G的 osd 权重为1，则200G的 osd 权重就应设置为2。

ceph osd tree 命令可以看到存储结构。可以结合自己机器执行的结果往下阅读。

一张官方图：

这是描述 ceph 存储结构的一张图。

首先这是一个树形结构。

其中最上层的 root default ：root 是根的意思，default 就是这个根的名字。

中间 host foo ：host 是主机的意思，foo 就是这个主机的名字。这里的主机名仅仅是个别称，不代表实际的主机，可以随意更改。

最下面的就是叶子节点了，具体指向 osd。

划分这三层结构的意义（不完全）：

本文使用 ceph-deploy 添加 osd 时，并没有直接将其设置到最终根下，后续还需要手动配置。这么操作是不合理的，暂时未找到 ceph-deploy 指定根的参数。

当前文章配置的缓存池是2副本的。

某些时候，缓存数据是允许丢失的，比如只读的缓存。这种缓存池单副本即可，但是经测试，单副本池在 ceph 中似乎困难重重。

可以通过修改该机器的 hostname ，一劳永逸

这个时候，当机器重启后，该机器的所有 osd 的 host 名称都一样了，导致 osd tree 混乱。这个时候可以在 ceph.conf 中具体配置某块盘的信息。

当前环境配置参考：

增加如下内容：

重启后，一切正常。

在 osd 的启动上做文章。

比如，配置 osd 的启动方式，容器化 osd，容器会记住某些信息，因此可以实现永久生效 hostname。

osd 上的 pg 数量会对整体集群性能造成影响，并不是越多越好，也不是越少越好。

由于池有副本的概念，因此产生了如下的计算方式：

官方建议每个 osd 上的 pg 数为 100。实际测试每个 osd 上的 pg 数到达 250 时开始告警，因此该集群的总 pg 数不应超过：

因此出现此问题的原因：

所有池的 pg 数加起来超过了设定的 总 pg 数 。但集群依然可正常使用，因此只是一个警告。

解决该问题的手段：

目前个人经验来说，不要使用单副本。

crush 规则参考：

都看完了嘛？相信现在您对ceph集群有一个初级的认识了吧！也可以收藏页面获取更多ceph集群部署知识哟！区块链、虚拟币，我们是认真的！