记一次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是否支持这种操作，那就试试这种
这个集群之所以能挽回，有几个特殊点正好都在，缺一不可
- 删除的数据盘居然没被格式化，或者搞掉，这个如果弄没了，数据必丢
- 删除的数据盘的盘位部分被新加的节点占用了，部分还没有被占用，而这个缺失数据的pg的数据所删除的osd正好又没有被占用（所以以后替换osd的时候最好是用新的编号，老的盘和编号保留着）
开始恢复的操作
之前我加节点的操作都是用的ceph-deploy，可以说基本没有遇到过手动能做的ceph-deploy无法完成的，好吧这次我知道了还是有无法完成的，手动的还是多学学比较好，好在我比较熟悉，就按步骤去做
1、增加认证
我们在删除osd的最后一步的时候操作都是ceph auth del
我就反向的操作
ceph auth add osd.0 osd 'allow *' mon 'allow rwx' -i /var/lib/ceph/osd0/keyring
这个对应keyring就是在删除那个osd上面有，每个osd上面都有的
这一步操作完成后auth里面就有osd.0了
2、创建osd
ceph osd create
这个步骤也是之前没有做过的，之前准备直接加crush 直接启动发现都是无法启动，提示没有osd
这一步相对于删除里面的操作应该就是 ceph osd rm 的操作了
3、增加crush
ceph osd crush add osd.0 0.9 host=node1
这个就是加入到crush里面去
4、启动osd
/etc/init.d/ceph start osd.0
检查现在环境状况
在检查的时候发现osd真的就加进来了，然后在添加了另一个被block的osd后，集群状态就没有imcomplete了就是active+其他的一些恢复状态什么的，只需要等待恢复，集群即可恢复正常了，到这个时候已经凌晨三点了，事情能够完满解决是最开心的事情
后记
集群的删除操作随意，集群的信息基本无记录，环境的基础记录都没有，这个是这个事故的最大原因，再往上走就是对于数据操作这块，公司没有一个重视的态度，上面的boss永远不会关心你运维做了什么操作，而运维人员也可以说是我按标准流程操作的，也没法去定谁的责任，丢了就是丢了，运维最多也就是丢了工作，而企业损失应该就是以万为单位的损失加客户的流失了
到这里也许这家公司的头并不知道发生了什么，也许只是认为是一个小的业务中断，但真的某一天出事了，这就是大事了，所以一定要重视系统的监控和系统操作的谨慎
by 运维-武汉-磨渣
2016年04月11日夜
