如何避免Cephfs被完全毁掉


rollback

前提

一套系统的最低要求是可恢复,也就是数据不丢失,但是在各种各样的原因下,整套系统都有被毁掉的可能,一直以来有个观点就是存储是需要两套的,一般情况下很难实现,但是如何把故障发生的概率降低到最低,这个是我们需要考虑的问题

最近在社区群里面又听闻一个案例,一套系统的文件系统被重置掉了,也就是fs被重建了,实际上这属于一个不应该有的操作,但是已经发生的事情,就看怎么样能在下次避免或者把损失降到最低,对于hammer版本来说,重建cephfs只是把目录树给冲掉了,实际的目录还是能创建起来,但是这其实是一个BUG,并且在最新的Jewel下已经解决掉这个问题,这就造成无法重建目录树,在Jewel下,在不修改代码的情况下,文件都可以扫描回来,但是全部塞到了一个目录下,对于某些场景来说,这个已经是最大限度的恢复了,至少文件还在,如果文件类型可知,也可以一个个去人工识别的,虽然工作量异常的大,但至少文件回来了,这种情况,如果有保留文件名和文件md5值的强制要求的话,文件是可以完全找回来的,当然,这都是一些防范措施,看有没有重视,或者提前做好了预备

本篇就是对于情况下,如何基于快照做一个防范措施,以防误操作引起的数据无法挽回的措施

实践

对于元数据存储池来说,元数据的大小并不大,百万文件的元数据也才几百兆,所以我们有没有什么办法去形成一种保护措施,答案是有的

我们知道,ceph的存储池是有快照的,对于rbd场景来说,快照可以交给存储池去做快照管理,也可以交给Image自己做快照管理,二者差别在于,是大批量的快照还是只需要部分的快照,对于存储池快照来说,给存储池做一个快照,实际上就是对这个存储池中的所有的对象做了一个快照

我们先来看看,这个地方是如何基于快照去做文件的目录树恢复的

准备测试数据

[root@lab8106 mnt]# df -TH|grep mnt
192.168.8.106:/ ceph 897G 110M 897G 1% /mnt
[root@lab8106 mnt]# cp -ra /usr/share/doc/ce* /mnt
[root@lab8106 mnt]# ll /mnt
total 0
drwxr-xr-x 1 root root 0 Dec 30 2015 celt051-0.5.1.3
drwxr-xr-x 1 root root 0 Mar 7 2016 centos-logos-70.0.6
drwxr-xr-x 1 root root 0 Mar 7 2016 centos-release
drwxr-xr-x 1 root root 0 Dec 21 15:04 ceph
drwxr-xr-x 1 root root 0 Sep 9 17:21 ceph-deploy-1.5.34
drwxr-xr-x 1 root root 0 Mar 7 2016 certmonger-0.78.4

准备快照和需要的相关数据

对元数据池做一个快照

[root@lab8106 ~]# ceph osd pool mksnap metadata snap1
created pool metadata snap snap1

记录下元数据池的对象名称

for a in `rados -p metadata ls`;do echo $a >> metalist;done;

一个简单的循环就可以拿到列表,注意,这里并不需要把数据get下来,我们只需要记录一次列表就行,这个过程,即使很多对象的情况,这个操作也是很快的

毁掉我们的文件系统

[root@lab8106 ~]# umount /mnt
[root@lab8106 ~]# systemctl stop ceph-mds@lab8106
[root@lab8106 ~]# ceph mds fail 0
failed mds gid 4140
[root@lab8106 ~]# ceph fs rm ceph --yes-i-really-mean-it
[root@lab8106 ~]# ceph -s
cluster ffe7a8db-c671-4b45-a784-ddb41e633905
health HEALTH_OK
monmap e1: 1 mons at {lab8106=192.168.8.106:6789/0}
election epoch 3, quorum 0 lab8106
osdmap e24: 3 osds: 3 up, 3 in
flags sortbitwise
pgmap v111: 192 pgs, 3 pools, 397 kB data, 52 objects
105 MB used, 834 GB / 834 GB avail
192 active+clean

