OpenStack 瘫痪的分析及解决方法,针对这个问题,这篇文章详细介绍了相对应的分析和解答,希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。
为英山等地区用户提供了全套网页设计制作服务,及英山网站建设行业解决方案。主营业务为做网站、网站制作、英山网站设计,以传统方式定制建设网站,并提供域名空间备案等一条龙服务,秉承以专业、用心的态度为用户提供真诚的服务。我们深信只要达到每一位用户的要求,就会得到认可,从而选择与我们长期合作。这样,我们也可以走得更远!
是软件就会有 bug,OpenStack 也不例外,只要用它就一定会遇到故障。Troubleshooting(故障排除)是运维 OpenStack 等开源项目的重要技能,遇到问题后一定要借助社区的力量定位、搜索、分析并解决问题。
下面 CloudMan 将分享一个真实的案例,还原当时 Troubleshooting 的过程,希望能给大家一些启发。
某天客户的 OpenStack 突然全线瘫痪:任何操作都无法正常完成,一直处于正在执行状态,界面上也不报错,就是无法完成操作。
这是一个全局性的问题,首先查看 nova 日志,无报错,再看 MySQL 和 RabbitMQ 日志,在 RabbitMQ 中发现大量重复报错:
一直报 reply_529af7a7c3784c2d9dc5e72c603024a5 这个 exchange 找不到。 这些 reply_XXX 的都是 OpenStack 自己维护的,之前运行得好好的,为什么突然找不到,应该是发生了异常,跟配置没有关系,估计是 bug。
先 google 一下吧。搜索技术问题,google 是首选,翻不了墙就用 bing,度娘嘛还是让她专注中文吧 :-)
这里贴出 bing 的搜索结果:
看上去第二个比较靠谱,点进去发现跟我们的情况完全一样,而且还提到一个相关 bug。
浏览一下 bug 的内容,确实是我们遇到的问题,这是一个 oslo.messaging 的 bug,而且已经 fix 了。
因为客户 OpenStack 版本是 kilo, 所以点击 kilo 对应的 review 链接看看 fix 都修改了哪些地方。
一共改了两个文件,点开 amqpdriver.py 的链接,可以看到 diff。
对比客户系统 /usr/local/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py 文件内容,确实是 fix 之前的版本。
问题确定了,解决办法也有了:更新 olso.messageing 包。
OpenStack 的源代码是在 github 上维护的,每个模块有自己的 repository。 oslo.messageing 的项目主页是 https://github.com/openstack/oslo.messaging
因为我们目前的版本是 kilo,所以要找 oslo.messaging 在 kilo 上的最新版本。
在 Tags 中,我们看到有 kilo-eol,eol 的意思是 “end of life”,是 kilo 的最终版本了。
可以再次确认,kilo-eol 确实包含了我们想要的 fix。后面的工作就很直接了:
下载 oslo.messaging 代码库。
安装 kilo-eol 版本。
重启相关 OpenStack 相关服务。
由于 oslo.messaging 是基础组件,几乎所有服务都会用到,所以不得不更新每一个节点并重启 OpenStack。工作量虽然大些,但问题终于解决了。
关于OpenStack 瘫痪的分析及解决方法问题的解答就分享到这里了,希望以上内容可以对大家有一定的帮助,如果你还有很多疑惑没有解开,可以关注创新互联行业资讯频道了解更多相关知识。