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。后面的工作就很直接了:

  1. 下载 oslo.messaging 代码库。
  2. 安装 kilo-eol 版本。
  3. 重启相关 OpenStack 相关服务。

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

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

时间: 2024-09-22 20:56:37

Troubleshooting OpenStack 瘫痪 - 每天5分钟玩转 OpenStack(160)的相关文章

如何使用 OpenStack CLI - 每天5分钟玩转 OpenStack(22)

  本节首先讨论 image 删除操作,然后介绍 OpenStack CLI 的使用方法,最后讨如何 Troubleshoot. Web UI 删除 image admin 登录后,Project -> Compute -> Images在列表中选择格式为 ARI 和 AKI 的 image,点击 点击确认删除 操作成功 CLI 删除 image 设置环境变量 查询现有image 删除image 如何使用 OpenStack CLI OpenStack 服务都有自己的 CLI. 命令很好记,就

教你看懂 OpenStack 日志 - 每天5分钟玩转 OpenStack(29)

  instance 从创建到删除的整个生命周期都是由 Nova 管理的. 后面各小节我们以 instance 生命周期中的不同操作场景为例,详细分析 Nova 不同组件如何协调工作,并通过日志分析加深大家对 Nova 的理解. 在研究 Nova 各个操作之前,我们先来学习一个重要的内容:OpenStack 日志.OpenStack 的日志记录了非常详细的细节信息,是我们学习和 troubleshoting 的利器. 日志的位置 我们实验环境使用的是 devstack,日志都统一放在 /opt/

OpenStack 架构 - 每天5分钟玩转 OpenStack(15)

终于正式进入 OpenStack 部分了. 今天开始,CloudMan 将带着大家一步一步揭开 OpenStack 的神秘面纱. OpenStack 已经走过了 6 个年头. 每半年会发布一个版本,版本以字母顺序命名.现在已经到第 12 个版本 Liberty(字母 L). OpenStack最初只有两个模块(服务),现在已经有 20+(见下图),每个模块作为独立的子项目开发. 面对如此庞大的阵容,作为初学者我们如何起步呢? 这也是 CloudMan 写这个系列教程的初衷: 通过实际操作帮助初学

写在最前面 - 每天5分钟玩转 OpenStack(1)

<每天5分钟玩转 OpenStack>是一个 OpenStack 教程,这是第 1 篇. 这个教程有下面两个特点: 系统讲解 OpenStack 从架构到各个组件:从整体到细节逐一讨论 重实践并兼顾理论 主要从实际操作的角度带着大家学习 OpenStack.   为啥要写这个? 简单回答是:因为OpenStack 学习难度大,但如果掌握了价值会很大 先做一个自我介绍吧. 本人网名CloudMan,在 IT 这个行当已经摸爬滚打了十多年,05年之前是搞上层应用开发的,那时候 Java 比较火,所

cloud-init 典型应用 - 每天5分钟玩转 OpenStack(174)

本节介绍几个 cloud-init 的典型应用:设置 hostanme,设置用户初始密码,安装软件.  设置 hostname cloud-init 默认会将 instance 的名字设置为 hostname.但这样不太方便,有时希望能够将二者分开,可利用 cloud-init 的set_hostname 模块实现.set_hostname 它会查询 metadata 中 hostname 信息,默认值就是 instance 的名字.我们可以指定自己的 hostname,方法是将下面的内容传给

学习 OpenStack 的方法论 - 每天5分钟玩转 OpenStack(150)

作为 OpenStack 的核心教程,我们已经到了最后总结的部分. OpenStack 目前已经有好几十个模块,本教程讨论的是最最重要的核心模块:Keystone,Nova,Glance,Cinder 和 Neutron.请大家看下图: 此图截自 https://www.openstack.org/software/project-navigator/,这是 OpenStack 官方定义的 6 个 Core Service.每个模块都会从三个维度来衡量: ADOPTION - 采用度 MATUR

1 张图秒懂 Nova 16 种操作 - 每天5分钟玩转 OpenStack(44)

前面我们讨论了 Instance 的若干操作,有的操作功能比较类似,也有各自的适用场景,现在是时候系统地总结一下了. 如上图所示,我们把对 Instance 的管理按运维工作的场景分为两类:常规操作和故障处理. 常规操作 常规操作中,Launch.Start.Reboot.Shut Off 和 Terminate 都很好理解. 下面几个操作重点回顾一下: Resize通过应用不同的 flavor 调整分配给 instance 的资源. Lock/Unlock可以防止对 instance 的误操作

Troubleshooting OpenStack Bug- 每天5分钟玩转 OpenStack(162)

这是 OpenStack 实施经验分享系列的第 12 篇.   问题描述 客户报告了一个问题:对 instance 执行 migrate 操作,几个小时了一直无法完成,不太正常.   问题分析 遇到这种情况,第一个要检查的就是 instance 所在计算节点的 nova-compute.log 日志,但不幸的是没有发现相关的错误. 如果 nova-compute 没有错误,那更底层的 hypervisor 有相关报错吗? 打开 /var/log/libvirt/libvirtd.log,这里我们

虚拟化 - 每天5分钟玩转 OpenStack(2)

  OpenStack是云操作系统,要学习OpenStack,首先需要掌握一些虚拟化和云计算的相关知识. 虚拟化 虚拟化是云计算的基础.简单的说,虚拟化使得在一台物理的服务器上可以跑多台虚拟机,虚拟机共享物理机的 CPU.内存.IO 硬件资源,但逻辑上虚拟机之间是相互隔离的. 物理机我们一般称为宿主机(Host),宿主机上面的虚拟机称为客户机(Guest). 那么 Host 是如何将自己的硬件资源虚拟化,并提供给 Guest 使用的呢?这个主要是通过一个叫做 Hypervisor 的程序实现的.