Linux 高可用（HA）集群基本概念详解

大纲

1、高可用集群的定义

2、高可用集群的衡量标准

3、高可用集群的层次结构

4、高可用集群的分类

5、高可用集群经常使用软件

6、共享存储

7、集群文件系统与集群LVM

8、高可用集群的工做原理

1、高可用集群的定义

   高可用集群，英文原文为High Availability Cluster，简称HACluster，简单的说，集群（cluster）就是一组计算机，它们做为一个总体向用户提供一组网络资源。这些单个的计算机系统 就是集群的节点（node）。

   高可用集群的出现是为了使集群的总体服务尽量可用，从而减小由计算机硬件和软件易错性所带来的损失。若是某个节点失效，它的备援节点将在几秒钟的时间内接管它的职责。所以，对于用户而言，集群永远不会停机。

   高可用集群软件的主要做用就是实现故障检查和业务切换的自动化。只有两个节点的高可用集群又称为双机热备，即便用两台服务器互相备份。当一台服务器出现故障时，可由另外一台服务器承担服务任务，从而在不须要人工干预的 状况下，自动保证系统能持续对外提供服务。双机热备只是高可用集群的一种，高可用集群系统更能够支持两个以上的节点，提供比双机热备更多、更高级的功能，更能知足用户不断出现的需求变化。

2、高可用集群的衡量标准  
   HA(High Available), 高可用性群集是经过系统的可靠性(reliability)和可维护性(maintainability)来度量的。工程上，一般用平均无端障时间(MTTF)来度量系统的可靠性,用平均维修时间（MTTR）来度量系统的可维护性。因而可用性被定义为：HA=MTTF/(MTTF+MTTR)*100%

   具体HA衡量标准:

• 99% 一年宕机时间不超过4天

• 99.9% 一年宕机时间不超过10小时

• 99.99% 一年宕机时间不超过1小时

• 99.999% 一年宕机时间不超过6分钟

3、高可用集群的层次结构

   说明：高可用集群可分为三个层次结构，分别由红色部分的Messaging与Membership层，蓝色部分的Cluster Resource Manager（CRM）层，绿色部分的Local Resource Manager（LRM）与Resource Agent（RA）组成，下面咱们就来具体说明（如上图），

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（主节点）上的文档是能够修改的，其余CIB都是复制DC上的那个文档而来的。对于LRM,是执行CRM传递过来的在本地执行某个资源的执行和中止的具体执行人。当某个节点发生故障以后，是由DC经过PE（策略引擎）和TE（实施引擎）来决定是否抢夺资源。

