Linux高可用性方案之Heartbeat的Stonith配置(原创)

前言 

前一阵,在为广发银行搭建HA集群时,客户总希望在出现脑裂问题后能很好的解决。当时由于没有深刻的理解heartbeat的各个模块,crm、ccm、ipfail各个插件试试得我是晕头转向的,最后的解决方式是加了两根心跳线。说白了,还是没解决,只是在心跳监测方面更加强壮而已,这里笔者介绍Stonith这个模块,以解决脑裂问题。

脑裂 

当群集发生裂脑的状况时候,因为无法进行任何沟通而误会对方无法运作,所以主与备份服务器都会启动浮动IP和相关服务,此时若两部服务器对外连线亦未短线,那么势必导致有些使用者存取的是主要服务器,另外一些则存取备份服务器的情形。此外,如果两部服务器共享一个存储装置,发生裂脑时两部服务器会同时挂载该存储装置,亦同时存取相同的档案,因此若共享存储装备缺乏良好的锁定机制,更可能使得存储装置上的档案因同时读写而损坏。更有可能导致硬盘中写入不一致的信息,导致后期数据错误,甚至整个数据库损坏,后果不堪设想。
避免裂脑的方法有两个:第一个方法是在服务器间使用多重连线;第二个则是使用heartbeat的STONITH功能。

Stonith概述
stonith是“shoot the other node in the head”的首字母简写,它是Heartbeat软件包的一个组件,它允许使用一个远程或“智能的”连接到健康服务器的电源设备自动重启失效服务器的电源,stonith设备可以关闭电源并响应软件命令,运行Heartbeat的服务器可以通过串口线或网线向stonith设备发送命令,它控制高可用服务器对中其他服务器的电力供应,换句话说,主服务器可以复位备用服务器的电源,备用服务器也可以复位主服务器的电源。
注意:尽管理论上连接到远程或“智能的”循环电源系统的电力设备的数量是没有限制的,但大多数stonith实现只使用两台服务器,因为双服务器stonith配置是最简单的,最容易理解,它能够长时间运行且不会降低系统的可靠性和高可用性。 

查看当前支持Stonith设备清单的命令:
#/usr/sbin/stonith -L

想要使用stonith功能需要安装 heartbeat-pils-*.rpm和rpm -ivh hearbeat-stonith-*.rpm
配置stonith设备

在Heartbeat中使用stonith和stonith_host这两个指令来配置stonith设备
stonith语法如下

stonith {stonith-device-type} {stonith-configuration-file} 
其中stonith-device-type为stonith设备的类型,而stonith-configuration-file为stonith设备的配置信息文件。例如:
stonith baytech /etc/ha.d/conf/stonith.baytech. 
stonith_host语法如下 
stonith_host {hostfrom} {stonith_type} {params...} 
其中 hostfrom为和stonith设备相连的主机可以使用*代表所有主机,stonith_type为stonith设备的类型,可通过stonith -L查看, params为stonith设备所需要的参数。例如

stonith_host   smart403   apcsmart   smart404   /dev/ttyS1 
单个Stonith设备 
正常情况下,高可用配置使用两个stonith设备构造(一个连接到主服务器,一个连接到备用服务器)但是,这里我们先来探讨如何使用单个stonith设备部署Heartbeat,它将在你的高可用配置中引入两个重要的限制:
1、 所有资源必须运行在主服务器上(在主服务器在线时不允许在备用服务器上运行资源)。
2、 故障转移事件只能发生一次,并只能朝一个方向转移,也就是说,运行在主服务器上的资源只能故障转移到备用服务器一次,当备用服务器取得了资源的所有权时,关闭主服务器,要恢复到主服务器正常运行必须要操作员干预。
当你只使用一个stonith设备时,你必须在主服务器上运行所有的高可用资源,因为主服务器不能复位备用服务器的电源(当主服务器从故障中恢复后想要取回资源的所有权时,它需要复位备用服务器的电源),也就是说,备用服务器上的资源在没有第二个stonith设备时不是高可用的,在使用单个stonith设备时,故障转移后,也需要操作员干预,因为主服务器将关闭。

正常情况下,主服务器广播它的心跳,备用服务器听到心跳就知道一切都运行正常,但当备用服务器听不到主服务器的心跳时,它向stonith设备发送恰当的软件命令循环主服务器上的电源

