Linux高可用集群方案之heartbeat基础原理及逻辑架构

 这篇文章我们主要学习heartbeat高可用集群的基础原理及逻辑架构

 ll  本文导航 

  · heartbeat之基本原理

  · heartbeat之版本介绍

  · heartbeat之相关术语

  · heartbeat之集群组件

  · heartbeat之心跳连接

  · heartbeat之配置文件

 ll  要求 

掌握heartbeat高可用集群的相关组件及简单配置

  heartbeat之基本原理 

  heartbeat是一个集群软件，它主要由心跳信息检测和资源管理两大核心部分组成。

  heartbeat构建的集群中，各服务器会向其他集群节点发送心跳信息（报文）并予以收集、分析，以判断该节点的状态，从而认为节点是否有效。当服务器在指定的时长内检测不到其他节点的心跳信息或无法通过网络等方式连接时，会认为对方节点失效，此时，服务器需要启动资源接管模块来接管失效节点上的服务和资源。

  heartbeat仅能完成心跳信息检测和资源监管，不会监视其他资源和应用服务。若要监控其他资源和应用服务是否可用，需要安装第三方插件；如ipfail, ldirectord等。

  同样，对于操作系统自身的问题heartbeat同样无法监控。若主节点因操作系统问题无法向备节点发送心跳信息，则备节点无法接收主节点的信息，从而认为主节点已经失效，此时会启动资源接管模块来接管主节点的服务和资源。而主节点资源和服务并没有释放，此时主备节点会发生资源争用的情况，严重时可能会导致共享资源的数据损坏或者文件系统的崩溃。对于linux系统而言，要解决这个问题，需要在内核中开启watchdog模块，开启此模块后，watchdog会定时向/dev/watchdog设备文件执行写操作，从而确定系统是否正常运行。如果watchdog认为内核挂起，就会自动重新启动系统，从而释放节点的服务和资源。

  heartbeat之版本介绍 

  heartbeat分为v1.x和v2.x两个版本，最新的版本为v3.x。

  v2.x的版本是兼容v1.x的配置文件的，从功能的角度来看，v2.x要比v1.x强大很多。而v3.x则是v2.x的修订版本，主要是修复v2.x中的一些bug，最重要的区别是将CRM资源管理器更改pacemaker，并将一些的模块集成到了pacemaker（心脏起搏器）中。基于CentOS6.5，从安装的角度来说，heartbeat-pils包与cluster-glue包冲突，如果使用yum安装，则不会安装安装heartbeat-pils包的，默认是安装cluster-glue包，但是heartbeat v2.x无法调用版本过高的cluster-glue包的。所以在安装的时候，需要手动解决依赖关系。

  1、heartbeat v1.x

    v1.x的资源文件为haresources，配置接口也较haresources。

    heartbeat v1.x允许集群和节点资源通过/etc/ha.d下的两个文件进行配置。

    ha.cf：定义集群节点、失效检测和切换的时间间隔，集群日志机制和Fence方法。

    haresources：定义集群资源组，每行可以定义失效切换的集群节点和一组资源，资源包括IP地址、文

    件系统、应用程序服务和存储等。

  2、heartbeat v2.x

    heartbeat v2.x相较于v1.x做了很大的改动，引进了集群资源管理器CRM，并且2.x基于CRM管理的

    资源文件变更为cib.xml。由于引进了CRM，在运行的heartbeat服务节点上，会独立运行一个进程

    crm，用户可以同过此进程发送请求。而在server端，需要运行crmd进程，它监听在一个套接字上，

    端口是5560。用户可以通过客户端crm向server端发送请求，crm实际上是一个crm shell(crmsh)命

    令行接口，用户可以通过这个接口配置集群服务；另外，heartbeat v2.x还增加了GUI图形配置工具，

    此模块名称就叫heartbeat-gui，用户可以通过此工具在图形化场景中配置集群服务。

    v2.x支持LSB、OCF、STONITH等形式的Resource Agent（资源代理）。

    v2.x支持GUI图形界面的配置和管理工具。

    v2.x对多资源组进行独立监控，不在需要mom或ldirctored等第三方脚本。

    v1.x只支持双节点，而v2.x基于CRM（Cluster Resource Manager）资源管理器模式最多支持16

    个节点。该模式使用基于XML的CIB（Cluster Infomation Base）资源信息的配置。cib文件会在各节

    点间自动复制，可以实现以下操作：

      集群节点的配置、监控；

      集群资源的粘性、约束、组和依赖性的配置；

      日志、监控、仲裁和Fence标准管理；

      当服务失败或设定的标准满足时，需要执行某些动作；

  3、heartbeat v3.x

    在v3.x版本之后，heartbeat在功能上进行了拆分，每个功能模块独立开发为不同的组件。在配置上，

    与v2.x版本基本相同。其架构拆分为heartbeat、pacemaker(心脏起搏器)、cluster-glue(集群黏合

    器)，它们可以结合其他的模块工作。

    heartbeat：负责维护集群节点间的通信以及信息传递。

    pacemaker：也就是CRM，它是管理HA的控制中心，客户端通过它配置和监控整个集群。

    cluster-glue：相当于一个中间件，它将heartbeat和pacmaker关联起来，主要包含LRM和STONITH

    resource agent：用于控制服务的启动和停止，监控脚本服务的脚本集合；LRM调用这些脚本从而

    实现资源的启动、停止和重启等。

  heartbeat之相关术语 

