Linux 高可用（HA）集羣基本概念詳解

大綱

1、高可用集羣的定義

2、高可用集羣的衡量標準

3、高可用集羣的層次結構

4、高可用集羣的分類

5、高可用集羣經常使用軟件

6、共享存儲

7、集羣文件系統與集羣LVM

8、高可用集羣的工做原理

1、高可用集羣的定義

   高可用集羣，英文原文爲High Availability Cluster，簡稱HACluster，簡單的說，集羣（cluster）就是一組計算機，它們做爲一個總體向用戶提供一組網絡資源。這些單個的計算機系統 就是集羣的節點（node）。

   高可用集羣的出現是爲了使集羣的總體服務儘量可用，從而減小由計算機硬件和軟件易錯性所帶來的損失。若是某個節點失效，它的備援節點將在幾秒鐘的時間內接管它的職責。所以，對於用戶而言，集羣永遠不會停機。

   高可用集羣軟件的主要做用就是實現故障檢查和業務切換的自動化。只有兩個節點的高可用集羣又稱爲雙機熱備，即便用兩臺服務器互相備份。當一臺服務器出現故障時，可由另外一臺服務器承擔服務任務，從而在不須要人工干預的 狀況下，自動保證系統能持續對外提供服務。雙機熱備只是高可用集羣的一種，高可用集羣系統更能夠支持兩個以上的節點，提供比雙機熱備更多、更高級的功能，更能知足用戶不斷出現的需求變化。

2、高可用集羣的衡量標準  
   HA(High Available), 高可用性羣集是經過系統的可靠性(reliability)和可維護性(maintainability)來度量的。工程上，一般用平均無端障時間(MTTF)來度量系統的可靠性,用平均維修時間（MTTR）來度量系統的可維護性。因而可用性被定義爲：HA=MTTF/(MTTF+MTTR)*100%

   具體HA衡量標準:

• 99% 一年宕機時間不超過4天

• 99.9% 一年宕機時間不超過10小時

• 99.99% 一年宕機時間不超過1小時

• 99.999% 一年宕機時間不超過6分鐘

3、高可用集羣的層次結構

   說明：高可用集羣可分爲三個層次結構，分別由紅色部分的Messaging與Membership層，藍色部分的Cluster Resource Manager（CRM）層，綠色部分的Local Resource Manager（LRM）與Resource Agent（RA）組成，下面咱們就來具體說明（如上圖），

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（主節點）上的文檔是能夠修改的，其餘CIB都是複製DC上的那個文檔而來的。對於LRM,是執行CRM傳遞過來的在本地執行某個資源的執行和中止的具體執行人。當某個節點發生故障以後，是由DC經過PE（策略引擎）和TE（實施引擎）來決定是否搶奪資源。

