Linux之HA高可用叢集的基礎概念總結

 主節點（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遠端登入到其他節點。

那第一個節點怎麼辦？

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

本文出自 “11097124” 部落格

http://11107124.blog.51cto.com/11097124/1868577