《 大话 Ceph 》 之 PG 那点事儿

《大话 Ceph 》系列文章通过通俗易懂的语言并结合基础实验,用最简单的描述来讲解 Ceph 中的重要概念。让读者对分布式存储系统有一个清晰的理解。

引言

PG,Placement Group,中文翻译为归置组,在 Ceph 中是一个很重要的概念,这篇文章将对 PG 进行深入浅出的讲解。

PG 是什么?

PG就是目录!

我事先搭建了一个3个host, 每个host有3个OSD的集群,集群使用3副本,min_size为2。 集群状态如下:

[root@ceph-1 ~]# ceph osd tree
ID WEIGHT   TYPE NAME       UP/DOWN REWEIGHT PRIMARY-AFFINITY 
-1 17.90991 root default                                      
-2  5.96997     host ceph-1                                   
 0  1.98999         osd.0        up  1.00000       1.00000 
 1  1.98999         osd.1        up  1.00000       1.00000 
 2  1.98999         osd.2        up  1.00000       1.00000 
-4  5.96997     host ceph-2                                   
 3  1.98999         osd.3        up  1.00000       1.00000 
 4  1.98999         osd.4        up  1.00000       1.00000
 5  1.98999         osd.5        up  1.00000       1.00000 
-3  5.96997     host ceph-3                                   
 6  1.98999         osd.6        up  1.00000       1.00000 
 7  1.98999         osd.7        up  1.00000       1.00000 
 8  1.98999         osd.8        up  1.00000       1.00000

每一个 pool 都有一个 id,系统默认生成的 rbd 池的 id 号为 0,那么 rbd 池内的所有 PG 都会以 0. 开头,让我们看一下 osd.0 下面的 current 目录的内容:

[root@ceph-1 ~]# ls /var/lib/ceph/osd/ceph-0/current/
0.0_head   0.1d_head  0.34_head  0.45_head  0.4e_head  
....省略部分内容
0.af_head  0.bc_head  0.d0_head  0.e2_head  0.f4_head

每个 OSD 的 current 目录下都保存了部分的 PG,而 rbd 池的 PG 则以 0.xxx_head 的目录形式存在!

现在我们通过 rados 向集群写入一个文件(/root/char.txt),在集群内保存名为 char ,通过下面的指令查看该文件实际保存的位置:

[root@ceph-1 ~]# ceph osd map rbd char
osdmap e109 pool 'rbd' (0) object 'char' -> pg 0.98165844 (0.44) -> up ([0,7,4], p0) acting ([0,7,4], p0)

可见,文件会保存在PG 0.44中,而这个PG位于osd.0,osd.7,osd.4中,之所以有这里有三个OSD,是因为集群副本数为3,可以在 0/7/4 这三个OSD的current下找到0.44_head目录。而同一份文件(比如这里的 /root/char.txt )的三个副本会分别保存在这三个同名的PG中。

执行指令,将/root/char.txt文件存入集群,并查看各个OSD的PG目录内容:

[root@ceph-1 cluster]# rados -p rbd put char char.txt 
[root@ceph-1 0.44_head]# pwd && ll
/var/lib/ceph/osd/ceph-0/current/0.44_head
-rw-r--r--. 1 root root 8 8月  25 01:38 char__head_98165844__0
-rw-r--r--. 1 root root 0 8月  24 23:40 __head_00000044__0
[root@ceph-2 0.44_head]# pwd && ll
/var/lib/ceph/osd/ceph-4/current/0.44_head
-rw-r--r-- 1 root root 8 8月  25 13:38 char__head_98165844__0
-rw-r--r-- 1 root root 0 8月  25 11:40 __head_00000044__0
[root@ceph-3 0.44_head]# pwd && ll
/var/lib/ceph/osd/ceph-7/current/0.44_head
-rw-r--r-- 1 root root 8 8月  25 13:38 char__head_98165844__0
-rw-r--r-- 1 root root 0 8月  25 11:40 __head_00000044__0

可见,这三个 OSD 保存了这个文件的三个副本,这就是 Ceph 的多副本的基础,将一份数据保存成多个副本,按照一定规则分布在各个OSD中,而多副本的数据的一个特点就是,他们都保存在同名的 PG 下面,也就是同名的目录下。这样,我们就对 PG 有了一个直观的理解。

active+clean 想说爱你不容易

active + clean 是 PG 的健康状态,然而 PG 也会生病,有的是小感冒,有的则可能是一级伤残,下面就是集群进入恢复状态时的一个截图,这里面聚集了各种老弱病残,现在就来分析下每种病症的原因:

