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

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（不傾向，即一有其他可運作此服務的節點，資源就立馬轉移到其他節點）

  資源的限制：定義資源與資源的傾向性

colocation（排列限制）：定義不同資源能否運作在同一個節點上，score>0（可以），score<0（不可以） 

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

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

location（位置限制）：每個節點都可以給某資源一個score，score >0（資源傾向運作在此節點） 

score <0（資源不傾向運作在此節點）

一般資源黏性+位置限制 哪個大，資源更傾向運作在那個節點

order(順序限制）：定義資源啟動關閉時的順序，因為不同資源可能有依賴關系如：vip與ipvs規則，vip先啟動ipvs規則後啟動

資源分類

primitive 一個資源單獨隻運作在一個節點上（主資源）。

clone  每個節點上都運作此資源。

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

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節點性能一般擁有一票投票權，此時就不用節點奇數，隻要總票數為奇數便可以産生決策。

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

freeze（當機） 此非法隻處理已經連接配接的請求，不再接受新的請求，處理完請求後再進行資源轉移

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

ignore 直接忽略 繼續正常運作服務 

什麼時候會用到ignore?

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

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

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

vip 專門提供服務

fip(float ip)流動的ip,可以再節點之間轉移

mysql服務

檔案系統（要進行挂載）

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

定義個節點的資源限制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同時往一個檔案中寫入，便會造成檔案系統的崩潰及檔案錯亂。

如何避免腦裂？

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

節點隔離 

stonish裝置 如 直接斷電爆頭，一發現某節點無法傳輸heartbeat直接給其斷電

資源級别隔離

fc-san （光纖交換機）可以實作在存儲資源隔離故障節點的通路

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

加仲裁磁盤 主節點往一個共享磁盤中不斷寫入資料，一旦備節點發現自己可以通路共享磁盤但未發現主節點寫入資料，則可以認為主節點挂掉，進行隔離

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

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的軟體實作

heartbeat（v1 v2 v3 三個版本）

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

corosync 紅帽6.0後預設使用的messaging layer

cman  紅帽5.0後預設使用的messaging layer 但由于工作在核心空間且配置複雜是以6.0後換成了工作在使用者空間的corosync

keepalived keepalived的配置與應用與前幾個相比有所不同，如對vip的配置是基于vrrp（virtual router redundancy protocol）虛拟路由備援協定實作的

crm（cluster resource manager）層的軟體實作

crm必須工作在messaging layer 層上

是以叢集的messager layer與crm 組合如下：

那麼定義一個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遠端登入到其他節點。

那第一個節點怎麼辦？

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

<b>本文來自雲栖社群合作夥伴“dbgeek”</b>