喜迎
元旦
处理一个unkonwn的PG | 奋斗的松鼠 - Blog

处理一个unkonwn的PG

字数统计: 2.1k字   |   阅读时长≈ 9分

写在前面

有些日志没更新了，原因比较多，后续也还是会努力更新…

本次是处理一个测试集群的unknown的PG问题，总体来说算基本操作，不是很复杂，重在思路

问题

首先是集群发现有一个pg进入了unknown状态：

1
2
3
4
5
6
7
8
9
10
data:
  pools:   11 pools, 42592 pgs
  objects: 530.00k objects, 890 GiB
  usage:   205 TiB used, 31 PiB / 31 PiB avail
  pgs:     0.002% pgs unknown
           42591 active+clean
           1     unknown

io:
  client:   2.7 MiB/s rd, 838 B/s wr, 2.77k op/s rd, 1.85k op/s wr

这里有个细节，其实一开始pg并不是unknown状态的，而是stale状态的，但是经过排查，松鼠哥发现mgr服务貌似有问题，像是卡住的状态，于是重启了一下mgr服务，pg就立刻进入unknown状态了，实际上这两个状态都很糟糕。

查一下osd的状态，发现是大量的osd挂掉了，三副本的pool有3个及以上的不同host的osd发生down，出问题几乎是必然的

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
[test1mon-1 user1]$ sudo ceph osd tree down
ID   CLASS WEIGHT    TYPE NAME               STATUS REWEIGHT PRI-AFF 
  -1       180.00000 root default                                    
  -5        12.00000     host mon-1                         
2160   ssd   1.00000         osd.2160          down        0 1.00000 
2166   ssd   1.00000         osd.2166          down        0 1.00000 
2171   ssd   1.00000         osd.2171          down        0 1.00000 
 -12        12.00000     host mon-2                         
2173   ssd   1.00000         osd.2173          down        0 1.00000 
2175   ssd   1.00000         osd.2175          down        0 1.00000 
2179   ssd   1.00000         osd.2179          down        0 1.00000 
2180   ssd   1.00000         osd.2180          down        0 1.00000 
2182   ssd   1.00000         osd.2182          down        0 1.00000 
2183   ssd   1.00000         osd.2183          down        0 1.00000 
  -4        12.00000     host mon-3                         
2185   ssd   1.00000         osd.2185          down        0 1.00000 
2187   ssd   1.00000         osd.2187          down        0 1.00000 
2188   ssd   1.00000         osd.2188          down        0 1.00000 
2190   ssd   1.00000         osd.2190          down        0 1.00000 
2192   ssd   1.00000         osd.2192          down        0 1.00000 
2193   ssd   1.00000         osd.2193          down        0 1.00000

注意到，这些down状态的osd都是out的，也就是REWEIGHT都为0，这种情况下，只有1个pg是unknown已是万幸，应该是osd发生down的事件连续发生，而该pg还没有来得及完整地backfill到其他osd上，其所有副本就都down了，尝试了一下拉起那些osd，有点麻烦，拉不起来。

初步看一下这个pg的map

1
2
[test1mon-1 user1]$ sudo ceph pg map 7.6ec
osdmap e290651 pg 7.6ec (7.6ec) -> up [2174,2191,2332] acting [2174,2191,2332]

发现2174,2191,2332这三个osd都是up的，但是他们上面都没有7.6ec这个pg，而且使用ceph pg 7.6ec query命令居然报错，说没有这个pg，上面的猜想看来是对的，该pg的三个副本都没有完成backfill就down了。

那么基于这个原因，我们能想到的处理方案就很直接了：从这个pg原来的osd中导出pg数据，再导入现在的pg的主osd中(2174)来恢复数据

问题的处理

要从pg的原来的osd中导出它的整个pg数据，首先要知道它原来在哪些osd上，这有几种思路：

  • 从所有down的osd中，使用ceph-objectstore-tool工具，去逐个找，看看哪个osd中存放了这个pg
  • 定位到故障前的某个osdmap版本，从该osdmap中找出当时的pg映射集合，找出目标osd

