喜迎
元旦
修复一个纸糊的集群 | 奋斗的松鼠 - Blog

修复一个纸糊的集群

字数统计: 1.6k字   |   阅读时长≈ 7分

这个集群真的问题多多，很拉跨

写在前面

松鼠哥的ceph专业课程上线啦！
面向新手同学，从0实战，全面入门ceph安装部署与运维，有需要的同学赶紧扫码订购吧：

目前我们生产环境大大小小的集群接近150个，而人手又不多，运维起来真的是一言难尽。这不，今天就记录(吐槽)其中一个集群，该集群非常突出，坏盘率/坏机率稳居所有集群之首，我想，这大概就是有毒吧。。。

背景

该集群硬件性能之差令人发指，平均一周坏几十个盘，要么隔三岔五机器挂掉，原因多种多样，什么内存坏了啊，什么网卡down了啊，cpu报错啊，奇葩不已，今天居然还发生一个数据损坏的事。。

集群使用了EC 12+4，故障域是host，理论上，只要不超过4台机器的盘在没有恢复完成数据之前都挂掉，是不会有数据损坏风险的，但是，它恰恰就是发生了这种事情

当一个osd的磁盘损坏后，我们将该osd处理成destroyed，然后记录坏盘情况，此时这个osd上的数据就要恢复到其他osd上，在恢复过程中，该osd所在的pool又以极快的速度再坏掉3块磁盘，也就是这个pool产生了m个坏盘，默认情况下就会出现pg卡住，此时要将pool的min_size修改为k(默认情况下的k被设置为k+1)，此时数据依然可以正常恢复，但是。。。如果第一块坏掉的osd的数据还没恢复完，又坏掉一块。。。这种情况就是坏掉>m份数据的情况，接下来就要处理这种故障-.-

处理

看下pg状态，感受一下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
[twj@cluster-mon1 ~]$ sudo ceph -s
  cluster:
    id:     xxxxxxxx-d44a-43ab-af2b-xxxxxxxxxxxx
    health: HEALTH_ERR
            noout,noscrub,nodeep-scrub flag(s) set
            36887093/16739168963 objects misplaced (0.220%)
            Reduced data availability: 440 pgs inactive, 1 pg down, 428 pgs peering, 1 pg incomplete
            Degraded data redundancy: 133429126/16739168963 objects degraded (0.797%), 10069 pgs degraded, 10140 pgs undersized
            Degraded data redundancy (low space): 52 pgs backfill_toofull
 
  services:
    mon: 3 daemons, quorum cluster-mon1,cluster-mon2,cluster-mon3
    mgr: cluster-mon2(active), standbys: cluster-mon1, cluster-mon3
    osd: 2178 osds: 2128 up, 2128 in; 10572 remapped pgs
         flags noout,noscrub,nodeep-scrub
    rgw: 19 daemons active
 
  data:
    pools:   10 pools, 34056 pgs
    objects: 1.05 G objects, 3.2 PiB
    usage:   4.7 PiB used, 11 PiB / 15 PiB avail
    pgs:     1.292% pgs not active
             133429126/16739168963 objects degraded (0.797%)
             36887093/16739168963 objects misplaced (0.220%)
             23197 active+clean
             6319  active+recovery_wait+undersized+degraded+remapped
             3406  active+undersized+degraded+remapped+backfill_wait
             290   active+undersized+degraded+remapped+backfilling
             278   peering
             275   active+remapped+backfill_wait
             149   remapped+peering
             69    active+undersized+remapped+backfill_wait
             43    active+undersized+degraded+remapped+backfill_wait+backfill_toofull
             9     active+remapped+backfill_wait+backfill_toofull
             5     activating+undersized+degraded+remapped
             4     active+recovering+undersized+degraded+remapped
             2     activating+undersized+degraded
             2     activating
             2     active+remapped+backfilling
             2     active+undersized+remapped+backfilling
             1     activating+remapped
             2     remapped+incomplete
             1     down
 
  io:
    client:   1.1 GiB/s rd, 7.3 GiB/s wr, 9.50 kop/s rd, 10.64 kop/s wr
    recovery: 3.6 GiB/s, 1.15 kobjects/s

光是inactive的pg就有440个，贼刺激，此时已经有两个pg进入remapped+incomplete状态，也就是有数据丢失风险的2个pg

注意到这个集群一共2178个osd，目前2128个in和up，那么另外那50个去哪了？能猜到吗？
对头对头！坏掉了，最近一两周坏掉的哦

这磁盘纸糊的一样有木有！

