Ceph 集群基础知识点

一、ceph 集群维护

1.1 通过套接字进行单机管理

查看 node 节点上的套接字文件

[root@ceph-node1 ~]# ll /var/run/ceph/
total 0
srwxr-xr-x 1 ceph ceph 0 Aug  9 00:04 ceph-osd.0.asok
srwxr-xr-x 1 ceph ceph 0 Aug  9 00:05 ceph-osd.1.asok
srwxr-xr-x 1 ceph ceph 0 Aug  9 00:06 ceph-osd.2.asok

[root@ceph-node1 ~]# ceph --admin-socket /var/run/ceph/ceph-osd.0.asok --help

将ceph.client.admin.keyring传到mon节点，以便执行ceph命令

[ceph@ceph-deploy ceph-cluster]$ scp ceph.client.admin.keyring root@10.0.0.14:/etc/ceph/
# 或
[ceph@ceph-deploy ceph-cluster]$ ceph-deploy admin ceph-mon1

认证文件的属主和属组为了安全考虑，默认设置为了 root 用户和 root 组，
如果需要 ceph 用 户也能执行 ceph 命令，那么就需要对 ceph 用户进行授权。

[root@ceph-mon1 ~]# setfacl -m u:ceph:rw /etc/ceph/ceph.client.admin.keyring

查看 mon 节点上的套接字文件

[root@ceph-mon1 ~]# ll /var/run/ceph/
total 0
srwxr-xr-x 1 ceph ceph 0 Aug  8 21:50 ceph-mon.ceph-mon1.asok

[root@ceph-mon1 ~]# ceph --admin-socket /var/run/ceph/ceph-mon.ceph-mon1.asok help    #mon 状态
[root@ceph-mon1 ~]# ceph --admin-daemon /var/run/ceph/ceph-mon.ceph-mon1.asok config show    #查看配置信息

1.2 集群的停止或重启

重启之前，要提前设置 ceph 集群不要将 OSD 标记为 out，避免 node 节点关闭服务后被踢出 ceph 集群外：

[ceph@ceph-deploy ceph-cluster]$ ceph osd set noout    #关闭服务前设置 noout
[ceph@ceph-deploy ceph-cluster]$ ceph osd unset noout    #启动服务后取消 noout

关闭服务的顺序

#关闭服务前设置 noout 
关闭存储客户端停止读写数据 
关闭网关服务，如对象网关 RGW 
关闭元数据服务 
关闭 ceph OSD 
关闭 ceph manager 
关闭 ceph monitor

启动服务的顺序

启动 ceph monitor 
启动 ceph manager 
启动 ceph OSD 
启动元数据服务 
启动网关服务，如对象网关 RGW 
启动存储客户端 
#启动服务后取消 noout-->ceph osd unset noout

二、ceph 配置文件

Ceph 的主配置文件是/etc/ceph/ceph.conf，ceph 服务在启动时会检查 cep.conf，分号;和#在配置文件中都是注释

[global]    #全局配置
[osd]    #osd 专用配置，可以使用 osd.N，来表示某一个 OSD 专用配置，N 为 osd 的编号，如 0、2、1 等。 
[mon]    #mon 专用配置，也可以使用 mon.A 来为某一个 monitor 节点做专用配置，其中 A 为该节点的名称，ceph-monitor-2、ceph-monitor-1 等，使用命令 ceph mon dump 可以获取节点的名称 
[client]    #客户端专用配置。

ceph 文件的加载顺序

$CEPH_CONF 环境变量 
-c 指定的位置 
/etc/ceph/ceph.conf 
~/.ceph/ceph.conf 
./ceph.conf

三、POOL、PG 与 CRUSH

