进口手表网站seo外推
一、 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 ceph-osd@4.service2>使用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 files3、模拟故障
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