分布式存储Ceph之PG状态详解

1. PG介绍

继上次分享的《Ceph介绍及原理架构分享》，这次主要来分享Ceph中的PG各种状态详解，PG是最复杂和难于理解的概念之一，PG的复杂如下：

• 在架构层次上，PG位于RADOS层的中间。
  a. 往上负责接收和处理来自客户端的请求。
  b. 往下负责将这些数据请求翻译为能够被本地对象存储所能理解的事务。
• 是组成存储池的基本单位，存储池中的很多特性，都是直接依托于PG实现的。
• 面向容灾域的备份策略使得一般而言的PG需要执行跨节点的分布式写，因此数据在不同节点之间的同步、恢复时的数据修复也都是依赖PG完成。

2. PG状态表

正常的PG状态是 100%的active + clean， 这表示所有的PG是可访问的，所有副本都对全部PG都可用。
如果Ceph也报告PG的其他的警告或者错误状态。PG状态表：

状态	描述
Activating	Peering已经完成，PG正在等待所有PG实例同步并固化Peering的结果(Info、Log等)
Active	活跃态。PG可以正常处理来自客户端的读写请求
Backfilling	正在后台填充态。 backfill是recovery的一种特殊场景，指peering完成后，如果基于当前权威日志无法对Up Set当中的某些PG实例实施增量同步(例如承载这些PG实例的OSD离线太久，或者是新的OSD加入集群导致的PG实例整体迁移) 则通过完全拷贝当前Primary所有对象的方式进行全量同步
Backfill-toofull	某个需要被Backfill的PG实例，其所在的OSD可用空间不足，Backfill流程当前被挂起
Backfill-wait	等待Backfill 资源预留
Clean	干净态。PG当前不存在待修复的对象， Acting Set和Up Set内容一致，并且大小等于存储池的副本数
Creating	PG正在被创建
Deep	PG正在或者即将进行对象一致性扫描清洗
Degraded	降级状态。Peering完成后，PG检测到任意一个PG实例存在不一致(需要被同步/修复)的对象，或者当前ActingSet 小于存储池副本数
Down	Peering过程中，PG检测到某个不能被跳过的Interval中(例如该Interval期间，PG完成了Peering，并且成功切换至Active状态，从而有可能正常处理了来自客户端的读写请求),当前剩余在线的OSD不足以完成数据修复
Incomplete	Peering过程中， 由于 a. 无非选出权威日志 b. 通过choose_acting选出的Acting Set后续不足以完成数据修复，导致Peering无非正常完成
Inconsistent	不一致态。集群清理和深度清理后检测到PG中的对象在副本存在不一致，例如对象的文件大小不一致或Recovery结束后一个对象的副本丢失
Peered	Peering已经完成，但是PG当前ActingSet规模小于存储池规定的最小副本数(min_size)
Peering	正在同步态。PG正在执行同步处理
Recovering	正在恢复态。集群正在执行迁移或同步对象和他们的副本
Recovering-wait	等待Recovery资源预留
Remapped	重新映射态。PG活动集任何的一个改变，数据发生从老活动集到新活动集的迁移。在迁移期间还是用老的活动集中的主OSD处理客户端请求，一旦迁移完成新活动集中的主OSD开始处理
Repair	PG在执行Scrub过程中，如果发现存在不一致的对象，并且能够修复，则自动进行修复状态
Scrubbing	PG正在或者即将进行对象一致性扫描
Unactive	非活跃态。PG不能处理读写请求
Unclean	非干净态。PG不能从上一个失败中恢复
Stale	未刷新态。PG状态没有被任何OSD更新，这说明所有存储这个PG的OSD可能挂掉, 或者Mon没有检测到Primary统计信息(网络抖动)
Undersized	PG当前Acting Set小于存储池副本数

3. 状态详解及故障模拟复现

3.1 Degraded

3.1.1 说明

• 降级：由上文可以得知，每个PG有三个副本，分别保存在不同的OSD中，在非故障情况下，这个PG是active+clean 状态，那么，如果PG 的 副本osd.4 挂掉了，这个 PG 是降级状态。

3.1.2 故障模拟

a. 停止osd.1

$ systemctl stop ceph-osd@1

b. 查看PG状态

$ bin/ceph pg stat
20 pgs: 20 active+undersized+degraded; 14512 kB data, 302 GB used, 6388 GB / 6691 GB avail; 12/36 objects degraded (33.333%)

c. 查看集群监控状态

$ bin/ceph health detail
HEALTH_WARN 1 osds down; Degraded data redundancy: 12/36 objects degraded (33.333%), 20 pgs unclean, 20 pgs degraded; application not enabled on 1 pool(s)
OSD_DOWN 1 osds down
    osd.1 (root=default,host=ceph-xx-cc00) is down
PG_DEGRADED Degraded data redundancy: 12/36 objects degraded (33.333%), 20 pgs unclean, 20 pgs degraded
    pg 1.0 is active+undersized+degraded, acting [0,2]
    pg 1.1 is active+undersized+degraded, acting [2,0]

d. 客户端IO操作

#写入对象
$ bin/rados -p test_pool put myobject ceph.conf

#读取对象到文件
$ bin/rados -p test_pool get myobject.old

#查看文件
$ ll ceph.conf*
-rw-r--r-- 1 root root 6211 Jun 25 14:01 ceph.conf
-rw-r--r-- 1 root root 6211 Jul  3 19:57 ceph.conf.old

故障总结：
为了模拟故障，(size = 3, min_size = 2) 我们手动停止了 osd.1，然后查看PG状态，可见，它此刻的状态是active+undersized+degraded,当一个 PG 所在的 OSD 挂掉之后，这个 PG 就会进入undersized+degraded 状态，而后面的[0,2]的意义就是还有两个副本存活在 osd.0 和 osd.2 上, 并且这个时候客户端可以正常读写IO。

3.1.3 总结

• 降级就是在发生了一些故障比如OSD挂掉之后，Ceph 将这个 OSD 上的所有 PG 标记为 Degraded。
• 降级的集群可以正常读写数据，降级的 PG 只是相当于小毛病而已，并不是严重的问题。
• Undersized的意思就是当前存活的PG 副本数为 2，小于副本数3，将其做此标记，表明存货副本数不足，也不是严重的问题。

3.2 Peered

3.2.1 说明

• Peering已经完成，但是PG当前Acting Set规模小于存储池规定的最小副本数(min_size)。

3.2.2 故障模拟

a. 停掉两个副本osd.1,osd.0

$ systemctl stop ceph-osd@1
$ systemctl stop ceph-osd@0

b. 查看集群健康状态

$ bin/cep