001.Heartbeat简介

一 Heartbeat简介

1.1 概述

Heartbeat是Linux-HA项目中的一个组件,也是当前开源HA项目中最成功的一个例子,它提供了所有HA软件所需要的基本功能,如心跳检测和资源接管、监测群集中的系统服务、在群集中的节点间转移共享IP地址的所有者等。heartbeat最核心的功能包括两个部分,心跳监测和资源接管。心跳监测可以通过网络链路和串口进行,而且支持冗 余链路,它们之间相互发送报文来告诉对方自己当前的状态,如果在指定的时间内未收到对方发送的报文,那么就认为对方失效,这时需启动资源接管模块来接管运行在对方主机上的资源或者服务。

1.2 相关概念

节点(node):运行heartbeat进程的一个独立主机,称为节点,节点是HA的核心组成部分,每个节点上运行着操作系统和heartbeat软件服务,在heartbeat集群中,节点有主次之分,分别称为主节点和备用/备份节点,每个节点拥有唯一的主机名,并且拥有属于自己的一组资源,例如,磁盘、文件系统、网络地址和应用服务等。主节点上一般运行着一个或多个应用服务,而备用节点一般处于监控状态。

资源(resource):资源是一个节点可以控制的实体,并且当节点发生故障时,这些资源能够被其它节点接管,heartbeat中,可以当做资源的实体通常有:

  • 磁盘分区、文件系统
  • IP地址
  • 应用程序服务
  • NFS文件系统

事件(event):也就是集群中可能发生的事情,例如节点系统故障、网络连通故障、网卡故障、应用程序故障等。这些事件都会导致节点的资源发生转移,HA的测试也是基于这些事件来进行的。

动作(action):事件发生时HA的响应方式,动作是由shell脚步控制的,例如,当某个节点发生故障后,备份节点将通过事先设定好的执行脚本进行服务的关闭或启动,进而接管故障节点的资源。

1.3 Heartbeat 2.x组件

Heartbeat提供了高可用集群最基本的功能,例如,节点间的内部通信方式、集群合作管理机制、监控工具和失效切换功能等等,目前的最新版本是Heartbeat3.x,Heartbeat 2.x内部组成主要分为以下几大部分:

  • heartbeat: 节点间通信检测模
  • Heartbeat支持通过以下网络链接类型进行群集通信:
    • 单播UDP over IPv4;
    • 广播UDP over IPv4;
    • 多播UDP over IPv4;
    • 串行链路通信。
  • ha-logd: 集群事件日志服务
  • CCM(Consensus Cluster Membership):集群成员一致性管理模块
    • CCM提供强关联的共识集群成员资格服务。它确保计算成员资格中的每个节点都可以与此相同成员资格中的每个其他节点进行通信。
  • LRM (Local Resource Manager):本地资源管理模块
  • Stonith Daemon: 使出现问题的节点从集群环境中脱离
  • CRM(Cluster resource management):集群资源管理模块
  • Cluster policy engine: 集群策略引擎
  • Cluster transition engine:集群转移引擎

001.Heartbeat简介_第1张图片

1.4 Heartbeat 3.x组件

Heartbeat:将原来的消息通信层独立为heartbeat项目,新的heartbeat只负责维护集群各节点的信息以及它们之前通信;

Cluster Glue:相当于一个中间层,它用来将heartbeat和pacemaker关联起来,主要包含2个部分,即为LRM和STONITH;

Resource Agent:用来控制服务启停,监控服务状态的脚本集合,这些脚本将被LRM调用从而实现各种资源启动、停止、监控等等;

Pacemaker:即Cluster Resource Manager(集群资源管理器,简称CRM),用来管理整个HA的控制中心,客户端通过pacemaker来配置管理监控整个集群;

Pacemaker 提供了多种用户管理接口,分别如下:

  • 基于命令的管理方式
    • crmsh
    • pcs
  • 基于图形界面的管理方式
    • pygui
    • hawk
    • LCMC
    • pcs
  • Pacemaker内部组件与模块

001.Heartbeat简介_第2张图片

  • Heartbeat v3.x 内部组件

001.Heartbeat简介_第3张图片

更多说明参考:http://clusterlabs.org/

1.5 Heartbeat特性

Heartbeat,它仅仅提供HA基本功能,能完成心跳监控和资源接管,但不会监视它控制的资源或应用程序,要监控资源和应用程序是否运行正常,必须结合第三方的插件,例如ipfail、Mon、Ldirector等。

Heartbeat自身包含了几个插件,分别是ipfail、Stonith和Ldirectord:

ipfail的功能直接包含在Heartbeat里面,主要用于检测网络故障,并作出合理的反应。ipfail使用ping节点或者ping节点组来检测网络连接是否出现故障,从而及时的做出转移措施。

Stonith插件可以在一个没有响应的节点恢复后,合理接管集群服务资源,防止数据冲突。当一个节点失效后,会从集群中删除,如果不使用Stonith插件,那么失效的节点可能会导致集群服务在多于一个节点运行,从而造成数据冲突甚至是系统崩溃。因此,使用Stonith插件可以保证共享存储环境中的数据完整性。

