高可用集群架构详解(基于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中，使他们能够更容易地监测资源故障。