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

Posted luohaixian

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了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

 













































以上是关于Ceph PG介绍及故障状态和修复的主要内容,如果未能解决你的问题,请参考以下文章

ceph分布式存储-常见 PG 故障处理

ceph pg分配状态#yyds干货盘点#

Ceph源码解析:PG peering

sh 修复ceph pg repair都无法修复的pg不连续

ceph pg degraded#yyds干货盘点#

ceph pg 状态监测#yyds干货盘点#