高可用集羣的前提：
1、節點需要不停的向其他節點通告自己的心跳信息，以判斷節點的健康狀態。
2、需要使用加密暗號進行溝通，防止任意主機的加入。
3、使用投票機制決定哪個主機爲活動主機。一般高可用集羣節點爲奇數個（至少3個），且當節點過多時，會被劃分爲多個小的集羣，當其中一個小的集羣不能與另一個小集羣連通時，這時多於半數的小集羣就會被當做主集羣。而少於半數的小集羣則放棄所有服務。
高可用集羣的資源：
就是運行在集羣中的服務，比如httpd、sshd等。
failover：節點主機故障後，運行在其上的資源轉移到備用節點上的過程。
failback：故障節點恢復後，資源轉移回來的過程。
資源粘性：資源啓動後，更傾向於運行在哪個節點主機上。
資源約束：(constraints)
位置約束：locations
定義資源和節點間的關係，比如資源更傾向於運行在哪個節點上。
定義範圍是正無窮(inf)到負無窮(-inf)。
正無窮表示只要有可能運行在當前節點就運行。負無窮則相反。
但是正無窮和負無窮相加，結果是負無窮。因爲正無窮需要額外資源。
順序約束：order
當有多個資源時，定義資源的啓動和關閉的先後順序。
比如web服務，必須先有IP資源，再有Filesystem，最有才是httpd
排列約束：colocations
定義資源間的關係，也就是2個資源要不要在一起啓動的傾向性。
比如IP和Filesystem必須要在一起。
依然使用正無窮(inf)和負無窮(-inf）來確定。
當集羣中有很多主機時，如果任由一個資源在主機間遊動，那麼過幾天肯定無法找到那個資源的位置。所以需要定義一個故障轉移策略限定資源的故障轉移域。
左對稱：使用白名單，資源只能轉移到預定的主機上。
右對稱：使用黑名單，資源不能轉移到某些主機上面。
高可用集羣的層次結構：
1、信息和成員關係層（Messaging and Membership），Messaging主要用於節點之間傳遞心跳信息，也稱爲心跳層。節點之間傳遞心跳信息可以通過廣播，組播，單播等方式。成員關係（Membership）層，這層最重要的作用是主節點（DC）通過Cluster Consensus Menbership Service（CCM或者CCS）這種服務由Messaging層提供的信息，來產生一個完整的成員關係。這層主要實現承上啓下的作用，承上，將下層產生的信息生產成員關係圖傳遞給上層以通知各個節點的工作狀態；啓下，將上層對於隔離某一設備予以具體實施。能夠直接運行在信息層上的軟件叫做高可用軟件，由於這種軟件開發難度高和週期長，所以又有了第二層。
2、集羣資源管理層（Cluster Resource
Manager），真正實現集羣服務的層。在該層中每個節點都運行一個集羣資源管理器（CRM，cluster Resource
Manager），它能爲實現高可用提供核心組件，包括資源定義，屬性等。在每一個節點上CRM都維護有一個CIB(集羣信息庫
XML文檔)和LRM（本地資源管理器）組件。對於CIB，只有工作在DC（Designated
Coordinator，指定的協調員。主節點）上的文檔是可以修改的，其他CIB都是複製DC上的那個文檔而來的。對於LRM,是執行CRM傳遞過來的在本地執行某個資源的執行和停止的具體執行人。當某個節點發生故障之後，是由DC通過PE（策略引擎）和TE（實施引擎）來決定是否搶奪資源，DC是集羣自動選舉出來的，不用手動修改。
3、資源代理層（Resource Agents），集羣資源代理(能夠管理本節點上的屬於集羣資源的某一資源的啓動，停止和狀態信息的腳本)，資源代理分爲：LSB（/etc/init.d/*）,OCF(比LSB更專業，更加通用),Legacy heartbeat（v1版本的資源管理）。
各層的實現工具介紹：
| Message Layer | CRM | RA |
| heartbeat V1 | haresource：heartbeat V1 | haresource：heartbeat V1 |
| heartbeat V2 | crm：heartbeat V2，crm牌CRM | LSB：/etc/rc.d/init.d/* |
| heartbeat V3 | pacemaker：獨立出heartbeat的項目，適配多款軟件。 | OCF：Open Cluster Framework開放集羣框架 |
| RHCS：cman(rhel5) | RHCS：rgmanger(RHEL6) | STONITH：電源交換機爆頭開關，防止集羣分類時的資源爭用 |
| coroync |
在RHEL6上有多種可供選擇的信息層+CRM組合方案
1、cman+rgmanger
2、cman+pacemaker
3、heatbeat V3+pacemaker
4、corosync+pacemaker
安裝corosync時，由於製作RPM時會依賴於heartbeat的一些RA，所以會同時裝上heartbeat，但是heartbeat不一定啓動。但是heartbeat卻不會依賴corosync的。
編輯HA集羣的接口：
1、直接編輯配置文件
2、CLI：crmsh(SUSE),pcs(redhat)命令行方式
3、GUI：heartbeat-GUI、LCMC、HAWK、pygui、RHCS的Conga
fencing：
當正在服務的節點突然宕機時，爲了保證其在宕機瞬間不再繼續佔用集羣資源，比如仍然在使用塊級別的存儲設備SAN，這時很有可能就會破壞文件，所以就需要讓其瞬間徹底的脫離集羣。
節點級別的fencing：使用STIONITH，能接受網絡信號的電源交換機，
當資源進入新的主機，那麼可以發信號切斷老主機電源
當老主機是虛擬機時，就可以直接殺死那個進程就可以了。
資源級別的fencing：在SAN設備上直接阻斷老主機進入的端口的流量。
XML： eXtended Markable Language擴展的可標記語言，但是很難配置，不易用
資源類型：
primitive，native：主資源，只能運行在一個節點上的資源
group：組資源，一個組資源也只能運行在一個節點上。
clone：克隆資源，需要運行在多個節點上，比如stonith，需要運行在多個節點上，
當資源轉移時，隨時槍斃老資源。
master/slave：主從類資源，也是克隆類資源，但分主從，比如drdb。
集羣模式：
active/passive：主備模型
active/active：雙活動節點，通過corosync提供的功能，實現一個資源(包括主資源)可以運行在多個節點上。
N對M：N個節點，M個服務。
N對N：N個節點，N個服務。
雙節點集羣：，
一般HA集羣至少是3個節點，但是雙節點在提供其他配置的情況下，也是可以運行的。
1、ping node，可以提供多個，可以使路由器。
2、qdisk（quarum disk)：仲裁磁盤，也就是一個共享磁盤
主節點不停的向qdisk上寫數據，然後由備用節點不停的監測，如果在規定時間內看不到新數據了，那麼就判定主節點已經掛掉，然後將其stonith並搶佔資源。