漫衍式存储 Ceph 中 PG 各类状态详解

作者：李航 来历：talkwithtrend

原文链接： https://mp.weixin.qq.com/s/a3mTVNQWYvMuEz8X_uCRMA

1. PG先容

这次首要来分享Ceph中的PG各类状态详解，PG是最伟大和难于领略的观念之一，PG的伟大如下：

- 在架构条理上，PG位于RADOS层的中间。

a. 往上认真吸取和处理赏罚来自客户端的哀求。

b. 往下认真将这些数据哀求翻译为可以或许被当地工具存储所能领略的事宜。

- 是构成存储池的根基单元，存储池中的许多特征，都是直接依托于PG实现的。

- 面向容灾域的备份计策使得一样平常而言的PG必要执行跨节点的漫衍式写，因此数据在差异节点之间的同步、规复时的数据修复也都是依靠PG完成。

2. PG状态表

正常的PG状态是 100%的active + clean， 这暗示全部的PG是可会见的，全部副本都对所有PG都可用。 假如Ceph也陈诉PG的其他的告诫可能错误状态。PG状态表：

3. 状态详解及妨碍模仿复现

3.1 Degraded

3.1.1 声名

降级：由上文可以得知，每个PG有三个副本，别离生涯在差异的OSD中，在非妨碍环境下，这个PG是active+clean 状态，那么，假如PG 的 副本osd.4 挂掉了，这个 PG 是降级状态。

3.1.2 妨碍模仿

• 遏制osd.1 $ systemctl stop ceph-osd@1

• 查察PG状态 $ bin/ceph pg stat 20 pgs: 20 active+undersized+degraded; 14512 kB data, 302 GB used, 6388 GB / 6691 GB avail; 12/36 objects degraded (33.333%)

• 查察集群监控状态

• 客户端IO操纵

妨碍总结：

为了模仿妨碍，(size = 3, min_size = 2) 我们手动遏制了 osd.1，然后查察PG状态，可见，它而今的状态是active+undersized+degraded,当一个 PG 地址的 OSD 挂掉之后，这个 PG 就会进入undersized+degraded 状态，尔后头的[0,2]的意义就是尚有两个副本存活在 osd.0 和 osd.2 上, 而且这个时辰客户端可以正常读写IO。

3.1.3 总结

• 降级就是在产生了一些妨碍好比OSD挂掉之后，Ceph 将这个 OSD 上的全部 PG 标志为 Degraded。

• 降级的集群可以正常读写数据，降级的 PG 只是相等于小短处罢了，并不是严峻的题目。

• Undersized的意思就是当前存活的PG 副本数为 2，小于副本数3，将其做此标志，表白存货副本数不敷，也不是严峻的题目。

3.2 Peered

3.2.1 声名

• Peering已经完成，可是PG当前Acting Set局限小于存储池划定的最小副本数(min_size)。

3.2.2 妨碍模仿

a. 停掉两个副本osd.1,osd.0

$ systemctl stop ceph-osd@1 $ systemctl stop ceph-osd@0

b. 查察集群康健状态

c. 客户端IO操纵(夯住)

读取工具到文件，夯住IO

$ bin/rados -p test_pool get myobject ceph.conf.old

妨碍总结：

- 此刻pg 只剩下osd.2上存活，而且 pg 还多了一个状态：peered，英文的意思是细心看，这里我们可以领略成协商、搜刮。

- 这时辰读取文件，会发明指令会卡在谁人处所一向不动，为什么就不能读取内容了，由于我们配置的 min_size=2 ，假如存活数少于2，好比这里的 1 ，那么就不会相应外部的IO哀求。

d. 调解min_size=1可以办理IO夯住题目

配置min_size = 1

$ bin/ceph osd pool set test_pool min_size 1 set pool 1 min_size to 1

e. 查察集群监控状态

f. 客户端IO操纵

读取工具到文件中

$ ll -lh ceph.conf* -rw-r--r-- 1 root root 6.1K Jun 25 14:01 ceph.conf -rw-r--r-- 1 root root 6.1K Jul 3 20:11 ceph.conf.old -rw-r--r-- 1 root root 6.1K Jul 3 20:11 ceph.conf.old.1

妨碍总结：

- 可以看到，PG状态Peered没有了，而且客户端文件IO可以正常读写了。

- 当min_size=1时，只要集群内里有一份副本在世，那就可以相应外部的IO哀求。

3.2.3 总结

