级别： 初级 David Kra (dakra@us.ibm.com), 执行 IT 架构师
2004 年 6 月 01 日 本文继续这个系列的主题，接着介绍启用网格应用的六种策略。文中展示了如何用六种策略的前两种启用网格应用，让应用程序作为具有一个或者多个实例、且与位置无关的批处理任务运行。本文解释了使用这些策略的应用程序所具有的特征，并详细说明了应用程序的开发人员在实现这些策略时必须、应该以及可以选择完成的任务。采用策略 1 和策略 2 时的一个主要目标就是让应用程序针对不同的中间件产品保持足够的灵活性。
简介
本系列的
第 1 部分概要介绍了这六种策略，并总结了每一种策略的特征和好处。
本文是这个系列的第 2 部分，展示如何利用策略 1：简单批处理和策略 2：独立并发批处理来启用网格应用。采用第一种策略，应用程序可以作为一个单独的作业，在众多网格计算机中的任意一台上运行。采用第二种策略，应用程序的多个独立实例可以并发运行。
第 3 部分描述了启用网格应用的六种策略中的第三和第四种，概述了如何将批处理程序的任务进行划分，以及程序如何成为可供客户机通过网格中间件来调用的服务子例程。
让我们先简要地复习一下。图 1 展示了前两种策略与后面几种之间的关系。
图 1. 六种启用网格的策略
策略 1：简单批处理具有以下的特征：
- 位置独立性，一项作业只有一个实例，可在多个节点中的任何一个上运行。
- LAN 和 WAN 上的 I/O 容量、定时功能和性能都是可接受的。
- 准备工作不太繁重。
- 软件许可工作不太繁重。
- 足够的安全管理级别。
- 启动时间令人满意。
- 任务调度由日程表、前提任务，或文件是否到达来决定
图 2 展示了批处理任务的一个实例在网格中的某个节点上运行的情况。
图 2. 策略 1：简单批处理
策略 2：独立并发批处理主要具有下面这些特征：
- 多个实例可独立运行，不会相互干扰。
- 独立任务是公用的。比如说，Account A 的 Job X 可以与 Account B 的 Job X 并发运行。
- 数据库或其他资源不会成为瓶颈，也不会发生死锁。
通过对案例的研究，对策略 1：简单批处理的讨论将向您展示在实现软件许可证、安全性、节点亲和性（affinity）、作业管理、多站点管理、可选的任务改变以及中间件方面需要做的工作。
策略 1：简单批处理
策略 1: 简单批处理的案例研究
对于这种策略而言，最基本的案例是这样一个应用程序：它具有一些命令行参数，并且根据命令行参数的定义使用一些文件和数据库。这个应用程序也可能是具有软件许可证的。
我们的目标是在众多网格节点中几乎任何一个上运行该应用程序的
一个实例。下一次运行的时候，中间件可能会选择其他的节点来运行。唯一的并发情形在于所选中的节点以及其他节点都在并发地运行其他应用程序。
许可证
我们必须正当使用应用程序。如果应用程序具有许可证，或者使用具有许可证的库或中间件，那么许可证的条款及其要求的条件就必须得到满足。除非您希望在网格中的每个节点上都安装软件的许可证，否则，应用程序就不能使用绑定在节点上的许可证。在这种启用网格的策略中，您至少应该采用“同一时刻有任一节点可以运行”的许可证模型。
Open Group X-Open Software License Use Management（XSLM） Standard Licensing 定义的五种模型 ( 相关链接请参阅
参考资料 ) 包括：
-
基本：基于企业或站点的许可证。
-
指定：基于注册用户或指定机器的许可证（也称为节点锁定的许可证）。
-
并发：并发使用的用户限制在一定数量的许可证。
-
累积或
消耗：基于使用的情况（如任务运行或执行的小时数）建立的许可证。实现这种许可证的基础可以是预先设置的限制，或实际使用的审计日志。
-
容量：限制只能在低于某个特定计算能力的计算机上使用的许可证。
您可以用几种方式处理许可证的管理问题：
- 使用契约，而不是技术的手段，让用户承担起遵守许可证条款的责任。
- 采用审计跟踪的方法，同时让应用程序或作业管理软件维护使用日志。
- 在网格中间件中强制使用许可控制服务，如 Platform Computing 的 Global License Broker。
- 应用程序强制使用许可证控制软件，如 Isogon 的 LicensePower/iFOR、Macrovision 的 FLEXnet、IBM 的 License Usage Manager（请参阅
参考资料）。
-
自己实现许可控制（不推荐这种做法）。请不要自己编写许可证控制的代码。应该充分利用市场上已有的许可证管理方案。
安全性
必须充分满足安全性的要求。理想的情况下，您应该在应用程序之外提供安全机制。应该由环境来负责决定谁可以运行您的应用程序。未经授权的用户 ID 必须禁止启动应用程序。
如果您的应用程序创建了一些含有机密数据的中间文件，而当应用程序运行失败的时候，这些文件也许不会被删除，那么您应该至少在操作说明书中将这种潜在的问题记录下来。
节点亲和性
您不能假设应用程序上一次和下一次执行都是在同一个节点上。您应该在文档中详细记录需要使用哪些文件、创建了哪些文件以及修改了哪些文件。这份文档让部署应用程序的人能够计划出必要的资源供应，同时也可以考虑采用缓冲技术，如 IBM 的 SAN File System，以及 Avaki 的 Data Grid（相关链接请参阅
参考资料）。
作业管理
您应该假定您的应用程序将通过作业管理系统来运行，而不是由一个人从命令行或菜单系统中启动。因此应该将标准输入/输出，如
stdin 、
stdout 以及
stderr 重定向到文件中。
单站点 -- LAN 流量
如果您的应用程序要在某个连接良好的站点上的一个或多个节点上运行，并且只使用站点内部的资源，那么您应该考虑局域网中的流量。这部分流量来自于执行之前在节点上准备好应用程序和所需的文件，以及执行之后将本地生成的结果移动到其他地方。如果使用到节点外的数据库、消息、事务系统等等，也会产生额外的流量。您还应该考虑同一个节点或其他节点上的应用程序也会使用到 LAN。
多站点 -- WAN 流量
如果您的应用程序要在不止一个站点上的多个节点上运行，您应该考虑涉及广域网的流量。如果文件不缓冲在每一个站点上，就要在准备过程提供这些文件。当应用程序结束之后，执行结果必须发送回最终的目的地。若是要通过 NFS 或其他技术远程访问未经缓冲的数据，那么只有当其访问的次数和传输数据的数量不会极大增加应用程序的执行时间，这才行得通。比如说，当大多数执行中只需要一个大文件中的一小部分内容，那么就不必拷贝或缓冲整个文件。对于跨站点的数据库访问而言也是如此。
多站点 -- 数据库的使用
除了 WAN 的流量之外，如果应用程序访问一个或多个远程站点上的数据库或其他事务性资源，那么还需要考虑额外的问题。当数据库管理系统（DBMS）有多个客户机时，使持有锁的时间最小化通常是很重要的问题。如果要使锁的持有期更低，安全性控制的更好，那么数据的所有者可能就会让应用程序在存储过程中对数据进行更新，而不是在客户机的应用程序中进行。如果数据是从多个站点联接得来的，那么可以采用联邦数据库技术，如 DB2
®Information Integrator（请参阅
参考资料），来帮助降低 WAN 的流量和客户端的代码量。
其他可选变动
在策略 1 中还有一些其他的改变措施，虽然不是强制性的，但是会带来好处：
- 您可以选择是否对应用程序参数可以控制的内容进行扩展，如可利用的最大内存或处理器数量。
- 您也可选择是否允许取消应用程序，并在不引起问题的前提下，稍后或在其他机器再次运行。
- 您可以选择非经常性地进行检查点操作，这样当应用程序中断之后重新运行时，就不需要再次执行所有的操作。您可以提供检查点和用于重新启动的参数，这样用户可以指定多久写一次检查点记录，比如说每
n个输入记录、每
m 分钟等等。如果缺少检查点记录，应用程序就只能从头开始重新执行。
-
您总是应该提供反映资源消耗情况的信息，如从启动以来或每个工作单元花费的内存、I/O 模式、时钟或 CPU 资源，以便在部署规划期间使用。您应该用文档齐全的工业标准方式将这些要求表达出来，这样负责部署应用程序的人就很容易理解。“Globus Resource Specification Language”（RSL）中的预定义属性，或“RSL Schema Documentation”（请参阅
参考资料）中的其他元素是很好的起点，也提供了很好的命名规范，这些与您使用的具体中间件环境无关。有些网格中间件产品内部并没有使用 RSL，而是提供了将 RSL 映射为其属性格式的工具。
保持对特定网格中间件的独立性
大多数已有的业务应用程序并不存在压倒性的测试网格环境的需求。通常让网格中间件来测试应用程序就足够了。如果您的业务应用程序需要确切地了解网格中间件，本系列的下一篇文章将详细讨论这个话题。
策略 1：简单批处理总结
为了在后端应用程序代码中启用网格功能，您至少必须做的工作是什么？
-
许可证：通常这方面不需要做什么事。最坏情况下，将许可证锁定在节点上，或分发到每一台机器上，这种方案毫无疑问会因为其高昂的费用而被一些企业否定。如果将许可证安装在一部分网格节点上，那么许可证就定义为 RSL 中的一项资源。在这种方式下，您的应用程序只能传递到具有那项资源的节点上。
- 安全性：通常不需要做什么事情。环境会控制谁可以运行应用程序和访问相应的内容。清除机密工作文件的工作应该由运行应用程序的 shell 脚本来完成。
- 节点亲和性：不需要。运作部门会负责将正确的文件放在正确的地方供后续运行时使用。
- 作业管理：不需要。
- 单站点 LAN 流量：不需要。
- 多站点 WAN 流量：不需要。
- 其他选项：不需要。
- 对特定中间件的了解：不需要。要避免这样做。这是部署人员或集成人员的任务。
策略 2：独立并发批处理
第二种策略是对第一种的扩展。对于策略 2：独立并发批处理而言，相同的作业，比如 Analysis-A，可以多次独立地并发运行。比如说，John 可以通过 Analysis-A 运行他的数据，而 Janme 也可以通过 Analysis-A 的另一个实例运行她的数据。这种策略与第一种没有重大的区别，但是的确考虑到了一些额外的情况。
图 3 展示的是多个独立实例并发运行而不相互干扰的情况。
图 3. 策略 2：独立并发批处理
许可证
如果应用程序获得了许可证，那么许可模型及其技术就必须允许进行这种并发操作。除了前面所说的启用策略 1 时需要考虑的技术之外，还可以考虑提供基于并发的软件许可。并发的项目可包括机器、处理器或实例。
互不干扰
现在，多个实例可以并发运行，所以很重要的一点就是这些实例之间不能相互干扰。您必须允许出现第一个启动的实例不是第一个结束的情况。您必须不能让一次运行的输出或更新覆盖另一次的。同时，在使用事务性资源时不要创建死锁模式。
访问热点问题似乎没那么明显。在数据库设计中，如果应用程序实例经常更新同一条记录，那么就会出现问题。您应该对应用程序进行修改，让其符合下面几种情况之一：
- 每个实例更新不同的记录。
- 实例不会经常更新共享的记录，也不会长期持有锁。
如果并发实例共享下列资源，请仔细地考虑应用程序的正确性和可重启性：
- 增量资源分配器（如序列号）
- 随机数生成器
- 种子分配器
策略 2：独立并发批处理总结
为了在后端应用程序代码中启用网格功能，您至少必须做的工作是什么？
- 许可证：不需要。最坏情况下，要求许可证锁定在节点上或分发到每台机器上。
- 互不干扰：保证在同一台或者不同的机器上同时运行多个应用程序的拷贝。
下一篇文章内容简介
“
启用网格应用的六种策略：第 3 部分：策略 3：并行批处理和策略 4：服务” 向您展示了应用程序如何通过策略 3：并行批处理将一项作业的任务划分为多项作业并行运行，然后将处理结果收集到一个节点上。策略 4：服务也会向您展示如何超越批处理的范畴，采用面向服务的架构，实现客户机和服务器的松耦合。
参考资料
关于作者  | 
| | David Kra 是 IBM Grid Computing 机构的执行 IT 架构师。他在 IBM 度过的 27 年职业生涯中，一直在指导用户的分布式计算项目，从应用程序层到电缆连线，从需求到部署，他都可以提供建议。自从上世纪 70 年代以来，他提出了各种具有可扩展性、高容量、高可用性的通信解决方案，几乎涉及 IBM 的每一种平台，以及若干种非 IBM 的平台。他是 IBM Academy of Technology 的成员。 |
对本文的评价
| 
