Pacemaker詳解一、前言二、 Pacemaker概述 三、Pacemaker叢集管理工具pcs 四、Pacemaker叢集資源管理 1、叢集資源代理

一、前言

　　雲計算與叢集系統密不可分，作為分布式計算和叢集計算的集大成者，雲計算的基礎設施必須通過叢集進行管理控制，而作為擁有大量資源與節點的叢集，必須具備一個強大的叢集資料總管（Cluster system Manager, CSM)來排程和管理叢集資源。對于任何叢集而言，叢集資料總管是整個叢集能夠正常運轉的大腦和靈魂，任何叢集資料總管的缺失和故障都會導緻叢集陷人癱瘓混亂的狀态。 Openstack的衆多元件服務既可以內建到單個節點上運作，也可以在叢集中分布式運作。但是，要實作承載業務系統的高可用叢集， Openstack服務必須部署到高可用叢集上，并在實作 Openstack服務無單點故障的同時，實作故障的自動轉移和自我愈合，而這些功能是 Openstack的多數服務本身所不具備的。是以，在生産環境中部署 OpenStack高可用叢集時，必須引人第三方叢集資源管理軟體，專門負責 Openstack叢集資源的高可用監控排程與管理。

　　叢集資源管理軟體種類衆多，并有商業軟體與開源軟體之分。在傳統業務系統的高可用架構中，商業叢集管理軟體的使用非常普遍，如 IBM的叢集系統管理器、 PowerHA SystemMirror（也稱為 HACMP)以及針對 DB2的 purescale資料庫叢集軟體；再如orcale的 Solaris Cluster系列叢集管理軟體，以及 oracle資料庫的 ASM和 RAC叢集管理軟體等商業高可用叢集軟體都在市場上占有很大的比例。此外，随着開源社群的發展和開源生态系統的擴大，很多商業叢集軟體也正在朝着開源的方向發展，如IBM開源的 xCAT集軟體，而在 Linux開源領域Pacemaker/Corosync、 HAproxy/Keepalived等組合的叢集資源管理軟體，也有着極為廣泛的應用。

二、 Pacemaker概述

1、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并将其作為叢集資料總管。

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)具有統一的腳本化的叢集管理工具。

2、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的節點均有額外的剩餘可用資源。

3、Pacemaker的架構

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

​（1）底層基礎子產品

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

（2）叢集無關元件

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

（3）資源管理

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

　　當Pacemaker與Corosync內建時， Pacemaker也支援常見的主流開源叢集檔案系統，而根據叢集檔案系統社群過去一直從事的标準化工作，社群使用了一種通用的分布式鎖管理器來實作叢集檔案系統的并行讀寫通路，這種分布式鎖控制器利用了Corosync所提供的叢集消息和叢集成員節點處理能力（節點是線上或離線的狀态）來實作檔案系統叢集，同時使用Pacemaker來對服務進行隔離。

4、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檔案的過程中極易出現人為錯誤。而在開源社群裡，簡單實用才是真正開源精神的展現，對于開源系統中任何檔案配置參數的修改，簡化統一的指令行工具才是最終的歸宿。

　　随着開源叢集軟體Pacemaker版本的不斷更新，社群推出了兩個常用的叢集管理指令行工具，即叢集管理者最為常用的 pcs和 crmsh指令。本文使用的是 pcs指令行工具，關于 crmsh的更多使用方法和手冊可以參考Pacemaker的官方網站。在 pacemaker叢集中PCS指令行工具幾乎可以實作叢集管理的各種功能，例如，全部受控的 pacemaker和配置屬性的變更管理都可以通過 pcs實作。此外，需要注意的是， pcs指令行的使用對系統中安裝的 pacemaker和 corosync軟體版本有一定要求，即 Pacemaker1.1.8及其以上版本， Corosync 2.0及其以上版本才能使用 pcs指令行工具進行叢集管理。 pcs指令可以管理的叢集對象類别和具體使用方式可以通過pcs --help參數檢視：

[[email protected] ~]# pcs --help

Usage: pcs [-f file] [-h] [commands]... Control and configure pacemaker and corosync.

