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

在心跳失效的时候，就发生了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，它将在你的高可用配置中引入两个重要的限制：
一、 全部资源必须运行在主服务器上（在主服务器在线时不容许在备用服务器上运行资源）。
二、故障转移事件只能发生一次，并只能朝一个方向转移，也就是说，运行在主服务器上的资源只能故障转移到备用服务器一次，当备用服务器取得了资源的全部权时，关闭主服务器，要恢复到主服务器正常运行必需要操做员干预。
当你只使用一个stonith设备时，你必须在主服务器上运行全部的高可用资源，由于主服务器不能复位备用服务器的电源（当主服务器从故障中恢复后想要取回资源的全部权时，它须要复位备用服务器的电源），也就是说，备用服务器上的资源在没有第二个stonith设备时不是高可用的，在使用单个stonith设备时，故障转移后，也须要操做员干预，由于主服务器将关闭。

 

 

 

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

 

 

Stonith事件序列
一、当备用服务器听不到心跳时Stontih事件开始。
注意：这并不必定意味着主服务器没有发送心跳，心跳可能有多种缘由而没有抵达备用服务器，这就是为何建议至少须要两条物理路径传输心跳以免出现假象的缘由了。
二、备用服务器发出一个Stonith复位命令到Stonith设备。
三、Stonith设备关闭主服务器的电力供应。
四、一经切断主服务器的电源，它就不能再访问集群资源，也不能再为客户端提供资源，保证客户端计算机不能访问主服务器上的资源，排除可能发生的头脑分裂状态。
五、而后备用服务器得到主服务器的资源，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.cfstonith_host smart403 null smart404Smart403:此处设定主要服务器的节点名称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 deadheartbeat[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:  smart404heartbeat[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.