1. PG介绍
继上次分享的《Ceph介绍及原理架构分享》，这次主要来分享Ceph中的PG各种状态详解，PG是最复杂和难于理解的概念之一，PG的复杂如下：
- 在架构层次上，PG位于RADOS层的中间。
a. 往上负责接收和处理来自客户端的请求。
b. 往下负责将这些数据请求翻译为能够被本地对象存储所能理解的事务。 - 是组成存储池的基本单位，存储池中的很多特性，都是直接依托于PG实现的。
- 面向容灾域的备份策略使得一般而言的PG需要执行跨节点的分布式写，因此数据在不同节点之间的同步、恢复时的数据修复也都是依赖PG完成。
2. 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小于存储池副本数 |
3. 状态详解及故障模拟复现
3.1 Degraded
3.1.1 说明
- 降级：由上文可以得知，每个PG有三个副本，分别保存在不同的OSD中，在非故障情况下，这个PG是active+clean 状态，那么，如果PG 的 副本osd.4 挂掉了，这个 PG 是降级状态。
3.1.2 故障模拟
a. 停止osd.1
1 | $ systemctl stop ceph-osd@1 |
b. 查看PG状态
1 | $ bin/ceph pg stat |
c. 查看集群监控状态
1 | $ bin/ceph health detail |
d. 客户端IO操作
1 | #写入对象 |
故障总结：
为了模拟故障，(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
1 | $ systemctl stop ceph-osd@1 |
b. 查看集群健康状态
1 | $ bin/ceph health detail |
c. 客户端IO操作(夯住)
1 |
|
故障总结：
- 现在pg 只剩下osd.2上存活，并且 pg 还多了一个状态：peered，英文的意思是仔细看，这里我们可以理解成协商、搜索。
- 这时候读取文件，会发现指令会卡在那个地方一直不动，为什么就不能读取内容了，因为我们设置的 min_size=2 ，如果存活数少于2，比如这里的 1 ，那么就不会响应外部的IO请求。
d. 调整min_size=1可以解决IO夯住问题
1 | #设置min_size = 1 |
e. 查看集群监控状态
1 | $ bin/ceph health detail |
f. 客户端IO操作
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
1 | $ systemctl stop ceph-osd@x |
b. 间隔5分钟，启动osd.x
1 | $ systemctl start ceph-osd@x |
c. 查看PG状态
1 | $ ceph pg stat |
d. 客户端IO操作
1 |
|
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
1 | $ systemctl stop ceph-osd@x |
b. 间隔1分钟启动osd.x
1 | osd$ systemctl start ceph-osd@x |
c. 查看集群监控状态
1 | $ ceph health detail |
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
1 | $ systemctl stop ceph-osd@x |
b. 间隔10分钟启动osd.x
1 | $ osd systemctl start ceph-osd@x |
c. 查看集群健康状态
1 | $ ceph health detail |
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
1 | $ systemctl stop ceph-osd@23 |
b. 然后停止osd.24
1 | $ systemctl stop ceph-osd@24 |
c. 查看停止两个副本PG 1.45的状态(undersized+degraded+peered)
1 | $ ceph health detail |
d. 在停止PG 1.45中第三个副本osd.10
1 | $ systemctl stop ceph-osd@10 |
e. 查看停止三个副本PG 1.45的状态(stale+undersized+degraded+peered)
1 | $ ceph health detail |
f. 客户端IO操作
1 | #读写挂载磁盘IO 夯住 |
故障总结：
先停止同一个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头文件
1 | $ rm -rf /var/lib/ceph/osd/ceph-34/current/3.0_head/DIR_0/1000000697c.0000122c__head_19785300__3 |
b. 手动执行PG 3.0进行数据清洗
1 | $ ceph pg scrub 3.0 |
c. 检查集群监控状态
1 | $ ceph health detail |
d. 修复PG 3.0
1 | $ ceph pg repair 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内副本数
1 | $ ceph pg dump | grep ^3.7f |
b. 停止PG 3.7f 副本osd.21
1 | $ systemctl stop ceph-osd@21 |
c. 查看PG 3.7f状态
1 | $ ceph pg dump | grep ^3.7f |
d. 客户端写入数据，一定要确保数据写入到PG 3.7f的副本中[5,29]
1 | $ fio -filename=/mnt/xxxsssss -direct=1 -iodepth 1 -thread -rw=read -ioengine=libaio -bs=4M -size=2G -numjobs=30 -runtime=200 -group_reporting -name=read-libaio |
e. 停止PG 3.7f中副本osd.29,并且查看PG 3.7f状态(undersized+degraded+peered)
1 | #停止该PG副本osd.29 |
f. 停止PG 3.7f中副本osd.5,并且查看PG 3.7f状态(undersized+degraded+peered)
1 | #停止该PG副本osd.5 |
g. 拉起PG 3.7f中副本osd.21(此时的osd.21数据比较陈旧), 查看PG状态(down)
1 | #拉起该PG的osd.21 |
h. 客户端IO操作
1 | #此时客户端IO都会夯住 |
故障总结：
首先有一个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 PG为Down的OSD丢失或无法拉起
- 修复方式(生产环境已验证)
1 | a. 删除无法拉起的OSD |
3.8.4 结论
- 典型的场景：A(主)、B、C
1 | a. 首先kill B |
- 出现PG为Down的场景是由于osd节点数据太旧，并且其他在线的osd不足以完成数据修复。
- 这个时候该PG不能提供客户端IO读写， IO会挂起夯住。
3.9 Incomplete
Peering过程中， 由于 a. 无非选出权威日志 b. 通过choose_acting选出的Acting Set后续不足以完成数据修复，导致Peering无非正常完成。
常见于ceph集群在peering状态下，来回重启服务器，或者掉电。
3.9.1 总结
- 修复方式 wanted: command to clear ‘incomplete’ PGs
比如：pg 1.1是incomplete，先对比pg 1.1的主副本之间 pg里面的对象数 哪个对象数多 就把哪个pg export出来
然后import到对象数少的pg里面 然后再mark complete，一定要先export pg备份。
简单方式，数据可能又丢的情况
1 | a. stop the osd that is primary for the incomplete PG; |
保证数据完整性
1 |
|