这里再次回忆下集群的配置:size = 3, min_size = 2

1、Degraded

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

[root@ceph-2 ~]# service ceph stop osd.4
=== osd.4 === 
Stopping Ceph osd.4 on ceph-2...kill 6475...kill 6475...done
[root@ceph-2 ~]# ceph pg dump_stuck |egrep ^0.44
0.44    active+undersized+degraded    [0,7]    0    [0,7]    0

这里我们前往 ceph-2 节点,手动停止了 osd.4,然后查看此时 PG : 0.44的状态,可见,它此刻的状态是active+undersized+degraded,当一个 PG 所在的 OSD 挂掉之后,这个 PG 就会进入undersized+degraded 状态,而后面的[0,7]的意义就是还有两个 0.44 的副本存活在 osd.0 和 osd.7 上。那么现在可以读取刚刚写入的那个文件吗?是可以正常读取的!

[root@ceph-1 0.44_head]# rados  -p rbd get char char.txt
[root@ceph-1 0.44_head]# cat char.txt 
abcdefg

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

2、Peered

那么,什么才是PG的大病呢,peered 算是一个,刚刚我们关闭了osd.4,集群里还活着两个PG 0.44,现在我们关闭osd.7,查看下0.44的状态:

[root@ceph-3 0.44_head]# service ceph stop osd.7
=== osd.7 === 
Stopping Ceph osd.7 on ceph-3...kill 5986...kill 5986...done
[root@ceph-2 ~]# ceph pg dump_stuck |egrep ^0.44
0.44    undersized+degraded+peered    [0]    0    [0]    0

可见,现在只剩下独苗苗活在 osd.0上了,并且 0.44 还多了一个状态:peered,英文的意思是仔细看,这里我们可以理解成协商、搜索,这时候读取char.txt文件,会发现指令会卡在那个地方一直不动,如此来解释min_size的作用,在 Ceph 中,它的全名叫做 osd_pool_default_min_size,这里大家就会问了,不是还活着一个呢吗,为什么就不能读取内容了,因为我们设置的 min_size=2 ,在 Ceph 中的意义就是,如果存活数少于2了,比如这里的 1 ,那么 Ceph 就不会响应外部的IO请求。

在这里如果执行指令,将 min_size 设置为 1 :

[root@ceph-2 ~]# ceph osd pool set rbd min_size 1
[root@ceph-2 ~]# ceph pg dump_stuck |egrep ^0.44
0.44    active+undersized+degraded    [0]    0    [0]    0

可以看到,0.44没有了 peered 状态,并且文件可以正常读写了,因为min_size=1时,只要集群里面有一份副本活着,那就可以响应外部的IO请求。

peered,我们这里可以将它理解成它在等待其他兄弟姐妹上线,这里 min_size =2 ,也就是 osd.4 和 osd.7 的任意一个上线就可以去除这个状态了,处于 peered 状态的 PG 是不能响应外部的请求的,外部就会觉得IO被挂起。

3、Remapped

Ceph 强大的自我恢复能力,是我们选择它的一个重要原因,在上面的试验中,我们关闭了两个 OSD,但是至少还有一个 PG 0.44存活在 osd.0 上,如果那两个盘真的坏了,Ceph 还是可以将这份仅存的数据恢复到别的OSD上的。

在 OSD 挂掉 5分钟 ( mon_osd_down_out_interval = 300 )之后,这个 OSD 会被标记为 out 状态,可以理解为 Ceph 认为这个 OSD 已经不属于集群了,然后就会把 PG 0.44 remap到别的OSD上去,这个 remap 到哪些 OSD 上也是按照一定的算法计算得到的,重映射之后呢,就会在另外两个 OSD 上找到 0.44 这个 PG,而这只是创建了这个目录而已,丢失的数据是要从仅存的OSD上回填到新的OSD上的,处于回填状态的PG就会被标记为backfilling

所以当一个PG处于remapped+backfilling状态时,可以认为其处于自我克隆复制的自愈过程。

4、 Recover

这里我们先来做一个实验,首先开启所有 OSD 使得集群处于健康状态,然后前往 osd.4 的 PG 0.44下面删除char__head_98165844__0这个文件,再通知 Ceph扫描(scrub)这个PG:

