pacemaker

基本介紹

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

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

（1）Heartbeat

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

（2）Cluster Clue

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

（3）Resource Agent

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

（4）pacemaker

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

特色功能

1、監測并恢復節點和服務級別的故障。                                                                                                        

2、存儲無關，并不需要共享存儲。

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

4、支持節點STONITH功能以保證集群數據的完整性和防止集群腦裂。

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

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

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

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

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

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

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

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

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

11、具有統一的、腳本化的集群管理工具。

規格參數

pacemaker的服務模式

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

（1）Active/Active模式

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

（2）Active/Passive模式

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

（3）N+1模式

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

（4）N+M模式

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

（5）N-to-l模式

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

（6）N-to-N模式

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

Pacemaker的架構

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

（1）底層基礎模塊

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

（2）集群無關組件

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

（3）資源管理

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

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

Pacemake內部組件

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

CIB：集群信息基礎（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的格式來顯示集群的配置信息和集群所有資源的當前狀態信息。CIB所管理的配置信息會自動在集群節點之間進行同步，PE將會使用 CIB所提供的集群信息來規劃集群的最佳運行狀態。并根據當前 CIB信息規劃出集群應該如何控制和操作資源才能實現這個最佳狀態，在 PE做出決策之后，會緊接著發出資源操作指令，而 PE發出的指令列表最終會被轉交給集群最初選定的控制器節點（ Designated controller，DC),通常 DC便是運行 Master CRMd的節點。

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

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

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

三、Pacemaker集群管理工具pcs

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