Options: 

    -h, --help Display usage and exit. 

    -f file Perform actions on file instead of active CIB. 

    --debug Print all network traffic and external commands run. 

    --version Print pcs version information. 

    --request-timeout Timeout for each outgoing request to another node in seconds.Default is 60s.

Commands:

    cluster   Configure cluster options and nodes. 

    resource   Manage cluster resources. 

    stonith   Manage fence devices.

    constraint   Manage resource constraints.

    property   Manage pacemaker properties. 

    acl   Manage pacemaker access control lists.

    qdevice   Manage quorum device provider on the local host. 

    quorum   Manage cluster quorum settings. 

    booth   Manage booth (cluster ticket manager). 

    status   View cluster status. 

    config   View and manage cluster configuration. 

    pcsd   Manage pcs daemon.

    node   Manage cluster nodes. 

    alert  Manage pacemaker alerts.

 最為常用的管理指令有：

cluster        配置叢集選項和節點

status         檢視目前叢集資源和節點以及程序狀态

resource     建立和管理叢集資源

constraint   管理叢集資源限制和限制

property     管理叢集節點和資源屬性

config         以使用者可讀格式顯示完整叢集配置資訊

四、Pacemaker叢集資源管理

1、叢集資源代理

　　在 pacemaker高可用叢集中，資源就是叢集所維護的高可用服務對象。根據使用者的配置，資源有不同的種類，其中最為簡單的資源是原始資源(primitive Resource)，此外還有相對進階和複雜的資源組(Resource Group)和克隆資源(Clone Resource)等叢集資源概念。在 Pacemaker叢集中，每一個原始資源都有一個資源代理(Resource Agent, RA)，RA是一個與資源相關的外部腳本程式，該程式抽象了資源本身所提供的服務并向叢集呈現一緻的視圖以供叢集對該資源進行操作控制。通過 RA，幾乎任何應用程式都可以成為 Pacemaker叢集的資源，進而被叢集資料總管控制。RA的存在使得叢集資料總管可以對其所管理的資源“不求甚解”，即叢集資料總管無需知道資源具體的工作邏輯和原理（ RA已将其封裝），資料總管隻需向RA發出 start、 stop、Monitor等指令， RA便會執行相應的操作。從資料總管對資源的控制過程來看，叢集對資源的管理完全依賴于該資源所提供的，即資源的 RA腳本功能直接決定了資料總管可以對該資源進行何種控制，是以一個功能完善的 RA在發行之前必須經過充分的功能測試。在多數情況下，資源 RA以 shell腳本的形式提供，當然也可以使用其他比較流行的如 c、 python、 perl等語言來實作 RA。

　　在 pacemaker叢集中，資料總管支援不同種類的資源代理，這些受支援的資源代理包括 OCF、LSB、 Upstart、 systemd、 service、 Fencing、 Nagios Plugins，而在 Linux系統中，最為常見的有 OCF(Open Cluster Framework)資源代理、 LSB（ Linux standard Base)資源代理、systemd和 service資源代理。

（1） OCF

　　OCF是開放式叢集架構的簡稱，從本質上來看OCF标準其實是對LSB标準約定中 init腳本的一種延伸和擴充。 OCF标準支援參數傳遞、自我功能描述以及可擴充性，此外，OCF标準還嚴格定義了操作執行後的傳回代碼，叢集資料總管将會根據資源代理傳回的執行代碼來對執行結果做出判斷。是以，如果OCF腳本錯誤地提供了與操作結果不比對的傳回代碼，則執行操作後的叢集資源行為可能會變得莫名其妙，而對于不熟悉OCF腳本的使用者，這将會是個非常困惑和不解的問題，尤其是當叢集依賴于OCF傳回代碼來在資源的完全停止狀态、錯誤狀态和不确定狀态之間進行判斷的時候。是以，在OCF腳本發行使用之前一定要經過充分的功能測試，否則有問題的OCF腳本将會擾亂整個叢集的資源管理。在Pacemaker叢集中，OCF作為一種可以自我描述和高度靈活的行業标準，其已經成為使用最多的資源類别。

（2） LSB

