前言：這裡是小白工作學習中對pacemaker的見解，大神可以直接繞道了，如果寫的不對的地方歡迎大神指正。對于初學的小白來說推薦一個網站，這個網站講的還是挺全的：http://clusterlabs.org/pacemaker.html

pacemaker簡介

下面我們用一張圖來簡易說明下這個到底是幹啥用的。

在硬體層面我們可以看到多個節點上啟用了不同服務，如資料庫，Apache服務等，這裡你可以看到有個standby machine，這台機器就是目前兩個服務不能在它原來的節點上運作時提供備用的。這樣能保證如果某一台機器的Apache服務或者某一台機器的資料庫服務挂了，那麼馬上在另外一個節點上能夠啟動該服務。當然首先這三個節點都是要預設安裝這些服務并且做配置的。那麼這樣看起來我們能夠通過增加節點來提供高可用解決單點故障。這也是HA要做的主要工作。

pacemaker作為linux系統高可用HA的資料總管，位于HA叢集架構中的資源管理，資源代理層，它不提供底層心跳資訊傳遞功能。(心跳資訊傳遞是通過corosync來處理的這個使用有興趣的可以在稍微了解一下，其實corosync并不是心跳代理的唯一元件，可以用hearbeat等來代替)。pacemaker管理資源是通過腳本的方式來執行的。我們可以将某個服務的管理通過shell,python等腳本語言進行處理，在多個節點上啟動相同的服務時，如果某個服務在某個節點上出現了單點故障那麼pacemaker會通過資源管理腳本來發現服務在改節點不可用。

pacemaker隻是作為HA的資料總管，是以不要想當然了解它能夠直接管控資源，如果你的資源沒有做腳本配置那麼對于pacemaker來說它就是不可管理的。

pacemaker叢集種類

pacemaker對環境沒有特定的要求，這使得它支援任何的備援配置，包括Active/Active,Active/Passive,N+1,N+M,N-to-1和N-to-N. 但是就備援性來說可以直覺地分為兩類Active/Passive HA 和Active/Active HA，其餘的隻是這兩類的變種。

Active/Passive HA：叢集隻包括兩個節點簡稱主備。在這種配置下，系統采用主和備用機器來提供服務，系統隻在主裝置上提供服務。在主裝置故障時，備裝置上的服務被啟動來替代主裝置提供的服務。典型地，可以采用 CRM 軟體比如 Pacemaker 來控制主備裝置之間的切換，并提供一個虛機 IP 來提供服務。

Active/Active HA：叢集隻包括兩個節點時簡稱雙活，包括多節點時成為多主（Multi-master）。在這種配置下，系統在叢集内所有伺服器上運作同樣的負載。以資料庫為例，對一個執行個體的更新，會被同步到所有執行個體上。這種配置下往往采用負載均衡軟體比如 HAProxy 來提供服務的虛拟 IP。

Active/Passive HA的架構：

這種方案是在多個節點（兩個或者兩個以上）構成叢集，但是目前現在就隻有一個節點的服務活動對外提供服務。如果該節點上服務故障則立馬将服務切換到備用節點。

Active/Active HA架構：

這種配置主要是對服務提供高可用和負載均衡，借助haproxy來将某個服務的業務流量平均的配置設定在多個節點上，而通過pacemaker來保證該服務至少是可用得。

pacemaker整體結構

在最高一個層次，叢集由三個部分組成：

1.提供消息和叢集關系功能的叢集核心基礎組建（标紅的部分）

2.叢集無關的元件（藍色部分）。在Pacemaker架構中，這部分不僅包含有怎麼樣啟動，關閉，監控資源的腳本，而且還有一個本地的守護程序來消除這些腳本實作的（采用的）不同标準之間的差異。

3.大腦（綠色部分）處理并響應來自叢集和資源的事件（比如節點的離開和加入，資源的失效），以及管理者對配置檔案的修改。在對所有這些事件的響應中，Pacemaker會計算叢集理想的狀态，并規劃一個途徑來實作它。這個操作可能會包含移動資源，停止節點，甚至使用遠端電源管理來強制使他們下線。

當與Corosync（實作HA心跳資訊傳輸的功能就是Corosync）內建時，Pacemaker也支援常見的開源叢集檔案系統，根據來着叢集檔案系統社群的最新标準，他們用一個通用的分布式鎖控制器，它靠Corosync通信并且用Pacemaker管理成員關系（哪些節點是開啟或關閉的）和隔離服務。

pacemaker内部元件

1.CIB（叢集資訊基礎，在記憶體中的一個xml格式叢集配置檔案）

2.CRMd（叢集資源管理守護程序,每個crmd上有一個cib用來定義維護資源， 主要是消息代理的PEngine和LRM，還選舉一個上司者（DC）統籌活動（包括啟動/停止資源）的叢集。）

3.PEngine（PE或者政策引擎）

4.STONITHd

5.ccm:cluster consensus membership service 共識叢集成員，心跳成員層。

CIB用XML來展示叢集的配置和資源的目前狀态。CIB的内容會自動地在叢集之間同步，并被PEngine用來計算叢集的理想狀态和如何達到這個理想狀态。

這個指令清單然後會被交給DC（指定協調者）。Pacemaker會推舉一個CRMd執行個體作為master來集中做出所有決策。如果推舉的CRMd繁忙中，或者這個節點不夠穩定，一個新的master會馬上被推舉出來。

DC會按順序處理PEngine的指令，然後把他們發送給LRMd（本地資源管理守護程序）或者通過叢集消息層發送給其他CRMd成員（就是把這些指令一次傳給LRMd）

節點會把他們所有操作的日志發給DC，然後根據預期的結果和實際的結果（之間的差異），執行下一個等待中的指令，或者取消操作，并讓PEngine根據非預期的結果重新計算叢集的理想狀态。

在某些情況下，可能會需要關閉節點的電源來保證共享資料的完整性是完全地恢複資源。為此Pacemaker引入了STONITHd。STONITH是Shoot-The-Other-Node-In-The-Head（爆其他節點的頭）的縮寫，并且通常是遠端電源開關來實作的。在Pacemaker中，STONITH裝置被當成資源（并且是在CIB中配置）進而輕松地監控，然而STONITHd會注意了解STONITH拓撲，比如他的用戶端請求隔離一個節點，它會重新開機那個機器。（不同的爆頭裝置驅動會對相同的請求有不同的了解，這些都是在驅動中定義的。）

lrmd：本地資源管理守護程序。它提供了一個通用的接口支援的資源類型。直接調用資源代理（腳本）。

pacemaker資源簡介

Pacemaker的資源主要有兩類，即LSB和OCF。其中LSB即linux标準服務，通常就是/etc/init.d目錄下那些腳本。Pacemaker可以用這些腳本來啟停服務。在crm ra list lsb中可以看到。另一類OCF實際上是對LSB服務的拓展，增加了一些高可用叢集管理的功能如故障監控等和更多的元資訊。可以通過crm ra list ocf 看到目前支援的資源。要讓pacemaker可以很好的對服務進行高可用保障就得實作一個OCF資源。

Pacemaker自帶的資源管理程式都在/usr/lib/ocf/resource.d下。其中的hearbeat目錄中就包含了那些自帶的常用服務。哪些服務的腳本可以作為我們自己實作時候的參考。