heartbeat高可用详解

文章从理论到实战，内容会比较长，可有选择的阅读。

一、heartbeat的概念
Linux-HA的全称是High-Availability Linux，它是一个开源项目，这个开源项目的目标是：通过社区开发者的共同努力，提供一个增强linux可靠性（reliability）、可用性（availability）和可服务性（serviceability）（RAS）的群集解决方案。其中Heartbeat就是Linux-HA项目中的一个组件，也是目前开源HA项目中最成功的一个例子，它提供了所有 HA 软件所需要的基本功能，比如心跳检测和资源接管、监测群集中的系统服务、在群集中的节点间转移共享 IP 地址的所有者等，自1999年开始到现在，Heartbeat在行业内得到了广泛的应用，也发行了很多的版本，可以从Linux-HA的官方网站www.linux-ha.org下载到Heartbeat的最新版本。

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

2．资源（resource）
  资源是一个节点可以控制的实体，并且当节点发生故障时，这些资源能够被其它节点接管，heartbeat中，可以当做资源的实体有：
  磁盘分区、文件系统
  IP地址
  应用程序服务
  NFS文件系统

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

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

三、Heartbeat的组成与原理
1．Heartbeat的组成
Heartbeat提供了高可用集群最基本的功能，例如，节点间的内部通信方式、集群合作管理机制、监控工具和失效切换功能等
Heartbeat内部组成，主要分为以下几大部分：

heartbeat：节点间通信检测模块
ha-logd：集群事件日志服务
CCM（Consensus Cluster Membership）：集群成员一致性管理模块
LRM （Local Resource Manager）：本地资源管理模块
Stonith Daemon：使出现问题的节点从集群环境中脱离
CRM（Cluster Resource Management）：集群资源管理模块
Cluster Policy Engine：集群策略引擎
Cluster Transition Engine：集群转移引擎

下图显示了Heartbeat2.0内部结构组成：

2．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仅仅是个HA软件，它仅能完成心跳监控和资源接管，不会监视它控制的资源或应用程序，要监控资源和应用程序是否运行正常，必须使用第三方的插件，例如ipfail、Mon、Ldirector等。Heartbeat自身包含了几个插件，分别是ipfail、Stonith和Ldirectord，介绍如下：

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

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

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

四、Heartbeat的配置

1、写在前面

HA即(high available)高可用，又被叫做双机热备，用于关键性业务。简单理解就是，有2台机器 A 和 B，正常是 A 提供服务，B 待命闲置，当 A 宕机或服务宕掉，会切换至B机器继续提供服务。常见的实现高可用的开源软件有 heartbeat 和 keepalived。

这样，一台 web 服务器一天24小时提供web服务，难免会存在 web 服务挂掉或服务器宕机宕机的情况，那么用户就访问不了服务了，这当然不是我们期望的。如果这样，有2台服务器，A对外提供 web 服务，B作为备用，如果A挂掉，那么B立刻替代A的位置去提供 web 服务，这样对用户来说是透明的。但是有个问题，服务器A的 ip 是 1.1.1.1，服务器B的 ip 是 1.1.1.2，显然向用户提供A或B的ip地址是不可行的，因为用户总不能去切换ip来访问的吧。这时heartbeat或keepalived可以提供一个虚拟IP：1.1.1.3，用户只需要访问 1.1.1.3，当A提供服务时，VIP 会设置在A服务器上，当B提供服务时，VIP会设置在B服务器上，这样就可以让用户通过访问 1.1.1.3来获取web服务，即使A或B服务器切换也不影响用户的正常访问。

下面我们使用 heartbeat 来做 HA 集群，并且把 nginx 服务作为 HA 对应的服务，VIP在哪，nginx就在哪台启动，slave那台nginx服务被关闭。

2、准备实验环境

服务器A：
主机名：master
操作系统：CentOS6.6 64位
eth0网卡地址：172.16.87.148
eth1网卡地址：172.16.254.48

服务器B：
主机名：slave
操作系统：CentOS6.6 64位
eth0网卡地址：172.16.87.168
eth1网卡地址：172.16.254.68

虚拟VIP：
VIP：172.16.87.196

eth0网卡用于管理及对外提供服务，eth1网卡用于节点直接的心跳。

3、设置主机名

master节点设置hostname