副本池:replicated，定义每个对象在集群中保存为多少个副本，默认为三个副本，一主两从，实现高可用，副本池是 ceph 默认的存储池类型。
纠删码池(erasure code): 把各对象存储为 N=K+M 个块，其中 K 为数据块数量，M 为编码快数量，因此存储池的尺寸为 K+M。
即数据保存在 K 个数据块，并提供 M 个冗余块提供数据高可用，那么最多能故障的块就是 M 个，实际的磁盘占用就是 K+M 块，因此相比副本池机制比较节省存储资源，一般采用 8+4 机制，即 8 个数据块 +4 个冗余块，那么也就是 12 个数据块有 8 个数据块保存数据，有 4 个 实现数据冗余，即 1/3 的磁盘空间用于数据冗余，比默认副本池的三倍冗余节省空间，但是不能出现大于一定数据块故障。
但是不是所有的应用都支持纠删码池，RBD 只支持副本池而 radosgw 则可以支持纠删码池。

3.1 副本池

将一个数据对象存储为多个副本
在客户端写入操作时，ceph 使用 CRUSH 算法计算出与对象相对应的 PG ID 和 primary OSD 主 OSD 根据设置的副本数、对象名称、存储池名称和集群运行图(cluster map)计算出 PG 的 各辅助 OSD，然后由 OSD 将数据再同步给辅助 OSD。

读取数据： 
1. 客户端发送读请求，RADOS 将请求发送到主 OSD。 
2. 主 OSD 从本地磁盘读取数据并返回数据，最终完成读请求。 

写入数据： 
1. 客户端 APP 请求写入数据，RADOS 发送数据到主 OSD。 
2. 主 OSD 识别副本 OSDs，并发送数据到各副本 OSD。 
3. 副本 OSDs 写入数据，并发送写入完成信号给主 OSD。 
4. 主 OSD 发送写入完成信号给客户端 APP。

3.2 纠删码池

Ceph 从 Firefly 版本开始支持纠删码，但是不推荐在生产环境使用纠删码池。
纠删码池降低了数据保存所需要的磁盘总空间数量，但是读写数据的计算成本要比副本池高 RGW 可以支持纠删码池，RBD 不支持。
纠删码池可以降低企业的前期 TCO 总拥有成本。

纠删码写： 数据将在主 OSD 进行编码然后分发到相应的 OSDs 上去。

纠删码读： 从相应的 OSDs 中获取数据后进行解码。

如果此时有数据丢失，Ceph 会自动从存放校验码的 OSD 中读取数据进行解码。

3.3 PG 与 PGP

PG = Placement Group 归置组
PGP = Placement Group for Placement purpose 归置组的组合
pgp 相当于是 pg 对应 osd 的 一种排列组合关系

归置组(placement group)是用于跨越多 OSD 将数据存储在每个存储池中的内部数据结构。
归置组在 OSD 守护进程和 ceph 客户端之间生成了一个中间层，CRUSH 算法负责将每个对象动态映射到一个归置组，然后再将每个归置组动态映射到一个或多个 OSD 守护进程，从而 能够支持在新的 OSD 设备上线时进行数据重新平衡。

相对于存储池来说，PG 是一个虚拟组件，它是对象映射到存储池时使用的虚拟层。 
可以自定义存储池中的归置组数量。 
ceph 出于规模伸缩及性能方面的考虑，ceph 将存储池细分为多个归置组，把每个单独的对 象映射到归置组，并为归置组分配一个主 OSD。 
存储池由一系列的归置组组成，而 CRUSH 算法则根据集群运行图和集群状态，将每个 PG 均 匀、伪随机(基于 hash 映射,每次的计算结果够一样)的分布到集群中的 OSD 之上。 
如果某个 OSD 失败或需要对集群进行重新平衡，ceph 则移动或复制整个归置组而不需要单 独对每个镜像进行寻址。

3.4 PG 与 OSD 的关系

ceph 基于 crush 算法将归置组 PG 分配至 OSD
当一个客户端存储对象的时候，CRUSH 算法映射每一个对象至归置组(PG)

3.5 PG 分配计算

