高可用集群有多种解决方案，例如keepalived程序可实现，还有就是ais家族中实现高可用集群多多种方式；较早出现的heartbeat，OpenAIS仅作为参考性模型，后来红帽在OpenAIS基础上研发的CMAN，
还有OpenAIS参考性中，实现独立出来成为的项目corosync都可用于高可用集群；但是，这些应用程序都是源于最早的heartbeat程序开发出来的。
OpenAIS家族中对于高可用集群在实现时的方式，都遵循一样的工作模式；都是通过集群方式来提高系统可用性，那么就是通过提供冗余主机节点，来完成系统可用性提升；
要实现高可用集群服务，就得把所有提供服务的节点纳入到集群中来，由集群统一负责管理，指派资源归哪个节点运行，并且还要检查各节点的健康状态，出现掉线，要把服务迁移到其它节点上运行，以实现服务不掉线，实现该服务的高可用的目的。
但是，要实现这一目的是非常复杂的，需要经过多个层级的控制；例如，每个节点也可以通过单播、多播、广播方式向同一集群中的其它节点通告自己的心跳信息以及其它与当前集群相关的事务类信息；这个层次只负责集群事务的传递，它叫做Messaging Layer消息层。这个消息层主要作用有两点：通过配置的接口和地址以及方式，来完成集群心跳及事务信息传递。
任何一个应用程序（服务）要想能够自己工作成高可用模型，将自己在messaging layer基础之上，运行为高可用；也就是说必须能与消息层通信。
有些程序能直接消息层通信，但有些应用程序不能，为了让各应用程序能与消息层通信，就设计出一个通用中间层代为自己实现与消息层通信，这就意味着要接受管理。所以不能与消息层直接通信的程序，想以高可用的方式运行时托管在这个中间层上；由中间层代为管理，它们就是高可用的了；而这个中间层称为集群资源管理器CRM。
CRM为了便于实现对每个节点的控制，需要一个LRM本地资源管理器，来负责具体某个节点上的服务管理，比如监控服务，启动服务，停止服务等操作；但是，真正完成监控、启动、停止操作的不是靠crm、lrm来完成的。
我们都知道在linux系统上，正常启动一个服务，例如在centos 7启动web服务上是使用systemctl start httpd.service，才能启动，在centos 6上使用service httpd start；使用的风格不同，centos 7使用systemd，而centos6使用sysv风格。所以，高可用集群，把各种启动服务的脚本称作RA资源代理。高可用集群实际上最终是通过调用这个服务程序资源代理来启动服务的。
messaging layer、CRM、RA这三个层次就是ais家族来实现集群功能的三个基本层次；
总结：
messaging layer主要作用：通过配置的接口和地址以及方式，来完成集群心跳及事务信息传递；
CRM作用：为非ha-aware（不能直接与消息层通信）程序提供中间层，因为非ha-aware程序不能调用messaging layer，而CRM可以调用了messaging layer，同时有可以向上提供一个托管接口，让任何非ha-aware应用程序，想以ha的方式运行时托管在这个中间层上；
而RA的主要作用：主要实现具体的资源管理操作功能。
这三层是概念性的模型，每一层都有其具体实现：
Messaging Layer：3种方案
heartbeat程序、corosync、cman；
CRM：3种方案
haresource、crm、pacemaker；
RA：资源代理当然就是有具体服务的程序包本身提供的了。
messing layer和CRM的组合方式：
heartbeat v1(haresource)：自己就是独立而完整的；
heartbeat v2(crm)：自己就是独立而完整的；
corosync + pacemaker（手动结合）：其中corosync有2个版本；
corosync v1 + pacemaker（plugin）：没有独立投票系统，pacemaker作为插件运行的；
corosync v2 + pacemaker(standalone service)：corosync的v2版有完整的投票系统；
cman + rgmanager(RHCS)：红帽自己研发的程序。
corosync v1 + cman + pacemaker：把corosync当做cman的插件来运行，反之也行，因为corosync只提供messaging layer与pacemaker结合工作，cman提供投票系统但其它功能太差。
想要深入理解学习corosync或ais家族的高可用解决方案里的概念，去查看suse官方高可用集群的官方文档即可。
quorum机制的概念，这对于多数的分布式系统都通用；主要用于解决发生网络分区导致脑裂；
有两种策略，符合法定票数和不符合法定票数；其中当不符合法定票数策略中，为避免资源争用，使用4种机制，stop：停止所有资源；默认；ignore：忽略法定票数与否，都继续工作；suicide：自杀；freeze：冻结；资源仍在运行，但是不接收新请求。
为了确保自杀成功，使用fencing机制，有了两种方案：启用stonith机制；光纤交换机。
注意：高可用集群中两节点集群或偶数节点发生脑裂必须做出决策，这是特殊情况。
集群信息及心跳信息的传递方式：单播、广播、组播。
集群资源管理：术语DC，集群的统一调度者；PE，策略引擎。
资源粘性：就是定义资源运行于当前节点的倾向性；默认为0；
资源的倾向性：也称资源的约束关系，资源对节点的倾向性、资源彼此间排列性、资源启动顺序。
资源的类型：4种类型
primitive：表示资源能且只能运行在一个节点上；是基本资源或主资源，是最常见的资源类型，仅能运行一份，仅能运行于一个节点；
group：组资源，将组成一个HA Service所需要的所有资源组织在一起；
clone：克隆资源，同一资源可以出现多份副本，可以运行多个节点；
multi-state（master/slave）：多状态资源，是特殊克隆的资源，副本间存在主从关系；
RA：资源代理，5种
LSB：Linux标准库，位于/etc/rc.d/init.d/*，至少支持start，stop，restart，status，reload，force-reload；注意：不能开机自动运行；
OCF：open Cluster framework，此种脚本比LSB脚本更灵活，/usr/lib/ocf/resource.d/provider/，类似于LSB脚本，但要求支持start，stop，status，monitor，meta-data；
STONITH：实现管理调用stonith设备的功能；
systemd：用unit file文件实现，/usr/lib/systemd/system/；注意：必须设置为enable状态；否则无法让crm代理管理；
service：调用用户自定义脚本；
演示：配置一个基于nfs的高可用mariadb服务：
物理机为win7，虚拟机使用centos7系统
时间服务器：172.18.0.1
nfs服务器：172.18.11.113
mariadb有两节点：
node1:172.18.11.111，主机名：node1.stu11.com
node2:172.18.11.112，主机名：node2.stu11.com
在两节点上执行如下操作：
第一步：时间同步
]# ntpdate 172.18.0.1 向时间服务器同步时间
]# crontab -e 定义时间同步周期任务
*/5 * * * * /usr/sbin/ntpdate 172.18.0.1 &> /dev/null
第二步：能够基于主机名互相解析，并且解析主机名要与使用的主机名一致
]# vim /etc/hosts
172.18.11.111 node1.stu11.com node1
172.18.11.112 node2.stu11.com node2
确保使用的名称和解析的名称必须一致；解析的名称设定为什么，使用是hostname命令看到的必须一样；否则，高可用集群不可用。
第三步：永久生效，设定主机名：
]#hostnamectl set-hostname node1.stu11.com
]#hostnamectl set-hostname node2.stu11.com
两节点，安装mariadb， pacemaker
]# yum -y install mariadb-server
]# systemctl enable mariadb.service
]# yum -y install pacemaker
]# systemctl start corosync.service pacemaker.service
配置nfs服务器：
]# yum -y install nfs-utils
]# vim /etc/exports
/mysql 172.18.11.0/24(rw,no_root_squash)
在两节点创建数据库存储路径：
]# mkdir /mysql
]# chown mysql.mysql /mysql
测试在两节点挂载是否成功：
]# showmount -e 172.18.11.113
]# mount -t nfs 172.18.11.113:/mysql /mysql
]# mount
]# vim /etc/my.cnf
datadir=/mysql
skip_name_resolve=on
innodb_file_per_table=on
]# crm ra
确保资源代理已经存在；
查看集群状态：
定义集群资源：
查看集群状态：
绑定资源在一起：
查看集群状态：
手动使node1下线，查看资源是否迁移
]# crm node standby
查看集群状态：
以上演示，实现了基于nfs的mariadb的高可用
corosync v2 + pacemaker 高可用mariadb服务
原文地址：http://linsj.blog.51cto.com/5440766/1784597
