分布式存储Ceph中PG各种状态详解Word文件下载.docx

1、描述ActivatingPeering已经完成，PG正在等待所有PG实例同步并固化Peering的结果（Info、Log等）Active活跃态。PG可以正常处理来自客户端的读写请求Backfilling正在后台填充态。 backfill是recovery的一种特殊场景，指peering完成后，如果基于当前权威日志无法对Up Set当中的某些PG实例实施增量同步（例如承载这些PG实例的OSD离线太久，或者是新的OSD加入集群导致的PG实例整体迁移） 则通过完全拷贝当前Primary所有对象的方式进行全量同步Backfill-toofull某个需要被Backfill的PG实例，其所在的OSD可用空

2、间不足，Backfill流程当前被挂起Backfill-wait等待Backfill 资源预留Clean干净态。PG当前不存在待修复的对象， Acting Set和Up Set内容一致，并且大小等于存储池的副本数CreatingPG正在被创建DeepPG正在或者即将进行对象一致性扫描清洗Degraded降级状态。Peering完成后，PG检测到任意一个PG实例存在不一致（需要被同步/修复）的对象，或者当前ActingSet 小于存储池副本数DownPeering过程中，PG检测到某个不能被跳过的Interval中（例如该Interval期间，PG完成了Peering，并且成功切换至Active

3、状态，从而有可能正常处理了来自客户端的读写请求）,当前剩余在线的OSD不足以完成数据修复IncompletePeering过程中， 由于 a. 无非选出权威日志 b. 通过choose_acting选出的Acting Set后续不足以完成数据修复，导致Peering无非正常完成Inconsistent不一致态。集群清理和深度清理后检测到PG中的对象在副本存在不一致，例如对象的文件大小不一致或Recovery结束后一个对象的副本丢失PeeredPeering已经完成，但是PG当前ActingSet规模小于存储池规定的最小副本数（min_size）Peering正在同步态。PG正在执行同步处理Re

4、covering正在恢复态。集群正在执行迁移或同步对象和他们的副本Recovering-wait等待Recovery资源预留Remapped重新映射态。PG活动集任何的一个改变，数据发生从老活动集到新活动集的迁移。在迁移期间还是用老的活动集中的主OSD处理客户端请求，一旦迁移完成新活动集中的主OSD开始处理RepairPG在执行Scrub过程中，如果发现存在不一致的对象，并且能够修复，则自动进行修复状态ScrubbingPG正在或者即将进行对象一致性扫描Unactive非活跃态。PG不能处理读写请求Unclean非干净态。PG不能从上一个失败中恢复Stale未刷新态。PG状态没有被任何OSD更

5、新，这说明所有存储这个PG的OSD可能挂掉, 或者Mon没有检测到Primary统计信息（网络抖动）UndersizedPG当前Acting Set小于存储池副本数3. 状态详解及故障模拟复现3.1 Degraded3.1.1 说明 降级：由上文可以得知，每个PG有三个副本，分别保存在不同的OSD中，在非故障情况下，这个PG是active+clean 状态，那么，如果PG 的 副本osd.4 挂掉了，这个 PG 是降级状态。3.1.2 故障模拟1.停止osd.1 $ systemctl stop ceph-osd12.查看PG状态 $ bin/ceph pg stat 20 pgs: 20 a

6、ctive+undersized+degraded; 14512 kB data, 302 GB used, 6388 GB / 6691 GB avail; 12/36 objects degraded （33.333%）3.查看集群监控状态4.客户端IO操作故障总结：为了模拟故障，（size = 3, min_size = 2） 我们手动停止了 osd.1，然后查看PG状态，可见，它此刻的状态是active+undersized+degraded,当一个 PG 所在的 OSD 挂掉之后，这个 PG 就会进入undersized+degraded 状态，而后面的0,2的意义就是还有两个副本存

7、活在 osd.0 和 osd.2 上, 并且这个时候客户端可以正常读写IO。3.1.3 总结降级就是在发生了一些故障比如OSD挂掉之后，Ceph 将这个 OSD 上的所有 PG 标记为 Degraded。降级的集群可以正常读写数据，降级的 PG 只是相当于小毛病而已，并不是严重的问题。Undersized的意思就是当前存活的PG 副本数为 2，小于副本数3，将其做此标记，表明存货副本数不足，也不是严重的问题。3.2 Peered3.2.1 说明Peering已经完成，但是PG当前Acting Set规模小于存储池规定的最小副本数（min_size）。3.2.2 故障模拟a. 停掉两个副本osd

8、.1,osd.0$ systemctl stop ceph-osd1 $ systemctl stop ceph-osd0b. 查看集群健康状态c. 客户端IO操作（夯住）读取对象到文件，夯住IO$ bin/rados -p test_pool get myobject ceph.conf.old- 现在pg 只剩下osd.2上存活，并且 pg 还多了一个状态：peered，英文的意思是仔细看，这里我们可以理解成协商、搜索。- 这时候读取文件，会发现指令会卡在那个地方一直不动，为什么就不能读取内容了，因为我们设置的 min_size=2 ，如果存活数少于2，比如这里的 1 ，那么就不会响应外部

9、的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 1e. 查看集群监控状态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:1

10、1 ceph.conf.old.1- 可以看到，PG状态Peered没有了，并且客户端文件IO可以正常读写了。- 当min_size=1时，只要集群里面有一份副本活着，那就可以响应外部的IO请求。3.2.3 总结Peered状态我们这里可以将它理解成它在等待其他副本上线。当min_size = 2 时，也就是必须保证有两个副本存活的时候就可以去除Peered这个状态。处于 Peered 状态的 PG 是不能响应外部的请求的并且IO被挂起。3.3 Remapped3.3.1 说明Peering完成，PG当前Acting Set与Up Set不一致就会出现Remapped状态。3.3.2 故障模拟

11、a. 停止osd.x$ systemctl stop ceph-osdxb. 间隔5分钟，启动osd.x$ systemctl start ceph-osdxc. 查看PG状态d. 客户端IO操作rados读写正常rados -p test_pool put myobject /tmp/test.log3.3.3 总结在 OSD 挂掉或者在扩容的时候PG 上的OSD会按照Crush算法重新分配PG 所属的osd编号。并且会把 PG Remap到别的OSD上去。Remapped状态时，PG当前Acting Set与Up Set不一致。客户端IO可以正常读写。3.4 Recovery3.4.1 说

12、明指PG通过PGLog日志针对数据不一致的对象进行同步和修复的过程。3.4.2 故障模拟b. 间隔1分钟启动osd.xosd$ systemctl start ceph-osdxc. 查看集群监控状态$ 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%

13、）, 17 pgs unclean, 17 pgs degraded pg 1.19 is active+recovery_wait+degraded, acting 29,9,173.4.3 总结Recovery是通过记录的PGLog进行恢复数据的。o记录的PGLog 在osd_max_pg_log_entries=10000条以内，这个时候通过PGLog就能增量恢复数据。3.5 Backfill3.5.1 说明当PG的副本无非通过PGLog来恢复数据，这个时候就需要进行全量同步，通过完全拷贝当前Primary所有对象的方式进行全量同步。3.5.2 故障模拟b. 间隔10分钟启动osd.x$ osd systemctl start ceph-osdxc. 查看集群健康状态 6/57927 objects degraded （0.010%）, 1 pg unclean, 1 pg degraded PG_DEGRADED Degraded data redundancy: 6/57927 objects degraded （0.010%）