重新启动群集之后，我们通过对主节点断电来造成一次故障。在 10 秒超时到时间以后，辅助节点再一次获取了资源。最后，我们通过拔掉串行接口和以太网接口来模拟两节点之间互连的完全失败。节点间通信的失败导致两台机器都试图充当主节点。这种情形被称为 “裂脑（split-brain）”。Heartbeat 在这种情形下的缺省行为说明了为什么 Heartbeat 需要多个使用不同媒介的互连媒介。在共享存储器设置中，存储器互连也可以作为 heartbeat 媒介使用，这减少了“裂脑”的机会。以下是来自 ha-log 的样本，它显示了关机过程：
heartbeat: 2001/09/07_14:49:46 info: mach_down takeover complete.
heartbeat: 2001/09/07_14:50:36 ERROR: TTY write timeout on [/dev/ttyS0] (no connection?)
heartbeat: 2001/09/07_14:52:53 WARN: Cluster node slave6 returning after partition
heartbeat: 2001/09/07_14:52:53 info: Heartbeat shutdown in progress.
heartbeat: 2001/09/07_14:52:53 ERROR: 105 lost packet(s) for [slave6] [191:297]
heartbeat: 2001/09/07_14:52:53 ERROR: lost a lot of packets!
heartbeat: 2001/09/07_14:52:53 info: Link slave6:eth1 up.
heartbeat: 2001/09/07_14:52:53 WARN: Late heartbeat: Node slave6: interval 211920 ms
heartbeat: 2001/09/07_14:52:53 info: Node slave6: status active
heartbeat: 2001/09/07_14:52:53 info: Giving up all HA resources.
heartbeat: 2001/09/07_14:52:53 info: Running /etc/ha.d/rc.d/status status
heartbeat: 2001/09/07_14:52:53 info: Running /etc/ha.d/rc.d/ifstat ifstat
heartbeat: 2001/09/07_14:52:53 info: Running /etc/ha.d/rc.d/shutdone shutdone
heartbeat: 2001/09/07_14:52:53 info: Releasing resource group: slave6 192.168.10.51 slapd
heartbeat: 2001/09/07_14:52:53 info: Running /etc/ha.d/resource.d/slapd stop
heartbeat: 2001/09/07_14:52:53 info: /etc/ha.d/resource.d/slapd: Shutting down
heartbeat: 2001/09/07_14:52:53 info: Running /etc/ha.d/resource.d/IPaddr 192.168.10.51 stop
heartbeat: 2001/09/07_14:52:53 info: IP Address 192.168.10.51 released
heartbeat: 2001/09/07_14:52:54 info: All HA resources relinquished.
heartbeat: 2001/09/07_14:52:54 info: Heartbeat shutdown in progress.
heartbeat: 2001/09/07_14:52:54 info: Giving up all HA resources.
heartbeat: 2001/09/07_14:52:54 info: All HA resources relinquished.
heartbeat: 2001/09/07_14:52:55 info: Heartbeat shutdown complete.
|
应在选择超时值时考虑这一问题。如果超时太短，负载繁重的系统会错误地触发接管，从而产生明显的“裂脑”关机。请参阅 Linux-ha FAQ 文档以获得有关这一点的更多信息。
故障转移后的恢复
如果当主 LDAP 服务器当机时，对 LDAP 名称空间进行了更新，则必须在重新启动主服务器之前重新同步 LDAP 数据库。有两种方法可做到这一点。如果可以中断服务的话，可以在 LDAP 服务器停止后手工复制数据库（缺省情况下，数据文件被放置在 /usr/local/var 中）。也可以使用 OpenLDAP 复制来恢复数据库而无需服务中断。首先，在以前的主节点上将 LDAP 服务器作为从服务器启动。然后在当前主节点上启动 slurpd 守护程序。在前主节点退出服务期间收到的更改将从新主节点“推”到原来的节点上。最后，在以前的主节点上停止从 LDAP 服务器，并启动 Heartbeat。这将导致向原始配置进行故障回复。
针对 Apache 的 LDAP 配置
这里是向 LDAP 服务器进行订阅的应用程序示例。该应用程序是 Apache Web 服务器，使用 mod_auth_ldap 软件包。
结束语
本文是一个非常简单的示例，使用开放源码软件创建一些高度可用的基本网络服务。网络服务（包括 LDAP）很少需要大型服务器。由群集提供的额外可靠性以及服务器和数据文件的复制可以增加服务可用性。系统经历了所有的测试，在所有情况下都在 15 秒内进行了故障转移。假如对系统负载和利用率有较好的理解，可以把故障转移时间减少到这个阈值以下。
ChinaITLab收集整理