HA cluster：高可用集羣High Avaliability Cluster
高可用性能實現的軟件組合： heartbeat V1
heartbeat V2
heartbeat+pacemaker
corosync+pacemake
cman(openais)+rgmanager
高可用性能:就是服務器不間斷的提供服務，而這種情況又是單個的服務器又不能完成的，所以我們就提供了高可用集羣。
高可用集羣:是指以減少服務中斷時間爲目的的服務器集羣技術
怎麼讓服務不中斷呢？就是一臺服務器down了，另一臺會頂上去。比如說現在又兩臺機器A和B，當A機down掉後，我們的B要馬上把在A上運行的服務以及對應的進程運行起來，並且幾乎是無縫隙的運行。那現在就出現了兩個問題，B主機怎麼知道A主機出了問題？
在高可用集羣當中，每個節點他們是通過心跳heartbeat信息來確定對方的健康狀況的，心跳信息就是每個節點每隔一個時間都要發出的一個信號，讓對方確認自己是否是正常的工作的，因爲要實現無縫隙對接，所以心跳信息的發送頻率是非常高的。所以當B在一個時間範圍內接收不到A傳過來的信息的時候，它就認爲A已經掛掉了，B此時就要用A機的IP接替A的工作了。那它是怎麼接替A的工作的呢？這就需要一個專門管理資源的層次，叫做資源管理層（CRM）。
上面提到他們是通過心跳的信息來判斷彼此的健康的狀況的，那心跳信息是怎麼傳遞過去的？心跳信息heartbeat的傳遞是需要一個通道的，可以稱它爲低層的通信信道，能夠提供這樣一個通道的軟件有heartbeat corosync cman。
另外在高可用服務當中一定要考慮的一個問題，當B要接替A的共作的時候，B如何獲取與A上面一摸一樣的數據呢？有兩種方式可以解決這個問題：
第一種方式是共享存儲；
第二種方式是通過文件同步功能來實現，DRBD種較理想的解決方案，當一個設備上的數據出現了問題，另一個設備上還有同樣的數據存在。
即使是已經解決了數據一致性的問題，還有一個問題沒有考慮，每個節點怎麼判斷它是集羣的一份子呢？它就是通過Quorum票數來判斷的。quorum機制就是讓集羣內的節點，對每個節點都進行投票選舉，如果節點接收到的Auorum票數，大於原來選取票數的1/2，它就認爲它自己還是機器的一份子，那麼它還會爲集羣服務，當小於1/2時候他就認爲它已經不是集羣了，所以就不在作爲集羣提供服務了，那對於3個節點的集羣來說至少2個節點時激活狀態纔有效，那對於兩個節點的集羣的話，如果一個節點出現問題，那票數怎麼都是小於二分之一，此時集羣就不能工作了。（共享存儲的一小塊分區來支持Quorum）
有了以上策略就避免了集羣分裂，但是資源依然會產生資源徵用，因爲這個節點上可能還運行着某個資源呢。應該將其停掉。爲了避免資源徵用，所以要隔離那些不再是集羣的節點去訪問那些集羣源。
隔離級別兩種，一種是節點級別隔離，一種是資源級別隔離。
節點級別的隔離：需要一種特殊的設備stonith來進行隔離，它是利用電源交換機。
資源級別的隔離：就是對應的設備自身就有資源隔離能力，FC SUN就有。
爲了解決小規模集羣存在的Quorum問題，引入了qdisk,它使用一個小於10MB的共享磁盤分區，Qdiskd進程運行在集羣的所有節點上，定期評估自身的健康情況，然後把它的狀態信息放入到指定的共享磁盤分區。每qdiskd接着查看其他節點的狀態，並傳遞信息給其他節點QDisk分區。在正常情況下，集羣的Quorum就是每個節點計數再加上QDisk分區的計數和。
對於兩個節點的集羣，任何一個節點出現問題，都會造成集羣的分裂癱瘓，面對這種情況有兩種解決方案：
第一、找個第三方節點，嘗試ping它來判斷自己是否正常的，這個第三方節點最好選網關。
第二、用共享的仲裁磁盤qdisk。
資源轉移：可不是資源流動啊，因爲每個資源在啓動的時候進程號是不一樣的，它表示把一個服務在毀掉的節點上停掉，然後在一個新的節點上啓動起來。
資源代理RA：資源代理RA：CIM正常工作了真正實現資源管理的還要靠RA.就是負責完成停掉這個服務，並且在新的節點上啓動這個服務的一個腳本。監控節點上的信息。（RA按圖結構給出的話應該位於CRM的上面）
CIB：Cluster Information Base集羣信息庫，用於保存集羣中資源的屬性配置信息，是CRM的一個子進程，它要運行在每個集羣的節點上,並且每個節點上的CIB都是一樣的，如果某個節點的壞掉了，CIB信息庫肯定是要改變了，它是先改變節點DC信息協調員上面的信息庫，在由DC同步到其它的節點上去。DC是由集羣自動選取的協調員。包括那個quorum票數也是保存在它上面。
PE：集羣策略引擎就是根據從底層收集來的信息判定集羣是否還能運行，並且生成big-picture。當發現集羣依然可以運行，它就會指揮TE完成。只運行在DC節點上。
TE：事物引擎，負責根據PE計算的結果指揮資源轉移，即通知LRM去完成這個動作，只運行在DC節點上。
LRM：運行在每個節點上的本地資源管理器，它可以理解是CRM的一個外派。它還是CRM的一個子組件。
既然要定義資源，那我們還需要定義資源的接口:
ha.resource
CLI
GUI:Web GUI 圖形化的接口
Web GUI又有很多種，因爲它們都是一個組件:
紅帽RHCS集羣套件中：luci/ricci
Debian/SUSE系統上，pacemaker自身帶有hawk的圖形接口
heartbeat GUI
底層通信信道的軟件實現方案：heartbeat corosync keepalived ultramonkey(前兩着同屬紅帽)
CRM軟件：heartbeat(V1) legacy CRM
heartbeat(V2) CRM
heartbeat(V3) + Pacemaker + Cluster-glue
在紅帽5中集羣套件：corosync+cman
在紅帽6中集羣套件：corosync+pacemaker
資源約束：位置約束/順序約束/排列約束
-inf 永遠不再一起
inf 百分百在一起