　　LSB是最為傳統的 Linux“資源标準之一，例如在 Redhat的 RHEL6及其以下版本中（或者對應的 centos版本中），經常在/etc/init.d目錄下看到的資源啟動腳本便是LSB标準的資源控制腳本。通常，LSB類型的腳本是由作業系統的發行版本提供的，而為了讓叢集能夠使用這些腳本，它們必須遵循 LSB的規定， LSB類型的資源是可以配置為系統啟動時自動啟動的，但是如果需要通過叢集資料總管來控制這些資源，則不能将其配置為自動啟動，而是由叢集根據政策來自行啟動。

（3） Systemd

　　在很多 Linux的最新發行版本中， systemd被用以替換傳統“sysv"風格的系統啟動初始化程序和腳本，如在 Redhat的 RHEL7和對應的 centos7作業系統中，systemd已經完全替代了 sysvinit啟動系統，同時 systemd提供了與 sysvinit以及 LSB風格腳本相容的特性，是以老舊系統中已經存在的服務和程序無需修改便可使用 systemd在 systemd中，服務不再是/etc/init.d目錄下的 shell腳本，而是一個單元檔案（ unit-file），Systemd通過單元檔案來啟停和控制服務， Pacemaker提供了管理 Systemd類型的應用服務的功能。

（4） Service

　　Service是 Pacemaker支援的一種特别的服務别名，由于系統中存在各種類型的服務（如 LSB、 Systemd和 OCF)，Pacemaker使用服務别名的方式自動識别在指定的叢集節點上應該使用哪一種類型的服務。當一個叢集中混合有 Systemd、 LSB和 OCF類型資源的時候，Service類型的資源代理别名就變得非常有用，例如在存在多種資源類别的情況下，Pacemaker将會自動按照 LSB、 Systemd、 Upstart的順序來查找啟動資源的腳本。在 pacemaker中，每個資源都具有屬性，資源屬性決定了該資源 RA腳本的位置，以及該資源隸屬于哪種資源标準。例如，在某些情況下，使用者可能會在同一系統中安裝不同版本或者不同來源的同一服務（如相同的 RabbitMQ Cluster安裝程式可能來自 RabbitMQ官方社群也可能來自 Redhat提供的 RabbitMQ安裝包），在這個時候，就會存在同一服務對應多個版本資源的情況，為了區分不同來源的資源，就需要在定義叢集資源的時候通過資源屬性來指定具體使用哪個資源。在 pacemaker叢集中，資源屬性由以下幾個部分構成。

Resource_id：使用者定義的資源名稱。

Standard：腳本遵循的标準，允許值為OCF、Service、Upstart、Systemd、LSB、Stonith。

Type：資源代理的名稱，如常見的IPaddr便是資源的。

Provider：OCF規範允許多個供應商提供同一資源代理，Provider即是指資源腳本的提供者，多數OCF規範提供的資源代均使用Heartbeat作為Provider。

例如在叢集中建立一個名稱為VirtualIP：

Resource_id Standard：Provider：Type

pcs resource create VirtualIP ocf:heartbeat:IPaddr2 ip=192.168.0.99 nic=eth2

常用的指令方法：

pcs resource list    檢視叢集中所有可用資源清單

pcs resource standards 檢視支援的資源代理标準

pcs resource providers 檢視叢集中可用資源代理提供程式清單

pcs resource describe Standard:Provider:Type  檢視Standard：Provider：Type指定的資源代理的詳細資訊。

pcs resource  cleanup resource_id 重置資源狀态

1、檢視http的資源代理

[[email protected] ~]# pcs resource list |grep http service:httpd - systemd unit file for httpd systemd:httpd - systemd unit file for httpd 

2、檢視怎麼建立http資源

 [[email protected] ~]# pcs resource describe systemd:httpd systemd:httpd - systemd unit file for httpd Cluster Controlled httpd Default operations: start: interval=0s timeout=100 stop: interval=0s timeout=100 monitor: interval=60 timeout=100

3、建立http資源

 [[email protected] ~]# pcs resource create http systemd:httpd

2、叢集資源限制

