欢迎各位兄弟 发布技术文章

这里的技术是共享的

You are here

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


来自  https://blog.csdn.net/czmmiao/article/details/84019105


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

Posted on 2012-07-14 10:00  HI END  阅读(535)  评论(0)  编辑  收藏

来源:http://zhumeng8337797.blog.163.com/blog/static/100768914201191810828662/?suggestedreading&wumii

前言

前一阵,在为广发银行搭建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


来自   https://www.cnblogs.com/fjlycsy/archive/2012/07/14/2591164.html

普通分类: