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等組合集羣資泖管理軟件也有着極爲普遍的應用。

2、 Pacemaker概述

一、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的主要功能包括如下幾方面：

　　　　一、監測並恢復節點和服務級別的故障。                                                                                                         
　　　　二、存儲無關，並不須要共享存儲。
　　　　三、資源無關，任何能用腳本控制的資源均可以做爲集羣服務。
　　　　四、支持節點 STONITH功能以保證集羣數據的完整性和防止集羣腦裂。
　　　　五、支持大型或者小型集羣。
　　　　六、支持 Quorum機制和資源驅動類型的集羣。
　　　　七、支持幾乎是任何類型的冗餘配置。
　　　　八、自動同步各個節點的配置文件。
　　　　九、能夠設定集羣範圍內的 Ordering、 Colocation and Anti-colocation等約束。
　　　　十、高級服務類型支持，例如：
　　　　　　Clone功能，即那些要在多個節點運行的服務能夠經過 Clone功能實現， Clone功能將會在多個節點上啓動相同的服務；

　　　　　　Multi-state功能，即那些須要運行在多狀態下的服務能夠經過 Multi--state實現，在高可用集羣的服務中，有不少服務會運行在不一樣的高可用模式下，

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

　　　　十一、具備統一的、腳本化的集羣管理工具。

二、pacemaker的服務模式。

　　Pacemaker對用戶的環境沒有特定的要求，這使得它支持任何類型的高可用節點冗餘配置，包括 Active/Active、 Active/Passive、N+一、 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設備。

3、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         以用戶可讀格式顯示完整集羣配置信息

 4、Pacemaker集羣資源管理

一、集羣資源代理

　　在 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

 

二、集羣資源約束

　　集羣是由衆多具備特定功能的資源組成的集合，集羣中的每一個資源均可以對外提供獨立服務，可是資源彼此之間存在依賴與被依賴的關係。如資源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集羣中最爲重要的三個約束經過這幾個資源約束設置，集羣中看起來彼此獨立的資源就會按照預先設置有序運行。

 三、集羣資源類型

　　在 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節點組，節點controller一、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上運行，毫不會在 controller一、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 )。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

摘自：山金孝的OpenStack高可用集羣一書