级别： 初级 Robert Vrablik, 资深分析师/网格计算解决方案架构师
Richard Strysniewicz, 资深软件工程师
Chris Reech (reech@us.ibm.com), 资深技术成员
Dennis Spexet, IT 架构师
2004 年 11 月 29 日 在这个系列 3 篇文章的第 2 篇中，作者将详细介绍分析加速网格环境（AAGE）基础设施组件如何相互关联、协调工作，以构建并交付支持大量应用需求的虚拟系统环境。在
第 1 部分 中，作者讨论了网格计算要解决的问题，以及商业组织可以从实现网格解决方案中获得的好处。第 3 部分将提供一个真实的实现例子。
AAGE 基础设施组件如何相互关联、协调工作，以构建并交付支持大量应用需求的虚拟系统环境呢？让我们来看一个基本的网格实现的例子。
图 1. 用于简化登录和访问的用户门户的基本网格实现
在本例中，已经建立了一个用户门户来简化有经验的工作人员的登录方式和从一个公共的位置访问应用的方式。这个 SAS 应用运行在一个 Data Synapse 托管的处理网格节点集上。应用门户使用 Data Synapse 界面向 Data Synapse 提交任务。Data Synapse 对在预先定义的 Data Synapse 引擎集上运行的任务进行管理。
在 Data Synapse 托管的环境中已经建立了一些策略，根据业务的优先级来确定分配给每个参与的业务单元的系统资源的数量。IBM DB2® Information Integrator 采用数据联邦技术从一组分布式数据源中构建应用程序的输入数据文件。
Avaki Data Grid 技术提供了对这些分布式输出数据的访问能力，使得输出结果对于用户来说就仿佛是一个文件，虽然数据文件仍然与分布式计算资源保持着相关性。
对于新采用网格技术的商业和公共机构来说，这个基本的实现是一个很好的入手方法。
在这个例子中，由多个业务单元共享一组通用的计算资源。每个业务单元都向网格提交自己的应用请求。如果只有一个业务单元请求执行网格中的服务，那么网格中的所有资源都被用来执行这个应用。
另一方面，如果多个业务单元主动搜寻网格中的应用服务，那么就由一种策略控制应该为每个业务单元消耗多少资源（可以为每个业务单元建立一个最小的资源集，这样就不会出现一个业务单元占据网格中所有资源的情况）。这导致如果业务单元管理它们自己的系统资源，它们就能够超出其可以访问的资源而随需应变地访问计算资源。
还有，由于信息技术是通过一个公共池管理的，因此这些资源的利用率更高，为业务提供了更强大的 ROI，同时提供了一个可以帮助简化对这些系统资源进行管理的环境。
这就是网格技术优化系统资源如何在企业中使用的同时，如何帮助加速应用的执行的。
尚需更多
为了促进业务操作以及对 IT 资源日益增长的需求，还需要其他网格技术。如果业务单元群集已经开始像上一个例子中描述的那样部署到网格中了，情况更是如此。
将一个部门网格作为一个虚拟的系统资源子集来使用可以得到更好的规模化效益，这是显然的。要实现这一点，基础设施需要具备以下属性：
- 协调单一应用和启用技术的的灵活性。
- 访问共享企业数据的访问能力。
- 应用程序的用户界面（或用户门户）的共同性。
- 在网格中提供系统资源来响应业务单元优先级并强制采用服务级别协定的能力。
- 协调系统资源的添加、减少和修改网格适应更多业务单元的能力。
以下各节（以及图 2）显示如何添加新技术来适应这种变化的情况。
虚拟化网格
IBM Grid Toolbox 网格服务被实现用来虚拟化网格的基础设施。这可以允许网格组件更容易地添加或修改，从而支持单个应用，它可以启用多种类型的可插入网格管理器，并能在网格中共存。
动态供应
IBM Tivoli® Intelligent Orchestrator 提供网格资源。它修改负载的需求，以便根据服务级别协定来为应用提供服务。
网格管理程序
网格管理程序平衡了资源之间的负载。
信息联邦
DB2 Information Integrator 从多个数据源（例如数据库、XML 和文本文件）中联合构建关系型输入数据。
文件和存储系统的虚拟化
SAN File System 提供了对在异种文件系统中保存的数据的通用访问能力和 SAN Volume Controller，后者可以优化地将文件存储在异种存储设备中。
用户门户
Portal Web 应用和 WebSphere® Application Server 通过为认证、提交和管理任务提供单一的界面从而对用户界面进行虚拟化。
图 2. 可以添加到 AAGE 中来管理变化环境的新技术
用户门户
用户门户是一个在 WebSphere Application Server 上运行的 Web 应用，设计用于将用户与网格基础设施隔离开来。用户不需要知道他们的任务是在哪个服务器上运行的，也不需要知道他们的数据保存在哪个服务器上。对于所有的采用 SAN 技术连接的存储，用户门户都表示为 SAN File System 的单一名称空间，如果有些存储设备不是采用 SAN 技术连接的，那么就使用一个组合的 SAN File System 和 Avaki 名称空间。
用户门户使用基于整数的安全系统提供了用户认证的一个单一入口。一旦用户登录到门户中并通过认证，那么他就可以访问自己的“证书”了，证书会在整个网格上进行传递，从而为用户进一步在底层机器上的操作提供授权。
用户门户提供了一个单一的界面来提交和管理任务。使用多个应用的用户从一个单一门户上提交和管理这些应用。这假设应用本身非常简单，例如提交任务和查看结果。ISV 开发的应用可能有自己的界面。用户门户也可以用来连接这些应用。
网格管理程序
大部分网格实现都是使用单个供应商的开源或自己的网格中间件构建的，因此网格上运行的所有应用都必须与给定的中间件兼容。随着网格计算的不断发展，可能会出现异种中间件实现需要共存的情况。一个很好的论据是网格实现都是基于开放标准的。
这个环境设计用于启用单个应用门户使用 IBM Grid Toolbox V3 for Multiplatforms 连接多个异种网格管理程序。网格计算的目标是从连接在一起的在多个平台环境中共享不同资源组合的系统集中创建一个强大的自管理虚拟计算机。这些系统以及系统之间的连接都是网格。
要实现这种功能，必须使用网格计算的通用标准构建一个安全而又稳健的基础设施。诸如开放网格服务基础设施（OGSI）之类的标准是由 Global Grid Forum 开发的，并且已经在不同的产品中实现了。IBM Grid Toolbox V3 for Multiplatforms 是基于开放网格服务架构（OGSA）的，并且实现了 OGSI 标准。 IBM 忠于这些标准；实际上，IBM 和其他参与人员已经宣称自己的目标是使用 Web Services Resource Framework (WS-RF) and Web Services Notification 来增强这些标准。在产品实现完成时，我们将把这种技术集成到 AAGE 项目中。
Toolbox 包括：
- 可以运行网格服务并与其他网格参与者共享服务的一个宿主环境。
- 用来管理网格服务和网格宿主环境的一组工具，包括一个基于 Web 的界面和 Grid Services Manager。
- 一组用来开发和部署新的网格服务和网格应用的 API 和开发工具。
通过使用这些虚拟化服务，环境的组件都被使用 OGSI 兼容的接口与网格管理程序隔离开来。这个环境设计用于通过使用基于开放标准的网格服务来支持异种网格中间件。
在网格上运行的服务通过这个接口动态驱动中间件的选择。用户不应该关心哪个网格管理程序启用了应用。它们只是获取支持网格的应用，配置并部署组件。网格服务的实现为数据中心管理程序提供了添加或减少网格管理程序实例的灵活性，而对当前运行的应用造成的影响最小。
最初，这个接口可以使用 Data Synapse 接口实现，但是以后可以添加其他应用。如果这些应用需要不同的网格管理程序进行支持，那么就必须为每个网格管理程序实例都开发一个 OGSI 接口。
网格中间件供应商正在开始采用开放标准的实现，因为实现这些标准可以让产品在网格系统中运行时动态性更好。不幸的是，向管理域中添加或减少系统资源并不是一个完全动态的任务。大部分网格基础设施管理程序仍然是静态地定义管理域中的资源。资源可以添加或删除，但是这通常需要手工干预。
下面我们将讨论这个简单的环境如何利用动态供应多个网格管理域中的系统资源的技术来满足服务级别协定策略的要求。
编排和供应
一个企业的最大挑战之一是将自己的 IT 基础设施转换为支持随需应变业务。虽然这与技术无关，但是它要处理组织策略。
商业组织中的各个部门需要自己的信息技术，并且不愿与其他用户共享资源。支持这种行为有很多原因：
- 政策力度。
- 预算。
- 担心会访问“属于”其他用户的资源。
- 数据的安全性。
这些行为不可能会变化。现在存在允许部门之间在企业内共享系统资源的技术，这并不会丧失按需访问这些资源的权利。
用户不必成为系统资源的物理属主，可以根据描述要访问的资源数量的策略进行通信，在可以访问资源时，就按照业务优先级进行访问，例如服务级别协定（SLA）。
IBM Tivoli Intelligent Orchestrator 包括 Tivoli Provisioning Manager，它根据变化的负载需求和策略中定义的限制在企业间分配系统资源。在这些策略中定义了系统资源的一个最大值和最小值，这样就不会有一个业务单元会消耗掉所有的可用系统资源。而且，系统资源可以根据日期、时间进行供应，也可以使用事件进行驱动。
在这个网格实现中，我们为 Tivoli Intelligent Orchestrator 定义了一些策略，用来判断如何管理为每个在网格中共享资源的应用域（或业务单元）建立的 SLA。Tivoli Intelligent Orchestrator 从每个网格管理域中接收资源消耗信息。这些消耗信息用来判断每个业务域的 SLA 是否满足。如果不满足，Tivoli Intelligent Orchestrator 就会与 Tivoli Provisioning Manager 一起检查其策略，从而确定是否由特定的组织可以提供更多或更少的资源来达到 SLA。如果有组织声明要消耗更多的系统资源，那么 Tivoli Provisioning Manager 就为需要这些资源的网格管理域提供更多系统资源。这些资源可以来自网格环境之外或从其他网格管理域中重新供应的一个资源池（这取决于采用的策略和这些系统资源的可用性）。
接收系统资源消耗信息是由一个 Tivoli Intelligent Orchestrator
ServerDriver 类实现的，它会根据网格管理程序的负载返回一个 CPU 的利用率。这个定制实现是使用一个介于 Tivoli Intelligent Orchestrator 和网格管理程序之间的兼容 OSGI 的接口实现的；标准的驱动使用 SNMP 接口。
Tivoli 正在为网格环境启用网格计算和供应/编排能力开发一个战略解决方案，称为 Objective Analyzer，它是 Tivoli Intelligent Orchestrator V2.0 的一部分。它启用了多个资源消耗算法，并与多个网格管理程序进行了集成。我们的示例实现使用一个更加灵活的战术方案来补充这个 Tivoli 战略方案。
图 3. 一种支持在两个组织之间编排和供应共享资源的配置
在这种配置中，组织 A 的供应优先级为白金级（最高），至少需要 2 个资源。组织 B 的供应优先级为黄金级（较低），至少需要 3 个资源。整个企业拥有 8 个资源，划分成两个共享池：一个用于 Linux 资源，一个用于 Windows 资源。配置中有两个网格管理程序 X 和 Y，表示在企业中静态配置的两种网格中间件。本例中“静态”的意思是说网格管理程序是不可供应的。
图 4. 描述已经支持两个并行应用的计算资源的例子
在本例中，每个组织都运行一个不同的应用。每个应用的执行都是由需要的网格管理程序进行管理的。每个网格管理程序都在供应给自己的所有资源上执行应用任务。供应给组织 A 的资源更多，因为它的供应优先级比组织 B 高。组织 B 根据其为最小资源数定义的策略而具有一个供应给它的最小资源数。
SAN File System
SAN File System 在 IBM Storage Virtualization 策略中提供了一个主要的平台。其主要功能是提供一个为存储域网络（SAN）设计的通用文件系统。它集成了不同磁盘子系统中的存储，并让连接到 SAN 环境中的服务器可以以共享文件系统的形式来使用这些存储设备。作为功能的一部分，它在网络中提供了一个单一的集中控制点来管理文件和数据，如图 5 所示。
图 5. SAN File System 在网络中提供了一个单一的集中控制点来管理文件和数据
SAN File System 的基本设计分为数据的处理和元数据的处理。正如图 5 所示的一样，SAN File System 客户机是连接在 LAN 和 SAN 环境中的。每当访问 SAN File System 时，元数据的处理都是由专用的元数据服务器通过 TCP/IP 与客户机进行通信来执行的。然而，也可以通过 SAN 直接访问数据本身。
作为一个产品来说，SAN File System 是一个在选定的 IBM xSeries® 服务器上安装的软件解决方案。这里的开发和测试使用的 SAN File System 是一套入门级的配置，只包含两个 xSeries 服务器，上面运行的操作系统是 SuSE Linux Enterprise Server 8。每台服务器上都包含 2 个 3-GHz 的 Xeon 处理器， 4 GB 的 RAM，双 Fibre Channel 口，以及 4 块 10/100/1000 MB/sec 的以太网卡。
使用这种方式处理文件系统数据提供了几个优点：
- 性能更高 —— 应用启用网格技术，可以在计算过程中获得更好的 I/O 性能。
在使用共享存储时，性能可以与本地磁盘访问媲美，甚至比本地磁盘访问的性能更高（光纤速度，条带化技术，等等）。
数据根据所需要的服务质量进行定位（即需要快速访问的数据保存到快速的硬件中）。
- 存储资源的利用率更高 —— 不需要数据的多份拷贝。
- 配置灵活 —— 存储硬件不直接连接在服务器硬件上，这样可以提供混合异构能力。存储设备和服务器可以独立升级。配置可以进行优化，以支持新的和变化的性能要求、容错能力要求和可用性要求。存储设备具有高度的可扩充性（也就是说，它可以进行扩充以适应大型网格的需要）。
- 管理成本更低 —— 基于策略的管理；集中化管理异种存储资源。
- 对用户和应用透明 —— 异种设备分组成行为和操作类似于单个文件系统的形式。
另外一个方面是 Avaki Data Grid，在这种环境中用来为多个管理域提供数据访问服务。 Avaki 使用一个联邦数据共享模型，一个全局的名称空间，以及一组 Data Grid Access Servers，它们可以支持 NFS 协议，客户机会装载这些服务器。这样可以有效地将数据网格映射为一个客户机文件系统层次。
Avaki 软件会被安装到一组选定的节点上，其中一个节点可以访问 SAN File System。SAN File System 中选定的部分被“导出”到 Avaki Data Grid 中，使 Avaki Data Grid Access Servers 节点可以对其进行访问。
Avaki Data Grid Access Servers 节点以 NFS 服务器的形式对外提供服务，NFS 客户机会像其他普通 NFS 服务器一样装载这些服务器。通过这种方式，SAN File System 中的数据就被导出到 Avaki 数据网格中，并由多管理域中的客户机使用 —— 即使那些没有传统的 SAN 连接的客户机也可以使用。这样就提供了使用以前独立的存储资源创建一个企业级网格的能力。
连接到 SAN 环境上的平台和那些通过 Avaki 访问数据的平台之间性能存在一些差异，但是使用 Avaki 的机器可能不会接收数据密集型的任务，这样就不会使整体的工作速度很慢。
数据联邦和许可证使用监视
数据联邦是这种架构的一种可选功能。这并不是启用网格环境所必需的。我们可以向这种环境中添加或删除数据联邦组件来支持特殊的应用需求。
例如，数据联邦可以使用一个数据预备阶段从多个异种数据源中搜集应用程序的输入数据。在本例中， 我们使用 DB2 Information Integrator 来获取数据并创建一个单一的输入数据集。
另外一个例子是在应用执行时动态访问多个异种数据源。在本例中，DB2 Information Integrator 的使用更加动态，在应用程序中动态访问多个数据源的 SQL 语句是以优化的方式执行的。
许可证使用的监视是本架构中的另外一个可选组件。它可以根据客户的要求添加或删除。如果在企业网格中需要监视软件许可证的使用，那么就必须在最初的开发和测试环境中包含这个组件。
在开发和测试过程中可以采用一种简单的方法。在这种简单的方法中，当应用在网格中的不同环境中运行时，Tivoli License Manager 可以对应用软件的许可证的使用进行监视。现有的 Tivoli License Manager 报告的接口让管理员可以查看应用软件许可证的使用情况。
详细介绍各种可能的软件许可证情况已经超出了本文的范围；这会高度依赖于软件供应商的许可证模式。注意在网格实现中，这是一个关键问题，应该在新实现的计划阶段就尽早解决。
安全性模型
系统将提供一个基于证书的模型，这样用户就可以访问 Web 门户和底层的资源。
Certificate Authority 为每个网格用户和作为网格成员之一的主机提供了签名的身份证书。任何 Certificate Authority 都是可以接受的（例如， Verisign 或 RSA Security）。现在， 在我们这个项目中可以使用与 IBM Grid Toolbox 一起提供的 SimpleCA。
Login 页面中包含了一个 Username 和一个 Password 文本输入域，以及一个 Login 按钮。要登录门户，用户需要输入用户名和密码，然后选择 Login。一旦用户允许登录， Web 应用就会调用
LoginServlet servlet Java 类。该类通过动态加载和调用一个 Java 用户认证和信息类对用户 ID 和密码进行认证。当前默认的用户认证和信息类可以通过一个 DB2 数据源访问共享的 Grid Information 仓库，并使用 Globus utility 类进行证书、密钥和代理的操作。
因此 servlet 和 JSP 可以进行通信，servlet 创建一个
UserInfoBean，它通过 Web 应用会话进行维护。在动态加载上面介绍的认证类之后， servlet 就可以在其中设置认证类。然后 servlet 向认证类传递用户名和密码，从而验证有效性。假设认证成功，servlet 然后就读取用户的信息（例如用户的角色）、应用程序以及结果目录，后者会在这个 Web 应用的后续步骤中用到。
除了动态加载用户认证和信息类之外，
LoginServlet 还要动态加载一个应用信息类和一个后端类，它们由 Web 应用中的其他 servlet 使用。
用户登录之后，Proxy JSP 就被调用了。Proxy JSP 访问前面创建的
UserInfoBean，从中提取出信息，并检查认证结果。如果认证失败了，就将失败信息呈现给用户，并在 10 秒钟之后自动返回 Login JSP。如果认证成功，就显示一个私钥密码，当前代理的位数，当前代理的生命期（单位是秒），以及两个按钮：Generate new proxy 和 Use existing proxy。
要生成一个新代理，用户需要输入自己的私钥和密码、长度以及当前代理的生命期，并选择 "Generate new proxy"。要使用现有的代理，用户只需要选择 "Use existing proxy"。在登录之前，Web 应用会调用
ProxyServlet servlet。根据选择的按钮不同，servlet 会使用所提供的参数生成一个新代理，或者什么也不做，只是切换到下一个 JSP 页面。
结束语
在本文中，我们详细介绍了分析加速网格环境（AAGE）基础设施组件如何相互关联、协调工作，以来构建并交付一个支持大量应用需求的虚拟系统环境。在本系列第 3 部分中，我们将提供一个真实的实现例子。
参考资料
作者简介  | | | Robert Vrablik 是 IBM Systems and Technology Group 的一名资深分析师和网格计算解决方案架构师。作为一名分析师，他负责判断对 IBM 产品进行功能集成的需求，从而支持 IBM 的网格计算业务。他在 IBM 的集成组工作，任务是为将来的网格业界特有的提供商设计解决方案原型。以前，他曾经是 IBM Consulting Group 的一名顾问，擅长的领域包括业务和信息技术转换，尤其擅长业务和 IT 综合领域，以及数据仓库的设计和实现。他还曾经当过几年的应用程序程序员/分析师，从事小型机上的业务应用和大型的业务保险系统应用的开发工作。 |
| | | Richard Strysniewicz 是 IBM Global Services 的一名资深工程师，在 IBM 基于 Web 的、分布式和实时系统开发方面具有 14 年多的从业经验。他是 IBM Global Services Grid Computing Initiative 组的成员之一，参与了很多项目的开发工作，包括参考架构、参考实现、网格中间件评估、客户支持以及内部及外部的培训和销售讲座。 |
| | | Chris Reech 是 IBM GglobalServices Technology Center 的一名资深技术成员，他是 IBM Global Services World Wide Grid Strategy 组的成员之一。他最近的工作重点是网格技术的商业化，以及面向石油、金融服务、设计与制造和生命科学客户的应用。他还领导着 IBM Global Services Universal Management Infrastructure 的网格技术应用，这是 IBM 的 交付管理技术，可以在一个共享的标准环境中实现“只为使用的资源付款”的要求。他具有 16 年多的分布式和实时计算开发方面的经验，目标客户是 IBM 的战略采购和咨询客户，以及美国的民间和军方组织。他拥有多项 IBM 在 Web 门户和随需应变网格计算技术方面的专利，毕业于 Lafayette 的路易斯安娜大学的计算机科学系，并获得了学士学位。 |
| | | Dennis Spexet 是 IBM Global Services 的一名 IT 架构师，已经在不同的技术领域工作了 10 年以上。他最近的工作重点是存储域网络以及与网格计算环境的集成。他拥有 Ann Arbor 的密歇根州立大学的数学硕士学位。 |
对本文的评价
| 
