二十一、PG管理

一、 PG异常状态说明

1、 PG状态介绍

可以通过ceph pg stat命令查看PG当前状态，健康状态为“active + clean”

[root@rbd01 ~]# ceph pg stat
192 pgs: 192 active+clean; 1.3 KiB data, 64 MiB used, 114 GiB / 120 GiB avail; 85 B/s rd, 0 op/s

2、pg常见状态

状态	含义
activating	peering即将完成，正在等待所有副本同步并固化peering结果（Info、log等）
active	活跃。PG可以正常处理来自客户端的读写请求
backfilling	正在后台填充态。 backfill是recovery的一种特殊场景，指peering完成后，如果基于当前权威日志无法对Up Set当中的某些PG实例实施增量同步(例如承载这些PG实例的OSD离线太久，或者是新的OSD加入集群导致的PG实例整体迁移) 则通过完全拷贝当前Primary所有对象的方式进行全量同步
backfill-toofull	副本所在OSD空间不足，backfill流程被挂起
backfill-wait	等待backfill资源预留完成
clean	PG当前不存在降级对象（待修复的对象），acting set和up set内容一致，并且大小等于存储池副本数
creating	PG正在被创建
deep	PG正在或即将执行Deep-Scrub（对象一致性扫描）
degraded	PG存在降级对象（peering完成后，PG检测到一个PG实例存在不一致），或者acting set规模小于存储池副本数（但是不小于存储池最小副本数）
down	Peering过程中，PG检测到某个不能被跳过的Interval中，当前仍然存活的副本不足以完成数据恢复
incomplete	Peering过程中，由于无法选出权威日志或者选出的acting set不足以完成数据修复
inconsistent	Scurb过程中检测到某个或者某些对象在副本之间出现了不一致
peered	Peering已经完成，但是pg当前acting set规模小于存储池规定的最小副本数
peering	Peer正在进行
recovering	PG正在后台按照Peering结果，对降级对象（不一致对象）进行修复
recovering-wait	等待Recovery资源预留完成
remapped	PG活动集任何的一个改变，数据发生从老活动集到新活动集的迁移。在迁移期间还是用老的活动集中的主OSD处理客户端请求，一旦迁移完成新活动集中的主OSD开始处理
repair	修复不一致对象
scrubbing	PG正在执行Scrub
stale	Monitor检测到当前Primary所在的OSD宕掉且后续没有发生切换，或者Primary超时未向Monitor上报PG相关的统计信息（例如出现临时性的网络拥塞）
undersized	当前acting set中副本个数小于存储池副本数（但是不小于存储池最小副本数）
unactive	PG不能处理读写请求
unclean	PG不能从上一个失败中恢复

3、pg常见异常状态

下面给出部分PG异常状态（需要人为修复）介绍。1>degraded：降级当客户端向主 OSD 写入数据时，由主 OSD 负责把数据副本写入其余副本 OSD 。主 OSD 把对象写入存储器后，在副本 OSD 创建完对象副本并报告给主 OSD 之前，主 OSD 会一直停留在 degraded 状态。归置组状态可以处于 active+degraded 状态，原因在于一 OSD 即使尚未持有所有对象也可以处于 active 状态。如果一 OSD 挂了， Ceph 会把分配到此 OSD 的归置组都标记为 degraded ；那个 OSD 重生后，它们必须重新互联。然而，客户端仍可以向处于 degraded 状态的归置组写入新对象，只要它还在 active 状态。如果一 OSD 挂了，且老是处于 degraded 状态， Ceph 会把 down 的 OSD 标记为在集群外（ out ）、并把那个 down 掉的 OSD 上的数据重映射到其它 OSD 。从标记为 down 到 out 的时间间隔由 mon osd down out interval 控制，默认是 300 秒。归置组也会被降级（ degraded ），因为 Ceph 找不到本应存在于此归置组中的一或多个对象，这时，你不能读写找不到的对象，但仍能访问位于降级归置组中的其它对象。2>remapped：重映射
负责维护某一归置组的 Acting Set 变更时，数据要从旧集合迁移到新的。新的主 OSD 要花费一些时间才能提供服务，所以老的主 OSD 还要持续提供服务、直到归置组迁移完。数据迁移完后，运行图会包含新 acting set 里的主 OSD 。3>stale：陈旧默认， OSD 守护进程每半秒（ 0.5 ）会一次报告其归置组、出流量、引导和失败统计状态，此频率高于心跳阀值。如果一归置组的主 OSD 所在的 acting set 没能向监视器报告、或者其它监视器已经报告了那个主 OSD 已 down ，监视器们就会把此归置组标记为 stale 。启动集群时，会经常看到 stale 状态，直到互联完成。集群运行一阵后，如果还能看到有归置组位于 stale 状态，就说明那些归置组的主 OSD 挂了（ down ）、或没在向监视器报告统计信息。4>inconsistent：不一致PG通常存在多个副本，其所有副本的数据应当是完全一致的。但有时会由于OSD故障、网络阻塞等某些因素，导致副本上的数据发生不一致的现象，此时需要对不一致的PG惊醒修复

二、常见故障处理方式

1、 OSD Down导致pg故障

