ceph pg Troubleshoting

最新推荐文章于 2024-05-15 01:43:01 发布

Man_In_The_Night

最新推荐文章于 2024-05-15 01:43:01 发布

阅读量1.4k

点赞数

分类专栏： ceph 运维文章标签： ceph pg Troubleshoting 排错

记录学习中的各种问题以及自己的理解，供以后温故以及分享一下，错误之处，希望批评指正，以免误导更多人。如有侵权，请联系删除。谢谢！

本文链接：https://blog.csdn.net/Man_In_The_Night/article/details/109090066

版权

运维同时被 2 个专栏收录

152 篇文章

订阅专栏

ceph

14 篇文章

订阅专栏

本文详细介绍了在Ceph存储系统中遇到的pg（Placement Group）问题，如stuck在degraded、peering或inactive状态的解决办法。通过`ceph health detail`和`ceph pg dump_stuck_inactive`等命令进行诊断，并提供了针对不同状态的解决策略，如重启osd、标记osd为lost等。此外，还提到了unfound object的情况以及如何处理。最后，讨论了pg inconsistent状态的修复方法，如使用`ceph pg repair`命令。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Troubleshoting pg

stuck placement group

pg 显示 degraded 和 peering 状态很正常，这些信息一般表明对失败的恢复过程采取的正常行动。但是，如果 pg 长时间处于这种状态，表明可能问题很严重。

inactive：pg 太长时间没有 active（pg 无法读写）

unclean：pg 太长时间没有 clean （pg 没有完全从之前的失败中恢复）

stale：ceph-osd 长时间没有报告 pg 的状态，表明存储该 pg 的所有节点可能 down 掉

对于处于 stale 状态的 pg，通常的做法是让对应的 osd 启动。对于 inactive 状态的 pg，通常是一个 peering 问题。对于处于 unclean 状态的 pg ，通常表明有些问题在阻止恢复，比如 object unfound。

placement group down peering failure

有些情况，ceph-osd peering 过程可能出问题，导致 pg 无法 active 和使用。例如下面的问题

[root@k8sGUPMaster01 ~]# ceph health detail
HEALTH_WARN Reduced data availability: 1 pg inactive, 1 pg peering
PG_AVAILABILITY Reduced data availability: 1 pg inactive, 1 pg peering
    pg 8.15 is stuck peering for 609046.271579, current state peering, last acting [44,29,38]

使用 ceph pg query 查看原因

[root@k8sGUPMaster01 ~]# ceph pg dump_stuck inactive
PG_STAT STATE   UP         UP_PRIMARY ACTING     ACTING_PRIMARY 
8.15    peering [44,29,38]         44 [44,29,38]             44 
ok

[root@k8sGUPMaster01 ~]# ceph pg 8.15 query
{
...
    "recovery_state": [
        {
            "name": "Started/Primary/Peering/GetInfo",
            "enter_time": "2020-07-20 00:22:22.401842",
            "requested_info_from": [
                {
                    "osd": "23"
                }
            ]
        },
        {
            "name": "Started/Primary/Peering",
            "enter_time": "2020-07-20 00:22:22.401834",
            "past_intervals": [
                {
                    "first": "2032",
                    "last": "2109",
                    "all_participants": [
                        {
                            "osd": 23
                        },
                        {
                            "osd": 29
                        },
                        {
                            "osd": 38
                        },
                        {
                            "osd": 44
                        }
                    ],
                    "intervals": [
                        {
                            "first": "2032",
                            "last": "2076",
                            "acting": "29,38,44"
                        },
                        {
                            "first": "2077",
                            "last": "2109",
                            "acting": "23,29,44"
                        }
                    ]
                }
            ],
            "probing_osds": [
                "23",
                "29",
                "38",
                "44"
            ],
            "down_osds_we_would_probe": [],
            "peering_blocked_by": []
        },
        {
            "name": "Started",
            "enter_time": "2020-07-20 00:22:22.401775"
        }
    ],
    "agent_state": {}
}

recovery_state 告诉我们 blocked 原因是 ceph-osd daemons，尤其是 osd.23. 正常情况，我们重启 osd.23 等待恢复就行。如果 osd.23 出现重大问题，我们可以告诉集群 osd.23 lost 并做好准备

下面操作需要谨慎

指导 ceph 继续，会导致数据丢失，多备份的话就没多少问题。

ceph osd out 23
ceph osd lost 23

unfound object

在某些综合 failures 状态下，ceph 会报 unfound warn

ceph health detail

查看哪些 osd 被探测或者包含这些数据

ceph pg xx query

如果已经查询了所有可能的位置并且仍然丢失了对象，则可能必须放弃丢失的对象。要将“未找到”的对象标记为“丢失”

ceph osd force-create-pg xx

查看该 pg 对哪些 pool 有影响

[root@k8sGUPMaster01 ~]# ceph pg ls-by-pool myfs-metadata | grep 8.15
8.15       2        0         0       0    90           0          0   5      peering   73m   468'5    2166:1780 [44,29,38]p44 [44,29,38]p44 2020-07-25 00:32:14.447205 2020-07-25 00:32:14.447205