Stonith事件序列 
1、当备用服务器听不到心跳时Stontih事件开始。
注意:这并不一定意味着主服务器没有发送心跳,心跳可能有多种原因而没有抵达备用服务器,这就是为什么建议至少需要两条物理路径传输心跳以避免出现假象的原因了。
2、备用服务器发出一个Stonith复位命令到Stonith设备。
3、Stonith设备关闭主服务器的电力供应。
4、一经切断主服务器的电源,它就不能再访问集群资源,也不能再为客户端提供资源,保证客户端计算机不能访问主服务器上的资源,排除可能发生的头脑分裂状态。
5、然后备用服务器获得主服务器的资源,Heartbeat用start参数运行资源脚本,并执行ARP欺骗广播以便客户端计算机发送它们的请求到它的网络接口上。
一旦主服务器完成重启,它会尝试回收它的资源,要求备用服务器释放资源,除非两台服务器都关闭了auto_failback选项

两个Stonith设备

两个Stonith设备的拓扑图如下

连接完毕后,在/etc/ha.d/ha.cf文件中加入下列内容即可
stonith_host   smart403   apcsmart   smart404   /dev/ttyS1

stonith_host   smart404   apcsmart   smart403   /dev/ttyS1 
第一行表示
通过smart403节点利用与stonith设备相连的com1 (STONITH装置相连接的Linux设备名称。可以使用stonith –h指令查询各装置的参数用法。)通过stonith设备apcsmart(stonith –h指令的列表中可以查到APC Smart UPS 的装置名称为apcsmart)关闭smart404节点
第二行表示
smart403可以藉由连接于COM2接头上的apcsmart装置,将smart404关机,与第一行相反。
有些STONITH装置必须使用密码才能连线,如果将密码设置在ha.cf文件中,最好将该文件的权限设置为600(#chmod /etc/ha.d/ha.cf),修改权限使其他人不可读取。如果泄密,任何人都可以随意关闭另一部服务器。
使用STONITH功能必须小心双方同时发出关机指令,导致两部服务器一起关机的情形。有些共享的STONITH装置可以设定为一次只接受一台主机的指令,如此便能避免此问题发生。或者也可以开启两部服务器的ha.cf档案,在“deadtime”项目设定不同的时间,例如主要服务器上设定为180秒,而备份服务器则为120秒,让两者判定对方【死亡】的时间不一致,也能避免这个情形的发生。
如果尚未购买STONITH功能所支援的硬件,但是想测试STONITH功能的话 ,可以使用虚拟的STONITH装置进行试验。可以使用文件编辑器打开主服务器上的/etc/ha.d/ha.cf
stonith_host smart403 null smart404 
Smart403:此处设定主要服务器的节点名称
Null:为虚拟STONITH装置的名称
Smart404:此处设定备份服务器的节点名称
编辑完成后重启heartbeat,以使新设定生效。
然后在备份服务器上执行下面命令关闭网络:
/etc/init.d/network stop 
最后开启主要服务器上的/var/log/ha-log记录,搜寻STONITH字串,观察STONITH功能的运作情形:
会发现内有:
heartbeat[7871]: 2011/09/18_21:51:26 WARN: node smart404: is dead
heartbeat[7871]: 2011/09/18_21:51:26 info: Link  smart404 :eth0 dead.
heartbeat[8419]: 2011/09/18_21:51:26 info: Resetting node  smart404 ith [NULL STONITH device]  //使用STONITH装置将备份服务器关机 
heartbeat[8419]: 2011/09/18_21:51:26 info: glib: Host null-reset:  smart404 
heartbeat[8419]: 2011/09/18_21:51:26 info: node  smart404 now reset.   //备份服务器已经关机 
heartbeat[7871]: 2011/09/18_21:51:26 info: Exiting STONITH  smart404 process 8419 returned rc 0.

参考至:《Linux企业集群》
           http://yimu1023.blog.163.com/blog/static/362522822008621511567/

           http://linux.chinaitlab.com/linuxjq/744842_4.html
           http://www.linux-ha.org/ha.cf

本文原创,转载请注明出处、作者

如有错误,欢迎指正

邮箱:czmcj@163.com

作者:czmmiao 原文地址:http://czmmiao.iteye.com/blog/1174667

时间: 2024-09-19 09:29:07

Linux高可用性方案之Heartbeat的Stonith配置(原创)的相关文章

Linux高可用性方案之Heartbeat的CRM配置(原创)

heartbeat默认模式是没法监控资源的,也就是说其中某个资源要是crash掉了,也不会发生任何动作,它只有当它认为对方机器dead后才会发生动作,也就是机器crashed,网络断掉了之类.这显然没法达到我们的目标.为了达到我们的目标就要采用crm(cluster resource management)模式了. 本文需要实现的目标,让ha自动监控资源的运行状态. 启动服务ip为192.168.0.222,自动运行脚本echo.sh echo.sh脚本内容如下#!/bin/bash echo

Linux高可用性方案之Heartbeat的watchdog配置(原创) 编辑

Watchdog概述  在日常使用heartbeat接管资源的应用中,由于heartbeat无法对操作系统自身出现的问题进行监控.如果主节点操作系统挂起,一方面可能导致服务中断,另一方面由于主节点资源无法释放,而备份节点却接管了主节点的资源,此时就发生了两个节点同时争用一个资源的状况. 针对这个问题,就需要在Linux内核中启用一个叫watchdog的模块.watchdog是一个Linux内核模块,它通过定时向/dev/watchdog设备文件执行写操作,从而确定系统是否正常运行.如果watch

Linux高可用性方案之Heartbeat的CRM节点得分计算(原创)

crm资源得分概述  在V2的Heartbeat中,为了将资源的监控和切换结合起来,同时支持多节点集群,Heartbeat提供了一种积分策略来控制各个资源在集群中各节点之间的切换策略.通过该积分机制,计算出各节点的的总分数, 得分最高者将成为active状态来管理某个(或某组)资源. 如果在CIB的配置文件中不做出任何配置的话,那么每一个资源的初始分数(resource-stickiness)都会是默认的0,而且每一个资源在每次失败之后所减掉的分数(resource-failure-sticki

Linux高可用性方案之Heartbeat日志查看(原创)

日志是我们跟踪系统和应用程序最好的方式,在Heartbeat中日志可以自定义输出位置,只需在ha.cf文件配置即可,具体可参见笔者的 http://czmmiao.iteye.com/blog/1174010 下面跟着笔者我们来看详细看下Heartbeat的日志启动主机Heartbeat服务  #/etc/init.d/heartbeat start  Heartbeat启动时,通过"tail -f /var/log/ messages"查看主节点系统日志信息,输出如下:# tail

Linux高可用性方案之Heartbeat安装(原创)

安装Heartbeat前的准备  Heartbeat集群必须的硬件 从下图看出,构建一个Heartbeat集群系统必须的硬件设备有: 节点服务器: 网络和网卡: 共享磁盘. 节点服务器 安装Heartbeat至少需要两台主机,并且对主机的要求不高,普通的PC服务器即可满足要求.当然,也可以在虚拟机上安装Heartbeat,现在Heartbeat可以很好地运行在Linux系统下,很多Linux发行版本都自带了Heartbeat套件,同时,还可以运行在FreeBSD和Solaris操作系统上. 网卡

Linux高可用性方案之Heartbeat架构(原创)

Heartbeat 概述  Heartbeat 是 Linux-HA 工程的一个组件, 1999 年开始到现在,发布了众多版本,是目前开源 Linux-HA 项目最成功的一个例子,在行业内得到了广泛的应用.随着 Linux在关键行业应用的逐渐增多,它必将提供一些原来由 IBM 和 SUN 这样的大型商业公司所提供的服务,这些商业公司所提供的服务都有一个关键特性,就是高可用集群. 高可用集群是指一组通过硬件和软件连接起来的独立计算机,它们在用户面前表现为一个单一系统,在这样的一组计算机系统内部的一

Linux高可用性方案之Heartbeat的日常维护命令(原创)

crm_resource  crm_resource命令对资源执行各种资源相关的操作.它可以修改已配置资源的定义.启动和停止资源,以及在节点间删除和迁移资源. crm_resource  [-?|-V|-S] -L|-Q|-W|-D|-C|-P|-p [options] 示例 列出所有资源:crm_resource -L  检查正在运行资源的位置(以及是否在运行):crm_resource -W  -r my_first_ip  如果 my_first_ip 资源正在运行,此命令的输出中会显示正

Linux 2.6.19.x 内核编译配置选项简介

Linux 2.6.19.x 内核编译配置选项简介 版权声明 本文作者是一位自由软件爱好者,所以本文虽然不是软件,但是本着 GPL 的精神发布.任何人都可以自由使用.转载.复制和再分发,但必须保留作者署名,亦不得对声明中的任何条款作任何形式的修改,也不得附加任何其它条件.您可以自由链接.下载.传播此文档,但前提是必须保证全文完整转载,包括完整的版权信息和作译者声明. 其他作品 本文作者十分愿意与他人共享劳动成果,如果你对我的其他翻译作品或者技术文章有兴趣,可以在如下位置查看现有作品的列表: 金步

网卡-linux vmware下的eth1和eth2配置不成功

问题描述 linux vmware下的eth1和eth2配置不成功 对一台vmare上的Linux 进行了如下配置: auto eth0 iface eth0 inet static address 192.168.0.21 gateway 192.168.0.1 netmask 255.255.255.0 dns-nameservers 192.168.0.1 auto eth1 iface eth1 inet static address 192.168.1.21 gateway 192.1