基本介紹

Pacemaker是Linux環(huán)境中使用最為廣泛的開源集群資源管理器，Pacemaker利用集群基礎(chǔ)架構(gòu)(Corosync或者Heartbeat)提供的消息和集群成員管理功能，實現(xiàn)節(jié)點和資源級別的故障檢測和資源恢復，從而最大程度保證集群服務的高可用。從邏輯功能而言，pacemaker在集群管理員所定義的資源規(guī)則驅(qū)動下，負責集群中軟件服務的全生命周期管理，這種管理甚至包括整個軟件系統(tǒng)以及軟件系統(tǒng)彼此之間的交互。Pacemaker在實際應用中可以管理任何規(guī)模的集群，由于其具備強大的資源依賴模型，這使得集群管理員能夠精確描述和表達集群資源之間的關(guān)系（包括資源的順序和位置等關(guān)系）。同時，對于任何形式的軟件資源，通過為其自定義資源啟動與管理腳本（資源代理），幾乎都能作為資源對象而被Pacemaker管理。此外，需要指出的是，Pacemaker僅是資源管理器，并不提供集群心跳信息，由于任何高可用集群都必須具備心跳監(jiān)測機制，因而很多初學者總會誤以為Pacemaker本身具有心跳檢測功能，而事實上Pacemaker的心跳機制主要基于Corosync或Heartbeat來實現(xiàn)

從起源上來看，Pacemaker是為Heartbeat項目而開發(fā)的CRM項目的延續(xù)，CRM最早出現(xiàn)于2003年，是專門為 Heartbeat項目而開發(fā)的集群資源管理器，而在2005年，隨著Heartbeat2.0版本的發(fā)行才正式推出第一版本的CRM,即 Pacemaker的前身。在2007年末，CRM正式從Heartbeat2.1.3版本中獨立，之后于2008年P(guān)acemaker0.6穩(wěn)定版本正式發(fā)行，隨后的2010年3月CRM項目被終止，作為CRM項目的延續(xù)，Pacemaker被繼續(xù)開發(fā)維護，如今Pacemaker已成為開源集群資源管理器的事實標準而被廣泛使用。此外，Heartbeat到了3．0版本后已經(jīng)被拆分為幾個子項目了，這其中便包括 Pacemaker、Heartbeat3.0、Cluster Glue和Resource Agent。

（1）Heartbeat

Heartbeat項目最初的消息通信層被獨立為新的Heartbeat項目，新的Heartbeat只負責維護集群各節(jié)點的信息以及它們之間的心跳通信，通常將Pacemaker與Heartbeat或者Corosync共同組成集群管理軟件，Pacemaker利用Heartbeat或者Corosync提供的節(jié)點及節(jié)點之間的心跳信息來判斷節(jié)點狀態(tài)。

（2）Cluster Clue

Cluster Clue相當于一個中間層，它用來將Heartbeat和Pacemaker關(guān)聯(lián)起來，主要包含兩個部分，即本地資源管理器（Local Resource Manager，LRM）和Fencing設備（Shoot The Other Node In The Head，STONITH）

（3）Resource Agent

資源代理（Resource Agent，RA）是用來控制服務的啟停，監(jiān)控服務狀態(tài)的腳本集合，這些腳本會被位于本節(jié)點上的LRM調(diào)用從而實現(xiàn)各種資源的啟動、停止、監(jiān)控等操作。

（4）pacemaker

Pacemaker是整個高可用集群的控制中心，用來管理整個集群的資源狀態(tài)行為，客戶端通過pacemaker來配置、管理、監(jiān)控整個集群的運行狀態(tài)。Pacemaker是一個功能非常強大并支持眾多操作系統(tǒng)的開源集群資源管理器，Pacemaker支持主流的 Linux系統(tǒng)，如 Redhat的 RHEL系列、Fedora系列、openSUSE系列、Debian系列、Ubuntu系列和centos系列，這些操作系統(tǒng)上都可以運行Pacemaker并將其作為集群資源管理器。