3.資源代理層（Resource Agents），集羣資源代理(可以管理本節點上的屬於集羣資源的某一資源的啓動，中止和狀態信息的腳本)，資源代理分爲：LSB（/etc/init.d/*）,OCF(比LSB更專業，更加通用),Legacy heartbeat（v1版本的資源管理）。

核心組件的具體說明（如上圖）：

1.ccm組件（Cluster Consensus Menbership Service）：做用，承上啓下，監聽底層接受的心跳信息，當監聽不到心跳信息的時候就從新計算整個集羣的票數和收斂狀態信息，並將結果轉遞給上層，讓上層作出決定採起怎樣的措施，ccm還可以生成一個各節點狀態的拓撲結構概覽圖，以本節點作爲視角，保證該節點在特殊狀況下可以採起對應的動做。

2.crmd組件（Cluster Resource Manager，集羣資源管理器，也就是pacemaker）：實現資源的分配，資源分配的每一個動做都要經過crm來實現，是核心組建，每一個節點上的crm都維護一個cib用來定義資源特定的屬性，哪些資源定義在同一個節點上。

3.cib組件（集羣信息基庫，Cluster Infonation Base）：是XML格式的配置文件，在內存中的一個XML格式的集羣資源的配置文件，主要保存在文件中，工做的時候常駐在內存中而且須要通知給其它節點，只有DC上的cib才能進行修改，其餘節點上的cib都是拷貝DC上。配置cib文件的方法有，基於命令行配置和基於前臺的圖形界面配置。

4.lrmd組件（Local Resource Manager，本地資源管理器）：用來獲取本地某個資源的狀態，而且實現本地資源的管理，如當檢測到對方沒有心跳信息時，來啓動本地的服務進程等。

5.pengine組件：

• PE（Policy Engine）：策略引擎，來定義資源轉移的一整套轉移方式，但只是作策略者，並不親自來參加資源轉移的過程，而是讓TE來執行本身的策略。

• TE（Transition Engine）： 就是來執行PE作出的策略的而且只有DC上才運行PE和TE。

6.stonithd組件

   STONITH(Shoot The Other Node in the Head，」爆頭「)， 這種方式直接操做電源開關，當一個節點發生故障時，另 一個節點若是能偵測到，就會經過網絡發出命令，控制故障節點的電源開關，經過暫時斷電，而又上電的方式使故障節點被重啓動， 這種方式須要硬件支持。

   STONITH應用案例（主從服務器），主服務器在某一端時間因爲服務繁忙，沒時間響應心跳信息，若是這個時候備用服務器一會兒把服務資源搶過去，可是這個時候主服務器尚未宕掉，這樣就會致使資源搶佔，就這樣用戶在主從服務器上都能訪問，若是僅僅是讀操做還沒事，要是有寫的操做，那就會致使文件系統崩潰，這樣一切都玩了，因此在資源搶佔的時候，能夠採用必定的隔離方法來實現，就是備用服務器搶佔資源的時候，直接把主服務器給STONITH，就是咱們常說的」爆頭 」。

4、高可用集羣的分類    
1.雙機熱備（Active/Passive）

官方說明：Two-node Active/Passive clusters using Pacemaker and DRBD are a cost-effective solution for many High Availability situations.

2.多節點熱備（N+1）

官方說明：By supporting many nodes, Pacemaker can dramatically reduce hardware costs by allowing several active/passive clusters to be combined and share a common backup node.

3.多節點共享存儲（N-TO-N）

官方說明：When shared storage is available, every node can potentially be used for failover. Pacemaker can even run multiple copies of services to spread out the workload.

4.共享存儲熱備 （Split Site）

官方說明：Pacemaker 1.2 will include enhancements to simplify the creation of split-site clusters.

5、高可用集羣軟件

Messaging and Membership Layer（信息與關係層）：

• heartbeat (v1,v2,v3)，heartbeat v3 分拆  heartbeat pacemaker cluster-glue

• corosync

• cman

• keepalived

• ultramokey

Cluster Resource Manager Layer（資源管理層，簡稱:CRM）：

• haresource,crm (heartbeat v1/v2)

• pacemaker (heartbeat v3/corosync)

• rgmanager (cman)

經常使用組合：

• heartbeat v2+haresource(或crm) (說明：通常經常使用於CentOS 5.X)

• heartbeat v3+pacemaker (說明：通常經常使用於CentOS 6.X)

• corosync+pacemaker (說明：如今最經常使用的組合)

• cman + rgmanager (說明：紅帽集羣套件中的組件，還包括gfs2,clvm)

• keepalived+lvs (說明：經常使用於lvs的高可用)

總結：咱們常常在技術博客中看到，heartbeat+pacemaker實現mysql高可用，或corosync+pacemaker實現mysql高可用等，有的博友會問了，咱們到底用什麼好呢？通過上面的說明你們應該有所瞭解！

6、共享存儲

   說到集羣， 咱們不得不說到，共享存儲，由於無論理是Web高可用也，Mysql高可用也好，他們的數據都是共享的就一份，全部必須放在共享存儲中，主節點能訪問，從節點也能訪問。下面咱們就簡單說一下共享存儲。

1.DAS:(Direct attached storage)直接附加存儲

說明：設備直接鏈接到主機總線上的，距離有限，並且還要從新掛載，之間有數據傳輸有延時

• RAID 陣列

• SCSI 陣列

2.NAS:(network attached storage)網絡附加存儲  
說明：文件級別的共享

• NFS

• FTP

• CIFS

3.SAN:(storage area network)存儲區域網絡  
說明：塊級別的，模擬的scsi協議

• FC光網絡（交換機的光接口超貴，一個差很少2萬，若是使用這個，代價過高）

• IPSAN（iscsi）存取快，塊級別，廉價

7、集羣文件系統與集羣LVM（集羣邏輯卷管理cLVM）

集羣文件系統：gfs二、ocfs2

集羣LVM：cLVM

注：通常用於高可用雙主模型中（以下圖）

8、高可用集羣的工做原理

說明：這裏主要以主/從節點的高可用來講明工做原理。

   主服務器和從服務器創建雙機熱備，基本上都是共享一個存儲，以mysql爲例。一般狀況下，數據庫文件掛載在主數據庫服務器上，用戶鏈接到主服務器上進行數據庫操做。當主服務器出現故障時，從服務器就會自動掛載數據庫文件，並接替主服務器的工做。用戶在未通知的狀況下，經過從數據庫鏈接到數據庫文件進行操做。等主服務器的故障修復以後，又能夠從新提供服務；

   那麼，從服務器是如何知道主服務器掛掉了呢，這就要使用必定的檢測機制，如心跳檢測，也就是說每個節點都會按期向其餘節點通知本身的心跳信息，尤爲是主服務器，若是從服務器在幾個心跳週期內（可自行設置心跳週期）尚未檢測到的話，就認爲主服務器宕掉了，而這期間在通告心跳信息固然不能使用tcp傳輸的，若是使用tcp檢測，還要通過三次握手，等手握完了，不定通過幾個心跳週期了，因此在檢測心跳信息的時候採用的是udp的端口694來進行傳遞信息的，若是主服務器在某一端時間因爲服務繁忙，沒時間響應心跳信息，這個時候從服務器要是把主服務資源搶過去（共享數據文件），可是這個時候主服務器尚未宕掉，這樣就會致使資源搶佔，就這樣用戶在主從上都能訪問，若是僅僅是讀操做還沒事，要是有寫的操做，那就會致使文件系統崩潰，這樣一切都玩了，因此在資源搶佔的時候，能夠採用必定的隔離方法來實現，就是從服務器搶佔資源的時候，直接把主服務器給「STONITH」，就是咱們常說的「爆頭」；

   那麼，咱們又用什麼方式來檢測心跳信息呢？就是經過心跳線來檢測。運行在從服務器上的Heartbeat能夠經過以太網鏈接檢測主服務器的運行狀態，一旦其沒法檢測到主服務器的「心跳」則自動接管主服務器的資源。一般狀況下，主、從服務器間的心跳鏈接是一個獨立的物理鏈接，這個鏈接能夠是串行線纜、一個由「交叉線」實現的以太網鏈接。Heartbeat甚至可同時經過多個物理鏈接檢測主服務器的工做狀態，而其只要能經過其中一個鏈接收到主服務器處於活動狀態的信息，就會認爲主服務器處於正常狀態。從實踐經驗的角度來講，建議爲Heartbeat配置多條獨立的物理連，以免Heartbeat通訊線路自己存在單點故障。

   上面的原理中咱們提到了「隔離方法」，下面咱們來講一說，隔離方法有兩種，一種是節點隔離，另外一種是資源隔離。節點隔離就是咱們常說的STONITH（Shoot The Other Node In the Head ，俗稱「爆頭」)，意思就是直接切斷電源；經常使用的方法是全部節點都接在一個電源交換機上，若是有故障，就直接致使該節點的電壓不穩定，或斷電，讓有故障的節點重啓或關閉。（以下圖），而資源隔離，就是 fencing 直接把某種資源截獲過來。

   下面咱們再來講一說「心路線」的類型，一種是串行電纜，另外一種就是咱們常看到的以太網線（交叉的雙絞線），它們各有優缺點，串行電纜，被認爲是比以太網鏈接安全性稍好些的鏈接方式，由於hacker沒法經過串行鏈接運行諸如telnet、ssh或rsh類的程序，從而能夠下降其經過已劫持的服務器再次侵入備份服務器的概率。但串行線纜受限於可用長度，所以主、備服務器的距離必須很是短。以太網線鏈接，使用此方式能夠消除串行線纜的在長度方面限制，而且能夠經過此鏈接在主從服務器之間同步文件系統，從而減小了對正常通訊鏈接帶寬的佔用。（以下圖）

參考文檔：

http://www.linux-ha.org/wiki/Main_Page

http://clusterlabs.org/wiki/Main_Page

http://opencf.org/home.html