• Peered状态我们这里可以将它领略成它在守候其他副本上线。

• 当min_size = 2 时，也就是必需担保有两个副本存活的时辰就可以去除Peered这个状态。

• 处于 Peered 状态的 PG 是不能相应外部的哀求的而且IO被挂起。

3.3 Remapped

3.3.1 声名

• Peering完成，PG当前Acting Set与Up Set纷歧致就会呈现Remapped状态。

3.3.2 妨碍模仿

a. 遏制osd.x

$ systemctl stop ceph-osd@x

b. 隔断5分钟，启动osd.x

$ systemctl start ceph-osd@x

c. 查察PG状态

d. 客户端IO操纵

rados读写正常

rados -p test_pool put myobject /tmp/test.log

3.3.3 总结

在 OSD 挂掉可能在扩容的时辰PG 上的OSD会凭证Crush算法从头分派PG 所属的osd编号。而且会把 PG Remap到此外OSD上去。

Remapped状态时，PG当前Acting Set与Up Set纷歧致。

客户端IO可以正常读写。

3.4 Recovery

3.4.1 声名

指PG通过PGLog日记针对数据纷歧致的工具举办同步和修复的进程。

3.4.2 妨碍模仿

a. 遏制osd.x

$ systemctl stop ceph-osd@x

b. 隔断1分钟启动osd.x

osd$ systemctl start ceph-osd@x

c. 查察集群监控状态

$ ceph health detail HEALTH_WARN Degraded data redundancy: 183/57960 objects degraded (0.316%), 17 pgs unclean, 17 pgs degraded PG_DEGRADED Degraded data redundancy: 183/57960 objects degraded (0.316%), 17 pgs unclean, 17 pgs degraded pg 1.19 is active+recovery_wait+degraded, acting [29,9,17]

3.4.3 总结

Recovery是通过记录的PGLog举办规复数据的。

记录的PGLog 在osd_max_pg_log_entries=10000条以内，这个时辰通过PGLog就能增量规复数据。

3.5 Backfill

3.5.1 声名

• 当PG的副本无非通过PGLog来规复数据，这个时辰就必要举办全量同步，通过完全拷贝当前Primary全部工具的方法举办全量同步。

3.5.2 妨碍模仿

a. 遏制osd.x

$ systemctl stop ceph-osd@x

b. 隔断10分钟启动osd.x

$ osd systemctl start ceph-osd@x

c. 查察集群康健状态

$ ceph health detail HEALTH_WARN Degraded data redundancy: 6/57927 objects degraded (0.010%), 1 pg unclean, 1 pg degraded PG_DEGRADED Degraded data redundancy: 6/57927 objects degraded (0.010%), 1 pg unclean, 1 pg degraded pg 3.7f is active+undersized+degraded+remapped+backfilling, acting [21,29]

3.5.3 总结

无法按照记录的PGLog举办规复数据时，就必要执行Backfill进程全量规复数据。

假如高出osd_max_pg_log_entries=10000条， 这个时辰必要全量规复数据。

3.6 Stale

3.6.1 声名

• mon检测到当前PG的Primary地址的osd宕机。

• Primary超时未向mon上报pg相干的信息(譬喻收集阻塞)。

• PG内三个副本都挂掉的环境。

3.6.2 妨碍模仿

a. 别离遏制PG中的三个副本osd, 起首遏制osd.23

$ systemctl stop ceph-osd@23

b. 然后遏制osd.24

$ systemctl stop ceph-osd@24

c. 查察遏制两个副本PG 1.45的状态

d. 在遏制PG 1.45中第三个副本osd.10

$ systemctl stop ceph-osd@10

e. 查察遏制三个副本PG 1.45的状态

f. 客户端IO操纵

读写挂载磁盘IO 夯住

ll /mnt/

妨碍总结：

先遏制统一个PG内两个副本，状态是undersized+degraded+peered。

然后遏制统一个PG内三个副本，状态是stale+undersized+degraded+peered。

3.6.3 总结

当呈现一个PG内三个副本都挂掉的环境，就会呈现stale状态。

此时该PG不能提供客户端读写，IO挂起夯住。

Primary超时未向mon上报pg相干的信息(譬喻收集阻塞),也会呈现stale状态。

3.7 Inconsistent

3.7.1 声名

• PG通过Scrub检测到某个可能某些工具在PG实例间呈现了纷歧致

3.7.2 妨碍模仿