3.资源代理层（Resource Agents），集群资源代理(可以管理本节点上的属于集群资源的某一资源的启动，中止和状态信息的脚本)，资源代理分为：LSB（/etc/init.d/*）,OCF(比LSB更专业，更加通用),Legacy heartbeat（v1版本的资源管理）。

核心组件的具体说明（如上图）：

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.stonithd组件

   STONITH(Shoot The Other Node in the Head，”爆头“)， 这种方式直接操做电源开关，当一个节点发生故障时，另 一个节点若是能侦测到，就会经过网络发出命令，控制故障节点的电源开关，经过暂时断电，而又上电的方式使故障节点被重启动， 这种方式须要硬件支持。

   STONITH应用案例（主从服务器），主服务器在某一端时间因为服务繁忙，没时间响应心跳信息，若是这个时候备用服务器一会儿把服务资源抢过去，可是这个时候主服务器尚未宕掉，这样就会致使资源抢占，就这样用户在主从服务器上都能访问，若是仅仅是读操做还没事，要是有写的操做，那就会致使文件系统崩溃，这样一切都玩了，因此在资源抢占的时候，能够采用必定的隔离方法来实现，就是备用服务器抢占资源的时候，直接把主服务器给STONITH，就是咱们常说的”爆头 ”。

4、高可用集群的分类    
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.

5、高可用集群软件

Messaging and Membership Layer（信息与关系层）：

• heartbeat (v1,v2,v3)，heartbeat v3 分拆  heartbeat pacemaker cluster-glue

• corosync

• cman

• keepalived

• ultramokey

Cluster Resource Manager Layer（资源管理层，简称:CRM）：

• haresource,crm (heartbeat v1/v2)

• pacemaker (heartbeat v3/corosync)

• rgmanager (cman)

经常使用组合：

• heartbeat v2+haresource(或crm) (说明：通常经常使用于CentOS 5.X)

• heartbeat v3+pacemaker (说明：通常经常使用于CentOS 6.X)

• corosync+pacemaker (说明：如今最经常使用的组合)

• cman + rgmanager (说明：红帽集群套件中的组件，还包括gfs2,clvm)

• keepalived+lvs (说明：经常使用于lvs的高可用)

总结：咱们常常在技术博客中看到，heartbeat+pacemaker实现mysql高可用，或corosync+pacemaker实现mysql高可用等，有的博友会问了，咱们到底用什么好呢？通过上面的说明你们应该有所了解！

6、共享存储

   说到集群， 咱们不得不说到，共享存储，由于无论理是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）存取快，块级别，廉价

7、集群文件系统与集群LVM（集群逻辑卷管理cLVM）

集群文件系统：gfs二、ocfs2

集群LVM：cLVM

注：通常用于高可用双主模型中（以下图）

8、高可用集群的工做原理

说明：这里主要以主/从节点的高可用来讲明工做原理。

   主服务器和从服务器创建双机热备，基本上都是共享一个存储，以mysql为例。一般状况下，数据库文件挂载在主数据库服务器上，用户链接到主服务器上进行数据库操做。当主服务器出现故障时，从服务器就会自动挂载数据库文件，并接替主服务器的工做。用户在未通知的状况下，经过从数据库链接到数据库文件进行操做。等主服务器的故障修复以后，又能够从新提供服务；

   那么，从服务器是如何知道主服务器挂掉了呢，这就要使用必定的检测机制，如心跳检测，也就是说每个节点都会按期向其余节点通知本身的心跳信息，尤为是主服务器，若是从服务器在几个心跳周期内（可自行设置心跳周期）尚未检测到的话，就认为主服务器宕掉了，而这期间在通告心跳信息固然不能使用tcp传输的，若是使用tcp检测，还要通过三次握手，等手握完了，不定通过几个心跳周期了，因此在检测心跳信息的时候采用的是udp的端口694来进行传递信息的，若是主服务器在某一端时间因为服务繁忙，没时间响应心跳信息，这个时候从服务器要是把主服务资源抢过去（共享数据文件），可是这个时候主服务器尚未宕掉，这样就会致使资源抢占，就这样用户在主从上都能访问，若是仅仅是读操做还没事，要是有写的操做，那就会致使文件系统崩溃，这样一切都玩了，因此在资源抢占的时候，能够采用必定的隔离方法来实现，就是从服务器抢占资源的时候，直接把主服务器给“STONITH”，就是咱们常说的“爆头”；

   那么，咱们又用什么方式来检测心跳信息呢？就是经过心跳线来检测。运行在从服务器上的Heartbeat能够经过以太网链接检测主服务器的运行状态，一旦其没法检测到主服务器的“心跳”则自动接管主服务器的资源。一般状况下，主、从服务器间的心跳链接是一个独立的物理链接，这个链接能够是串行线缆、一个由“交叉线”实现的以太网链接。Heartbeat甚至可同时经过多个物理链接检测主服务器的工做状态，而其只要能经过其中一个链接收到主服务器处于活动状态的信息，就会认为主服务器处于正常状态。从实践经验的角度来讲，建议为Heartbeat配置多条独立的物理连，以免Heartbeat通讯线路自己存在单点故障。

   上面的原理中咱们提到了“隔离方法”，下面咱们来讲一说，隔离方法有两种，一种是节点隔离，另外一种是资源隔离。节点隔离就是咱们常说的STONITH（Shoot The Other Node In the Head ，俗称“爆头”)，意思就是直接切断电源；经常使用的方法是全部节点都接在一个电源交换机上，若是有故障，就直接致使该节点的电压不稳定，或断电，让有故障的节点重启或关闭。（以下图），而资源隔离，就是 fencing 直接把某种资源截获过来。

   下面咱们再来讲一说“心路线”的类型，一种是串行电缆，另外一种就是咱们常看到的以太网线（交叉的双绞线），它们各有优缺点，串行电缆，被认为是比以太网链接安全性稍好些的链接方式，由于hacker没法经过串行链接运行诸如telnet、ssh或rsh类的程序，从而能够下降其经过已劫持的服务器再次侵入备份服务器的概率。但串行线缆受限于可用长度，所以主、备服务器的距离必须很是短。以太网线链接，使用此方式能够消除串行线缆的在长度方面限制，而且能够经过此链接在主从服务器之间同步文件系统，从而减小了对正常通讯链接带宽的占用。（以下图）

参考文档：

http://www.linux-ha.org/wiki/Main_Page

http://clusterlabs.org/wiki/Main_Page

http://opencf.org/home.html