可以看到上面的操作已经把文件系统给推掉了

新创建一个文件系统

[root@lab8106 ~]# ceph fs new ceph metadata data
new fs with metadata pool 1 and data pool 2
[root@lab8106 ~]# systemctl start ceph-mds@lab8106
[root@lab8106 ~]# mount -t ceph 192.168.8.106:/ /mnt
[root@lab8106 ~]# ll /mnt
total 0

可以看到上面的操作以后,我们的目录树已经空空如也了,到这里如果没有做上面的快照相关操作,需要恢复的话,基本需要去对源码进行修改,并且需要对代码非常的熟悉才能做,一般是没有办法了,我们来看下我们基于快照的情况下,是如何恢复的
先umount掉挂载点

umount /mnt

还记得上面的快照名称和对象列表吧,我们现在对数据进行回滚:

[root@lab8106 mds]# systemctl stop ceph-mds@lab8106
[root@lab8106 mds]# for a in `cat metalist`;do rados -p metadata rollback $a snap1;done;
rolled back pool metadata to snapshot snap1
rolled back pool metadata to snapshot snap1
rolled back pool metadata to snapshot snap1
rolled back pool metadata to snapshot snap1
···

重启一下mds

[root@lab8106 mds]# systemctl restart ceph-mds@lab8106

检查下目录树,没问题,都恢复了

[root@lab8106 mds]# mount -t ceph 192.168.8.106:/ /mnt
[root@lab8106 mds]# ll /mnt
total 0
drwxr-xr-x 1 root root 3577 Dec 30 2015 celt051-0.5.1.3
drwxr-xr-x 1 root root 1787 Mar 7 2016 centos-logos-70.0.6
drwxr-xr-x 1 root root 20192 Mar 7 2016 centos-release
drwxr-xr-x 1 root root 19768 Dec 21 15:04 ceph
drwxr-xr-x 1 root root 13572 Sep 9 17:21 ceph-deploy-1.5.34
drwxr-xr-x 1 root root 147227 Mar 7 2016 certmonger-0.78.4

如果数据被不小心清空了

上面是基于重建fs情况下的恢复,下面来个更极端的,元数据池的对象全部被删除了

[root@lab8106 mds]# for a in `rados -p metadata ls`;do rados -p metadata rm $a ;done;
[root@lab8106 mds]# rados -p metadata ls
[root@lab8106 mds]# systemctl restart ceph-mds@lab8106

这个时候查看ceph -s状态,mds都无法启动,我们来做下恢复

[root@lab8106 mds]# systemctl stop ceph-mds@lab8106
[root@lab8106 mds]# ceph mds fail 0
[root@lab8106 mds]# ceph fs rm ceph --yes-i-really-mean-it
[root@lab8106 mds]# ceph fs new ceph metadata data
[root@lab8106 mds]# for a in `cat metalist`;do rados -p metadata rollback $a snap1;done;
rolled back pool metadata to snapshot snap1
rolled back pool metadata to snapshot snap1
rolled back pool metadata to snapshot snap1
rolled back pool metadata to snapshot snap1
···
[root@lab8106 mds]# rados -p metadata ls|wc -l
20
[root@lab8106 mds]# systemctl start ceph-mds@lab8106

这个时候需要多等下mds恢复正常,有可能记录了原来的客户端信息,需要做重连,如果一直没恢复就重启下mds
挂载以后,可以看到,对象数据都回来了

总结

这个能算一个防患于未然的办法,如果对于纯数据存储的情况,存储池的快照也是能够在某些场景下发挥很大的作用的,当然什么时机做快照,保留什么多少版本,什么时候删除快照,这个都是有学问的,需要根据实际的场景和压力去做