读者老铁遇到的生产问题
写在前面
松鼠哥的ceph专业课程上线啦！
面向新手同学，从0实战，全面入门ceph安装部署与运维，有需要的同学赶紧扫码订购吧：
服务器掉电对存储来说是非常严重的事故，尽管在机制上，存储集群本身会针对这种突发情况有准备，例如osd的wal及pglog，大部分场景下仍能保持数据的完整性，但是总会有意外。
关于机房掉电，松鼠哥处理过多次。这个问题也是空余时间帮看了一下，本篇介绍的情况，是社区QQ群一位老铁的环境，他们机房因为其他搞人搬迁导致自己公司的机器掉电=.=，后来重新上电后少量pg有问题，问题比较罕见，处理起来不容易(这真的是锅从天上来..)。
开始
首先，该环境的表象是，集群机器重新上电后，提示有pg的不一致，即inconsistent，存储池是3副本：
1 | [ root@mon01 ~]# ceph health detail |
一般来说，pg的inconsistent不是太致命，松鼠哥也有类似的文章讨论如何处理这种pg，但该环境无法通过正常的repair进行修复，由于负责该集群的老铁对ceph也不是很熟悉，尝试了几种方案后，仍不能解决。
过了一段时间，老铁又报，由于不能解决pg的inconsistent的问题，于是他将osd.10重启了(也就是inconsistent的pg所在的主osd)，然后osd.29和osd.40就挂了，从这开始，三个osd不能同时在线，轮流重启轮流挂，集群使用的是rbd，多个副本的osd反复挂掉导致pg down，有pg处于down状态意味着很多虚拟机会卡死，问题比较严重。
经过调查，3个osd挂掉的原因，都在同一个位置，现象是osd启动过程中反复重启，具体就是断言挂掉：
1 | -10001> 2024-08-21 09:36:32.021 7fa3b6176700 1 -- 172.20.2.18:6804/5802 --> 172.20.2.23:0/2444346583 -- osd_op_reply(4846807 rbd_data.e5c477389900d3.0000000000004a20 [write 708608~4096] v87902'67607321 uv67607321 ondisk = 0) v8 -- 0x560e55b2e840 con 0 |
三个osd都是挂在get_clone_bytes，网上说有时候是scrub发现问题挂掉，有时候是上面这种，在backfill和recover流程中挂掉，总之现象类似，反复重启，但是关闭backfill和recover就不会挂，即ceph osd set norecover和ceph osd set nobackfill就让osd不会down，但是pg状态是inconsistent的，而且一旦打开recover和backfill，osd立马挂掉，出于数据可靠性考虑，集群可不能一直关闭backfill和recover，而且inconsistent不是合理的状态，所以这个问题还是要处理。
查了一圈，从资料来看，这是ceph的罕见bug(参考社区的issue：RADOS：Bug #56764,Bug #56772)，而且这bug状态目前还是NEW，一直没有修复，出现的概率倒是很小，看大家的讨论几乎都是用ceph-objectstore-tool进行整个pg的导入导出，或者是osd out完成pg的迁移来修复，但是这个环境3个osd都报这个问题，没办法简单地通过这种导入导出pg的方式来操作修复(实际上一开始是采用这种import和export的方式来处理的，但是没办法解决)。
它是在backfill和recover过程中某些快照数据丢失导致的，也许就是因为断电导致的数据损坏，pg在scrub后发现了不一致，最终数据没办法达成一致。
处理之前，需要明确的是，受影响的rbd块，对应的快照数据会丢失，因为本身快照数据就出错了，不一致了，没办法修复，所以要有丢失快照的准备，对集群的rbd进行逐个调查，发现这些rbd都是给openstack的kvm做虚拟盘，而且快照都是2021年前后打的，基本上没什么用了，可以处理掉。
处理的方式为：
1 | 1、首先获取pg包含的所有object列表 |
这里是对pg的所有snap进行处理，实际处理的时候，如果想要尽可能保存快照数据，应该是哪个rbd_data块报错就处理哪个，不是所有的都处理。
完成后，对指定的pg做scrub，为了让这个Pg能够立刻得到scrub资源并开始做清洗，应该先停掉当前集群的scrub：
1 | ceph osd set noscrub |
此时集群的状态发生了变化：
1 | data: |
虽然还是inconsistent且有snaptrim_error，但它好歹是active+clean的，说明数据大体上没问题，接下来要处理snaptrim和inconsistent的问题，发现经过scrub，osd的日志会报一堆的错，内容为：
1 | 2024-08-23 06:39:37.186 7fa476a0f700 -1 log_channel(cluster) log [ERR] : repair 10.276 10:6e4a5b8f:::rbd_data.02741d3602832c.0000000000002460:c3 : is an unexpected clone |
这是因为pg对应的数据对象的clone信息被清理了，但是实际上clone对象仍然存在，接下来根据rbd_data.xxx定位出是哪个rbd报错的：
1 | rbd info xxx |
其中rbd_data.02741d3602832c.0000000000002460:c3冒号后面的c3是十六进制，它表示snapid，定位到snap后，删掉该snap就可以了：
1 | rbd snap remove rbdname@snapname |
从实际操作来看，即便删除掉快照，仍可能有object报上述的unexpected clone，应该还需要进一步处理，em….松鼠哥对快照还是不够熟悉，而且环境中rbd的使用还算复杂，不但早早地打快照并使用了几年，还基于快照做了很多的克隆，说不定克隆后还再次克隆，且接手的人换了，连最早为啥克隆都搞不清楚，这产生了更复杂的使用场景。
最后没办法了，老铁两手一摊，我***，环境先不管，虚拟机还都跑得好好的，让它跑吧，反正集群现在没有太大问题。。(相信很多老铁也曾被故障搞破防)
这下松鼠哥没现场了=.=
好吧，说下接下来松鼠哥觉得可以做的操作：
1 | 既然集群搞快照对象麻烦，那么可以考虑创建全新的rbd，搞同样的大小，map进去kvm中，在kvm内对磁盘进行全拷贝，比如使用dd |
如果其他老铁有更好的方案，也欢迎提出~
总结
rbd的快照是Ceph基于Copy-On-Write的机制实现，而这个环境又基于快照进行了克隆，又碰上了掉电，说实话场景还是挺复杂了，松鼠哥对rbd在各种场景的使用和故障处理还是缺乏一些处理手法，在集群侧能做的pg修复和osd处理已经拉满，同时希望各位老铁可以推荐一些rbd场景的故障内容大家相互学习~
- 本文作者： 奋斗的松鼠
- 本文链接： http://www.strugglesquirrel.com/2024/09/06/一次掉电引发的rbd快照数据丢失问题/
- 版权声明： 本博客所有文章除特别声明外，创作版权均为作者个人所有，未经允许禁止转载！