专利名称：应用系统智能优化器的制作方法
技术领域：
本发明一般地涉及按需操作环境和动态工作负载均衡，并且更特别 地涉及一种应用系统智能优化器。
背景技术：
按需操作环境使得信息技术(IT)基础设施内的价值体现出来，以 应用于解决商业问题。IT基础设施是使得能够进行对商业应用和处理的 快速部署和集成的基于开放标准的集成平台。与实现基础设施的真实虚 拟化和自动化的环境相结合，它能够按需递送IT能力。按需操作环境 必须是灵活的、自管理的、可缩;故的、经济的、有弹性的并且基于开方文 标准的。当建立按需操作环境时，应当分析三个主要方面
-集成提供工具以获得处理、人员、信息和系统的统一视图。
-虚拟化考虑到合并和用以适应变化的需求的能力，通过隐藏底 层硬件和系统软件的细节，简化部署并改善对计算资源的使用。
-自动化克服系统管理的复杂性以能够更好地使用固定设备、改 善可用性和弹性，并且基于商业策略和目标来减少成本。
按需体系结构引起应用于系统环境的工作负载发生变化，达到以前 从未达到的规模，并且影响到比以前大得多的范围和种类的组件。这一 变化影响了整个客户商业解决方案，包括应用和与其相关联的基础设 施。从IT的观点看来，这转化为能够为公司提供由如下机制驱动的灵 活的基础设施，该机制持续地调整并调节全局系统容量使其适应持续变 化的应用工作负载。
当今，还没有能够优化全局应用系统的现有系统，包括软件应用包 和与其相关联的基础设施，也就是硬件和中间件。一^殳而言，现有的应 用系统优化器只在应用级或基础设施级上起作用，但是它们不会在同一
逻辑流中的两个级别上起作用。
影响应用和基础设施两者的现有系统实现监控、建才莫和规划阶段， 并且提出将要在系统级或应用级上采取的动作。现有系统不利用在商业 应用级上的直接结果来执行实时优化动作。因此，当今的系统提供了有 限范围的优化。
对全局商业解决方案系统进行优化需要若干分立步骤，包括监
视、分析、建模、规划以及在应用级和/或系统级上采取动作；在一 些出版物中描述了这些系统，其中每个出版物只涉及特定范围的动 ^f乍 。 #J 长口 , 在 http:〃www.umt.com/site/index_356.html 禾口 http:〃www.redbooks.ibm.com/redbooks/pdfs/sg246057.pdf 中描述了用于
监^L和改善应用性能的系统。
发明内容
因此，本发明的一般目的在于克服如上所述的现有技术的缺点。
本发明的另 一个目的在于提供一种基于应用组件和系统体系结构 分析来定义并应用 一组联合动作的管理系统。
本发明的另一个目的在于提供一种在应用级、系统级和全局体系结 构级上起作用的自优化的(self-optimized)管理应用系统。
本发明的另一个目的在于提供一种适合于减少应用系统管理的成 本和应用基础设施的全局成本的自优化的管理系统。
这些和其他相关目的通过如下方法来达到，该方法是一种用于对在 包括多个资源的计算机环境中执行至少 一个应用组件进行优化的方法， 一组所述多个资源专用于所述至少一个应用组件，所述方法包括以下步 骤
-在初始化阶段
-创建系统数据模型表，其包括对所述多个资源的主要特征的 描述；以及
-创建应用数据模型表，其适合于存储对分配给所述至少一个 应用组件的所述至少一个应用组件所需的资源、所述至少一个应用
组件的响应时间、以及所述应用组件所需的响应时间的描述；
-在运行时
-收集分配给所述至少一个应用组件的资源的状态，并且将所
述状态存储在所述应用数据模型表中；
-收集所述至少一个应用组件的响应时间，并且将所述响应时 间存储在所述应用数据模型表中；
-将分配给所述至少一个应用组件的资源与所述至少一个应用 组件所需的资源进行比较；
-将所述至少 一个应用组件的响应时间与所述至少一个应用组 件所需的响应时间进行比较；以及
-如果所述至少一个应用组件的响应时间大于所述至少一个应 用组件所需的响应时间，如果所述专用资源的^f吏用率在所述至少一 个应用组件的资源需求内，并且如果至少一个第二应用组件正在运 行，则如果所述至少一个第二应用组件的优先级低于所述至少一个 应用组件的优先级或者如果所述至少一个第二应用组件比所述至少 一个应用组件更耗费资源，就延迟对所述至少 一个第二应用组件的 执行；
-否则，如果所述至少一个应用组件的响应时间大于所述至少 一个应用组件所需的响应时间，并且如果所述专用资源的使用率低 于所述至少 一个应用组件的资源需求，则向所述至少 一个应用组件 分配更多的所述专用资源；
-否则，如果所述至少一个应用组件的所述响应时间大于所述 至少 一 个应用组件所需的响应时间，并且如果全部所述多个资源并 非专用于所述至少一个应用组件，则向所述至少一个应用组件提供 并非专用于所述至少一个应用组件的一部分所述多个资源。 本发明的更多实施例在所附权利要求书中提供。 通过研究附图和详细描述，本发明的更多优势对于本领域普通技术 人员来说将变得明显。其目的在于在此包含任意附加的优势。
图1示出了称为"应用系统智能优化器"的本发明系统的一般环境。 图2描绘了与专用系统和全局系统池相关联的系统数据模型表。
图3示出了与企业应用包的特定模块相对应的应用数据模型表。 图4示出了在图3的表上示出的应用组件层级的示例以及本发明的 三个优化级别。
具体实施例方式
根据本发明，提供了一种管理系统，其定义并应用一组联合动作， 该组联合动作根据从不同组件收集的输入数据的组合而产生，这些输入 数据包括
*应用数据，诸如
-实际的全局工作负载；
-每种类型的实际的工作负载(例如，联机、批处理、打印和更新)； -每种工作负载类型的实际响应时间；以及
*基础设施数据，诸如
-系统(例如，CPU、存储器、I/O、网络、磁盘使用率)； -中间件(例如，数据库容量和访问类型，以及响应时间)； -应用服务器(例如，容量和事务类型，以及响应时间)； 通过在以下不同级别上按照从最简单到更复杂的逻辑顺序采取的
动作，所收集的数据将产生自优化的应用系统
-应用级，诸如工作优先级、工作重组织(例如，"联机"相对于 "批处理"，以及"更新"相对于"只读")；
-系统级，在一组预定和分配的资源内(工作负载管理原则、在所
定义的资源范围内管理优先级)；以及
-全局体系结构级，其中根据需要并且在前述步骤已经达到它的动
作限制时，扩展从共享池分配给应用的资源(提供原则)并且将资源动
态地添加到应用系统基础i殳施。
同样，根据本发明的优化可以在宏观阶段(例如，应用模块或系统
实体)和/或在微观阶段(应用模块的特定事务或者系统子实体)进行。 在优选实施例中，优化首先在宏观阶段应用，并且该阶段连续递减直到 系统达到期望的优化状态，或者直到已经达到更低的阶段。可以通过例 如应用或系统实体的主要特征和特性的数值和精度来确定应用或系统 实体的阶段。
本发明的核心基于三个主要原则
-将应用工作负载和所需的系统资源二者都视为组件，实现各种各
样的"应用到资源"组合和(重)分配决定；
-监视实际应用工作负载和系统资源使用率并且将其与所定义的 需求进行比较；以及
-当观察到实际的和所需的状态之间的差异时，采取优化动作。 图1示出了称为"应用系统智能优化器，，(ASIO)的所公开的发明 的一般环境100。应当注意，该系统环境包括分配给特定应用的专用子 系统和全局子系统，全局子系统也就是不专用于任何特定应用的系统资 源池。由ASIO系统105使用的数据来自应用环境应用数据IIO和系统 环境系统数据115 二者。这些初始数据由应用系统策略和规则来完成， 通过应用系统策略和规则接口 120将这些策略和规则输入到系统中。应 用系统策略和MJ'j可以由用户输入或者/人存储^殳备或网络进行访问(没 有示出)。应用系统策略和规则存储在知识库125中，知识库125包括 应用和系统数据模型和相关联的状态。优选地，应用和系统策略和规则 在建立或初始化步骤期间通过接口 120定义并且按照请求而进行更新。 ASIO算法包括初始化步骤和运行时模式。如上所述，在初始化步 骤期间，优选地确定应用特性和策略(定义ASIO算法身见则)，识别专 用系统和全局系统，并且设置应用和系统数据模型。
在运行时模式中，ASIO算法通过以下操作来监视并优化应用系统 -通过将应用资源需求与所分配的应用资源进行比较，分析应用资 源需求以收集状态信息；
-分析状态信息并分析所需的资源与实际所分配的资源之间的差
别；
-确定一组推荐的动作，并将这些动作转换成可由对应的执行系统 执4亍的命令；
-在正确的级别上，将命令发送到执行系统，
-应用纟及；
-专用系统级；以及 -全局系统池级。
为此，应用事务和系统资源分析器130分析应用数据IIO和系统数 据115,并且将应用事务和系统资源状态发送到知识库125。根据预先 确定的频率参数周期性地更新这种状态。因而，知识库125汇总了根据 系统和应用前景以及应用需求和可用资源来表征系统状态的所有信息。
应用和系统监视模块135监视存储在知识库125中的数据以检查应 用系统(AS)的不同组件的行为来确定是否满足了应用需求。通过将应 用需求与应用状态进行比较，应用和系统监视模块135确定应用优化器 140是否必须向AS的不同单元给出命令，以通过对应用、专用系统和 全局系统池环境上的动作进行组合来实现对全局系统的优化。
如果应用和系统监视模块13 5确定应用资源需求不同于所分配的应 用资源并且超过了预先确定的门限，则进行对应于第 一级优化的第 一测 试145以确定能否优化应用工作负载。如果能够优化应用工作负载，则 确定用于根据应用系统策略和规则推荐来管理应用工作负载优先级的 命令(方框150 )，并且将该命令发送到应用包功能155。如果不能优化 应用工作负载，则进行对应于第二级优化的第二测试160以确定能否将 现有资源添加到应用系统。如果能够将现有资源添加到应用系统，则确 定用于根据应用系统策略和规则推荐来向应用分配更多资源的命令(方 框165),并且将该命令发送到专用系统优化功能170。如果不能将现有 资源添加到应用系统，则进行对应于第三级优化的第三测试175以确定 能否将附加资源添加到应用系统。如果能够将附加资源添加到应用系 统，则确定用于根据应用系统策略和规则推荐来向应用提供更多资源的 命令(方框180),并且将该命令发送到全局系统池提供和协调 (providionning and orchestration)管理器185。
应当注意，根据在需求和所监视的状态之间所观察到的差异，命令 或所推荐的动作可以包括添加或释放资源。同样，对命令的执行可以由
应用系统自动执行，或者被作为将要进行的动作向操作者提出。
根据第一级优化，事务类型的应用组件与系统组件(专用系统)相 关联，并且由ASIO引擎根据系统组件状态和资源可用性通过应用包功
能155潜在地进行重组织或重调度。
第二级优化可以实现模块和事务类型组件族二者。它与专用系统组
件级相关联。ASIO算法使用应用和专用系统组件参数的组合来动态地 使系统资源适应于应用组件工作负载，其中使用专用系统优化功能170， 如工作负载管理、动态分区和动态数据库优化。
第三级优化实现应用模块类型的组件，它涉及与资源的全局系统池 的交互。通过提供和协调管理器185， ASIO算法使用应用组件和系统 组件参数的组合来请求从可用的资源池添加系统资源。
在优选实施例中，知识库125包括两个表，称为系统数据模型和应 用数据模型，根据系统和应用前景以及应用需求和可用资源来表征系统状态。
系统数据模型(基础设施数据)
系统数据模型表是对包括专用系统和全局系统池的整个系统资源 的描述。因此，它描述了对使得应用系统以优化方式运行来说可用的全 部资源。在优选实施例中，系统数据模型资源清单(inventory)是一个 表，该表的行表示资源，列表示资源的主要特征。例如，图2的表200 描绘了与专用系统和全局系统池相关联的系统数据模型表。如在图2上
所示出的，系统数据模型表200的每一行， 一般地指代为205,对应于 特定的资源。例如，行205-3描述了单个系统(S)。行的数量依赖于系 统和优化该系统所需的粒度。如果需要，可以在ASIO正在运行时更新 该粒度。例如，如果存储特征可以存储在单个行中，则随后可以将这一 行分解为表征子存储设备特征的若干行，使得可以进行更高级的优化。 如上所述，系统数据模型表200的每一列， 一般地指代为210,对应于
资源的主要特征。例如，歹lj 210-1包括与CPU特性相关的信息，而列
210-2涉及存储器特性。同样，列的数量依赖于系统特性和优化该系统 所需的粒度。如果需要，可以在ASIO正在运行时更新该粒度。例如， 如果CPU特性可以存储在单个列中，则随后可以将这一列分解为表征 诸如CPU本身和高速緩存之类的子CPU特性的若干列，使得可以进行 更高级的优化。同样，在优选实施例中，如上所述，在初始化步骤期间 完成系统数据模型表。依赖于资源类型和资源特征，系统数据模型表的 一些单元格可能是空的。例如，即使存储设备可以包括CPU, CPU仍 然不是这类资源的主要特征，因此对应的单元格可以是空的。可以通过 图1的应用和系统策略和规则接口 120来识别这种单元格。
应当理解，模型是足够灵活的，使得新资源类型和相关联的参数能 够被定义，并通过资源模型到应用模型的灵活关联而被输入到ASIO逻 辑流中。特别地，在将新资源添加到系统环境时更新系统数据模型表。
优选地，使用资源的如下主要特征在系统数据模型表中描述资源， 这些主要特征对应于应用工作负载组件用来定义它们的特定资源需求 的参数。自然地，必须针对系统的每个资源而识别的关键特性依赖于资 源本身的种类。例如，此处是对以下资源来说应当记住的主要特性
*单个系统系统ID
-专用于应用组件(是/否)；
-体系结构类型和OS版本例如，Intel ( xx处理器)、Unix (例 如AIX、 HPunix或Solaris )、 zOS、 Linux (例如RedHat或Suze ) 或者I5/OS;
-CPU (处理器速度(MHZ)、使用率(％ )以及分区数量； -存储器(中央存储器大小(MB)和使用率(％ )); -硬盘(专用于系统的容量(GB)和使用率(％ ));以及 -I/O (数量、与系统相关联的I/0带宽(GB/s)和使用率(％ ))。 *逻辑分区分区ID (与对系统来说相同的特性)以及 -连接到单个系统ID。
*数据库数据库ID
-类型(例如DB2、 Oracle和SQL DB);
-版本；
-DB大小(MB);
-所分配的存储器(缓冲池和使用率(％ ));以及 -任意其他的关键参数(例如依赖于所实现的数据库) *应用/事务服务器
-类型(例如CICS、 Tuxedo、 WebSphere和WebLogic );以及
-版本。
自然地，为了优化的目的，可以定义其他类型的系统资源并且将其 关联到应用组件。
为了进行说明，假定表200的每个资源参数是"灵活的并且可远程 管理的，，，也就是为了优化的目的，可以远程改变它的值。如果在系统 数据模型表中需要不可远程管理的资源参数，则附加的状态可以用于表 明对应的参数是否是可远程管理的。
应用数据模型
应用数据模型表在系统基础设施和应用行为之间建立链接。在应用 数据模型表中汇总了应用数据，其中依赖于所需的粒度，每一行包含特 定应用、特定应用组件或特定应用子组件的主要参数。应用数据模型表 的每一列表征了应用所需的并且当前分配给这些应用的特定资源。同 样，列的数量依赖于所需的粒度并且能够动态地调整。依赖于应用类型 和参数类型，应用数据模型表的一些单元格可以是空的。例如，不会将 任何数据库参数(被请求但未被分配的)分配给不使用任何数据库的应 用组件。可以通过图1的应用系统策略和规则接口 120来确定这种单元 格。
应用数据模型表优选地在初始化步骤创建，并且每当特定应用、特 定应用组件或特定应用子组件开始或停止时根据预先确定的频率参数 在定期的基础上对该应用数据模型表进行更新。
现在转到图3,在此描绘了应用数据模型表300，其对应于企业应 用包的特定模块，即清单管理模块，其包括诸如清单管理模块、清单状 态事务、更新清单事务以及打印清单汇总事务之类的应用组件和子组
件。如上所述，应用数据模型表300的每一行， 一般地指代为305,包 括特定应用、特定应用组件或特定应用子组件的主要参数。应用数据模 型表300的每一列， 一般地指代为310，表征了应用所需的并且当前分 配给这些应用的特定资源。例如，行305-2包含清单状态事务的主要参 数，并且列310-1和310-2包含响应时间和优先级参数的值。特别地， 清单状态事务的实际响应时间等于0.9秒，而这一事务所需的最大响应 时间等于2秒，并且这一事务的优先级设置为高。同样，在优选实施例 中，将一列分配给专用系统并且该列包括与专用系统标识(ID )、它的 所请求的专用部分(Rqd)和它的所分配的专用部分(Act)相关的信息。
因而，每个应用组件由一组参数和一组对应的参数值来表征，这些 参数值确定了如下资源需求，其中针对应用组件而请求这些资源需求以 根据所定义的策略和规则来进行操作。例如，更新清单事务由参数"响 应时间，，和"优先级，，以及由对应的参数值"2秒，，和"低"来表征。 例如，此处是可以用于表征应用、应用组件或应用子组件的主要参数和 参数值或者策略和规则
*应用组件应用参数
-应用组件类型(例如，应用模块、事务族、商业事务和IT事务 (工作或任务)) -相关联的层级 -应用模块(例如清单管理)
-商业事务(例如清单状态和更新清单)；
-IT事务(例如与状态请求相关联的查询和与更新清单相 关联的提交)；
-事务类型(例如用户交互(对话)、批处理、更新、外部访问和 打印)
*应用组件策略和规则
-期望的响应时间(秒)；以及 -优先级(例如高、中或低)。
*应用组件资源需求参数
-所需的系统类型(例如相关联的操作系统、数据库和中间件)； 以及
-所需的资源中的工作负载特性(根据应用组件)，其中所需的资 源例如 -系统CPU(o/o); -所需的存储器(MB); -数据库表空间(MB); -所需的I/0带宽(MB/s); -不兹盘空间(GB);以及 -网络带宽(GB/s)。 这一应用组件结构使得能够调整表征组件的参数和相关联的所需 资源。应当注意，响应时间可以是真实地测量的响应时间或平均响应时 间(在预先确定的时间段上)。
层级结构还使得能够将ASIO引擎用于粒度级别，其将是模块化的 并且依赖于全局应用系统的大小和复杂度。它的实现可以是渐进的，从 最高级别(应用组件-模块类型级)开始，渐进地向下到达某个低级别 的组件，这对使用这一应用系统的商业来说可能是关键的。特别地，可 以根据用户请求或者在不能对应用组件的执行进行优化时更新应用数 据模型表。在该后一种情况下，有必要确定可以优化哪些应用子组件。
在附加的列中来进行。在这种情况下，通过确定可用资源的类型，该系 统能够确定可以优化哪些应用子组件，从而在应用数据模型表中针对这 些应用子组件创建新的条目。
图4示出了前面示例的层级和三个优化级别。如所描绘的，方框400 到方框415表示应用组件参数，并且方框420到方框430表示可能的优 化。更特别地，方框400包含名称为"清单管理"的应用工作负载组件
的主要参数。如所示，清单管理组件的主要参数是它的名称、工作负载 模式(参考所有的参数)、专用于这一应用组件的系统的名称(X)、实 际的和所请求的CPU平均使用率(分别是80%和60% )、实际的和所请
求的数据库緩冲池(每个100MB)、以及实际的和所需的响应时间(分 别是2.3秒和2秒)。方框405、方框410和方框415包含子事务简档， 也就是链接到父应用组件的应用组件的主要参数。特别地，方框405包 含应用组件的名称(清单状态)、它的类型(对话)、它的优先级(中)、 实际的和所需的CPU平均使用率(分别是30%和60% )、实际的和所请 求的响应时间(分别是1.4秒和1秒)。如果需要，可以根据上面通过参 考图1而描述的第一级、第二级或第三级优化来优化对每个应用组件的 执行。例如，可以根据包括提供和协调新资源的第三级优化来优化清单 管理组件(方框420)。同样，可以根据第二级优化来优化清单状态组件， 其中所述第二级优化包括在专用系统中进行例如工作负载管理、动态分 区调整或数据库优化。最后，可以根据第一级优化来优化更新清单组件 和打印清单组件，其中所述第 一级优化基本上包括对工作进行调度和区
分优先级。
回到图1，应用事务和系统资源分析器130在知识库125的预先确 定的频率参数给定的定期的基础上检查在该应用数据模型表300中定义 的每个应用组件的所分配的参数值。在另一个实施例中，这一预先确定 的频率参数依赖于应用组件的类型。将这些所分配的参数值存储在应用 数据模型表300内。同时，应用系统监视模块135将所请求的参数值与 存储在应用数据模型表300中的所分配的参数值进行比较。
如果所分配的参数值不属于所请求的参数值，则ASIO算法检查系 统，以根据在上面讨论的并在下面详细描述的三个级别的优化来优化该 系统。
*第一级优化(方框150):分析并管理应用组件 如果应用组件或子组件中之一 的响应时间或平均响应时间大于在 应用数据模型表300中确定的所请求的响应时间，并且如果相关联的专
用资源(如在示例中对应于清单管理模块的应用工作负载组件级上所 见)在应用数据模型表300中所定义的需求内，则ASIO算法将所有应 用组件和子组件的响应时间状态进行比较，以定义有多少应用组件具有
响应时间问题以及哪些应用组件具有响应时间问题并且需要来自ASIO 的动作。如果应用组件具有最低的优先级(如在知识库125中所定义的 的，例如高、中和低)，或者如果有需要更少资源的(根据优先级)应 用组件类型(降序，例如更新、对话、批处理和打印)正在运行，则 ASIO算法将延迟最低优先级应用组件的命令和需要更多CPU的应用组 件类型发送给应用调度和分区管理模块，以便得到更多的对故障应用组 件来说可用的资源。
如果在预先确定的监视周期之后的结果回到正常，则不需要进一步 的动作。这种预先确定的监视周期可以存储在例如知识库125中。如果 该结果在预先确定的监视周期之后仍然很差，或者如果实际的专用环境 资源状态不在所定义的需求内，则ASIO算法试图应用第二级优化。
*第二级优化(方框265 ):分析并管理专用资源 如果ASIO算法已经检测到具有比所请求的响应时间更大的响应时 间的应用组件或子组件，并且如果相关Jf关的专用系统具有^^于在应用数 据模型表300中定义的需求的全局CPU使用率，则ASIO算法开始分析 专用系统资源状态。
根据所确定的与专用系统相关的参数，其中这些参数与应用数据模 型表300中的应用组件相关联并且超出了在应用数据模型表300中定义 的使用率限制(对于已分区的系统CPU、存储器、I/O数据库存储池 大小、分页速率、磁盘I/0速率等等，这些参数依赖于专用系统类型和 操作系统)，ASIO算法标识别相对于在应用数据模型表300中定义的需 求来说过度利用的参数，并且使用诸如SNMP或CIM之类的标准协议 来向对应的专用资源的专用系统管理模块发送命令，请求附加的容量用
以分配给响应时间大于所请求的响应时间的应用组件。
如果若干参数超出了所定义的限制，则根据专用系统类型，由ASIO
算法利用在知识库125中定义的优先级(例如根据CPU、存储器、I/O
或DB緩冲池大小和分页速率)来进行重复的请求。
这种工作负载管理、动态分区和数据库优化功能的机制(根据专用 系统能力，并且如在系统组件描述中所定义的那样)用于从专用系统向 应用组件分配附加的资源。
如果在这些动作之后并且在预先确定的监视周期之后应用组件结 果回到正常，则不需要进一步的动作。在这些动作之后并且在预先确定 的监视周期之后如果结果仍然超出所定义的限制或者如果专用系统具
有超出所定义的需求的全局CPU使用率，则ASIO算法试图应用第三级优化。
*第三级优化(方框180):分析并管理全局资源池 如果ASIO算法已经检测到具有比所定义的限制更大的响应时间的 应用组件或子组件，以及如果专用系统具有超出所定义的需求的全局 CPU使用率，并且如果第 一级和第二级优化未能成功地使响应时间回到 正常，则ASIO算法分析全局服务器池状态并且通过提供和协调管理器 185来开始动作。通过将系统数据模型表200与应用数据模型表300进 行比较来确定全局服务器池状态，以确定可用的非专用资源，可以将这
根据需要附加资源的应用组件，提供和协调管理器185确定可以从 全局服务器池将哪一资源添加到应用专用资源。这种确定通过分析应用 数据模型表300来进行。
这一添加附加资源的操作可以包括若干步骤，诸如向服务器分配IP 地址、在数据中心中配置网络设备和负载均衡器、以及安装软件包。在 服务器中还需要软件补丁 。由于这些步骤是通过任意现有的提供和协调 模块185来进行的，所以不对它们进行详细描述。依赖于应用组件，可 以在一个或多个所需的步骤上使用由应用编辑器(ISV)开发的工作流。
根据ASIO算法的请求，所有这些操作由提供和协调管理器185来 管理。
根据在知识库125中所定义的内容，这一请求可能使得自动地将例 如服务器之类的附加资源提供给应用组件，或提供到对操作者操作的建 议中。
如果例如服务器之类的分配给应用组件(来自全局服务器池)的资 源的平均使用率低于所定义的限制(当最大应用组件工作负载时段结束
时)，则具有它自身的监视和执行的提供和协调管理器185还能够释放 (de-provision)这一月良务器。
如果在已经应用第三级优化之后所有的应用组件都回到正常，则不 需要其他的进一步动作，ASIO算法将消息发送到操作者控制台，汇总 了所采取的动作的状态，并且请求在全局系统上进行人工干扰，以使用
人类的经验和专门技术来最终完成对应用系统的分析和优化。
为了进行说明，前面描述的清单模块的示例可以在如下应用系统上 实现，该应用系统包括PeopleSoft应用包(PeopleSoft是Orace国际公 司的商标)、运行在例如IBM AIX (IBM和AIX是国际商业机器公司的 商标)之类的Unix服务器上的ERP模块、IBM存储磁盘和相关联的网 络作为专用系统，并且该应用系统使用DB2(DB2是国际商业机器公司 的商标)数据库管理器。由Intel刀片服务器(Intel是Intel公司的商标) 构成的附加服务器池在应用系统范围内也是可用的。第一级优化可以使 用PeopleSoft功能(工作调度机制)来实现，第二级优化可以使用与 Unk服务器(例如AIX5.3级)的工作负载管理器相关联的逻辑分区来 实现，并且第三级优化可以使用IBMTivoli提供和协调软件(Tivoli是 国际商业机器公司的商标)来实现。
通过使用本发明，所得到的应用系统智能优化器将实现
-更有效的优化，其中考虑了应用和基础设施参数，并且避免了对 于快速工作负载发展的错误的或緩慢的反应；
-应用系统管理的更低的成本，其中对监视、建模和优化阶段进行 组合，而不需要人工规划或操作者动作；
-应用基础设施的更低的全局成本，其中优化全局基础设施使用率 (减少客户所需的投资)；以及-更好的用户经验(对应用系统的更好的内部或外部用户感知)。 自然地，为了满足局部的特定需求，本领域普通技术人员可以将很 多修改和变更应用于以上描述的解决方案，但是所有这些修改和变更都 包括在如所附权利要求书所限定的本发明的保护范围内。
权利要求
1. 一种用于对在包括多个资源的计算机环境中执行至少一个应用组件进行优化的方法，一组所述多个资源专用于所述至少一个应用组件，所述方法包括以下步骤-在初始化阶段-创建系统数据模型表，其包括对所述多个资源的主要特征的描述；以及-创建应用数据模型表，其适合于存储对分配给所述至少一个应用组件的所述至少一个应用组件所需的资源、所述至少一个应用组件的响应时间、以及所述应用组件所需的响应时间的描述；-在运行时-收集分配给所述至少一个应用组件的资源的状态，并且将所述状态存储在所述应用数据模型表中；-收集所述至少一个应用组件的响应时间，并且将所述响应时间存储在所述应用数据模型表中；-将分配给所述至少一个应用组件的资源与所述至少一个应用组件所需的资源进行比较；-将所述至少一个应用组件的响应时间与所述至少一个应用组件所需的响应时间进行比较；以及-如果所述至少一个应用组件的响应时间大于所述至少一个应用组件所需的响应时间，如果所述专用资源的使用率在所述至少一个应用组件的资源需求内，并且如果至少一个第二应用组件正在运行，则如果所述至少一个第二应用组件的优先级低于所述至少一个应用组件的优先级或者如果所述至少一个第二应用组件比所述至少一个应用组件更耗费资源，就延迟对所述至少一个第二应用组件的执行；-否则，如果所述至少一个应用组件的响应时间大于所述至少一个应用组件所需的响应时间，并且如果所述专用资源的使用率低于所述至少一个应用组件的资源需求，则向所述至少一个应用组件分配更多的所述专用资源；-否则，如果所述至少一个应用组件的所述响应时间大于所述至少一个应用组件所需的响应时间，并且如果全部所述多个资源并非专用于所述至少一个应用组件，则向所述至少一个应用组件提供并非专用于所述至少一个应用组件的一部分所述多个资源。
2. 根据权利要求1所述的方法，进一步包括将在所述应用数据模型表定义的 分配给所有应用组件的资源与在所述系统数据模型表重定义的可用资源进行比较的步骤。
3. 根据权利要求1或权利要求2所述的方法，进一步包括在新资源 被添加到所述计算机环境时将对所述新资源的描述添加到所述系统数 据模型表中的步骤。
4. 根据前述权利要求中任一项所述的方法，进一步包括将对分配给 所述至少一个应用组件的子组件的所述子组件所需的资源、所述应用子 组件的响应时间、以及所述应用子组件所需的响应时间的描述添加到所 述应用数据才莫型表的步骤。
5. 根据权利要求4所述的方法，其中所述应用子组件是应用事务。
6. 根据权利要求4或权利要求5所述的方法，其中根据用户请求来 执行所述将对分配给所述至少一个应用组件的子组件的所述子组件所 需的资源、所述应用子组件的响应时间、以及所述应用子组件所需的响 应时间的描述添加到所述应用数据模型表的步骤。
7. 根据权利要求4或权利要求5所述的方法，其中当不能对执行所 述至少 一个应用组件进行优化时，执行所述将对分配给所述至少 一个应 用组件的子组件的所述子组件所需的资源、所述应用子组件的响应时 间、以及所述应用子组件所需的响应时间的描述添加到所述应用数据模 型表的步骤。
8. 根据前述权利要求中任一项所述的方法，其中对存储在所述应用 数据模型表中的资源的所述描述包括CPU信息。
9. 一种设备，包括适合于执行根据权利要求1到8中任一项所述的方法的每个步骤的装置。
10. —种计算机类可读介质，包括用于执行根据权利要求1到8中 任一项所述的方法的每个步骤的指令。
全文摘要
根据本发明，提供了一种管理系统，其定义并应用一组联合动作，该组联合动作根据从不同组件收集的输入数据的组合而产生，这些输入数据包括诸如工作负载和响应时间之类的应用数据以及诸如系统CPU、存储器和I/O之类的基础设施数据。通过在以下不同级别上按照从最简单到更复杂的逻辑顺序采取的动作，所收集的数据导致自优化的应用系统。第一级优化涉及诸如工作优先级和工作重组织之类的应用。第二级优化涉及在一组预定和分配的资源内的系统。第三级优化涉及全局体系结构，其中通过根据需要扩展从共享池分配给应用的资源并且将资源动态地添加到应用系统基础设施。
文档编号G06F9/48GK101390056SQ200680028974
公开日2009年3月18日 申请日期2006年4月28日 优先权日2005年8月8日
发明者F·布里昂, F·迪布瓦, P·德让, S·洛朗西 申请人:国际商业机器公司