1. 本章详细介绍stonith，当两台服务器都尝试要去接管资源的时候，就会出现split-brain的情况，当“心跳线”出现问题的时候，最容易出现这 种情况。这种情况是很致命的，他可能导致服务无法正常运行，更坏的是，有可能导致数据遭破坏，因为此时两台服务器都可能对一个数据源进行读写，这就很有可 能导致问题，就算两台服务器都只会写各自的存储设备，但也会导致两台服务器的存储内容不一致，所以这种情况要尽量避免，heartbeat给出的解决方案 就是－－stonith
2. stonith要能正常执行，需要一定的硬件设备。该设备具有这样的特性，他可以连接在HA的两台服务器上（或连接在一台上也可），而且能通过软件命令的 方式给这个设备发送指令，然后该设备直接将被控制的服务器重启或断电，通过这种方式，快速的重启或关闭一台服务器，从而避免split-brain的情况 发生。
2. stonith要能正常执行，需要一定的硬件设备。该设备具有这样的特性，他可以连接在HA的两台服务器上（或连接在一台上也可），而且能通过软件命令的 方式给这个设备发送指令，然后该设备直接将被控制的服务器重启或断电，通过这种方式，快速的重启或关闭一台服务器，从而避免split-brain的情况 发生。
3. 本节开始介绍一个实际例子。该例子不是很常见，而且有一定的局限性，原因就在于这个例子中只使用了一个stonith设备，该设备连接了一台服务器，换言 之，如果stonith设备连接了primary server，那么，在该例子中，只能由backup server发送命令，让primary server重启，primary server无法让backup server重启或关闭。
4. OK，该例子的硬件连接图如下：附件1
5. 从附件的图上可以看出，本例有如下两点局限性：(1)所有的resource只能跑在primary server上 (2)failover只能从primary server -> backup server，因为一旦failover发生，backup server会发送命令让primary server关闭或重启以保证不会发生split-brain的情况
6. OK，在这种架构下，如果failover发生，那么，会变成这种样子，见附件2
7.上图画的很清楚了，当heartbeat消失（可能是primary server down了，也可能是心跳线出现了问题），backup server通过stonith device发送reset的命令，从而将primary server强行重启，如果auto_failback是配置成on的话，那么，有可能在primary server重启完成后，重新取回资源的控制权，但是通过这种方式，有效的避免了split-brain情况的发生。
4. OK，该例子的硬件连接图如下：附件1
5. 从附件的图上可以看出，本例有如下两点局限性：(1)所有的resource只能跑在primary server上 (2)failover只能从primary server -> backup server，因为一旦failover发生，backup server会发送命令让primary server关闭或重启以保证不会发生split-brain的情况
6. OK，在这种架构下，如果failover发生，那么，会变成这种样子，见附件2
7.上图画的很清楚了，当heartbeat消失（可能是primary server down了，也可能是心跳线出现了问题），backup server通过stonith device发送reset的命令，从而将primary server强行重启，如果auto_failback是配置成on的话，那么，有可能在primary server重启完成后，重新取回资源的控制权，但是通过这种方式，有效的避免了split-brain情况的发生。
8. 然后给出目前heartbeat支持的一部分stonith设备的清单：见附件1
9. 除了上面那些真实设备之外，heartbeat还支持一些fake的device，通过这些device，可以让我们模拟情况来debug stonith是否能正常工作。见附件2
10. 在我们安装了heartbeat的stonith的package之后，可以通过这个命令来查看当前heartbeat支持的stonith device列表：/usr/sbin/stonith -L
11. 下面开始讲解Meatware device。这是一个fake的stonith device，但是可以用来给我们调试stonith。当我们配置了一个meatware的stonith device之后，stonith不会去发送什么command给stonith device，然后简单的发布一个operator alert（一般可以在heartbeat的日志中查看到这条信息），通过这种方式，可以让我们测试一下stonith。
12. 通过以下命令创建一个meatware device:
#/usr/sbin/stonith -t meatware -p "" chilly
这个命令表示为host chilly创建一个meatware type的stonith device，parameter为空。
执行完这个命令后，查看/var/log/messages文件，会发现：
STONITH: OPERATOR INTERVENTION REQUIRED to reset test.
STONITH: Run "meatclient -c test" AFTER power-cycling the machine.
这表示STONITH让我们运行meatclient -c chilly这个命令，从而对重启chilly这台机器做一次测试。如果我们真的有chilly这台机器，那么就需要手动将这台机器重启一下，然后执行 meatclient -c chilly这个命令将这条stonith的event清除掉。由于我们没有chilly这台机器，所以直接执行：meatclient -c chilly，将这条event清除。执行这条命令或，会出现：
WARNING!
If server "chilly" has not been manually power-cycled or disconnected from all shared resources and networks, data on shared disks may become corrupted and migrated services might not work as expected.
Please verify that the name or address above corresponds to the server you just rebooted.
PROCEED? [yN]
按下y之后，出现：
Meatware_client: reset confirmed.
13. 这样，一个meatware device创建完成了，然后我们就可以在ha.cf中配置了，在两台服务器的/etc/ha.d/ha.cf中都添加这样一行：
stonith_host * meatware
OK了，第二个参数的作用是告诉heartbeat哪台服务器是连接在stonith device上的，这里用了一个*，表示两台服务器都物理连接在了stonith device上，stonith可以对任何一台都做reset这样的动作，因为我们用的是meatware，所以当然可以这样写，如果是真实设备，那么， 按照具体的来写。
14. 这样就OK了，把两台服务器的heartbeat都启动起来，然后用kill -9将primary server的heartbeat进程杀掉（注意不要用service heartbeat stop这样的命令哦，因为这个命令会将primary server上的资源安全卸载，backup server顺利接收，从而构不成split-brain的情况，只有强行杀掉，模拟服务器失效的场景），此时观察backup server的/var/log/messages：
backupserver heartbeat[835]: info: **************************
backupserver heartbeat[835]: info: Configuration validated. Starting heartbeat <version>
backupserver heartbeat[836]: info: heartbeat: version <version>
backupserver heartbeat[836]: info: Heartbeat generation: 3
backupserver heartbeat[836]: info: UDP Broadcast heartbeat started on port 694 (694) interface eth0
backupserver heartbeat[841]: info: Status update for server backupserver: status up
backupserver heartbeat: info: Running /etc/ha.d/rc.d/status status
backupserver heartbeat[841]: info: Link backupserver:eth0 up.
backupserver heartbeat[841]: WARN: server primaryserver: is dead
backupserver heartbeat[841]: info: Status update for server backupserver: status active
backupserver heartbeat[847]: info: Resetting server primaryserver with [Meatware Stonith device]
backupserver heartbeat[847]: OPERATOR INTERVENTION REQUIRED to reset primaryserver.
backupserver heartbeat[847]: Run "meatclient -c primaryserver" AFTER power-cycling the machine.
backupserver heartbeat: info: Running /usr/local/etc/ha.d/rc.d/status status
backupserver heartbeat[852]: info: No local resources [/usr/local/lib/heartbeat/ResourceManager listkeys backupserver]
backupserver heartbeat[852]: info: Resource acquisition completed.
从上面的log信息可以看到，backup server并没有马上把sendmail服务启动（sendmail是本例中的resource），而是在等待我们清除meatware stonith event，这表示我们要手动重启primary server，然后用meatclient -c这样的命令清除event，这样heartbeat才会认为OK, primary server重启了，backup server可以安全的启动sendmail了，:)
15. 好的，那我们就开始清除这个event：
backupserver> meatclient -c primaryserver
此时，backup server的log如下：
backupserver heartbeat[847]: server primaryserver Meatware-reset.backupserver heartbeat[847]: info: server primaryserver now reset.
backupserver heartbeat[841]: info: Resources being acquired from primaryserver.
backupserver heartbeat: info: Running /usr/local/etc/ha.d/rc.d/stonith STONITH
backupserver heartbeat: info: Running /usr/local/etc/ha.d/rc.d/status status
backupserver heartbeat: stonith complete
backupserver heartbeat: info: Taking over resource group sendmail
backupserver heartbeat: info: Acquiring resource group: primaryserver sendmail
backupserver heartbeat: info: Running /etc/init.d/sendmail start
OK，backup server将sendmail启动起来了。
9. 除了上面那些真实设备之外，heartbeat还支持一些fake的device，通过这些device，可以让我们模拟情况来debug stonith是否能正常工作。见附件2
10. 在我们安装了heartbeat的stonith的package之后，可以通过这个命令来查看当前heartbeat支持的stonith device列表：/usr/sbin/stonith -L
11. 下面开始讲解Meatware device。这是一个fake的stonith device，但是可以用来给我们调试stonith。当我们配置了一个meatware的stonith device之后，stonith不会去发送什么command给stonith device，然后简单的发布一个operator alert（一般可以在heartbeat的日志中查看到这条信息），通过这种方式，可以让我们测试一下stonith。
12. 通过以下命令创建一个meatware device:
#/usr/sbin/stonith -t meatware -p "" chilly
这个命令表示为host chilly创建一个meatware type的stonith device，parameter为空。
执行完这个命令后，查看/var/log/messages文件，会发现：
STONITH: OPERATOR INTERVENTION REQUIRED to reset test.
STONITH: Run "meatclient -c test" AFTER power-cycling the machine.
这表示STONITH让我们运行meatclient -c chilly这个命令，从而对重启chilly这台机器做一次测试。如果我们真的有chilly这台机器，那么就需要手动将这台机器重启一下，然后执行 meatclient -c chilly这个命令将这条stonith的event清除掉。由于我们没有chilly这台机器，所以直接执行：meatclient -c chilly，将这条event清除。执行这条命令或，会出现：
WARNING!
If server "chilly" has not been manually power-cycled or disconnected from all shared resources and networks, data on shared disks may become corrupted and migrated services might not work as expected.
Please verify that the name or address above corresponds to the server you just rebooted.
PROCEED? [yN]
按下y之后，出现：
Meatware_client: reset confirmed.
13. 这样，一个meatware device创建完成了，然后我们就可以在ha.cf中配置了，在两台服务器的/etc/ha.d/ha.cf中都添加这样一行：
stonith_host * meatware
OK了，第二个参数的作用是告诉heartbeat哪台服务器是连接在stonith device上的，这里用了一个*，表示两台服务器都物理连接在了stonith device上，stonith可以对任何一台都做reset这样的动作，因为我们用的是meatware，所以当然可以这样写，如果是真实设备，那么， 按照具体的来写。
14. 这样就OK了，把两台服务器的heartbeat都启动起来，然后用kill -9将primary server的heartbeat进程杀掉（注意不要用service heartbeat stop这样的命令哦，因为这个命令会将primary server上的资源安全卸载，backup server顺利接收，从而构不成split-brain的情况，只有强行杀掉，模拟服务器失效的场景），此时观察backup server的/var/log/messages：
backupserver heartbeat[835]: info: **************************
backupserver heartbeat[835]: info: Configuration validated. Starting heartbeat <version>
backupserver heartbeat[836]: info: heartbeat: version <version>
backupserver heartbeat[836]: info: Heartbeat generation: 3
backupserver heartbeat[836]: info: UDP Broadcast heartbeat started on port 694 (694) interface eth0
backupserver heartbeat[841]: info: Status update for server backupserver: status up
backupserver heartbeat: info: Running /etc/ha.d/rc.d/status status
backupserver heartbeat[841]: info: Link backupserver:eth0 up.
backupserver heartbeat[841]: WARN: server primaryserver: is dead
backupserver heartbeat[841]: info: Status update for server backupserver: status active
backupserver heartbeat[847]: info: Resetting server primaryserver with [Meatware Stonith device]
backupserver heartbeat[847]: OPERATOR INTERVENTION REQUIRED to reset primaryserver.
backupserver heartbeat[847]: Run "meatclient -c primaryserver" AFTER power-cycling the machine.
backupserver heartbeat: info: Running /usr/local/etc/ha.d/rc.d/status status
backupserver heartbeat[852]: info: No local resources [/usr/local/lib/heartbeat/ResourceManager listkeys backupserver]
backupserver heartbeat[852]: info: Resource acquisition completed.
从上面的log信息可以看到，backup server并没有马上把sendmail服务启动（sendmail是本例中的resource），而是在等待我们清除meatware stonith event，这表示我们要手动重启primary server，然后用meatclient -c这样的命令清除event，这样heartbeat才会认为OK, primary server重启了，backup server可以安全的启动sendmail了，:)
15. 好的，那我们就开始清除这个event：
backupserver> meatclient -c primaryserver
此时，backup server的log如下：
backupserver heartbeat[847]: server primaryserver Meatware-reset.backupserver heartbeat[847]: info: server primaryserver now reset.
backupserver heartbeat[841]: info: Resources being acquired from primaryserver.
backupserver heartbeat: info: Running /usr/local/etc/ha.d/rc.d/stonith STONITH
backupserver heartbeat: info: Running /usr/local/etc/ha.d/rc.d/status status
backupserver heartbeat: stonith complete
backupserver heartbeat: info: Taking over resource group sendmail
backupserver heartbeat: info: Acquiring resource group: primaryserver sendmail
backupserver heartbeat: info: Running /etc/init.d/sendmail start
OK，backup server将sendmail启动起来了。
16. 使用一个real的stonith device。很显然，每个stonith device都有各自不同的配置，执行命令stonith -help可以看到如何配置这些device，配置一个real的stonith device的语法是这样的：
STONITH: Config file syntax: <serial_device> <server> <outlet> [ <server> <outlet> [...] ]
比如：
STONITH_host backupserver rps10 /dev/ttyS0 primaryserver.mydomain.com 0
这个配置表示: backup server可以通过stonith device控制primary server，stonith device通过/dev/ttyS0连接在backup server上（串口线），primary server是连接在名为rps10的stonith device的0号outlet（插口）上。
还是比较简单的，注意现在很多stonith device都是通过网线和服务器连接，此时的配置有可能还要配置登录的用户名和密码（增强安全性，防止黑客轻松重启这些服务器），而且在很多大厂的设备 中，比如hp，stonith device直接就集成在服务器内部也是有可能的。
17. 避免多次stonith event，如果我们将auto_failback配置成on，而且stonith是重启服务器而不是关闭，那么就有可能发生循环stonith的情况， 比如primary server down了，stonith device重启了他，当primary server起来后，接管回资源后又down了，那么又重复上述过程，这就是多次stonith，解决这种问题很简单，直接power off primary server，而不是reset他即可，要做到这样有两种办法，第一，修改heartbeat的source code（好夸张哦）：
rc = s->s_ops->reset_req(s, ST_GENERIC_RESET, nodename);
修改成：
rc = s->s_ops->reset_req(s, ST_POWEROFF, nodename);
或者是第二种办法，修改primary server的BIOS设定，很多机器的BIOS中可以设定reset信号收到时执行关机的动作而不是reset。
STONITH: Config file syntax: <serial_device> <server> <outlet> [ <server> <outlet> [...] ]
比如：
STONITH_host backupserver rps10 /dev/ttyS0 primaryserver.mydomain.com 0
这个配置表示: backup server可以通过stonith device控制primary server，stonith device通过/dev/ttyS0连接在backup server上（串口线），primary server是连接在名为rps10的stonith device的0号outlet（插口）上。
还是比较简单的，注意现在很多stonith device都是通过网线和服务器连接，此时的配置有可能还要配置登录的用户名和密码（增强安全性，防止黑客轻松重启这些服务器），而且在很多大厂的设备 中，比如hp，stonith device直接就集成在服务器内部也是有可能的。
17. 避免多次stonith event，如果我们将auto_failback配置成on，而且stonith是重启服务器而不是关闭，那么就有可能发生循环stonith的情况， 比如primary server down了，stonith device重启了他，当primary server起来后，接管回资源后又down了，那么又重复上述过程，这就是多次stonith，解决这种问题很简单，直接power off primary server，而不是reset他即可，要做到这样有两种办法，第一，修改heartbeat的source code（好夸张哦）：
rc = s->s_ops->reset_req(s, ST_GENERIC_RESET, nodename);
修改成：
rc = s->s_ops->reset_req(s, ST_POWEROFF, nodename);
或者是第二种办法，修改primary server的BIOS设定，很多机器的BIOS中可以设定reset信号收到时执行关机的动作而不是reset。
17. network failures. 到目前为止，我们已经做了很多努力来避免单点故障的情况，但是还不够，比如本节说到的network failure。这种情况是这样的，我们都知道，服务器通过网络对外提供服务，如果这个服务网络出现问题怎么办？（心跳线没有问题），此时clients 无法通过网络和primary server通讯，那么，服务就暂停了。对于这样的问题，我们有两种解决方案：
(1)运行一个第三方的监控程序，监控primary server是否能正常访问网络，如果发现通信异常，该监控程序将shutdown primary server上的heartbeat daemon，此时failover发生，backup server接管服务。
(2)使用heartbeat自带的ipfail plug-in，通过这个ipfail，我们可以在heartbeat中配置让ipfail定时的去ping一批服务器，如果ping发生异 常，ipfail会询问backup server "你的网络正常么？"，如果backup server能正常访问网络，那么failover发生。
本节描述第二种方法：
respawn hacluster /usr/lib/heartbeat/ipfail
ping 10.1.1.254 10.1.1.253
auto_failback off
从上可以看出，首先我们以hacluster用户的名义启动了ipfail这个daemon，然后ping 10.1.1.254和10.1.1.253两台服务器。这些配置可以添加在/etc/ha.d/ha.cf文件中最后部分（写在server配置的前面）
(1)运行一个第三方的监控程序，监控primary server是否能正常访问网络，如果发现通信异常，该监控程序将shutdown primary server上的heartbeat daemon，此时failover发生，backup server接管服务。
(2)使用heartbeat自带的ipfail plug-in，通过这个ipfail，我们可以在heartbeat中配置让ipfail定时的去ping一批服务器，如果ping发生异 常，ipfail会询问backup server "你的网络正常么？"，如果backup server能正常访问网络，那么failover发生。
本节描述第二种方法：
respawn hacluster /usr/lib/heartbeat/ipfail
ping 10.1.1.254 10.1.1.253
auto_failback off
从上可以看出，首先我们以hacluster用户的名义启动了ipfail这个daemon，然后ping 10.1.1.254和10.1.1.253两台服务器。这些配置可以添加在/etc/ha.d/ha.cf文件中最后部分（写在server配置的前面）
18. watchdog and softdog. watchdog分为硬件和软件两种，硬件就是专门的硬件狗了，当发现OS异常，就会重启机器；软件dog指的是linux kernel自带的一个softdog daemon，如果kernel不支持，那就要重新编译kernel了，一般我们用的redhat这些这个feature kernel都是有的，大不了是一个module。
19. 本节只讲softdog，用modprobe可以挂载softdog模块，挂载上了之后，当发现系统异常，softdog就会将系统置于一个kernel panic的状态，但是我们希望的是重启系统，而不是panic系统，这可以通过这样的配置来解决：
(1)修改lilo或grub的启动参数，在image=...这个之前加入：append="panic=60"
(2)这种方法更简便，如下：#echo 60 > /proc/sys/kernel/panic ，默认的panic时间是0，修改成60后，就会重启系统了。
20. heartbeat也支持watchdog，在/etc/ha.d/ha.cf文件中加入：
watchdog /dev/watchdog
这样dog就会监控heartbeat进程，如果我们kill了heartbeat的进程，那么，系统就会重启（因为软件狗在起作用）
19. 本节只讲softdog，用modprobe可以挂载softdog模块，挂载上了之后，当发现系统异常，softdog就会将系统置于一个kernel panic的状态，但是我们希望的是重启系统，而不是panic系统，这可以通过这样的配置来解决：
(1)修改lilo或grub的启动参数，在image=...这个之前加入：append="panic=60"
(2)这种方法更简便，如下：#echo 60 > /proc/sys/kernel/panic ，默认的panic时间是0，修改成60后，就会重启系统了。
20. heartbeat也支持watchdog，在/etc/ha.d/ha.cf文件中加入：
watchdog /dev/watchdog
这样dog就会监控heartbeat进程，如果我们kill了heartbeat的进程，那么，系统就会重启（因为软件狗在起作用）
21. heartbeat已经全部讲解完毕了，后面就会开始讲LVS了。这里有个总结，如何测试我们的heartbeat配置，书中给了一些建议，还不错，这里将内容提纲列在这里，详细的请参考书的内容：
(1)unplug the power cord on the primary server
(2)test the behavior of the hb_standby command
(3)unplug the production network cable on the primary server
(4)remove one of the heartbeat paths between the two servers
(5)remove all of the heartbeat paths between the two servers
(6)kill the heartbeat daemon on the primary server
(7)kill the resource daemons on the primary server（如果我们用了cl_respawn，那么heartbeat会自动重启resource，当发现resource script的status脚本不返回OK的时候）
(8)reboot both servers
(1)unplug the power cord on the primary server
(2)test the behavior of the hb_standby command
(3)unplug the production network cable on the primary server
(4)remove one of the heartbeat paths between the two servers
(5)remove all of the heartbeat paths between the two servers
(6)kill the heartbeat daemon on the primary server
(7)kill the resource daemons on the primary server（如果我们用了cl_respawn，那么heartbeat会自动重启resource，当发现resource script的status脚本不返回OK的时候）
(8)reboot both servers