高可用集羣架構詳解(基於corosync)

架構圖

Messaging and Infrastructure Layer

第一層是messaging/infrastructure層，也就是Corosync/OpenAIS層。經過這一層發送「我還活着」的信號。

 

Resource Allocation Layer

第二層是resource allocation layer.這一層最爲複雜，包含如下組件：

 

ClusterResource Manager (CRM)

在資源分配層，每個動做的執行都要通過CRM。資源分配層上的其它組件（或者更高層的組件）通訊也要經過CRM。在每個節點上，CRM都會維護一個CIB。

Cluster Information Base (CIB)

CIB使用XML表示整個集羣的配置和當前狀態信息。它包含全部集羣選項、節點、資源、約束的定義和彼此之間的關係。而且CIB同步更新至全部的集羣節點。在集羣內有一個經過DC維護的主CIB節點。其它全部節點存在一個CIB的副本。

Designated Coordinator (DC)

某一個CRM被推選爲DC。DC 是羣集中惟一能夠決定須要在整個羣集執行更改（例如節點屏蔽或資源移動）的實體。其它全部的節點從當前DC得到配置和資源分配信息。

Policy Engine (PE)

只要DC須要進行羣集範圍的更改（對新 CIB 做出反應），PE會根據當前集羣狀態和配置計算出下一個狀態並反饋生成一列指令給DC。PE一般在DC上運行。

Local Resource Manager (LRM)

LRM是CRM的代理，表明 CRM 調用本地RA.它能夠執行start/stop/monitor操做並把結果反饋給CRM。而且能夠隱藏不一樣RA(OCF,LSB)直接的差別。LRM 是其本地節點上全部資源相關信息的權威來源。

Resource Layer

最頂層是RL，RL包含不一樣的RA。RA是已寫入的用來啓動、中止和監視某種服務（資源）的程序（一般是shell腳本），僅能被LRM調用。

 

 

 

執行流程

• Pacemaker做爲CRM。CRM做爲守護進程(crmd)執行。Pacemaker集中全部集羣決策經過推選一個crmd 實例做爲DC。若是這個節點故障，會當即推選一個新的DC。

• 每一個節點保留了一個CIB，反映的是集羣的配置和當前全部資源狀態信息。CIB中的內容會自動同步到整個集羣。

• 集羣中不少操做的執行會致使集羣的改變。這些動做可能包含增長或移除一個集羣資源或改變資源約束。理解執行這些動做在集羣上發生了什麼是很是重要的。

• 例如，你想增長一個集羣IP地址資源。要想完成，你可能使用命令行工具或GUI去修改CIB。並不要求在DC上執行動做，你能夠在其它節點使用一個工具修改，這些操做會通知給DC。而後DC會複製CIB中改變的部分到全部的集羣節點。

• 根據CIB中的信息，PE計算出集羣的理想狀態以及實現過程，而且反饋指令列表給DC。DC 經過messaging/infrastructure layer發送指令，這些指令被其它節點上的crmd對等體接收。每個crmd使用LRM執行資源的修改。lrmd是非集羣可感知的，它直接與資源源代理（scripts）交互。

• 全部同等的節點反饋執行的結果給DC。一旦DC推斷出全部必要的操做執行成功，集羣將會返回到空閒狀態並等待進一步事件。若是任一操做未執行成功，則會再次調用PE，CIB中將記錄新信息。

• 在某些狀況下，爲了保護共享數據不被破壞和資源恢復須要關閉某一節點。爲此，Pacemaker 附帶了一個屏蔽子系統，stonithd。STONITH 是 「Shoot The Other NodeIn The Head」 的首字母縮寫，一般經過一個遠程電源交換機實施。Pacemaker中，STONITH設備配置爲資源保存在CIB中，使他們能夠更容易地監測資源故障。