首页 > 代码库 > 高可用集群软件Heartbeat介绍
高可用集群软件Heartbeat介绍
一、Heartbeat的定义
Heartbeat 项目是 Linux-HA 工程的一个组成部分，也是目前开源HA项目中最成功的一个例子，Linux-HA的全称是High-Availability Linux，这个开源项目的目标是：通过社区开发者的共同努力，提供一个增强linux可靠性（reliability）、可用性（availability）和可服务性（serviceability）（RAS）的群集解决方案，它实现了一个高可用集群系统。心跳服务和集群通信是高可用集群的两个关键组件，在 Heartbeat 项目里，由 heartbeat 模块实现了这两个功能。
Linux-HA的官方网站：
http://www.linux-ha.org
http://hg.linux-ha.org
二、HA集群中的相关术语
1）节点（node）
运行heartbeat进程的一个独立主机，称为节点，节点是HA的核心组成部分，每个节点上运行着操作系统和heartbeat软件服务，在heartbeat集群中，节点有主次之分，分别称为主节点和备用/备份节点，每个节点拥有唯一的主机名，并且拥有属于自己的一组资源，例如，磁盘、文件系统、网络地址和应用服务等。主节点上一般运行着一个或多个应用服务。而备用节点一般处于监控状态。
2）资源（resource）
资源是一个节点可以控制的实体，并且当节点发生故障时，这些资源能够被其它节点接管，heartbeat中，可以当做资源的实体有：
磁盘分区、文件系统
IP地址
应用程序服务
NFS文件系统
3）事件（event）
也就是集群中可能发生的事情，例如节点系统故障、网络连通故障、网卡故障、应用程序故障等。这些事件都会导致节点的资源发生转移，HA的测试也是基于这些事件来进行的。
4）动作（action）
事件发生时HA的响应方式，动作是由shell脚步控制的，例如，当某个节点发生故障后，备份节点将通过事先设定好的执行脚本进行服务的关闭或启动。进而接管故障节点的资源。
三、Heartbeat的版本与组件
说明：Heartbeat有三个版本分别为Heartbeat v1.x，Heartbeat v2.x，Heartbeat v3.x。Heartbeat v1.x和Heartbeat v2.x版本的组成结构十分简单，所有模块都集中在heartbeat中，到了v3版本后，整个heartbeat项目进行了拆分，分为不同的项目来分别进行开发。
1）Heartbeat v1.x与v2.x的组件
heartbeat：节点间通信检测模块
ha-logd：集群事件日志服务
CCM（Consensus Cluster Membership）：集群成员一致性管理模块
LRM （Local Resource Manager）：本地资源管理模块
Stonith Daemon： 使出现问题的节点从集群环境中脱离或重启
CRM（Cluster resource management）：集群资源管理模块
Cluster policy engine： 集群策略引擎
Cluster transition engine：集群转移引擎（也叫策略执行引擎）
Heartbeat v1.x与Heartbeat v2.x区别：在Heartbeat v2.x中增加了一个新的集群资源管理器crm，在Heartbeat v1.x中的集群资源管理器是haresource，Heartbeat v2.x中为了兼容v1.x保留了haresource，但同时又新增了一个功能更强大的crm资源管理器。crm管理方式有，一种是基于命令行crmsh，一种是基于图形界面的hb_gui。
2）Heartbeat v3.x的组件
Heartbeat：将原来的消息通信层独立为heartbeat项目，新的heartbeat只负责维护集群各节点的信息以及它 们之前通信。
Cluster Glue：相当于一个中间层，它用来将heartbeat和pacemaker关联起来，主要包含2个部分，即为LRM 和STONITH。
Resource Agent：用来控制服务启停，监控服务状态的脚本集合，这些脚本将被LRM调用从而实现各种资源 启动、停止、监控等等。
Pacemaker：也就是Cluster Resource Manager（集群资源管理器，简称CRM），用来管理整个HA的控制中 心，客户端通过pacemaker来配置管理监控整个集群。
四、Heartbeat的各版本之间的区别
与v1.x风格相比，Heartbeat v2.x版本之后功能变化如下:
1）保留原有所有功能
2）自动监控资源
默认情况下每2分钟检测资源运行情况，如果发现资源不在，则尝试启动资源， 如果60s后还未启动成功，则资源切换向另节点。时间可以修改。
3）可以对各资源组实现独立监控
比如apache运行在node1上，mysql运行在node2上，Heartbeat可同时实现两台主机的服务监控
4）同时监控系统负载
可以自动将资源切换到负载低的node上
5）新增crm资源管理器
crm管理器可以让heartbeat基于图形界面管理，即hb_gui
与v2.x风格相比，Heartbeat 3最主要变化是功能拆分，Heartbeat官方最后一个STABLE release 2.x 版本是2.1.4，Heartbeat 3官方正式发布的首个版本是3.0.2，Heartbeat 3与Heartbeat2.x的最大差别在于，Heartbeat3.x按模块把的原来Heartbeat2.x拆分为多个子项目，但是HA实现原理与Heartbeat2.x基本相同，配置也基本一致。
五、heartbeat集群中的概念解析
ha_aware：如果一个应用程序自己能够利用底层心跳信息传递层的功能完成集群事物决策的过程的软件就叫ha_aware。
DC：Designated Coordinator选定的协调员，当DC所在的主机挂了就会先选出一个DC，再由DC做出事物的决策。注意：在高可用集群中最核心的、最底层的管理的单位叫资源，把资源组合在一起来组合成一个服务。
CRM：Cluster Resources Manager集群资源管理，真正做出决策的是CRM。
高可用集群中任何资源都不应该自行启动，而是由CRM管理启动启动的；
heartbeat v1版时就有了资源管理的概念，而v1版的资源就是heartbeat自带的，叫haresources，这个文件是个配置文件；而这个配置文件接口就叫haresources；
当heartbeat v2第二版的时候，heartbeat被做了很大的改进，自己可以做为一个独立进程来运行，并而可以通过它接收用户请求，它就叫crm，在运行时它需要在各节点上运行一个叫crmd的进程，这个进程通常要监听在一个套接字上，端口就是5560，所以服务器端叫crmd，而客户端叫crm(可以称为crm shell)，是个命令行接口，通过这个命令行接口就可以跟服务器端的crm通信了，heartbeat也有它的图形化界面工具，就叫heartbeat-GUI工具，通过这个界面就可以配置进行。
第三版heartbeat v3，被独立成三个项目heartbeat、pacemaker(心脏起博器)、cluster-glue(集群的贴合器)，架构分离开来了，可以结合其它的组件工作了。
RA：resource agent资源代理，其实就是能够接收CRM的调度用于实现在节点上对某一个资源完成管理的工具，这个管理的工具通常是脚本，所以我们通常称为资源代理。任何资源代理都要使用同一种风格，接收四个参数：{start|stop|restart|status}，包括配置IP地址的也是。每个种资源的代理都要完成这四个参数据的输出。
失效转移(failover)：当某一个节点出现故障时，其上面的资源被自动转移到其它正常的备用节点上并启动的这个过程叫故障转移，也称为失效转移。
故障转回(failback)：如果出现故障的节点又回来的，那我们就要把这个节点添加回来，那这个添加回来的过程我们就叫失效转回，也称故障转回。
资源争用、资源隔离：
万一集群发生分裂时，为了避免不再成为集群上的节点继续使用资源而发生资源争用情况，导致有挂载文件系统的系统文件发生崩溃，成为新的集群的就会给不再成为集群的节点补一枪，让不是集群节点的服务死透，不再接收请求，这就叫stonith(shoot the other node in the head)，而这种功能就叫资源隔离。争用共享存储的后果是非常严重的，轻则共享存储崩溃，重则整个文件系统都崩溃，数据全部丢失。
资源隔离有两种级别：
节点级别：这种就叫STONITH，这种就是不管怎么样直接把对方的电源给切断，一般这种主机都是连接到电源交换机上的。
资源级别：这种需要依赖一些硬件设备来完成，比如连接到共享存储的光纤交换机，把需要踢除出去的节点的光纤接口屏蔽了，这种就叫资源级别的隔离。
对于服务器左右分隔的这种情况通常称为脑裂(brain-split)，左右不协调了，在高可以用集群中避免资源争用完成资源隔离是我们在设计高可用集群中必须要考滤的问题。
两个节点的模式下，一旦发生集群分隔以后，其中一个节点发生故障，在我们无法判定哪个节点不正常的时候，而正常的节点一定是可以连到互联网上去的，这样的话就说明正常的节点是可以跟前端路由通信的，所以我们就把前端路由当成第三个节点，这里我们称为ping节点，当每个节点联系到对方之后先去ping前端的节点，如果可以ping通，那就说明自己是正常的，就说明该节点是有多票法定票数的节点，而前端的ping节点就叫仲裁设备，帮助节点判断哪个节点是优胜一方的，偶数节点数时就会借助于仲裁设备。
RHCS不是使用ping节点来判断的，他是使用了一个共享存储的设备，偶数个节点处于活动的节点不断的往磁盘中写数据，按照心跳信息频率每隔一个信息频率就往磁盘里写一个数据位，只要这个设备每隔一个心跳时间间隔就更新一次数据位，就说明这个设备处于活动状态的，如果发现节点多次没有写数据位了就认为节点挂了，这种也叫仲裁设备(qdisk)。仲裁设备又有两种：分别为ping node和qdisk；
那心跳是怎么传递的呢，在多台主机之机又是怎么互相工作良好呢，如图：高可用主从的两个节点；
信息层(Messaging Layer)：主从两个节点的心跳信息都要基于信息层来实现，也叫底层基础架构层，用于传递心跳信息的，而能够实现这种功能的有Corosync和heartbeat，corosync是openAIS的一个组件，
资源分配层(Resource Allocation)：也叫资源管理器层，这层的核心组件叫CRM(Cluster Resourcce Manager集群资源管理器)，CRM上必须有一个资源被推举成为管理者的，叫Leader，它的工作是决策集群中的所有事物的，这里称为DC(Designated Coordinator指定协调员)，任何DC上会额外运行两个进程，一个叫PE(Policy Engine策略引擎)，所谓策略引擎就是将底层信息层收集整个集群中所有节点上的信息在本地生成一个大图big pic来策略节点运行在哪个节点上，并通知其实节点上的资源管理器来实现资源的启动和关闭等操作；一个叫TE(Transition Engine 传输引擎)，它主要是把PE做出的决策通告给对应节点的CRM；
集群资源管理器必须借助于Messageing Layer通告给每一个节点，自动的广播或组播给每一个节点，这样就保证了每一个节点上的信息都是一样的，而这些数据在计算机中又怎么样来交互数据的呢，这里就要基于扩展标记语言来实现数据的格式传递的，这种叫半结构化数据基于XML的，所以在各节点之间实现配置信息保存都是通过XML文件保存的，而要能够理解这个XML文件保存的信息使用到一个工具叫CIB(Cluster Information Base集群信息库)；只要能连接到CRM上都可以去配置这个XML文件，首先它会先保存到DC的XML中，然后再由DC同步支每个节点上的XML文件中去的；
Resources层：而PE(策略引擎)就是根据XML这个库来获取资源的配置信息的，并通过Messaging Layer不获取当前节点的活动信息，而后做出决策，一旦做得决策就要启动资源了；所以PE借助于本地的Messaging Layer通知给其实节点的集群信息库来实现对某些资源信息的传递，比如说通告其它CRM要启动某一资源了，收到信息后CRM并不负责启动，转由LRM(Local Resource Manager本地资源管理)启动，每个节点上都运行在这个LRM，而并发资源又借助于RA(Resource Agent资源代理)实现资源管理，这就是它的工作原理；CRM负责收集信息，推举为DC的由PE运行，PE负责整合整个集群中的所有资源，并确保某些资源在合适的节点上运行起来，一旦做出决策就会通告给其它节点上的CRM，对应节点上的CRM收到通告以后会调用自己的LRM，由LRM指挥RA完成相关的操作；
文章内容多参考：http://blog.csdn.net/sdd00001/article/details/21464713
http://tanxw.blog.51cto.com/4309543/1401096?utm_source=tuicool&utm_medium=referral
本文出自 “IT小二郎” 博客，请务必保留此出处http://jerry12356.blog.51cto.com/4308715/1855377
高可用集群软件Heartbeat介绍