a. 删除PG 3.0中副本osd.34头文件

$ rm -rf /var/lib/ceph/osd/ceph-34/current/3.0_head/DIR_0/1000000697c.0000122c__head_19785300__3

b. 手动执行PG 3.0举办数据洗濯

$ ceph pg scrub 3.0 instructing pg 3.0 on osd.34 to scrub

c. 搜查集群监控状态

$ ceph health detail HEALTH_ERR 1 scrub errors; Possible data damage: 1 pg inconsistent OSD_SCRUB_ERRORS 1 scrub errors PG_DAMAGED Possible data damage: 1 pg inconsistent pg 3.0 is active+clean+inconsistent, acting [34,23,1]

d. 修复PG 3.0

妨碍总结：

当PG内部三个副本稀有据纷歧致的环境，想要修复纷歧致的数据文件，只必要执行ceph pg repair修复指令，ceph就会从其他的副本中将丢失的文件拷贝过来就行修复数据。

3.7.3 妨碍模仿

• 当osd短暂挂掉的时辰，由于集群内还存在着两个副本，是可以正常写入的，可是 osd.34 内的数据并没有获得更新，过了一会osd.34上线了，这个时辰osd.34的数据是陈旧的，就通过其他的OSD 向 osd.34 举办数据的规复，使其数据为最新的，而这个规复的进程中，PG的状态会从inconsistent ->recover -> clean,最终规复正常。

• 这是集群妨碍自愈一种场景。

3.8 Down

3.8.1 声名

Peering进程中，PG检测到某个不能被跳过的Interval中(譬喻该Interval时代，PG完成了Peering，而且乐成切换至Active状态，从而有也许正常处理赏罚了来自客户端的读写哀求),当前剩余在线的OSD不敷以完成数据修复.

3.8.2 妨碍模仿

a. 查察PG 3.7f内副本数

$ ceph pg dump | grep ^3.7f dumped all 3.7f 43 0 0 0 0 494927872 1569 1569 active+clean 2018-07-05 02:52:51.512598 21315'80115 21356:111666 [5,21,29] 5 [5,21,29] 5 21315'80115 2018-07-05 02:52:51.512568 6206'80083 2018-06-29 22:51:05.831219

b. 遏制PG 3.7f 副本osd.21

$ systemctl stop ceph-osd@21

c. 查察PG 3.7f状态

$ ceph pg dump | grep ^3.7f dumped all 3.7f 66 0 89 0 0 591396864 1615 1615 active+undersized+degraded 2018-07-05 15:29:15.741318 21361'80161 21365:128307 [5,29] 5 [5,29] 5 21315'80115 2018-07-05 02:52:51.512568 6206'80083 2018-06-29 22:51:05.831219

d. 客户端写入数据，必然要确保数据写入到PG 3.7f的副本中[5,29]

e. 遏制PG 3.7f中副本osd.29,而且查察PG 3.7f状态

f. 遏制PG 3.7f中副本osd.5,而且查察PG 3.7f状态

g. 拉起PG 3.7f中副本osd.21(此时的osd.21数据较量陈旧), 查察PG状态(down)

h. 客户端IO操纵

此时客户端IO城市夯住

ll /mnt/

妨碍总结：

起首有一个PG 3.7f有三个副本[5,21,29]， 当停掉一个osd.21之后， 写入数据到osd.5, osd.29。 这个时辰停掉osd.29, osd.5 ，最后拉起osd.21。 这个时辰osd.21的数据较量旧，就会呈现PG为down的环境，这个时辰客户端IO会夯住，只能拉起挂掉的osd才气修复题目。

3.8.3 结论

• 典范的场景：A(主)、B、C

1. 起首kill B

2. 新写入数据到 A、C

3. kill A和C

4. 拉起B

• 呈现PG为Down的场景是因为osd节点数据太旧，而且其他在线的osd不敷以完成数据修复。

• 这个时辰该PG不能提供客户端IO读写， IO会挂起夯住。

本文作者：李航，多年的底层开拓履历，在高机能nginx开拓和漫衍式缓存redis cluster有着富厚的履历，，今朝从事Ceph事变两年阁下。 先后在58同城、汽车之家、优酷土豆团体事变。 今朝供职于滴滴基本平台运维部 认真漫衍式Ceph集群开拓及运维等事变。 小我私人首要存眷的技能规模：高机能Nginx开拓、漫衍式缓存、漫衍式存储。

（编辑：河北网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!