ceph运维大宝剑之拯救destroyed的osd

2024-04-16

字数统计: 2.5k字 | 阅读时长≈ 11分

本篇介绍一种特殊情况下进行osd的修复。

写在前面

一句话广告：欢迎老铁们支持松鼠哥的课程，大家的支持就是对松鼠哥最大的鼓励，创作真的不易哇~~

本篇介绍一种特殊情况下进行osd的修复，在极端情况下，如误操作导致数据风险，或者需要进行关键数据的提取，都具有很好的借鉴意义，另外，在处理过程中用到的思路和内容，都能够为大家解决其他问题提供参考。

场景

我们知道，ceph集群的osd状态有好几种，最常见的就是up/down/in/out/destroyed，其中前面4种状态，ceph集群是可以自动调整切换的，如osd进程发生故障，在超时时间后，osd在集群的状态就会变成down，当osd重新被创建时，它在集群中的状态会重新up和in，但是destroyed状态必须是人为进行操作的，在松鼠哥的课程中有提到，osd坏盘处理过程中，我们应该尽量显式地将osd设置为destroyed状态，这个操作告诉集群这个osd的数据已经永久地被毁灭了，它将会进行换盘然后重建。

而本次集群就是一种意外情况，在实际操作中，osd进程本来是好的，它的数据、磁盘、lvm等都是没有问题的，意外地被操作删除了它在集群的key和标记为destroyed，这种情况下，osd将会被逐出集群，并且osd进程也不能正常运行

[twj@test-cluster ~]# sudo ceph osd tree down
ID   CLASS WEIGHT    TYPE NAME               STATUS    REWEIGHT PRI-AFF 
-176       20.00000 root test-root-1                                   
 -48        10.00000     host host1                            
 688   hdd   1.00000         osd.688         destroyed        0 1.00000

当osd进入destroyed状态后，显式表示该osd的数据完全被毁灭，osd需要换盘后重新创建，这种状态的osd，集群仅支持两种操作，第一种操作就是重建osd，它会在osd完成prepare后进入down状态，然后在active后，osd进程拉起来进入up状态，第二种操作就是ceph osd rm，将其从集群完全清除，除此之外，osd的集群状态是不能变化的，也就是，没有其他办法能够将destroyed状态的osd变成down状态或者up状态。

如果我们的osd是被误操作的，或者，这个osd的磁盘还有继续使用的可能性(比如这个osd包含了最后一个副本，如果起不来可能会导致数据丢失)，而osd目前是destroyed状态的，有没有可能救回这个osd呢？从思路上来说有2个：

修改osdmap

松鼠哥在课程中也重点提到，osdmap是集群最重要的map，它维护集群重要的信息，其中osd的集群状态信息就保存在osdmap中，那么我们能不能将对应osd的状态从destroyed直接修改为down，再将osdmap进行注入来达到目的呢？

答案是：不行~

原因是ceph不允许外力修改osdmap的内容，它不支持，也没有可行的办法去修改集群的osdmap并进行注入，外力能够做的最大努力，应该只有松鼠哥之前做的集群osdmap的回滚，如果能够修改osdmap，我们还做什么回滚。。

这里补充一个知识点，集群的osdmap只有mon能修改，而其他任何组件不具有修改osdmap的能力，并且，其他组件无条件相信mon的osdmap，所以mon的osdmap是最权威的数据。

况且在本场景中，为了几个osd的状态变化，去回滚整个集群的osdmap，不值得，也具有很高的风险！

欺骗mon让它帮忙将osd的集群状态进行修改

既然只有mon才能修改osdmap，那么我们能不能通过某些手段，让mon将osd的destroyed状态修改为down呢？这个思路就非常奇特了，事实上是行得通的。

从前述内容可知，mon修改osd的状态只有一种方法，就是告诉集群，这个osd将要被重建，那么我们可以利用这个过程，达到修改osd状态的目的。

首先，我们在节点上创建一个10G的文件，然后将其转变为块设备，并在它上面创建lvm，为osd的创建做准备

首先生成文件，大小为10G
[twj@test-cluster ~]# dd if=/dev/zero of=/var/temposdblock bs=1M count=10240
将文件转化为块设备
[twj@test-cluster ~]# losetup /dev/loop0 /var/temposdblock 
查看，发现文件已经被设置为块设备文件
[twj@test-cluster ~]# ls -l /dev/loop0
brw-rw---- 1 root disk 7, 0 Apr  7 14:05 /dev/loop0