Ldirector是一个监控集群服务节点运行状态的插件。Ldirector如果监控到集群节点中某个服务出现故障,就屏蔽此节点的对外连接功能,同时将后续请求转移到正常的节点提供服务,这个插件经常用在LVS负载均衡集群中。

同样,对于操作系统自身出现的问题,Heartbeat也无法监控,如果主节点操作系统挂起,一方面可能导致服务中断,另一方面由于主节点资源无法释放,而备份节点却接管了主节点的资源,此时就发生了两个节点同时争用一个资源的状况。

为防止此情况发生,需要在linux内核中启用一个叫watchdog的模块,watchdog是一个Linux内核模块,它通过定时向/dev/watchdog设备文件执行写操作,从而确定系统是否正常运行,如果watchdog认为内核挂起,就会重新启动系统,进而释放节点资源。

在linux中完成watchdog功能的软件叫softdog,softdog维护一个内部计时器,此计时器在一个进程写入/dev/watchdog设备文件时更新,如果softdog没有看到进程写入/dev/watchdog文件,就认为内核可能出了故障。watchdog超时周期默认是一分钟,可以通过将watchdog集成到Heartbeat中,从而通过Heartbeat来监控系统是否正常运行。

1.6 Heartbeat工作原理

heartbeat内部结构有三大部分组成:

集群成员一致性管理模块(CCM)用于管理集群节点成员,同时管理成员之间的关系和节点间资源的分配,heartbeat模块负责检测主次节点的运行状态,以决定节点是否失效。ha-logd模块用于记录集群中所有模块和服务的运行信息。

本地资源管理器(LRM)负责本地资源的启动,停止和监控,一般由LRM守护进程lrmd和节点监控进程(Stonith Daemon)组成,lrmd守护进程负责节点间的通信,Stonith Daemon通常是一个Fence设备,主要用于监控节点状态,当一个节点出现问题时处于正常状态的节点会通过Fence设备将其重启或关机以释放IP、磁盘等资源,始终保持资源被一个节点拥有,防止资源争用的发生。

    集群资源管理模块(CRM)用于处理节点和资源之间的依赖关系,同时,管理节点对资源的使用,一般由CRM守护进程crmd、集群策略引擎和集群转移引擎三个部分组成,集群策略引擎(Cluster policy engine)具体实施这些管理和依赖,集群转移引擎(Cluster transition engine)监控CRM模块的状态,当一个节点出现故障时,负责协调另一个节点上的进程进行合理的资源接管。

    在Heartbeat集群中,最核心的是heartbeat模块的心跳监测部分和集群资源管理模块的资源接管部分,心跳监测一般由串行接口通过串口线来实现,两个节点之间通过串口线相互发送报文来告诉对方自己当前的状态,如果在指定的时间内未受到对方发送的报文,那么就认为对方失效,这时资源接管模块将启动,用来接管运行在对方主机上的资源或者服务。

二 Heartbeat配置文件解析

2.1 ha.cf

主要配置项及解析如下:/usr/local/heartbeat/etc/ha.d/ha.cf

  1 #debugfile /var/log/ha-debug	#记录Heartbeat调试日志信息
  2 #logfile    /var/log/ha-log	#记录Heartbeat其他相关日志信息
  3 logfacility local0		#设置heartbeat的日志,这里用的是系统日志
  4 #keepalive 2			#设定心跳(监测)时间间隔为2秒
  5 #deadtime 30

解释:多长时间宣告节点死亡,即指定若备用节点在30秒内未收到主节点心跳信号,则判断死亡,接管主服务器资源。

  1 #warntime 10

解释:指定心跳延迟的时间为10秒,10秒内备节点不能接收主节点心跳信号,即往日志写入警告日志,但不会切换服务。

  1 #initdead 120

解释:初始化时间,节点重启后等待网络启动需要一定时间,因此预留系统启动或重启后忽略的时间段,取值至少为deadtime的两倍。

  1 #udpport    694			#用于通信的UDP端口
  2 #baud   19200			#串口波特率
  3 #serial /dev/ttyS0  # Linux
  4 #serial /dev/cuaa0  # FreeBSD
  5 #serial /dev/cuad0  # FreeBSD 6.x
  6 #serial /dev/cua/a  # Solaris	#各操作系统串口名字
  7 #bcast  eth0        # Linux
  8 #bcast  eth1 eth2   # Linux
  9 #bcast  le0         # Solaris
 10 #bcast  le1 le2     # Solaris	#接受广播心跳的网卡接口
 11 #   mcast [dev] [mcast group] [port] [ttl] [loop]	#设置多播心跳检测及设备,实例如下
 12 #mcast eth0 225.0.0.1 694 1 0	#配置为UDP多播监测心跳
 13 
 14 #   ucast [dev] [peer-ip-addr]				#设置单播心跳检测及设备,示例如下
 15 #   [dev]			#发送和接受心跳的设备
 16 #   [peer-ip-addr]		#发送数据包到的对等点的IP地址
 17 #ucast eth0 192.168.1.2		#设置本机用于单播检测心跳的网卡及需要检测的对方IP

