HA - 台部落

大綱

一、高可用集羣的定義
二、高可用集羣的衡量標準
三、高可用集羣的層次結構
四、高可用集羣的分類
五、高可用集羣常用軟件
六、共享存儲
七、集羣文件系統與集羣LVM
八、高可用集羣的工作原理

一、高可用集羣的定義

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

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

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

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

具體HA衡量標準:

99% 一年宕機時間不超過4天
99.9% 一年宕機時間不超過10小時
99.99% 一年宕機時間不超過1小時
99.999% 一年宕機時間不超過6分鐘

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

說明：高可用集羣可分爲三個層次結構，分別由紅色部分的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，就是我們常說的”爆頭 ”。

四、高可用集羣的分類
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.

五、高可用集羣軟件

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高可用等，有的博友會問了，我們到底用什麼好呢？經過上面的說明大家應該有所瞭解！

六、共享存儲

說到集羣，我們不得不說到，共享存儲，因爲不管理是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）存取快，塊級別，廉價

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

集羣文件系統：gfs2、ocfs2

集羣LVM：cLVM

注：一般用於高可用雙主模型中（如下圖）

八、高可用集羣的工作原理

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

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

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

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

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

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