高可用叢集Heartbeat簡單闡述

一、高可用叢集是神馬？怎麼工作的？

        高可用叢集（HA：High Availability）,就是為了保證服務的持續可用性，使用1個或多個備用主機來保證主伺服器宕掉後能自動接替其工作的方案。

        這些主機中，正在工作的，我們稱為主節點，看着主節點挂掉然後才能幹活的，我們稱之為備節點，一般高可用叢集中，隻有兩個節點是很特殊的HA叢集，一般都是3個或3個以上。

        而主機工作一般都是提供各種服務，不管是網頁服務還是郵件服務或者資料庫服務等，我們将這些服務和服務所需的一些特性或者屬性稱為資源：（resource） 常見的資源類型有：磁盤分區、檔案系統、IP位址、服務程式、NFS檔案系統，以及不常見的primitive(本地類型)，group，clone，Master-slave等.

        HA叢集中，主節點一般會不停的發出一些廣播資訊，告知其他節點，他在工作，當其他節點收不到這資訊時，就認為他挂了，然後接替他的工作。看起來似乎很不錯，對吧。對了，主節點發出的這個資訊，一般都稱之為心跳資訊。

        但實際上，試想一種情況，當網絡問題，主備節點不能通信怎麼辦？又也許，主節點忙的沒時間發心跳資訊怎麼辦？涼拌麼，親？不管是那種情況，備用節點在指定的時間周期内收不到主節點的資訊就會開始篡權了。那麼，資料怎麼辦？服務資源怎麼辦？跟主節點混？誰是主節點？大家都是！是以，資料等資源就躺着也中槍了。

        這些叢集中可能發生的事情，例如節點系統故障、網絡連通故障、網卡故障、應用程式故障等，我們稱之為：事件（event）。這種各節點各自為政的行為，一般稱之為：腦裂（Split-brain）

        為了解決腦裂問題，那些V5的設計人員又折騰了出了一個霸氣的機制：爆頭（STONITH->Shoot The Other Node In The Head），可以肯定的是，肯定不會拿把槍把伺服器給崩了，雖然這會很爽。實際上，簡單來講：就是誰最先搶到主節點，然後發現有别人還跟自己搶的話，就把對方的電源給掐了或是讓對方重新開機。

        爆頭調用的裝置，在紅帽的RHCS套件中又叫隔離裝置(Fence)，其實就是當主節點挂了，備節點不急着搶資源，而是調用Fence裝置，将其隔離（重新開機，關機或者斷網），隔離成功後，再安安心心的接管。

        再試想一種場景，當一個高可用叢集中有很多台伺服器，其中一個主節點挂了，其資源給誰呢？誰搶的快給誰？不是的，我們可以定義，這個資源，譬如http服務的主節點挂了，我們在它正常的時候可以定義，如果他挂了，他優先選擇轉移到哪個節點上工作，或者隻能選擇哪個節點，或者哪個節點一定不能去，或者等他修好了，http服務還在這個節點上工作，這種方式就是對資源的限制，又叫資源粘性Stickness。

        控制着資源在自己挂了之後的選擇方式叫：資源轉移(failover)，而故障的主節點正常後，資源再主動回來的情況叫failback。

        如果有一個叢集，有10台正在工作，因為老鼠把網線咬斷了，叢集分裂了，其中6個可以通訊，另外4個可以通訊，那麼此時的叢集，到底誰幹活？大家都幹？顯然不是的，那麼怎麼辦？投票有木有？好，那就投票，很簡單，票數多于半數的，則繼續幹活，票數少的，則放棄服務。那麼此時呢？肯定是6個的繼續，4個放棄麼？錯了，要知道，票數(quorum)可不等于伺服器個數，親。管理投票的節點叫做DC（Designated Coordinator 指定的協調員）。

看了筆者廢話這麼多，納尼是不是要問：這丫的到底咋工作的？來點清晰的東西。先來個圖吧，當然，不是筆者自己畫的…

二、工作層次

        對上圖以及網絡資源的整理，筆者在解釋上圖時，簡單說一下，高可用叢集一次執行的流程如下：

        心跳層資訊------->CCM收到并廣播資訊-------->CRM（收到CCM或者CIB的資訊）通知PE更新------->PE檢視并生成一個更新動作圖傳給CRM-------->CRM把更新動作圖給TE-------->TE通過CRM指令LRM-------->LRM收到請求後調用RA執行請求。

        其實筆者覺得分兩層多省事：心跳層和處理層：一層負責發資訊，一層負責接收資訊并做相應的處理，簡單明了，對吧，哈哈。但是上面的圖分了四層，還是比較官方的資料。而且筆者也畫不出來這種圖，好吧，不要注意這些細節啊，魂淡。

        1. 還是先說心跳吧，這個工作在最底層，用來傳遞各種資訊，僅傳遞，别的啥都不管。一般稱之為基礎架構層又稱心跳層Messaging and Infrastructure。

        2. 成員關系層：Membership Layer，這一層中，有個叫CCM的服務用于管理叢集節點成員屬性的一緻性，上層需要做神馬操作，都會需要他提供的成員關系來執行。

        3. 資源配置設定曾：Resource Allocation Layer

        a)      CRM叢集資料總管(Cluster Resource Manager)，它運作在每個節點上，并監控CCM的成員關系資訊，并根據相關的資訊作出相應的處理，上面說的DC，就是CRM随機指派的。

        b)       CIB叢集資訊庫(Cluster Information Base)，這裡面放的就是XML格式的文檔，平時運作在記憶體中，通過crm等指令操作，操作後會同步到其他節點，貌似是由DC排程。

        c)       PE和TE  政策引擎和執行引擎(Policy Engine和Transition Engine)；基本上，看這名字就知道他倆是幹嘛的，一個是負載定制怎麼改，一個負責執行的，實際上他倆不通信，都是通過CRM這厮進行通信的，甚至TE執行的時候都是通過CRM讓各個節點的本地資料總管(LRM)進行執行的.

        d)       LRM本地資料總管(Local Resource Manager)。CRM是對整個叢集資源的宏觀調整的話，這個就是每個節點自己對自身資源的管理操作了。

        4. 資源層Resource Layer，通過RA(Resource Agents)腳本實作對資源的各種操作，開始，關閉，重新開機，狀态資訊查詢，配置重新載入甚至爆頭等，其實最後幹的活都是RA來做的。資源代理支援的類型有如下幾種：

Lsb符合linux标準庫的腳本；

Ocf:  Open Cluster Framework 開放叢集架構，比LSB更略微強大；

Heartbeat V1: Heartbeat早起出現時使用的腳本，就叫做heartbeat V1；

Stonith: 這種腳本必須對應相應的硬體裝置支援，否則無意義。常見的此類型裝置分兩類（内部|外部）。内部：IBM RSAII卡、HP的iLo卡，以及IPMI的裝置等。外部：UPS，SAN SWITCH，NETWORK SWITCH等。

三、軟體分類

        心跳層的事，就是傳遞資訊，不做處理，是以我們可以了解成：運作在這一層上面的軟體隻是一個API（Application Programming Interface,應用程式程式設計接口）。運作在這一層上的軟體有如下：

Heartbeat

Keepalived

Ultramonkey

Corosync(OpenAIS子項目)

等~~~