 |
|
级别： 初级
Hidayatullah Shaikh ([email protected]), 高级软件工程师, IBM
2005 年 3 月 28 日
对随需应变的商务而言，工作负载管理至关重要。IBM LoadLeveler 是一个作业管理系统，它通过匹配作业的处理需求与可用资源，让用户可以在更短的时间内运行更多作业。保持作业管理系统的最大限度系统正常运行时间日益重要。学习如何去使用 LoadLeveler 内在的高可用能力获得 LoadLeveler 集群的高可用性，以及如何使用开放源代码的高可用性软件来进一步提高其可用性。
IBM LoadLeveler 是一个工作负载管理系统，允许用户在一个资源池中提交、调度和执行作业。它为集群资源的最优化利用提供了动态调度和工作负载均衡的功能。它还为有效的作业和工作负载管理提供了单点控制。
LoadLeveler 在其每个客户机机器上作为一组后台进程运行。一组客户机机器从属于某个中央管理器机器的形式，称作是 LoadLeveler 集群，LoadLeveler 集群由配置文件来定义。
为了最大限度地理解并使用本文，您应该对 IBM LoadLeveler 和高可用集群有基本的了解。还应该熟悉本系列的第一篇文章 Linux 上的高可用中间件，第 1 部分：heartbeat 与 Apache Web 服务器。
使用 LoadLeveler 实现高可用性
在作业的调度中，LoadLeveler 集群的每一台机器都要扮演一个或者多个角色。这些角色以及它们如果出现故障会带来的影响如下：
-
调度机器（scheduling machine）： 作业提交的结果是，提交来的作业放置在调度机器所管理的一个队列中。调度机器询问中央管理器（接下来会描述此角色），找到可以运行那个作业的机器，然后调度机器还要在磁盘上保持关于作业的持久信息。
每个调度机器上的作业信息通常并不是共享的，也不能由 LoadLeveler 集群中其他调度机器所访问。调度机器独立运作，当某个调度机器出现故障时，位于出现故障的调度机器上的作业信息将临时不可使用（但并没有丢失）。在此期间，将不考虑执行等待被调度的作业。令调度机器尽可能快地恢复过来至关重要。在调度机器的高可用配置的示例中，必需的本地文件和目录都位于外部共享磁盘存储器上，这就使得当调度器节点出现故障时，备份的调度机器可以访问它们。
-
中央管理器机器（central manager machine）： 中央管理器的角色是，基于作业的需求在 LoadLeveler 集群中找到将要运行那个作业的一台或多台机器。找到机器后，它会通知调度机器。
中央管理器是 LoadLeveler 的中心控制点。LoadLeveler 允许您定义一个预备的中央管理器，在主中央管理器出现故障时它可以接管那个角色。稍后的一节将对此进行详细讨论。
当某个中央管理器出现故障，而又没有定义预备的中央管理器时，已经开始的作业将会继续运行直到完成，不会丢失信息，但是它们的状态将不会报告给用户。调度节点将会接受新的作业，稍后等中央管理器恢复后或者预备的中央管理器接管后再转发。
-
执行机器（executing machine）：运行作业的机器称为执行机器。
当某个执行节点出现故障时，在那个节点上运行的作业会失败，需要在节点恢复后重新开始运行。作业或者从头开始运行，或者从最后一个检查点开始运行。作业检查点可以选择作为一个选项，或者编入应用程序中。备份执行节点的建立，将直接提供在更短时间内重新开始运行作业的能力。不管有没有备份节点，当节点出现故障时，作业及其作业信息和检查点都不会丢失，因为借助合适的线缆和磁盘技术仍然可以访问它们的磁盘。
调度节点和执行节点都要维持关于它们的作业状态的持久信息。调度节点和执行节点通过一个协议来确保至少它们其中一个要在磁盘上保持那些状态信息。这样就确保了当调度节点或者执行节点出现故障时那些状态可以恢复。调度节点和执行节点都不会丢弃作业的信息，直到它被传递到其他节点并被接受。在本文所阐述的配置中，作业信息存储在一个共享磁盘上。
- 提交机器（submitting machine）：这台机器用于提交、查询和取消作业，没有任何关于作业的持久数据。由于没有任何持久数据，因而对这些机器来说高可用性并不重要。
客户机机器的角色取决于在它之上配置的是哪个 LoadLeveler 后台进程。总体上，集群具备构建、提交、执行和管理串行与并行批作业的能力。
接下来的章节讨论 LoadLeveler 可用于高用性的一些内在能力，以及可以如何使用 heartbeat 提高整个系统的可用性。
 |
