分类: LINUX
2008-04-28 22:31:34
常规 Heartbeat 准备
有几个较好的基本 Heartbeat 配置示例可供使用(请参阅本文的结尾部分)。以下是我们的配置中相关的内容。我们的配置非常简单,所以没有多少内容。缺省情况下,所有的配置文件都保存在 /etc/ha.d/中。
ha.cf包含群集的全局定义。我们对所有的超时都采用缺省值。
|
haresources该文件是配置故障转移的地方。在文件的底部有些有趣的东西。
slave6 192.168.10.51 slapd
我们在这里指明了三件事。资源的主要所有者是节点‘slave6’(该名称必须与您打算设为主节点机器的‘uname -n’输出相匹配)。我们的服务地址(虚拟 IP)是‘192.168.10.51’(本示例是在专用实验室网络完成的,所以使用 192.168 地址)。服务脚本的名称是‘slapd’。Hearbeat 将在 /etc/ha.d/resource.d 和 /etc/init.d 中寻找脚本。
服务脚本对于简单“冷备用”情况,我们可以不加修改地使用标准 /etc/init.d/slapd 脚本。我们希望做一些特别的事,因此我们创建了自己的 slapd 脚本,该脚本在 /etc/ha.d/resource.d/中。 Heartbeat 将该目录放置在其搜索路径中的第一位,因此我们不必担心会运行 /etc/init.d/slapd 脚本。但是,您应该检查以确保引导时不再启动 slapd(从 /etc/rc.d 树结构除去所有 S*slapd 文件)。首先,我们在第 17 行和第 18 行指明 slapd 服务器的启动配置文件。
该脚本遵循标准 init.d 语法,因此启动信息包含在从第 21 行开始的 test_start() 函数中。首先,我们停止当前运行的所有 slapd 实例。在第 39 行,我们使用主服务器配置文件启动主服务器。我们的设计将遵循这样的规则:如果主节点和辅助节点都已启动,则在主节点上将 slapd 作为主服务脚本启动,在辅助节点上将 slapd 作为从服务脚本启动,并启动复制守护程序。如果只有一个节点启动,则将 slapd 作为主服务脚本启动。将虚拟 IP 绑定到 slapd 主服务脚本。要完成这一点,我们必须知道哪个节点正在执行该脚本,如果是主节点,那么我们需要知道辅助节点的状态。重要的内容在脚本的‘start’分支中。因为我们已经在 Heartbeat 配置中指明了主节点,所以我们知道当 test_start() 函数运行时,它运行在 Heartbeat 主节点上(因为 Heartbeat 使用 /etc/init.d/ 脚本,因此所有的脚本都用参数“start|stop|restart”调用)。当调用脚本时,Heartbeat 会设置许多环境变量。下面是我们感兴趣的一个:
HA_CURHOST=slave6
可以使用‘HA_CURHOST’值来了解何时正在主节点(slave6)上执行以及何时处于故障转移中(HA_CURHOST 应是‘slave5’)。现在我们需要知道另一个节点的状态。要了解这一点,可以“询问” Heartbeat。我们将使用随 Heartbeat 一同提供的 api_test.c文件,并创建一个简单的客户机来“询问”节点状态(api_test.c 文件有许多内容都与客户机有关,我们只需除去不需要的内容,然后添加一条输出语句)。请注意程序中执行查询的第 31 行。
Heartbeat 查询源代码清单
编译后,我们将文件安装在 /etc/ha.d/resource.d/中。程序的名称为‘other_state’。以下是访问完整的故障转移脚本的链接,我们还是从与 Heartbeat 一同提供的示例脚本开始,并增加少许修改:
启动脚本
测试
我们现在可以在两个服务器上都启动 Heartbeat。Heartbeat 文档包含一些有关测试基本设置的信息,所以我们将不在这里重复。在连接了两种 heartbeat 媒介的情况下,您应该看到六个 heartbeat 进程正在运行。为了验证故障转移,我们做了几种测试。为了提供测试用的客户机,我们创建了一个简单的 KDE 应用程序,该应用程序查询服务器并显示连接的状态。真正的客户机在这种情况下只查询虚拟 IP,但我们查询所有的三个 IP,以作为演示之用。为进行该测试,我们每小时发送一万条查询。
S6 是主 LDAP 服务器,S5 是活动的备用服务器。下面的框代表虚拟 IP。在正常状态下,S5 和 S6 都为绿色,表明成功的查询。
首先,我们停止主节点上的 heartbeat 进程。在此情况下,从机器在 10 秒钟的节点超时出现后获得资源,如日志摘录中所示:接管过程包括启动脚本中额外的 2 秒延迟。
|