ceph pg incomplete状态处理

Posted 2023-04-12

参考技术A 先记录下初始pg现状，防止osd服务down掉之后，主、从、历史副本发生变化
ceph pg dump|grep incom > pgincom.info
ceph pg 1.4 query > 1.4query

查找历史pg所在osd和其他副本pg所在osd，查看pg中的对象，先对比pg的主副本之间 pg里面的对象数 哪个对象数多 就把哪个pg export出来，然后import到对象数少的pg里面，选择完整对象的pg导出，再导入到主pg中（导入前备份）
然后再mark complete

对于数据不完整的pg，实在无法修复的，执行删除操作

修复完的pg进行cpmplete标记

systemctl start ceph-osd@$OSD_NUMBER
ceph osd unset noout

Ceph PG介绍及故障状态和修复

1 PG介绍
pg的全称是placement group，中文译为放置组，是用于放置object的一个载体，pg的创建是在创建ceph存储池的时候指定的，同时跟指定的副本数也有关系，比如是3副本的则会有3个相同的pg存在于3个不同的osd上，pg其实在osd的存在形式就是一个目录，可以列出来看下：

[[email protected] ~]# ll /var/lib/ceph/osd/ceph-2/current/
total 332
drwxr-xr-x 2 root root 32 Sep 19 15:27 1.11_head
drwxr-xr-x 2 root root 98 Sep 21 15:12 1.14_head
drwxr-xr-x 2 root root 83 Sep 21 14:12 1.1f_head
drwxr-xr-x 2 root root 98 Sep 21 18:43 1.24_head
drwxr-xr-x 2 root root 6 Sep 21 18:43 1.24_TEMP
drwxr-xr-x 2 root root 32 Sep 19 15:27 1.25_head
drwxr-xr-x 2 root root 164 Sep 21 15:14 1.2d_head
drwxr-xr-x 2 root root 32 Sep 19 15:27 1.2_head
drwxr-xr-x 2 root root 98 Sep 21 15:15 1.34_head

这里只列出来一部分，可以看到有1.24这样开头的，这其实就是pg的id，前面的1表示这个pg是对应哪个存储池的，存储池id可以通过ceph df看到：

[[email protected] ~]# ceph df
GLOBAL:
SIZE AVAIL RAW USED %RAW USED 
10704G 9808G 896G 8.37 
POOLS:
NAME ID USED %USED MAX AVAIL OBJECTS 
volumes 1 116M 0 3059G 46 
images 2 29218M 0.92 3059G 3669 
backups 3 0 0 3059G 0 
vms 4 269G 8.09 3059G 103678 
snapshots 5 0 0 3059G 0 
gnocchi 6 394M 0.01 3059G 23310

说明该pg是属于volumes存储池的，后面的24是用于区分同个池中的不同的pg的，两者结合起来就作为pg的id了，crush map通过pgid可以计算出该pg是分布在哪组osd上的，可以通过如下命令查看pg分布于哪些osd上：

[[email protected] ~]# ceph pg map 1.24
osdmap e1008 pg 1.24 (1.24) -> up [0,2,8] acting [0,2,8]

可以看到该pg的3副本分别是分布在osd.0，osd.2和osd.8上的，其中最前面的0表示主副本存在于osd.0上。

 

2 PG在ceph中的作用
从上面可以看到所有数据其实都是抽象成多个object，每个object都会对应到唯一的一个pg上（多副本表示有多个相同的pg，当然object也自然是多副本的），然后pg映射到osd上存储，所以pg可以说是ceph的核心概念了，那为什么要引进pg这个概念呢？
这是因为如果要追踪的目标如果是object，那么要追踪的数量就太多了，这样可能会加大复杂性，而且也会带来不小的开销，于是引进pg这个概念，把object装进pg中，以pg为存储单元个体，直接追踪pg状态，一般pg数量是远远小于object数量的。

 

3 PG数量计算方法
官方给出的计算公式是这样的：
Total PGs = (Total_number_of_OSD * 100) / max_replication_count
但每个池中pg数量最好接近或等于2的次方
例：
有100个osd，2副本，5个pool
Total PGs =100*100/2=5000
每个pool 的PG=5000/5=1000，那么创建pool的时候就指定pg为1024
ceph osd pool create pool_name 1024
下面给出我在程序中写的pg计算函数（仅供参考）：

def pg_calc(osd_count, pool_count, rep_size):
    osd_count = int(osd_count)
    pool_count = int(pool_count)
    rep_size = int(rep_size)
    pg_num = 512
    if rep_size == 2:
        if osd_count > 0 and osd_count < 5:
            pg_num = 128
        elif osd_count >= 5 and osd_count <= 10:
            pg_num = 512
        else:
            pg_num = int((osd_count * 100) / (rep_size))
    else:
        pg_num = int((osd_count * 100) / (rep_size))
        per_pool_pg = pg_num / pool_count
    for i in range(0, 21):
        tmp = 2 ** i
        if tmp >= per_pool_pg:
            pg_num = tmp
            break

    return pg_num

 

