Planet Ceph

Aggregated news from external sources

February 24, 2017

记最近一次ceph故障修复

前言

所谓吃一堑长一智,每次面对问题才是最好的学习机会,在面对问题的时候,尽量是能够自己去解决,或者去尝试能够最接近答案,确实无法解决再去寻求他人帮助,这样成长的会更快一些,在学校读书做题的时候,老师也是经常告诉我们要忍住,不要去直接翻答案,在当今的互联网飞速的发展下,在google的帮助下,基本上90%的问题都能找到正确的答案,而我们其实真正需要锻炼的是实践能力和甄别的能力

去年一年给不少的生产环境解决过问题,在相互交流几次以后,解决问题的过程,基本也熟悉了,一般解决问题的大致流程都是:

  • 告之我环境的当前状况,需要实现的情况
  • 准备好远程的环境
  • 告之对方可能出现的情况,是否可操作,然后解决问题
  • 交流问题的出现原因以及解决的办法

目前来看,基本都解决了,对于我来说是一次处理故障经验的累积,对对方来说是环境的恢复,以及下次在出现相同故障的时候,自己能够处理好类似问题

本次恢复对于我来说也是刷新了的认识,进展只到了解决问题的地方,就结束了,那么我就记录下这次解决问题当中的收获

处理过程

故障的发生应该是在一次掉电后触发的,整个集群在重新启动以后,出现了多块磁盘故障的问题,也有主机无法启动的情况,整个集群的PG状态处于一个混乱的状态,stale和incomplete以及peering状态的都很多

告之对方,需要把相关的osd节点全部都启动起来,然后再看是否有恢复的可能,常规来说,如果三台机器同时出现磁盘损坏,那么这个集群的数据必然会丢失,并且丢失的数据基本将是覆盖所有数据

在将近一周的时间以后,集群环境磁盘都能挂载,环境可以进行处理了

出现pg状态一直是peering状态的情况

用ceph -s 检查集群的状态,集群的状态所有的osd都是正常的up in状态,但是pg状态就是peering状态无法恢复,然后查看都是来自其中的某一个osd,登陆上机器后查看osd的日志,显示无法获取心跳,但是网络明明是好的,并且还能登陆到其他机器上,这就奇怪了,这里先讲下这个地方对方环境埋下的一个坑

hosts文件里面是这种组合

10.10.10.101 node1
192.168.10.1 node1
10.10.10.102 node2
192.168.10.2 node2
10.10.10.103 node3
192.168.10.3 node3

也就是一个主机名映射了两个IP,这个对方说没问题,我也就不多说了,只是我的环境是不会允许这么配置,正是因为这个配置,也就间接隐藏了一个错误的配置,这个错误就是居然在环境当中配置两台主机相同的IP,这也就是为什么出现相同的IP我还能登陆机器

环境配置成了

10.10.10.102 node3
192.168.10.3 node3

也就是node3和node2的集群IP冲突了,所以我在ssh node3的时候能正确登陆node3 ssh node2也能正确登陆node2,只是集群用的IP冲突了,而两台机器之间网络又可以通过其他的网段通信,集群的osd状态是正常,只是pg异常了

IP冲突在生产环境中是大忌,可能会毁掉整个集群的状态,这个有多大影响?你可以试下配置好一个集群,然后把两个节点的IP配置成一样,然后检查集群的状态和你的上面运行的存储的状态,这个环境因为是在不提供服务状态下,所以带来的影响没有那么大

在排查到这个错误的时候,已经是晚上快11点了,对方也要回家了,作为运维比较苦逼的就是很多时候,需要待在公司到晚上很晚才能离开,所以问了下是否能留远程给我,得到了许可,可以继续操作,因为这个环境状态来看我觉得还在我的可控范围内,所以想继续尝试,对方也是问过几次,这个环境是否可恢复,我给出的回答也是尽量,IP冲突的问题解决后,重新启动OSD,集群基本快正常了,还是有一些异常的PG需要处理

出现osd无法启动

verify_reply couldn’t decrypt with error: error decoding block for decryption

这个错误之前有处理经验,时间偏移过大引起认证不通过,登陆上osd对应的机器,检查发现时间偏移了几个小时,引起错误,检查发现ntp配置文件使用的是默认配置文件,至少这台没配置ntp,调整好时间,重启osd解决无法启动问题

出现PG incomplete的状态

这个状态一般是环境出现过特别的异常状况,PG无法完成状态的更新,这个只要没有OSD被踢出去或者损坏掉,就好办,这个环境的多个PG的数据是一致的,只是状态不对,这个就把PG对应的OSD全部停掉,然后用ceph-object-tool 进行mark complete,然后重启osd,一般来说这个都是能解决了,没出意外,这个环境用工具进行了修复,当然8个这样的PG操作起来还是要比较长的时间,一个个的确认状态,还好都解决了,这个工具是jewel上面集成的,所以在老版本出现这个问题,可以通过升级后进行处理,之前有个别人的生产环境这么处理过这个问题

