心跳脑裂解决方案之Heartbeat的Stonith配置

wuliuwang

　　在心跳失效的时候，就发生了split-brain。
　　比如： 正常情况下，NodeA和NodeB在心跳检测以确认对方存在；在通过心跳检测不到对方时，就接管对应的resource。如果突然间，NodeA和NodeB之间的心跳不存在了，而NodeA和NodeB事实上都active，这时NodeA要接管NodeB的resource么？而同时NodeB要接管NodeA的resource么？这时就是split-brain。
　　不对的情况请大家指正。
　　split-brain会引起数据的不完整性,甚至是灾难性的,又如何理解呢?
　　其实不仅仅是数据的不完整性，可能会对服务造成严重影响。
　　对于数据的不完整性，主要为集群节点访问同一存储，而此时并没有锁机制来控制数据访问（都split-brain，心跳全没有了，咋控制里），那就存在数据的不完整性的可能。这个也是RHCS为何必须要fence设备的主要原因。可以参考RHCS的文档，其中也有对split-brainde 说明。
　　对于服务的影响，主要是可能早上NodeA和NodeB同时接管了一个虚拟IP（仅仅是举例子。）
　　在“双机热备”高可用（HA）系统中，当联系2个节点的“心跳线”断开时，本来为一整体、动作协调的HA系统，就分裂成为2个独立的个体。由于相互失去了联系，都以为是对方出了故障，2个节点上的HA软件像“裂脑人”一样，“本能”地争抢“共享资源”、争起“应用服务”，就会发生严重后果：或者共享资源被瓜分、2边“服务”都起不来了；或者2边“服务”都起来了，但同时读写“共享存储”，导致数据损坏（常见如数据库轮询着的联机日志出错）。
　　对付HA系统“裂脑”的对策，目前我所了解的大概有以下几条：
　　1）添加冗余的心跳线，例如双线条线。尽量减少“裂脑”发生机会。
　　2）启用磁盘锁。正在服务一方锁住共享磁盘，“裂脑”发生时，让对方完全“抢不走”共享磁盘资源。但使用锁磁盘也会有一个不小的问题，如果占用共享盘的一方不主动“解锁”，另一方就永远得不到共享磁盘。现实中假如服务节点突然死机或崩溃，就不可能执行解锁命令。后备节点也就接管不了共享资源和应用服务。于是有人在HA中设计了“智能”锁。即，正在服务的一方只在发现心跳线全部断开（察觉不到对端）时才启用磁盘锁。平时就不上锁了。
　　3）设置仲裁机制。例如设置参考IP（如网关IP），当心跳线完全断开时，2个节点都各自ping一下参考IP，不通则表明断点就出在本端，不仅“心跳”、还兼对外“服务”的本端网络链路断了，即使启动（或继续）应用服务也没有用了，那就主动放弃竞争，让能够ping通参考IP的一端去起服务。更保险一些，ping不通参考IP的一方干脆就自我重启，以彻底释放有可能还占用着的那些共享资源。
　　# What does "split-brain" mean?
　　"Split brain" is a condition whereby two or more computers or groups of computers lose contact with one another but still act as if the cluster were intact. This is like having two governments trying to rule the same country. If multiple computers are allowed to write to the same file system without knowledge of what the other nodes are doing, it will quickly lead to data corruption and other serious problems.
　　Split-brain is prevented by enforcing quorum rules (which say that no group of nodes may operate unless they are in contact with a majority of all nodes) and fencing (which makes sure nodes outside of the quorum are prevented from interfering with the cluster).
　　# What does "split-brain" mean?
　　"Split brain" is a condition whereby two or more computers or groups of computers lose contact with one another but still act as if the clus ...
　　这个应该是红帽文档吧？
　　简单来说，脑裂就是上面提到的当心跳网络出现状况的时候，集群可能分裂成几个节点组，几个节点组都分别接管服务并且访问文件系统资源（例如并发写入文件系统）导致数据损坏。
　　实际上脑裂正常情况下是无法见到的，现代集群都应该有保护机制来避免这种情况发生。例如RHCS引入的fence的概念。
　　具体情况是这样，例如2个节点集群，当心跳断开导致节点之间互相无法通信的时候，每个节点会尝试fence掉对方（确保对方释放掉文件系统资源）后再继续运行服务访问资源。这样，就可以确保只有一个节点可以访问资源而不会导致数据损坏。
　　所以这个也是RHCS为什么必须有fence设备的原因。前面很多帖子都在讨论到底要不要fence，官方讲法是，如果你跑生产，要保证数据不受损坏，就必须有fence设备。
　　集群出现bug的时候也会出现脑裂，这里就不提怎么产生脑裂了，希望大家都别碰到。。。 呵呵
　　前一阵，在为广发银行搭建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  smart404ith [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.