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 包。

因為我們目前的版本是 kilo，是以要找 oslo.messaging 在 kilo 上的最新版本。

在 Tags 中，我們看到有 kilo-eol，eol 的意思是 “end of life”，是 kilo 的最終版本了。

可以再次确認，kilo-eol 确實包含了我們想要的 fix。後面的工作就很直接了：

下載下傳 oslo.messaging 代碼庫。

安裝 kilo-eol 版本。

重新開機相關 OpenStack 相關服務。

下節我們會詳細讨論如何更新 OpenStack 元件。

由于 oslo.messaging 是基礎元件，幾乎所有服務都會用到，是以不得不更新每一個節點并重新開機 OpenStack。工作量雖然大些，但問題終于解決了。

本文轉自CloudMan6 51CTO部落格，原文連結:http://blog.51cto.com/cloudman/1904163