Troubleshooting OpenStack 瘫痪 - 每天5分钟玩转 OpenStack(160)
这是 OpenStack 实施经验分享系列的第 10 篇。
是软件就会有 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 相关服务。
下节我们会详细讨论如何更新 OpenStack 组件。
由于 oslo.messaging 是基础组件,几乎所有服务都会用到,所以不得不更新每一个节点并重启 OpenStack。工作量虽然大些,但问题终于解决了。
最新文章
- ITIL十大流程
- jQuery表单编程实例
- App Store
- Dynamic CRM 2013学习笔记(十七)JS读写各种类型字段方法及技巧
- Spark源码系列(九)Spark SQL初体验之解析过程详解
- GEOS库学习之五:与GDAL/OGR结合使用
- 重温设计模式(三)——职责链模式(chain of responsibility)
- 企业级应用架构(三)三层架构之数据访问层的改进以及测试DOM的发布
- js node
- TreeSet排序
- Java 学习内容总结
- didLoadFromCCB方法的调用顺序
- win10更新失败——适用于Windows 10 Version 1709 的03累积更新,适合基于x64系统(KB4088776)更新失败
- 使用 wordcloud 构建词云图
- Linux实时查询GPU使用命令
- 使用Dockerfile来构建镜像
- 微信小程序制作家庭记账本之一
- 前端面试题 | JS部分(附带答案)
- C++ Templates 关于程序库的概念和通用工具
- VGA、DVI、HDMI、DP 接口介绍及优劣