网格计算——下一代分布式计算

【导读】过去有两种主要的需求极大地增长了网格计算的价值。不对称经济使得那些 IT 预算有限的公司只能更加充分地利用现有的计算资产，并通过智能地将有限的资源分配给适当的业务应用程序，才能更加灵活地对迅速变化的市场作出快速的响应。

　　过去有两种主要的需求极大地增长了网格计算的价值。不对称经济使得那些 IT 预算有限的公司只能更加充分地利用现有的计算资产，并通过智能地将有限的资源分配给适当的业务应用程序，才能更加灵活地对迅速变化的市场作出快速的响应。本文是这个 “网格观点” 系列文章的第一篇。在本文中，作者 Matt Haynos 对网格计算和诸如 P2P（端到端）、CORBA、集群计算和分布式计算环境（DCE）之类的分布式计算系统之间的异同进行了简要的分析。

　　网格计算最近作为一种分布式计算体系结构日益流行，它非常适合企业计算的需求。很多领域都正在采用网格计算解决方案来解决自己关键的业务需求，例如：金融服务已经广泛地采用网格计算技术来解决风险管理和规避问题、 自动化制造业使用网格解决方案来加速产品的开发和协作、石油公司大规模采用网格技术来加速石油勘探并提高成功采掘的几率。

　　随着网格计算的不断成熟，该技术在其他领域技术的应用也会不断增加。

　　从这个特征定义上来说，网格计算与其他所有的分布式计算范例都有所区别：网格计算的本质在于以有效且优化的方式来利用组织中各种异构松耦合资源，来实现复杂的工作负载管理和信息虚拟化功能。（注意，一个组织可能会跨越很多部门、物理位置等。我们此处使用的是 “组织” 一词的抽象意义。）

　　上一段提到的特征怎么将网格计算与其他分布式模型区分开来呢？这就是我们在本文中希望解答的问题 。我们不是展望网格的未来，而是探索一下网格的起源，并了解网格技术是如何逐渐成熟的，然后阐述网格技术与其他分布式计算解决方案（例如 P2P 和 CORBA）之间的区别。我们将通过对网格概念与最流行的分布式计算解决方案进行对比来探索这个问题。首先，我们来理解一下网格计算的价值。

　　为什么要进行网格计算？

　　在过去几年中，随着对自己在信息技术方面投资的重新审视，很多工作公司都得出这样一个结论：最重要的事情是更充分地利用已有的计算资源。因此，利用率的重要性就不断增加。从有限的 IT 预算中榨取更多功能已经很有必要。 另外，分布式企业中出现一个广泛的需求：要求能够将有限的资源智能地 分配给适当的业务应用程序。这种技术为企业提供了一定的灵活性，形式可能是对资源重新进行分发，来解决新的市场问题；也可能是让业务应用程序可以更好地服务于迅速变化的现有客户。

　　从制造业来看 —— 它们将自己的大部分资源都投入到了利润最高的产品中 —— 工作负载管理的目标是将计算资源分配给最重要的应用程序。我们称之为工作负载优化（workload optimization）。这是一个非常有吸引力的概念，不过它可以表示很多业务转换的挑战。例如，我们如何确定企业中到底是哪些东西构成了组件或组织上最重要的工作呢？

　　现在，这种概念所产生的潜在生产力和与向工作负载优化转化的趋势相关的商业利益都仍然如此巨大，因此这个概念还不可能被丢弃。网格计算背后的思想是解决平衡和重新分配现有 IT 资源所需要的压力。接下来，我们来看看这些思想和概念的起源。

网格计算的起源

　　与 Internet 类似，学术机构在开发构成网格计算基础的第一代技术和架构时，也走在了最前面。很多机构，例如 Globus Alliance、China Grid 和 e-Science Grid 核心程序，都是第一批开始孵化并培育网格解决方案使其不断成熟并适用于商业解决方案的地方。

　　网格诞生于那些非常需要进行协作的研究和学术社区。研究中非常重要的一个部分是分发知识的能力 —— 共享大量信息和帮助创建这些数据的计算资源的效率越高，可以实现的协作的质量就越好，协作级别也越广泛。

