分布式存储Ceph中PG各种状态详解.docx
- 文档编号:3093242
- 上传时间:2022-11-17
- 格式:DOCX
- 页数:15
- 大小:488.76KB
分布式存储Ceph中PG各种状态详解.docx
《分布式存储Ceph中PG各种状态详解.docx》由会员分享,可在线阅读,更多相关《分布式存储Ceph中PG各种状态详解.docx(15页珍藏版)》请在冰豆网上搜索。
分布式存储Ceph中PG各种状态详解
分布式存储Ceph中PG各种状态详解
1.PG介绍
本文主要来分享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完成后,如果基于当前权威日志无法对UpSet当中的某些PG实例实施增量同步(例如承载这些PG实例的OSD离线太久,或者是新的OSD加入集群导致的PG实例整体迁移)则通过完全拷贝当前Primary所有对象的方式进行全量同步
Backfill-toofull
某个需要被Backfill的PG实例,其所在的OSD可用空间不足,Backfill流程当前被挂起
Backfill-wait
等待Backfill资源预留
Clean
干净态。
PG当前不存在待修复的对象,ActingSet和UpSet内容一致,并且大小等于存储池的副本数
Creating
PG正在被创建
Deep
PG正在或者即将进行对象一致性扫描清洗
Degraded
降级状态。
Peering完成后,PG检测到任意一个PG实例存在不一致(需要被同步/修复)的对象,或者当前ActingSet小于存储池副本数
Down
Peering过程中,PG检测到某个不能被跳过的Interval中(例如该Interval期间,PG完成了Peering,并且成功切换至Active状态,从而有可能正常处理了来自客户端的读写请求),当前剩余在线的OSD不足以完成数据修复
Incomplete
Peering过程中,由于a.无非选出权威日志b.通过choose_acting选出的ActingSet后续不足以完成数据修复,导致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当前ActingSet小于存储池副本数
3.状态详解及故障模拟复现
3.1Degraded
3.1.1说明
•降级:
由上文可以得知,每个PG有三个副本,分别保存在不同的OSD中,在非故障情况下,这个PG是active+clean状态,那么,如果PG的副本osd.4挂掉了,这个PG是降级状态。
3.1.2故障模拟
1.停止osd.1$systemctlstopceph-osd@1
2.查看PG状态$bin/cephpgstat20pgs:
20active+undersized+degraded;14512kBdata,302GBused,6388GB/6691GBavail;12/36objectsdegraded(33.333%)
3.查看集群监控状态
4.客户端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.2Peered
3.2.1说明
·Peering已经完成,但是PG当前ActingSet规模小于存储池规定的最小副本数(min_size)。
3.2.2故障模拟
a.停掉两个副本osd.1,osd.0
$systemctlstopceph-osd@1$systemctlstopceph-osd@0
b.查看集群健康状态
c.客户端IO操作(夯住)
读取对象到文件,夯住IO
$bin/rados-ptest_poolgetmyobjectceph.conf.old
故障总结:
-现在pg只剩下osd.2上存活,并且pg还多了一个状态:
peered,英文的意思是仔细看,这里我们可以理解成协商、搜索。
-这时候读取文件,会发现指令会卡在那个地方一直不动,为什么就不能读取内容了,因为我们设置的min_size=2,如果存活数少于2,比如这里的1,那么就不会响应外部的IO请求。
d.调整min_size=1可以解决IO夯住问题
设置min_size=1
$bin/cephosdpoolsettest_poolmin_size1setpool1min_sizeto1
e.查看集群监控状态
f.客户端IO操作
读取对象到文件中
$ll-lhceph.conf*-rw-r--r--1rootroot6.1KJun2514:
01ceph.conf-rw-r--r--1rootroot6.1KJul320:
11ceph.conf.old-rw-r--r--1rootroot6.1KJul320:
11ceph.conf.old.1
故障总结:
-可以看到,PG状态Peered没有了,并且客户端文件IO可以正常读写了。
-当min_size=1时,只要集群里面有一份副本活着,那就可以响应外部的IO请求。
3.2.3总结
·Peered状态我们这里可以将它理解成它在等待其他副本上线。
·当min_size=2时,也就是必须保证有两个副本存活的时候就可以去除Peered这个状态。
·处于Peered状态的PG是不能响应外部的请求的并且IO被挂起。
3.3Remapped
3.3.1说明
·Peering完成,PG当前ActingSet与UpSet不一致就会出现Remapped状态。
3.3.2故障模拟
a.停止osd.x
$systemctlstopceph-osd@x
b.间隔5分钟,启动osd.x
$systemctlstartceph-osd@x
c.查看PG状态
d.客户端IO操作
rados读写正常
rados-ptest_poolputmyobject/tmp/test.log
3.3.3总结
·在OSD挂掉或者在扩容的时候PG上的OSD会按照Crush算法重新分配PG所属的osd编号。
并且会把PGRemap到别的OSD上去。
·Remapped状态时,PG当前ActingSet与UpSet不一致。
·客户端IO可以正常读写。
3.4Recovery
3.4.1说明
·指PG通过PGLog日志针对数据不一致的对象进行同步和修复的过程。
3.4.2故障模拟
a.停止osd.x
$systemctlstopceph-osd@x
b.间隔1分钟启动osd.x
osd$systemctlstartceph-osd@x
c.查看集群监控状态
$cephhealthdetailHEALTH_WARNDegradeddataredundancy:
183/57960objectsdegraded(0.316%),17pgsunclean,17pgsdegradedPG_DEGRADEDDegradeddataredundancy:
183/57960objectsdegraded(0.316%),17pgsunclean,17pgsdegradedpg1.19isactive+recovery_wait+degraded,acting[29,9,17]
3.4.3总结
·Recovery是通过记录的PGLog进行恢复数据的。
o记录的PGLog在osd_max_pg_log_entries=10000条以内,这个时候通过PGLog就能增量恢复数据。
3.5Backfill
3.5.1说明
·当PG的副本无非通过PGLog来恢复数据,这个时候就需要进行全量同步,通过完全拷贝当前Primary所有对象的方式进行全量同步。
3.5.2故障模拟
a.停止osd.x
$systemctlstopceph-osd@x
b.间隔10分钟启动osd.x
$osdsystemctlstartceph-osd@x
c.查看集群健康状态
$cephhealthdetailHEALTH_WARNDegradeddataredundancy:
6/57927objectsdegraded(0.010%),1pgunclean,1pgdegradedPG_DEGRADEDDegradeddataredundancy:
6/57927objectsdegraded(0.010%)
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 分布式 存储 Ceph PG 各种 状态 详解
![提示](https://static.bdocx.com/images/bang_tan.gif)