最常见的PG故障都是由于某个或者多个OSD对应的硬盘损坏导致进程挂掉出现的。一般更换硬盘可以解决, 多关注集群节点dmesg日志，查看关于磁盘坏道或者io/error相关报错，及时更换硬盘

2、pg数据不一致

PG状态为inconsistent时，说明PG中存在对象不一致的情况。有可能时某个OSD磁盘损坏，或者磁盘上的数据发生静默错误。

一般手动修复损坏的PG即可, 使用ceph pg repair {pgid}
尝试手动构造一个PG数据损坏的例子，并修复它

1>关闭1个osd
systemctl stop [e-mail]2>使用ceph-objectstore-tool 挂载 /var/lib/ceph/osd/ceph-4 到 /mnt/ceph-osd@4
[root@rbd05 ~]# mkdir /mnt/ceph-4
[root@rbd05 ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-4/ --op fuse --mountpoint /mnt/ceph-4
mounting fuse at /mnt/ceph-4 ...3>另开一个窗口，查看osd内内容，以及pg目录结构
[root@rbd05 ~]# cd /mnt/ceph-4/
[root@rbd05 ceph-4]# ls
1.10_head  1.1a_head  1.6_head  2.10_head  2.18_head  2.23_head  2.2b_head  2.32_head  2.3f_head  2.c_head   3.12_head  3.1c_head  3.9_head  4.10_head  4.19_head  4.2_head  4.9_head  5.0_head   5.17_head  5.1_head  5.a_head
1.11_head  1.1b_head  1.7_head  2.12_head  2.1b_head  2.24_head  2.2c_head  2.34_head  2.3_head   2.d_head   3.13_head  3.1d_head  3.b_head  4.11_head  4.1a_head  4.3_head  4.a_head  5.12_head  5.18_head  5.3_head  5.b_head
1.12_head  1.1c_head  1.8_head  2.13_head  2.1c_head  2.25_head  2.2d_head  2.36_head  2.4_head   2.e_head   3.14_head  3.1f_head  3.c_head  4.12_head  4.1b_head  4.5_head  4.b_head  5.13_head  5.19_head  5.5_head  5.e_head
1.13_head  1.1f_head  1.9_head  2.14_head  2.20_head  2.28_head  2.2e_head  2.3a_head  2.7_head   2.f_head   3.15_head  3.1_head   3.d_head  4.14_head  4.1c_head  4.6_head  4.d_head  5.14_head  5.1a_head  5.7_head  5.f_head
1.15_head  1.1_head   1.b_head  2.15_head  2.21_head  2.29_head  2.2_head   2.3b_head  2.9_head   3.0_head   3.17_head  3.5_head   3.f_head  4.16_head  4.1d_head  4.7_head  4.e_head  5.15_head  5.1b_head  5.8_head  meta
1.18_head  1.2_head   1.e_head  2.17_head  2.22_head  2.2a_head  2.30_head  2.3e_head  2.b_head   3.10_head  3.19_head  3.6_head   4.0_head  4.17_head  4.1_head   4.8_head  4.f_head  5.16_head  5.1f_head  5.9_head  type[root@rbd06 ceph-5]# cd 1.10_head/
[root@rbd06 1.10_head]# 
[root@rbd06 1.10_head]# tree ./
./
├── all
│   ├── #1:08000000::::head#
│   │   ├── attr
│   │   ├── bitwise_hash
│   │   ├── data
│   │   ├── omap
│   │   │   ├── 0000000017.00000000000000000001
│   │   │   ├── 0000000067.00000000000000000002
│   │   │   ├── _biginfo
│   │   │   ├── _epoch
│   │   │   ├── _info
│   │   │   ├── _infover
│   │   │   └── may_include_deletes_in_missing
│   │   └── omap_header
│   └── #1:0ec1d93a:::zone_info.fa15c50d-1027-4f2c-b2e6-972a058506a5:head#
│       ├── attr
│       │   ├── _
│       │   └── snapset
│       ├── bitwise_hash
│       ├── data
│       ├── omap
│       └── omap_header
├── bitwise_hash_bits
├── bitwise_hash_end
├── bitwise_hash_start
├── by_bitwise_hash
└── pgmeta├── attr├── bitwise_hash├── data├── omap│   ├── 0000000017.00000000000000000001│   ├── 0000000067.00000000000000000002│   ├── _biginfo│   ├── _epoch│   ├── _info│   ├── _infover│   └── may_include_deletes_in_missing└── omap_header11 directories, 28 files

3、模拟故障

1>选取pg 1.10模拟故障，模拟故障环境，使用ceph-objectstore-tool，删除三副本中两个副本上的同一个对象。
[root@rbd01 ~]# ceph pg ls|grep 1.10 
1.10       1        0         0       0   805           0          0    2 active+clean    2m     67'2  140:278 [1,2,3]p1 [1,2,3]p1 2023-03-11 09:10:17.550546 2023-03-11 09:10:17.5505462> 使用ceph-objectstore-tool前，需要停掉该osd服务，使用systemctl stop ceph-osd@{id}
systemctl stop ceph-osd2
systemctl stop ceph-osd@3