　　叢集是由衆多具有特定功能的資源組成的集合，叢集中的每個資源都可以對外提供獨立服務，但是資源彼此之間存在依賴與被依賴的關系。如資源B的啟動必須依賴資源A的存在，是以資源A必須在資源B之前啟動，再如資源A必須與資源B位于同一節點以共享某些服務，則資源 B與 A在故障切換時必須作為一個邏輯整體而同時遷移到其他節點，在 pacemaker中，資源之間的這種關系通過資源限制或限制（ Resource constraint)來實作。 pacemaker叢集中的資源限制可以分為以下幾類:

        位置限制(Location)：位置限制限定了資源應該在哪個叢集節點上啟動運作。

        順序限制(Order)：順序限制限定了資源之間的啟動順序。

        資源捆綁限制(Colocation)：捆綁限制将不同的資源捆綁在一起作為一個邏輯整體，即資源 A位于 c節點，則資源 B也必須位于 c節點，并且資源 A、 B将會同時進 行故障切換到相同的節點上。

　　在資源配置中， Location限制在限定運作資源的節點時非常有用，例如在 Openstack高可用叢集配置中，我們希望 Nova-ompute資源僅運作在計算節點上，而nova-api和 Neutron-sever等資源僅運作在控制節點上，這時便可通過資源的Location限制來實作。例如，我們先給每一個節點設定不同的 osprole屬性（屬性名稱可自定義），計算節點中該值設為 compute，控制節點中該值設為 controller，如下：

pcs property set --node computel Osprole=compute

pcs property set --node computel osprole=compute

pcs property set --node controller1 osprole=controller

pcs property set --node controller2 osprole=controller

pcs property set --node controller3 osprole=controller

然後，通過為資源設定 Location限制，便可将 Nova-compute資源僅限制在計算節點上運作，Location限制的設定指令如下：

pcs constraint location nova-compute-clone rule resource-discovery=exclusive score=0 osprole eq compute

即資源 Nova-compute-clone僅會在 osprole等于 compute的節點上運作，也即計算節點上運作。

　　在 pacemaker叢集中，order限制主要用來解決資源的啟動依賴關系，資源啟動依賴在Linux系統中非常普遍。例如在Openstack高可用叢集配置中，需要先啟動基礎服務如 RabbitMQ和 MySQL等，才能啟動 Openstack的核心服務，因為這些服務都需要使用消息隊列和資料庫服務；再如在網絡服務 Neutron中，必須先啟動Neutron-server服務，才能啟動Neutron的其他 Agent服務，因為這些 Agent在啟動時均會到 Neutron-sever中進行服務注冊。 Pacemaker叢集中解決資源啟動依賴的方案便是 order限制。例如，在 openstack的網絡服務 Neutron配置中，與 Neutron相關的資源啟動順序應該如下：Keystone-->Neutron-server-->Neutron-ovs-cleanup-->Neutron-netns-cleanup-->Neutron-openvswitch-agent-->Neutron-dncp-agent-->Neutron-l3-agent。上述依賴關系可以通過如下Order限制實作：

pcs constraint order start keystone-clone then neutron-server-api-clone

pcs constraint order start neutron-server-api-clone then neutron-ovs-cleanup-clone

pcs constraint order start neutron-ovs-cleanup-clone then Neutron-netns-cleanup-clone

pcs constraint order start Neutron-netns-cleanup-clonethen Neutron-openvswitch-agent-clone

pcs constraint order start Neutron-openvswitch-agent-clone then Neutron-dncp-agent-clone

pcs constraint order start Neutron-dncp-agent-clone then Neutron-l3-agent-clone

　　Colocation限制主要用于根據資源 A的節點位置來決定資源 B的位置，即在啟動資源 B的時候，會依賴資源 A的節點位置。例如将資源 A與資源 B進行 Colocation限制，假設資源A已經運作在 node1上，則資源 B也會在node1上啟動，而如果node1故障，則資源B與 A會同時切換到node2而不是其中某個資源切換到 node3。在 Openstack高可用叢集配置中，通常需要将 Libvirtd-compute與 Neutron-openvswitch-agent進行資源捆綁，要将 Nova-compute與 Libvirtd-compute進行資源捆綁，則 Colocation限制的配置如下：

