心跳腦裂解決方案之Heartbeat的Stonith配置

在心跳失效的時候，就發生了split-brain。
好比： 正常狀況下，NodeA和NodeB在心跳檢測以確認對方存在；在經過心跳檢測不到對方時，就接管對應的resource。若是忽然間，NodeA和NodeB之間的心跳不存在了，而NodeA和NodeB事實上都active，這時NodeA要接管NodeB的resource麼？而同時NodeB要接管NodeA的resource麼？這時就是split-brain。

不對的狀況請你們指正。

split-brain會引發數據的不完整性,甚至是災難性的,又如何理解呢?
其實不只僅是數據的不完整性，可能會對服務形成嚴重影響。

對於數據的不完整性，主要爲集羣節點訪問同一存儲，而此時並無鎖機制來控制數據訪問（都split-brain，心跳全沒有了，咋控制裏），那就存在數據的不完整性的可能。這個也是RHCS爲什麼必需要fence設備的主要緣由。能夠參考RHCS的文檔，其中也有對split-brainde 說明。
對於服務的影響，主要是可能早上NodeA和NodeB同時接管了一個虛擬IP（僅僅是舉例子。）

在「雙機熱備」高可用（HA）系統中，當聯繫2個節點的「心跳線」斷開時，原本爲一總體、動做協調的HA系統，就分裂成爲2個獨立的個體。因爲相互失去了聯繫，都覺得是對方出了故障，2個節點上的HA軟件像「裂腦人」同樣，「本能」地爭搶「共享資源」、爭起「應用服務」，就會發生嚴重後果：或者共享資源被瓜分、2邊「服務」都起不來了；或者2邊「服務」都起來了，但同時讀寫「共享存儲」，致使數據損壞（常見如數據庫輪詢着的聯機日誌出錯）。

對付HA系統「裂腦」的對策，目前我所瞭解的大概有如下幾條：
1）添加冗餘的心跳線，例如雙線條線。儘可能減小「裂腦」發生機會。
2）啓用磁盤鎖。正在服務一方鎖住共享磁盤，「裂腦」發生時，讓對方徹底「搶不走」共享磁盤資源。但使用鎖磁盤也會有一個不小的問題，若是佔用共享盤的一方不主動「解鎖」，另外一方就永遠得不到共享磁盤。現實中假如服務節點忽然死機或崩潰，就不可能執行解鎖命令。後備節點也就接管不了共享資源和應用服務。因而有人在HA中設計了「智能」鎖。即，正在服務的一方只在發現心跳線所有斷開（察覺不到對端）時才啓用磁盤鎖。平時就不上鎖了。
3）設置仲裁機制。例如設置參考IP（如網關IP），小心跳線徹底斷開時，2個節點都各自ping一下參考IP，不通則代表斷點就出在本端，不只「心跳」、還兼對外「服務」的本端網絡鏈路斷了，即便啓動（或繼續）應用服務也沒有用了，那就主動放棄競爭，讓可以ping通參考IP的一端去起服務。更保險一些，ping不通參考IP的一方乾脆就自我重啓，以完全釋放有可能還佔用着的那些共享資源。

# What does "split-brain" mean?

"Split brain" is a condition whereby two or more computers or groups of computers lose contact with one another but still act as if the cluster were intact. This is like having two governments trying to rule the same country. If multiple computers are allowed to write to the same file system without knowledge of what the other nodes are doing, it will quickly lead to data corruption and other serious problems.

Split-brain is prevented by enforcing quorum rules (which say that no group of nodes may operate unless they are in contact with a majority of all nodes) and fencing (which makes sure nodes outside of the quorum are prevented from interfering with the cluster).

# What does "split-brain" mean?

"Split brain" is a condition whereby two or more computers or groups of computers lose contact with one another but still act as if the clus ...
這個應該是紅帽文檔吧？

簡單來講，腦裂就是上面提到的小心跳網絡出現情況的時候，集羣可能分裂成幾個節點組，幾個節點組都分別接管服務而且訪問文件系統資源（例如併發寫入文件系統）致使數據損壞。

實際上腦裂正常狀況下是沒法見到的，現代集羣都應該有保護機制來避免這種狀況發生。例如RHCS引入的fence的概念。

具體狀況是這樣，例如2個節點集羣，小心跳斷開致使節點之間互相沒法通訊的時候，每一個節點會嘗試fence掉對方（確保對方釋放掉文件系統資源）後再繼續運行服務訪問資源。這樣，就能夠確保只有一個節點能夠訪問資源而不會致使數據損壞。

