corosync+pacemaker构建高可用集群

2322312

一、集群简介
引自suse官方关于corosync的高可用集群的框架图：
   
    由图，我们可以看到，suse官方将集群的Architecture Layers分成四层。最低层Messaging/Infrastructure Layer提供了HeartBeat节点间传递心跳信息，即为心跳层。第二层Membership Layer层为集群事务决策层，决定了哪些节点作为集群节点，并传递给集群内所有节点，如果集群中成员拥有的法定票数不大于半数，该怎么作出决策等，通俗点讲，就是投票系统，同时，还提供了构建成员关系的视图。第三层Resource Allocation Layer为资源分配层，包含了crm，cib；crm作为资源分配层的核心组件，包括了Local Resource Manager、Transition Engine、Policy Engine三大组件，这三大组件都是在crm的基础之上得以实现的，同时，每个节点的crm还维持本节点的cib。在crm中选出一个节点作为DC（Designated Coordinator），DC负责维持主cib，所以所有cib的修改都由DC来实现，而后DC同步给其他节点，一个集群只有一个DC。cib是一个在内存中xml格式书写的保存着集群配置各条目的配置信息（集群状态，各节点，各资源，约束关系），可以使用gui修改，也可以使用crm_sh命令行修改。Transition Engine和Policy Engine，这两个组件只有DC拥有，PE是当集群状态改变时，根据配置文件中的约束信息，节点粘性计算要转移到的节点一应状态信息，并写入cib，TE根据PE作出的指示进行转移资源等操作。DC将改变的状态信息传至各crm，各节点的crm将要作出的改变传给lrm作出相应的更改，lrm有start|stop|monitor三种状态信息，在接受crm指令作出更改后，将状态信息传回crm。说到lrm了，下面我们来看看第四层Resources Layer层，即资源代理层，负责根据lrm传来的指令，找到对应的执行脚本执行，资源代理层有lsb格式，ocf格式的脚本，ocf相对于lsb，除了能接收更多参数外，还能提供监控功能。

HA Cluster的工作模型
A/P：两节点集群，active，passive：工作于主备模型
HA Services通常只有一个；HA resources可能会有多个
A/A：两节点集群，active/active；工作于双主模型
N-M：N个节点，M个服务；通常N>M
N-N：N个节点，N个服务

HA Cluster的组合方式：
heartbeat v2（v1 crm）
heartbeat v2（v2 crm）
corosync + pacemaker
cman + rgmanager

二、corosync + pacemaker

corosync + pacemaker框架图（引自马哥文档）


   Pacemaker Stack栈由众多组件组成，其主要组件为corosync + pacemaker。corosync能实现底层传递心跳信息，但不提供资源管理器，因此，由工作于corosync之上的pacemaker提供资源管理的功能，并借助Resource Agents和Cluster Glue为不具备高可用的服务与资源提供高可用服务。
   框架图的箭头描述了编译安装过程中的依赖关系，首先安装corosync和cluster glue，其次安装Resource Agents，之后再安装pacemaker，接着安装distibuted lock manager（分布式锁管理器），最后安装cLVM2，GFS2，OCFS2（非必须）。cLVM2，GFS2，OCFS2提供集群文件系统。

colosync
    OpenAIS：Application Interface Standard  开放应用接口标准
提供了一种集群模式，包含集群框架，集群成员管理，通信方式，集群监测，但没有集群资源管理。因其是由服务可用性轮胎维护，切为开源的，所有每种分支包含的组件不同。其主要分支有：picacho，witetank，wilson。colosync是由wilson把关于OpenAIS的功能独立出来形成的项目，实际上colosync是一个集群管理引擎，只是OpenAIS的一个子组件。从此OpenAIS分裂为两个项目，corosync和wilson。
pacemaker
(引自pacemaker官方站点http://clusterlabs.org/wiki/Main_Page)
    上图描述了corosync + pacemaker的四种工作模型。