pcs constraint colocation add nova-compute-clone with libvirtd-compute-clone

pcs constraint colocation add libvirtd-compute-clone with neutron-openvswitch-agent-compute-clone

　　Location限制、 Order限制和 Colocation限制是 Pacemaker叢集中最為重要的三個限制通過這幾個資源限制設定，叢集中看起來彼此獨立的資源就會按照預先設定有序運作。

3、叢集資源類型

　　在 Pacemaker叢集中，各種功能服務通常被配置為叢集資源，進而接受資料總管的排程與控制，資源是叢集管理的最小機關對象。在叢集資源配置中，由于不同高可用模式的需求，資源通常被配置為不同的運作模式，例如 Active/Active模式、 Active/Passive模式以及 Master/Master模式和 Master/Slave模式，而這些不同資源模式的配置均需要使用 Pacemaker提供的進階資源類型，這些資源類型包括資源組、資源克隆和資源多狀态等。

（1）資源組

　　在Pacemaker叢集中，經常需要将多個資源作為一個資源組進行統一操作，例如将多個相關資源全部位于某個節點或者同時切換到另外的節點，并且要求這些資源按照一定的先後順序啟動，然後以相反的順序停止，為了簡化同時對多個資源進行配置，供了進階資源類型一資源組。通過資源組，使用者便可并行配置多個資源，資源組的建立很簡單，其文法格式如下：

pcs resource group add group_name resource_id  ... [resource_id] [--before resource_id] --after resource_id

　　使用該指令建立資源組時，如果指定的資源組目前不存在，則此指令會建立一個資源組，如果指定的資源組已經存在，則此指令會将指定的資源添加到該資源組中并且組中的資源會按照該指令中出現的先位置順序啟動，并以相反的順序停止。在該指令中，還可使用--before和--after參數指定所添加的資源與組中已有資源的相對啟動順序。在為資源組添加資源時，不僅可以将已有資源添加到組中，還可以在建立資源的同時順便将其添加到指定的資源組中，指令文法如下：

pcs resource create resource_id Standard:Provider:Type丨 type [ resource_options] [op operation_action operation_options] --group group_name

如下是資源組操作中經常使用的指令文法：

将資源從組中删除，如果該組中沒有資源，這個指令會将該組删除：

pcs resource group remove group_name resource_id ...

檢視目前巳經配置的資源組：

pcs resource group list

建立名為Mygroup的資源組，并添加資源 IPaddr和 HAproxy：

pcs resource group add MyGroup IPaddr HAproxy

在 Pacemaker叢集中，資源組所包含的資源數目是不受限的，資源組中的資源具有如下的基本特性：

　　資源按照其指定的先後順序啟動，如在前面示例的 MyGroup資源組中，首先啟動 IPaddr，然後啟動 HAproxy。

　　資源按照其指定順序的相反順序停止，如首先停止 HAproxy，然後停止 IPaddr

　　如果資源組中的某個資源無法在任何節點啟動運作，那麼在該資源後指定的任何資源都将無法運作，如 IPaddr不能啟動，則 HAproxy也不能啟動。

　　資源組中後指定資源不影響前指定資源的運作，如 HAproxy不能運作，但IPaddr卻可以正常運作。

　　在叢集資源配置過程中，随着資源組成員的增加，叢集資源的配置工作将會明顯減少，因為管理者隻需要添加資源到資源組中，然後便可對資源組進行整體操作。資源組具有組屬性，并且資源組會繼承組成員的部分屬性，主要被繼承的資源屬性包括 Priority、Targct-role、Is-managed等，資源屬性決定了資源在叢集中的行為規範，以及資料總管可以對其進行哪些操作，是以，了解資源的常見屬性也是非常有必要的，如下是資源屬性中比較重要的幾個屬性解釋及其預設值。

　　　　Priority：資源優先級，其預設值是0，如果叢集無法保證所有資源都處于運作狀态，則低優先權資源會被停止，以便讓高優先權資源保持運作狀态。　　　　

　　　　Target-role：資源目标角色，其預設值是started'表示叢集應該讓這個資源處于何種狀态，允許值為：

