级别： 初级 Bart Jacob (bjacob@us.ibm.com), ITSO 红皮书项目主管
2004 年 2 月 01 日 如果您知道您期望获得什么，那么为网格计算设计应用程序就简单多了。在本文中，您将学习到哪些设计元素适合用于网格应用程序，哪些则不适合。掌握了这些信息之后，您就可以将注意力集中在任务、数据、以及应用程序如果您知道您期望获得什么，那么为网格计算设计应用程序就简单多了。在本文中，您将学习到哪些设计元素适合用于网格应用程序，哪些则不适合。掌握了这些信息之后，您就可以将注意力集中在任务、数据、以及应用程序使用的环境上，从而使已有的和新开发的应用程序都能够适应网格的需要。您也应该作出计划，使用那些为网格应用程序所专门设计的开发环境和工具集，如 Globus Toolkit。
简介
一开始，让我们区分一下网格
应用程序和网格
服务。后者已经经历了若干年的开发，其中包括基于开放网格服务架构（Open Grid Services Architecture，OGSA）的一些有用功能。目前，开放网格服务基础设施（Open Grid Services Infrastructure，OGSI）提供了有关查询、监控、发现、制造、通知、安全、注册、管理、规划以及其他一些功能的规范，可以供所有的网格用户使用。网格应用程序可以使用这些经过注册的服务（其中包括网格基础设施）来完成特定的与工作相关的任务，从而解决业务和技术方面的问题。基本上说，网格应用程序是一组工作项（work item）或
作业（job），这些作业通过使用网格资源来完成一项复杂的计算任务。网格应用程序通常处于开发人员的控制之下，并保持其私密性。
由于一个网格可能会很大，很分散，并且是异类的，因此设计网格应用程序是一种挑战。非网格应用程序在相对稳定、定义良好并且通常是专用的环境中运行，而具有网格功能的应用程序的运行环境则是一种动态的、有时还是松散定义的并且强烈依赖于网络的环境。正如“
通过 Globus 启用应用程序的网格计算功能”这本红皮书中所阐述的，在设计或启用网格应用程序的时候，需要考虑的架构和环境方面的因素有 30 多个。在本文中，我将向您介绍这本红皮书，并概要叙述与作业、数据以及网格应用程序的环境有关的设计问题。
注意：本文并没有涉及网格基础设施自身，这方面在其他文章中有详细叙述。更详细的信息请参阅本文末尾的
参考资料。
设计问题简介
表 1中将 32 种设计因素分为三大领域，当您为网格计算修改或设计应用程序的时候要考虑这些问题。“
代号”一列用于帮助您找到本表格之下与之相关的讨论。下面首先简要描述一下三大需要考虑的领域：
- “
作业”领域内的要素与构成网格应用程序的工作单元（工作的最小单位）集合相关。其中也包括了作业流和应用程序流。
- “
数据”领域与网格应用程序中数据的输入、存储和输出有关，这一领域涉及数据管理方面的复杂问题。
- “
环境”领域与硬件、软件、网络以及与之类似的依赖关系，这些关系对在网格上运行的应用程序的适应性产生影响。
“
相对简单的方法”和“
相对复杂的方法”两栏中的内容可以帮助您在面对设计问题的时候对难易程度有个概念，但是您要记得，在这两类极端的方法之间还有很多中等程度的方法。在网格中使用越多“相对简单的方法”，那么应用程序运行成功的可能性就越大。如果您使用了很多“相对复杂的方法”，您也可能设计或修改出能在网格上运行的应用程序，特别是在这些因素对应用程序而言不是很重要时。
在“
是否重要”一栏中，如果您的网格应用程序对该因素的依赖性很强，那么就选择“
是”，反之选择“
否”。所选择的“否”越多，您对网格应用程序的设计或修改也就越容易。
表 1. 作业、数据和环境等设计因素
|
代号
|
作业
|
相对简单的方法
|
相对复杂的方法
|
是否重要
| | J1 | 作业流 | 并行流 | 网络流 | 是/否 | | J2 | 作业类型 | 批处理作业 | 复杂并行或 EJB 作业 | 是/否 | | J3 | 不同作业的数量 | 单一作业 | 大量作业 | 是/否 | | J4 | 子作业深度 | 无子作业 | 深度子作业 | 是/否 | | J5 | 冗余作业执行 | 不要求 | 强烈要求 | 是/否 | | J6 | 拾遗（Scavenging）网格 | 所有作业独立拾遗 | 作业不适合拾遗 | 是/否 | | J7 | 作业拓扑 | 简单作业拓扑 | 复杂作业拓扑 | 是/否 | |
代号
|
数据
|
相对简单的方法
|
相对复杂的方法
|
是否重要
| | D1 | 数据拓扑 | 简单数据拓扑 | 复杂数据拓扑 | 是/否 | | D2 | 数据类型：字符集 | 常用的 SBCS 或 Unicode | 网络上不一致的字符集 | 是/否 | | D3 | 数据类型：多媒体格式 | 统一使用一组多媒体格式 | 混合使用多种格式 | 是/否 | | D4 | 数据量 | 少量数据 | 由单个作业处理大量数据 | 是/否 | | D5 | 每项作业的数据可分离性 | 数据很容易分离 | 数据不能分离 | 是/否 | | D6 | 作业数据 I/O | 命令行参数 | 需要使用 API | 是/否 | | D7 | 共享的数据访问 | 只读的文件 | 可读写的 DBMS | 是/否 | | D8 | 临时数据空间 | 少量 | 要求具有无限康牧偈笨占? | 是/否 | | D9 | 时间敏感的数据 | 数据总是有效 | 数据的有效性取决于时间 | 是/否 | | D10 | 数据加密 | 统一使用已有的加密技术 | 使用网络上多种不同的加密技术 | 是/否 | |
代号
|
环境
|
相对简单的方法
|
相对复杂的方法
|
是否重要
| | E1 | 对 OS 的依赖性 | 独立 | 强烈依赖 | 是/否 | | E2 | 每项作业需要使用的存储空间 | 少量 | 大量 | 是/否 | | E3 | 需要使用的 DLL | 标准 DLL | 定制 DLL | 是/否 | | E4 | 编译器设置 | 不需要编译器 | 要求特殊的编译器设置 | 是/否 | | E5 | 运行时环境 | 不要求 | 要求特殊的运行时环境 | 是/否 | | E6 | 应用程序服务器 | 不要求 | EJB 或者其他特殊要求 | 是/否 | | E7 | 外部应用程序 | 不要求 | 要求进行特殊的设置或安装 | 是/否 | | E8 | 硬件依赖性 | 不要求 | 要求使用特殊的设备 | 是/否 | | E9 | 网络带宽 | 少量 | 要求使用广域网 | 是/否 | | E10 | 安全策略 | 所有用户都遵从相同的标准 | 互不匹配 | 是/否 | | E11 | 单用户界面 | 不要求 | 集成的通用用户界面 | 是/否 | | E12 | 时间约束 | 无时间限制 | 强烈要求在一定的时间内、一定的数据供应量下执行 | 是/否 | | E13 | 网络可扩展性 | 可扩展性图的上限很高 | 上限很低 | 是/否 | | E14 | 软件许可证 | 全部许可 | 全部受限 | 是/否 | | E15 | 付费服务 | 不要求 | 复杂的付费服务，有第三方参与 | 是/否 |
如果大多数设计时考虑的问题都落在“相对简单的方法”一栏中，那么您设计或修改的这个网格应用程序就能够适应网格的需要，至于重要性一栏选的是“是”还是“否”，就无关紧要了。然而，如果大量的设计问题都落在“相对复杂的方法”上，而且重要性为“是”，那么您在继续进行您所设想的这个应用程序之前就得多多考虑了。
设计问题的细节
下面简要解释了一下从 J1 到 E16 的每一个设计因素，在您设计或修改某个应用程序以用于网格上之前，必须要仔细考虑这些问题。有关这些问题更完整的解释可以从本文末尾列出的
参考资料中找到。
作业、作业流和应用程序流
首先，让我们把
作业定义为一个独立的工作单元，一个二进制可执行程序，或是一条命令，可以在网格中的一台计算机上运行。作业可以在它所运行的节点上启动一个或者多个进程。由于作业必须从发出请求的机器“流”到远程机器上，然后再流回来，因此我们必须对
作业流和
应用程序流进行区分。作业流是指在单个工作单元或作业内完成的内部工作流，而应用程序流是指构成整个应用程序的所有作业之间的工作流。在网格应用程序中可能出现三种类型的应用程序流：
- 并行流，其中很多或大多数作业是在同一时刻以肩并肩的方式运行的。
- 串行流，其中很多或大多数作业必须一个接一个运行，因为应用程序流中后面的作业不能在前面的作业结束之前开始。
- 网络流，其中有些作业以并行方式运行，有些以串行方式运行，一些或者全部的作业都通过一种复杂的方式交换数据。
J1：作业与应用程序流
使用并行流的应用程序最能利用网格计算的优势，如果操纵数据的方式也很直接，那就更好了。使用串行流的应用程序，尤其是具有复杂的数据接收与存储功能的，可能在网格上运行还不如在专用的本地环境中运行，因为这样的应用程序需要在启动进程之前等待前一个进程结束。应用程序还可能必须先将一组数据存储起来，然后另外一个进程才能检索这些数据。
J2：作业类型
作业类型从简单的、很少或没有数据交换的批处理作业，到使用 EJB 等其他技术的高度复杂的计算都有。后面这些类型也可能要求进行复杂的数据交换。作业类型越简单，越适合在网格中使用，不过如果您考虑到所有的需求，复杂作业类型也是可能实现的。
J3：作业数量
只要网格的规模足够大，可以容纳所有的作业，那么在考虑应用程序是否适合进行网格计算的时候，作业数量比作业类型的重要程度低。还有一个稍微次要一些的问题，就是当作业数量增加的时候，作业管理器的开销也随之增长。然而，大量并行作业比少量串行作业在网格中的运行情况要好得多。
J4：子作业
孤立地考虑子作业，似乎对网格应用程序不会造成什么困难。然而从进程间通信、数据交换、作业执行的阶段与规划以及作业的并发提交等方面看，子作业是非常不独立的。在这样的情况下，我们有必要将这样的不独立性最小化。另一方面需要考虑的问题是“嵌套”子作业。嵌套的层数越多，复杂程度越高，因此在网格中执行成功的可能性就越小。
J5：作业的执行
要求作业冗余执行可能会降低应用程序对网格的适用性，因为这样需要对作业的启动和数据的交换进行协调。即便是有大量可用的计算能力资源，等待时间及开销的增长也可能使系统变得效率低下。然而，如果您能够对作业、数据存储、数据检索等进行适当的规划，那么这种网格应用程序运行成功的几率也就能变得更高。
J6：拾遗网格中的作业
计算网格（致力于高性能数字处理）或数据网格（致力于让用户能够访问大量已经存储的数据）上的应用程序设计或修改起来比拾遗网格的应用程序更加容易。原因在于，拾遗网格是从桌面 PC 中获取计算周期，而资源的所有者仍然在本地，所以网格对资源的规划必须适应资源所有者的需要。因此，拾遗网格上的应用程序最好是在非高峰时段运行，并且最好尽量少受本地控制的干扰。同时，出于对本地安全性的要求，这样的应用程序可能无法使用某些资源。
J7：作业拓扑
应用程序对子作业层次关系的要求可能会降低它适应网格计算的程度。一种行之有效的方法是将作业的层次关系、通信与存储路径、进行复杂数据交换可能花费的等待时间等都详细地绘制出来。不管您采取何种措施，只要能降低层次，使通信和检索存储的依赖性最小，都会增大在网格上运行应用程序成功的可能性。
数据管理
有了网格计算的强大功能，应用程序所操纵的数据量的重要程度就比可用的计算时间、数据位置等的重要程度低得多。比如说，如果一组数据必须从网格的一端传输到另外一端，那么根据网络流量的不同，其中大量的等待时间中就具有可挖掘的潜力。
D1：数据拓扑
与作业拓扑相似，了解网格应用程序将要操作的数据类型及位置也是很重要的事情。您应该在数据拓扑图中将下列问题都绘制出来：
- 每一种类型的数据在服务器和存储系统中的位置，目的是使访问时间和数据进出运行特定作业的节点的时间最短。
- 每一种类型的数据的安全规划与需求，这样网格应用程序才能访问到数据，同时阻止非授权访问。
- 所使用的备份、归档、复制方案，以便网格应用程序检索到最新的数据拷贝。
- 有关数据的所有 I/O 情况，这样网格应用程序才能获得最高的性能。
D2 和 D3：字符集与多媒体格式
应用程序如果使用的是符合广泛应用规范的单字节字符集（SBCS）或 Unicode，那么它在网格中的工作情况就是最好的。如果网格中包含双字节字符集（DBCS）以及非标准字符集，那么应用程序就必须处理这些情况才能有效运行。同样，只访问少数几种标准多媒体文件格式的网格应用程序比必须访问很多种音频、视频及其他文件格式的程序复杂程度要低。
D4 和 D5：数据的数量与可分离程度
网格应用程序通常在数据的数量和作业的数量（J3）之间存在某种关系：一般来说，数据越多，应用程序中包含的作业数也应该越多。通常最好不要由一个作业处理大多数数据。同时，由于网格中提供了充足的计算能力，应用程序对网格计算的适应程度受应用程序中所使用数据数量的影响要小于受数据集大小或数据可分离程度的影响。将巨大的数据集移动到应用程序运行的位置通常并不可行，但是您也许能够复制或拷贝数据的一个子集。数据的粒度越小，对网格计算的适应程度越高。
D6：数据 I/O
网格应用程序中可能需要用若干种方法来检索和存储它所要求的数据。下面列出网格应用程序处理数据 I/O 的五种方法：
- 带有命令行接口的脚本，这种方法尤其适用于在一个脚本中请求的数据数量和类型相当少且统一的情况。
- 文件系统、数据库记录或诸如数据仓库之类的系统，只要网格应用程序具备相应的访问权限即可。
- 当网格应用程序能够处理所需的 API 时，可以使用消息队列。
- 用系统返回值指示 I/O 是否成功。网格应用程序依然必须自己到数据存储或消息队列中访问数据。
- 高级协议或 API，如 HTTP、HTML、XML、SOAP 等。然而，这些标准可以广泛使用，主要的问题变成网格应用程序必须处理的 I/O 次数。
D7：数据共享
在网格应用程序的两个或者多个作业之间共享同一个数据集，这种共享与其他任何地方的数据集共享问题都相似。下面是在规划数据共享的时候需要考虑的问题：
- 当网格应用程序需要访问数据库、文件系统或其他数据存储的时候，有什么样的读写限制？
- 是否必须对网格应用程序中的作业赋予任何附加的访问权限？
- 在共享的资源当中，网格应用程序如何确定它所需要的数据真的可用，并且就是它所期望的格式，也处于它所期望的服务级别？
- 什么地方可能出现数据访问冲突，网格应用程序该如何处理这些冲突？
- 如果网格应用程序需要访问的数据库记录被锁定，在此类情况下作业该如何应对？
- 当两个或者多个作业试图更新同一条记录的时候，网格应用程序该如何处理这样的冲突？
- 当作业中包含的业务事务需要执行提交或者回滚的时候会发生什么事情（目前在网格环境中还不存在处理跨系统事务的标准）？
D8：临时数据存储
尽管有些网格应用程序可能需要很少的临时空间进行数据存储，但是您还是需要对网格应用程序可能会用到的存储空间规模进行规划。下面是一些需要考虑的问题：
- 除了数量充足的临时数据存储空间之外，该网格应用程序是否用到了任何由网格服务器或门户服务器管理的缓存？如果用到了，这个网格应用程序必须能正确地处理这些缓存。
- 对网络上所使用的操作系统是否有特定的要求？因为数据管理方案随着操作系统的不同而不同，所以网格应用程序需要知道本地的、跨系统的、网络的以及平台上的有关数据格式、访问和安全性的规则。
- 是否依赖本地或共享的文件系统？如果是，您需要计划出一种方式，以保证运行时的访问是最优的。
- 临时数据存储需要占用多少存储空间？请力图避免不必要的数据交换，并保证您能够明确网格环境中可执行程序和操作系统的任何特定要求。
D9：数据时效
如果网格应用程序可能碰到具有有限生命期的对时间敏感的数据，那么相关的作业必须在这项数据还存在的时候访问它。该网格应用程序还必须能够处理网格中所使用的各种不同的数据缓存和复制方案，这样才能保证作业只使用到正确的数据。
D10：数据加密
网格应用程序需要处理所有的认证、访问控制、数据一致性、数据保密性、公钥私钥管理等方面的需求。Globus Toolkit 提供了一个认证中心（Certificate Authority，CA），用于为网格中的每一个成员创立身份标识。公钥基础设施（Public Key Infrastructure，PKI）以及网格安全基础设施（Grid Security Infrastructure，GSI）能提供相应帮助。此外，网格应用程序必须处理对称及非对称的加密方案。有关加密和安全性的更多信息，请参阅本文末尾的
参考资料。
环境因素
本文是一篇简要的介绍，我仅仅涉及了网格应用程序必须处理的网格环境中的一些重要方面。您从
参考资料中可以看到更完整的书籍和文章列表。不过一般来说，应用程序开发的最佳策略是坚持遵循 OGSA 和 OGSI，这样当这些标准普遍推广开来的时候，如果网格环境发生变化，对您的网格应用程序的影响就会最少。
E1：操作系统
由于很多网格运行于多种操作系统，所以网格应用程序必须要么运行在一个单独的 OS 上，要么知道如何处理下面这些 OS 特性：
- 版本。
- 服务级别。
- 所需的任何参数设置。
- 所需的任何辅助应用程序，如注册表。
- 任何附加的 OS 要求。
E2：作业占用的内存
如果指定运行某项作业的某个节点不具备该作业所需的足够内存，那么内存容量的问题就变得相当重要了。网格应用程序可以在运行的时候请求额外的内存，但是 OS 必须有赋予其内存的能力。
E3：DLL
如果某项作业需要使用特定的 DLL，那么这些 DLL 必须要么就位于运行该作业的这个节点上，要么至少应该从别的地方临时移动到执行节点上。更进一步玻珼LL 之间的链接一定不能因为这种临时的存储位置而断裂。同时，一定要保证您所期望的那个级别和版本的 DLL 是可用的。
E4：编译器
作业中使用的一些已编译的模块可能对它们所运行的环境非常敏感。根据目标环境的不同，编译器标记需要经过恰当的设置，运行作业的系统中也要具备正确的运行库。在某些情况下，资源的类型多种多样，因此很有必要在运行该作业的第一步先在目标系统中编译这些模块。这条经验能够保证可执行模块与目标系统的架构兼容。
E5：运行环境
在网格应用程序发起它的第一项作业之前，它所要求的运行时环境必须准备就绪。其中可能包括适当的 JDK 版本，适当的解释级别，以及执行作业所需的任何文件。同质的运行时环境最适合网格应用程序使用，但是如果您计划使用异质系统，也是可以的。
E6：应用程序服务器
如果网格应用程序需要访问某个应用程序服务器，就必须知道或者有能力发现：服务器的版本号、使用的标准、容量、所提供的服务以及任何特殊的访问需求。为了使潜在的网络传输问题减到最少，花点力气找到一个与应用程序服务器临近的节点是值得的。
E7：外部应用程序
如果网格应用程序依赖于任何外部程序，如编译器、数据库、目录、注册表，等等，那么这些东西必须在第一个作业启动之前就准备就绪。如果这些应用程序模块需要移动到目标系统中，那么很多与数据管理有关的设计问题也都需要考虑，如模块的大小和网络带宽等。
E8：硬件
如果网格应用程序依赖于任何不寻常的外围设备、存储系统、测量设备，等等，那么在网格应用程序运行的时候，这些设备必须就绪。您也应该知道网格上的硬件备份和容错系统，以及任何可能在将来对网格应用程序产生影响的硬件升级计划。
E9：网络带宽
因为带宽永远都不是无限的，因此只要经过适当的计划，并使用成熟的压缩与解压缩技术，网格应用程序甚至可以在非常拥挤的环境中运行。然而，如果需要经常在网格中传输大的数据集，应用程序就可能用去它能够使用的所有带宽。高速广域网也许能为网格应用程序提供最优的性能。
E10：安全策略
如果整个网格在授权、认证、数据保密、访问控制、数据加密、密钥管理、用户登录等相关问题上使用相同的标准和策略，那么这样的网格应用程序要做的事情就比较少。不过通常来说，网格中可能包含多种不同的标准和策略。Globus 中的网格安全基础设施（Globus grid Security Infrastructure，GSI）为我们提供了网格级别的指导，但是您还必须知道所有使用的本地安全标准及策略，然后才能将特定的一组机器变成某个网格的组成部分。
E11：单用户界面
单一的用户界面，或者说单点登录，可以提供在整个系统中映射用户 ID 的技术。然而，网格应用程序还必须知道多个用户是否能映射到同一个用户 ID 上，是否需要通过审计来确定发起该应用程序的用户的身份，以及网格中是否使用了不同的 ID 映射方案。
E12：时间约束
网格环境中的时间约束问题与数据管理（D9）中的时间敏感性问题十分相似，但是也要求网格应用程序知道诸如规划好的维护例程、数据库备份活动、高峰期和非高峰期可用性之间的差异，以及其他类似的资源管理问题。
E13：网络可扩展性
在设计或修改网格应用程序之前，您不仅应该预见到网格应用程序本身的可扩展性要求（即它会需要多少以及何种类型的节点），而且要预测网络的可扩展性（即是否可以动态分配额外的节点）。为使网络通信和网络延迟降到最低，付出一点努力是值得的。
E14：软件许可证
如果网格应用程序要求在某个特定节点上访问具有许可证的软件，您应该确定这个节点上的软件许可证数量是否能满足网格应用程序发出的请求。有些许可证有特定的使用个数限制，将忽略超出的用户请求。还有一些许可证并不禁止用户访问，但是却因此认为用户违反了许可证协议，这怎么都不是件好事。为了避免在将来出现问题，您在使用之前就应该预测网格应用程序所需的许可证数量。
E15：付费服务
软件付费服务与许可证相似，只要有可能，您就应该预测网格应用程序对付费服务的需求，可以按每一次使用付费，也可以是不限次使用的统一价格。支付系统可能非常复杂，所以网格应用程序中只能使用那些得到广泛支持的标准。同时，支付系统越少越好。
结束语
很多类型的应用程序都可以设计或修改成适合网格计算。前面的讨论指出，与作业、数据和环境有关的很多设计因素都可以应用到网格应用程序中去，如果您能跟上工具集和开发环境的最新进展就更好了，Globus Toolkit 中就提供了相关的功能。
不论您多么有经验，多么细心，如果您规划的网格应用程序严重依赖于下面这些原则，那么这个程序运行成功的可能性就很低，甚至有时根本不能成功：
- 作业之间使用了大量的进程间通信。
- 本地作业的调度很严格，且数据的产生是不受控制的。
- 网络带宽不足。
- 存在尚未解决的环境和运行时问题。
- 业务依赖于提交-回滚过程，而网格计算上的相关标准正在制定中。
- 作业流要求作业之间相互依赖，尤其是在进行数据操纵的时候。
- 防火墙和其他访问规则可能不允许在网格应用程序中使用它们不支持的网络协议。
随着网格计算的持续发展，很多类似的潜在问题对网格应用程序开发人员来说都会变得没那么严重了。
参考资料
关于作者  | | | Bart Jacob 是位于德克萨斯州奥斯汀的 IBM 国际技术支持组织中心（International Technical Support Organization Center）的高级 IT 咨询专家。在为 IBM 的各种产品和技术（包括通信、面向对象的软件开发以及系统管理和新兴技术）提供技术支持方面，他有 23 年的经验。他在 ITSO 工作已有 10 余年，在那里他曾编写了一些 IBM 红皮书，并就各方面的主题，在全球范围内开办了一些讲习班，向这些讲习班学员讲授知识。他拥有美国雪城大学（Syracuse University）的数字分析硕士学位。 |
对本文的评价
| 
