一、高可用集群是神马？怎么工作的？
高可用集群（HA：High Availability）,就是为了保证服务的持续可用性，使用1个或多个备用主机来保证主服务器宕掉后能自动接替其工作的方案。
这些主机中，正在工作的，我们称为主节点，看着主节点挂掉然后才能干活的，我们称之为备节点，一般高可用集群中，只有两个节点是很特殊的HA集群，一般都是3个或3个以上。
而主机工作一般都是提供各种服务，不管是网页服务还是邮件服务或者数据库服务等，我们将这些服务和服务所需的一些特性或者属性称为资源：（resource） 常见的资源类型有：磁盘分区、文件系统、IP地址、服务程序、NFS文件系统，以及不常见的primitive(本地类型)，group，clone，Master-slave等.
HA集群中，主节点一般会不停的发出一些广播信息，告知其他节点，他在工作，当其他节点收不到这信息时，就认为他挂了，然后接替他的工作。看起来似乎很不错，对吧。对了，主节点发出的这个信息，一般都称之为心跳信息。
但实际上，试想一种情况，当网络问题，主备节点不能通信怎么办？又也许，主节点忙的没时间发心跳信息怎么办？凉拌么，亲？不管是那种情况，备用节点在指定的时间周期内收不到主节点的信息就会开始篡权了。那么，数据怎么办？服务资源怎么办？跟主节点混？谁是主节点？大家都是！所以，数据等资源就躺着也中枪了。
这些集群中可能发生的事情，例如节点系统故障、网络连通故障、网卡故障、应用程序故障等，我们称之为：事件（event）。这种各节点各自为政的行为，一般称之为：脑裂（Split-brain）
为了解决脑裂问题，那些V5的设计人员又折腾了出了一个霸气的机制：爆头（STONITH->Shoot The Other Node In The Head），可以肯定的是，肯定不会拿把枪把服务器给崩了，虽然这会很爽。实际上，简单来讲：就是谁最先抢到主节点，然后发现有别人还跟自己抢的话，就把对方的电源给掐了或是让对方重启。
爆头调用的设备，在红帽的RHCS套件中又叫隔离设备(Fence)，其实就是当主节点挂了，备节点不急着抢资源，而是调用Fence设备，将其隔离（重启，关机或者断网），隔离成功后，再安安心心的接管。
再试想一种场景，当一个高可用集群中有很多台服务器，其中一个主节点挂了，其资源给谁呢？谁抢的快给谁？不是的，我们可以定义，这个资源，譬如http服务的主节点挂了，我们在它正常的时候可以定义，如果他挂了，他优先选择转移到哪个节点上工作，或者只能选择哪个节点，或者哪个节点一定不能去，或者等他修好了，http服务还在这个节点上工作，这种方式就是对资源的约束，又叫资源粘性Stickness。
控制着资源在自己挂了之后的选择方式叫：资源转移(failover)，而故障的主节点正常后，资源再主动回来的情况叫failback。
如果有一个集群，有10台正在工作，因为老鼠把网线咬断了，集群分裂了，其中6个可以通讯，另外4个可以通讯，那么此时的集群，到底谁干活？大家都干？显然不是的，那么怎么办？投票有木有？好，那就投票，很简单，票数多于半数的，则继续干活，票数少的，则放弃服务。那么此时呢？肯定是6个的继续，4个放弃么？错了，要知道，票数(quorum)可不等于服务器个数，亲。管理投票的节点叫做DC（Designated Coordinator 指定的协调员）。
看了笔者废话这么多，纳尼是不是要问：这丫的到底咋工作的？来点清晰的东西。先来个图吧，当然，不是笔者自己画的… 二、工作层次对上图以及网络资源的整理，笔者在解释上图时，简单说一下，高可用集群一次执行的流程如下：
心跳层信息------->CCM收到并广播信息-------->CRM（收到CCM或者CIB的信息）通知PE更新------->PE查看并生成一个更新动作图传给CRM-------->CRM把更新动作图给TE-------->TE通过CRM命令LRM-------->LRM收到请求后调用RA执行请求。
其实笔者觉得分两层多省事：心跳层和处理层：一层负责发信息，一层负责接收信息并做相应的处理，简单明了，对吧，哈哈。但是上面的图分了四层，还是比较官方的资料。而且笔者也画不出来这种图，好吧，不要注意这些细节啊，魂淡。
1. 还是先说心跳吧，这个工作在最底层，用来传递各种信息，仅传递，别的啥都不管。一般称之为基础架构层又称心跳层Messaging and Infrastructure。
2. 成员关系层：Membership Layer，这一层中，有个叫CCM的服务用于管理集群节点成员属性的一致性，上层需要做神马操作，都会需要他提供的成员关系来执行。
3. 资源分配曾：Resource Allocation Layer
a) CRM集群资源管理器(Cluster Resource Manager)，它运行在每个节点上，并监控CCM的成员关系信息，并根据相关的信息作出相应的处理，上面说的DC，就是CRM随机指派的。
b) CIB集群信息库(Cluster Information Base)，这里面放的就是XML格式的文档，平时运行在内存中，通过crm等命令操作，操作后会同步到其他节点，貌似是由DC调度。
c) PE和TE 策略引擎和执行引擎(Policy Engine和Transition Engine)；基本上，看这名字就知道他俩是干嘛的，一个是负载定制怎么改，一个负责执行的，实际上他俩不通信，都是通过CRM这厮进行通信的，甚至TE执行的时候都是通过CRM让各个节点的本地资源管理器(LRM)进行执行的.
d) LRM本地资源管理器(Local Resource Manager)。CRM是对整个集群资源的宏观调整的话，这个就是每个节点自己对自身资源的管理操作了。
4. 资源层Resource Layer，通过RA(Resource Agents)脚本实现对资源的各种操作，开始，关闭，重启，状态信息查询，配置重新载入甚至爆头等，其实最后干的活都是RA来做的。资源代理支持的类型有如下几种：
Lsb符合linux标准库的脚本；
Ocf: Open Cluster Framework 开放集群框架，比LSB更略微强大；
Heartbeat V1: Heartbeat早起出现时使用的脚本，就叫做heartbeat V1；
Stonith: 这种脚本必须对应相应的硬件设备支持，否则无意义。常见的此类型设备分两类（内部|外部）。内部：IBM RSAII卡、HP的iLo卡，以及IPMI的设备等。外部：UPS，SAN SWITCH，NETWORK SWITCH等。
三、软件分类
心跳层的事，就是传递信息，不做处理，因此我们可以理解成：运行在这一层上面的软件只是一个API（Application Programming Interface,应用程序编程接口）。运行在这一层上的软件有如下：
HeartbeatKeepalivedUltramonkeyCorosync(OpenAIS子项目)等~~~只有能监控，且能根据监控信息作出处理的服务程序，才能称为高可用服务，能提供这些的软件有如下：
Heartbeat V1Heartbeat V2 前两个版本自带CRM.Heartbeat V3 + Pacemaker +Cluster-glue把CRM独立出来，改名叫做Pacemaker，并使用Cluster-glue粘合Heartbeat(心跳层)和Pacemaker(资源管理层)。官方说，这对16个节点内的集群有着良好的支持能力。Corosync + Pacemaker 听说支持一百多个节点，性能卓越…很好很强大。RHCS： RedHat Cluster Suite 红帽一直以来，都是很给力的，这个笔者也没玩的多深入。本篇，到此为止吧…本文出自 “” 博客，请务必保留此出处