前言:

   該文章耗費作者大量時間,轉載宣告轉http://anyisalin.blog.51cto.com/

為什麼要提供一個服務的高可用?

   高可用(High Available)顧名思義是提高一個服務的可用性,在生產環境當中,如果對外提供服務的主機出現故障是致命的,可能會造成很大損失,我們需要提供一個解決方案,在伺服器出現故障時能迅速將伺服器上執行的服務轉移到其他備用的節點,並讓其繼續執行對外提供服務.

服務高可用該如何實現？

在實現服務高可用的時候有許許多多的問題需要,例如備用節點如何知道主節點出現故障？、備用節點如何接管資源?、如果主節點沒故障,備用節點認為其故障而強制接管其資源怎麼辦？諸多問題需要解決.那麼我們到底該怎麼實現高可用叢集呢？我們需要了解一些關於高可用叢集的原理.

實現原理
    在高可用叢集的各節點中定義了一個抽象層,資訊傳遞層(Messaing Layer),用來傳遞叢集之間的事務(Transaction)資訊.事務資訊中包含了節點的心跳資訊(是否線上),節點的主機名、IP等一系列資訊.當然光有Messaging Layer並不能實現一個叢集的高可用.這裡我們介紹一個概念

一個服務要是想實現高可用需要兩個條件:

Messaging Layer

 實現Messaging Layer的軟體有很多,例如corosync,heartbeat...

ha-aware/CRM

 ha-aware: 是指一個服務本身具備高可用能力,能夠通過API呼叫Messaging Layer傳遞的資訊來提供高可用

 CRM: 全稱Cluster Resource Manager,叢集資源管理.能夠通過Messaging Layer傳遞的資訊,對叢集中各節點的資源進行相應處理

CRM需要在叢集各節點中選舉出DC(Designated Coordinator)指定調解員對叢集上的資源進行計算,計算出資源更適合執行在哪個節點中.

   DC中又包含兩個引擎來處理不同的事情

    PE: Policy Engine  用來計算

    TE: Transaction Engine 用來指揮資源的轉移

     TE通過指揮LRM(Local Resource Manager)來實現資源轉移

      FailOver: 故障轉移,執行資源的節點出現故障時將資源轉移到其他節點

      FailBack: 轉回,節點重新上線後將原來的資源轉回

資源:

資源是執行在叢集上的服務,IP等一系列可以被CRM所管理的,能夠在節點出現故障時收到LRM的指令做出相應的動作

例如: 我們要提供一個httpd服務的高可用需要的資源:      VIP: 對外提供服務的IP地址

     httpd: httpd服務

但是資源應該在那個節點中執行,是否能夠執行在某個節點上都是通過Resource Constraint來定義的

Constraint: 資源約束分為三個類別

    Location: 位置約束

     使用分數來定義資源是否傾向於執行在此節點上

        INF: 傾向於執行在此節點

        -INF: 不傾向於執行在此節點

    Colocation: 排列約束

     使用分數來定義資源是否能夠同時執行在一個節點上

        INF: 能夠同時執行在一個節點上

         -INF: 不能同時執行在同一節點上

   Order: 順序約束

     定義資源啟動|關閉的順序

  如果主節點出現故障,備用節點接管其資源來提供服務,一段時間後,主節點重新上線,那麼叢集資源是否會重新回到主節點,這裡我們就要解釋一下Resource Stickiness

Resource Stickiness: 資源粘性,定義一個資源是否傾向於留在此節點.

  相信大家都瞭解,位置約束是定義資源是否傾向執行在此節點,那麼當同時定義了資源粘性和資源約束的時候,資源到底應該執行在哪個節點上呢,我們來看一個案例

  例子: 

    節點: node1.anyisalin.com,node2.anyisalin.com

    節點資源: httpd 

    預設資源粘性為100,httpd對node1的位置約束的分數值為INF,對node2的位置約束的分數值為200

    原本httpd服務執行在node1上,有一天node1突然出現了故障,資源理所應當轉移到node2上,運行了一段時間之後,node1重新上線,我們來計算一下httpd服務到底應該執行在哪個節點

RA: Resource Agent資源代理,其實就是定義成叢集資源的指令碼,能夠LRM的傳送的指令來實現對叢集資源的管理

RG: Resource group資源組,若干個叢集資源組成的組,同進同退

RA Classes:

LSB: Linux Standard Base

    /etc/init.d/下的所有指令碼就是LSB標準的,至少支援statr,status,restart,stop四個指令

OCF: Open CLuster Framework

    一個支援更多指令的標準,更加的靈活

Resources Classes:

Primitive: 

    主資源型別,同一時刻叢集中只能有一個節點執行主資源

Clone:

    克隆,將主資源克隆,同一時刻必須執行在指定的節點上

Group:

    組,將若干個主資源歸類為組,當成一個單位同進同退

Master/Slave:

    特殊的Clone資源,只能執行兩份,一個節點為主節點,一個節點為備份節點

資源隔離:

什麼時候需要資源隔離？

   當叢集節點無法有效獲取其他節點資訊,以至於搶佔資源

    嚴重後果: 搶佔儲存資源,導致分割槽崩潰

    解決方案: 資源隔離

資源隔離:

節點級別: 

    STONITH: 使用STONITH裝置強制關閉|重啟節點

資源級別: 

    使用FC交換機,實現在儲存資源級別隔離節點訪問

我們可能還需要考慮一種情況,在節點發生故障時候,不能獲取其他節點資訊,節點是如何得知到底是自己出現故障,還是其他節點故障？

這裡我們可以使用ping node,或者仲裁磁碟來解決了.

ping node: 當節點不能獲取另一個節點資訊時,ping提供的第三方節點,如果能ping通,fence另一個節點

仲裁磁碟: 叢集中各節點在執行的時候,同時向同一共享儲存中寫入資料,當某節點不能獲取另一個節點資訊時,檢視仲裁磁碟另一個節點是否還在寫入資料,如果沒有,fence另一個節點

在一些特定場景,我們在高可用叢集中可能要使用多於2個的節點,那麼我們需要考慮更多問題了

一個節點出現故障該如何判定自己應該自殺還是fence其他節點？

quorum: 法定票數

多節點叢集中,每一個節點都具有相應的法定票數

node1 不能獲取其他節點資訊

node2 <--> node3 node2和node3能夠獲取對方資訊

假定每個節點的票數都為1票

node2+node3 > 3/2 node1應該根據資源策略才做出相應動作

資源策略: Without_quorum_Policy 不具有法定票數

freeze: 不再接受新的請求,已連線的不便

stop: 停止叢集服務

ignore: 忽略,繼續執行叢集服務