4 PG的状态有哪些
从第2点我们知道由于pg的引进，我们只要追踪pg的状态即可，因此pg在集群中是存在多种状态的，pg的状态也决定着当前集群数据的健康状态。
（1）Active：当前拥有最新状态数据的pg正在工作中，能正常处理来自客户端的读写请求。
（2）inactive：正在等待具有最新数据的OSD出现，即当前具有最新数据的pg不在工作中，不能正常处理来自客户端的读写请求。
（3）Clean：PG所包含的object达到指定的副本数量，即object副本数量正常。
（4）Unclean：PG所包含的object没有达到指定的副本数量，比如一个PG没在工作，另一个PG在工作，object没有复制到另外一个PG中。
（5）Peering：PG所在的OSD对PG中的对象的状态达成一个共识（维持对象一致性）。
（6）Degraded：主osd没有收到副osd的写完成应答，比如某个osd处于down状态。
（7）Stale：主osd未在规定时间内向mon报告其pg状态，或者其它osd向mon报告该主osd无法通信。
（8）Inconsistent：PG中存在某些对象的各个副本的数据不一致，原因可能是数据被修改。
（9）Repair：pg在scrub过程中发现某些对象不一致，尝试自动修复。
（10）Undersized：pg的副本数少于pg所在池所指定的副本数量，一般是由于osd down的缘故。
（11）Scrubbing（deep + Scrubbing）：pg对对象的一致性进行扫描。
（12）Recovering：pg间peering完成后，对pg中不一致的对象执行同步或修复，一般是osd down了或新加入了osd。
（13）Backfilling：一般是当新的osd加入或移除掉了某个osd后，pg进行迁移或进行全量同步。

 

5 PG修复
5.1 通常查看集群是否正常都是通过ceph -s命令查看，如果显示是HEALTH_OK则表示集群是健康的，一切运行正常，比如：

[[email protected] ~]# ceph -s
cluster ce0d75a9-9d6a-4b8e-ab4c-c3645f69506a
health HEALTH_OK
monmap e3: 3 mons at {ctl0=10.16.30.16:6789/0,ctl1=10.16.30.14:6789/0,ctl2=10.16.30.15:6789/0}
election epoch 20, quorum 0,1,2 ctl1,ctl2,ctl0
osdmap e39: 3 osds: 3 up, 3 in
pgmap v58: 192 pgs, 6 pools, 0 bytes data, 0 objects
102 MB used, 98153 MB / 98255 MB avail
192 active+clean

但有时也会遇见ceph -s显示的是HEALTH_WARN，如下所示：

[[email protected] ~]# ceph -s
cluster ce0d75a9-9d6a-4b8e-ab4c-c3645f69506a
health HEALTH_WARN
135 pgs degraded
135 pgs stuck unclean
135 pgs undersized
1/3 in osds are down
monmap e3: 3 mons at {ctl0=10.16.30.16:6789/0,ctl1=10.16.30.14:6789/0,ctl2=10.16.30.15:6789/0}
election epoch 20, quorum 0,1,2 ctl1,ctl2,ctl0
osdmap e41: 3 osds: 2 up, 3 in
pgmap v64: 192 pgs, 6 pools, 0 bytes data, 0 objects
103 MB used, 98152 MB / 98255 MB avail
135 active+undersized+degraded
57 active+clean

可以看到很多pg的状态是不健康的了，但从中其实也可以发现有一个osd挂了，其实只要把该osd重新拉起来就好了，拉起来后集群会自动重新恢复健康状态。但是也有可能出现这个osd再也起不来了，比如硬盘损坏了，这时多副本就发挥作用了，因为还有其它副本在其它osd上，这时我们可以通过均衡数据的方法来将集群恢复并将该osd踢出集群。
这里我们以osd.2为例子。
均衡数据恢复步骤：
# 先将该osd reweight 到0，也就是将权重降低到0，让数据副本分散到其它osd上

ceph osd reweight 2 0.0

# 待集群重新恢复为ok后执行以下命令将osd踢出集群

service ceph stop osd.2
ceph osd out 2
ceph osd crush remove osd.2
ceph auth del osd.2
ceph osd rm osd.2

 

5.2 有时可能碰上osd拉起后还是有些pg不健康的，比如：
（1）Unfound objects
ceph集群知道该对象存在，但无法定位该object在哪时会报这个错误。
解决办法：
<1>尝试让失败的osd起来，如果起来后集群恢复正常，则结束
<2>尝试将该pg的unfound对象回滚到上一个版本，ceph pg $pgid mark_unfound_lost revert，如果恢复正常，则结束
<3>如果还是不行，那只有将该object删除掉了，注意这会导致丢失数据，ceph pg $pgid mark_unfound_lost delete

（2）inconsistent objects
pg中保存的object中有些副本数据不一致
<1>ceph health detail 找出问题pg
<2>尝试ceph pg repair $pgid,若成功，则结束
<3>通过ceph pg map $pgid，找出主osd，打开其日志查看是哪个object不一致
<4>找出所有该objects所有副本存放的位置，用摘要算法(md5sum,sha256)等计算出其hash值，如果是3副本，删除与其他副本不一致的；如果是2副本，则可能会误删。
<5> 再次执行 ceph pg repair $pgid