在网格上构建动态基础设施之路 大部分组织都是通过使用诸如 Platform LSF 或 Altair 的 PBS Professional 之类的作业调度器，对任务负载进行虚拟化而开始构建自己的网格的。实际上，IBM 最近开始推出另外一个产品 Grid and Grow，其目标用户正是这些类型的客户。本文将首先从任务负载的上下文开始进行介绍。一旦对任务负载进行虚拟化之后，我们的重点就转向资源管理，以及能够根据任务负载需求来智能地匹配基础设施的资源（服务器、存储、许可证、网络带宽），并且是以一种自动化的方式来实现这种功能。这样，组织就可以将自己的注意力集中在如何一起应用作业调度技术和供应与自动配置技术上了。
随着组织迈出在网格计算基础上构建动态基础设施的步伐，他们发现要集成诸如供应和自动配置之类的技术，必须要有一些预见性的规划。这其中当然有技术问题，但是有一个非常重要的部分是要能够从根本上适合自动化的概念。
自动化哲学
基础设施的自动化是一个简单而明确的概念。如果能在正确的时间和正确的地点在企业中的多个应用程序和基础设施之间动态地分配资源，这当然是非常迷人的。但是事实证明，用户和组织都已经对这种思想和自动化思想普遍接纳了。人们天生对自动化的概念都心存疑虑，直到他们看到自动化过程或任务可以表现出与他们自己操作时相同的智能，他们才能打消疑虑。不过要将自己的作业或任务全部替换成自动化实现可能会有些问题。
此处有几种类似的场景可以提供帮助。第 1 条是一个基础设施自动化公司与我进行共享的。现在假设您正在购买一辆新车。您看了很多车，有一个资格非常老的销售员过来向您介绍他有一辆非常好的车。您并不相信它的功能！您想，“多告诉我点儿有关这辆车的信息。” 销售员说，当您坐在后座上时这辆新车可以自动驾驶。现在，问题是要自问一下您是否会坐在后座上。尽管您可能会对这辆车很感兴趣，但是答案可能是不。在您希望坐到后座上之前，需要能够接受这种方式并了解它的确能够正常工作才行。同样的准测也适用于自动化。
我也很难回到作为程序员每天花费几个小时在 UNIX® shell 脚本上的时光了。我曾经花费了几个星期来完善一个实现开发和管理操作的脚本，这可以简化我的（以及我公司的）工作生活。每次运行这个脚本时，我都要检查结果是否正如我们期望的一样。我盯着这个脚本几个星期，直到最终确认它可以正确运行了。我天生就是个怀疑论者，直到我确定这个脚本已经实现了想要做的事情，我才能放下心来。它从此就开始正式起航了。
我们介绍这几个例子的用意是，我们要适应自动化的生活是需要时间和经验的。聪明的组织已经意识到实现自动化必须有一个合理的过程，并且人类因素是一个重要的考虑因素。
从供应到自动配置
在图 1 中，我们会看到一种方法，它从最开始的阶段将网格部署到日益增多的自动化资源上。我们假设资源可以部署到多个应用程序基础设施上。例如，金融公司可能会有一个具有相应基础设施的面向客户的帐号管理应用程序，以及一个具有相关网格基础设施的风险管理程序。资源是有限的，技巧是将这些资源在正确的时间分配给正确的应用程序，从而将服务不可用的级别降至最低，或者最大化实现业务的价值。我们后面会再回到这个例子上来：
图 1. 实现完全自动化的革命性途径
让我们来看一下实现完全自动化的途径。前三个步骤涉及启动风险管理程序和新的网格基础设施。这通常都非常简单。首先，要构建网格基础设施，然后配置网格中间件和资源，之后再开始通过将其在网格资源集上进行调度来运行风险管理程序。当然，这假设您已经启用了应用程序，可以是对其进行了并行化处理，或者按照一种分散-聚合的方法来实现，从而在一系列分布式资源上运行。
下一个步骤非常重要。在这个步骤中，您将开始理解网格应用程序的资源使用和消费模式的强大功能。可以通过其他方法实现这种功能，例如使用某些离线分析工具，或者通过测量程序来获得有关如何操作和资源分配效果的智能。实现这些需要一些科学原则；但是整个模式要依赖于各个应用程序的特性。通用的目标是开始深入了解应用程序如何作为一个资源分配函数进行工作。这对于开始适应资源如何进行分配和对应用程序产生的总体影响来说至关重要。
假设您已经在 IBM Tivoli® Intelligent Orchestrator 之类的产品（称为目标分析器，在下一节中我们将介绍更多有关这方面的内容）中建立了确定资源分配的相关算法，下一个步骤是，资源分配软件在资源应该从一个基础设施分配到另一个基础设施时向系统管理员提供一些警告信息。此处没有什么可以进行自动化的。系统管理员开始理解资源分配软件给出的建议，并负责手工启动重新供应任务。这个步骤可能比较痛苦，因为这里会有很多管理操作，但是这对于适应资源分配软件决定的级别来说是一个非常重要的步骤。
步骤 6 提供了警告功能。但是这同时也为管理员提供了一种让资源分配软件真正应用和实现资源分配（或回收）的方法。资源分配软件向系统管理员提供自己的建议，并请他确认应该采取的响应操作。这与步骤 5 非常类似；唯一的区别在于我们提供了一种真正地执行资源分配的选项。这是一个非常重要的步骤，因为管理员会本能地说，“继续，就这样吧，我相信你”。一段时间之后，管理员就会适应自动化软件的用法了。
最后一个步骤实际上要对资源分配软件进行完全控制。如果已经开发了适当的资源分配算法和策略，那么您就可以坐在那儿，观察自己的有限资源如何在正确的时间部署到正确的应用程序上，从而最小化服务不可用的级别，或者为您的公司提高业务的价值。
网格环境中的资源分配
资源分配软件中的一个关键问题和考虑因素是，如何确定何时将资源分配给特定的应用程序及其相关的基础设施。我们介绍了一种革命性的过程来实现资源分配自动化，这实际上可以同时应用于网格基础设施和非网格基础设施。这是一种哲学。但是在涉及网格基础设施时，在制订资源分配决策时存在的问题要求特别进行考虑。
Tivoli Intelligent Orchestrator 在多个应用程序基础设施之间制订资源分配决策的方法是，通过一个具有称为目标分析器 的可插入模块的框架来实现的。对于每个应用程序基础设施来说，至少存在一个用于这个环境的目标分析器。目标分析器就是软件中的一部分，它返回使用 1 到 N 个资源来实现一定的服务级别的可能性。
目标分析器实际上会让 Tivoli Intelligent Orchestrator 知道，在应用程序（或应用程序组）分配了一定数量（至少是一个）资源的情况下，不能实现自己的服务级别协定的可能性。Tivoli Intelligent Orchestrator 的工作是利用所有这些信息，并在多个应用程序之间制订基于策略的资源分配决定。对于网格环境来说，技巧是如何构建智能目标分析器。
网格环境有很多不同的特性。通常来讲，资源利用率是可以实现的服务级别的一个很好的指示器。这对于 Web 服务环境（例如我们的金融帐号管理应用程序）来说尤其是如此。但是它对于我们的风险管理应用程序这种网格环境来说并不能正常工作。实际上对于很多网格用户来说，一个被高度利用的网格基础设施才是我们的目的，这也是我们的首要目标。
对于网格环境来说，更为重要的是计算的速度。应用程序的处理完成得如何呢？它的速度是否变慢了呢？增加其他资源可以使其加速吗（这取决于应用程序）？这对于网格环境的评价来说更为适合。另外，这既适用于长时间运行的任务负载，也适用于短时间运行的任务负载。对于短时间运行的任务负载来说，速度实际上是在网格基础设施上可以实现的事务吞吐量（任务）。
为网格环境制订资源分配决定和构建目标分析器可能非常复杂，因为在集成时需要考虑很多问题。然而，现在采用的一种非常简单的策略是基于一天中的时间的。在我们的例子中，对帐号管理应用程序的使用可能比较少，例如，它可以在正常的业务时间之后运行。因此现在来说，我们可以将这些资源重新提供给风险管理应用程序，或者当时可能运行的其他网格应用程序。这是一种确定何时应该分配网格基础设施的简单资源分配策略。
想了解甲骨文公司在网格计算领域的最新研究成果吗？那就进来看看吧
从供应到自动配置
在本文中，我们介绍了在多个应用程序基础设施之间制订资源分配决策时所涉及的自动化智能方面的考虑。尽管所涉及的技术可能并不太重要，尤其是在涉及网格基础设施时更是如此，要考虑的一个关键问题是自动化中人的因素。另外，网格环境中的资源分配决策需要特别考虑典型的 3 层应用程序基础设施。
最后需要一提的一件事情是有一些集成网格包，例如 WebSphere® Extended Deployment（XD），可以为管理员简化对于应用程序优先级策略的设置。我们并不需要构建其他资源分配软件。管理员可以指定应用程序的相对重要性及其服务级别的目标，WebSphere XD 可以自动管理资源的分配。
