fence_ipmilan 的一個缺陷
前幾天,我們的linux-HA 的主從資料庫同時poweroff 了
系統當機,
在6月份也莫名其妙的發生過一次,當時不得其解,將其歸結為偶然事件。
這次再發生就不能放過了,可以用重現,說明問題是存在的。
問題發生後,我們的猜測: 1 是 主機ipmi 部件有bug,在特定條件下無法響應 fence裝置的請求,導致傳送了reboot命令後
impi裝置只執行了poweroff 或者就乾脆 fence裝置,解析錯了pacemaker 的指令, 吧reboot 解析為poweroff
2 fence裝置對reboot 命令的執行不是原子的,即需要向主機ipmi裝置提交兩次指令,先提交poweroff 然後再提交poweron 指令
strace 了 fence-ipmilan 的執行發現他是透過呼叫 impitool 的lib庫來執行的,而不是直接呼叫ipmitool 這個client命令來執行,
把我們當初設想的,為ipmitool 寫個shell 來包裝的做法給否決了。
那麼就只有檢視fence_ipmilan的原始碼來分析了。
透過檢視原始碼,就是這裡了,印證了我們的猜測,fence-ipmilan 是對reboot 的操作不是原子的,而是分拆為兩個命令來提交到主機的ipmi模組。
到這裡 ,我們就可以反推出當時主機同時當機的原因了。
先是是主庫 發現從庫 離線,然後啟動fence裝置去reboot 從庫,對從庫傳送了reboot命令,但是當只提交了一個poweroff 的時候,
這個時候從庫也發現了主庫離線了,從庫也啟用fence裝置去reboot 主庫,這個時候,主庫還在等待,ipmi 返回poweroff 的執行狀態,
還沒有向從庫提交poweron 的指令,所以從庫就直接poweroff 了,而主庫的ipmi裝置接收了從庫的reboot命令只完成了poeeroff ,
但是從庫已經被主庫關機了,這個時候,它已經無法發出剩下的那個poweron請求了。
從這裡我們猜測當時應該是叢集發生腦裂了。 兩臺機器同時認為對方發生了離線了,需要把對方fence 掉。
而且對端主機的對reboot 的返回,都沒有完成,就出現這個問題了。
關於解決方案, 雙機模式下,確實發生腦裂的機率會大很多,
目前想到的一個比較可行的方案: 對其中一臺fence裝置,設定一個合適的時間間隔,等待一個時間後,再fence掉對方,
而另一臺機器則直接fence 對方的機器,這樣即使發生了腦裂,應該只有一臺機器會把對方fence掉
這裡可能會發生一個情況,對方機器啟動後, 會繼續fence對方,還是要經過雙方都要重啟一次。
另一個方案是隻部署一個fence裝置,只fence 一臺機器,但是這個情況需要測試。
經過測試,這個方式是可行的,一臺機器利用delay 選項 演示fence 另一臺機器直接fence 可以解決這個問題。
系統當機,
在6月份也莫名其妙的發生過一次,當時不得其解,將其歸結為偶然事件。
這次再發生就不能放過了,可以用重現,說明問題是存在的。
問題發生後,我們的猜測: 1 是 主機ipmi 部件有bug,在特定條件下無法響應 fence裝置的請求,導致傳送了reboot命令後
impi裝置只執行了poweroff 或者就乾脆 fence裝置,解析錯了pacemaker 的指令, 吧reboot 解析為poweroff
2 fence裝置對reboot 命令的執行不是原子的,即需要向主機ipmi裝置提交兩次指令,先提交poweroff 然後再提交poweron 指令
strace 了 fence-ipmilan 的執行發現他是透過呼叫 impitool 的lib庫來執行的,而不是直接呼叫ipmitool 這個client命令來執行,
把我們當初設想的,為ipmitool 寫個shell 來包裝的做法給否決了。
那麼就只有檢視fence_ipmilan的原始碼來分析了。
1 | if (!strcasecmp(op, "reboot")) { printf("Rebooting machine @ IPMI:%s...", ip); fflush(stdout); if(!strcasecmp(method, "cycle")) { ret = ipmi_op(i, ST_STATUS, power_status); |
2 | if (ret == STATE_OFF) { /* State is off -> use onoff method because cycle is not able to turn on*/ snprintf(method, sizeof(method), "onoff"); } } |
3 | if (!strcasecmp(method, "cycle")) { ret = ipmi_cycle(i); } else { /* Original onoff method */ ret = ipmi_off(i); translated_ret = (ret==0?ERR_OFF_SUCCESSFUL:ERR_OFF_FAIL); if (ret != 0) { goto out; } ret = ipmi_on(i); } |
到這裡 ,我們就可以反推出當時主機同時當機的原因了。
先是是主庫 發現從庫 離線,然後啟動fence裝置去reboot 從庫,對從庫傳送了reboot命令,但是當只提交了一個poweroff 的時候,
這個時候從庫也發現了主庫離線了,從庫也啟用fence裝置去reboot 主庫,這個時候,主庫還在等待,ipmi 返回poweroff 的執行狀態,
還沒有向從庫提交poweron 的指令,所以從庫就直接poweroff 了,而主庫的ipmi裝置接收了從庫的reboot命令只完成了poeeroff ,
但是從庫已經被主庫關機了,這個時候,它已經無法發出剩下的那個poweron請求了。
從這裡我們猜測當時應該是叢集發生腦裂了。 兩臺機器同時認為對方發生了離線了,需要把對方fence 掉。
而且對端主機的對reboot 的返回,都沒有完成,就出現這個問題了。
關於解決方案, 雙機模式下,確實發生腦裂的機率會大很多,
目前想到的一個比較可行的方案: 對其中一臺fence裝置,設定一個合適的時間間隔,等待一個時間後,再fence掉對方,
而另一臺機器則直接fence 對方的機器,這樣即使發生了腦裂,應該只有一臺機器會把對方fence掉
這裡可能會發生一個情況,對方機器啟動後, 會繼續fence對方,還是要經過雙方都要重啟一次。
另一個方案是隻部署一個fence裝置,只fence 一臺機器,但是這個情況需要測試。
經過測試,這個方式是可行的,一臺機器利用delay 選項 演示fence 另一臺機器直接fence 可以解決這個問題。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/133735/viewspace-1068927/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 阮一峰:Javascript的10個設計缺陷JavaScript
- 一個專業的缺陷跟蹤管理軟體:JIRA
- Javascript的10個設計缺陷JavaScript
- [個體軟體過程]之缺陷管理--缺陷預測 (轉)
- 推薦一個專業優秀的缺陷跟蹤管理軟體
- 缺陷和缺陷報告
- Java中的讀寫鎖ReentrantReadWriteLock詳解,存在一個小缺陷Java
- 分享一個你很可能不知道的Java異常實現的缺陷Java
- 原始碼解讀: Vuex 的一些缺陷原始碼Vue
- 關於超融合基礎設施,有兩個缺陷一定要談
- 軟體缺陷的案例
- ltrim() 函式的缺陷函式
- 那些 “被消失” 的缺陷
- 缺陷描述
- 的確,Java存在缺陷。但是……Java
- check_postgres.pl 的缺陷
- C# 壓縮的缺陷C#
- 曝Wi-Fi重大缺陷:你瀏覽的或是個假網站網站
- C陷阱和缺陷,必須知道的495個C語言問題C語言
- 漏洞解析——通用異常缺陷及字串比較缺陷字串
- MongoDB的排除查詢$ne缺陷MongoDB
- 請教:單例模式的缺陷單例模式
- 遠端呼叫procedure可能會有一些缺陷!
- 安全缺陷持續升高,新系統帶來新缺陷(轉)
- 聊聊缺陷逃逸率
- Facebook AI指出:CNN的padding機制,存在一大缺陷AICNNpadding
- 和智慧手錶相比:智慧手環這個缺陷太致命
- 程式碼缺陷解讀:通用異常捕獲宣告缺陷漏洞
- 強化學習的基礎缺陷強化學習
- 學校C語言教材的缺陷C語言
- 淺析Windows防火牆的缺陷(轉)Windows防火牆
- ARP協議的安全缺陷 (轉)協議
- [個體軟體過程]之缺陷管理--程式碼複查 (轉)
- [個體軟體過程]之缺陷管理--編碼標準 (轉)
- DAISY : 一種 Linux 上可用的服務於視力缺陷者的文字格式AILinux
- halcon缺陷檢測
- 軟體缺陷管理流程
- 字串型別存在缺陷字串型別