　　在商业领域也存在这样需要分发知识能力的一种类似情况。网格计算也可以解决这些需求，这是由于在 Web 服务标准的推动下，业务过程和事务的集成的重要性继续提高。随着商业网格计算的继续采用，（例如由 Global Grid Forum（即 GGF）之类的组织提出）标准会使从实际需求到商业应用程序都会受益。

　　目前，网格计算从学术界基于标准的技术的早期界定和开发中获益良多，这些标准可以满足商业业务所需要的更实际、更稳健的实现需求。我们没有理由去猜测这种协同趋势会随着网格计算的不断成熟而没落。

网格填充了一个重要的空白

　　在过去几年中，网格处理能力（网格每秒可以处理的位数）和微处理器的速度（它依赖于每个集成电路中晶体管的数量）之间出现了一个巨大的差距，如图 1 所示。

　　　　　　　图 1. 摩尔定律与存储发展、光纤发展的比较
　　正如图中所示的一样，网络处理能力现在每 9 个月就会翻一倍，而在历史上这种增长曾经一度非常缓慢。摩尔定律指出每个集成电路中晶体管中的数量每 18 个月就会翻一倍。这样就出现了一个问题。与网络能力的发展相比，处理器的发展速度（摩尔定律）要慢很多。

　　如果您接受这样一个前提：关键的网络技术现在正以比微处理发展速度更快的速度发展，为了利用网络的优点，我们需要另外一种更有效利用微处理器的方法。这个新观点改变了历史上网络与处理器成本之间的平衡。类似的讨论同样适用于存储设备。

　　网格计算就是解决这种差距的手段，它通过将分布式资源绑定在一起构成一个单一的虚拟计算机从而改变了资源之间的平衡。这个资源丰富的虚拟计算机以及应用程序加速所带来的优点（从几周变成几天，从几天变成几小时，从几小时变成几分钟，依此类推）为商业业务逻辑提供了一个诱人的前景（不过这也可能会需要在通信业务实践中作出重大的变化，以价格变化最为突出）。

　　现在我们已经介绍了网格计算的起源，并给出了一个例子来证明它的重要性，接下来我们将对其与其他分布式计算概念（集群计算、CORBA、DCE  和 P2P）进行比较，这样就可以

网格与集群计算的区别

　　集群计算实际上不能真正地被看作是一种分布式计算解决方案。不过对于理解网格计算与集群计算之间的关系是很有用的。通常，人们都会混淆网格计算与基于集群的计算这两个概念，但实际上这两个概念之间有一些重要的区别。

　　网格是由异构资源组成的。集群计算 主要关注的是计算资源；网格计算则对存储、网络和计算资源进行了集成。集群通常包含同种处理器和操作系统；网格则可以包含不同供应商提供的运行不同操作系统的机器（IBM、Platform Computing、DataSynapse 和 United Devices 提供的网格工作负载管理软件都可以将工作负载分发到类型和配置不同的多种机器上。）

　　网格本质上就是动态的。集群包含的处理器和资源的数量通常都是静态的；而在网格上，资源则可以动态出现。资源可以根据需要添加到网格中，或从网格中删除。

　　网格天生就是在本地网、城域网或广域网上进行分布的。通常，集群物理上都包含在一个位置的相同地方；网格可以分布在任何地方。集群互连技术可以产生非常低的网络延时，如果集群距离很远，这可能会导致产生很多问题。

　　网格提供了增强的可扩展性。物理临近和网络延时限制了集群地域分布的能力；由于这些动态特性，网格可以提供很好的高可扩展性。

　　例如，最近 IBM、United Devices 和多个生命科学合作者完成了一个设计用来研究治疗天花的药品的网格项目。这个网格包括大约两百万台个人计算机。使用常见的方法，这个项目很可能需要几年的时间才能完成—— 但是在网格上它只需要 6 个月。设想一下如果网格上已经有两千万台 PC 会是什么情况。极端地说，天花项目可以在分钟级内完成。

　　集群和网格计算是相互补充的。很多网格都在自己管理的资源中采用了集群。实际上，网格用户可能并不清楚他的工作负载是在一个远程的集群上执行的。尽管网格与集群之间存在很多区别，但是这些区别使它们构成了一个非常重要的关系，因为集群在网格中总有一席之地 —— 特定的问题通常都需要一些紧耦合的处理器来解决。

　　然而，随着网络功能和带宽的发展，以前采用集群计算很难解决的问题现在可以使用网格计算技术解决了。理解网格固有的可扩展性和集群提供的紧耦合互连机制所带来的性能优势之间的平衡是非常重要的。