　　　　　　Stopped：表示強制資源停止；

　　　　　　Started：表示允許資源啟動，但是在多狀态資源的情況下不能将其提升為 Master資源；

　　　　　　Master：允許資源啟動，并在适當時将其提升為 Master。

　　　　is-managed：其預設值是true，表示是否允許叢集啟動和停止該資源，false表示不允許。

 　　　 Resource-stickiness：預設值是0，表示該資源保留在原有位置節點的傾向程度值。

　　　　Requires：預設值為 fencing，表示資源在什麼條件下允許啟動。　　　　

（2）資源克隆

　　克隆資源是Pacemaker叢集中的進階資源類型之一，通過資源克隆，叢集管理者可以将資源克隆到多個節點上并在啟動時使其并行運作在這些節點上，例如可以通過資源克隆的形式在叢集中的多個節點上運作備援IP資源執行個體，并在多個處于 Active狀态的資源之間實作負載均衡。通常而言，凡是其資源代理支援克隆功能的資源都可以實作資源克隆，但需要注意的是，隻有己經規劃為可以運作在Active/Active高可用模式的資源才能在叢集中配置為克隆資源。配置克隆資源很簡單，通常在建立資源的過程中同時對其進行資源克隆，克隆後的資源将會在叢集中的全部節點上存在，并且克隆後的資源會自動在其後添加名為 clone的字尾并形成新的資源 ID，資源建立并克隆資源的文法如下：

pcs resource create resource_id standard:provider: type| type [resource options] --clone[meta clone_options]

　　克隆後的資源 ID不再是文法中指定的 Resource_id,而是 Resource_id-clone并且該資源會在叢集全部節點中存在。在 Pacemaker叢集中，資源組也可以被克隆，但是資源組克隆不能由單一指令完成，必須先建立資源組然後再對資源組進行克隆，資源組克隆的指令文法如下：

pcs resource clone resource_id group_name [clone_optione] ...

克隆後資源的名稱為 Resource_id-clone或 Group_name-clone在資源克隆指令中，可以指定資源克隆選項(clone_options)，如下是常用的資源克隆選項及其意義。

Priority/Target-role/ls-manage：這三個克隆資源屬性是從被克隆的資源中繼承而來的，具體意義可以參考上一節中的資源屬性解釋。　　　　

Clone-max：該選項值表示需要存在多少資源副本才能啟動資源，預設為該叢集中的節點數。　　　　

Clone-node-max：表示在單一節點上能夠啟動多少個資源副本，預設值為1。　　　　 

Notify：表示在停止或啟動克隆資源副本時，是否在開始操作前和操作完成後告知其他所有資源副本，允許值為 False和 True，預設值為 False。　　　　

Globally-unique：表示是否允許每個克隆副本資源執行不同的功能，允許值為 False和 True。如果其值為 False,則不管這些克隆副本資源運作在何處，它們的行為都是完全和同的，是以每個節點中有且僅有一個克隆副本資源處于 Active狀态。其值為 True,則運作在某個節點上的多個資源副本執行個體或者不同節點上的多個副本執行個體完全不一樣。如果Clone-node-max取值大于1，即一個節點上運作多個資源副本，那麼 Globally-unique的預設值為 True，否則為 False。

Ordered：表示是否順序啟動位于不同節點上的資源副本，“。為順序啟動，、為并行啟動，預設值是 False。

Interleave：該屬性值主要用于改變克隆資源或者 Masters資源之間的 ordering限制行為， Interleave可能的值為 True和 False,如果其值為 False,則位于相同節點上的後一個克隆資源的啟動或者停止操作需要等待前一個克隆資源啟動或者停止完成才能進行，而如果其值為 True,則後一個克隆資源不用等待前一個克隆資源啟動或者停止完成便可進行啟動或者停止操作。 Interleave的預設值為 False。

　　在通常情況下，克隆資源會在叢集中的每個線上節點上都存在一個副本，即資源副本數目與叢集節點數目相等，但是，叢集管理者可以通過資源克隆選項Clone-max将資源副本數目設為小于叢集節點數目，如果通過設定使得資源副本數目小于節點數目，則需要通過資源位置限制（ Location Constraint)将資源副本指定到相應的節點上，設定克隆資源的位置限制與設定正常資源的位置限制類似。例如要将克隆資源 Web-clone限制在 node1節點上運作，則指令文法如下：

