本文发布于Cylon的收藏册,转载请著名原文链接~
heartbeat介绍
Heartbeat一款开源提供高可用(Highly-Available)服务的软件,通过heartbeat,可以将资源(IP及程序服务等资源)从一台已经故障的计算机快速转移到另一台正常运转的机器上继续提供服务,一般称之为高可用服务。在实际生产应用场景中,heartbeat的功能和另一个高可用开源软件keepalived有很多相同之处,但在生产中,对应实际的业务应用也是有区别的,例如:keepalived主要是控制IP的漂移,配置、应用简单,而heartbeat则不但可以控制IP漂移,更搜长对资源服务的控制,配置、应用比较复杂
heartbeat工作原理
通过修改heartbeat软件的配置文件,可以指定哪一台Heartbeat服务器作为主服务器,则另一台将自动成为热备服务器.然后在热备服务器上配里Heartbeat守护程序来监听来自主服务器的心跳消息。如果热备服务器在指定时间内未监听到来自主服务器的心跳,就会启动故障转移程序,并取得主服务器上的相关资源服务的所有权,接替主服务器继续不间断的提供服务,从而达到资源及服务高可用性的目的。
以上描述的是heartbeat主备的模式,heartbeat还支持主主棋式,即两台服务器互为主备,这时它们之间会相互发送报文来告诉对方自己当前的状态,如果在指定的时间内未受到对方发送的心跳报文,那么,一方就会认为对方失效或者宕机了,这时每个运行正常的主机就会启动自身的资源接管模块来接管运行在对方主机上的资源或者服务,继续为用户提供服务。一般情况下,可以较好的实现一台主机故障后,企业业务仍能够不间断的持续运行。
注意:所谓的业务不间断,再故障转移期间也是需要切换时间的(例如:停止数据库及存储服务等),heartbeat的主备高可用的切换时间一般是在5-20秒左右(服务器宕机的切换比人工切换要快)。
另外,和keepalived高可用软件一样,heartbeat高可用是操作系统级别的,不是服务(软件)级别的,可以通过简单的脚本控制.实现软件级别的高可用。
高可用服务器切换的常见条件场景:
- 主服务器物理宕机(硬件损坏,操作系统故障)。
- Heartbeat服务软件本身故障。
- 两台主备服务器之间心跳连接故障。
服务故障不会导致切换.可以通过服务宕机把heartbeat服务停掉。
3 heartbeat心跳连接 经过前面的叙述,要部署heartbeat服务,至少需要两台主机来完成。那么,要实现高可用服务,这两台主机之间是如何做到互相通信和互相监侧的呢?
下面是两台heartbeat主机之间通信的一些常用的可行方法:
- 利用串行电缆,即所谓的串口线连接两台服务器(可选)。
- 一根以太网电缆两网卡直连(可选)。
- 以太网电缆,通过交换机等网络设备连接(次选)。
如何为高可用服务器端选择心跳通信方案?
-
串口线信号不会和以太网网络交集,也不需要单独配置丐地址等信息,因此传输稳定不容易出现问题,使用串口线的缺点是两个服务器对之间的距离距离不能太远,串口线对应服务端的设备为/dev/ttys0。串口线形状如下图所示:
-
使用以太网网线(无需特殊交叉线了)直连网卡的方式,配置也比较简单,只需对这两块直连网线的网卡配好独立的IP段地址能够互相通信即可,普通的网线就可以了(推荐)
-
使用联网以太网网线和网卡作为心跳线是次选的方案,因为这个链路里增加了交换机设备这样的故障点,且这个线路不是专用心跳线路,容易受以太网其他数据传输的影响,导致心跳报文发送延迟或者无法送达问题。
选择方案小结:
- 和数据相关的业务,要求较高,可以串口和网线直连的方式并用。
- Web业务,可以网线直连的方式或局域网通信方式也可。
Heartbeat软件未来发展说明
有关heartbeat分3个分支的说明
自2.1.4版本后,Linux-HA将Heartbeat分包成三个不同的子项目,并且提供了一个cluster-glue的组件,专用于Local ResourceManager 的管理。即heartbeat + cluster-glue + resouce-agent 三部分。
Heartbeat
hearbeat本身是整个集群的基础(cluster messaging layer),负责维护集群各节点的信息以及它们之前通信。
Cluster Glue
相当于一个中间层,负责调度,可以将heartbeat和crm(pacemaker)联系起来,包括两个摸块:本地资漂管理(Local Resource Manager)LRM和STONITH。
Resource Agents
资源代理层,各种的资源的ocf脚本,这些脚本将被LRM调用从而实现各种资源启动、停止、监控等等。
Pacfrmaker资料
pacemaker介绍:http://baike.baidu.com/view/8635511.htm
从头开始搭建其群在Fedora上面创建主/主和主/备集群 http://www.clusterlabs.org/doc/zh-CN/Pacemaker/1.1/html-single/Clusters_from_Scratch/index.html
参考文档:http://www.2cto.com/os/201511/448872.html
裂脑
什么是裂脑
由于某些原因,导致两台高可用服务器对之间在指定时间内,无法互相检侧到对方心跳而各自启动故障转移功能,取得了资源及服务的所有权,而此时的两台高可用服务器对都还活着并在正常运行,这样就会导致同一个IP或服务在两端同时启动而发生冲突的严重问题,最严重的是两台主机占用同一个VIP地址,当用户写入数据时可能会分别写入到两端,这样可能会导致服务器两端的数据不一致或造成数据丢失,这种情况就被称为裂脑,也有人称其为分区集群或大脑垂直分割,英文为split brain。
导致裂脑发生的多种原因
一般来说,裂脑的发生,有以下几个原因。 高可用服务器对之间心跳线链路故障。导致无法正常通信。
- 心跳线坏了(包括断了,老化)。
- 网卡及相关驱动坏了,IP配置及冲突问题(网卡直连)。
- 心跳线间连接的设备故障(网卡及交换机)。
- 仲裁的机器出问题(仲裁的方案)。
- 高可用服务器对上开启了如iptables防火墙阻挡了心跳的传输。
- 高可用服务器对上心跳网卡地址等信息配置不正确,导致发送心跳失败。
- 其它服务配置不当等原因,如心跳方式不同,心跳广播冲突、软件BUG等。
提示:另外的高可用软件keepalived配置里如果virtual router_id参数,两端配置不一致,也会导致裂脑问题发生。
防止裂脑发生的8种秘籍
发生裂脑时,对业务的影响是极其严重的,有时甚至是致命的。如:两台高可用服务器对之间发生裂脑,导致互相争用同一IP资源,就如同我们在局域网内常见的IP地址冲突一样,两个机器就会有一个或者两个都不正常,影响用户正常访问服务器。如果是应用在数据库或者存储服务这种极重要的高可用上,那就可能会导致用户发布的数据间断的写在两台不同服务器上,最终数据恢复极困难或难以恢复(当然,有NAS等公共存储的硬件也许会好一些)。
实际生产环境中,我们可以从以下几个方面来防止裂脑问题的发生。
-
同时使用串行电缆和以太网电缆连接,同时用两条心跳线路,这样一条线路坏了,另一个还是好的,依然能传送心跳消息。(网卡设备和网线设备)。
-
当检测到裂脑时强行关闭一个心跳节点。(这个功能需要特殊设备支持,如stonith、fence)相当于程序上北街店发现心跳线故障,发送关机命令到主节点。
-
做好对裂脑的监控报警(如邮件及手机短信等,值班),在问题发生时人为第一时间介入仲裁,降低损失。百度的报警监控有上行和下行。和人工交互的过程。当然,在实施高可用方案时,要根据业务需求确定是否能容忍这样的损失。对于一般的网站常规业务,这个损失是可控的。
-
启用磁盘锁.正在服务一方锁住共享磁盘,“裂脑”发生时让对方完全“抢不走”共享磁盘资源。但使用锁磁盘也会有一个不小的问题,如果占用共享盘的一方不主动"解锁",另一方就永远得不到共享磁盘.现实中假如服务节点突然死机或崩演,就不可能执行解锁命令。后备节点也就接管不了共享资源和应用服务。于是有人在HA中设计了“智能”锁。即,正在服务的一方只在发现心跳线全部断开(察觉觉不到对端)时才启用磁盘锁。平时不上锁。此功能适合共享场景。
-
报警报在服务器接管之前,给人员你处理留够时间。1分钟内报警了,但是服务器此时没有接管,而是5分钟接管。接管的时间较长,数据不会丢,导致用户无法写数据。
-
报警后不自动服务器接管,而是由人为人员控制管理。
-
增加仲裁机制,确定谁该获得资派。这又有几个参考的思路:
- 加一个仲截机制。例如设且参考IP(如网关IP).当心跳线完全断开时,2个节点都各自Ping一下参考IP,不通则表明断点就出在本端。不仅心跳线、还有对外服务的本地网络链路断了,这样就主动放弃竞争.让能够Ping通参考IP的一端去接管服务。Ping不通参考IP的一方可以自我重启,以彻底释放有可能还占用着的那些共享资源(heanbeat也有此功能)。
- 通过第三方软件仲裁谁该获得资源,这个在阿里的集团有类似的软件应用。
小结:如何开发程序判断裂脑:
- 简单判断,只要备节点出现VIP就是报普(a.主机宕机了,各机接管了。b.主机没宕,裂脑了),不管哪个情况,人工查看。
- 严谨判断,备机出现VIP,并且主机及服务还活着,裂脑了(依赖报警)。
fence设备和仲裁机制
先说下我以前做项目的环境,基本都是RHEL/CENTOS (以下简称RHEL),用的是RHCS集群套件,这个集群套件其实只是很多个软件整合在一起,在其他linux发行版里也有,只是比较零散,在RHEL中RHCS集群套件被做成了一个group,可以通过yum group install来安装集群套件,当然一个个rpm包安装也没问题。这个集群套件里还包含了一个LB的软件,就是LVS. Heartbeat和RHCS其实是差不多的东西,都是靠心跳来检测健康状态的,所以下面说的内容在Heartbeat应该也是通用的。
先说fence,fence只是HA集群环境下的术语,在硬件领域,fence设备其实就是一个只能电源管理设备(IPMI),也叫做Intelligent PowerManagement Interface,如果你去和服务器代理商说fence,他们一定不知道是什么东西(原厂可能知道),你得和他们说是队们一定不知道是什么东西(原厂可能知道),你得和他们说是智能电源管理设备或远程管理卡,他们就理解了,老师在视频里说这是一个特殊的插线板,这是fence设备的一种,叫做外部fence,还有一种叫内部fence.是插在服务器里的,不管是内部还是外部fence,这些设备都是带有以太网口的,用来在HA切换触发时通过网络重启提供资源服务的服务器。
至于外部fence设备,我只用过APC(著名的UPS电源生产商)的PowerSwitch, 这是一个带以太网口的电源插座,征每个插口都对应一个ID号,用来在命令中指定对哪一个ID号上的电源进行切断或者重启,为什么我当时会接触到外部fence设备呢,是因为当时做了一个医院的挂号系统,用的是IBM的小机装的RHEL5.x,因为小机上没有支持的内部fence,只有使用外部fence来实现了,至于为什么在小机上装RHEL这种2B方案(AIX也有成熟的HA解决方案),得牵涉到商务上的忽悠,给客户返点各种营销上的潜规则,我才得以在实战中接触到这些东西。
在RHCS下有仲裁机制是一个叫做仲裁盘的东西,他是通过额外的存储来实现的,比如SAN,通过mkgdisk命令来制作的一个特殊块设备,这个设备做什么用呢?默认情况下双节点的HA架构,主从服务器的投票数都是1,双方使用的ping网关的方式来将自己的存活状态写入仲裁盘内,一旦节点心跳发生问题并且仲裁盘没有收到节点的存活信息,则启动fence设备来重启/关闭故障节点。这种方式可以有效的防止裂脑情况。缺点就是判断时间会不普通的HA时间长,这而要配合业务的需求,当时我们用RHCS+ORALCE+SAN存储来实现全国中信银行的帐务集中系统,数据必须保证完全一致,我们在实际测试中从故障到切换到备机接管能够提供服务的时间在2分钟以内。当然随着数据库增大,可能在启动Oracle数据库实例的时候会有所增加。以上就是我对fence设备和仲裁机制的个人补充,欢迎老师和大家拍砖。
stonith
介绍
stonith是“shoot the other node in the head”的首字母简写,它是Heartbeat软件包的一个组件,它允许使用一个远程或“智能的”连接到健康服务器的电源设备自动重启失效服务器的电源,stonith设备可以关闭电源并响应软件命令,运行Heartbeat的服务器可以通过串口线或网线向stonith设备发送命令,它控制高可用服务器对中其他服务器的电力供应,换句话说,主服务器可以复位备用服务器的电源,备用服务器也可以复位主服务器的电源。
注意:尽管理论上连接到远程或“智能的”循环电源系统的电力设备的数量是没有限制的,但大多数stonith实现只使用服务器,因为双服务器stonith配置是最简单的,最容易理解,它能够长时间运行且不系统的可靠性和高可用性。
Stonith事件触发工作步骤
- 当备用服务器听不到心跳时Stontih事件开始。
注意:这并不一定意味着主服务器没有发送心跳,心跳可能有多种原因而没有抵达备用服务器,这就是为什么建议至少需要两条物理路径传输心跳以避免出现假象的原因了。 2. 备用服务器发出一个Stonith复位命令到Stonith设备。
- Stonith设备关闭主服务器的电力供应。
一经切断主服务器的电源,它就不能再访问集群资源,也不能再为客户端提供资源,保证客户端计算机不能访问主服务器上的资源,排除可能发生的头脑分裂状态。
4. 然后备用服务器获得主服务器的资源,Heartbeat用start参数运行资源脚本,并执行arp欺骗广播以便客户端计算机发送它们的请求到它的网络接口上。 详情可参考Heartbeat高可用Stonith配置201503。
Heartbeat消息类型
Heartbeat高可用软件在工作过程中,一般来说,有三种消息类型,具体为:心跳消息、集群转换消息、重传请求
心跳消息
心跳消息为约150字节的数据包,可能为单播、广播或多播的方式,控制心跳频率及出现故障要等待多久进行故障转换。
集群转换消息
ip-request和ip-request-respy
当主服务器恢复在线状态时,通过ip-request 消息要求备机释放主服务器失败时备服务器取得的资源,然后备份服务器关闭释放主服务器失败时取得的资源及服务。
备服务器释放主服务器失败时取得的资源及服务后,就会通过ip-request-resp消息通知主服务器它不在拥有该资源及服务,主服务器收到来自备节点的ip-request-resp消息通知后,启动失败时释放的资源及服务,并开始提供正常的访问服务。
提示:以上心跳控制消息都使用UDP协议发送到/etc/ha.d/ha.cf文件指定的任意端口,或指定的多播地址,如果使用多播默认端口为694
跳实现方式及查看心跳消息
参考:http://blog.chinaunix.net/uid-7921481-id-1617030.html
Heartbeat IP地址接管和故障转移
Heartbeat是通过IP地址接管和ARP广播进行故陈转移的。
ARP广播:在主服务器故阵时,备用节点接管资源后.会立即强制更新所有客户端本地的ARP表(即清除客户端本地缓存的失败取务器的VIP地址和mac地址的解析记录)。确保客户端和新的主服务器对话。
VIP/IP别名/辅助IP
real IP
真实IP,又彼称为管理IP,一般是配置在物理网卡上的实际IP,这可以看作你本人的姓名,如:张三。在负载均衡及高可用环境中,管理IP是不对外提供用户访问服务的,而仅作为管理服务器用,如SSH可以通过这个管理IP连接服务器。
VIP
虚拟IP即VIP,实际上救是heartbeat临时绑定在物理网卡上的别名IP (heartbeat3以上也采用了辅助IP)。如eth0:x,x为0-255的任惫数字.你可以在一块网卡上绑定多个别名.这个VIP可以看作是你上网的QQ网名、呢称、外号等。在实际生产环境中,需要把DNS配置中把网站域名地址解析到这个VIP地址。由这个VIP对用户提供服务。
这样做的好处就是当提供服务的服务器宕机以后,在接管的服务器上直接会自动配置上同样的VIP提供服务。如果是使用管理IP的话,来回迁移就难以做到,而且,迁移走了。我们就只能去机房连接服务器了。VIP的实质就是确保两台服务器各有一个管理IP不动,就是随时可以连上机器,然后,增加绑定其他的VIP,这样就算VIP转移走了,也不至于服务器本身连不上,因为还有管理IP呢。
Linux系统给网卡配置VIP的方法常见的有两种,即别名和辅助IP###
别名IP(alias ip)
ip alias 是由 Linux 系统的 ifconfig 命令来创建和维护的,别名IP就是在网卡设备上绑定的第二个及以上的IP,例如: 手工配置别名VIP的方法
ifconfig eth0:1 192.168.1.1 netmask 255.255.255.0 up
ifconfig eth0:1 192.168.1.1/24 up #<==up 关键字可省略默认为up
ifconfig eth0:1 192.168.1.1/24 down
让别名IP永久生效 写入到网卡配置文件可以让别名IP永久生效,名字可以为ifcfg-eth0:x,x为0-255的任意数字,IP等内容格式和ifcfg-eth0一致,或者将命令写入/etc/rc.local
注意:别名IP在centos 7中被遗弃,用辅助IP替代。
辅助IP(secondary ip address)
辅助IP则是由Linux系统的ip命令创建和维护的,ip addr add
创建的辅助IP,不能通过ifconfig
查看,但是通过ifconfig
创建的别名IP却可以在ip addr show 命令查看。
ip addr add 192.168.3.3/24 dev eth0
ip addr del 192.168.3.3/24 dev eth0
heartbeat3 版本起,不在使用别名,而是使用辅助IP提供服务,而 keepalived
软件一直都是使用的辅助IP技术。
部署heartbeat
heartbeat服务主机资源规划
名称 | 接口 | IP | 用途 |
---|---|---|---|
MATER | eth0 | 192.168.2.22 | 外网管理IP,用于WAN数据转发。 |
eth1 | 10.0.0.1 | 内网管理IP,用于LAN数据转发。 | |
eth2 | 10.1.0.1 | 用于服务器心跳连接(直连)。 | |
VIP | 172.168.1.1 | 用于提供应用程序A挂载服务。 | |
BACKUP | eth0 | 192.168.2.82 | 外网管理IP,用于WAN数据转发。 |
eth1 | 10.0.0.3 | 内网管理IP,用于LAN数据转发。 | |
eth2 | 10.1.0.3 | 用于服务器心跳连接(直连)。 | |
VIP | 10.1.0.3 |
安装heartbeat
http://blog.csdn.net/celeste7777/article/details/47808519 http://www.cnblogs.com/zhanjindong/p/3618055.html#anzhuang http://wangzhijian.blog.51cto.com/6427016/1708694?utm_source=tuicool&utm_medium=referral
rpm -ivh https://mirrors.aliyun.com/epel/epel-release-latest-6.noarch.rpm
注:centos 7 epel源内没有heartbeat。
yum安装heartbeat
yum install heartbeat -y
编译安装heartbeat
heartbeat3.x版本把安装包分成了4个部分,分别是:Cluster Glue、Resource Agents、heartbeat和pacemaker,所以要分别安装。
安装依赖
yum install gcc \
gcc-c++ \
autoconf \
automake \
libtool \
glib2-devel \
libxml2-devel \
bzip2 bzip2-devel \
e2fsprogs-devel \
libxslt-devel \
libtool-ltdl-devel \
asciidoc -y
创建用户
useradd hab -s /sbin/nologin -M
安装Cluster Glue
./autogen
./configure \
--prefix=/app/heartbeat-3.0.6 \
--with-daemon-user=hab \
--with-daemon-group=hab \
--enable-fatal-warnings=no LIBS='/lib64/libuuid.so.1' #<==指定uuid库文件
编译Resource Agents
./autogen
./configure \
--prefix=/app/heartbeat-3.0.6 \
--with-daemon-user=hab \
--with-daemon-group=hab \
--enable-fatal-warnings=no LIBS='/lib64/libuuid.so.1' #<==指定uuid库文件
编译heartbeat
export CFLAGS="$CFLAGS -I/app/heartbeat-3.0.6/include -L/app/heartbeat-3.0.6/lib"
./configure \
--prefix=/app/heartbeat-3.0.6 \
--with-daemon-user=hab \
--with-daemon-group=hab \
--enable-fatal-warnings=no LIBS='/lib64/libuuid.so.1'
heartbeat说明
/etc/init.d/heartbeat #<== 启动脚本
/etc/ha.d #<==配置文件目录
/etc/ha.d/resource.d #<==控制资源的脚本,被HA调用。也可以放到/etc/init.d下
提示:把脚本放到上面两个路径其中任意一个下面,然后在heartbeat的haresourc配置文件中配置脚本名称就能调用到该脚本,进而控制资源和服务的启动和关闭。
heartbeat配置文件
heartbeat的默认配置文件目录为/etc/ha.d。heartbeat常用的配置文件有三个,分别为ha.c,authkey,haresource,如果你细看,可以发现名字信息就如其实际功能。
配置名称 | 作用 | 备注 |
---|---|---|
ha.cf | heartbeat参数配置文件 | 在这里配置heartbeat的一些基本参数 |
authkey | heartbeat认证文件 | 高可用服务器对之间根据对端authkey,对对端进行认证。 |
haresource | heartbeat资源配置文件 | 如配置启动IP资源及脚本程序,服务等,调用/etc/ha.d/resource.d下面配置 |
配置服务器心跳连接
eth2 10.0.0.1和eth2 10.1.0.3两块网卡之间是通过普通网线直连连接的,即不通过交换机,直接将两块网卡通过网线连在一起,用于做心跳检测或传输数据等。
高可用服务器对上的Heartbeat软件会利用这条心跳找来性查对端的权器足否存活,进而决定是 否做故障漂移,资源切换,来保证业务的连续性。
如条件允许,以上连接可同时使用,来加大保险系数防止裂肺问砚发生。在我的生产环境中,常使用前两者之一或者结合使用。本文的环节为一根以太网网线两网卡直连,也是近几年,在生产环境中选用的。选用原因:简单、容易部署、效果也不错。做一件事情有多种选择.往往到及后娜泛性价比方面的考虑。如:部署简单,维护方便,效果不是最好的,但也无不错的。这样就好了。并不是做什么都是最好的。实际工作中往往最好的是最不现实的。
配置ha.cf文件
heartbeat配置文件模板路径在
/usr/share/doc/heartbeat-3.0.4/
ha.cf文件详细说明
debugfile /var/log/ha-debug #<== heartbeat的调试日志存放位置
logfile /var/log/ha-log #<== heartbeat的日志存放位置
logfacility local0 #<== 在syslog服务中配置通过local0设备接受日志
keepalive 2 #<== 指定心跳间隔时间为2秒(即每两秒中在eth2上发一次广播)
deadtime 30 #<== 指定若备用节点在30秒内没有收到主节点的心跳信号,则立即接管主节点的服务资源
warntime 10 #<== 指定心跳延迟的时间为10秒。当10秒种内备份节点不能接收到主节点的心跳信号时,就会往日志中写入一个警告日志,但此时不会切换服务。
initdead 120 #<== 指定在HEARTBEAT首次运行后,需要等待120秒才启动主服务器的任何资源。该选项用于解决这种情况产生的时间间隔。取值至少为deadtime的两倍。单机启动时会遇到vip绑定很慢,为正常现象。该值设置的长的原因
bcast eth2 #<== 指明心跳使用以太网广播方式在eth2接口上进行广播。如使用两个实际网络来传送心跳,则 bcast eth1 eth2
mcast eth2 225.0.0.1 694 1 0 #<== 设置广播通信使用的端口,694为默认使用的端口号
auto_failback on #<== 用来定义当主节点恢复后,是否将服务自动切回.
node data-1-1 #<== 主节点主机名,通过命令 uname -n查看
node data-1-3 #<== 备用节点主机名,可以通过命令 uname-n 查看
crm no #<== 是否开启cluster resource manager(集群资源管理)功能
还可以查/usr/share/doc/heanbeat-3.0.4/下的ha.cf.来了解更详细的参数信息
配置authkey文件
软件提供的authkey默认文件并不是很复杂 http://wangzhijian.blog.51cto.com/6427016/1708694
Authentication file. Must be mode 600 #<==此处提到了authkey文件权限必须为600
Available methods: crc sha1, md5. Crc doesn't need/want a key. #<==可以设置的认证方法
sha1 is believed to be the "best", md5 next best.
crc adds no security, except from packet corruption
$ echo 111|sha1sum
63bea2e3b0c7cd2d1f98bc5b7a9951eafcfead0f -
cat >authkeys <<EOF
auth 1
1 sha1 63bea2e3b0c7cd2d1f98bc5b7a9951eafcfead0f
EOF
配置haresource文件
编辑配置heartbeat资源文件/etc/ha.d/haresources
生产环境的配置如下:
ha-b IPaddr::10.1.0.2/24/eth0
配置haresource说明 ha-b为主机名,表示初始状态会在ha-b绑定IP 10.0.0.17,IPaddr为heartbeat配置lP的默认脚本,其后的lP等都是脚本的参数。10.0.0.17/24/eth0为集群对外服务的VIP,初始启动在ha-b上,24为子网掩码,eth0为ip绑定的实际物理网卡,为heartbeat提供对外服务的通信接口。
ha-b drbddis:data Filesystem::/dev/drbd0::/data::ext3 rsdata IPaddr:10.0.0.1/24/eth0
- 设置drbb,drbddisk::data
- 挂载/data到/dev/drbdO Filesystem::/dev/drbd0::/data/ext3
- NFS/MFS服务配置 rsdata (不要开机启动)
- 启动 VIP IPaddr::10.0.0.3/24/eth0
以上设置休验最好
一旦heartbeat无法控制资源的启动,heartbeat会采取极端的措施.例如重启系统.来释放没法管理的资源。因此,被管理的资源必须不能开机启动。可以写脚本来张制控制资源的处理,来防止heartbeat重启。
安装错误
Oct 26 10:07:18 node1 heartbeat: [2063]: ERROR: Illegal directive [ucast] in /usr/local/heartbeat/etc/ha.d//ha.cf
Oct 26 10:07:18 node1 heartbeat: [2063]: ERROR: Illegal directive [ping] in /usr/local/heartbeat/etc/ha.d//ha.cf
解决方法:建立plugin软链接:
ln -svf /app/heartbeat/lib64/heartbeat/plugins/* /app/heartbeat/lib/heartbeat/plugins/
heartbeat高可用实战
有关heartbeat调用资源的生产场景应用
在实际工作中有两种常见方法实现高可用问题:
- heartbeat可以仅控制vip资源的漂移,不负责服务资源的启动及停止,本节的httpd服务就可以这样做。适合web服务
- heartbeat即控制vip资源的漂移,同时又控制服务资源启动及停止,本节的httpd服务例子既是ip和服务要切换都切换. ←适合数据服务(数据库和存储)只能一端写。
VIP正常,httpd服务宕了.这个时候不会做高可用切换.写个简单的脚本定时或守护进程判断httpd服务,如果有问题,则停止heartbeat,主动使其上的业务到另一台。
两端服务能同时起,那最好不要交给heartbeat,对于某些服务,不能两端同时起,heartbeat可以控制服务启动。
ha高可用httpd案例结论
- 日志很重要。不管是heartbeat,所有服务的日志都很重要。有问题时多查看相关日志。
- httpd的高可用还可以是两边都处于启动状态,即httpd不需要交给ha启动,而是默认状态就先启动运行。
- 这个httpd高可用性配置在生产环境中用的很少,但它确是生产环境需求的一个初级模型。
如:heanbeat+drbd+mysql实现数据库高可用性配置,heanbeat+active/active+nfs/mfs实现存储高可用性配置。
heartbeat和keepalived应用场景区别
- 对于一般的web, db、负载均衡(nginx,haproxy )等等heartbeat和keepalived都可以实现。
- lvs负载均衡最好和keepalived结合,虽然heartbeat也可以调用带有ipvsadm命令的脚本来启动和停止lvs负载均衡,但是heartbeat本身并没有对下面节点rs的健康检查功能,heartbeat的这个缺陷可以通过ldircetord插聆来弥补,所以,当你搜索heartbeat+lvs+ldirectord可以有lvs的别解决方案)。
- 需要要数据同步(配合drbd )的高可用业务最好用heartbeat,例如:mysgl双主多从,NFS/MFS 存储,他们的特点是需要数据同步,这样的业务最好用heartbeat.因为hearbeat自带了drbd的脚本,可以利用强大的drbd同步软件配合实现同步。如果你解决了数据同步可以不用drbd,例如:共享存储或者inotify+rsync (sersync+rsync),那么就可以考虑keepalived。
运维人员对哪个更热悉就用哪个,其实,就是你要能控制维护你部署的服务。目前,总体网友们更倾向于使用leepalived软件的多一些。
heartbeat服务生产环境下维护要点
修改配置文件要点:在我们每天的实战运维工作中,当有新项目上线或者VIP更改需求时,可能会进行添加修改服务VIP的操作,那么,下面我们就以heartbeat+haproxy/nginx高可用负载均衡为例给大家讲解下生产环境下的维护方法。
所有配置放到SVN,更改后提交SVN,对比。推送到正式环境!
常见的情况就是修改配置文件,我们知道配置文件有3个:ha.cf
authkey
haresourece
。在修改配置前执行/etc/init.d/heartbeat stop
或/app/heartbeat/share/heartbeat/hb_staudby
(编译安装),/usr/lib/heartbeat/hb_staudby
(此命令最好)
本文发布于Cylon的收藏册,转载请著名原文链接~
链接:https://www.oomkill.com/2016/11/heartbeat/
版权:本作品采用「署名-非商业性使用-相同方式共享 4.0 国际」 许可协议进行许可。