基本介紹

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

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

（1）Heartbeat

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

（2）Cluster Clue

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

（3）Resource Agent

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

（4）pacemaker

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

特色功能

1、監(jiān)測(cè)并恢復(fù)節(jié)點(diǎn)和服務(wù)級(jí)別的故障。                                                                                                        

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

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

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

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

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

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

8、自動(dòng)同步各個(gè)節(jié)點(diǎn)的配置文件。

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

10、高級(jí)服務(wù)類型支持，例如：

Clone功能，即那些要在多個(gè)節(jié)點(diǎn)運(yùn)行的服務(wù)可以通過Clone功能實(shí)現(xiàn)，Clone功能將會(huì)在多個(gè)節(jié)點(diǎn)上啟動(dòng)相同的服務(wù)；

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

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

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

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

pacemaker的服務(wù)模式

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

（1）Active/Active模式

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

（2）Active/Passive模式

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

（3）N+1模式

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

（4）N+M模式

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

（5）N-to-l模式

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

（6）N-to-N模式

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

Pacemaker的架構(gòu)

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

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

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

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

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

（3）資源管理

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

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

Pacemake內(nèi)部組件

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

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

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

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

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

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

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

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

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

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

三、Pacemaker集群管理工具pcs

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