記一次RabbitMQ集群故障處理

RabbitMQ在Openstack雲平台中可以說是一個非常重要的角色，幾乎所有的 OpenStack 模塊都會用到 RabbitMQ，如果 RabbitMQ 掛了，OpenStack 也就癱了，可以說它是最重要的組件。

比如，在有時候，你發現Openstack的服務狀態不正常，nova service-list查看nova的服務狀態，兩次執行結果差別很大，總是在up-down之間來回切換，其他服務也是類似，或者，登錄Openstack dashboard提示無法登陸，inviald password，但是密碼確認是正確的，那麼，很大的可能性就是rabbitmq出了問題。

故障環境：

mirantis fuel 9.0 對接VMware vcenter 6.0，三個控制節點，一個計算節點管理vcenter。

這個環境運行時間比較久了，前段時間由於不可預知的問題機房斷電，然後平台就無法啟動了。三個控制節點均是在vcenter上的虛擬機，系統無法啟動。

處理過程：

首先處理系統問題，系統啟動不了估計是文件系統有問題，fscheck一下，系統正常啟動了。三個控制節點，一個計算節點都恢復了。

然後檢查Openstack平台是否可用。登陸界面是可以打開的，但是，輸入正確的賬號密碼就是登陸不了。

登陸控制節點，首先查看各個服務狀態，就如同上文所述，服務狀態一會up，一會down，那可能就是rabbitmq的問題。

在三個控制節點查看rabbitmq集群狀態，發現三個節點已經各自為政了。正常的集群應該是這樣的（請忽略那些alarms）：

執行rabbitmqclt cluster_status

然而，實際情況是控制節點一狀態為running_nodes只有自己，控制節點二也是只有自己，節點三乾脆提示（網上找的圖，故障現場已經沒了）：

好吧，首先搞定前兩個。既然各自為政了，那麼關掉其中一個，然後重新啟動就會自動加入集群，可是，重啟服務依然沒有加入集群。因為不會有人更改文件，所以，Erlang的cookie應該是沒有問題的，對比一下也證實了三個節點的cookie完全一樣的。

既然無法互相加入集群，嘗試把集群拆了，重新創建rabbitmq集群。

在控制節點一，控制節點二都執行刪除操作。

刪除操作

1. rabbitmq-server -detached

2. rabbitmqctl stop_app或者更暴力一點rabbitmqctl stop

3. rabbitmqctl reset

4. rabbitmqctl start_app

然後把節點二加入節點一，在節點二上執行以下操作。

1. rabbitctl stop_app

2. rabbitmqctl join_cluster --ram rabbit@node01（此步失敗）

3. rabbitmqctl start_app

4. rabbitmqctl cluster_status

嘗試多次，集群仍舊沒有恢復，找「兼職運維」了解情況，原來node01很早就down了，那麼rabbitmq的主節點應該在node02上，好吧，把節點一加入節點二，這次成功了。

控制節點三怎麼加入？重啟服務，一直卡在activing狀態，好不容易running了，執行加入集群操作，仍舊失敗，報錯信息見上圖。

ps -ef|grep rabbitmq 進程是ok的，mnesia進程也是ok的。嘗試清除mnesia的數據，重新加入，依舊無法加入。

rm -rf /var/lib/rabbitmq/mnesia/*

查看rabbimq日誌，居然發現，然而並沒有新的日誌！！！我開始懷疑是不是我記錯的日誌目錄了。可是對比一下另外的兩個節點，日誌正常的。

查看磁碟空間吧 ,根目錄空間還有很多空間啊。等等，為什麼日誌分區是單獨的分區！？不夠細心啊 。

df -h

Filesystem Size Used Avail Use% Mounted on

/dev/sda3 70G 24G 46G 34% /

devtmpfs 32G 0 32G 0% /dev

tmpfs 32G 0 32G 0% /dev/shm

tmpfs 32G 3.2G 29G 10% /run

tmpfs 32G 0 32G 0% /sys/fs/cgroup

/dev/sda2 494M 129M 366M 27% /boot

/dev/sda4 20G 20G 0 0% /var/log

tmpfs 6.3G 0 6.3G 0% /run/user/0

刪日誌，問題順利解決！其他節點也刪掉很多日誌。（「兼職運維」確實不夠專業）

（注意下，刪除日誌可以，千萬不要刪除某些日誌目錄，有些服務例如Openvswitch的日誌目錄不存在則無法啟動，所以，刪除的時候一定只刪除日誌）

當然，之後，Openstack各個服務還需要重啟一下，太麻煩了，三個節點依次重啟，一切恢復。

總結故障原因：

1、斷電，直接 原因。

2、控制節點系統啟動失敗，文件系統錯誤。

3、根本原因，磁碟滿了，具體來說是日誌分區滿了，實際上三個節點日誌都滿了，前兩個可能幸運一點，日誌分區還有幾十k的空間。第三個節點完全滿了，估計文件系統錯誤也和這個有關。