特色功能

1、監(jiān)測并恢復節(jié)點和服務級別的故障。                                                                                                        

2、存儲無關(guān)，并不需要共享存儲。

3、資源無關(guān)，任何能用腳本控制的資源都可以作為集群服務。

4、支持節(jié)點STONITH功能以保證集群數(shù)據(jù)的完整性和防止集群腦裂。

5、支持大型或者小型集群。

6、支持Quorum機制和資源驅(qū)動類型的集群。

7、支持幾乎是任何類型的冗余配置。

8、自動同步各個節(jié)點的配置文件。

9、可以設定集群范圍內(nèi)的Ordering、Colocation and Anti-colocation等約束。

10、高級服務類型支持，例如：

Clone功能，即那些要在多個節(jié)點運行的服務可以通過Clone功能實現(xiàn)，Clone功能將會在多個節(jié)點上啟動相同的服務；

Multi-state功能，即那些需要運行在多狀態(tài)下的服務可以通過Multi--state實現(xiàn)，在高可用集群的服務中，有很多服務會運行在不同的高可用模式下，

如：Active/Active模式或者Active/passive模式等，并且這些服務可能會在Active與standby(Passive)之間切換。

11、具有統(tǒng)一的、腳本化的集群管理工具。

規(guī)格參數(shù)

pacemaker的服務模式

Pacemaker對用戶的環(huán)境沒有特定的要求，這使得它支持任何類型的高可用節(jié)點冗余配置，包括Active/Active、 Active/Passive、N+1、N+M、N-to-1 and N-to-N模式的高可用集群，用戶可以根據(jù)自身對業(yè)務的高可用級別要求和成本預算，通過Pacemaker部署適合自己的高可用集群。

（1）Active/Active模式

在這種模式下，故障節(jié)點上的訪問請求或自動轉(zhuǎn)到另外一個正常運行節(jié)點上，或通過負載均衡器在剩余的正常運行的節(jié)點上進行負載均衡。這種模式下集群中的節(jié)點通常部署了相同的軟件并具有相同的參數(shù)配置，同時各服務在這些節(jié)點上并行運行。

（2）Active/Passive模式

在這種模式下，每個節(jié)點上都部署有相同的服務實例，但是正常情況下只有一個節(jié)點上的服務實例處于激活狀態(tài)，只有當前活動節(jié)點發(fā)生故障后，另外的處于standby狀態(tài)的節(jié)點上的服務才會被激活，這種模式通常意味著需要部署額外的且正常情況下不承載負載的硬件。

（3）N+1模式

所謂的N+1就是多準備一個額外的備機節(jié)點，當集群中某一節(jié)點故障后該備機節(jié)點會被激活從而接管故障節(jié)點的服務。在不同節(jié)點安裝和配置有不同軟件的集群中，即集群中運行有多個服務的情況下，該備機節(jié)點應該具備接管任何故障服務的能力，而如果整個集群只運行同一個服務，則N+1模式便退變?yōu)锳ctive/Passive模式。

（4）N+M模式

在單個集群運行多種服務的情況下，N+1模式下僅有的一個故障接管節(jié)點可能無法提供充分的冗余，因此，集群需要提供M（M>l）個備機節(jié)點以保證集群在多個服務同時發(fā)生故障的情況下仍然具備高可用性，M的具體數(shù)目需要根據(jù)集群高可用性的要求和成本預算來權(quán)衡。

（5）N-to-l模式

在N-to-l模式中，允許接管服務的備機節(jié)點臨時成為活動節(jié)點（此時集群已經(jīng)沒有備機節(jié)點），但是，當故障主節(jié)點恢復并重新加人到集群后，備機節(jié)點上的服務會轉(zhuǎn)移到主節(jié)點上運行，同時該備機節(jié)點恢復standby狀態(tài)以保證集群的高可用。

（6）N-to-N模式