节点（node）

  运行heartbeat进程的一个独立主机，成为节点；node是HA的核心组成部分,每个node上都运行各自独立的操作系统和heartbeat服务。在heartbeat集群软件中，节点分为主节点、备用/备份节点，主、备节点都有各自的hostname，并且拥有各自的一组资源。比如：文件系统、磁盘、ip地址和应用程序服务等。主节点一般运行的一个或多个服务，而备节点则属于监控状态。

资源（resource）

  资源是节点中可控制的实体，当主节点发生故障时，备用节点将接管主节点上的资源。heartbeat服务中可以当作资源的实体有：

  1、文件系统、磁盘分区；

  2、NFS网络存储系统；

  3、IP地址；

  4、应用程序服务；如：httpd、mysqld等

事件（event）

  事件是指集群中可能发生的事情。比如：节点系统故障、网络通信故障、网卡故障、应用程序故障等等，这些事件都可能会导致节点中的资源发生转移。HA的测试也是基于这些事件来进行的。

动作（action）

  动作是指事件发生时HA的响应方式，它是由shell脚本控制的。比如，当主节点发生故障后，备份节点将通过实现设定好的脚本来进行服务的关闭或启动，从而接管故障节点的资源。

  heartbeat之集群组件

heartbeat：heartbeat软件的整个通信模块，所有节点之间的通信都是靠此模块来完成。这个模块会根据不同类型的通信启动不同的事件handler，当监听到不同的通信请求后会交给不同的handler处理。这一点从这个heartbeat日志中可以看出来。

CCM（cluster consensus menbership）：集群共识成员；它起到承上启下的作用。监听底层的心跳信息，当监听不到心跳信息时，将重新计算这个集群的票数和收敛状态信息，并将结果发送给上层处理，上层将通过此结果采取何种决策。ccm还能生成一个集群节点的拓扑概览图，以本节点为参照，保证该节点在特殊情况下能够采取相应的动作。  

CRM（cluster resource manager）：集群资源管理器，也就是pacemaker。它主要管理集群节点服务的资源配置信息，实现对资源的分配与调度。根据资源的配置信息以及运行状态，CRM决定资源该在哪个节点运行，但是，CRM并不直接参与动作，而是交给其他组件完成。CRM通过heartbeat组件收集到的各个成员节点的基本信息转交给CCM来更新整个集群的membership信息。指挥LRM对当前节点的各资源执行 start|stop|restart|status|monitor 等操作，同时接收LRM执行操作后的反馈信息并作出相应的决策进行后续工作。CRM还负责将各个组件反馈回来的信息通过调用设定的日志记录程序记录进日志文件中。

LRM（local resource manager）: 本地资源管理器；它是heartbeat中一个直接操作集群管理中各个资源的模块；负责对资源的启动、停止、重启或监控等；这个模块目前支持4种resource agent，分别是：heartbeat自身、LSB、OCF、STONITH；四种类型调用的脚本位置如下：

    heartbeat：/etc/ha.d/resource.d/

    LSB：/etc/rc.d/init.d/

    OCF：/usr/lib/resource.d/heartbeat/

    STONITH（Shot The Other Node In The heat）：俗称“爆头”；这种方式是直接通过控制电源

开关执行关闭或重新启动节点的方式。在heartbeat高可用集群中，如果主节点因为特殊原因无法与备节点响应心跳信息时，此时备节点会认为主节点已经失效，会立即启动资源接管模块接管主节点上的资源，导致集群中主备节点产生资源争用的情况。为了避免因资源争用导致的文件损坏或文系统奔溃，此时，备节点接管资源后，就会通过网络发送关机或重启的命令给主节点，从而让主节点释放资源，这就是我们所说的“爆头”。需要注意的是，STONITH机制需要硬件的支持。

LRM就是通过调用以上路径下的各个脚本实现对资源的控制，脚本可以自行定义，只需要遵循特定的参数：start|stop|restart|status

PE（policy engine）:  策略引擎；主要负责将CRM发送过来的信息对比配置文件中的参数配置进行计算、分析，并将计算、分析出来的结果通过CRM发送给TE去分析后续需要执行的动作。PE需要计算、分析的信息主要是有哪些节点，各节点的状态，当前管理了哪些资源，各资源当前运行在哪个节点，及资源在各个节点的状态。

TE（translation engine）：主要分析PE的计算结果，然后根据配置信息转换成后续所需的相应操作。

PE和TE并不直接通信，它们都是通过CRM来传递信息的，且PE和TE只有处在active的节点被启动。