网格还是 CORBA？

　　对于所有的分布式计算环境来说，CORBA 与网格计算表面的相似性可能比其他技术都要多。这是由于开放网格服务架构（OGSA）中网格计算和 Web 服务之间的策略关系所决定的。它们都是基于面向服务架构（SOA）的概念。CORBA 是很多任务关键的应用程序的骨干，从 1991 年创建以来不断发展成熟。在很多方面，CORBA 都是今天 Web（网格）服务的先驱。它提供了一个重要的基础，就像是几年之后 Java™ Remote Method Invocation（RMI）的地位一样。

　　例如，Boeing 在自己的 DCAC/MRM（Define and Control Airplane Configuration/Manufacturing Resource Management 的缩写）应用程序中使用了基于 CORBA 的解决方案，尤其是管理商业飞机所采用的零部件配置和目录部分的应用程序更是如此（喷气式客机有很多零部件）。Peter Coffee 是 e-Week 的一名技术编辑，他最近分析说新 Cunard Queen Mary 2 远洋航线中所有的操作都是由 CORBA 支持的。

　　CORBA 与网格计算之间的主要区别是 CORBA 假定是面向对象的（毕竟，这是名字中的一部分），但是网格计算没有采用这种假定。在 CORBA 中，每个实体都是一个对象，可以支持诸如继承和多态之类的机制。在 OGSA 中，存在一些与对象非常类似的概念，但是这并没有假定架构中有面向对象的实现。架构是面向消息的；面向对象是一个实现概念。然而，在 WSRF（Web Services Resource Framework）中使用形式定义语言（例如 WSDL，Web Services Definition Language）就意味着接口和交互操作都与 CORBA中的定义一样，它们共享一个主要软件工程的优点，同时可以采用面向对象的设计呈现。

　　另外一点区别是网格计算（OGSA）是在 Web 服务的基础上进行构建的。CORBA 与 Web 服务进行了集成，并与 Web 服务进行交互操作。CORBA 的一个问题是它假设了太多的 “端点”，这通常是参与 CORBA 环境的所有机器（客户机和服务器）。供应商的CORBA 实现中也存在交互操作的问题，CORBA 节点之间在 Internet 上如何操作的问题，以及端点如何命名的问题。这意味着所有的机器都必须遵守特定的规则和特定的方法，只有这样 CORBA 才能正常工作（所有这些都假设采用与 IDL、IOR 和 IIOP 类似的协议）。在构建高可用、紧耦合、预编译的系统时，这是一种比较合适的方法。

　　然而，在 CORBA 执行作业的方式和 Internet 方法之间缺少协作能力。CORBA 的确为 Web 服务标准的创建提供了灵感 —— 人们非常喜欢 CORBA 基础所提供的功能，并开始建立诸如 XML、WSDL、SOAP 之类的标准。他们通过在开放的Internet 基础上构建 Web 服务对 CORBA 的交互操作能力和灵活性问题进行了改进，这种方法在服务请求者和服务之间采用的是松耦合和延后绑定技术。为了实现这种改进，OGSA 增加了一种“软状态” 方法来进行容错。这些正是它们的设计目标。

　　Web 服务架构是一个面向服务的架构，CORBA 也是。不过 CORBA 的目标不同 —— 它被设计用来构建相当封闭的集成系统。

DCE 如何？

　　顾名思义，分布式计算环境（DCE）与其说是一个架构，还不如说是一个环境，二者之间有一个重要的区别。DCE 可以定义为一个设计用来促进分布式计算的紧密集成的技术集；网格计算（以 OGSA 的格式）不仅仅是一个设计用来封装分布式计算众多复杂机制的架构。

　　正如我们在对 CORBA 的介绍中看到的一样，在 DCE 中我们也可以看到紧耦合与松耦合方法之间的区别。DCE 技术包括安全性技术（DCE ACL 或 Aclearcase/" target="_blank" >ccess Control Lists)、对象和组件技术（DCE 分布式对象）、文件系统（DFS 或 Distributed File System）以及一个目录定义（DCE 注册项） —— 实际上，OGSA 可以在很多 DCE 技术基础上工作。

