喜迎
元旦
当三副本池挂了4个osd | 奋斗的松鼠 - Blog

当三副本池挂了4个osd

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

ceph出现数据问题的场景不多

介绍

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

是的，故障域为host，当一个3副本池，连续有3个不同host的osd坏掉，未来得及迁移完成的pg就会出问题，经常关注松鼠哥博客、公众号的老铁，对这种故障的处理应该说很熟悉，属于基操了~

本篇松鼠哥在测试环境14版本又遇到这种场景，顺手写一下，基操就基操了，谨防有新手同学搞不清楚。

开始

一个压测的测试集群验证某些问题，使用对象存储，环境告警提示有osd又down了，这次不一般，挂掉的osd达到了4个，如果pg来不及完成backfill，那么必然会有数据风险：

1
2
3
4
5
6
7
8
9
10
[root@testcluster twj]# ceph osd tree down
-555       116.00000 root default                                    
 -47        12.00000     host testcluster-1                            
 519   hdd   1.00000         osd.519              down        0 1.00000 
 -40        12.00000     host testcluster-2                            
 559   hdd   1.00000         osd.559              down        0 1.00000 
 -48        12.00000     host testcluster-3                            
 571   hdd   1.00000         osd.571              down        0 1.00000 
 -62        12.00000     host testcluster-4                            
 610   hdd   1.00000         osd.610              down        0 1.00000

这种情况下，3副本的存储池必然是有pg异常，稍微看了一下只有一个pg为down状态，是12.4ea，用ceph pg 12.4ea query看下具体情况：

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
......
        "probing_osds": [
            "490",
            "532",
            "638"
        ],
        "blocked": "peering is blocked due to down osds",
        "down_osds_we_would_probe": [
            519,
            559,
            610
        ],
        "peering_blocked_by": [
            {
                "osd": 610,
                "current_lost_at": 0,
                "comment": "starting or marking this osd lost may let us proceed"
            }
        ]
    },
    {
        "name": "Started",
        "enter_time": "2024-07-23 01:14:17.542611"
    }
],
"agent_state": {}
}

看起来暂时卡在了osd.610，osd.610因为磁盘故障，持续震荡，无法正常拉起，ceph无法完成peer，所以pg也没办法处理后续，所以首先根据提示将osd.610标记为lost：

1
[root@testcluster twj]# ceph osd lost 610 --yes-i-really-mean-it

但是这个处理并不能让pg恢复正常，因为12.4ea所在的3个osd都已经down掉了拉不起来，所以思路上，就要从这3个已经down掉的osd磁盘中将这个pg导出来，然后重新导入到新的pg map所指向的osd中，这里，就是将12.4ea导出，然后导入osd.490，由于存储池的min_size当前为1，所以理论上导入osd.490即可，首先从519导出看看：

1
ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-519/ --bluestore --op export --pgid 12.4ea --file 12.4ea1

导出过程发现，在没有完全导出的情况下，报错了：

1
2
......
export_files error -5

查一下报错码，发现是io错误，em…因为磁盘是hdd盘，坏道多到osd都拉不起来了，所以有io错误也正常，重试了几次，发现后面几次导出来的内容大小一致，这就说明在某个地方，ceph-objectstore-tool确实读不到了：

1
2
3
4
5
6
[root@testcluster-1 twj]$ ll
total 342752
-rw-r----- 1 root root 73391856 Jul 22 23:39 12.4ea1
-rw-r----- 1 root root 92525937 Jul 22 23:40 12.4ea2
-rw-r----- 1 root root 92525937 Jul 22 23:44 12.4ea3
-rw-r----- 1 root root 92525937 Jul 22 23:45 12.4ea4

考虑到这个盘应该是读不到多少数据了，所以想办法去另外2个盘试下，发现读出的数据量也有差异

1
2
3
4
5
6
7
8
9
[root@testcluster-2 twj]$ ll
total 14900360
-rw-r----- 1 root  root 10996611711 Jul 23 00:09 12.4ea5
-rw-r----- 1 root  root   4261352251 Jul 23 00:18 12.4ea6
[root@testcluster-3 twj]$ ll
total 31587432
-rw-r----- 1 root root 15844530489 Jul 23 00:51 12.4ea7
-rw-r----- 1 root  root    617895434 Jul 23 00:59 12.4ea8
-rw-r----- 1 root  root  15844530489 Jul 23 01:20 12.4ea9

即便是15GiB左右的导出数据量，也是以报错结束，这就是说，数据的导出是不完整的，这意味着很多数据的丢失。

有没有办法能够尽可能读出所有数据呢？