因此這個也是RHCS爲何必須有fence設備的緣由。前面不少帖子都在討論到底要不要fence，官方講法是，若是你跑生產，要保證數據不受損壞，就必須有fence設備。

集羣出現bug的時候也會出現腦裂，這裏就不提怎麼產生腦裂了，但願你們都別碰到。。。 呵呵

 

前一陣，在爲廣發銀行搭建HA集羣時，客戶總但願在出現腦裂問題後能很好的解決。當時因爲沒有深入的理解heartbeat的各個模塊，crm、ccm、ipfail各個插件試試得我是暈頭轉向的，最後的解決方式是加了兩根心跳線。說白了，仍是沒解決，只是在心跳監測方面更增強壯而已，這裏筆者介紹Stonith這個模塊，以解決腦裂問題。

腦裂

當羣集發生裂腦的情況時候，由於沒法進行任何溝通而誤會對方沒法運做，因此主與備份服務器都會啓動浮動IP和相關服務，此時若兩部服務器對外連線亦未短線，那麼勢必致使有些使用者存取的是主要服務器，另一些則存取備份服務器的情形。此外，若是兩部服務器共享一個存儲裝置，發生裂腦時兩部服務器會同時掛載該存儲裝置，亦同時存取相同的檔案，所以若共享存儲裝備缺少良好的鎖定機制，更可能使得存儲裝置上的檔案因同時讀寫而損壞。更有可能致使硬盤中寫入不一致的信息，致使後期數據錯誤，甚至整個數據庫損壞，後果不堪設想。
避免裂腦的方法有兩個：第一個方法是在服務器間使用多重連線；第二個則是使用heartbeat的STONITH功能。

Stonith概述
stonith是「shoot the other node in the head」的首字母簡寫，它是Heartbeat軟件包的一個組件，它容許使用一個遠程或「智能的」鏈接到健康服務器的電源設備自動重啓失效服務器的電源，stonith設備能夠關閉電源並響應軟件命令，運行Heartbeat的服務器能夠經過串口線或網線向stonith設備發送命令，它控制高可用服務器對中其餘服務器的電力供應，換句話說，主服務器能夠復位備用服務器的電源，備用服務器也能夠復位主服務器的電源。
注意：儘管理論上鍊接到遠程或「智能的」循環電源系統的電力設備的數量是沒有限制的，但大多數stonith實現只使用兩臺服務器，由於雙服務器stonith配置是最簡單的，最容易理解，它可以長時間運行且不會下降系統的可靠性和高可用性。

查看當前支持Stonith設備清單的命令：
#/usr/sbin/stonith -L

想要使用stonith功能須要安裝heartbeat-pils-*.rpm和rpm -ivh hearbeat-stonith-*.rpm
配置stonith設備

在Heartbeat中使用stonith和stonith_host這兩個指令來配置stonith設備
stonith語法以下

stonith {stonith-device-type} {stonith-configuration-file}
其中stonith-device-type爲stonith設備的類型，而stonith-configuration-file爲stonith設備的配置信息文件。例如：
stonith baytech /etc/ha.d/conf/stonith.baytech.
stonith_host語法以下
stonith_host {hostfrom} {stonith_type} {params...}
其中hostfrom爲和stonith設備相連的主機可使用*表明全部主機，stonith_type爲stonith設備的類型，可經過stonith -L查看，params爲stonith設備所須要的參數。例如

stonith_host  smart403  apcsmart  smart404  /dev/ttyS1
單個Stonith設備
正常狀況下，高可用配置使用兩個stonith設備構造(一個鏈接到主服務器，一個鏈接到備用服務器)可是，這裏咱們先來探討如何使用單個stonith設備部署Heartbeat，它將在你的高可用配置中引入兩個重要的限制：
一、 全部資源必須運行在主服務器上（在主服務器在線時不容許在備用服務器上運行資源）。
二、故障轉移事件只能發生一次，並只能朝一個方向轉移，也就是說，運行在主服務器上的資源只能故障轉移到備用服務器一次，當備用服務器取得了資源的全部權時，關閉主服務器，要恢復到主服務器正常運行必需要操做員干預。
當你只使用一個stonith設備時，你必須在主服務器上運行全部的高可用資源，由於主服務器不能復位備用服務器的電源（當主服務器從故障中恢復後想要取回資源的全部權時，它須要復位備用服務器的電源），也就是說，備用服務器上的資源在沒有第二個stonith設備時不是高可用的，在使用單個stonith設備時，故障轉移後，也須要操做員干預，由於主服務器將關閉。

 

 

 