　　例如，网格安全协议可以采用 GSI（Grid Security Infrastructure）格式，也可以采用适当的 Web服务标准格式，可以用来与 DCE ACL 进行交互。很多网格应用程序都利用底层的 DFS（或其前辈 AFS，Andrew File System）。核心网格注册服务可以利用 DCE 注册项。

　　尽管这些技术大部分都被认为是服务，但是 DCE 与其说是一个面向服务的架构，还不如一组技术的集合。它对于 SOA 环境中构建应用程序的支持是有限的，因为 DCE 主要是通过采用一些块来构建分布式应用程序，但是并不需要去构建分布式的面向服务的应用程序。

　　网格计算与 DCE 之间另外一点重要的区别也与 CORBA 有关：OGSA 网格计算定义了以下 3 类服务：网格核心服务、 网格数据服务、 网格程序执行服务 。

　　CORBA、DCE 和 Java RMI 并不会特别关注数据（DFS 之外的数据）或程序执行服务，因为这些技术都是远程过程调用（RPC）系统所必需的。（RPC 是一种协议，应用程序可以使用这种协议向网络中另外一台机器上的一个程序请求提供服务，而无需理解网络的详细信息。这是一个同步操作，需要请求程序一直挂起等待远程过程返回结果，除非您使用了共享相同地址空间的轻量级进程（lightweight processe）。在网格核心服务（以及 WSRF）中定义和实现的很多服务都与 DCE 和 CORBA 中的基本服务类似。但是数据和程序执行服务是网格计算所特有的。

　　最后，我们对网格计算和 CORBA 与 Web 服务标准的关系所总结的区别也同样适用于 DCE。同样，我们在 Web 服务中所看到的很多改进都得益于使用诸如 DCE 和 CORBA 之类优秀分布式系统的经验。

最后来看一下 P2P

　　诸如 KaZaA —— 由于一些版权问题，它总是以大字标题的形式出现 —— 之类的应用程序是最近吸引人们对点对点（P2P）计算的注意的主要原因。不过这种技术本身展示了一些有趣的分布式特性，如果在网格环境中使用这些特性，很多都会非常有用。

　　首先，P2P 系统的特点是缺少集中管理点；这使它非常适合于提供匿名服务，或者提供一些反跟踪保护机制。另一方面，网格环境通常都有某种形式的集中管理和安全性（例如，资源管理和工作负载调度）。

　　P2P 环境中这种没有集中点的特性引发了两个重要结果：P2P 系统的可扩展性通常都比网格计算系统好。即使我们要在响应能力的控制和分布之间达成某种平衡时，网格计算系统也天生不如 P2P 系统的可扩展性好。

　　P2P 系统容忍单点失效的能力通常比网格计算系统更好。尽管网格比紧耦合的分布式系统的弹性更好，但是网格不可避免地要包含一些可能成为单点故障的关键元素。这意味着构建网格计算系统的关键是在分散与管理能力之间达成某种平衡—— 这可不是件简单的事情。

　　另外，网格计算的一个重要特性是资源都是动态的；在 P2P 系统中，资源的动态性天生就比网格计算系统更好，资源出现和消失的变化比网格中更快。对于 P2P 和网格计算系统来说，分布式资源的利用率是一个主要目标。给定一定的计算资源，这两种系统都可以尽可能地对这些资源进行使用。

　　这两个系统之间最后一点区别是标准：与网格领域中的标准相比，在 P2P 中通常缺少标准。另外，有了诸如 Global Grid Forum 之类的实体，网格领域就有了一种机制来重新定义现有的标准并建立新标准。

　　基于网格和 P2P 系统提供的互补优点，我们可以期望这两种方法最终会殊途同归，尤其是当网格达到“网格间” 的开发阶段时，届时这两种技术都将成为一些公共工具。

充分利用数据

　　我们已经介绍了网格计算的组件和起源，并解释了它在基于 Web 服务的企业级应用程序中的重要性，并对网格计算与其他 4 种主要分布式计算系统之间的异同进行了简要的分析。

　　几乎每个组织现在都有很多广泛分布的未用计算能力。虚拟化 —— 网格计算背后的驱动力 —— 可以帮助我们利用这些尚未使用的计算能力，IBM 参与虚拟内存、虚拟存储和虚拟处理器技术已经有很长的时间了。但是它并不仅仅是为客户创建这些技术。

原文转自：http://www.ltesting.net