|
安装 IBM LoadLeveler
本节介绍的是如何在三台机器上（ha1、ha2 和 ha3）安装 IBM LoadLeveler 3.2 for Linux™。这些步骤基于 LoadLeveler Installation Memo 文档（见 参考资料 中的链接）第 4 章中所列举的步骤。
- 为 LoadLeveler 创建如下目录：
- 本地目录：/var/loadl
- 主目录：/home/loadl
- 发布目录：/opt/ibmll/LoadL/full
- 中央管理器机器的名称：ha
- 以 root 身份登录
- 创建
loadl组名称。 下面的命令会在所有节点上创建一个组 ID 为 1000 的loadl组：
groupadd g 1000 loadl - 创建
loadl用户 ID。 下面的命令会在所有的节点上创建loadl用户标识：
useradd c loadleveler_user -d /home/loadl -s /bin/bash \ -u 1000 g 1000 -m loadl - 安装 LoadLeveler RPM
- 安装 license RPM（在
LLIMAGEDIR中包含有安装所用的 RPMS）
cd $LLIMAGEDIR rpm -Uvh LoadL-full-license-3.2.0.0-0.i386.rpm - 安装其他 RPM
cd /opt/ibmll/LoadL/sbin ./install_ll -y -d "$LLIMAGEDIR"
- 安装 license RPM（在
- 运行初始化脚本 llinit
- 创建本地目录：
mkdir /var/loadl - 设置所有者
chown loadl.loadl /var/loadl - 切换到
loadl
ID
su - loadl - 输入下面的命令，将当前目录切换到发布目录中的 bin 子目录：
cd /opt/ibmll/LoadL/full/bin - 确保您在 LoadLeveler 的主目录、本地目录和 /tmp 目录中有写权限
- 输入
llinit命令，如下：
./llinit -local /var/loadl -release /opt/ibmll/LoadL/full -cm ha
- 创建本地目录：
|
|
创建高可用的调度机器配置
在这个设置中：
- 机器 ha1 将作为主调度机器
- 机器 ha2 将作为备份调度机器
- 机器 ha3 将用作一台作业执行机器
在高可用配置中，ha1 所需要的本地文件和目录位于外部共享磁盘上，这就使得当调度节点出现故障时 ha2 可以使用它们。就是像下面这样设置的：
- 在 ha1 和 ha2 上以 root 身份登录。
- 在共享磁盘（/ha）上创建下面的目录：
- /ha/loadl/execute
- /ha/loadl/spool
- 在节点 ha1 上运行下面的命令来设置所有者：
chown loadl.loadl /ha/loadl/ chown loadl.loadl /ha/loadl/execute chown loadl.loadl /ha/loadl/spool - 在节点 ha1 和 ha2 上切换到
loadlID：
su - loadl - 在节点 ha1 上使用下面所示的命令对共享目录设置适当的权限：
chmod 0777 /ha/loadl/execute chmod 775 /ha/loadl/spool - 在节点 ha1 和 ha2 上，删除 /var/loadl 下的 execute 和 spool 目录。
rm -rf /var/loadl/execute rm rf /var/loadl/spool - 在节点 ha1 和 ha2 上使用下面的命令创建指向共享目录的符号链接：
ln -s /ha/loadl/execute /var/loadl/execute ln -s /ha/loadl/spool /var/loadl/spool - 编辑机器的节文件（stanza）。下面是不同节点上 LoadL_admin（在 /home/loadl）文件的相关部分：
- ha1 作为主调度机器和中央管理器。在生产环境中，建议将中央管理器和调度后台程序安排在不同的机器上。
... ha1: type = machine central_manager = true schedd_host = true ha3: type = machine ... - ha2 作为备份的调度机器和中央管理器
... ha2: type = machine central_manager = true schedd_host = true ha3: type = machine ... - ha3 作为执行机器
... ha: type = machine central_manager = true schedd_host = true ha3: type = machine ...
- ha1 作为主调度机器和中央管理器。在生产环境中，建议将中央管理器和调度后台程序安排在不同的机器上。
- 修改不同机器上 LoadL_config（在 /home/loadl 目录下）文件中的
RUNS_HERE标记，如下：
- ha1 和 ha2
... SCHEDD_RUNS_HERE = True STARTD_RUNS_HERE = False ...这将确保作业不会被调度到调度机器上去执行。我们希望 ha1 和 ha2 只作为调度机器。
- ha3
... SCHEDD_RUNS_HERE = False STARTD_RUNS_HERE = True ...
- ha1 和 ha2
- 编辑三个节点上的 /etc/hosts 文件，如下：
- ha1
... 9.22.7.46 ha.haw2.ibm.com ha 9.22.7.46 ha2.haw2.ibm.com ha2 ... - ha2
... 9.22.7.46 ha.haw2.ibm.com ha 9.22.7.46 ha1.haw2.ibm.com ha1 ... - ha3
... 9.22.7.46 ha.haw2.ibm.com ha 9.22.7.46 ha1.haw2.ibm.com ha1 9.22.7.46 ha2.haw2.ibm.com ha2 ...
- ha1
|
|
配置 heartbeat 来管理调度机器
要配置 heartbeat 来管理 LoadLeveler：
- 创建一个启动和停止 LoadLeveler 进程的脚本。清单 1 展示了一个非常基本的脚本。可以根据您的设置进行进一步定制。将这个脚本放入 /etc/rc.d/init.d 目录中。
清单 1. loadl 脚本
#!/bin/bash # # /etc/rc.d/init.d/loadl # # Starts the loadleveler processes # # chkconfig: 345 89 56 # description: Runs loadleveler . /etc/init.d/functions # Source function library. PATH=/usr/bin:/bin:/opt/ibmll/LoadL/full/bin #====================================================================== SU="sh" if [ "`whoami`" = "root" ]; then SU="su - loadl" fi #====================================================================== start() { echo "$0: starting loadleveler" $SU -c "llctl start" } #====================================================================== stop() { echo "$0: Stoping loadleveler" $SU -c "llctl stop" } case $1 in 'start') start ;; 'stop') stop ;; 'restart') stop start ;; *) echo "usage: $0 {start|stop|restart}" ;; esac - 现在修改 /etc/ha.d/haresources 文件（在两台调度机器节点上），令它们包含上面的 loadl 脚本。修改后的文件相关部分是：
ha1.haw2.ibm.com 9.22.7.46 Filesystem::hanfs.haw2.ibm.com:/ha::/ha::nfs::rw,hard loadl这一行表明，在启动 heartbeat 时，令 ha1 服务集群 IP 地址，挂载共享的文件系统，然后启动 LoadLeveler 后台进程。在关闭时，heartbeat 将首先停止 LoadLeveler，然后卸载共享文件系统，最后释放 IP。
|
|
测试调度机器失效切换
本节将阐述如何测试调度后台进程的高可用性。
- 使用下面的命令先后在主节点和备份节点上启动 heartbeat 服务：
/etc/rc.d/init.d/heartbeat start当 heartbeat 成功启动后，您应该可以看到一个新的界面（interface），其 IP 是您在 ha.cf 文件所配置的那个。启动了 heartbeat 后，去看一下主节点上的日志文件（默认是 /var/log/ha-log），并确保它正在接管 IP 并启动了 LoadLeveler。通过
ps命令确认 LoadLeveler 后台进程正在在主节点上运行。heartbeat 将不会在备份节点上启动上述任何一个进程。只是在主节点出现故障后才会启动它们。 - 使用下面的命令以用户 loadl 的身份 在 ha3 上启动 loadleveler 后台进程：
llctl start - 通过耗尽
startd后台进程，令 ha3 不能作为一台执行机器。为了测试失效切换，这需要在提交作业后再留出足够的时间。以用户 loadl 的身份在节点 ha3 上执行下面的命令：
llctl drain startd - 在 ha1 机器上，以用户 loadl 的身份使用下面的命令查看哪些作业已经调度到 LoadLeveler 集群：
llq在我们的设置中命令的输出如图 1 所示。这个命令将列出 LoadLeveler 集群中所有未完成的旧的作业。
图 1. 在节点 ha1 上 llq 命令的输出在 ha1 机器上，以用户 loadl 的身份使用下面的命令查看 LoadLeveler 集群中机器的状态：
llstatus
图 2. 在节点 ha1 上 llstatus 命令的输出在图 2 中，您可以看到，在 ha1 机器上 Scehdd 是可用的，而由于前面的第三个步骤，ha3 机器上的 Startd 已经被耗尽了。
- 设置示例目录的所有者。 在节点 ha3上（作业将要执行的地方）执行下面的命令：
chown loadl.loadl /opt/ibmll/LoadL/full/samples - 提交一个作业。 在机器 ha1 上以用户 loadl 的身份执行下面的命令，提交一个 LoadLeveler 所附带的示例作业：
cd /home/loadl/samples llsubmit job1.cmd如果成功，您将看到一条类似如下的消息：
llsubmit: The job "ha1.haw2.ibm.com.23" with 2 job steps has been submitted.示例 job1 是一个具有两个步骤的作业，结果是创建两个新的作业步骤。这两个新的作业步骤将变成停止状态（I），因为没有可用的执行机器。见图 3。
图 3. job1 提交后节点 ha1 上 llq 命令的输出现在，让主调度机器出现故障。
- 模拟失效切换。 只要使用下面这个命令在主系统中停止 heartbeat 即可。
/etc/rc.d/init.d/heartbeat stop在不到一分钟之内，您应该就会看到在备份机器上所有的服务都启动起来。可以在备份机器上通过检查 /var/log/ha-log 文件并执行
ps命令来确认 LoadLeveler 正在备份机器上运行。备份机器接管控制权后，在备份机器上以用户 loadl 的身份运行llstatus和llq命令。图 4 和图 5 给出了运行这两个命令的输出。
图 4. 失效切换后，在节点 ha2 上 llq 命令的输出
图 5. 失效切换后，在节点 ha2 上 llstatus 命令的输出在图 4 和图 5 中，注意：
- 所有先前的未完成的作业，包括上面步骤 6 中提交的作业所对应的两个作业。这就证明了当机器发生失效切换时作业信息都保存了下来。
- 现在在 ha2 机器上 schedd 是可用的。
- 在 ha3 机器上 startd 仍然是停止的。
- 通过在 ha3 上以用户 loadl 的身份执行下面的命令，重新恢复 ha3 机器上的 startd 后台进程：
llctl resume startdha3 机器现在可以用于执行作业。两个作业应该会变为运行状态，并且应该在 ha3 机器上最终完成。在 ha3 机器上的 /home/loadl/samples 目录中有由这两个步骤的作业所创建的 .out 文件，可以查看它们以确认作业的完成。对这次运行而言，您应该会看到两个文件，即 job1.ha1.23.0.out 和 job1.ha1.23.1.out。
- 重新在主节点上启动 heartbeat 服务。这应该会停止备份节点上的 LoadLeveler 进程，并在主节点上启动它们。主节点同样会接管集群 IP。使用下面这个命令启动 heartbeat 服务：
/etc/rc.d/init.d/heartbeat start您可以看到，在主调度节点出现故障前提交的作业，在备份节点接管后如何通过共享磁盘被恢复。
|
|
建立中央管理器的高可用性
如果您决定像安排调度机器那样将中央管理器安置在独立的节点上（ha4），那么您可以利用中央管理器内在的高可用性。要尝试这种配置，请在所有机器的配置文件中将 ha4 定义为中央管理器。
网络通信、软件或者硬件出现故障的问题都会导致中央管理器不可使用。在这种情况下， LoadLeveler 集群中的其他机器将认为中央管理器机器不再运转。为解决这个问题，您可以在机器的节文件中指派一个或多个备用的中央管理器来接手控制。
下面的机器节文件示例将机器 ha5 定义为一台备用的中央管理器：
ha5: type = machine
central_manager = alt
|
如果主中央管理器出现故障，那么备用的中央管理器就会成为中央管理器。当某个备用中央管理器成为中央管理器时，作业不会丢失，但集群中所有的机器向新的中央管理器汇总这些作业可能需要一会儿的时间。结果是，在短时间内作业状态查询可能会不正确。
定义备用中央管理器时，您应该在配置文件中设置下面的关键字：
CENTRAL_MANAGER_HEARTBEAT_INTERVAL = |
在下面的示例中，备用中央管理器将等待两个时间间隔，其中每个时间间隔为 30 秒：
CENTRAL_MANAGER_HEARTBEAT_INTERVAL = 30
CENTRAL_MANAGER_TIMEOUT = 2
|
|
|
测试中央管理器机器的失效切换
可以通过在 ha4 机器上杀死名为 Loadl_negotiator 的中央管理器进程来测试失效切换。为了防止中央管理器后台进程在同一台机器被重新启动，您应该将 RESTARTS_PER_HOUR 设置为 0。这样，在大约一分钟之内，将在备用节点 ha5 上启动中央管理器。
|
|
为执行 LoadLeveler 的机器设置高可用性
此设置类似于为调度机器设置高可用性。
|
|
结束语
在本文中，您已经了解了如何使用 LoadLeveler 内在的能力实现 LoadLeveler 集群的高可用性，以及如何使用开放源代码软件进一步提高可用性。本系统的第 4 部分将讨论 IBM WebSphere® Application Server 高可用性的实现。
|
|
致谢
感谢 Waiman Chan 对 IBM LoadLeveler 高可用性实现的审查，感谢 Liana L. Fong 所提供的关于 IBM LoadLeveler 的技术指导。
|
|
下载
| 描述 | 名字 | 大小 | 下载方法 |
|---|---|---|---|
| 本系列文章的示例代码包 | hahbcode.tar.gz | 25 KB | HTTP |
|
||||
 |
