分布式存储Ceph中PG各种状态详解.docx

? ? ? ? ? ? ? 分布式存储 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完成后，如果基于当前权威日志无法对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 故障模拟 停止osd.1 $ systemctl stop ceph-osd@1 查看PG状态 $ bin/ceph pg stat 20 pgs: 20 active+undersized+degra