query一下其中的remapped+incomplete的pg，发现是这样的

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
[twj@cluster-mon1 ~]$ sudo ceph pg 13.1fb7 query
{
    "state": "remapped+incomplete",
    "snap_trimq": "[]",
    "snap_trimq_len": 0,
    "epoch": 519426,
    "up": [
        2112,
        1833,
        1697,
        1941,
        1761,
        1896,
        2055,
        1866,
        2135,
        2025,
        1729,
        1644,
        1809,
        1993,
        1653,
        1966
    ],
    "acting": [
        2147483647,
        1833,
        1697,
        2147483647,
        1761,
        1896,
        2055,
        1866,
        2135,
        2025,
        2147483647,
        1644,
        1809,
        1993,
        2147483647,
        2147483647
    ],
    ......
    "recovery_state": [
        {
            "name": "Started/Primary/Peering/Incomplete",
            "enter_time": "2022-01-19 16:19:09.453481",
            "comment": "not enough complete instances of this PG"
        },
    ],
    "agent_state": {}
}

查了一圈，有说丢失数据没关系就直接强制重建pg的

1
sudo ceph osd force-create-pg 13.1fb7 --yes-i-really-mean-it

但是并没有什么用，依旧卡住，猜测是该pg存在的副本还有11个，就一直卡在了无法请求足够副本的地方

思路上，我们还可以用硬核一点的方法，此前的文章也有提到过，就是到该pg所在的所有up的osd上，将其删掉，osd起来后发现没有了该副本，也就可以重新创建pg了

首先，查询一下该pg涉及的所有 osd

1
2
[twj@cluster-mon1 ~]$ sudo ceph pg map 13.1fb7
osdmap e540550 pg 13.1fb7 (13.1fb7) -> up [2112,1833,1697,1941,1761,1896,2055,1866,2135,2025,1729,1644,1809,1993,1653,1966] acting [2147483647,1833,1697,2147483647,1761,1896,2055,1866,2135,2025,2147483647,1644,1809,1993,2147483647,2147483647]

然后，依次到对应的机器，将osd进程down掉，然后使用ceph-objectstore-tool将其从bluestore 删掉，这里遇到一个现象，就是删掉后立刻启动osd，删掉的pg还会回来，不知道为什么。。所以删掉后不要着急起osd，等一会一起启动即可

1
2
3
4
5
6
[twj@osd-node-62 ~]$ sudo systemctl stop ceph-osd@1833.service
[twj@osd-node-62 ~]$ sudo ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-1833/ --type bluestore --pgid 13.1fb7s1 --op remove --force
 marking collection for removal
setting '_remove' omap key
finish_remove_pgs 13.1fb7s1_head removing 13.1fb7s1
Remove successful

如果删除pg的时候提示PG '13.1fb7s0' not found也不要慌，说明它就是没有，不用管它

1
2
[twj@cluster-mon1 ~]$ sudo ceph pg map 13.1fb7
osdmap e540657 pg 13.1fb7 (13.1fb7) -> up [2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647] acting [2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647]

所有osd都起来后，pg信息重新刷新，过了一会这个pg就active+clean了

1
2
3
[twj@osd-node-62 ~]$ sudo ceph pg dump|grep  13.1fb7
dumped all
13.1fb7     294                  0        0         0       0    944858059  531      531                                                       active+clean 2022-01-21 11:39:05.750869       540816'531        540819:580 [2112,1833,1697,1941,1761,1896,2055,1866,2135,2025,1729,1644,1809,1993,1653,1966]       2112 [2112,1833,1697,1941,1761,1896,2055,1866,2135,2025,1729,1644,1809,1993,1653,1966]           2112             0'0 2022-01-19 17:42:36.400161             0'0 2022-01-19 17:42:36.400161

完美！

另外一个pg也如法炮制，问题解决

总结

累，心累，这个集群的坏盘记录还在增加，集群上线后没有一天的状态是HEALTH_OK的，硬件跟纸糊的一样，关键是，一期集群上线这样，二期还是这样，三期，还是这样，严重怀疑机房经常性震动、漏水、电源不稳定。没办法，已经要求机房、集成协助调查此环境，如果有类似情况的读者朋友，也希望可以分享原因和解决方案

赏

谢谢你请我吃糖果

支付宝
微信
  • 本文作者： 奋斗的松鼠
  • 本文链接： http://www.strugglesquirrel.com/2022/07/06/修复一个纸糊的集群/
  • 版权声明： 本博客所有文章除特别声明外，创作版权均为作者个人所有，未经允许禁止转载！

扫一扫，分享到微信

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级别。