关于下载方法的信息 | |
||
参考资料
- 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
- 阅读本系列的其他文章：
- “Linux 上的高可用中间件，第 1 部分：Heartbeat 与 Apache Web 服务器”
- “Linux 上的高可用中间件，第 2 部分：IBM WebSphere MQ”
- 要获得关于安装和运行 IBM LoadLeveler 的详细资料，请阅读 LoadLeveler 文档。您尤其应该去阅读以下内容：
- “LoadLeveler for AIX 5L and Linux: Installation Memo”（GI11-2819-02）
- “LoadLeveler for AIX 5L and Linux: Diagnosis and Messages Guide”（GA22-7882-02）
- “LoadLeveler for AIX 5L and Linux: Using and Administering”（SA22-7881-02）
- 阅读 IBM Software Announcement，获得关于 订购 IBM LoadLeveler 的信息。
- 访问 High-Availability Linux 项目 Web 站点，获得关于 heartbeat 的更多资料，其中包括 Heartbeat 成功故事。
- 在下面这些地方您可以下载到本系列文章所需要的大部分软件（注意，并不是所有下载都是免费的）：
- Red Hat Enterprise Linux 3.0 (2.4.21-15.EL)
- Heartbeat 1.2.3
- IBM Java™ 2 SDK 1.4.2
- IBM WebSphere® MQ for Linux 5.3.0.2 with Fix Pack 7
- IBM WebSphere Base Edition 5.1.1 for Linux with Cumulative Fix 1
- IBM DB2® Universal Database™ Enterprise Server Edition V8.1 for Linux
- AndrÉ BonhÔte 在“Inner Pulse” （PDF 格式）一文中介绍了如何构建 HA NFS 服务器，此文发表在欧洲刊物 Linux Magazine 2003 年 8 月那一期。
- 要使用 HACMP 实现 LoadLeveler 高可用性，请查阅 IBM 红皮书 “Implementing High Availability on RISC/6000 SP”。
- 通过“ DB2 UDB 的高可用性和灾难恢复概述” （developerWorks，2003 年 4 月）一文，了解 DB2 Universal Database 中提供高可用能力的特性。
- 要获得关于可用性以及如何在企业中间件环境中规划和维护它的详细讨论，请阅读 “企业中的可用性规划 ”（developerWorks，2003 年 12 月）。
- 通过 “创建 WebSphere Application Server V5 群集”（developerWorks，2004 年 1 月）一文，深入了解对 Linux on POWER 负载均衡和失效切换的支持。
- 在 developerWorks Linux 专区 可以找到更多为 Linux 开发者准备的参考资料。
- 通过参与 developerWorks blogs 加入到 developerWorks 社区。
- 购买 Developer Bookstore Linux 区 打折出售的 Linux 书籍。
- 订购免费的 SEK for Linux，在这套 DVD 一共两张，包含有来自 DB2®、Lotus®、Rational®、 Tivoli® 和 WebSphere® 的最新的用于 Linux 的 IBM 试用软件。
- 使用可以直接从 developerWorks 下载的 IBM 试用软件 来改革您的下一个 Linux 开发项目。
关于作者
|
||
|
|
|
Hidayatullah H. Shaikh 是IBM T.J. Watson Research Center 的 On Demand Architecture and Development Team 的一名高级软件工程师。他所感兴趣和专长的领域包括业务流程建模和集成、面向服务的体系结构、网格计算、电子商务、企业 Java、数据库管理系统和高可用集群。您可以通过 [email protected] 与 Hidayatullah 联系。 |