hostname master
vim /etc/sysconfig/network
编辑配置文件:
HOSTNAME=master

slave节点设置hostname

# hostname slave
# vim /etc/sysconfig/network
编辑配置文件:
HOSTNAME=slave

4、关闭防火墙和selinux(2台节点都要操作)

关闭iptables

# service iptables stop

# chkconfig iptables off

关闭selinux：

# setenforce 0
# sed -i 's/SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config

5、配置hosts文件(2台节点都操作)

# vim /etc/hosts
增加内容如下：
172.16.87.148 master
172.16.87.168 slave

6、安装epel扩展源 (2台都操作)

# yum install -y epel-release

7、安装heartbeat (2台都操作)

# yum install -y heartbeat* libnet nginx

8、主master节点配置

1、拷贝配置文件：

# cd /usr/share/doc/heartbeat-3.0.4/
# cp authkeys ha.cf haresources /etc/ha.d/
# cd /etc/ha.d

2、修改authkeys（26行代码）

# vim authkeys
更改或增加如下内容：
auth 3
3 md5 Hello!
然后修改其权限
# chmod 600 authkeys

3、编辑haresources文件（149行代码）

# vim haresources
加入下面一行：
master 172.16.87.196/24/eth0:10 nginx

说明：master为主节点hostname，172.16.87.196为vip，/24为掩码为24的网段，eth0:10为vip的设备名，nginx为heartbeat监控的服务，也是两台机器对外提供的核心服务。

4、编辑ha.cf（340行代码）

# vim ha.cf
文件中都有相关参数的英文解释，为了不破坏整体性，建议配置在最后追加，追加如下内容：
debugfile /var/log/ha-debug
logfile /var/log/ha-log
logfacility local0
keepalive 2
deadtime 30
warntime 10
initdead 60
udpport 694
ucast eth1 172.16.254.68
auto_failback on
node master
node slave
ping 172.16.87.254
respawn root /usr/lib64/heartbeat/ipfail

apiauth ipfail gid=root  uid=root

如果ping不通，vip是不会启用的。

配置说明（更多详细说明见文章最后部分）：

debugfile /var/log/ha-debug：该文件保存heartbeat的调试信息。
logfile /var/log/ha-log：heartbeat的日志文件。
keepalive 2：心跳的时间间隔，默认时间单位为秒s。
deadtime 30：超出该时间间隔未收到对方节点的心跳，则认为对方已经死亡。
warntime 10：超出该时间间隔未收到对方节点的心跳，则发出警告并记录到日志中。
initdead 60：在某系统上，系统启动或重启之后需要经过一段时间网络才能正常工作，该选项用于解决这种情况产生的时间间隔，取值至少为deadtime的2倍。
udpport 694：设置广播通信使用的端口，694为默认使用的端口号。
ucast eth1 172.16.254.28：设置对方机器心跳检测的网卡和IP。
auto_failback on：heartbeat的两台主机分别为主节点和从节点。主节点在正常情况下占用资源并运行所有的服务，遇到故障时把资源交给从节点由从节点运行服务。在该选项设为on的情况下，一旦主节点恢复运行，则自动获取资源并取代从节点，否则不取代从节点。
respawn heartbeat /usr/lib/heartbeat/ipfail：指定与heartbeat一同启动和关闭的进程，该进程被自动监视，遇到故障则重新启动。最常用的进程是ipfail，该进程用于检测和处理网络故障，需要配合ping语句指定的ping node来检测网络连接。如果你的系统是64bit，请注意该文件的路径。

9、把主节点上的三个配置文件拷贝到从节点

# cd /etc/ha.d
# scp authkeys ha.cf haresources slave:/etc/ha.d

10、从节点slave编辑ha.cf

# vim /etc/ha.d/ha.cf
只需要更改一个地方如下:
ucast eth1 172.16.254.68改为ucast eth1 172.16.254.48

11、从节点slave修改authkey权限

chmod 600 authkeys

12、启动heartbeat服务

配置完毕后，先master启动，后slave启动。

# service heartbeat start

13、检查测试

# ifconfig
看是否有接口 eth0:10# ps aux | grep nginx
看是否有nginx进程

14、测试方式1

主节点上故意禁ping

# iptables -I INPUT -p icmp -j DROP

15、测试方式2

主节点停止heartbeat服务

# service heartbeat stop

16、测试脑裂

