HA（High Availability）高可用集群，其特點為根據實際需求為前端Diretor,后端RS-server，數據庫服務器，共享存儲等集群節點做一個從備份服務器或者多個服務器互相備份，一旦主服務器掛掉，備份服務器能立馬檢測到并取代主服務器上的資源繼續運行服務，從而最大限度避免了因服務器宕機造成的服務中止。

主節點（active/primary）備節點（passive/standby）

主調度器（Director）一般為集群中的關鍵節點，所以一般都有備份節點的存在；而后端RS-server可以根據實際可靠需求加備份節點，而存儲服務器，如Mysql-Server,也作為集群的關鍵節點，一般都配有主從服務器。

HA集群著重服務的可靠性和穩定性兩個方面

可用性=服務在線時間/（服務在線時間+故障處理時間）

可用性由 99%，99.9%，99.99%，99.999%不斷提升，每多一個9，服務可用性提高十倍。在某些應用中服務可用性都要達到五個9的級別如：金融交易系統.....

HA Resource（高可用集群資源）:一旦節點故障這些資源需要轉移到其他備份節點上，包括VIP，服務，隔離設備，文件系統。每個RS上都運行有服務資源，當有多個RS節點時，一旦某個節點發生故障要立馬進行資源轉移到其他節點，讓其他節點處理未處理完的請求，并且要防止Director將前端請求繼續此節點，但有如此多的節點存在，故障發生時到底往哪個節點轉移了？且要是這個故障節點又恢復了如何處理？這時就要定義資源的黏性，資源的約束等。

資源的粘性：資源更傾向運行在哪個節點上，即資源與節點的傾向性

如：定義web服務在A服務器上的資源粘性為120，在B服務器上的資源粘性為100，一旦A發生故障又恢復正常后web服務又會從B服務器上轉移到A服務器

資源的黏性：資源是否傾向運行在當前節點，Score>0（傾向）Scoro<0（不傾向，即一有其他可運行此服務的節點，資源就立馬轉移到其他節點）

資源的約束：定義資源與資源的傾向性