正常狀況下，主服務器廣播它的心跳，備用服務器聽到心跳就知道一切都運行正常，但當備用服務器聽不到主服務器的心跳時，它向stonith設備發送恰當的軟件命令循環主服務器上的電源

 

 

Stonith事件序列
一、當備用服務器聽不到心跳時Stontih事件開始。
注意：這並不必定意味着主服務器沒有發送心跳，心跳可能有多種緣由而沒有抵達備用服務器，這就是爲何建議至少須要兩條物理路徑傳輸心跳以免出現假象的緣由了。
二、備用服務器發出一個Stonith復位命令到Stonith設備。
三、Stonith設備關閉主服務器的電力供應。
四、一經切斷主服務器的電源，它就不能再訪問集羣資源，也不能再爲客戶端提供資源，保證客戶端計算機不能訪問主服務器上的資源，排除可能發生的頭腦分裂狀態。
五、而後備用服務器得到主服務器的資源，Heartbeat用start參數運行資源腳本，並執行ARP欺騙廣播以便客戶端計算機發送它們的請求到它的網絡接口上。
一旦主服務器完成重啓，它會嘗試回收它的資源，要求備用服務器釋放資源，除非兩臺服務器都關閉了auto_failback選項

兩個Stonith設備

兩個Stonith設備的拓撲圖以下

 

鏈接完畢後，在/etc/ha.d/ha.cf文件中加入下列內容便可
stonith_host  smart403  apcsmart  smart404  /dev/ttyS1

stonith_host  smart404  apcsmart  smart403  /dev/ttyS1第一行表示經過smart403節點利用與stonith設備相連的com1(STONITH裝置相鏈接的Linux設備名稱。可使用stonith –h指令查詢各裝置的參數用法。)經過stonith設備apcsmart(stonith –h指令的列表中能夠查到APC Smart UPS 的裝置名稱爲apcsmart)關閉smart404節點第二行表示smart403能夠藉由鏈接於COM2接頭上的apcsmart裝置，將smart404關機，與第一行相反。有些STONITH裝置必須使用密碼才能連線，若是將密碼設置在ha.cf文件中，最好將該文件的權限設置爲600（#chmod /etc/ha.d/ha.cf），修改權限使其餘人不可讀取。若是泄密，任何人均可以隨意關閉另外一部服務器。使用STONITH功能必須當心雙方同時發出關機指令，致使兩部服務器一塊兒關機的情形。有些共享的STONITH裝置能夠設定爲一次只接受一臺主機的指令，如此便能避免此問題發生。或者也能夠開啓兩部服務器的ha.cf檔案，在「deadtime」項目設定不一樣的時間，例如主要服務器上設定爲180秒，而備份服務器則爲120秒，讓二者斷定對方【死亡】的時間不一致，也能避免這個情形的發生。若是還沒有購買STONITH功能所支援的硬件，可是想測試STONITH功能的話，可使用虛擬的STONITH裝置進行試驗。可使用文件編輯器打開主服務器上的/etc/ha.d/ha.cfstonith_host smart403 null smart404Smart403:此處設定主要服務器的節點名稱Null：爲虛擬STONITH裝置的名稱Smart404：此處設定備份服務器的節點名稱編輯完成後重啓heartbeat，以使新設定生效。而後在備份服務器上執行下面命令關閉網絡：/etc/init.d/network stop最後開啓主要服務器上的/var/log/ha-log記錄，搜尋STONITH字串，觀察STONITH功能的運做情形:會發現內有：heartbeat[7871]: 2011/09/18_21:51:26 WARN: node smart404: is deadheartbeat[7871]: 2011/09/18_21:51:26 info: Link  smart404:eth0 dead.heartbeat[8419]: 2011/09/18_21:51:26 info: Resetting node  smart404ith [NULL STONITH device] //使用STONITH裝置將備份服務器關機heartbeat[8419]: 2011/09/18_21:51:26 info: glib: Host null-reset:  smart404heartbeat[8419]: 2011/09/18_21:51:26 info: node  smart404 now reset.   //備份服務器已經關機heartbeat[7871]: 2011/09/18_21:51:26 info: Exiting STONITH  smart404 process 8419 returned rc 0.