Ceph PG状态小结

最近部署碰到最多的问题就是创建完ceph后，pg状态老是不对，在这贴一下遇到的问题，和解决的办法

为什么我的pg状态老是不对，为什么不对？

在刚进行创建系统池的时候，真的就是懵，不知道问题出现在哪里，然后摸索好久，首先最直观能够影响的就是crushmap的设置了

crushmap一般为这样

先可以看一下osd 划分情况

$ceph osd tree
-1            0 root default
 0            0 osd.0            up  1.00000 1.00000
 0            0 osd.1            up  1.00000 1.00000
 0            0 osd.2            up  1.00000 1.00000
 0            0 osd.3            up  1.00000 1.00000

$ceph osd  getcrushmap -o crushmap
获得crushmap
$crushtool -d crushmap  -o crushmap.txt
反编译crushmap
$vim crushmap.txt

# begin crush map
tunable choose_local_tries 0
tunable choose_local_fallback_tries 0
tunable choose_total_tries 150
tunable chooseleaf_descend_once 1
tunable chooseleaf_vary_r 1
tunable chooseleaf_stable 1
tunable straw_calc_version 1
tunable allowed_bucket_algs 54
# devices                      devices是在设备上创建了几个osd
device 1 osd.1
device 2 osd.2
device 3 osd.3
# types
type 0 osd
type 1 host
type 2 chassis
type 3 rack
type 4 row
type 5 pdu
type 6 pod
type 7 room
type 8 datacenter
type 9 region
type 10 root
# buckets
root default {                                         
    id -1       # do not change unnecessarily
    # weight 0.000
    alg straw2
    hash 0  # rjenkins1
}
root test {                                             #root是划分host点
    id -5       # do not change unnecessarily          
    # weight 0.879
    alg straw2
    hash 0  # rjenkins1
    item test_host weight 0.293                         #将定义好的host配置在root下
    item test_host2 weight 0.293
    item test_host3 weight 0.293
}
host test_host {                                        #host是每个节点所包含建立好的osd,具体有多少个osd，可以通过开始的查看命令进行查看
    id -3       # do not change unnecessarily
    # weight 0.098
    alg straw2
    hash 0  # rjenkins1
    item osd.1 weight 0.098                             #host下有一个osd.1
}
host test_host2 {
    id -6       # do not change unnecessarily
    # weight 0.098
    alg straw2
    hash 0  # rjenkins1
    item osd.2 weight 0.098
}
host test_host3 {
    id -7       # do not change unnecessarily
    # weight 0.098
    alg straw2
    hash 0  # rjenkins1
    item osd.3 weight 0.098
}
# rules
rule replicated_rule {                                 #这个rule是创建pool时所需要用的规则
    id 0
    type replicated
    min_size 1
    max_size 10
    step take default
    step chooseleaf firstn 0 type host
    step emit
}
rule test_pool {                                         #这个rule时自己定义的
    id 1
    type replicated
    min_size 1
    max_size 10
    step take test                                       #take后面的变量是所包含的root
    step chooseleaf firstn 3 type host
    step emit
}
# end crush map

在编写完毕之后，进行编译
$crushtool -c crushmap.txt -o crushmap.map
在设置进去
$ceph osd setcrushmap -i crushmap.map
成功之后，进行查看

$ceph osd tree
大致为这种样子
-5       0.87900 root test
-3       0.29300     host test_host
 1       0.09799         osd.1           up  1.00000 1.00000
-6       0.29300     host test_host2
 2       0.09799         osd.2           up  1.00000 1.00000
-7       0.29300     host test_host3
 3       0.09799         osd.3           up  1.00000 1.00000
这时的crush map设置成功

除了注释的地方，其他解释就是，每次去建立资源池是，选择的host一定要大于或者等于副本数，比如你要建立一个三副本的池子，但是只在rule task root时，root的bucket只有两个host就会发生降级

例如：

会出现这个状态

`Degraded data redundancy: 14918/22377 objects degraded (66.667%), 128 pgs[16.7,16.6,16.5,16.4..] degraded, 128 pgs[16.7,16.6,16.5,16.4..] undersized`

`data:`

`pools: 16 pools, 128 pgs`

`objects: 7459 objects, 110M`

`usage: 11067M used, 40133M / 51200M avail`

`pgs: 14918/22377 objects degraded (66.667%)`

`128 active+degraded+undersized`

这个就是因为副本数和rule里面root的host数量不匹配所造成的，修改一下crushmap，或者修改副本数都能修复，这个具体看实现场景

$ceph osd pool set testpool size ${num}   	${num}替换成crush中的host数量

正常状态如下：

`usage: 3051M used, 369G / 371G avail`

`pgs: 2368 active+clean`

除了上面的这种情况还有其他的情况，在保证crushmap设置正确之后，创建池子如果出现

`pools: 16 pools, 128 pgs`

`objects: 7459 objects, 110M`

`usage: 11067M used, 40133M / 51200M avail`

`pgs: 14918/22377 objects degraded (66.667%)`

`128 active+degraded+undersized`

48 peering+creating

这样一直卡在创建状态

有以下几种可能

osd节点挂了，这种情况重新启动osd服务，或者看具体日志报错
网络故障问题，可能是防火墙拦截或者是其他问题。

排查的时候可以将怀疑节点在crushmap中剔除然后试着创建，最终来排查出原因。

最后放一个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 小于存储池副本数