pcs constraint location web-clone prefers node1

（3）資源多态

　　多狀态資源是 Pacemaker叢集中實作資源 Master/Master或 Master/S1ave高可用模式的機制，并且多态資源是一種特殊的克隆資源，多狀态資源機制允許資源執行個體在同一時刻僅處于 Master狀态或者Slave狀态。多狀态資源的建立隻需在普通資源建立的過程中指定一 Master參數即可，Master/Slave多狀态類型資源的建立指令文法如下：

pcs resource create resource_id standard：provider: type| type [resource options] --master [meta master_options]

　　多狀态資源是一種特殊的克隆資源，預設情況下，多狀态資源建立後也會在叢集的全部節點中存在，多狀态資源建立後在叢集中的資源名稱形如 Resource_id-master。需要指出的是，在 Master/Slave高可用模式下，盡管在叢集中僅有一個節點上的資源會處于 Master狀态，其他節點上均為 Slave狀态，但是全部節點上的資源在啟動之初均為 Slave狀态，之後資料總管會選擇将某個節點的資源提升為 Master。另外，使用者還可以将已經存在的資源或資源組建立為多狀态資源，指令文法如下：

pcs resource master master/slave_name resource_id group_name [master_options]

在多狀态資源的建立過程中，可以通過Master選項（ Master_options)來設定多狀态資源的屬性，Master_options主要有以下兩種屬性值：　　　　

　　Master-max：其值表示可将多少個資源副本由Slave狀态提升至 Master狀态，預設值為1，即僅有一個 Master。　　　　

　　Master-node-max：其值表示在同一節點中可将多少資源副本提升至Master狀态，預設值為1。

　　在通常情況下，多狀态資源預設會在每個線上的叢集節點中配置設定一個資源副本，如果希望資源副本數目少于節點數目，則可通過資源的Location限制指定運作資源副本的叢集節點，多狀态資源的Location限制在實作的指令文法上與正常資源沒有任何不同。此外，在配置多狀态資源的Ordering限制時，可以指定對資源進行的操作是提升（Promote）還是降級(Demote)操作：

pcs constraint order [action] resource_id then [action] resource_id [options]

　　Promote操作即是将對應的資源（resource_id)提升為 Master狀态， Demote操作即是将資源(resource_id)降級為 Slave狀态，通過 ordering限制即可設定被提升或降級資源的順序。

（4）叢集資源規則

　　資源規則（Rule）使得 pacemaker叢集資源具備了更強的動态調節能力，資源規則最常見的使用方式就是在叢集資源運作時設定一個合理的粘性值（Resource-stickness)'以防止資源回切到資源建立之初指定的高優先級節點上，即動态改變資源粘性值以防止資源意外回切。在大規模的叢集資源配置中，資源規則的另一重要作用就是通過設定節點屬性，将多個具有某一相同屬性值的實體節點聚合到一個邏輯組中，然後通過資源的 Location限制，利用節點組的這個共有節點屬性值，将資源限制在該節點組上運作，即隻允許此節點組中的節點運作該資源，在 Openstack高可用叢集配置中，将會使用這種方式來限制不同的資源運作在不同的節點組上（控制節點組和計算節點組），大緻的配置方式就是先為標明的節點設定某一自定義屬性，以将其歸納到一個節點組，如下配置指令将計算節點和控制節點分别設定為不同的節點屬性：

pcs property set --node computel osprole=compute

pcs property set --node computel osprole=compute

pcs property set --node controller1 osprole=controller

pcs property set --node controller2 osprole=controller

pcs property set --node controller3 osprole=controller

　　此處通過為節點分别設定不同的osprole屬性值，将節點劃分為兩個集合，即計算節點組和控制節點組，将節點 compute1和 compte2歸納到 compute節點組，節點controller1、controller2以及 controller3歸納到 controller節點組，然後通過資源的 Location限制将資源限制到不同的節點組中運作，配置指令如下：