[root@ceph-2 0.44_head]# pwd && rm -f char__head_98165844__0 
/var/lib/ceph/osd/ceph-4/current/0.44_head
[root@ceph-2 0.44_head]# ceph pg scrub 0.44
[root@ceph-2 0.44_head]# ceph pg dump |egrep ^0.44
active+clean+inconsistent [0,7,4]    0    [0,7,4]    0

可见,0.44 多了个 inconsistent 状态,顾名思义,Ceph发现了这个 PG 的不一致状态,这样就可以理解这个 inconsistent 的意义了。

想要修复丢失的文件呢,只需要执行 ceph pg repair 0.44,ceph就会从别的副本中将丢失的文件拷贝过来,这也是ceph自愈的一个情形。

现在再假设一个情形,在 osd.4 挂掉的过程中呢,我们对 char 文件进行了写操作,因为集群内还存在着两个副本,是可以正常写入的,但是 osd.4 内的数据并没有得到更新,过了一会,osd.4上线了,Ceph 就发现,osd.4的char文件是陈旧的,就通过别的 OSD 向 osd.4 进行数据的恢复,使其数据为最新的,而这个恢复的过程中,PG就会被标记为 recover

总结

至此,我们对 PG 在磁盘的具体意义进行了分析,相信大家也对PG有了更深入的理解,同时,对常见的PG状态进行了剖析,今后看到了长长的病例单也不会有所畏惧了。 最后,本文对 PG 状态的解释都基于作者对 Ceph浅显的理解,如果有错误的地方,恳请指正!

大话Ceph系列文章

《大话Ceph》之PG那点事儿 《大话 Ceph》之 RBD 那点事儿 《大话 Ceph 》之 CephX 那点事儿

本文来自:Tstack 公众号

原创声明,本文系作者授权云+社区-专栏发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

6 条评论
登录 后参与评论

相关文章

来自专栏分布式系统进阶

Kafka Manager实现原理与填坑

props.put("group.id", "KafkaManagerOffsetCache")这句说明不管启动了几个kafka manager, 消费"__c...

1122
来自专栏微信终端开发团队的专栏

Hello Bonjour!

Hello Bonjour! 一开始用Bonjour,我是拒绝的。 让我们以一个问题开头:如何能在本地网络找到自己想要的硬件设备及相应服务,并连接? 在这个以I...

21810
来自专栏恰同学骚年

.NET Core微服务之基于Ocelot+Butterfly实现分布式追踪

  微服务的特点决定了功能模块的部署是分布式的,以往在单应用环境下,所有的业务都在同一个服务器上,如果服务器出现错误和异常,我们只要盯住一个点,就可以快速定位和...

803
来自专栏沃趣科技

ASM 翻译系列第三十六弹:ACFS磁盘组的重平衡操作

原作者:Bane Radulovic 译者: 魏兴华 审核: 魏兴华 DBGeeK社区联合出品 原文链接:http://asmsupportguy....

31211
来自专栏数据和云

12c特性解读:RAC MGMTDB资料库的转移与维护

戴明明(Dave) Oracle ACE-A,ACOUG核心成员,宝存科技数据库方案架构师 Dave也是CSDN 认证专家,超过7年的DBA经验,擅长Orac...

2724
来自专栏北京马哥教育

MySQL Master High Available 理论篇(一)

一、概况 MHA 提供自动master故障转移以及在最短的时间内(10~30秒)提升slave为new master MHA 解决了切换后的数据不一致问题 所有...

3237
来自专栏北京马哥教育

服务器程序源代码分析之二:php-fpm

php作为排名top2 互联网开发工具,非常流行,可以参考:中国最大的25个网站采用技术选型方案 php这个名称实际上有两层含义 广义的php 是指用后缀名为....

2734
来自专栏琯琯博客

awesome-java-cn

Java 资源列表,内容包括:构建工具、数据库、框架、模板、安全、代码分析、日志、第三方库、书籍、Java 站点等等。 古董级工具 这些工具伴随着Java一起出...

3528
来自专栏ITCloud的专栏

consul的service mesh功能初体验

|作者简介 ? consul之前一直被当成一个服务发现、分布式KV服务、服务健康检查服务等,但此前发布的1.2版本,宣称其实现了Service Mesh方案。...

631
来自专栏恰同学骚年

.NET Core微服务之基于Steeltoe使用Hystrix熔断保护与监控

  在微服务架构中,我们将系统拆分为很多个服务,各个服务之间通过注册与订阅的方式相互依赖,由于各个服务都是在各自的进程中运行,就有可能由于网络原因或者服务自身的...

1103

扫码关注云+社区