归置组(PG)的数量是由管理员在创建存储池的时候指定的，然后由 CRUSH 负责创建和使用， PG 的数量是 2 的 N 次方的倍数,每个 OSD 的 PG 不要超出 256 个 PG。

1. 通常，PG 的数量应该是数据的合理力度的子集。 例如：一个包含 256 个 PG 的存储池以，每个 PG 包含大约 1/256 的存储池数据。建议每个PG大小最大一两百GB。
2. 当需要将 PG 从一个 OSD 移动到另一个 OSD 的时候，PG 的数量会对性能产生影响。 PG 的数量过少，ceph 将不得不同时移动相当数量的数据，其产生的网络负载将对集群的 性能输出产生一定影响。 PG 过多的时候，ceph 将会占用过多的 CPU 和内存资源用于记录 PG 的状态信息
3. PG 的数量在集群分发数据和重新平衡时扮演者重要的角色作用。在所有 OSD 之间进行数据持久存储以及完成数据分布会需要较多的归置组，但是他们的 数量应该减少到实现 ceph 最大性能所需的最小 PG 数量值，以节省 CPU 和内存资源。

一般来说，对于有着超过 50 个 OSD 的 RADOS 集群，建议每个 OSD 大约有 50*100 个 PG 以平衡资源使用及取得更好的数据持久性和数据分布，而在更大的集群中，每个 OSD 可以 有 100-200 个 PG。

至于一个 pool 应该使用多少个 PG，可以通过下面的公式计算后，将 pool 的 PG 值四舍五 入到最近的 2 的 N 次幂，如下先计算出 ceph 集群的总 PG 数：
Total OSDs * PGPerOSD/replication factor => total PGs
磁盘总数 x 每个磁盘 PG 数/副本数 => ceph 集群总 PG 数(略大于 2^n 次方)

官方的计算公式：
Total PGs = (Total_number_of_OSD * 100) / max_replication_count

单个 pool 的 PG 计算如下：
有 100 个 osd，3 副本，5 个 pool
Total PGs =100*100/3=5000
每个 pool 的 PG=5000/5=1000，那么创建 pool 的时候就指定 pg 为 1024

需要结合数据数量、磁盘数量及磁盘空间计算出 PG 数量，8、16、32、64、128、256 等 2 的 N 次方。

一个 RADOS 集群上会存在多个存储池，因此管理员还需要考虑所有存储池上的 PG 分布后 每个 OSD 需要映射的 PG 数量。

每个PG建议几十个GB或者一两百GB，32个PG，一个100GB，一共能存9600GB

3.6 验证 PG 与 PGP 组合

[ceph@ceph-deploy ceph-cluster]$ ceph pg ls-by-pool mypool 
[ceph@ceph-deploy ceph-cluster]$ ceph pg ls-by-pool mypool | awk '{print $1,$2,$15}'

四、PG 的状态

4.1 Peering

正在同步状态
同一个 PG 中的 OSD 需要将准备数据同步一致，而 Peering(对等)就是 OSD 同步过程中的状态。

4.2 Activating

Peering 已经完成
PG 正在等待所有 PG 实例同步 Peering 的结果(Info、Log 等)

4.3 Clean

干净态
PG 当前不存在待修复的对象，并且大小等于存储池的副本数，即 PG 的活动集(Acting Set)和上行集(Up Set)为同一组 OSD 且内容一致。
活动集(Acting Set)：由 PG 当前主的 OSD 和其余处于活动状态的备用 OSD 组成，当前 PG 内 的 OSD 负责处理用户的读写请求。
上行集(Up Set):在某一个 OSD 故障时，需要将故障的 OSD 更换为可用的 OSD，并主 PG 内部 的主 OSD 同步数据到新的 OSD 上，例如 PG 内有 OSD1、OSD2、OSD3，当 OSD3 故障后需要 用 OSD4 替换 OSD3，那么 OSD1、OSD2、OSD3 就是上行集，替换后 OSD1、OSD2、OSD4 就 是活动集，OSD 替换完成后活动集最终要替换上行集。

