一、前言
雲計算與集群系統密不可分，作為分布式計算和集群計算的集大成者，雲計算的基礎設施必須通過集群進行管理控制，而作為擁有大量資源與節點的集群，必須具備一個強大的集群資源管理器（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功能將會在多個節點上啟動相同的服務；
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參數查看：
[root@controller1 ~]# 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標准還嚴格定義了操作執行后的返回代碼，集群資源管理器將會根據0資源代理返回的執行代碼來對執行結果做出判斷。因此，如果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的資源代理 [root@controller1 ~]# pcs resource list |grep http service:httpd - systemd unit file for httpd systemd:httpd - systemd unit file for httpd 2、查看怎么創建http資源： [root@controller1 ~]# 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資源： [root@controller1 ~]# 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。
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的表達式主要分為節點屬性表達式和時間/日期表達式，節點屬性表達式由以下幾個部分組成。
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 )。
摘自：山金孝的OpenStack高可用集群一書