主节点master和从节点slave都down掉eth1网卡

# ifdown eth1

可以利用/usr/share/heartbeat下的hb_standby和hb_takeover命令来模拟资源切换

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Heartbeat配置文件的详解

1．主配置文件（/etc/ha.d/ha.cf）

下面对ha.cf文件的每个选项进行详细介绍，其中"#"号后面的内容是对选项的注释说明。

#debugfile /var/log/ha-debug
logfile /var/log/ha-log #指名heartbeat的日志存放位置。
#crm yes #是否开启Cluster Resource Manager（集群资源管理）功能。
bcast eth1 #指明心跳使用以太网广播方式，并且是在eth1接口上进行广播。
keepalive 2 #指定心跳间隔时间为2秒（即每2秒钟在eth1上发送一次广播）。
deadtime 30 #指定若备用节点在30秒内没有收到主节点的心跳信号，则立即接管主节点的服务资源。
warntime 10 #指定心跳延迟的时间为10秒。当10秒钟内备份节点不能接收到主节点的心跳信号时，就会往日志中写入一个警告日志，但此时不会切换服务。
initdead 120 #在某些系统上，系统启动或重启之后需要经过一段时间网络才能正常工作，该选项用于解决这种情况产生的时间间隔。取值至少为deadtime的两倍。
udpport 694 #设置广播通信使用的端口，694为默认使用的端口号。
baud 19200 #设置串行通信的波特率。
#serial /dev/ttyS0 #选择串行通信设备，用于双机使用串口线连接的情况。如果双机使用以太网连接，则应该关闭该选项。
#ucast eth0 192.168.1.2 #采用网卡eth0的udp单播来组织心跳，后面跟的 IP地址应为双机对方的IP地址。
#mcast eth0 225.0.0.1 694 1 0 #采用网卡eth0的Udp多播来组织心跳，一般在备用节点不止一台时使用。Bcast、ucast和mcast分别代表广播、单播和多播，是组织心跳的三种方式，任选其一即可。
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 #主节点主机名，可以通过命令"uanme -n"查看。
node node2 #备用节点主机名。
ping 192.168.60.1 #选择ping的节点，ping节点选择的越好，HA集群就越强壮，可以选择固定的路由器作为ping节点，但是最好不要选择集群中的成员作为ping节点， ping节点仅仅用来测试网络连接。
respawn hacluster /usr/lib/heartbeat/ipfail #该选项是可选配置，列出与 heartbeat一起启动和关闭的进程，该进程一般是和heartbeat集成的插件，这些进程遇到故障可以自动重新启动。最常用的进程是ipfail，此进程用于检测和处理网络故障，需要配合ping语句指定的ping node来检测网络的连通性。其中hacluster表示启动ipfail进程的身份。

2．资源文件（/etc/ha.d/haresources）

Haresources文件用于指定双机系统的主节点、集群IP、子网掩码、广播地址以及启动的服务等集群资源，文件每一行可以包含一个或多个资源脚本名，资源之间使用空格隔开，参数之间使用两个冒号隔开，在两个HA节点上该文件必须完全一致，此文件的一般格式为：

node-name network <resource-group>

node-name表示主节点的主机名，必须和ha.cf文件中指定的节点名一致。network用于设定集群的IP地址、子网掩码和网络设备标识等。需要注意的是，这里指定的IP地址就是集群对外服务的IP地址，resource-group用来指定需要Heartbeat托管的服务，也就是这些服务可以由Heartbeat来启动和关闭。如果要托管这些服务，就必须将服务写成可以通过start/stop来启动和关闭的脚步，然后放到/etc /init.d/或者/etc/ha.d/resource.d/目录下，Heartbeat会根据脚本的名称自动去/etc/init.d或者/etc /ha.d/resource.d/目录下找到相应脚步进行启动或关闭操作。

下面对配置方法进行具体说明：

node1 IPaddr::192.168.60.200/24/eth0/ Filesystem:: /dev/sdb5::/webdata::ext3 httpd tomcat