CIB（cluster infomation base）：集群信息库；CIB是集群中的各资源配置、节点信息的初始状态及变化后的搜集中心，是一个不断变化的信息库。当集群中资源、节点信息发生变化并被CIB收集到时，CIB会立即更新集群信息库并分发给其他节点，但是，分发动作并不是由CIB本身完成，而是有heartbeat组件完成的。CIB的配置文件名称为cib.xml，CIB在运行时，cib.xml中的配置信息常驻于DC（desginnated coordinator，主节点）的内存中，且只有DC才会经常读取并修改此文件的内容，以保证每个节点的各资源、节点信息的更新至最新状态，其他节点上的cib.xml配置文件都是通过heartbeat组件从DC上复制的。

  heartbeat之心跳连接

heartbeat部署至少需要两台服务器完成。这两台服务器的心跳信息传递通过何种物理链路来进行连接呢？

  1、串行线缆（首选，缺点是距离不能太长）

  2、将一条以太网线连接两台服务器的网卡（推荐）

  3、两台服务器连到同一交换机（次选，增加了交换机设备的故障率；同时，线路不是专用心跳线，容易受其他数据传输的影响）

  heartbeat之配置文件

heartbeat的默认配置文件目录为/etc/ha.d/，此目录下包含authkey、ha.cf、haresources三个主要的配置文件。

ha.cf配置文件部分参数详解：

autojoin    none

#集群中的节点不会自动加入

logfile /var/log/ha-log

#指名heartbaet的日志存放位置

keepalive 2

#指定心跳使用间隔时间为2秒（即每两秒钟在eth2上发送一次广播）

deadtime 30

#指定备用节点在30秒内没有收到主节点的心跳信号后，则立即接管主节点的服务资源

warntime 10

#指定心跳延迟的时间为十秒。当10秒钟内备份节点不能接收到主节点的心跳信号时，就会往日志中写入一个警告日志，但此时不会切换服务

initdead 120

#在某些系统上，系统启动或重启之后需要经过一段时间网络才能正常工作，该选项用于解决这种情况产生的时间间隔。取值至少为deadtime的两倍。

udpport 694

#设置广播通信使用的端口，694为默认使用的端口号。

baud    19200

#设置串行通信的波特率       

bcast   eth0        

# Linux  指明心跳使用以太网广播方式，并且是在eth0接口上进行广播。

#mcast eth0 225.0.0.1 694 1 0

#采用网卡eth0的Udp多播来组织心跳，一般在备用节点不止一台时使用。Bcast、ucast和mcast分别代表广播、单播和多播，是组织心跳的三种方式，任选其一即可。

#ucast eth0 192.168.1.2

#采用网卡eth0的udp单播来组织心跳，后面跟的IP地址应为双机对方的IP地址

auto_failback on

#用来定义当主节点恢复后，是否将服务自动切回，heartbeat的两台主机分别为主节点和备份节点。主节点在正常情况下占用资源并运行所有的服务，遇到故障时把资源交给备份节点并由备份节点运行服务。在该选项设为on的情况下，一旦主节点恢复运行，则自动获取资源并取代备份节点，如果该选项设置为off，那么当主节点恢复后，将变为备份节点，而原来的备份节点成为主节点

#stonith baytech /etc/ha.d/conf/stonith.baytech

# stonith的主要作用是使出现问题的节点从集群环境中脱离，进而释放集群资源，避免两个节点争用一个资源的情形发生。保证共享数据的安全性和完整性。

#watchdog /dev/watchdog

#该选项是可选配置，是通过Heartbeat来监控系统的运行状态。使用该特性，需要在内核中载入"softdog"内核模块，用来生成实际的设备文件，如果系统中没有这个内核模块，就需要指定此模块，重新编译内核。编译完成输入"insmod softdog"加载该模块。然后输入"grep misc /proc/devices"(应为10)，输入"cat /proc/misc |grep watchdog"(应为130)。最后，生成设备文件："mknod /dev/watchdog c 10 130" 。即可使用此功能

node node1.magedu.com  

#主节点主机名，可以通过命令“uanme –n”查看。

node node2.magedu.com  

#备用节点主机名

ping 192.168.12.237

#选择ping的节点，ping 节点选择的越好，HA集群就越强壮，可以选择固定的路由器作为ping节点，但是最好不要选择集群中的成员作为ping节点，ping节点仅仅用来测试网络连接

ping_group group1 192.168.12.120 192.168.12.237

#类似于ping  ping一组ip地址

apiauth pingd  gid=haclient uid=hacluster

respawn hacluster /usr/local/ha/lib/heartbeat/pingd -m 100 -d 5s

#该选项是可选配置，列出与heartbeat一起启动和关闭的进程，该进程一般是和heartbeat集成的插件，这些进程遇到故障可以自动重新启动。最常用的进程是pingd，此进程用于检测和监控网卡状态，需要配合ping语句指定的ping node来检测网络的连通性。其中hacluster表示启动pingd进程的身份。

#下面的配置是关键，也就是激活crm管理，开始使用v2 style格式

crm respawn

#注意，还可以使用crm yes的写法，但这样写的话，如果后面的cib.xml配置有问题

#会导致heartbeat直接重启该服务器，所以，测试时建议使用respawn的写法

#下面是对传输的数据进行压缩，是可选项

compression     bz2

compression_threshold 2

 本文到此先告一段落，欢迎大家指出其中的问题，后续还会不断的完善。