首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >如何避免Cephfs被完全毁掉

如何避免Cephfs被完全毁掉

作者头像
用户2772802
发布2018-08-06 17:58:15
1.6K0
发布2018-08-06 17:58:15
举报
文章被收录于专栏:磨磨谈磨磨谈

前提

一套系统的最低要求是可恢复,也就是数据不丢失,但是在各种各样的原因下,整套系统都有被毁掉的可能,一直以来有个观点就是存储是需要两套的,一般情况下很难实现,但是如何把故障发生的概率降低到最低,这个是我们需要考虑的问题 最近在社区群里面又听闻一个案例,一套系统的文件系统被重置掉了,也就是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 挂载以后,可以看到,对象数据都回来了

总结

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

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2016-12-23,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 磨磨谈 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 前提
  • 实践
    • 准备测试数据
      • 准备快照和需要的相关数据
        • 毁掉我们的文件系统
          • 新创建一个文件系统
            • 如果数据被不小心清空了
            • 总结
            相关产品与服务
            数据保险箱
            数据保险箱(Cloud Data Coffer Service,CDCS)为您提供更高安全系数的企业核心数据存储服务。您可以通过自定义过期天数的方法删除数据,避免误删带来的损害,还可以将数据跨地域存储,防止一些不可抗因素导致的数据丢失。数据保险箱支持通过控制台、API 等多样化方式快速简单接入,实现海量数据的存储管理。您可以使用数据保险箱对文件数据进行上传、下载,最终实现数据的安全存储和提取。
            领券
            问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档