4.4 Active

就绪状态或活跃状态
Active 表示主 OSD 和备 OSD 处于正常工作状态，此时的 PG 可以正常 处理来自客户端的读写请求，正常的 PG 默认就是 Active+Clean 状态。

[root@ceph-node1 ~]# ceph pg stat 
224 pgs: 224 active+clean; 303 MiB data, 97 GiB used, 1.1 TiB / 1.2 TiB avail

4.5 Degraded

降级状态
降级状态出现于 OSD 被标记为 down 以后，那么其他映射到此 OSD 的 PG 都会转换到降级状态。
如果此 OSD 还能重新启动完成并完成 Peering 操作后，那么使用此 OSD 的 PG 将重新恢复为 clean 状态。
如果此 OSD 被标记为 down 的时间超过 5 分钟还没有修复，那么此 OSD 将会被 ceph 踢出集 群，然后 ceph 会对被降级的 PG 启动恢复操作，直到所有由于此 OSD 而被降级的 PG 重新恢 复为 clean 状态。
恢复数据会从 PG 内的主 OSD 恢复，如果是主 OSD 故障，那么会在剩下的两个备用 OSD 重 新选择一个作为主 OSD。

一般就是最好有四台node服务器，当一块osd坏掉了，会拿一块新的osd同步数据。

4.6 Stale

过期状态
正常状态下，每个主 OSD 都要周期性的向 RADOS 集群中的监视器(MGR)报告其作为主 OSD 所持有的所有 PG 的最新统计数据，因任何原因导致某个 OSD 无法正常向监视器发送汇报信息的、或者由其他 OSD 报告某个 OSD 已经 down 的时候，则所有以此 OSD 为主 PG 则会立即被标记为 stale 状态，即他们的主 OSD 已经不是最新的数据了，如果是备份的 OSD 发送 down 的时候，则 ceph 会执行修复而不会触发 PG 状态转换为 stale 状态。
遇到这种情况，赶紧加服务器，或者拷贝数据，主的坏掉才会标记成stale，背得坏掉不会标记stale

4.7 undersized

PG 当前副本数小于其存储池定义的值的时候，PG 会转换为 undersized 状态
比如两个备 份 OSD 都 down 了，那么此时 PG 中就只有一个主 OSD 了，不符合 ceph 最少要求一个主 OSD 加一个备 OSD 的要求，那么就会导致使用此 OSD 的 PG 转换为 undersized 状态，直到添加备 份 OSD 添加完成，或者修复完成。

4.8 Scrubbing

scrub 是 ceph 对数据的清洗状态
用来保证数据完整性的机制，Ceph 的 OSD 定期启动 scrub 线程来扫描部分对象，通过与其他副本比对来发现是否一致，如果存在不一致，抛出 异常提示用户手动解决，scrub 以 PG 为单位，对于每一个 pg，ceph 分析该 pg 下所有的 object, 产生一个类似于元数据信息摘要的数据结构，如对象大小，属性等，叫 scrubmap, 比较主与 副 scrubmap，来保证是不是有 object 丢失或者不匹配，扫描分为轻量级扫描和深度扫描， 轻量级扫描也叫做 light scrubs 或者 shallow scrubs 或者 simply scrubs 即轻量级扫描. Light scrub(daily)比较 object size 和属性，deep scrub (weekly)读取数据部分并通过 checksum(CRC32 算法)对比和数据的一致性,深度扫描过程中的 PG 会处于 scrubbing+deep 状态。

4.9 Recovering:

正在恢复态
集群正在执行迁移或同步对象和他们的副本，这可能是由于添加了一个新的 OSD 到集群中或者某个 OSD 宕掉后，PG 可能会被 CRUSH 算法重新分配不同的 OSD，而由于 OSD 更换导致 PG 发生内部数据同步的过程中的 PG 会被标记为 Recovering。

