如何避免Cephfs被完全毁掉

前提

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

最近在社区群里面又听闻一个案例，一套系统的文件系统被重置掉了，也就是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

挂载以后，可以看到，对象数据都回来了

总结

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