1. colocation（排列約束）：定義不同資源能否運行在同一個節點上，Score>0（可以），Score<0（不可以）?

   -inf(負無窮。。決不能運行在同一節點）

   inf(正無窮。。必須運行在同一個節點）

2. location（位置約束）：每個節點都可以給某資源一個Score，Score >0（資源傾向運行在此節點）

3. Score <0（資源不傾向運行在此節點）

一般資源黏性+位置約束 哪個大，資源更傾向運行在那個節點

Order(順序約束）：定義資源啟動關閉時的順序，因為不同資源可能有依賴關系如：VIP與IPVS規則，VIP先啟動IPVS規則后啟動

資源分類

1. Primitive 一個資源單獨只運行在一個節點上（主資源）。

2. clone 每個節點上都運行此資源。

3. group 將多個資源劃分為一個組，同組資源同進退，一起在節點上進行轉移。

4. master/slave 主/從,一個資源只能運行在兩個節點上，且一個為主一個為從。

備份節點如何知道主節點故障？

heartbeat（心跳信息）：每個節點都要隨時與備份節點上進行通信，目的為檢測對方是否在線

但當存在三個及三個以上節點時且這些節點也要互相傳輸心跳信息（如 運行有同種服務的RS之間互為備份節點，），從而判斷自己是否故障，是否為合法節點，如何判斷？

將所有節點定義在一個組播內讓其互相ping， 比如有A、B、C、D、E 五個RS節點運行有Web服務，某時刻A、B、C三個節點能互相ping通，而D、E兩個節點可以互相ping 通，則可以定義一個Quorum（投票）機制，為每個節點定義為一票，則五個節點共五票，且定義只有獲得一半以上票數才為合法節點，所以此時A、B、C節點共三票，而D,E節點共兩票，可以認為D,E節點未非法節點（即D,E節點出了故障）

或者A節點ping不通其他節點獲得一票，而B、C、D、E四個節點可以互相ping通獲得四票，可以認為A節點為非法節點

而對于多節點集群來說，為了投票機制的實施，節點數最好為奇數，獲得票數超過一半則認為合法

且可以定義不同節點的擁有票數不同，如A節點性能好有兩票投票權，B節點性能一般擁有一票投票權，此時就不用節點奇數，只要總票數為奇數便可以產生決策。

一旦節點被認為為非法節點應對其采取什么措施？

1. Freeze（凍結） 此非法只處理已經連接的請求，不再接受新的請求，處理完請求后再進行資源轉移

2. stop 非法節點直接停止運行服務，進行資源轉移，這種措施最常用

3. ignore 直接忽略 繼續正常運行服務

什么時候會用到ignore?

只有兩個互為備份的節點時

當只有兩個節點互為備份時，一旦主節點ping不通備份節點，這時因為只有兩個節點無法采取投票機制（一旦采取投票機制則兩個節點都只獲得一票，都認為自己掛掉了，那么不但主節點會停止服務，原本應該替代主節點的備份節點也因為認為自己非法而無法對主節點進行取代），主節點只能繼續運行服務，直到被Stonish設備或fence設備隔離進行資源轉移，這時備份節點也會取代主節點。

為了提供一個一個MySQL服務要具有哪些資源？

1. VIP 專門提供服務

2. FIP(float IP)流動的IP,可以再節點之間轉移

3. Mysql服務

4. 文件系統（要進行掛載）

一旦一個節點掛掉，向哪個節點轉移？

定義個節點的資源約束score,哪個score大，更傾向于向哪個節點轉移

腦裂:假設一個集群有4個RS_Server A、B、C、D

其中A正在往一個文件中寫入數據，并且由于A服務器的CPU繁忙或錯誤添加了一條Iptables規則隔離了heartbeat傳輸等原因，未對其備份節點發出自己的心跳信息，這時CRM(cluster resource manager 專門用來收集集群資源或服務信息的集群資源管理器）發現檢測不到A的心跳信息，認為A服務器掛掉了，便把A上的所有資源轉移到了其他節點比如B上，這是B節點繼續完成A節點的任務（向文件中寫入數據），就會造成A和B同時往一個文件中寫入，便會造成文件系統的崩潰及文件錯亂。

如何避免腦裂？

在進行資源轉移之前先將原來的節點進行資源隔離：

1. 節點隔離

   Stonish設備 如 直接斷電爆頭，一發現某節點無法傳輸heartbeat直接給其斷電

2. 資源級別隔離

   FC-SAN （光纖交換機）可以實現在存儲資源隔離故障節點的訪問

如何檢測一個節點是否故障？

1. 加仲裁磁盤 主節點往一個共享磁盤中不斷寫入數據，一旦備節點發現自己可以訪問共享磁盤但未發現主節點寫入數據，則可以認為主節點掛掉，進行隔離

2. ping網關 只要能ping通網關 說明本節點正常，一旦ping不同則可以認為自己發生故障進行隔離

3. watchdog看門狗，協調同一個節點上不同進程每隔一段時間往watchdog中寫入數據，一旦寫入中斷watchdog會嘗試重啟此進程，如果重啟不了，則此節點故障，從此集群中去掉

Massaging Layer（負責以UDP協議在主節點與備節點間以組播模式傳輸heartbeat，資源黏性，資源約束，等信息），Massaging Layer 也是一個服務（UDP/694），且要讓其開機自啟動。

Cluster Resource Manager（集群的資源管理器）：專門處理統計收集群上每個資源的狀態如：資源黏性資源約束，節點是否健康;并又CRM的子件PE計算出資源現在應該運行在哪個節點上，再由CRM的子件TE指揮每個節點的LRM完成相應操作如：將服務從A節點遷移到B，在B節點上啟用VIP，文件系統.....

高可用集群節點上的服務啟動都要由CRM決定，不能讓其自啟動,所以必須#chkocnfig 服務名稱 off

PE:policy engine 策略引擎

TE：Tranaction Engine 事物引擎

LRM：location Resource Manager 本地資源管理器

PE，TE，LRM都是CRM的組成

RA：Resource Agent資源代理

所有能夠負責資源啟動、關閉、重啟、狀態監測的腳本都叫RA，RA運行在每個節點上

RA的類別

Legency heartbeat v1 RA

LSB 所有遵循linux的shell編程支持start|restart|stop|status的腳本都是LSB類型 如/etc/rc.d/init.d/目錄中的所有腳本

OCF（open cluster framework）此類腳本不但可以接受start|restart|stop|status等參數，甚至可以接受monitior（監控）等參數

DC(designated coordinator）事物協調員，DC也為CRM的子件，是在多節點中選舉出的一個節點

Messager Layer的軟件實現

1. heartbeat（v1 v2 v3 三個版本）

2. heartbeat v3 又分為heartbeat、pacemaker、cluster-glue

3. CoroSync 紅帽6.0后默認使用的Messaging Layer

4. Cman 紅帽5.0后默認使用的Messaging Layer 但由于工作在內核空間且配置復雜所以6.0后換成了工作在用戶空間的CoroSync

5. keepalived keepalived的配置與應用與前幾個相比有所不同，如對VIP的配置是基于VRRP（Virtual Router Redundancy Protocol）虛擬路由冗余協議實現的

CRM（cluster resource manager）層的軟件實現

CRM必須工作在Messaging Layer 層上

1. Haresources (heartbeat v1 v2 都有自帶）

2. CRM （heartbeat v2 自帶）

3. Pacemaker (heartbeat v3 獨立出去的項目）

4. Ragmanager (專門為Cman提供的一種crm）

所以集群的Messager Layer與CRM 組合如下：

1. haresource + heartbeat v1/v2

2. crm + heartbeat v2

3. pacemaker + corosync

4. pacemaker + heartbeat v3

5. cman + ragmanager

那么定義一個Web服務的高可用集群至少要幾個節點？要定義幾個資源？

至少需要兩個節點，上面要運行MassagerLayer 和 CRM

至少要定義四個資源 VIP 、httpd服務 、Filesystem、Stonish設備

為了避免隨便一個服務器配好資源，裝上MassagerLayer和CRM，時間再一同步就可以隨便加入我們的集群系統，該如何處理？

首先每個節點要裝Messager Layer和CRM節點之間進行heartbeat等信息傳輸時都因該采取加密傳輸（如進行hash運算），如果有兩個節點可以進行單播傳輸heartbeat信息，兩個以上節點可以進行單播、組播、廣播傳輸heartbeat信息，高級可用集群節點上的服務必須由CRM控制，所以要設置CRM自啟動而服務要用chkconfig關閉開機自啟動，而Massager Layer也是一個服務且要開機自啟動，Messager Layer監聽在UDP/694上，以UDP協議在Messager Layer層傳輸heartbeat等信息。

如果要配置一個HA集群要注意什么？

節點名稱要與uname -n的結果一致；節點名稱/IP的解析最好在/etc/hosts文件中，不要用DNS解析，否則DNS-Server掛掉會對集群造成影響；節點的時間必須同步；SSH互信通信（當要停止或其他節點的HA集群服務時，不能從此節點進行，而要從一個正常的節點進行HA服務的關閉或啟動）這是就必須要求能夠以SSH遠程登錄到其他節點。

那第一個節點怎么辦？

第一個節點要自我啟動，然后啟動其他節點上的服務。