4.10 Backfilling

正在后台填充态
backfill 是 recovery 的一种特殊场景，指 peering 完成后，如果基于当前权 威日志无法对 Up Set（上行集）当中的某些 PG 实例实施增量同步(例如承载这些 PG 实例的 OSD 离线太久，或者是新的 OSD 加入集群导致的 PG 实例整体迁移) 则通过完全拷贝当前 Primary 所有对象的方式进行全量同步，此过程中的 PG 会处于 backfilling。

4.11 Backfill-toofull

某个需要被 Backfill 的 PG 实例，其所在的 OSD 可用空间不足，Backfill 流程当前被挂起时 PG 给的状态
下线满的OSD，让一块更大的OSD磁盘进行数据同步

五、数据读写流程

1、计算 File -> Object 映射（如果 File 为用户要读写的文件）得到 oid(object id) [oid = ino + ono] 
ino:inode number (INO)，File 的元数据序列号，File 的唯一 id。 
ono:object number (ONO)，File 切分产生的某个 object 的序号，默认以 4M 切分一个块大小。 

2、通过一致性 HASH 计算 Object 到 PG， Object -> PG 映射 hash(oid) & mask-> pgid 。 

3、通过 CRUSH 算法计算 PD 到 OSD，PG -> OSD 映射：[CRUSH(pgid)->(osd1,osd2,osd3)]

ceph 读写对象的时候，客户端从 ceph 监视器检索出集群运行图(cluster map)，然后客户端 访问指定的存储池，并对存储池内 PG 的对象执行读写操作。

存储池的 CRUSH 计算结果和 PG 的数量，是决定 ceph 如何放置数据的关键因素。 
基于集群的最新运行图，客户端能够了解到集群中的所有监视器和 OSD 以及他们各自当前的状态。
但是客户端仍然不知道对象的保存位置。

客户端在读写对象时，需要提供的是对象标识和存储池名称。

客户端需要在存储池中读写对象时，需要客户端将对象名称、对象名称的 hash 码、存储池 中的 PG 数量和存储池名称作为输入信息提供给 ceph，然后由 CRUSH 计算出 PG 的 ID 以及 此 PG 针对的主 OSD 即可读写 OSD 中的对象。 
具体写操作如下： 
1.APP 向 ceph 客户端发送对某个对象的请求，此请求包含对象和存储池，然后 ceph 客户端 对访问的对象做 hash 计算，并根据此 hash 值计算出对象所在的 PG，完成对象从 Pool 至 PG 的映射。
APP 访问 pool ID 和 object ID （比如 pool = pool1 and object-id = “name1”） 
ceph client 对 objectID 做哈希 
ceph client 对该 hash 值取 PG 总数的模，得到 PG 编号(比如 32),(第 2 和第 3 步基本保证了 一个 pool 内部的所有 PG 将会被均匀地使用） 
ceph client 对 pool ID 取 hash（比如 “pool1” = 3） 
ceph client 将 pool ID 和 PG ID 组合在一起(比如 3.23)得到 PG 的完整 ID。

2.然后客户端据 PG、CRUSH 运行图和归置组(placement rules)作为输入参数并再次进行计算， 并计算出对象所在的 PG 内的主 OSD ，从而完成对象从 PG 到 OSD 的映射。 
Ceph client 从 MON 获取最新的 cluster map。 
Ceph client 根据上面的第(2)步计算出该 object 将要在的 PG 的 ID。 
Ceph client 再根据 CRUSH 算法计算出 PG 中目标主和备 OSD 的 ID，即可对 OSD 的数据进行读写。 

3.客户端开始对主 OSD 进行读写请求(副本池 IO)，如果发生了写操作，会有 ceph 服务端完 成对象从主 OSD 到备份 OSD 的同步。