2011年（28）
分类： LINUX
2011-08-03 09:34:19
名为 High-Availability Linux 的开源项目的目标是，通过社区开发努力提供一个提升 Linux 可靠性（reliability）、可用性（availability）和可服务性（serviceability）（RAS）的群集解决方案。Linux-HA 项目得到了广泛的应用，是很多有趣的高可用性解决方案的重要组成部分。
heartbeat 是可以从 Linux-HA 项目 Web 站点公开获得的软件包之一。它提供了所有 HA 系统所需要的基本功能，比如启动和停止资源、监测群集中系统的可用性、在群集中的节点间转移共享 IP 地址的所有者等。它通过串行线、以太网接口或者同时使用二者来监测特定服务（或多个服务）的健康状况。当前版本支持两节点配置，使用专门的 heartbeat“pings”来检查服务的状态和可用性。heartbeat 为比本文中所描述的更复杂的情形提供了基础，比如 active/active 配置，该配置中两个节点是并行工作的，负责完成负载平衡。
要获得更多关于将 heartbeat 和项目应用在什么地方的资料，请访问 Linux-HA 项目的 Web 站点（请参阅 参考资料中的链接）。
这些文章中测试使用的群集配置如图 1 所示。该设置包括一对构成群集服务器（ha1 和 ha2），两者都可以访问包含多个物理磁盘的磁盘盒；服务器处于冷备份模式。应用程序数据需要位于两个节点都可访问的共享设备上。该设备可以是一个共享磁盘，或者网络文件系统。为了防止数据被破坏，设备本身应该被镜像或者具有数据保护。这种配置经常被称作 共享磁盘群集，不过，实际上，这是一个什么都不共享的体系结构，因为在同一时刻任何磁盘都只能被一个节点访问。
在测试设置中，我使用的共享磁盘机制是 NFS，如图 2 所示，不过，我建议使用如图 1 所示的选项，尤其是在产品环境中时。两个系统的串口之间的直连线缆用来在两个节点间传输 heartbeat。
表 2 给出的是我所使用的两个节点的配置。在本例中，可以通过 DNS 或者两个节点上的 /etc/hosts 文件得到主机名和 IP 地址。
| 角色 | 主机名 | IP 地址 |
| 共享（群集） | ha.haw2.ibm.com | 9.22.7.46 |
| Node1（主） | ha1.haw2.ibm.com | 9.22.7.48 |
| Node2（备份） | ha2.haw2.ibm.com | 9.22.7.49 |
| Node 3（未知） | ha3.haw2.ibm.com | 9.23.7.50 |
| NFS 服务器 | hanfs.haw2.ibm.com | 9.2.14.175 |
通过两个节点的串口，使用一根直连线缆将它们连接起来。现在测试串行连接，如下所示：
在 ha1（接收者）上输入以下内容：
cat < /dev/ttyS0
在 ha2（发送者）上输入以下内容：
echo "Serial Connection test" > /dev/ttyS0
您应该会在接收者节点（ha1）上看到这些文本。如果成功，那么互换它们的角色，重新再试一次。
如前所述，在测试设置中，我使用 NFS 在节点间共享数据。
要设置并运行 NFS，需要执行以下操作：
| ... /ha 9.22.7.48(rw,no_root_squash) /ha 9.22.7.46(rw,no_root_squash) /ha 9.22.7.35(rw,no_root_squash) /ha 9.22.7.49(rw,no_root_squash) /ha 9.22.7.50(rw,no_root_squash) ... |
| ... nfsha.haw2.ibm.com:/ha /ha nfs noauto,rw,hard 0 0 ... |
稍后，我们将配置 heartbeat 来安装该文件系统。
| cd /ha tar xvfz hahbcode.tar.gz |
通过 参考资料中的链接下载 heartbeat，然后输入清单 4 中的命令，在 ha1 和 ha2 这两台机器上安装它（按照给出的顺序）。
| rpm -ivh heartbeat-pils-1.2.2-8.rh.el.3.0.i386.rpm rpm -ivh heartbeat-stonith-1.2.2-8.rh.el.3.0.i386.rpm rpm -ivh heartbeat-1.2.2-8.rh.el.3.0.i386.rpm |
要使用 heartbeat，必须配置三个文件：authkeys、ha.cf 和 haresources。我将给出实现中我使用的具体配置；如果需要更多资料，请参阅 heartbeat Web 站点，并阅读它们的文档（请参阅 参考资料）。
该文件确定了为群集所使用的认证密钥；两个节点上的密钥必须相同。有三种认证模式可以选择：crc、md5 或 sha1。如果您的 heartbeat 运行在一个安全的网络上，比如例子中的交叉线缆，那么应该使用 crc。从资源的角度看，该方法的花费最低。如果您的网络不够安全，但您不是特别多疑，或者不是很关心最小化 CPU 资源的使用，那么应该使用 md5。最后，如果您想要得到最好的认证，而不考虑 CPU 资源的使用，那么请使用 sha1，因为它最难破解。
文件的格式如下：
auth[ ]
在测试设置中，我选择的是 crc 模式。清单 5 给出了 /etc/ha.d/authkeys 文件。要确保其许可是安全的，比如 600。
| auth 2 2 crc |
这个文件将位于安装后创建的 /etc/ha.d 目录中。它告诉 heartbeat 使用哪些类型的媒体路径以及如何配置它们。该文件还定义了群集中的节点，以及 heartbeat 用来确认系统是否在运行的接口。清单 6 给出了我的设置中 /etc/ha.d/ha.cf 文件的相关部分。
| ... # File to write debug messages to debugfile /var/log/ha-debug # # # File to write other messages to # logfile /var/log/ha-log # # # Facility to use for syslog()/logger # logfacility local0 # # # keepalive: how long between heartbeats? # keepalive 2 # # deadtime: how long-to-declare-host-dead? # deadtime 60 # # warntime: how long before issuing "late heartbeat" warning? # warntime 10 # # # Very first dead time (initdead) # initdead 120 # ... # Baud rate for serial ports... # baud 19200 # # serial serialportname ... serial /dev/ttyS0 # auto_failback: determines whether a resource will # automatically fail back to its "primary" node, or remain # on whatever node is serving it until that node fails, or # an administrator intervenes. # auto_failback on # ... # # Tell what machines are in the cluster # node nodename ... -- must match uname -n node ha1.haw2.ibm.com node ha2.haw2.ibm.com # # Less common options... # # Treats 10.10.10.254 as a pseudo-cluster-member # Used together with ipfail below... # ping 9.22.7.1 # Processes started and stopped with heartbeat. Restarted unless # they exit with rc=100 # respawn hacluster /usr/lib/heartbeat/ipfail ... |
该文件描述的是 heartbeat 管理的资源。这些资源本质上只是一些 start/stop 脚本，非常类似于在 /etc/rc.d/init.d 中用来启动和停止资源的那些脚本。注意，heartbeat 会在 /etc/rc.d/init.d 和 /etc/ha.d/resource.d 中去寻找脚本。脚本文件 httpd 是 heartbeat 自带的。清单 7 给出了我的 /etc/ha.d/haresources 文件：
| ha1.haw2.ibm.com 9.22.7.46 Filesystem::nfsha.haw2.ibm.com:/ha::/ha::nfs::rw,hard httpd |
该文件在两个节点上必须相同。
这一行指出，在启动时，要实现以下操作：
在后面的文章中，我将向这个文件中添加更多的资源。在关闭时，heartbeat 将执行以下操作：
这假定 uname -n 命令会显示 ha1.haw2.ibm.com；您的配置中可能只显示 ha1，如果是那样的话，请使用 ha1。
在这个步骤中，我将对 Apache Web 服务器的设置进行一些修改，使得它可以为共享系统上的文件提供服务，并为机器 ha1 和 ha2 的本地文件系统中的文件提供服务。index.html 文件（包含于代码示例中）将从共享的磁盘获得服务，而 hostname.html 文件将从机器 ha1 和 ha2 上的本地文件系统获得服务。要实现 Apache Web 服务器的 HA，请执行以下操作：
必须修改文件中的群集名称。
修改这个文件中的群集名称和节点名称。
现在您就已经准备好测试 HA 实现了。
要测试 Web 服务器的高可用性，请执行以下操作：
如果该命令失败，那么去查看 /var/log/messages，以确定原因并进行改正。heartbeat 成功启动后，您应该看到一个新的网络接口，其 IP 地址是您在 ha.cf 文件中配置的那个 IP 地址。启动 heartbeat 之后，查看一下主节点上的日志文件（默认是 /var/log/ha-log），确保它正在进行 IP 接管并启动 Apache Web 服务器。使用 ps 命令来确保 Web 服务器后台进程正在主节点上运行。heartbeat 将不会在备份节点上启动任何 Web 服务进程。只是在主节点失败时才会在备份节点上启动 Web 服务进程。
注意，在上面我使用的是群集地址，而不是主节点的地址。
对于第一个 URL，浏览器将显示下面的文本：
Hello!!! I am being served from a High Availability Cluster ha.haw2.ibm.com对于第二个 URL，浏览器将显示下面的文本：
Hello!!! I am being served from a node ha1.haw2.ibm.com in a High Availability Cluster ha.haw2.ibm.com您应该会看到，在一分钟之内，第二个节点上的所有 Web 服务器进程都会启动。如果不是那样，那么去查看 /var/log/messages 来确定问题所在并改正它。
对于第一个 URL，浏览器将显示下面的文本：
Hello!!! I am being served from a High Availability Cluster ha.haw2.ibm.com对于第二个 URL，浏览器将显示下面的文本：
Hello!!! I am being served from a node ha2.haw2.ibm.com in a High Availability Cluster ha.haw2.ibm.com注意，现在正在为该页提供服务的节点是 ha2。
这样，通过将 Web 页放置在共享磁盘上，当主节点机器发生故障时，第二节点机器就可以向客户机提供其服务。故障转移对访问 Web 页的客户机来说是透明的。该技术同样适用于提供 CGI 脚本服务。
我希望您尝试使用该技术，用廉价的硬件和立即可用的软件建立一个可用性非常高的 Web 服务器。在本系列的下一篇文章中，您将看到如何使用 WebSphere MQ 来构建一个高可用性的消息队列服务器。