N-to-N是Active/Active模式和N+M模式的結(jié)合，N-to-N集群將故障節(jié)點的服務和訪問請求分散到集群其余的正常節(jié)點中，在N-to-N集群中并不需要有Standby節(jié)點的存在、但是需要所有Active的節(jié)點均有額外的剩余可用資源。

Pacemaker的架構(gòu)

從高層次的集群抽象功能來看，Pacemaker的核心架構(gòu)主要由集群不相關(guān)組件、集群資源管理組件和集群底層基礎(chǔ)模塊三個部分組成。

（1）底層基礎(chǔ)模塊

底層的基礎(chǔ)架構(gòu)模塊主要向集群提供可靠的消息通信、集群成員關(guān)系和等功能，底層基礎(chǔ)模塊主要包括像 corosync、CMAN和Heartbeat等項目組件。

（2）集群無關(guān)組件

在Pacemaker架構(gòu)中，這部分組件主要包括資源本身以及用于啟動、關(guān)閉以及監(jiān)控資源狀態(tài)的腳本，同時還包括用于屏蔽和消除實現(xiàn)這些腳本所采用的不同標準之間差異的本地進程。雖然在運行多個實例時，資源彼此之間的交互就像一個分布式的集群系統(tǒng)，但是，這些實例服務之間仍然缺乏恰當?shù)腍A機制和獨立于資源的集群治理能力，因此還需要后續(xù)集群組件的功能支持。

（3）資源管理

Pacemaker就像集群大腦，專門負責響應和處理與集群相關(guān)的事件，這些事件主要包括集群節(jié)點的加人、集群節(jié)點脫離，以及由資源故障、維護、計劃的資源相關(guān)操作所引起的資源事件，同時還包括其他的一些管理員操作事件，如對配置文件的修改和服務重啟等操作。在對所有這些事件的響應過程中，Pacemaker會計算出當前集群應該實現(xiàn)的最佳理想狀態(tài)并規(guī)劃出實現(xiàn)該理想狀態(tài)后續(xù)需要進行的各種集群操作，這些操作可能包括了資源移動、節(jié)點停止，甚至包括使用遠程電源管理模塊來強制節(jié)點下線等。

當Pacemaker與Corosync集成時，Pacemaker也支持常見的主流開源集群文件系統(tǒng)，而根據(jù)集群文件系統(tǒng)社區(qū)過去一直從事的標準化工作，社區(qū)使用了一種通用的分布式鎖管理器來實現(xiàn)集群文件系統(tǒng)的并行讀寫訪問，這種分布式鎖控制器利用了Corosync所提供的集群消息和集群成員節(jié)點處理能力（節(jié)點是在線或離線的狀態(tài)）來實現(xiàn)文件系統(tǒng)集群，同時使用Pacemaker來對服務進行隔離

Pacemake內(nèi)部組件

Pacemaker作為一個獨立的集群資源管理器項目，其本身由多個內(nèi)部組件構(gòu)成，這些內(nèi)部組件彼此之間相互通信協(xié)作并最終實現(xiàn)了集群的資源管理，Pacemaker項目由五個內(nèi)部組件構(gòu)成，各個組件之間的關(guān)系如右圖所示。

CIB：集群信息基礎(chǔ)（Cluster Information Base)。 

CRMd：集群資源管理進程（Cluster Resource Manager deamon)。

LRMd：本地資源管理進程(Local Resource Manager deamon)。

PEngine(PE)：策略引擎(PolicyEngine)。

STONITHd：集群Fencing進程（Shoot The Other Node In The Head deamon)。

CIB主要負責集群最基本的信息配置與管理，Pacemaker中的CIB主要使用XML的格式來顯示集群的配置信息和集群所有資源的當前狀態(tài)信息。CIB所管理的配置信息會自動在集群節(jié)點之間進行同步，PE將會使用 CIB所提供的集群信息來規(guī)劃集群的最佳運行狀態(tài)。并根據(jù)當前 CIB信息規(guī)劃出集群應該如何控制和操作資源才能實現(xiàn)這個最佳狀態(tài)，在 PE做出決策之后，會緊接著發(fā)出資源操作指令，而 PE發(fā)出的指令列表最終會被轉(zhuǎn)交給集群最初選定的控制器節(jié)點（ Designated controller，DC),通常 DC便是運行 Master CRMd的節(jié)點。

