记一次ceph的故障修复(20160408)

ceph的在正常运行的时候基本不会出现故障,出现故障一般在变动的时候,具体有下面几种可能出现的情形

  • 软件升级
  • 增加存储节点
  • 减少存储节点
  • 调整副本数目
  • 调整pg数目
  • 磁盘出现损坏
  • 节点网络出现异常

以上这些操作过程中是最可能出现异常的情形,并不是一定会出问题,以上问题除了网络和磁盘问题出现的异常是基本无法避免外,其他出现的时候,一般是非正常操作引起的,也就是我通常认为的人为事故,这个一般出现在操作的不谨慎上

本篇记录了一次故障的修复过程,这个故障不是出现在我们公司的产品上,是看到一个ceph社区群里有一个成员在里面问到一个异常是否能解决,这个不同于普通的问题,从他贴出的信息来看,集群已经是非常严重的状态了

正好看到是周五,周六还可以休息下,所以即使快到了晚上12点了,我还是联系了一下那哥们,从简短的几句交流后,基本可以判断对方对于ceph基本处于刚接触的阶段,在询问是否有其他人能协助他做一些比较有难度的操作的时候,他说没有,就他一个人,我想在目前中国很多公司,都是让一个并不太熟悉ceph的运维人员,或者完全就是开发人员维护着存储着非常宝贵的数据的云存储环境,上面运行的应该都是客户的数据,想想我们自己的电脑在硬盘损坏后,自己有多么不爽,而对于企业来说,一个运行环境的损坏有多么严重,一方面损失了数据,另一方面,基本不会再选择这个服务的提供商了,而这些都是一个定时炸弹,运行在中国的开源存储网络环境当中,而且基本都是初创小企业,大企业会有专门的专业的相关人员,而一个数据损失基本会对这些初创企业带来巨大的损失,这些都是需要企业的boss多关注的,这也是我一直持有的一个观点,越来越多的企业是用ceph,也意味着存储需要修复的出现几率就越大,其实我们也是一个小企业,我个人是非常关注数据恢复这一块的,这个比调优更加的重要,大环境的吐槽就到这里,下面开始讲下具体的经过

首先找对方要了一个ssh登陆环境

这个对方正好有这个环境允许我的登陆,虽然中间经过了堡垒机,虽然运行命令比较卡顿,但好歹能上去,这个是我个人非常支持的一种做法,不管怎样,是VPN也好,代理也好,一定留一个外网的ssh端口能够让连上机器,这个能允许随时随地能上去处理问题,等你运维人员到达现场,真是黄花菜都凉了,对于比较保密的环境,最好也能够有一个在紧急情况下开启远程允许环境的条件,这个具体花费,一个上网卡,一台破旧的笔记本就基本能实现了,在需要远程操作的时候能够连上去处理,目前已经协助了几个朋友处理了一些简单的问题,基本都是ssh连过去的,而没有远程环境的,我也是无能为力的

检查环境

登陆上去以后,检查环境发现提示的是2个pg的状态imcomplete,这个是pg的数据不一致的提示,而在检查了对应的osd上的这个pg的数据的时候,发现映射计算到的3个上面有两个是没有数据的,有一个是有数据的,在询问对方做过的操作后,对方是做了一个删除osd的操作,并且是多台机器上面都做过删除,到这里我询问了一下对方,对方是按照一些通用的操作去做的删除操作,命令肯定是没有问题的,这个在后面我处理完后,基本能判断出对方是人为的操作失误引起的

尝试修复

开始想起之前做过的一次模拟修复,本来以为这个可以把环境弄好了,基本想法就是如下流程:

  • 停止pg对应的3个osd
  • 导出有数据的pg
  • 在无数据的osd上进行pg的数据导入
  • 启动三个osd

在进行到数据的导入的时候提示了pg is blocked,这个在我之前的做的测试中是没有遇到过的,后来进行pg的状态查询时候,发现是pg的显示的数据全是0,也就是集群认为这个pg是没有数据的,并且被几个已经删除了的osd blocked,而且做ceph osd lost 也是无法操作的,提示没有osd,这个应该是pg状态不一致,也就是这个pg状态完全异常了,并且还无法导入了

思考解决办法

到这里我个人判断基本是回天无力了,再次跟对方确认删除的过程,发现对方好在数据盘都保留了,并且还插在机器上,只是有部分osd在进行增加的时候还占用了删除的osd的id

到这里我基本想出来两种方法:

  • 最不济,也是终极解决办法就是把后台缺失的数据拼起来,这个耗时巨大,操作难度大,基本上只能作为最后终极挽回的方法,这个只有在客户已经觉得数据可能要丢了,然后去做最后的终极挽回大法了,客户的容忍度是会随着你问题严重性而改变的,相信我数据还在都好说
  • 就是将删除的数据盘给加进来,这个操作在我几年ceph生涯中也是从未做过的,也想不出什么场景下需要这种操作,好吧,不管多么特殊的操作,总有它的存在的意义,我也不能确定ceph是否支持这种操作,那就试试这种

这个集群之所以能挽回,有几个特殊点正好都在,缺一不可

  1. 删除的数据盘居然没被格式化,或者搞掉,这个如果弄没了,数据必丢
  2. 删除的数据盘的盘位部分被新加的节点占用了,部分还没有被占用,而这个缺失数据的pg的数据所删除的osd正好又没有被占用(所以以后替换osd的时候最好是用新的编号,老的盘和编号保留着)

开始恢复的操作

之前我加节点的操作都是用的ceph-deploy,可以说基本没有遇到过手动能做的ceph-deploy无法完成的,好吧这次我知道了还是有无法完成的,手动的还是多学学比较好,好在我比较熟悉,就按步骤去做

1、增加认证

我们在删除osd的最后一步的时候操作都是ceph auth del
我就反向的操作

1
ceph auth add osd.0 osd 'allow *' mon 'allow rwx' -i /var/lib/ceph/osd0/keyring

这个对应keyring就是在删除那个osd上面有,每个osd上面都有的
这一步操作完成后auth里面就有osd.0了

2、创建osd

1
ceph osd create

这个步骤也是之前没有做过的,之前准备直接加crush 直接启动发现都是无法启动,提示没有osd
这一步相对于删除里面的操作应该就是 ceph osd rm 的操作了

3、增加crush

1
ceph osd crush add osd.0 0.9 host=node1

这个就是加入到crush里面去

4、启动osd

1
/etc/init.d/ceph start osd.0

检查现在环境状况

在检查的时候发现osd真的就加进来了,然后在添加了另一个被block的osd后,集群状态就没有imcomplete了就是active+其他的一些恢复状态什么的,只需要等待恢复,集群即可恢复正常了,到这个时候已经凌晨三点了,事情能够完满解决是最开心的事情

后记

集群的删除操作随意,集群的信息基本无记录,环境的基础记录都没有,这个是这个事故的最大原因,再往上走就是对于数据操作这块,公司没有一个重视的态度,上面的boss永远不会关心你运维做了什么操作,而运维人员也可以说是我按标准流程操作的,也没法去定谁的责任,丢了就是丢了,运维最多也就是丢了工作,而企业损失应该就是以万为单位的损失加客户的流失了
到这里也许这家公司的头并不知道发生了什么,也许只是认为是一个小的业务中断,但真的某一天出事了,这就是大事了,所以一定要重视系统的监控和系统操作的谨慎

by 运维-武汉-磨渣
2016年04月11日夜