HA cluster：高可用集群High Avaliability Cluster 

高可用性能实现的软件组合： heartbeat  V1
  heartbeat  V2
  heartbeat+pacemaker
  corosync+pacemake
  cman(openais)+rgmanager
高可用性能:就是服务器不间断的提供服务，而这种情况又是单个的服务器又不能完成的，所以我们就提供了高可用集群。
高可用集群:是指以减少服务中断时间为目的的服务器集群技术
     怎么让服务不中断呢？就是一台服务器down了，另一台会顶上去。比如说现在又两台机器A和B，当A机down掉后，我们的B要马上把在A上运行的服务以及对应的进程运行起来，并且几乎是无缝隙的运行。那现在就出现了两个问题，B主机怎么知道A主机出了问题？
    在高可用集群当中，每个节点他们是通过心跳heartbeat信息来确定对方的健康状况的，心跳信息就是每个节点每隔一个时间都要发出的一个信号，让对方确认自己是否是正常的工作的，因为要实现无缝隙对接，所以心跳信息的发送频率是非常高的。所以当B在一个时间范围内接收不到A传过来的信息的时候，它就认为A已经挂掉了，B此时就要用A机的IP接替A的工作了。那它是怎么接替A的工作的呢？这就需要一个专门管理资源的层次，叫做资源管理层（CRM）。
    上面提到他们是通过心跳的信息来判断彼此的健康的状况的，那心跳信息是怎么传递过去的？心跳信息heartbeat的传递是需要一个通道的，可以称它为低层的通信信道，能够提供这样一个通道的软件有heartbeat corosync cman。
    另外在高可用服务当中一定要考虑的一个问题，当B要接替A的共作的时候，B如何获取与A上面一摸一样的数据呢？有两种方式可以解决这个问题：
 
                  第一种方式是共享存储；
                  第二种方式是通过文件同步功能来实现，DRBD种较理想的解决方案，当一个设备上的数据出现了问题，另一个设备上还有同样的数据存在。
 
    即使是已经解决了数据一致性的问题，还有一个问题没有考虑，每个节点怎么判断它是集群的一份子呢？它就是通过Quorum票数来判断的。quorum机制就是让集群内的节点，对每个节点都进行投票选举，如果节点接收到的Auorum票数，大于原来选取票数的1/2，它就认为它自己还是机器的一份子，那么它还会为集群服务，当小于1/2时候他就认为它已经不是集群了，所以就不在作为集群提供服务了，那对于3个节点的集群来说至少2个节点时激活状态才有效，那对于两个节点的集群的话，如果一个节点出现问题，那票数怎么都是小于二分之一，此时集群就不能工作了。（共享存储的一小块分区来支持Quorum）
     有了以上策略就避免了集群分裂，但是资源依然会产生资源征用，因为这个节点上可能还运行着某个资源呢。应该将其停掉。为了避免资源征用，所以要隔离那些不再是集群的节点去访问那些集群源。
    隔离级别两种，一种是节点级别隔离，一种是资源级别隔离。
    节点级别的隔离：需要一种特殊的设备stonith来进行隔离，它是利用电源交换机。
    资源级别的隔离：就是对应的设备自身就有资源隔离能力，FC SUN就有。
 
    为了解决小规模集群存在的Quorum问题，引入了qdisk,它使用一个小于10MB的共享磁盘分区，Qdiskd进程运行在集群的所有节点上，定期评估自身的健康情况，然后把它的状态信息放入到指定的共享磁盘分区。每qdiskd接着查看其他节点的状态，并传递信息给其他节点QDisk分区。在正常情况下，集群的Quorum就是每个节点计数再加上QDisk分区的计数和。
 
对于两个节点的集群，任何一个节点出现问题，都会造成集群的分裂瘫痪，面对这种情况有两种解决方案：
      第一、找个第三方节点，尝试ping它来判断自己是否正常的，这个第三方节点最好选网关。
      第二、用共享的仲裁磁盘qdisk。
 
高可用集群----理论_第1张图片
 
资源转移：可不是资源流动啊，因为每个资源在启动的时候进程号是不一样的，它表示把一个服务在毁掉的节点上停掉，然后在一个新的节点上启动起来。
 
资源代理RA：资源代理RA：CIM正常工作了真正实现资源管理的还要靠RA.就是负责完成停掉这个服务，并且在新的节点上启动这个服务的一个脚本。监控节点上的信息。（RA按图结构给出的话应该位于CRM的上面）
 
CIB：Cluster Information Base集群信息库，用于保存集群中资源的属性配置信息，是CRM的一个子进程，它要运行在每个集群的节点上,并且每个节点上的CIB都是一样的，如果某个节点的坏掉了，CIB信息库肯定是要改变了，它是先改变节点DC信息协调员上面的信息库，在由DC同步到其它的节点上去。DC是由集群自动选取的协调员。包括那个quorum票数也是保存在它上面。
 
PE：集群策略引擎就是根据从底层收集来的信息判定集群是否还能运行，并且生成big-picture。当发现集群依然可以运行，它就会指挥TE完成。只运行在DC节点上。
 
TE：事物引擎，负责根据PE计算的结果指挥资源转移，即通知LRM去完成这个动作，只运行在DC节点上。
 
LRM：运行在每个节点上的本地资源管理器，它可以理解是CRM的一个外派。它还是CRM的一个子组件。
 
既然要定义资源，那我们还需要定义资源的接口:
ha.resource
CLI
GUI:Web GUI 图形化的接口
 
Web GUI又有很多种，因为它们都是一个组件:
红帽RHCS集群套件中：luci/ricci
Debian/SUSE系统上，pacemaker自身带有hawk的图形接口
heartbeat GUI
 
底层通信信道的软件实现方案：heartbeat corosync keepalived ultramonkey(前两着同属红帽)
 
CRM软件：heartbeat(V1)  legacy CRM 
heartbeat(V2)   CRM 
heartbeat(V3) + Pacemaker + Cluster-glue
 
在红帽5中集群套件：corosync+cman
在红帽6中集群套件：corosync+pacemaker
 
资源约束：位置约束/顺序约束/排列约束
 
 -inf 永远不再一起
  inf 百分百在一起