TroubleshootingOpenStack瘫痪-每天5分钟玩转OpenStack160

这是 OpenStack 实施经验分享系列的第 10 篇。
是软件就会有 bug,OpenStack 也不例外,只要用它就一定会遇到故障。Troubleshooting(故障排除)是运维 OpenStack 等开源项目的重要技能,遇到问题后一定要借助社区的力量定位、搜索、分析并解决问题。
下面 CloudMan 将分享一个真实的案例,还原当时 Troubleshooting 的过程,希望能给大家一些启发。


问题描述


某天客户的 OpenStack 突然全线瘫痪:任何操作都无法正常完成,一直处于正在执行状态,界面上也不报错,就是无法完成操作。


问题分析


这是一个全局性的问题,首先查看 nova 日志,无报错,再看 MySQL 和 RabbitMQ 日志,在 RabbitMQ 中发现大量重复报错:


TroubleshootingOpenStack瘫痪-每天5分钟玩转OpenStack160


一直报 reply_529af7a7c3784c2d9dc5e72c603024a5 这个 exchange 找不到。 这些 reply_XXX 的都是 OpenStack 自己维护的,之前运行得好好的,为什么突然找不到,应该是发生了异常,跟配置没有关系,估计是 bug。

先 google 一下吧。搜索技术问题,google 是首选,翻不了墙就用 bing,度娘嘛还是让她专注中文吧 :-)


这里贴出 bing 的搜索结果:


TroubleshootingOpenStack瘫痪-每天5分钟玩转OpenStack160


看上去第二个比较靠谱,点进去发现跟我们的情况完全一样,而且还提到一个相关 bug。


TroubleshootingOpenStack瘫痪-每天5分钟玩转OpenStack160

TroubleshootingOpenStack瘫痪-每天5分钟玩转OpenStack160

浏览一下 bug 的内容,确实是我们遇到的问题,这是一个 oslo.messaging 的 bug,而且已经 fix 了。


TroubleshootingOpenStack瘫痪-每天5分钟玩转OpenStack160


因为客户 OpenStack 版本是 kilo, 所以点击 kilo 对应的 review 链接看看 fix 都修改了哪些地方。


TroubleshootingOpenStack瘫痪-每天5分钟玩转OpenStack160


一共改了两个文件,点开 amqpdriver.py 的链接,可以看到 diff。


TroubleshootingOpenStack瘫痪-每天5分钟玩转OpenStack160

对比客户系统 /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 的最终版本了。


TroubleshootingOpenStack瘫痪-每天5分钟玩转OpenStack160


可以再次确认,kilo-eol 确实包含了我们想要的 fix。后面的工作就很直接了:


  1. 下载 oslo.messaging 代码库。

  2. 安装 kilo-eol 版本。

  3. 重启相关 OpenStack 相关服务。

下节我们会详细讨论如何更新 OpenStack 组件。


由于 oslo.messaging 是基础组件,几乎所有服务都会用到,所以不得不更新每一个节点并重启 OpenStack。工作量虽然大些,但问题终于解决了。


TroubleshootingOpenStack瘫痪-每天5分钟玩转OpenStack160

更多相关文章
  • nova-compute部署instance详解-每天5分钟玩转OpenStack28
    本节讨论 nova-compute,并详细分析 instance 部署的全过程. 先给大家道个歉:今天这篇文章的篇幅比以往要多一些,本来想分两次发,但考虑到文章的完整和系统性,还是一次发了出来,这次可能要超出 5 分钟了,大家见谅.nova-compute 在计算节点上运行,负责管理节点上的 ins ...
  • OpenStack通用设计思路-每天5分钟玩转OpenStack25
    API 前端服务 每个 OpenStack 组件可能包含若干子服务,其中必定有一个 API 服务负责接收客户请求. 以 Nova 为例,nova-api 作为 Nova 组件对外的唯一窗口,向客户暴露 Nova 能够提供的功能. 当客户需要执行虚机相关的操作,能且只能向 nova-api 发送 RE ...
  • 看nova-scheduler如何选择计算节点-每天5分钟玩转OpenStack27
    本节重点介绍 nova-scheduler 的调度机制和实现方法:即解决如何选择在哪个计算节点上启动 instance 的问题. 创建 Instance 时,用户会提出资源需求,例如 CPU.内存.磁盘各需要多少. OpenStack 将这些需求定义在 flavor 中,用户只需要指定用哪个 fla ...
  • Launch和ShutOff操作详解-每天5分钟玩转OpenStack30
    本节详细分析 instance launch 和 shut off 操作,以及如何在日志中快速定位有用信息的技巧. Launch Launch instance 应该算 Nova 最重要的操作. 仔细研究 lanuch 操作能够帮助我们充分理解 Nova 各个子服务的协调配合和运行机制. 前面我们已 ...
  • StartInstance操作详解-每天5分钟玩转OpenStack31
    本节通过日志文件详细分析 instance start 操作. 下面是 start instance 的流程图 向 nova-api 发送请求 nova-api 发送消息 nova-compute 执行操作 下面我们详细讨论每一个步骤. 向 nova-api 发送请求 客户(可以是 OpenStac ...
一周排行