接下来创建vg和lv
[twj@test-cluster ~]# /usr/sbin/vgcreate --force --yes testosdblockvg /dev/loop0
Volume group "testosdblockvg" successfully created
[twj@test-cluster ~]# /usr/sbin/lvcreate --yes -l 100%FREE -n testosdblocklv testosdblockvg
  Logical volume "testosdblocklv" created.

准备完成后，我们还要查看一下目标osd的原来的osdid，因为这些信息是保存在osd的磁盘上的，如果我们指定的id不对，可能会导致osd在启动时id对不上，而无法正常启动，因此我们在进行prepare的时候，指定这个osd原来的id

1
2
3

[twj@test-cluster ~]# cd /var/lib/ceph/osd/ceph-688
[twj@test-cluster ceph-688]# cat fsid 
5ecb4e14-cbe9-4d0c-ab4c-7ec0672e6913

接下来就是prepare了，它是ceph-volume创建osd的第一步，松鼠哥的课程内有详细讲解

[twj@test-cluster ~]# /usr/sbin/ceph-volume --cluster ceph lvm prepare --bluestore --data testosdblockvg/testosdblocklv  --osd-id 688 --osd-fsid 5ecb4e14-cbe9-4d0c-ab4c-7ec0672e6913
Running command: /usr/bin/ceph-authtool --gen-print-key
Running command: /usr/bin/ceph --cluster ceph --name client.bootstrap-osd --keyring /var/lib/ceph/bootstrap-osd/ceph.keyring osd tree -f json
Running command: /usr/bin/ceph --cluster ceph --name client.bootstrap-osd --keyring /var/lib/ceph/bootstrap-osd/ceph.keyring -i - osd new 5ecb4e14-cbe9-4d0c-ab4c-7ec0672e6913 688
Running command: /usr/bin/ceph-authtool --gen-print-key
Running command: /usr/bin/mount -t tmpfs tmpfs /var/lib/ceph/osd/ceph-688
Running command: /usr/bin/chown -h ceph:ceph /dev/testosdblockvg/testosdblocklv
Running command: /usr/bin/chown -R ceph:ceph /dev/dm-90
Running command: /usr/bin/ln -s /dev/testosdblockvg/testosdblocklv /var/lib/ceph/osd/ceph-688/block
Running command: /usr/bin/ceph --cluster ceph --name client.bootstrap-osd --keyring /var/lib/ceph/bootstrap-osd/ceph.keyring mon getmap -o /var/lib/ceph/osd/ceph-688/activate.monmap
 stderr: got monmap epoch 1
Running command: /usr/bin/ceph-authtool /var/lib/ceph/osd/ceph-688/keyring --create-keyring --name osd.688 --add-key AQCaORJm3mjwGxAAEUdN5zr3GT7ueF+BebTzqA==
 stdout: creating /var/lib/ceph/osd/ceph-688/keyring
added entity osd.688 auth auth(auid = 18446744073709551615 key=AQCaORJm3mjwGxAAEUdN5zr3GT7ueF+BebTzqA== with 0 caps)
Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-688/keyring
Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-688/
Running command: /usr/bin/ceph-osd --cluster ceph --osd-objectstore bluestore --mkfs -i 688 --monmap /var/lib/ceph/osd/ceph-688/activate.monmap --keyfile - --osd-data /var/lib/ceph/osd/ceph-688/ --osd-uuid 5ecb4e14-cbe9-4d0c-ab4c-7ec0672e6913 --setuser ceph --setgroup ceph
--> ceph-volume lvm prepare successful for: testosdblockvg/testosdblocklv

如果在prepare的时候提示osd entity存在了，就用ceph auth rm osd.xx进行删除。上述操作完成后，查看osd的状态，发现已经变成了down，当然，我们并不打算对它继续创建。

[twj@test-cluster ceph-688]# sudo ceph osd tree down
ID   CLASS WEIGHT    TYPE NAME               STATUS    REWEIGHT PRI-AFF 
-176       20.00000 root test-root-1                                    
 -48        10.00000     host host1                            
 688   hdd   1.00000         osd.688              down        0 1.00000