松鼠哥不用蛮力，用第二种方法。

首先是要找到osdmap的版本，初步想了一下，有2种方案：

  • 1、使用目标pg的前后一个pg，查看它们的详细信息，定位版本
  • 2、从osd中探查osdmap的早期版本

第1种想法是基于故障发生的时间戳，我们可以找一个pg，跟目标pg 7.6ec是相邻的，那么我们可以认为，该pg与目标pg 7.6ec发生故障的时间应该是一样的，于是，如果我们基于这个pg的最后clean时间，理论上就能够知道，目标pg7.6ec最后一次clean状态的osdmap版本，从而达到我们的目的。

这里松鼠哥选择 7.6ed，探查一下它的pg clean版本

1
2
3
4
5
6
7
[test1mon-1 user1]$ sudo ceph pg 7.6ed query|grep last_epoch_clean
            "last_epoch_clean": 290211,
            "last_epoch_clean": 290211,
                "last_epoch_clean": 290211,
                "last_epoch_clean": 290207,
                "last_epoch_clean": 290211,
                "last_epoch_clean": 288951,

这里可以看到最小的osdmpa版本是288951，那么这就是我们要的版本吗？实际处理发现，并不是，在该版本中，7.6ec已经发生了remap，不是我们要的版本。

于是松鼠哥继续采取第2种想法，从osd种探查osdmap的更早的版本。

这里选择了osd.2160，这个是随机选择的，它的原理是，在pg全面进入active+clean状态之后，osd才会对本地的osdmap进行裁剪，这是为了让osd能够使用osdmap进行集群事件的回溯，于是我们在osd.2160种进行查找。

首先需要导出osd的rocksdb

1
ceph-bluestore-tool bluefs-export --path /var/lib/ceph/osd/ceph-2160 --out-dir /ceph-2160

然后，在该rocksdb中选择osdmap

1
2
3
4
5
6
[test1mon-1 user1]$ ceph-kvstore-tool rocksdb /ceph-2160/db/ list O|grep osdmap > osdmaps
[rootmon-1 db]# more osdmaps 
O	%7f%7f%ff%ff%ff%ff%ff%ff%ff%20%00%25%83%21osdmap.287881%21%3d%00%00%00%00%00%00%00%00%ff%ff%ff%ff%ff%ff%ff%ffo
O	%7f%7f%ff%ff%ff%ff%ff%ff%ff%20%00%25%83%21osdmap.287881%21%3d%00%00%00%00%00%00%00%00%ff%ff%ff%ff%ff%ff%ff%ffo%00%00%00%00x
O	%7f%7f%ff%ff%ff%ff%ff%ff%ff%20%00%25%83%21osdmap.287881%21%3d%00%00%00%00%00%00%00%00%ff%ff%ff%ff%ff%ff%ff%ffo%00%06%00%00x
O	%7f%7f%ff%ff%ff%ff%ff%ff%ff%20%00%25%83%21osdmap.287881%21%3d%00%00%00%00%00%00%00%00%ff%ff%ff%ff%ff%ff%ff%ffo%00%0c%00%00x

这里使用grep和awk处理后，发现osd.2160本地存储的最早期的osdmap版本就是287881，于是我们可以从集群得到这个版本的osdmap，从而实现pg的映射查找

1
2
3
4
5
[test1mon-1 user1]$ ceph osd getmap 287881 -o osdmap.287881
[test1mon-1 user1]$ sudo osdmaptool osdmap.287881 --test-map-pg 7.6ec
osdmaptool: osdmap file 'osdmap.287881'
 parsed '7.6ec' -> 7.6ec
7.6ec raw ([2252,2233,2308], p2252) up ([2233,2308], p2233) acting ([2233,2308], p2233)

好的，得到了[2252,2233,2308]，这就够了，现在可以去osd.2233上导出pg了