其中，node1是HA集群的主节点，IPaddr为heartbeat自带的一个执行脚步，Heartbeat首先将行/etc/ha.d/resource.d/IPaddr 192.168.60.200/24 start的操作，也就是虚拟出一个子网掩码为255.255.255.0，IP为192.168.60.200的地址。此IP为Heartbeat对外提供服务的网络地址，同时指定此IP使用的网络接口为eth0。接着，Heartbeat将执行共享磁盘分区的挂载操作，"Filesystem::/dev/sdb5::/webdata::ext3"相当于在命令行下执行mount操作，即"mount -t ext3 /dev/sdb5 /webdata"，最后依次启动httpd和Tomcat服务。

注意主节点和备份节点中资源文件haresources要完全一样。

3．认证文件（/etc/ha.d/authkeys）

authkeys文件用于设定Heartbeat的认证方式，共有3种可用的认证方式，即 crc、md5和sha1。3种认证方式的安全性依次提高，但是占用的系统资源也依次增加。如果Heartbeat集群运行在安全的网络上，可以使用 crc方式；如果HA每个节点的硬件配置很高，建议使用sha1，这种认证方式安全级别最高；如果是处于网络安全和系统资源之间，可以使用md5认证方式。这里我们使用crc认证方式，设置如下：

auth 1
1 crc
#2 sha1 sha1_any_password
#3 md5 md5_any_password

需要说明的一点是：无论auth后面指定的是什么数字，在下一行必须作为关键字再次出现，例如指定了"auth 6"，下面一定要有一行"6 认证类型"。

最后确保这个文件的权限是600（即-rw——-）。

heartbeat高可用详解相关推荐

Nginx简介配置及高可用详解
1.Nginx简介 2.nginx指令配置详解 3.nginx负载均衡及反向代理实现 4.nginx浏览器跨域问题 5.nginx防盗链 6.nginx缓存 7.nginx压缩 8.nginx配置ht ...
运维企业专题（8）LVS高可用与负载均衡后篇——LVS健康检查与高可用详解
实验准备 1.下面的实验使用的是rhel6系列(rhel6.5)的虚拟机,因此你需要有对应的镜像和yum源 2.准备三台虚拟机,为了区分主机名与IP分别为 server1 172.25.6.1 ser ...
sparkstreaming监听hdfs目录如何终止_HDFS—HA高可用详解
一.HA概述 1)所谓HA(high available),即高可用(7*24小时不中断服务). 2)实现高可用最关键的策略是消除单点故障.HA严格来说应该分成各个组件的HA 机制:HDFS的HA和Y ...
Redis复制的高可用详解
一.sentinel基础在Redis的主从复制中有一个问题很明显,比如说在一主三从的架构下,如果主节点宕机,那么所有的写操作也就不能执行了,这个主从复制架构也就瘫痪了,所以Redis引入了senti ...
keepalived实现haproxy高可用详解
一,keepalived介绍 keepalived是一个可以实现某些资源高可用的开源软件,其主要的组件包括core,check,vrrp,libipfwc,libipvs,这里说下各个组件的功能. c ...
Redis高可用详解：持久化技术及方案选择
文章摘自:https://www.cnblogs.com/kismetv/p/9137897.html 前言在上一篇文章中,介绍了Redis的内存模型,从这篇文章开始,将依次介绍Redis高可用相关 ...
redis作用_Redis高可用详解：持久化技术及方案选择
本文将先说明上述几种技术分别解决了Redis高可用的什么问题,然后详细介绍Redis的持久化技术,主要是RDB和AOF两种持久化方案.在介绍RDB和AOF方案时,不仅介绍其作用及操作方法,同时还会介绍 ...
Redis的高可用详解：Redis哨兵、复制、集群的设计原理，以及区别
谈到Redis服务器的高可用,如何保证备份的机器是原始服务器的完整备份呢?这时候就需要哨兵和复制. 哨兵(Sentinel):可以管理多个Redis服务器,它提供了监控,提醒以及自动的故障转移的功能. ...
互联网架构之 “高可用” 详解
一.什么是高可用高可用HA(High Availability)是分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计减少系统不能提供服务的时间. 假设系统一直能够提供服务,我们说系统的可用 ...
LVSKeepalived—集群、负载均衡、企业高可用详解
LVS负载均衡集群及配置负载均衡概述 1.集群通过集群(cluster)技术,可以在付出较低成本的情况下获得在性能.可靠性.灵活性方面的相对高的收益,其任务调度则是集群系统中的核心技术. 集群搭建 ...

heartbeat高可用详解

heartbeat高可用详解相关推荐

最新文章

热门文章