在集群啟動之初，pacemaker便會選擇某個節(jié)點上的CRM進程實例來作為集群Master CRMd,然后集群中的CRMd便會集中處理PE根據(jù)集群CIB信息所決策出的全部指令集。在這個過程中，如果作為Master的CRM進程出現(xiàn)故障或擁有 Master CRM進程的節(jié)點出現(xiàn)故障，則集群會馬上在其他節(jié)點上重新選擇一個新的Master CRM進程。

在PE的決策指令處理過程中，DC會按照指令請求的先后順序來處理PEngine發(fā)出的指令列表，簡單來說，DC處理指令的過程就是把指令發(fā)送給本地節(jié)點上的LRMd（當前節(jié)點上的CRMd已經(jīng)作為Master在集中控制整個集群，不會再并行處理集群指令）或者通過集群消息層將指令發(fā)送給其他節(jié)點上的CRMd進程，然后這些節(jié)點上的CRMd再將指令轉(zhuǎn)發(fā)給當前節(jié)點的 LRMd去處理。當集群節(jié)點運行完指令后，運行有CRMd進程的其他節(jié)點會把他們接收到的全部指令執(zhí)行結(jié)果以及日志返回給 DC（即DC最終會收集全部資源在運行集群指令后的結(jié)果和狀態(tài)），然后根據(jù)執(zhí)行結(jié)果的實際情況與預期的對比，從而決定當前節(jié)點是應該等待之前發(fā)起的操作執(zhí)行完成再進行下一步的操作，還是直接取消當前執(zhí)行的操作并要求PEngine根據(jù)實際執(zhí)行結(jié)果再重新規(guī)劃集群的理想狀態(tài)并發(fā)出操作指令。

在某些情況下，集群可能會要求節(jié)點關(guān)閉電源以保證共享數(shù)據(jù)和資源恢復的完整性，為此，Pacemaker引人了節(jié)點隔離機制，而隔離機制主要通過STONITH進程實現(xiàn)。STONITH是一種強制性的隔離措施，STONINH功能通常是依靠控制遠程電源開關(guān)以關(guān)閉或開啟節(jié)點來實現(xiàn)。在Pacemaker中，STONITH設備被當成資源模塊并被配置到集群信息CIB中，從而使其故障情況能夠被輕易地監(jiān)控到。同時，STONITH進程（STONITHd)能夠很好地理解STONITH設備的拓撲情況，因此，當集群管理器要隔離某個節(jié)點時，只需STONITHd的客戶端簡單地發(fā)出Fencing某個節(jié)點的請求，STONITHd就會自動完成全部剩下的工作，即配置成為集群資源的STONITH設備最終便會響應這個請求，并對節(jié)點做出Fenceing操作，而在實際使用中，根據(jù)不同廠商的服務器類型以及節(jié)點是物理機還是虛擬機，用戶需要選擇不同的STONITH設備。

三、Pacemaker集群管理工具pcs

可以用用cibadmin命令行工具來查看和管理pacemaker的集群配置信息，集群CIB中的配置信息量非常大而且以 XML語言呈現(xiàn)，對于僅由極少數(shù)節(jié)點和資源所組成的集群，cibadmin也許是個可行方案。但是，對于擁有大量節(jié)點和資源的大規(guī)模集群，通過編輯XML文件來查看修改集群配置顯然是非常艱難而且極為不現(xiàn)實的工作由于XML文件內(nèi)容條目極多，因此用戶在修改XML文件的過程中極易出現(xiàn)人為錯誤。而在開源社區(qū)里，簡單實用才是真正開源精神的體現(xiàn)，對于開源系統(tǒng)中任何文件配置參數(shù)的修改，簡化統(tǒng)一的命令行工具才是最終的歸宿。