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。
 
高可用集群----理论_高可用集群
 
资源转移:可不是资源流动啊,因为每个资源在启动的时候进程号是不一样的,它表示把一个服务在毁掉的节点上停掉,然后在一个新的节点上启动起来。
 
资源代理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 百分百在一起