一、高可用集群的定义
高可用集群，英文原文为High Availability Cluster，简称HACluster，简单的说，集群（cluster）就是一组计算机，它们作为一个整体向用户提供一组网络资源。这些单个的计算机系统 就是集群的节点（node）。
高可用集群的出现是为了使集群的整体服务尽可能可用，从而减少由计算机硬件和软件易错性所带来的损失。如果某个节点失效，它的备援节点将在几秒钟的时间内接管它的职责。因此，对于用户而言，集群永远不会停机。
高可用集群软件的主要作用就是实现故障检查和业务切换的自动化。只有两个节点的高可用集群又称为双机热备，即使用两台服务器互相备份。当一台服务器出现故障时，可由另一台服务器承担服务任务，从而在不需要人工干预的 情况下，自动保证系统能持续对外提供服务。双机热备只是高可用集群的一种，高可用集群系统更可以支持两个以上的节点，提供比双机热备更多、更高级的功能，更能满足用户不断出现的需求变化。
二、高可用集群的衡量标准
高可用性群集是通过系统的可靠性(reliability)和可维护性(maintainability)来度量的。工程上，通常用平均无故障时间(MTTF)来度量系统的可靠性,用平均维修时间（MTTR）来度量系统的可维护性。于是可用性被定义为：HA=MTTF/(MTTF+MTTR)*100%
具体HA衡量标准:
99% 一年宕机时间不超过4天
99.9% 一年宕机时间不超过10小时
99.99% 一年宕机时间不超过1小时
99.999% 一年宕机时间不超过6分钟
三、高可用集群的层次结构
如上述三张图片所示
高可用集群可分为三个层次结构，分别由红色部分的Messaging与Membership层，蓝色部分的Cluster Resource Manager（CRM）层，绿色部分的Local Resource Manager（LRM）与Resource Agent（RA）组成，
1.位于最底层的是信息和成员关系层（Messaging and Membership），Messaging主要用于节点之间传递心跳信息，也称为心跳层。节点之间传递心跳信息可以通过广播，组播，单播等方式。成员关系（Membership）层，这层最重要的作用是主节点（DC 只有一个node是DC）通过Cluster Consensus Menbership Service（CCM或者CCS）这种服务由Messaging层提供的信息，来产生一个完整的成员关系。这层主要实现承上启下的作用，承上，将下层产生的信息生产成员关系图传递给上层以通知各个节点的工作状态；启下，将上层对于隔离某一设备予以具体实施。
2.集群资源管理层（CRM Cluster Resource Manager），真正实现集群服务的层。在该层中每个节点都运行一个集群资源管理器（CRM，cluster Resource Manager），它能为实现高可用提供核心组件，包括资源定义，属性等。在每一个节点上CRM都维护有一个CIB(集群信息库 XML文档)和LRM（本地资源管理器）组件。对于CIB，只有工作在DC（主节点）上的文档是可以修改的，其他CIB都是复制DC上的那个文档而来的。对于LRM,是执行CRM传递过来的在本地执行某个资源的执行和停止的具体执行人。当某个节点发生故障之后，是由DC通过PE（策略引擎）和TE（实施引擎）来决定是否抢夺资源。
其实，CRM就是一个粘合层，完成了对不具备ha-aware的软件提供了ha的能力，借此来监控各节点的运行状况并且管理各节点的资源，一旦节点出现故障，它就会将该节点上的资源转移到其他正常运行的节点之上。
说明：
Ha-aware: 它意味着应用程序自身能够从信息层收集高可用信息或者事务信息，并在我们节点发生状态转换的时候能够自动采取一些动作来控制节点上资源的调度，
3.资源代理层（RA Resource Agents），集群资源代理(能够管理本节点上的属于集群资源的某一资源的启动，停止和状态信息的脚本)，资源代理分为：LSB（/etc/init.d/*）,OCF(比LSB更专业，更加通用)
核心组件的具体说明
（如上图）：
1.ccm组件（Cluster Consensus Menbership Service）：作用，承上启下，监听底层接受的心跳信息，当监听不到心跳信息的时候就重新计算整个集群的票数和收敛状态信息，并将结果转递给上层，让上层做出决定采取怎样的措施，ccm还能够生成一个各节点状态的拓扑结构概览图，以本节点做为视角，保证该节点在特殊情况下能够采取对应的动作。
2.crmd组件（Cluster Resource Manager，集群资源管理器，也就是pacemaker）：实现资源的分配，资源分配的每个动作都要通过crm来实现，是核心组建，每个节点上的crm都维护一个cib用来定义资源特定的属性，哪些资源定义在同一个节点上。
3.cib组件（集群信息基库，Cluster Infonation Base）：是XML格式的配置文件，在内存中的一个XML格式的集群资源的配置文件，主要保存在文件中，工作的时候常驻在内存中并且需要通知给其它节点，只有DC上的cib才能进行修改，其他节点上的cib都是拷贝DC上。配置cib文件的方法有，基于命令行配置和基于前台的图形界面配置。
4.lrmd组件（Local Resource Manager，本地资源管理器）：用来获取本地某个资源的状态，并且实现本地资源的管理，如当检测到对方没有心跳信息时，来启动本地的服务进程等。
5.pengine组件：
PE（Policy Engine）：策略引擎，来定义资源转移的一整套转移方式，但只是做策略者，并不亲自来参加资源转移的过程，而是让TE来执行自己的策略。
TE（Transition Engine）： 就是来执行PE做出的策略的并且只有DC上才运行PE和TE。
6.STONITH组件
STONITH(Shoot The Other Node in the Head，”爆头“)， 这种方式直接操作电源开关，当一个节点发生故障时，另 一个节点如果能侦测到，就会通过网络发出命令，控制故障节点的电源开关，通过暂时断电，而又上电的方式使故障节点被重启动， 这种方式需要硬件支持。
STONITH应用案例（主从服务器），主服务器在某一端时间由于服务繁忙，没时间响应心跳信息，如果这个时候备用服务器一下子把服务资源抢过去，但是这个时候主服务器还没有宕掉，这样就会导致资源抢占，就这样用户在主从服务器上都能访问，如果仅仅是读操作还没事，要是有写的操作，那就会导致文件系统崩溃，这样一切都玩了，所以在资源抢占的时候，可以采用一定的隔离方法来实现，就是备用服务器抢占资源的时候，直接把主服务器给STONITH，就是我们常说的”爆头 ”。
四、高可用集群的分类
1.双机热备（Active/Passive）
官方说明：Two-node Active/Passive clusters using Pacemaker and DRBD are a cost-effective solution for many High Availability situations.
2.多节点热备（N+1）
官方说明：By supporting many nodes, Pacemaker can dramatically reduce hardware costs by allowing several active/passive clusters to be combined and share a common backup node.
3.多节点共享存储（N-TO-N）
官方说明：When shared storage is available, every node can potentially be used for failover. Pacemaker can even run multiple copies of services to spread out the workload.
4.共享存储热备 （Split Site）
官方说明：Pacemaker 1.2 will include enhancements to simplify the creation of split-site clusters.
五、高可用集群软件
⒈Messaging and Membership Layer （信息与关系层）：
①heartbeat (v1,v2,v3)，heartbeat v3 分拆 heartbeat pacemaker cluster-glue
②corosync （rhel6.0以后）
③cman （rhel5.x）
④keepalived （本身为lvs而开发的高可用机制）
⑤ultramokey
⒉Cluster Resource Manager Layer （资源管理层，简称:CRM）：
①heartbeat v1:haresource
②heartbeat v2:haresource、crm （v2自带二个CRM，第一个兼容v1的haresource，另一个CRM）
③pacemaker:pacemaker是crm发展的一个独立项目，功能更强大
常用组合：
heartbeat v3 （信息与关系层）+pacemaker（CRM）
corosync + pacemaker
④rgmanager (cman)
常用组合：
①heartbeat v2+haresource(或crm) (说明：一般常用于CentOS 5.X)
②heartbeat v3+pacemaker (说明：一般常用于CentOS 6.X)
③corosync+pacemaker (说明：现在最常用的组合)
④cman + rgmanager (说明：红帽集群套件中的组件，还包括gfs2,clvm)
⑤keepalived+lvs (说明：常用于lvs的高可用)
六、共享存储
共享存储，不管理是Web高可用也，Mysql高可用也好，他们的数据都是共享的就一份，所有必须放在共享存储中，主节点能访问，从节点也能访问。
1.DAS:(Direct attached storage)直接附加存储
说明：设备直接连接到主机总线上的，距离有限，而且还要重新挂载，之间有数据传输有延时
RAID 阵列
SCSI 阵列
2.NAS:(network attached storage)网络附加存储
说明：文件级别的共享
NFS
FTP
CIFS
3.SAN:(storage area network)存储区域网络
说明：块级别的，模拟的scsi协议
FC光网络（交换机的光接口超贵，一个差不多2万，如果使用这个，代价太高）
IPSAN（iscsi）存取快，块级别，廉价
七、集群文件系统与集群LVM（集群逻辑卷管理cLVM）
集群文件系统：gfs2、ocfs2
集群LVM：cLVM
注：一般用于高可用双主模型中（如下图）
八、高可用集群的工作原理
说明：以主/从节点的高可用来说明工作原理。
主服务器和从服务器建立双机热备，基本上都是共享一个存储，以mysql为例。通常情况下，数据库文件挂载在主数据库服务器上，用户连接到主服务器上进行数据库操作。当主服务器出现故障时，从服务器就会自动挂载数据库文件，并接替主服务器的工作。用户在未通知的情况下，通过从数据库连接到数据库文件进行操作。等主服务器的故障修复之后，又可以重新提供服务；
那么，从服务器是如何知道主服务器挂掉了呢，这就要使用一定的检测机制，如心跳检测，也就是说每一个节点都会定期向其他节点通知自己的心跳信息，尤其是主服务器，如果从服务器在几个心跳周期内（可自行设置心跳周期）还没有检测到的话，就认为主服务器宕掉了，而这期间在通告心跳信息当然不能使用tcp传输的，如果使用tcp检测，还要经过三次握手，等手握完了，不定经过几个心跳周期了，所以在检测心跳信息的时候采用的是udp的端口694来进行传递信息的，如果主服务器在某一端时间由于服务繁忙，没时间响应心跳信息，这个时候从服务器要是把主服务资源抢过去（共享数据文件），但是这个时候主服务器还没有宕掉，这样就会导致资源抢占，就这样用户在主从上都能访问，如果仅仅是读操作还没事，要是有写的操作，那就会导致文件系统崩溃，这样一切都玩了，所以在资源抢占的时候，可以采用一定的隔离方法来实现，就是从服务器抢占资源的时候，直接把主服务器给“STONITH”，就是我们常说的“爆头”；
那么，我们又用什么方式来检测心跳信息呢？就是通过心跳线来检测。运行在从服务器上的Heartbeat可以通过以太网连接检测主服务器的运行状态，一旦其无法检测到主服务器的“心跳”则自动接管主服务器的资源。通常情况下，主、从服务器间的心跳连接是一个独立的物理连接，这个连接可以是串行线缆、一个由“交叉线”实现的以太网连接。Heartbeat甚至可同时通过多个物理连接检测主服务器的工作状态，而其只要能通过其中一个连接收到主服务器处于活动状态的信息，就会认为主服务器处于正常状态。从实践经验的角度来说，建议为Heartbeat配置多条独立的物理链路，以避免Heartbeat通信线路本身存在单点故障。
上面的原理中我们提到了“隔离方法”，下面我们来说一说，隔离方法有两种，一种是节点隔离，另一种是资源隔离。节点隔离就是我们常说的STONITH（Shoot The Other Node In the Head ，俗称“爆头”)，意思就是直接切断电源；常用的方法是所有节点都接在一个电源交换机上，如果有故障，就直接导致该节点的电压不稳定，或断电，让有故障的节点重启或关闭。（如下图），而资源隔离，就是 fencing 直接把某种资源截获过来。
下面我们再来说一说“心路线”的类型，一种是串行电缆，另一种就是我们常看到的以太网线（交叉的双绞线），它们各有优缺点，串行电缆，被认为是比以太网连接安全性稍好些的连接方式，因为hacker无法通过串行连接运行诸如telnet、ssh或rsh类的程序，从而可以降低其通过已劫持的服务器再次侵入备份服务器的几率。但串行线缆受限于可用长度，因此主、备服务器的距离必须非常短。以太网线连接，使用此方式可以消除串行线缆的在长度方面限制，并且可以通过此连接在主从服务器之间同步文件系统，从而减少了对正常通信连接带宽的占用。（如下图）
九、高可用资源类型以及属性
⒈CRM要管理的资源的类型有：
①primitive : 也称为local类型，同一时刻只能运行在一个节点上
②group ：组资源，将多个资源定义成一个组，这个组在同一时刻运行在一个节点上 ，同进同退
③clone ：需要同时运行在多个节点上的资源 ，允许无限克隆，如集群文件系统分布式锁程序，STONITH进程
④Master-slave ：特殊的clone资源，需要运行在2个节点，只能克隆2分，并且是一主一从的
上面提到了资源的同进同退，这又涉及到资源的属性
⒉资源属性
资源属性，也称之为资源约束（Constraint）：每个资源之间的关系，资源与资源的倾向性；资源间的约束关系可以定义故障节点上的资源进行转移的位置。
资源约束一共有3种：
①排列约束 (colocation)：它定义了资源间的排列关系，资源是否能够运行于同一节点。如：ip地址要不要和web服务运行在一起等 有了这样一个约束，RA可以根据其约束关系来判定某一资源到底要运行在同一节点
score:
正值：可以在一起 >0 inf: 正无穷
负值：不能在一起 <0 -inf: 负无穷
② 位置约束 (location)：定义了某个资源更倾向于运行在哪个节点上
整数值，score(分数)
正值：倾向于此节点
负值：倾向于逃离于此节点
③ 顺序约束 (order)：定义了资源的启动顺序，例如，共享存储要先于web服务进行启动
资源最终运行在哪个节点，取决于所有资源，所有约束分数和的大小。
十、RA（ResourceAgent）类型
既然有以上资源，那么如何使这些资源在各节点上运行起来呢？？
这就需要有一个资源代理（RA），在某一时刻资源代理来管理各节点上资源的动作，即资源代理就是当某一节点上的资源出现故障，它可以将该资源在另外节点上启动起来的一个脚本程序。
RA的类型有：
①Heartbeat v1
②LSB:linux standard base--linux标准库，只有start|stop|restart|status 四个参数
③OCF:open cluster framework 能力比LSB更强，可提供更多参数
④STONITH:隔离
十一、脑裂 split-brain
脑裂，脑裂即集群的各节点之间无法互相通知集群信息了，但是节点本身仍然是运行的，这样一来，各节点间无法探测到彼此的心跳信息了，那么彼此就会以为对方节点出现故障了，因此就会在彼此之间产生资源争用，这在集群中是不允许的；
那么一旦出现这种状况，首先要解决的问题就是，一旦某一节点故障，其他节点是否还能称之为集群继续运行，这要取决于一种仲裁机制：quorum—法定票数，我们每个节点都持有票数，当一个节点出现故障的时候，可以根据当前状态的集群所持有的票数占上一个状态上的集群票数的多少来判定它是否还能够以集群的身份予以运行，如果法定票数超过半数以上，我们就称之为集群继续运行，如果不到一半，各节点就会认为其不再是集群中的一员，再运行资源也没有什么意义了，它就会自动放弃自身资源，不再运行，这就避免了资源间的争用；
计算节点是否能当做集群来运行，这要有一个节点来作为DC:Designated Coordinator—指定的协调员完成。
有一种特殊的情况：如果是2节点的集群，当其中一个节点出现故障了，按照我们此前的说法，任一节点持有的票数都不超过一半，那么它就会自动放弃本身的资源了，显然是不行的，在这种情况下，就不能采取法定票数这种策略了，这种情况下，RHCS套件借助了额外手段：在2节点集群中，引入一个共享磁盘，2节点可以通过和共享磁盘通信 机制来判定它是否正常运行，如果某一节点不再和共享磁盘进行通信，就可以认为它故障了，另一节点可以继续提供服务，这时的共享磁盘就是一个伪节点的存在，称之为仲裁磁盘。还有一种方式即ping node，可以设置集群内的节点ping某个设备，既不能通信，又不能ping通，即认为自己不再是集群。