1
2
3
4
5
6
7
8
[root@mon-3 user1]# ceph-objecttest1-tool --data-path /var/lib/ceph/osd/ceph-2233/ --op list-pgs|grep 7.6ec
7.6ec
[root@mon-3 user1]# ceph-objecttest1-tool --data-path /var/lib/ceph/osd/ceph-2233/ --pgid 7.6ec --op export --file 7.6ec.pg
Exporting 7.6ec info 7.6ec( v 280324'962028 (280324'961503,280324'962028] local-lis/les=287895/287896 n=1 ec=2657/2612 lis/c 287895/287828 les/c/f 287896/287829/0 287967/287967/287967)
Read #7:37644942:::.dir.1f49e675-e820-4e36-b332-b8f2938cb451.74994546.1.14:head#
Export successful
[root@mon-3 user1]# ls -l 7.6ec.pg 
-rw-r----- 1 root root 3351940 Jun  8 11:34 7.6ec.pg

导出没问题，看大小也是挺正常的，接下来根据现在最新的pg映射将pg导入，因为3副本min_size设置为1，因此导一个osd就够了，

1
2
3
4
5
6
7
8
9
10
11
[test1mon-1 user1]$ sudo ceph pg map 7.6ec
osdmap e290651 pg 7.6ec (7.6ec) -> up [2174,2191,2332] acting [2174,2191,2332]
[root@mon-2 user1]# sudo systemctl stop ceph-osd@2174.service
[root@mon-2 user1]# sudo ceph-objecttest1-tool --data-path /var/lib/ceph/osd/ceph-2174/ --pgid 7.6ec.pg --op import --file ./7.6ec.pg 
get_pg_num_history pg_num_history pg_num_history(e290651 pg_nums {5={2609=32},6={2687=8192},7={2751=8192},8={2613=512},9={2614=512},10={2615=512},11={2771=8192},12={2765=8192},13={2789=8192},14={3279=32},15={31723=32}} deleted_pools )
Importing pgid 7.6ec
Write #7:37644942:::.dir.1f49e675-e820-4e36-b332-b8f2938cb451.74994546.1.14:head#
snapset 0=[]:{}
write_pg epoch 287968 info 7.6ec( v 280324'962028 (280324'961503,280324'962028] local-lis/les=287895/287896 n=1 ec=2657/2612 lis/c 287895/287828 les/c/f 287896/287829/0 287967/287967/287967)
Import successful
[test1mon-1 user1]$ sudo ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-2174/ --pgid 7.6ec --op mark-complete

这就完成了，拉起osd.2174，过一会pg就都正常了

1
2
3
4
5
6
7
8
data:
  pools:   11 pools, 42592 pgs
  objects: 530.00k objects, 890 GiB
  usage:   205 TiB used, 31 PiB / 31 PiB avail
  pgs:     42592 active+clean

io:
  client:   10.4 MiB/s rd, 980 B/s wr, 3.99k op/s rd, 3.85k op/s wr

总结

本次故障并不复杂，大多数是基本操作，主要是思路，用蛮力去查找所有osd，找出目标pg进行导出，也是一个有效方案，本次松鼠哥使用历史osdmap导出，并在该版本上使用pg map找到目标osd，是一个比较有意思的视角，实际上，我们可以从中举一反三，只要是需要定位故障时间戳、集群版本号的，都可以使用该思路

赏

谢谢你请我吃糖果

支付宝
微信
  • 本文作者： 奋斗的松鼠
  • 本文链接： http://www.strugglesquirrel.com/2026/09/29/处理一个unkonwn的PG/
  • 版权声明： 本博客所有文章除特别声明外，创作版权均为作者个人所有，未经允许禁止转载！

扫一扫，分享到微信

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia-plus根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

松鼠哥，存储研发专家
曾就职于深信服北京研发中心，负责存储相关产品的调研测试
在分布式存储领域深耕近十年，实战经验和理论经验功力深厚
累计管理及上线生产集群超过600个，机器超3万台，磁盘总数超过80万块，总容量达到EB级别。