继上次分享的《Ceph介绍及原理架构分享》,这次主要来分享Ceph中的PG各种状态详解,PG是最复杂和难于理解的概念之一,PG的复杂如下:
正常的PG状态是 100%的active + clean, 这表示所有的PG是可访问的,所有副本都对全部PG都可用。 如果Ceph也报告PG的其他的警告或者错误状态。PG状态表:
状态 | 描述 |
---|---|
Activating | Peering已经完成,PG正在等待所有PG实例同步并固化Peering的结果(Info、Log等) |
Active | 活跃态。PG可以正常处理来自客户端的读写请求 |
Backfilling | 正在后台填充态。 backfill是recovery的一种特殊场景,指peering完成后,如果基于当前权威日志无法对Up Set当中的某些PG实例实施增量同步(例如承载这些PG实例的OSD离线太久,或者是新的OSD加入集群导致的PG实例整体迁移) 则通过完全拷贝当前Primary所有对象的方式进行全量同步 |
Backfill-toofull | 某个需要被Backfill的PG实例,其所在的OSD可用空间不足,Backfill流程当前被挂起 |
Backfill-wait | 等待Backfill 资源预留 |
Clean | 干净态。PG当前不存在待修复的对象, Acting Set和Up Set内容一致,并且大小等于存储池的副本数 |
Creating | PG正在被创建 |
Deep | PG正在或者即将进行对象一致性扫描清洗 |
Degraded | 降级状态。Peering完成后,PG检测到任意一个PG实例存在不一致(需要被同步/修复)的对象,或者当前ActingSet 小于存储池副本数 |
Down | Peering过程中,PG检测到某个不能被跳过的Interval中(例如该Interval期间,PG完成了Peering,并且成功切换至Active状态,从而有可能正常处理了来自客户端的读写请求),当前剩余在线的OSD不足以完成数据修复 |
Incomplete | Peering过程中, 由于 a. 无非选出权威日志 b. 通过choose_acting选出的Acting Set后续不足以完成数据修复,导致Peering无非正常完成 |
Inconsistent | 不一致态。集群清理和深度清理后检测到PG中的对象在副本存在不一致,例如对象的文件大小不一致或Recovery结束后一个对象的副本丢失 |
Peered | Peering已经完成,但是PG当前ActingSet规模小于存储池规定的最小副本数(min_size) |
Peering | 正在同步态。PG正在执行同步处理 |
Recovering | 正在恢复态。集群正在执行迁移或同步对象和他们的副本 |
Recovering-wait | 等待Recovery资源预留 |
Remapped | 重新映射态。PG活动集任何的一个改变,数据发生从老活动集到新活动集的迁移。在迁移期间还是用老的活动集中的主OSD处理客户端请求,一旦迁移完成新活动集中的主OSD开始处理 |
Repair | PG在执行Scrub过程中,如果发现存在不一致的对象,并且能够修复,则自动进行修复状态 |
Scrubbing | PG正在或者即将进行对象一致性扫描 |
Unactive | 非活跃态。PG不能处理读写请求 |
Unclean | 非干净态。PG不能从上一个失败中恢复 |
Stale | 未刷新态。PG状态没有被任何OSD更新,这说明所有存储这个PG的OSD可能挂掉, 或者Mon没有检测到Primary统计信息(网络抖动) |
Undersized | PG当前Acting Set小于存储池副本数 |
• 降级:由上文可以得知,每个PG有三个副本,分别保存在不同的OSD中,在非故障情况下,这个PG是active+clean 状态,那么,如果PG 的 副本osd.4 挂掉了,这个 PG 是降级状态。
停止osd.1
$ systemctl stop ceph-osd@1
查看PG状态
$ bin/ceph pg stat
故障总结:
为了模拟故障,(size = 3, min_size = 2) 我们手动停止了 osd.1,然后查看PG状态,可见,它此刻的状态是active+undersized+degraded,当一个 PG 所在的 OSD 挂掉之后,这个 PG 就会进入undersized+degraded 状态,而后面的[0,2]的意义就是还有两个副本存活在 osd.0 和 osd.2 上, 并且这个时候客户端可以正常读写IO。
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
故障总结:
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
故障总结:
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
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]
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]
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。
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就会从其他的副本中将丢失的文件拷贝过来就行修复数据。
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才能修复问题。
• 典型的场景:A(主)、B、C
• 出现PG为Down的场景是由于osd节点数据太旧,并且其他在线的osd不足以完成数据修复。
• 这个时候该PG不能提供客户端IO读写, IO会挂起夯住。
作者信息
作者:李航 个人简介: 多年的底层开发经验,在高性能nginx开发和分布式缓存redis cluster有着丰富的经验,目前从事Ceph工作两年左右。 先后在58同城、汽车之家、优酷土豆集团工作。 目前供职于滴滴基础平台运维部 负责分布式Ceph集群开发及运维等工作。 个人主要关注的技术领域:高性能Nginx开发、分布式缓存、分布式存储。
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞8
添加新评论1 条评论
2018-07-12 09:33