高可用集群的前提：
1、节点需要不停的向其他节点通告自己的心跳信息，以判断节点的健康状态。
2、需要使用加密暗号进行沟通，防止任意主机的加入。
3、使用投票机制决定哪个主机为活动主机。一般高可用集群节点为奇数个（至少3个），且当节点过多时，会被划分为多个小的集群，当其中一个小的集群不能与另一个小集群连通时，这时多于半数的小集群就会被当做主集群。而少于半数的小集群则放弃所有服务。
高可用集群的资源：
就是运行在集群中的服务，比如httpd、sshd等。
failover：节点主机故障后，运行在其上的资源转移到备用节点上的过程。
failback：故障节点恢复后，资源转移回来的过程。
资源粘性：资源启动后，更倾向于运行在哪个节点主机上。
资源约束：(constraints)
位置约束：locations
定义资源和节点间的关系，比如资源更倾向于运行在哪个节点上。
定义范围是正无穷(inf)到负无穷(-inf)。
正无穷表示只要有可能运行在当前节点就运行。负无穷则相反。
但是正无穷和负无穷相加，结果是负无穷。因为正无穷需要额外资源。
顺序约束：order
当有多个资源时，定义资源的启动和关闭的先后顺序。
比如web服务，必须先有IP资源，再有Filesystem，最有才是httpd
排列约束：colocations
定义资源间的关系，也就是2个资源要不要在一起启动的倾向性。
比如IP和Filesystem必须要在一起。
依然使用正无穷(inf)和负无穷(-inf）来确定。
当集群中有很多主机时，如果任由一个资源在主机间游动，那么过几天肯定无法找到那个资源的位置。所以需要定义一个故障转移策略限定资源的故障转移域。
左对称：使用白名单，资源只能转移到预定的主机上。
右对称：使用黑名单，资源不能转移到某些主机上面。
高可用集群的层次结构：
1、信息和成员关系层（Messaging and
Membership），Messaging主要用于节点之间传递心跳信息，也称为心跳层。节点之间传递心跳信息可以通过广播，组播，单播等方式。成员关系（Membership）层，这层最重要的作用是主节点（DC）通过Cluster
Consensus Menbership
Service（CCM或者CCS）这种服务由Messaging层提供的信息，来产生一个完整的成员关系。这层主要实现承上启下的作用，承上，将下层产生的信息生产成员关系图传递给上层以通知各个节点的工作状态；启下，将上层对于隔离某一设备予以具体实施。能够直接运行在信息层上的软件叫做高可用软件，由于这种软件开发难度高和周期长，所以又有了第二层。
2、集群资源管理层（Cluster Resource
Manager），真正实现集群服务的层。在该层中每个节点都运行一个集群资源管理器（CRM，cluster Resource
Manager），它能为实现高可用提供核心组件，包括资源定义，属性等。在每一个节点上CRM都维护有一个CIB(集群信息库
XML文档)和LRM（本地资源管理器）组件。对于CIB，只有工作在DC（Designated
Coordinator，指定的协调员。主节点）上的文档是可以修改的，其他CIB都是复制DC上的那个文档而来的。对于LRM,是执行CRM传递过来的在本地执行某个资源的执行和停止的具体执行人。当某个节点发生故障之后，是由DC通过PE（策略引擎）和TE（实施引擎）来决定是否抢夺资源，DC是集群自动选举出来的，不用手动修改。
3、资源代理层（Resource
Agents），集群资源代理(能够管理本节点上的属于集群资源的某一资源的启动，停止和状态信息的脚本)，资源代理分为：LSB（/etc/init.d/*）,OCF(比LSB更专业，更加通用),Legacy
heartbeat（v1版本的资源管理）。
各层的实现工具介绍：
| Message Layer | CRM | RA |
| heartbeat V1 |
haresource：heartbeat V1 |
haresource：heartbeat V1 |
| heartbeat V2 |
crm：heartbeat V2，crm牌CRM |
LSB：/etc/rc.d/init.d/* |
| heartbeat V3 |
pacemaker：独立出heartbeat的项目，适配多款软件。 |
OCF：Open Cluster Framework开放集群框架 |
| RHCS：cman(rhel5) |
RHCS：rgmanger(RHEL6) |
STONITH：电源交换机爆头开关，防止集群分类时的资源争用 |
| coroync |
在RHEL6上有多种可供选择的信息层+CRM组合方案
1、cman+rgmanger
2、cman+pacemaker
3、heatbeat V3+pacemaker
4、corosync+pacemaker
安装corosync时，由于制作RPM时会依赖于heartbeat的一些RA，所以会同时装上heartbeat，但是heartbeat不一定启动。但是heartbeat却不会依赖corosync的。
编辑HA集群的接口：
1、直接编辑配置文件
2、CLI：crmsh(SUSE),pcs(redhat)命令行方式
3、GUI：heartbeat-GUI、LCMC、HAWK、pygui、RHCS的Conga
fencing：
当正在服务的节点突然宕机时，为了保证其在宕机瞬间不再继续占用集群资源，比如仍然在使用块级别的存储设备SAN，这时很有可能就会破坏文件，所以就需要让其瞬间彻底的脱离集群。
节点级别的fencing：使用STIONITH，能接受网络信号的电源交换机，
当资源进入新的主机，那么可以发信号切断老主机电源
当老主机是虚拟机时，就可以直接杀死那个进程就可以了。
资源级别的fencing：在SAN设备上直接阻断老主机进入的端口的流量。
XML： eXtended Markable
Language扩展的可标记语言，但是很难配置，不易用
资源类型：
primitive，native：主资源，只能运行在一个节点上的资源
group：组资源，一个组资源也只能运行在一个节点上。
clone：克隆资源，需要运行在多个节点上，比如stonith，需要运行在多个节点上，
当资源转移时，随时枪毙老资源。
master/slave：主从类资源，也是克隆类资源，但分主从，比如drdb。
集群模式：
active/passive：主备模型
active/active：双活动节点，通过corosync提供的功能，实现一个资源(包括主资源)可以运行在多个节点上。
N对M：N个节点，M个服务。
N对N：N个节点，N个服务。
双节点集群：，
一般HA集群至少是3个节点，但是双节点在提供其他配置的情况下，也是可以运行的。
1、ping node，可以提供多个，可以使路由器。
2、qdisk（quarum disk)：仲裁磁盘，也就是一个共享磁盘
主节点不停的向qdisk上写数据，然后由备用节点不停的监测，如果在规定时间内看不到新数据了，那么就判定主节点已经挂掉，然后将其stonith并抢占资源。