所谓吃一堑长一智，每次面对问题才是最好的学习机会，在面对问题的时候，尽量是能够自己去解决，或者去尝试能够最接近答案，确实无法解决再去寻求他人帮助，这样成长的会更快一些，在学校读书做题的时候，老师也是经常告诉我们要忍住，不要去直接翻答案，在当今的互联网飞速的发展下，在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