变成down就好办了，我们可以直接修改osd的链接信息并用它原来的盘进行拉起，注意要修改权限，否则会起不来

[twj@test-cluster ceph-688]# ls -l 
total 52
-rw-r--r-- 1 ceph ceph 528 Apr  7 14:14 activate.monmap
lrwxrwxrwx 1 ceph ceph  34 Apr  7 14:14 block -> /dev/testosdblockvg/testosdblocklv
-rw-r--r-- 1 ceph ceph   2 Apr  7 14:14 bluefs
-rw-r--r-- 1 ceph ceph  37 Apr  7 14:14 ceph_fsid
[twj@test-cluster ceph-688]# rm -f block
[twj@test-cluster ceph-688]# ln -s /dev/ceph-xxx/osd-xxx block
[twj@test-cluster ceph-688]# ln -s /dev/ceph-xxx/osd-xxx.db block.db
[twj@test-cluster ceph-688]# ln -s /dev/ceph-xxx/osd-xxx.wal block.wal
[twj@test-cluster ceph-688]# ll
total 52
-rw-r--r-- 1 ceph ceph 528 Apr  7 14:14 activate.monmap
lrwxrwxrwx 1 root root  33 Apr  7 14:21 block -> /dev/ceph-xxx/osd-xxx
lrwxrwxrwx 1 root root  36 Apr  7 14:21 block.db -> /dev/ceph-xxx/osd-xxx.db
lrwxrwxrwx 1 root root  36 Apr  7 14:21 block.wal -> /dev/ceph-xxx/osd-xxx.wal
[twj@test-cluster ceph-688]# cd ..
[twj@test-cluster osd]# chown ceph.ceph ceph-688/ -R
[twj@test-cluster osd]# systemctl start ceph-osd@688.service

拉起后，看到进程能够顺利起来了~~注意到，osd的拉起过程中，有日志提示它被标记为destroyed

1
2
3

2024-04-07 14:24:40.191 7f49b977cb80  0 osd.688 140029 done with init, starting boot process
2024-04-07 14:24:40.191 7f49b977cb80  1 osd.688 140029 start_boot
2024-04-07 14:24:40.192 7f4991578700 -1 osd.688 140029 osdmap says I am destroyed

即在osdmap的版本140029中，osd.688是destroyed的，不过因为当前osdmap版本已经到了更高的版本，因此这个日志输出尽管是-1级别，但并不影响osd的启动运行。

1 2	[twj@test-cluster osd]# ceph osd dump\|more epoch 142099

在经过半个小时的启动后，osd中遇完全起来了，pg数据也正常扫描并顺利上线

[twj@test-cluster ~]# sudo ceph osd tree-from host1
ID   CLASS WEIGHT    TYPE NAME               STATUS    REWEIGHT PRI-AFF 
-176       20.00000 root test-root-1                                    
 -48        10.00000     host host1                            
 688   hdd   1.00000         osd.688           up       1.00000   1.00000
[twj@test-cluster ~]# sudo ceph osd df|grep 688
 688   hdd 1.00000  1.00000 7.4 TiB 6.1 TiB 6.0 TiB     0 B   87 GiB  1.2 TiB 83.18 1.40  62

接下来还要再把用来进行prepare的文件进行处理，主要是卸载和删除

[twj@test-cluster ~]# lvremove -y testosdblockvg/testosdblocklv
  Logical volume "testosdblocklv" successfully removed
[twj@test-cluster ~]# vgremove testosdblockvg
  Volume group "testosdblockvg" successfully removed
[twj@test-cluster ~]# pvremove /dev/loop0
  Labels on physical volume "/dev/loop0" successfully wiped.
[twj@test-cluster ~]# losetup -d /dev/loop0
[twj@test-cluster ~]# rm -f /var/temposdblock

至此，osd从destroyed状态转变到了up状态，它上面的数据也得到了恢复。

总结

即便不是误操作，在集群运行过程中仍然有可能会需要用到osd的集群状态变化，本篇提出的办法利用osd创建过程导致的osd变化，来实现原来osd的重新上线，为大家做数据恢复提供思路。

本文作者： 奋斗的松鼠
本文链接： http://www.strugglesquirrel.com/2024/04/16/ceph运维大宝剑之拯救destroyed的osd/
版权声明： 本博客所有文章除特别声明外，创作版权均为作者个人所有，未经允许禁止转载！