级别： 中级 James W. Penney (penney@us.ibm.com), Portfolio 首席工程师, IBM
Mahi R. Inampudi (inampudi@us.ibm.com), IT 架构师, IBM
Moon J. Kim (moonkim@us.ibm.com), 首席架构师，Strategic System Initiatives, IBM
2005 年 11 月 07 日 IBM 的应用程序开发人员需要采用一种方法来构建启用网格的应用程序，而不用真正使用网格系统。解决方案是构建一个网格框架，称为 IBM Global Account（IGA）网格体系架构。作者在本文中将介绍这种网格框架的体系架构和组件，以及这种框架的部署模型。
我们为什么要构建一个网格体系架构供应用程序开发人员使用？
在本文中，我们从技术方面对一个用来帮助 IBM 内部开发人员开发网格应用程序的工具进行介绍：这个工具是 IBM Global Account（IGA）网格体系架构。IGA 网格体系架构的目标是，让我们的网格开发人员能够为网格框架设计应用程序，并且在开发阶段就可以体验网格计算设计的强大功能，而且开发时不需要复杂的网格系统。
IGA 网格解决了使用目前可用技术的宿主环境对于网格解决方案的需要。这种体系架构在整个公司部署到世界各地的各个大型机基础上创建了一个网格基础设施，从而充分利用这些服务器的空闲服务周期合并成一个功能强大的网格系统，由此来减少用户的总体拥有成本（TCO）。这种体系架构可以与大部分可用的网格框架一起使用。应用程序可以使用一个开关来关闭网格控制器的远程调用，并使用 LocalGridFacade。在本文中，我们将讨论这种系统的基本需求，并对这个系统从组件和架构方面进行详细的介绍。
我们将介绍 IGA 网格框架的体系架构，并介绍它的部署模型。如果您正在考虑为自己的开发团队构建一个网格框架环境，那么您就会发现这种模型非常有用。
首先，让我们记住网格都提供了哪些优点。
网格的目标
网格计算让我们可以更好地利用服务器池。在最简单的情况中，它将服务器资源、存储系统和网络放入一个单独的大型系统，同时提供了更好的吞吐量，效果比用于特定目的的单用户点所能达到的吞吐量更好。
网格的主要目标是对资源进行虚拟化来解决问题。网格计算让我们可以访问的主要资源有：
- 计算和处理能力。
- 数据存储和网络文件系统。
- 通信和带宽。
- 应用程序软件。
图 1 详细介绍了传统的网格体系架构。
图 1. 传统的网格体系架构
现在，有很多应用程序框架（我们在 IBM 内部已经构建了几种框架），它们可以让应用程序充分利用网格技术。大部分网格模型的体系架构都非常相似：为了实现更好的吞吐量，大部分模型都可以根据需要为任务添加网格节点（服务器资源）。
由于不能充分得到利用，有大量的计算能力都被浪费了。通常，规划和设计计算能力需求的工作都是根据峰值需求进行的，从统计结果来看，实际的利用率不过是 60% 左右。利用这些尚未使用的计算能力 —— 这是 IGA 的另外一个目标 —— 就可以为那些已经购买了大量大型服务器的组织带来经济上的回报。
IGA 网格体系架构
目前我们使用的 IGA 网格体系架构是使用 Globus Toolkit 3.0（GT3）来构建的。很快我们就会使用 GT4 开发一个版本。
在 GT3 环境中，网格任务之间的隔离性基于平台操作系统所使用的隔离机制。通常，网格任务都是作为操作系统中一些单独的进程运行的，因此会由操作系统来控制资源的共享。这种情况可能会导致有意无意地向其他任务暴露本任务所使用的数据，或被其他任务破坏数据。
IGA 网格在网格作业之间提供了更好的隔离性，它增强了网格环境中的私密性和安全性。在 IGA 的设计中，我们将 GT3 的隔离性机制替换成另外一个模型。我们没有在相同的 Linux® 实例中运行多个 User Hosting Environment（UHE）实例，而是每个 UHE 实例都在一个单独的 Linux 实例上运行。因此，属于不同用户的作业就永远不会共享任何资源。
图 2 是分布在世界各地的数据中心的拓扑图。
图 2. IGA 网格体系架构
 |