数据读出不完整的问题，主要是ceph-objectstore-tool在读取过程中遇到了错误，直接退出了，后续的内容就不再读取，这个做法是有点问题的，假设一个Pg的数据量有10GiB，如果因为在2GiB附近出现io错误无法读出，就不再读取后面的8GiB数据，那么后面8GiB是要被放弃掉吗？显然是不行的，因此能够想到的思路有：

  • 遇到io错误的对象，跳过，不要那个对象了，继续读取后面的对象，而不是直接退出，允许极少数据丢失。
  • 遇到io错误的对象，填充错误部分，允许小部分数据丢失。
  • 遇到io错误的对象，就是要自行车，想100%不丢数据，3副本挂4个osd，还是介质错误，还想100%不丢，只有将所有的副本都使用上面的2个方法导出来，对比差异，赌它3个副本不会坏在同一个地方，这个思路难度大而且很复杂，除非那部分数据价值千金，非要不可，否则，emmm，就是很费人。

通过参考更高版本的ceph代码，发现ceph用的是第二个思路，就是填充。

第一种跳过错误的对象虽然思路上行得通，但是实践起来比较麻烦，因为要回滚已经读出来的元数据，但是这部分数据已经写了，要回滚很麻烦，新版本的填充处理关键位置是：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
file:ceph_objectstore_tool.cc      
      const size_t block_size = 4096;
      while(o < offset + len) {
        bufferlist bl;
        int r = store->read(ch, obj, o, block_size, bl);
        if (r <= 0) {
          rawdatabl.append_zero(block_size);
          cerr << "read failure: " << cpp_strerror(r == 0 ? -EINVAL : r)
               << " at obj:" << obj << std::hex
               << ", read 0x" << o << "~" << block_size
               << std::dec << std::endl;
        } else {
          rawdatabl.claim_append(bl);
        }
        o += block_size;
      }
      ret = len;
    }

它的想法是，以4k为单位，如果读失败，那么就将这4k填充，将影响降至最小。

使用这个代码得自行重编一下ceph-objectstore-tool，较简单，这里就不展开了。

使用这个办法重新导出pg的效果怎么样呢？还是比较明显的，导出的最终结果也是Export successful：

1
2
3
4
[root@testcluster-3 bin]$ ll
total 29070136
-rw-r----- 1 root root 29720785585 Jul 23 12:49 12.4ea8
-rwxr-x--- 1 root root    18126640 Jul 23 11:51 ceph-objectstore-tool

可见本次导出的有效数据比之前导出的多很多，用这个28GiB多的pg进行导入，然后重新拉起osd，Pg的状态从down转变到incomplete：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
pgs:     0.001% pgs not active
         64230729/32972877024 objects degraded (0.195%)
         33628628/32972877024 objects misplaced (0.102%)
         133273 active+clean
         270    active+undersized+degraded+remapped+backfill_wait
         203    active+recovery_wait+degraded
         155    active+remapped+backfill_wait
         101    active+undersized+degraded+remapped+backfilling
         37     active+remapped+backfilling
         3      active+recovery_wait+degraded+remapped
         2      active+remapped+backfill_wait+backfill_toofull
         2      active+recovery_wait+undersized+degraded+remapped
         1      incomplete
         1      active+undersized+degraded+remapped+backfill_wait+backfill_toofull

好歹osd起来了，pg的数据也重新识别到了，incomplete状态不是太大的麻烦，手工mark一下就好，这还是基操：

1
2
3
4
5
[root@testcluster-3 bin]# systemctl stop ceph-osd@490
[root@testcluster-3 bin]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-490/ --op mark-complete --pgid 12.4ea 
Marking complete 
Marking complete succeeded
[root@testcluster-3 bin]# systemctl start ceph-osd@490

等了一会，osd正常起来，就自动backfill了，最终回到了active+clean的状态。

总结

在规划和部署合理、监控到位的情况下，ceph稳如老狗，数据丢失的场景并不多，从业界使用情况来看，会导致数据丢失的情况主要有以下几种：

  • 掉电导致服务器瞬间挂掉，这种情况下难免会使磁盘产生错误，损坏数据，或者raid卡数据没有及时刷盘，丢失这部分缓存数据，这种情况会有少量数据找不回，甚至影响osd拉起。
  • 连续的坏盘使冗余策略失败，就像本篇的场景，这种情况丢失的数据可能会比较多，能找回多少要看手段了。
  • 静默错误且未开scrub，不常见，但是吧，你就说可不可能吧。
  • 误删，不多说，只要是个人，都有可能误操作，只能靠规范和流程尽可能规避。

最后，精品制作不易，如果本篇对你有启发和帮助，可以顺手赏松鼠哥一杯咖啡，多谢~

赏

谢谢你请我吃糖果

支付宝
微信
  • 本文作者： 奋斗的松鼠
  • 本文链接： http://www.strugglesquirrel.com/2024/09/06/当三副本池挂了4个osd/
  • 版权声明： 本博客所有文章除特别声明外，创作版权均为作者个人所有，未经允许禁止转载！

扫一扫，分享到微信

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