概述
为了实现不同存储池之间的策略隔离，以及针对不同用途的存储池指定不同的容灾策略，ceph crush使用中间结构即Placement Group（后续均以PG简称）将应用数据对象进行映射后，写入OSD本地存储设备。PG也是我们日常运维当中，操作最多、关注最多、数据恢复和迁移的基本单位。
pg dump
以下几个pg信息中较常用的一些概念
pgid
pg唯一标识，由poolid+pg编号组成。
Acting set
一组osd组合，类似[0,1,2]，代表osd.0，osd.1，osd.2这三个osd，代表这组osd当前正承担这个pg对应的副本，该组合是根据osd状态变化、历史pg归属等选择出来的（并非crush直接计算得出，有别于up set）。
Up set
根据crush 计算出来的osd组合，也表示该pg正常状态下应当由哪些osd承担副本，一般通过比对Up set和Acting set就可以得知该pg的大概状态。一般来说up set与acting set的osd组合一致。（表示集群当前承担数据的osd与计算得出应该存在的osd时一致的）。高版本后引入upmap工具，可以重映射或更改up set，从而实现pg迁移。
简单理解，集群的pg数据恢复，就是acting set 变为和up set一致且osd中对象完整的过程。
primary
up set和acting set组合中的一个osd，对应pg为主pg，osd即为主osd
replica
除了主osd外，副本组合中的其他osd成员
backfill
backfill的本质可以理解为pg的全量复制，往往是pg peering完成后，如果基于权威日志无法进行增量同步（坏盘，本身盘离线太久，或者新osd本身就没有日志和数据，pg的整体迁移），就会将acting primary中所有对象进行全量复制的方式进行同步恢复。
backfill是集群数据恢复非常重要的方式之一，该过程对集群的数据一致性，集群稳定性，业务性能都有重大意义。
recovery
同样也是集群数据恢复的方式之一，如果集群权威日志足够进行增量同步，副本间数据差异较小（常见于osd重启等），当peering成功完成后，对pg中的降级对象进行增量同步，最终达到clean状态。
epoch
osdmap版本号，集群monitor角色生成，是会不断增长的正整数。
epoch递增表示集群的osdmap发生了变化，该变化会通知到所有的客户端和osd。需要注意的是，集群中所有的osd的osdmap应该一致，即使这些osd不同属一个pool或者归置组。
通过osd status可以看到osd最老和最新的epoch版本号，两者间的差值即为osd一共保存的osdmap个数，一般来说在两千以内。（osdmap保存需要占用实际硬盘空间，而且每个osd都需要保存osdmap，所以需要控制该数量）。正常情况下，最老的版本会自动删除，向最新的靠近，当集群有osd异常时，osdmap会一直保留（认为离线和异常的osd还会重新up，因此会等待老版本osdmap），此时需要注意osdmap占用和集群健康问题。
此外在osd.log，osd init和start过程中，也经常能看到类似，"src have [1000，2000]，i have 600 epoc"之类的日志，当该osdmap与集群同步后，该osd才能正常进入up 状态。
log
记录所有客户端写的简略信息，作为集群异常时，recovery的依赖
peering
归属同一个pg的所有副本队pg存储的所有对象和状态进行判断和达成一致的过程。一般peering后，pg会进入active状态，以接受客户端的读写请求。
pg temp
为避免业务中断，用来进行业务过度的临时机制。例如，当扩容新osd时，根据 crush计算，up primary为新osd，然后此时新osd上还没有pg数据，此时就需要选择有该完整副本的osd加入pg temp。由这些临时副本处理客户端的读写请求，指导副本全部同步完成。
常见pg状态
- active：pg可以处理客户端读写请求
- activing：pg peering结束，正在等待副本同步和返回peering结果
- backfilling：正在进行副本的全量同步
- backfill_wait:位于backfill队列中，等待系统资源
- backfill-toofull：需要进行全量复制的osd空间不足（一般集群的backfill_full_ratio默认为90%）
- clean：pg中所有副本都在线，且数据一致
- creating：一般是刚创建pool时，pg正在创建
- degraded：pg中有降级对象，或该pg所在的osd组合低于对应存储池的size，例如三副本pool，某个pg有一个osd离线
- down：peering时，发现存活的副本不足以完成数据恢复
- incomplete：peering时，无法选出权威日志，或acting set无法完成数据恢复（不完整）
- inconsistent：集群scrub时，发现某些对象在副本之间有差异（不一致）
- recovering：根据日志对降级对象进行数据恢复
- remapped：pg重映射，up set与acting set不一致，常发生于pg迁移，重平衡过程
- scrubbing：pg正在进行scrub
- stale：pg所在主osd没有想monitor更新pg相关信息，或者osd down后没有切换到新osd进行io。
- undersized：当前acting中副本数小于存储池副本数。