pcs constraint location nova-compute-clone rule resource-discovery=exclusive score=0 osprole eq compute

pcs constraint location nova-api-clone rule resource-discovery=exclusive score=0 osprole eq controller

　　在上述指令中，當Rule表達式“osprole-compute" 或者"osprole=controller"成立，即Rule為True，則執行對應資源的Location限制。此處，通過資源Location 限制的“ resource-discovery-exclusive"配置，資源nova-compute-clone隻能運作在compute節點組中，而 compute組中隻有 compute1和compute2節點，是以nova-compute-clone隻能在 compute1和 compute2上運作，絕不會在 controller1、controller2及controller3上運作。同樣， nova-api-clone資源隻會在controller組中的三個節點上運作。絕不會在 compute1和 compute2節點上運作。

　　在 Pacemaker叢集中，每個資源的 Rule都會包含一個或多個數字、時間及日期表達式， Rule最終的取值則取決于多個表達式布爾運算的結果。布爾運算可以是管理者指定的邏輯與或者邏輯或操作，此外， Rule的效果總是以 constraint的形式展現。是以， Rule通常在 Constraint指令中配置，如下語句是配置資源 Rule的文法格式：

pcs constraint rule add constraint_id [rule_type] [score=score] (id=rule-id] expression丨date_expression丨date-spec options

　　如果忽略 score值，則使用預設值 INFINITY,如果忽略 ID,則自動從 Constraint_id生成一個規則 ID，而 Rule-type可以是字元表達式或者日期表達式。需要注意的是，在删除資源 Rule時候，如果此 Rule是 Constraint中的最後一個 Rule，則該 Constraint将被删除，删除資源 Rule文法如下：

pcs constraint rule remove rule_id

資源 Rule的表達式主要分為節點屬性表達式和時間/日期表達式，節點屬性表達式由以下幾個部分組成。

　　　　Value：使用者提供的用于同節點屬性值進行比較的值。

　　　　Attribute：節點屬性變量名，其值即是 value要比對的節點屬性值。

　　　　Type：确定使用哪種類型的值比對，允許的值包括字元串、整數、版本号(Version)。

　　　　Operation：操作符，确定使用者提供的1“與節點 Attribute的值如何比對，主要包括以下幾種操作符。

　　　　　　lt：如果 value 小于 Attribute的值，表達式為正 True；

　　　　　　gt：如果 value 大于 Attribute的值，表達式為正 True；

　　　　　　lte：如果value 小于等于 Attribute的值，表達式為正 True；

　　　　　　gte：如果 value 大于等于 Attribute的值，表達式為正 True；

　　　　　　eq：如果 value 等于 Attribute的值，表達式為正；

　　　　　　ne：如果 value不等于 Attribute的值，表達式為正 True；

　　　　　　defined：如果表達式中的 Attribute在節點中有定義，則表達式為 True;

　　　　　　not_defined：如果節點中沒有定義表達式中的 Attribute，則表達式為True。

要通過Rule的節點屬性表達式來确定資源的Location，則通常的指令文法如下：

pcs resource constraint location resource_id rule [rule_id] [role=master|slave] [score=score expression]

此處的表達式可以是以下幾種形式：

　　　　defined|not_defined attribute

　　　　attribute lt|gt|Ite|gte|eq|ne value

　　　　date [start=start] [end=end] operation=gt|lt|in-range

　　　　date-spec date_spec_options

在 Openstack高可用叢集配置中，使用最多的是第二種形式的表達式，例如要限制 Nova-compute服務僅運作在計算節點上，則可以通過如下 Rule和 Location配置實作：

pcs constraint location nova-compute-clone rule resource-discovery=exclusive score=0 osprole eq compute

　　上述指令中，"osprole eq compute"即是 Rule的表達式，其中 osprole是節點的Atfribute, Compute是使用者指定的節點屬性值，該表達式的操作符是等于符号（該指令語句中的規則表達式的意思就是，當節點的值等于使用者指定值（ compute)的時候，則 Rule表達式為 True（計算節點屬性中已經預先設定了osprole屬性值為compute )。