出现PG inconsistent状态的

这个是环境中有数据不一致了,这个算比较小的问题,直接对pg进行了repair的修复,然后pg状态就正常了,不得不说现在的ceph比很久前的版本要好很多,Jewel版本的修复工具已经非常完善了,基本能覆盖很多常规的故障

出现PG 处于activaing状态

上面的各种问题都处理过来了,到了最后一个,有一个PG处于activating状态,对于ceph来说真是一个都不能少,这个影响的是这个PG所在的存储池当中的数据,影响的范围也是存储池级别的,所以还是希望能够修复好,在反复重启这个pg的所在的osd后,发现这个pg总是无法正常,并且这个机器所在的OSD还会down掉,开始以为是操作没完成,需要很多数据要处理,所以增加了osd_op_thread_suicide_timeout的超时值,发现增大到180s以后还是会挂掉,然后报一堆东西,这个时候想起来还没去检查下这个PG是不是数据之前掉了,检查后就发现了问题,主PG里面的目录居然是空的,而另外两个副本里面的数据都是完整的并且一样的,应该是数据出了问题,造成PG无法正常

停止掉PG所在的三个OSD,使用ceph-object-tool进行pg数据备份,然后用ceph-object-tool在主PG上删除那个空的pg,这里要注意不要手动删除数据,用工具删除会去清理相关的元数据,而手动去删除可能会残留元数据而引起异常,然后用ceph-object-tool进行数据的导入,然后重启节点,还是无法正常,然后开日志看,发现是对象权限问题,用工具导入的时候,pg内的对象是root权限的,而ceph 启动的权限无法读取,手动给这个pg目录进行给予ceph的权限,重启osd,整个集群正常了

然后通知对方,环境修复好了,对方回复,有空检查下虚拟机情况,然后就没有然后了···

这个环境暴露的问题

1、主机名hosts内单主机名对应多IP
这个对于对主机名敏感的应用会受影响
2、环境出现IP冲突
这个属于细节问题,当然也是最不好排查的一种故障
3、环境内没配置内网ntp
操作其中的某台机器的时候报了,不清楚整个环境没配置还是只是一台没配置
4、有一个mon挂掉了,没有先处理
这个对于进行故障处理的时候经常会请求到故障的mon上,造成卡操作,因为不清楚mon状态,所以没启动,直接注释配置文件进行操作
5、主机环境的内存分配设置有问题
这个因为没太多交流也就不多说了
6、ceph版本为10.2.2
这个版本有什么问题吗?用的不是好好的吗?这个问题我一直认为公司一定需要有人会选择版本,这里说下怎么选,你也可以自检下自己的版本,当然你们研发觉得没问题,我也就不做过多评论,每个人有自己的想法,别乱来就好

  • 软件的开发一般会是隔一个版本会是一个长期支持版本,所以尽量不要选择
    INFERNALIS这个版本,Jewel刚出来,那么你应该选择harmer最后一个版本,而这个时候就会有人选择了Jewel版本,也就是上面的10.2.2或者更低10.0.x
  • 长期支持版本出来了,那么尽量等版本出到4或者5再去用,也就是现在的Jewel的10.2.5,这个版本不会出现大的bug,K版本就不要随便上生产,等等后面的 Luminous的稳定版本
  • 内部做升级需求的时候,在选择下个版本的时候同样是选择下一个长期支持版本的稳定版本,这样能保证软件的稳定性,以及版本的生命周期尽量长
  • 正常运行的时候都没事,碰上异常经常一搜就是已经解决了bug,等到这个时候再升级,就是故障中升级,拉长了故障恢复时间
  • 所以现在的版本能够用Jewel的最后一个版本和hammer的最后一个版本,一些能backports的功能,也会合成到hammer的最后一个版本
  • 小版本中间也可能有大变化,0.94.4和0.94.7这两个都是节点版本,节点版本就是你从更低的版本往更高的版本升级的时候,需要先来到节点版本,然后才能往上走,也就是迭代升级,如果不了解清楚,直接把集群升级到起不来也是会出现的事情

总结

本次处理的故障属于组合型的,本篇是博客当中贴命令最少的一篇,当然内容不少,相信你看了处理过程也会有所收获,不管你是搞云计算还是云存储,一定要重视数据的可恢复问题

变更记录

Why Who When
创建 武汉-运维-磨渣 2017-02-24

Source: zphj1987@gmail (记最近一次ceph故障修复)

Careers