连续大量删除osd引发的集群崩溃

2022-07-06

字数统计: 1.2k字 | 阅读时长≈ 4分

操作还是有点问题啊~~

写在前面

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

有段日子没更新了，今天忙里抽空更新一个遇到的坑

发现问题

需求是这样的。我们有个集群一共36个osd节点，分成两个root，每个节点有30块盘

-112       540.00000 root hdd-root-2
 -25        30.00000     host store-data-019
......
 -33        30.00000     host store-data-036
-111       540.00000 root hdd-root-1
 -39        30.00000     host store-data-001
......
 -20        30.00000     host store-data-018
  -1        18.00000 root default
-118         6.00000     host store-mon-001
-119         6.00000     host store-mon-002
-117         6.00000     host store-mon-003

现在需求是，将hdd-root-2的所有机器从这个集群下线，然后物理搬迁到另外一个省去扩容。

由于这个集群建好后一直没有写入业务数据，只有部分cosbench的测试数据，所以在下线节点的时候是直接使用ansible跑存放在节点的磁盘上的删除osd的脚本

删除osd的脚本逻辑很简单粗暴，先是获取到本机所有osd的id，然后逐个删除，最后清理掉lvm

#!/bin/bash

all_osds=`/usr/bin/sudo /usr/bin/ls -l /var/lib/ceph/osd |/usr/bin/grep 'ceph'|/usr/bin/awk '{print $9}'|/usr/bin/awk -F '-' '{print $2}'|/usr/bin/sort -n`
delete_all_osd(){

    /usr/bin/sudo /usr/bin/systemctl stop ceph-osd.target
    /usr/bin/sleep 10
    for x in $all_osds;
    do
        osd=$x
        /usr/bin/sudo /usr/bin/ceph osd down $osd
        /usr/bin/sleep 1
        /usr/bin/sudo /usr/bin/ceph osd destroy $osd --yes-i-really-mean-it
    done
}
delete_all_osd

刚开始，ansible跑得很顺利，下线了几台机器后，速度开始大幅度下降，很显然，干掉的osd使得集群的crushmap快速变化，在mon端看到mon的cpu使用率达到了300%左右！

注意到，删除脚本中使用了ceph命令，而此时在命令行使用ceph -s明显感觉卡得厉害。。

不信邪，删除继续。。。好了，删了快一天了，终于跑完了删除脚本，此时执行ceph命令更卡了，mon的cpu使用依然维持在300%左右的水平

1 2	PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 18623 ceph 20 0 1644788 1.8g 17144 S 299.8 0.5 240:33.94 ceph-mon

看来剧烈的集群变动使得mon陷入困境了，这时为了解救mon，我手贱重启了一下三个mon，悲剧发生了，ceph命令完全不能执行了。。。

1 2	[twj@store-mon-001 ~]$ sudo ceph -s 2021-10-08 18:25:04.649 7f6f857fa700 0 monclient(hunting): authenticate timed out after 300

这下可好了，连ceph命令都执行不了了，mon进程倒是在，cpu占用仍然居高不下，嗯。。。完了完了。。。等待了相当长时间，还是不能执行ceph命令，mon完全没有要恢复的意思

幸亏这是个没有数据的测试集群，集群多次抢救无效后，决定重建！

经验与教训

事后分析，本次操作的osd数量较多，18台集群一共540个osd连续逐个down、destroy，对于每一个操作，每一条命令下去，mon都要做一系列的调整，其中最要命的是pgmap，因为osdmap发生了变化，对应的pg需要执行一次重分布，集群越大，这里的计算量会越大，如果短时间内产生了过量的操作请求，就可能使得mon陷入困境(事实上我怀疑这里有bug，猜的)，最终的结果很有可能就是这种下场，集群崩溃，这里如果要深究，强行抢救应该还是可以的，但是耗费的精力还不如直接重建，所以没有更进一步的深入了

正确的做法

要短时间大规模干掉osd，正确的做法应该是这样的：

删除osd对应的pool(如果可以删除的话)，这里我们环境就是这种情况
停掉对应的osd
等待集群显示对应的osd都down掉后，执行批量删除操作，也就是destroy或者rm

这样操作，mon能按照既定的顺序处理变化，尤其是删除pool，不过要注意，删除的pool如果数据很多，可能会引发osd暂时的down，其实没有关系，本来就要删掉它的，直接down了不是更好?

总结

删除大量osd跟删除几个坏盘的osd对于集群来说还是有点不同的，任何事操之过急都容易适得其反，希望经过此事能够吸取教训，避免线上集群出事

本文作者： 奋斗的松鼠
本文链接： http://www.strugglesquirrel.com/2022/07/06/连续大量删除osd引发的集群崩溃/
版权声明： 本博客所有文章除特别声明外，创作版权均为作者个人所有，未经允许禁止转载！