提示:Bcast、ucast和mcast分别代表广播、单播和多播,是组织心跳的的方式,任选其一。

  1 #auto_failback on

解释:auto_failback指当主节点由失败转为正常后,是否将服务自动切回。

auto_failback的通常可配置以下值:

on:自动故障恢复功能;

off:禁用自动故障恢复;

legacy:在系统中启用自动故障恢复(默认项)。

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

解释:该基本STONITH指令用于支持集群的STONITH设备,从配置文件读取此设备的参数。格式为:

stonith < stonith_type > < configfile >.

  1 #stonith_host *     baytech 10.0.0.3 mylogin mysecretpassword
  2 #stonith_host ken3  rps10 /dev/ttyS1 kathy 0
  3 #stonith_host kathy rps10 /dev/ttyS1 ken3 0

解释:以上为配置fence设置的命令,其命令格式为:

stonith_host

  • :stonith设备连接到的机器,或*表示它可以从任何主机访问。
  • :stonith设备的类型(支持的驱动器列表在/usr/lib/stonith中)。
  • :驱动程序特定的参数,可通过stonith -l -t 查看。

stonith -L:获得受支持的stonith设备的列表;

stonith -h:获取关于支持哪些stonith设备及其详细配置选项的详细信息。

  1 #watchdog /dev/watchdog

解释:watchdog通常用于监听心跳,若一定时间心跳异常,则重启机器。

注意:如果您使用软件watchdog,建议模块添加参数“nowayout=0”,或者编译时不使用CONFIG_WATCHDOG_NOWAYOUT。否则,即使是心跳的有序关闭也会触发重启。

  1 #node   ken3
  2 #node   kathy			#集群节点的名称,必须匹配uname -n的结果。
  3 #ping 10.10.10.254
  4 #ping_group group1 10.10.10.254 10.10.10.253

解释:ping指令以及ping_group指令是用于建立伪集群成员,此两项配置必须与下述ipfail指令一起使用,它们的作用是监测物理链路,即如果集群节点与上述伪设备不相通,那么该节点也将无权接管资源或服务,它将释放掉资源。

  1 #hbaping fc-card-name
  2 #respawn userid /path/name/to/run
  3 #respawn hacluster /usr/lib/heartbeat/ipfail

解释:指定与heartbeat一同启动和关闭的进程及该进程的用户和组,该进程被自动监视,遇到故障则重新启动。最常用的进程是ipfail,该进程用于检测和处理网络故障,需要配合ping语句指定的ping node来检测网络连接。如果你的系统是64bit,请注意该文件的路径。

注意:一般启动时会报错,因为ping和ucast这些配置都需要插件支持,需要将lib64下面的插件软连接到lib目录 才不会抛出异常:

  1 ln -svf /usr/local/heartbeat/lib64/heartbeat/plugins/RAExec/* \
  2 /usr/local/heartbeat/lib/heartbeat/plugins/RAExec/
  3 ln -svf /usr/local/heartbeat/lib64/heartbeat/plugins/* \
  4 /usr/local/heartbeat/lib/heartbeat/plugins/
  5 
  6 #apiauth client-name gid=gidlist uid=uidlist
  7 #apiauth ipfail gid=haclient uid=hacluster	#客户端通过api访问的权限,默认是没有访问权限
  8 
  9 #hopfudge 1			        #最大跳数减去配置中的节点数
 10 #deadping 30			#ping节点的死亡时间
 11 #hbgenmethod time		        #
 12 #realtime off			#默认开启
 13 #debug 1			        #debug级别
 14 
 15 #apiauth ipfail uid=hacluster
 16 #apiauth ccm uid=hacluster
 17 #apiauth cms uid=hacluster
 18 #apiauth ping gid=haclient uid=alanr,root
 19 #apiauth default gid=haclient

解释:设置uid和gid列表,若同时使用这两种方法,那么如果流程符合uid列表或gid列表下的条件,那么它就是授权的。

  1 #msgfmt  classic/netstring		#消息格式,默认为classic
  2 # use_logd yes/no			#是否使用日志守护进程,建议设置为yes
  3 #conn_logd_time 60			#连接失败后重新连接日志守护进程的时间间隔
  4 
  5 #compression    bz2
  6 #compression_threshold 2

解释:配置压缩模块,可以是zlib,也可以是bz2,这取决于系统中是否有对应的库。

配置压缩消息的阈值压缩阈值,若阈值是1,那么任何大小大于1kb的消息都会被压缩,默认值是2(KB)。

参考:

https://blog.csdn.net/beckdon/article/details/45341039

http://www.linux-ha.org/doc/users-guide

https://blog.csdn.net/xxj123go/article/details/72828896

https://blog.csdn.net/liaomin416100569/article/details/76087448

http://blog.chinaunix.net/uid-20788470-id-1841643.html

https://blog.csdn.net/whyhonest/article/details/8171537

http://blog.sina.com.cn/s/blog_7b6fc4c901012om0.html

http://blog.chinaunix.net/uid-20788470-id-1841644.html

你可能感兴趣的:(001.Heartbeat简介)