GT3 中的 UHE
GT3 Globus Resource Allocation Manager（GRAM）由两个服务容器组成：User Hosting Environment（UHE）和 Master Hosting Environment（MHE）。UHE 通知客户机提交作业的状态，并使用 FSS 来将作业的输出结果（例如 stdout 和 stderr）重定向到客户机。这种体系架构防止了出现以 root 用户身份运行进程的问题，它使用一个 setuid 程序来启动用户帐号中预先配置好的 UHE。
|
|
网格用户与系统之间通过一个网格管理中心进行交互。网格管理服务包括一个作业管理服务，以及通用的管理和用户管理服务。每个数据中心都包括一个或多个 zSeries® 或 S/390® 节点。AIX® 节点也可以连接到这个基础设施上。给定数据中心的节点可以是异构节点。在图 2 中，每个数据中心都有一组不同的机器组合。
大型机节点可以通过逻辑分区进行分区（每个逻辑分区称为一个 LPAR）。每个 LPAR 的功能都类似于一个单独的操作系统，具有自己的宿主操作系统，具有一个或多个应用程序。通常，有一个或多个 LPAR 可以专门用于数据中心的应用程序。
然而，我们可以利用空闲的机器周期为网格基础设施创建一个特殊的分区。这个分区我们称之为 Grid LPAR，它与其他分区共享虚拟处理器，不过其优先级低于其他 LPAR，这样可以确保网格使用节点不会影响到大型机上的正常操作。它只使用了大型机上过剩的计算能力。
两个框架编程模型
如图 1 所示，传统的网格架构遵循以下设计：
- 应用程序客户机使用网格 API 调用一个作业，网格控制器在网格服务器上对这个作业进行调度。
- 网格控制器将这个任务划分成子任务，并将其分配到网格中的多个网格节点上。
- 网格控制器所调用的网格节点的个数本质上是动态的。
- 每个网格节点产生的结果可以由结果搜集器进行搜集。
- 结果搜集器返回网格控制器所调用的作业的结果。
- 网格搜集器将结果返回给应用程序客户机。
图 3 给出了 intraGrid 的体系架构，这是 IBM 内部使用的另外一个网格框架。intraGrid 可以支持网格应用程序，其中应用程序客户机使用 intraGrid API 来调度作业，网格控制器调用子任务在多个网格节点上运行，这样作业就能使用更高的吞吐量来完成了。
图 3. intraGrid 编程模型
现在让我们来看一下 IGA 设计的主要组件：LocalGridFacade。
LocalGridFacade 模型
LocalGridFacade 提供了一个简单版本的网格框架来提高一台服务器上的资源利用率。开发人员可以使用这种框架在本地开发环境中构建适用于任何网格框架的应用程序。图 4 阐述了这种设计。
图 4. LocalGridFacade 设计
计算网格是用于大型任务的，这些任务可以划分成子任务，并可以在多个分布式服务器上并行运行。尽管实现高吞吐量是我们的目标，但是对于这种应用程序来说，性能定义与 Web 事务应用程序的性能定义有着很大的区别：
-
更好的吞吐量 —— 使用
LocalGridFacade 开发的应用程序能够得到更好的吞吐量。注意本地网格节点的数目越多，吞吐量也就越好。LocalGridFacade 提供了一种机会来提高本地服务器上的资源利用率。
-
开发框架 —— 并不是每个应用程序都适合于网格系统。在为网格框架构建应用程序时，开发人员需要处理复杂的系统体系架构，并理解这个框架与系统交互的方式。
LocalGridFacade 可以简化这个过程。应用程序开发人员可以使用它来构建应用程序：通过将任务划分成多个并行的 工作单元 并在本地测试其实现。这样就可以在本地开发环境中体验网格框架的功能，而不需要真正的网格框架。
-
简化部署 —— 由于
LocalGridFacade 早已经将作业划分成了子作业，因此很容易理解部署结构。
下面让我们来快速了解一下其中的部分组件。
网格控制器
网格控制器 是 LocalGridFacade 的客户机界面部分。根据在属性文件中所指定的参数，网格控制器可以确定是使用 LocalGridFacade，还是调用远程的网格框架。当网格控制器被配置为使用本地网格时，会调用指定数目的本地网格节点并将子作业分配给这些网格节点。
网格节点
计算网格和数据网格都涉及称为 网格节点 的异构的相似小组件或服务器。
结果搜集器
计算网格和数据网格中所有的活动网格节点组件都与一个 结果搜集器 进行通信，从而提交所处理的子作业或子任务的结果。结果搜集器会汇集所有活动网格节点的结果，对这些结果进行整理，并在所调度的任务完成之后将结果返回给网格控制器。网格控制器然后将这个结果返回给应用程序客户机。
应用程序客户机
应用程序客户机 使用网格 API 将作业提交给网格控制器进行调度。通常，网格控制器提供了通知功能，这样网格控制器就可以在网格处理完之后立即通知应用程序。
部署模型
图 5 给出了 LocalGridFacade 型系统典型的部署模型。
图 5. 部署模型
从部署模型的观点来看，网格应用程序的流程与任何应用程序的开发都非常类似。项目执行人提供了业务需求。IT 架构师负责对这些需求进行分析，并评价在应用程序体系架构中使用网格计算的业务优点，并确定对于网格组件的需求。架构师决定要用来构建网格应用程序所需要的工具和产品，并确定吞吐量是否是整个体系架构中最为关键的因素。然后，开发人员可以使用 LocalGridFacade 来创建应用程序，并使用一种集成开发环境（例如 WebSphere® Studio Application Developer 或 Rational® Application Developer）来开发应用程序，而不需要了解或处理网格体系架构的复杂性。开发完成之后，构建师和网格管理员就可以对这个应用程序进行配置，将其部署到网格计算体系架构中。
图 6 从技术角度给出了整个系统的模型。
图 6. 部署模型
从技术设计的观点来看，LocalGridFacade 的工作单元是在网格集群中的各个网格节点上执行的，全部工作单元当作是一个单元进行控制。intraGrid Management Service 对来自各个网格节点的结果进行汇总，并使用 Globus Tookit NotificationListener（在客户机上运行）将其传递给应用程序客户机。
在应用程序开发完成之后，LocalGridFacade 就仅仅是实际的应用程序与 IGA 网格框架之间的额外一层了。应用程序架构师要负责确定网格应用程序是否需要 localGrid 的组合来提高一个网格中资源的利用率，以及是否让网格门户来动态地控制所需要的网格节点数量。这种模型简化了将网格应用程序部署到 IGA 的过程。
结束语
在本文中，我们对 IGA 网格体系架构从技术方面进行了概要介绍；这是一种用来帮助应用程序开发人员构建网格应用程序的机制，在开发过程中并不需要真正使用网格系统。本文重点介绍了：
- 一般底层网格系统的复杂性（以及传统网格和 IGA 网格之间的区别）。
- IGA 系统的基本需求。
- 这种系统中的具体组件。
- 体系结构概述。
- 这种系统的简明部署模型。
参考资料 学习
获得产品和技术
作者简介 | 
| | James W. Penney 是一名 IBM 认证的执行 IT 架构师，负责开发各种在 IBM 内部提供支持的解决方案。他是几个 IBM 领域的首席工程师，包括 IBM Global Services、IBM Global Financing、HR 和 Finance。除了在应用程序中实现网格技术之外，他的兴趣还包括持续改进应用程序开发的方法，并应用一些灵活的编程方法。 |
| 
| | Mahi R. Inampudi 是一名 IT 架构师，从事 IBM 的 On Demand Workplace 专家位置系统（BluePages）方面的开发工作。他的工作还包括为几个 IBM 内部部门提供架构和解决方案设计，并与 CIO 部门和 IBM Research 部门协同工作来使用最新的 SOA 方法帮助设计应用程序。他最近的兴趣包括充分利用一些新技术的潜力，例如 WebSphere eXtended Deployment、Rational 产品组件和 IBM 的 intraGrid 架构。 |
| 
| | Moon J. Kim 是 IBM 的一名资深技术成员，负责开发战略性的基础设施，包括网格计算。他已经开发了很多系统解决方案，例如 Advanced Web System 和 Broadband Interactive System；他还是 S/390 系列和 MPP 系统的一名核心架构师和开发人员。他是 IBM 的一位发明家，已经发表了很多技术论文和书籍。 |
对本文的评价
| 
