Ceph 放置组（PG）故障排查完全指南：从 PG 卡在非 clean 状态到数据恢复实战

存储分布式文件系统对象存储后端高可用【免费下载链接】cephCeph is a distributed object, block, and file storage platform项目地址https://gitcode.com/gh_mirrors/ce/ceph点击查看免费下载导读本文聚焦 Ceph 分布式存储集群中最为关键的运维场景——放置组Placement Group, PG的状态异常与故障排查。当集群出现activedegraded、downpeering、stuck unclean或inconsistent等异常状态时如何定位根因、使用正确的命令进行干预是每一个 Ceph 管理员都必须掌握的硬技能。读完本文你将能够诊断 PG 无法达到activeclean的多种配置原因、识别并处理 stuck卡死PG、应对 peering 失败与 unfound找不到对象、理解并执行 PG 修复repair流程以及解决纠删码erasure coded池的 CRUSH 映射问题。本文内容以官方文档 troubleshooting-pg.rst 为骨架并结合仓库源码如 global.yaml.in、osd.yaml.in、MonCommands.h、PGMap.cc对每个结论给出实现级佐证确保每一条建议都可查证、可落地。一、PG 永远无法达到 clean先检查配置Placement Group 长期停留在active、activeremapped或activedegraded状态始终无法进入activeclean通常是集群配置问题而非硬件故障。出现这种情况时请先回头审查 Pool、PG 与 CRUSH 配置参考 中的相关设置并做针对性调整。作为通用原则生产集群至少运行多个 OSD且池的副本数size应大于 2否则一旦发生故障数据冗余度将不足以支撑恢复。常见的具体原因与对策如下。1.1 单节点集群必须修改 chooseleaf 类型Ceph 是面向分布式计算设计的系统官方已不再为单节点运行提供完整文档。单节点上同时运行 Ceph 守护进程并直接挂载内核客户端可能因 Linux 内核自身问题引发死锁除非客户端跑在虚拟机中。但在理解上述限制的前提下仍可在单节点上进行实验。搭建单节点集群时必须在创建 Monitor 和 OSD之前修改配置项osd_crush_chooseleaf_type 0默认值为1含义是host主机/节点改为0后含义为osd即允许 CRUSH 在同一台主机上放置多个 OSD 的 PG。如果该值大于0Ceph 会尝试把某个 OSD 的 PG 与另一个 OSD 的 PG 放到**另一台节点、机箱chassis、机架rack、行row或数据中心datacenter**上具体取决于设置单节点集群将永远无法完成映射。该配置项在源码 global.yaml.in 中的定义佐证了这一点desc明确指出它是 CRUSH 规则中chooseleaf使用的 bucket 类型default: 1并带有cluster_create标志——即在创建集群时生效这也解释了为何必须在创建 Monitor/OSD 前设置。提示切勿在内核客户端与 Ceph 存储集群共存的同一节点上直接挂载内核客户端内核冲突不可避免如需单节点挂载请使用虚拟机VM作为客户端。若使用单块磁盘创建 OSD还需手动先创建数据目录。1.2 可用 OSD 少于副本数如果部分 OSD 处于up且in状态但 PG 始终无法activeclean很可能是 osd_pool_default_size 的值大于当前处于upin状态的 OSD 数量。两种典型的解决办法接受降级写入调低 min_size例如希望以osd_pool_default_size3运行、但集群只剩 2 个副本可用时将osd_pool_default_min_size设为2集群就能在activedegraded状态下继续接收写入。直接降低副本数将osd_pool_default_size改为2只保留 2 份副本原始 1 副本集群通常即可恢复到activeclean。注意这两个参数都带有runtime标志见 global.yaml.in可以在集群运行期间动态修改但如果写入的是 Ceph 配置文件如ceph.conf则需要重启集群才能生效。从源码看osd_pool_default_min_size 的long_desc解释了它的真实语义它是“客户端 I/O 被确认所需的最少副本数”若未达到该值Ceph 将不向客户端确认 I/O可能导致数据丢失默认值0表示无特别限制此时有效最小值按size - (size / 2)计算。1.3 池大小 1数据无第二份副本若osd_pool_default_size1对象只有一份拷贝。OSD 依赖其他 OSD 告知自己应当拥有哪些对象——如果某个对象只有第一份拷贝而没有任何第二份就没有第二个 OSD 能告诉第一个 OSD“你该拥有这个 PG”。此时针对映射到该 OSD 的每个 PG可用ceph pg dump查看可以强制该 OSD 意识到自己需要的 PGceph osd force-create-pg pgid该命令在 MonCommands.h 中注册并在 OSDMonitor.cc 中处理属于 Monitor 侧直接干预 PG 创建的命令仅在极少数如单副本且 OSD 重启后丢失 PG 认知的场景下使用。1.4 CRUSH Map 存在错误如果集群中有任何 PG 处于unclean状态则 CRUSH map 中很可能存在错误例如 bucket 结构、权重或规则与物理拓扑不符。此时应结合下文“纠删码池的 CRUSH 映射问题”一节使用ceph osd crush rule dump与crushtool对规则进行离线验证。二、Stuck卡死放置组健康告警与三种典型状态组件故障后 PG 进入degraded或peering状态是正常的它们反映的是故障恢复流程的预期推进。但若 PG 长期停留于某一非最优状态则可能暗示更大的问题。为此Ceph Monitor 会对“卡死”的 PG 发出健康告警具体检测三种情况状态判定条件含义inactivePG 长时间未处于active无法服务读写请求uncleanPG 长时间未处于clean无法从之前的故障中完全恢复staleOSD 长时间未更新 PG 状态存储该 PG 的所有节点可能均已down列出卡死的 PGceph pg dump_stuck stale ceph pg dump_stuck inactive ceph pg dump_stuck uncleanstale通常意味着关键 OSD 未运行inactive通常意味着 peering 问题见下文第三节unclean通常意味着有东西阻碍恢复完成例如存在 unfound 对象见下文第四节。该命令在 Monitor 侧由 PGMap.cc 的dump_stuck/dump_stuck_plain/dump_stuck_pg_stats系列函数实现其核心逻辑即以当前时间与cutoff卡死阈值时间比较筛选出超时未更新的 PG。三、PG Down Peering 失败定位与恢复某些情况下OSD 的peering对等过程会遇到问题导致 PG 无法变为active并对外服务。此时运行ceph health detail会输出类似以下内容HEALTH_ERR 7 pgs degraded; 12 pgs down; 12 pgs peering; 1 pgs recovering; 6 pgs stuck unclean; 114/3300 degraded (3.455%); 1/3 in osds are down ... pg 0.5 is downpeering pg 1.4 is downpeering ... osd.1 is down since epoch 69, last address 192.168.106.220:6801/8651下一步是查询该 PG 的详细状态弄清其为何被标记为downceph pg 0.5 query返回的 JSON 中recovery_state是关键{ state: downpeering, ... recovery_state: [ { name: Started/Primary/Peering/GetInfo, enter_time: 2012-03-06 14:40:16.169679, requested_info_from: []}, { name: Started/Primary/Peering, enter_time: 2012-03-06 14:40:16.169659, probing_osds: [ 0, 1], blocked: peering is blocked due to down osds, down_osds_we_would_probe: [ 1], peering_blocked_by: [ { osd: 1, current_lost_at: 0, comment: starting or marking this osd lost may let us proceed}]}, { name: Started, enter_time: 2012-03-06 14:40:16.169513} ] }recovery_state告诉我们peering 被阻塞的原因是 OSD 宕机具体是osd.1。此时有两种处理路径路径一恢复 OSD。若osd.1只是临时故障例如进程被杀、机器重启直接启动该 OSD恢复流程即会自动继续。路径二宣告 OSD lost。若osd.1发生灾难性故障如磁盘损坏、数据不可恢复可告知集群该 OSD 已lost并指示集群在尽力而为的前提下继续恢复ceph osd lost 1重要宣告 OSD 丢失是危险操作——集群无法保证其余副本的数据是一致且最新的。仅在确认该 OSD 数据永久不可用时才执行。执行后恢复流程会继续进行。关于 peering 失败与 OSD 故障的更多背景可参阅 Ceph 健康检查文档 中关于 OSD down 与 PG 状态的说明。四、Unfound找不到对象数据存在却无处可寻在某些故障组合下Ceph 会报告unfound对象ceph health detailHEALTH_WARN 1 pgs degraded; 78/3778 unfound (2.065%) pg 2.4 is activedegraded, 78 unfound含义是集群知道某些对象或现有对象的更新版本存在但找不到它们的任何副本。文档给出了一个典型的产生场景以数据分布在第 1、2 号 OSD 的 PG 为例OSD 1 宕机OSD 2 独自处理了部分写入OSD 1 恢复上线OSD 1 与 OSD 2 重新 peeringOSD 1 缺失的对象进入恢复队列新对象尚未拷贝完成前OSD 2 又宕机了。此时 OSD 1 知道这些对象存在但没有存活的 OSD 持有它们的副本。对这些对象的 I/O 会阻塞集群寄希望于故障节点尽快回归——这被认为是优于直接向用户返回 I/O 错误的做法。注意这正是复制池设置size2、纠删码池设置m1会面临数据丢失风险的原因之一——只有一份冗余任何节点宕机都可能造成不可恢复。4.1 列出 unfound 对象ceph pg 2.4 list_unfound [starting offset, in json]{ num_missing: 1, num_unfound: 1, objects: [ { oid: { oid: object, key: , snapid: -2, hash: 2249616407, max: 0, pool: 2, namespace: }, need: 43251, have: 00, flags: none, clean_regions: clean_offsets: [], clean_omap: 0, new_object: 1, locations: [ 0(3), 4(2) ] } ], state: NotRecovering, available_might_have_unfound: true, might_have_unfound: [ { osd: 2(4), status: osd is down } ], more: false }字段解读objects每个缺失对象的元数据oid、所需版本need、已有版本have等might_have_unfound可能持有该对象副本的 OSD 列表及其探测状态——仅当available_might_have_unfound为 true 时提供其语义与ceph pg #.# query的输出一致区别在于已处于already probed状态的 OSD 会被忽略more若为true说明结果过长被截断需用starting offset继续分页查询。4.2 用 query 查看候选位置也可以直接使用 queryceph pg 2.4 queryrecovery_state: [ { name: Started/Primary/Active, enter_time: 2012-03-06 15:15:46.713212, might_have_unfound: [ { osd: 1, status: osd is down}]}]上例中集群知道osd.1可能持有数据但它处于down。候选 OSD 的完整状态集合包括already probed已探测querying查询中OSD is downOSD 宕机not queried (yet)尚未查询有时集群查询可能位置需要一些时间请耐心等待重试。需要说明的是还可能存在未列出的其他位置。例如某个 OSD 被停止并移出集群、集群完全恢复后又经后续故障出现 unfound 对象集群会忽略已被移除的 OSD尽管这种场景并不常见。4.3 宣告 unfound 对象为丢失如果所有可能位置都已被查询而对象依然丢失则只能放弃这些对象仅出现在异常故障组合下集群先了解到某些写入、而写入本身尚未恢复。将 unfound 对象标记为 lostceph pg 2.5 mark_unfound_lost revert|delete最后一个参数指定处理方式delete让集群彻底遗忘这些对象revert回滚到对象的上一版本若对象本身是新建的则遗忘之。注意revert不适用于纠删码池且可能让依赖该对象存在的应用产生困惑请谨慎使用。五、Homeless PG无处安放的 PG全部副本 OSD 均故障如果持有某个 PG 副本的所有OSD 全部故障该对象存储子集将不可用Monitor 将收不到这些 PG 的任何状态更新。此时 Monitor 会把主 OSD 故障的 PG标记为staleceph healthHEALTH_WARN 24 pgs stale; 3/300 in osds are down用以下命令确认哪些 PG 是stale、以及最后持有它们的 OSD 是谁ceph health detailHEALTH_WARN 24 pgs stale; 3/300 in osds are down ... pg 2.5 is stuck staleactiveremapped, last acting [2,0] ... osd.10 is down since epoch 23, last address 192.168.106.220:6800/11080 osd.11 is down since epoch 13, last address 192.168.106.220:6803/11539 osd.12 is down since epoch 24, last address 192.168.106.220:6806/11861上例中pg 2.5最后是由osd.0和osd.2管理的。重启这些 OSD集群即可恢复该 PG。六、只有少数 OSD 收到数据PG 数量不足或分布不均如果集群中只有少数节点在接收数据请检查池中的 PG 数量参见 Placement Groups 操作文档。由于 PG 到 OSD 的映射过程涉及“集群 PG 总数 ÷ 集群 OSD 总数”的除法运算当 PG 数量很少时除法的余数部分有时不会被均匀分布到整个集群。解决办法让池的 PG 数量成为 OSD 数量的整数倍。关于 PG 数量选择的原则以及每个 PG 承载对象数、容量预算等权衡请参阅 pg-concepts.rst如需修改新建池的默认 PG 数量参见 Pool、PG 与 CRUSH 配置参考。另外要注意现代 Ceph 默认启用 PG 自动缩放器autoscaler新建池默认只有 1 个 PG由 autoscaler 根据使用情况自动调整这一点在 osd_pool_default_pg_num 的long_desc中有明确说明。七、无法写入数据min_size 未满足集群整体在线、但部分 OSD 宕机时无法写入数据请确认池中运行的最小 OSD 数量是否满足要求。若未达到osd_pool_default_min_sizeCeph 将拒绝写入——因为无法保证数据能够被复制。其实现语义已在 global.yaml.in 中定义min_size 是客户端 I/O 被确认所需的最少副本数不满足即不确认详见 1.2 节。八、PG InconsistentScrub 发现不一致与 PG 修复8.1 发现不一致若ceph health detail报告activecleaninconsistent状态通常意味着scrub清扫过程中发现了错误。定位不一致的 PGceph health detailHEALTH_ERR 1 pgs inconsistent; 2 scrub errors pg 0.6 is activecleaninconsistent, acting [0,1,2] 2 scrub errors需要以编程方式检查时可使用rados list-inconsistent-pg rbd[0.6]注意一致的状态只有一种但最坏情况下多个对象的不同视图可能各自存在不同的不一致。例如 PG0.6中名为foo的对象被截断truncated时rados list-inconsistent-obj 0.6 --formatjson-pretty{ epoch: 14, inconsistents: [ { object: { name: foo, nspace: , locator: , snap: head, version: 1 }, errors: [ data_digest_mismatch, size_mismatch ], union_shard_errors: [ data_digest_mismatch_info, size_mismatch_info ], selected_object_info: 0:602f83fe:::foo:head(161 client.4110.0:1 dirty|data_digest|omap_digest s 968 uv 1 dd e978e67f od ffffffff alloc_hint [0 0 0]), shards: [ { osd: 0, errors: [], size: 968, omap_digest: 0xffffffff, data_digest: 0xe978e67f }, { osd: 1, errors: [], size: 968, omap_digest: 0xffffffff, data_digest: 0xe978e67f }, { osd: 2, errors: [ data_digest_mismatch_info, size_mismatch_info ], size: 0, omap_digest: 0xffffffff, data_digest: 0xffffffff } ] } ] }上例输出揭示了以下几点唯一不一致的对象是foo其head快照存在不一致不一致分为两类errors对象级表明各 shard 之间存在不一致但不指出哪个 shard 是坏的。结合shards数组中的错误即可定位问题。data_digest_mismatch从OSD.2读到的副本 digest 与OSD.0、OSD.1的不同size_mismatch从OSD.2读到的副本大小为0而OSD.0、OSD.1报告的为968。union_shard_errorsshard 级错误并集shards数组中所有 shard 特定错误的并集错误设置在出问题的那个 shard上包括read_error及其他类似错误以oi结尾的错误表示与selected_object_info的比较结果。data_digest_mismatch_infoobject-info中存储的 digest 与从OSD.2读取计算的 digest 不一致0xffffffff表示无有效 digestsize_mismatch_infoobject-info中记录的大小与从OSD.2实际读取的大小0不同。警告若某 shard 的errors中出现read_error不一致很可能是物理存储错误导致的。此时应先检查该 OSD 使用的存储介质在尝试修复磁盘前先查看dmesg与smartctl的输出。8.2 执行 PG 修复修复不一致的 PGceph pg repair {placement-group-ID}示例ceph pg repair 1.4警告该命令会用“权威副本”覆盖“坏副本”。大多数情况下 Ceph 能按预定义标准从所有可用副本中选出权威副本但并非总能奏效——例如存储的数据 digest 缺失时计算得到的 digest 在选择权威副本时会被忽略。请谨慎使用。说明PG ID 形如N.xxxxx其中N是所在池的编号。可用ceph osd listpools或ceph osd dump | grep pool查看池编号列表。另外若activecleaninconsistent周期性出现且怀疑与时钟偏移clock skew有关请考虑在 Monitor 主机上配置 NTP 守护进程并互为对端。可参考 mon-config-ref.rst 中的时钟设置章节。8.3 深入理解 PG 修复机制Ceph 会存储并持续更新集群中对象的校验和checksum。当对某个 PG 执行 scrub 时主 OSD 会尝试从各副本中选出一个权威副本可能的情况只有一种是一致的。执行深度 scrubdeep scrub后Ceph 会计算每个从磁盘读出的对象的校验和并与先前记录的校验和比对不一致即视为 inconsistency。对于复制池任一副本的校验和与权威副本不一致即构成不一致并导致 PG 状态被置为inconsistent。pg repair命令会尝试修复各种不一致对不一致的副本用权威副本的 digest覆盖其 digest对复制池中的不一致副本将其标记为 missing缺失——复制池场景下真正恢复数据已超出pg repair的职责范围需要依赖常规 recovery 流程补齐。对于纠删码池与 BlueStore 池Ceph 可自动执行修复条件是osd_scrub_auto_repair 设为true默认false发现的错误数不超过 osd_scrub_auto_repair_num_errors默认5。这两个配置项在 osd.yaml.in 中的定义明确印证了上述行为自动修复由 scrub/deep-scrub 发现错误时触发超过错误数阈值则不执行修复。pg repair并不能解决所有问题Ceph 也默认不会在发现不一致时自动修复 PG。此外RADOS 对象或 omap 的校验和并非总是可用——校验和是增量计算的若复制对象被非顺序更新写入操作会改变对象并使既有校验和失效且重算校验和时不会整对象重读。因此即使没有校验和如 Filestore 场景pg repair也能执行修复。对于 Filestore 复制池用户手动修复可能比ceph pg repair更合适。注意以上关于校验和的讨论主要针对FilestoreBlueStore 拥有自己的内部校验和机制。需要认识到已记录校验和与计算校验和匹配并不能证明某个副本就是权威的。若校验和不可用pg repair会偏向主副本primary上的数据但主副本未必是未损坏的那一份。正因这种不确定性发现不一致时通常需要人工介入有时会用到ceph-objectstore-tool进行对象级操作。官方另提供了一份针对已废弃的 Filestore 后端的 PG 修复演练指南见原文档引用的 ceph.io 页面对希望手工修复 Filestore PG 的读者有参考价值但不适用于现代 BlueStore OSD。九、纠删码池的 PG 无法 activeclean三类 CRUSH 映射问题如果 CRUSH 找不到足够多的 OSD 来映射某个 PG映射结果中会出现2147483647即ITEM_NONE等价于 “no OSD found”。示例[2,1,6,0,5,8,2147483647,7,4]针对不同的根因处理方式不同。9.1 情形一OSD 数量不足Not enough OSDs若集群只有 8 个 OSD而纠删码池每个 PG 需要 9 个 OSD映射必然失败集群报Not enough OSDs。两种解法添加更多 OSD——新 OSD 会被 PG 自动使用创建一个需要更少 OSD 的纠删码池ceph osd erasure-code-profile set myprofile k5 m3 ceph osd pool create erasurepool erasure myprofile9.2 情形二CRUSH 约束无法满足集群 OSD 总数足够但CRUSH 规则强加的约束无法被满足。例如两个主机上共有 10 个 OSD而 CRUSH 规则要求同一 PG 内不能出现来自同一主机的两个 OSD由于每主机只有 5 个 OSD映射就会失败。先检查dump规则ceph osd crush rule ls[ replicated_rule, erasurepool]ceph osd crush rule dump erasurepool{ rule_id: 1, rule_name: erasurepool, type: 3, steps: [ { op: take, item: -1, item_name: default}, { op: chooseleaf_indep, num: 0, type: host}, { op: emit}]}注意steps中的chooseleaf_indep ... type: host——正是它要求每个 PG 的 OSD 来自不同主机。解决办法是创建一个允许同一主机内 OSD 共存的池ceph osd erasure-code-profile set myprofile crush-failure-domainosd ceph osd pool create erasurepool erasure myprofilecrush-failure-domainosd将故障域从host降为osdCRUSH 便不再强制跨主机选择。9.3 情形三CRUSH 过早放弃Gives up too soon集群 OSD 数量刚好够用例如共 9 个 OSD、每个 PG 需要 9 个 OSD时CRUSH 可能在找到合法映射前就因重试次数用尽而放弃。解决途径有四降低每个 PG 所需 OSD 数需新建池因为纠删码 profile 无法动态修改向集群添加更多 OSD无需改动池会自动恢复 clean使用手工 CRUSH 规则并增大set_choose_tries让 CRUSH 尝试更多次使用多步重试Multi-Step Retry, MSRCRUSH 规则Squid 及以后版本参见 crush-map.rst 与 crush-map-edits.rst。先验证、后修改建议先用crushtool离线验证避免直接改动线上集群。具体流程ceph osd crush rule dump erasurepool{ rule_id: 1, rule_name: erasurepool, type: 3, steps: [ { op: take, item: -1, item_name: default}, { op: chooseleaf_indep, num: 0, type: host}, { op: emit}]}ceph osd getcrushmap crush.mapgot crush map from osdmap epoch 13crushtool -i crush.map --test --show-bad-mappings \ --rule 1 \ --num-rep 9 \ --min-x 1 --max-x $((1024 * 1024))bad mapping rule 8 x 43 num_rep 9 result [3,2,7,1,2147483647,8,5,6,0] bad mapping rule 8 x 79 num_rep 9 result [6,0,2,1,4,7,2147483647,5,8] bad mapping rule 8 x 173 num_rep 9 result [0,4,6,8,2,1,3,7,2147483647]参数说明--num-rep纠删码 CRUSH 规则所需的 OSD 数--ruleceph osd crush rule dump输出的rule_id字段值--min-x/--max-x模拟的 PG 放置数量范围PG 放置彼此独立仅取决于 hash 与 bucket 算法。若测试无任何输出说明所有映射均成功问题另有其因若出现如上所示的 bad mappings说明当前拓扑下 CRUSH 无法稳定放置 PG。只要并非所有映射都失败就可以通过让 CRUSH 规则搜索更久增大 tries来改善。9.4 修改 set_choose_tries 的具体步骤第 1 步反编译 CRUSH map 以编辑规则crushtool --decompile crush.map crush.txt为便于说明文档使用了一个简化的 CRUSH map 示例模拟单主机、四块磁盘3×1 TiB 1×200 GiB。以下设置专为该示例选取与生产集群通常使用的 CRUSH Map Tunables 不同由于默认值可能随版本变化请以你所用 Ceph 版本的文档为准。tunable choose_local_tries 0 tunable choose_local_fallback_tries 0 # artificially low total tries, for illustration tunable choose_total_tries 10 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 device 0 osd.0 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 zone type 10 region type 11 root # buckets host example { id -2 alg straw2 hash 0 # rjenkins1 item osd.0 weight 1.00000 item osd.1 weight 1.00000 item osd.2 weight 1.00000 item osd.3 weight 0.20000 } root default { id -1 alg straw2 hash 0 # rjenkins1 item example weight 3.20000 } # rules rule ec { id 0 type erasure step set_chooseleaf_tries 5 # artificially low tries, for illustration step set_choose_tries 5 step take default step choose indep 0 type osd step emit }第 2 步修改set_choose_tries向规则中添加一行若该行已存在如本例只需修改其数值step set_choose_tries 100修改后的规则应类似rule ec { id 0 type erasure step set_chooseleaf_tries 5 step set_choose_tries 100 step take default step choose indep 0 type osd step emit }第 3 步重新编译并重测crushtool --compile crush.txt -o better-crush.map第 4 步用--show-choose-tries查看尝试次数直方图当所有映射成功后可用直方图观察找到每个映射所需的尝试次数crushtool -i better-crush.map --test --show-bad-mappings \ --show-choose-tries \ --rule 0 \ --num-rep 3 \ --min-x 1 --max-x 100: 0 1: 0 2: 4 3: 3 4: 1 5: 1 6: 1 7: 0 8: 0 9: 0说明输出总行数等于 CRUSH map 中的choose_total_tries值但crushtool的计算不受该设置影响仅输出被截断。也可用--set-choose-total-tries参数在不修改 CRUSH map 的前提下调整该值。解读直方图输出是每个放置所需尝试次数的直方图。--min-x 1到--max-x 10共 10 次 PG 放置全部成功无 bad mapping 诊断消息4 个 PG 在 2 次尝试内完成放置1 个 PG 直到第 4 次尝试才成功。失败的放置会被计入其失败时所在的桶bucket——例如原始crush.txt中第 8 次放置在第 5 次尝试后失败会被计入第 5 个桶与另一个在第 5 次尝试成功的映射一同显示为 1 个条目。如前所述PG 放置仅取决于 CRUSH 拓扑与 hash/bucket 算法仅用--x 8而非范围运行原始crush.txt会确定性失败。因此生产环境评估合适的 tries 值时应使用大得多的范围如前述1024 * 1024。如何选取合适的 tries 值可先设置一个非常高的值如500并用大样本量大x范围测试观察整体分布。从统计学角度取最后一个非零值作为最大值在实际中几乎不可能再触发放置失败若希望用更小的值则需接受可能偶发放置失败、需要人工干预的风险。十、排查流程速查表症状首选诊断命令典型根因处理动作PG 长期activedegradedceph pg dump可用 OSD 数 size调osd_pool_default_size/osd_pool_default_min_size或补 OSDPGstaleceph pg dump_stuck stale关键 OSD 未运行重启对应 OSDPGinactive/downpeeringceph pg pgid querypeering 被宕机 OSD 阻塞恢复 OSD或ceph osd lost id慎用unfound对象ceph pg pgid list_unfound故障组合导致无存活副本恢复 OSD确认丢失后mark_unfound_lost revert\|deleteactivecleaninconsistentrados list-inconsistent-pgscrub 发现校验和/大小不一致ceph pg repair pgid检查物理盘纠删码池映射失败2147483647ceph osd crush rule dumpcrushtoolOSD 不足 / 约束过严 / tries 太少加 OSD、改 profile 或调set_choose_tries只有少数 OSD 收数据检查池 pg_numPG 数不是 OSD 数的整数倍调整 PG 数量利用 autoscaler 或手动设置无法写入检查 min_size存活的 OSD 少于 min_size恢复 OSD 或调整 min_size参考资源本文依据troubleshooting-pg.rst配置参考Pool、PG 与 CRUSH 配置参考PG 概念与数量规划pg-concepts.rst、placement-groups.rstCRUSH map 编辑与 MSR 规则crush-map-edits.rst、crush-map.rst健康检查与状态说明health-checks.rst、pg-states.rst关键配置项源码定义global.yaml.inosd_crush_chooseleaf_type/osd_pool_default_size/osd_pool_default_min_size、osd.yaml.inosd_scrub_auto_repair系列命令与实现源码MonCommands.hosd force-create-pg、PGMap.ccdump_stuck系列、OSDMonitor.ccforce-create-pg处理赞分享存储分布式文件系统对象存储后端高可用【免费下载链接】cephCeph is a distributed object, block, and file storage platform项目地址https://gitcode.com/gh_mirrors/ce/ceph点击查看免费下载相关推荐Ceph 放置组PG状态全解从 activeclean 到异常状态定位与恢复Ceph 放置组PG状态全解从 activeclean 到异常状态定位与恢复 本指南以 Ceph 官方文档 Placement Group States存储分布式文件系统对象存储后端高可用Ceph OSD 与 Placement GroupPG监控与故障排查实战指南Ceph OSD 与 Placement GroupPG监控与故障排查实战指南 Ceph 是一个分布式对象、块与文件存储平台其高可用与高可靠性建立在容错式存储分布式文件系统对象存储后端高可用Ceph RADOS 故障排查完全指南从动态日志调试到 Monitor/OSD/PG 深度排障与性能剖析Ceph RADOS 故障排查完全指南从动态日志调试到 Monitor/OSD/PG 深度排障与性能剖析 本文基于 Ceph 官方 RADOS 故障排查文档体存储分布式文件系统对象存储后端高可用创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考