在电信服务和/或网络管理平台中管理资源的方法、相应平台及其计算机程序产品

摘要

本发明涉及用于在电信服务和网络中管理资源的方法和系统。该方法和系统涉及由处理机器(H)上的分布式代理(A1、A2、A3)执行处理(WF1、……、WFn)，以执行在网络上的预定的任务，并且其特征在于：设置将由系统满足的包括关于处理(WF1、……、WFn)和资源使用约束的目标；监视计算代理的资源使用和处理执行，并且收集代表资源使用和处理执行的性能数据；比较所收集的性能数据与所设置的数据，当性能数据并未实现目标数据时，建立处罚；并且重新分配用于代理(A1、A2、A3)的处理执行的资源，从而使基于所述比较而确定的处罚最小化。

说明书

技术领域

本发明涉及一种用于管理旨在管理电信网络和/或服务的平台内的资源的方法。具体而言，本发明涉及一种用于在管理电信网络和/或服务的平台内分配资源的方法和相应的管理平台。

背景技术

在通信网络/服务领域内，提供包括多个组件的管理平台，所述多个组件例如为在分级架构上组织(有时基于代理)的操作支持系统(OSS)。

US 6243396公开了例如一种通信网络管理系统或平台，其具有控制电信网络资源的互连管理机构的多层分级架构。每个机构具有负责处理的执行的多个代理，它们可以是智能的或者简单的反应代理。

在该公知的架构中，反应代理位于该机构的平台部分内，智能代理位于该机构的控制部分内。将智能和反应代理分组到功能组件以将FCAPS(故障、配置、计费、性能、安全)功能提供给平台。

WO 01/02973教导使用包括集中式处理协调器的平台，所述协调器用于分布式代理的协调，通常利用运行工作流描述(类似于流程图)的工作流引擎来实现，所述工作流描述包括将作业委托给组件(代理)、从代理收集响应、等等。

申请人认为上述架构并未保证代理执行工作流引擎委托的作业。实际上，可用于代理的IT资源，例如计算能力，是有限的，不能保证IT资源足以满足对于平台的所请求商业目标或工作负载。

换句话说，可用于代理的IT资源可能阻止达到预定的商业目标，该商业目标要求由代理执行例如将服务递送给客户的任务。

例如，任务可以是在短于预先定义的持续时间的平均时间内完成预定的处理，或者在固定的期限内完成确定数量的处理。

代理的巨大工作负载可能妨碍代理在预先定义的平均时间或者在固定的期限内完成任务，因而导致无法达到商业目标。

在如WO 01/02973公开的使用集中式处理协调器的基于代理的架构中的另一个问题是协调器本身变成平台操作中的瓶颈，处于将工作流添加到协调器中以提高灵活性的代理外部的处理逻辑越多，协调器将变得越慢。这可能使处理商业性能目标(例如具有其执行期限的处理)的架构的能力恶化。

在IT资源管理领域中，美国专利申请第2003/0167270号公开了一种分布式环境中的资源管理系统，该系统包括多个主机，这些主机实例化(instantiate)可伸缩应用的拷贝。该资源管理系统基于关于应用的拷贝和主机性能的信息，生成启动、关机或者将可伸缩应用的选定拷贝在主机间移动的信号。

此种解决方案至少因为下述原因而并不非常适合于包括由处理协调器或工作流引擎协调的分布式代理架构的平台：

-在所有代理都已经执行某些任务的情况下，可能没有空闲代理用于紧急工作或应用的新执行；

-每次定义新工作流(即新功能)，为了满足商业目标(如商业处理的期限)，公知系统需要测量关于应用的参数和建立新模型以调整所有代理的新行为；

-公知的资源管理系统仅仅用于可被实例化为多个拷贝的应用或功能。

发明内容

因此，本发明的目的是提供一种对用于管理电信服务和/或网络的基于代理的平台的资源进行管理的方法，该方法通过在资源使用中实现最佳性能，以提高平台效率，从而实现预定的商业目标。

本发明的另一个目的是具有分散式处理逻辑从而在提高平台灵活性的同时实现其更佳性能的管理平台。

根据本发明，这些目的是通过一种对用于管理电信服务和/或网络的平台内的资源进行管理的方法以及通过具有在独立权利要求内提及的特征的管理平台来实现的。

本发明的其它目的是如权利要求所要求保护的用于建立和运行电信管理平台的计算机程序产品或计算机程序集合、电信网络和方法。

总之，为了克服现有技术的缺点，本发明公开了一种基于由预定的指示器(如商业密钥指示器)和目标驱动的预测和适应机制的方法和相应平台，其用于测量和自动控制在管理平台中的IT资源使用。

优选地，根据本发明的平台的架构特征是：

-在代理内提供处理(工作流和规则)引擎，用于实施由所述代理提供的所有功能，以使得代理必须运行的作业成为工作流执行。可以将规则引擎耦合到工作流引擎以执行某些类型的作业。

-提供集中式处理描述数据库用于定义和存储处理描述，并用于将这些描述分给代理。

-提供目标和约束控制台，其允许包括商业目标(如SLA，服务层级协议)的目标数据的指定，和基于功能定义及其集合(如集合到像实现、保证、计费这样的商业处理领域)的处理优先级；

-提供控制代理，其被安排为用于监视在平台的每个代理内的每个处理执行对IT资源的使用，以及由商业处理对工作流的执行，即例如用于监视已过时间、执行频率等等；并

-提供资源分配模块，其被安排为用于基于指定的目标数据(商业目标)和所监视的代表资源使用的性能数据，以自适应方式将IT资源重新分配给平台的每个代理，从而提供最大层级的商业目标实现。

有利地，根据本发明的优选实施例，提供重新分配器控制台作为图形用户界面来定义资源重新分配规则，并提供监视控制台，该监视控制台允许对SLA实现趋势和相应IT资源使用及相关代价进行控制。

在代理内提供处理引擎被证明对于代理间IT资源的动态分配是有利的特征，使得提高了灵活性同时未引入瓶颈，当所有引擎都放置在集中式处理协调器内时就是如此。代理内部的处理引擎允许对于每个功能执行(即，处理执行)分析地测量代理内的资源使用(例如，所使用的CPU时间或RAM)。

将在集中式数据库内的处理描述跨越平台分发给每个代理以在它们的处理引擎内使用，从而实现与平台的全部操作功能的自动同步，以便可以调整与作业语义一起运行的资源管理过程。

实际上，用于管理电信服务和网络的平台的管理员可以建立任何FCAPS(故障、配置、计费、性能和安全)功能，该功能在处理数据库中定义一个或多个工作流和/或规则或者组合现有的多个工作流和/或规则；随后代理自动地获取新处理(工作流和规则)定义并在需要时运行它们。目标控制台自动地允许对于新处理定义SLA和优先级。在运行时间，控制代理允许对于新处理控制SLA趋势和相应IT资源使用，以便重新分配器模块可以优化整体配置，即，改变代理处的工作流优先级或者向该代理提供更多的计算资源(CPU、存储器等等)。

根据本发明的资源管理优选地是在平台中由集中式模块(管理器模块)和分布式模块(控制代理)一起实现的。集中式和分布式功能的组合是该方案的自适应机制的基础。

附图说明

在以下描述中将更详细地解释本发明的其它特征和优点，通过参考附图以非限制示例的方式提供所述描述，在附图中：

图1是表示根据本发明的用于管理电信网络的服务的系统或平台的架构的方框图；

图2是表示图1的管理器模块的内部结构的方框图；

图3是表示图1的具有代理模块和控制代理的主机的内部结构的方框图；

图4是表示根据另选实施例的代理模块的内部结构的方框图；

图5是根据本发明的资源管理方法的流程图；

图6是包含根据本发明的系统的三层服务规定场景的示意图；和

图7是表示在图6的服务规定场景中的多层工作流的图。

具体实施方式

图1表示根据本发明的用于管理电信服务和网络的系统的示例架构。该系统优选地在包括多个处理主机H的分布式处理架构上实现，每个主机H可以包括一个或多个软件代理(A1，A2，A3)。

系统(或平台)包括集中式控制模块或管理器模块MM，该集中式控制模块或管理器模块MM包括在主机上运行并与用于各种协调动作的分布式代理交互的程序或程序组，所述协调动作例如为处理描述的分发、操作的调用、管理控制等等。管理器模块MM还可以优选地包括用于与诸如系统管理员的用户交互的图形用户界面。

在该说明书中，术语处理用于代表一个或多个工作流、一个或多个规则、或者优选地一个或多个工作流和一个或多个规则的组合。

可以将工作流定义为商业过程的自动化，在该过程中，根据一组程序规则，将信息或任务从一个代理传送给另一个代理以进行动作。

通过具有一系列任务以及任务之间的时间和逻辑依赖性的、包括多个另外的或并行的分支的流程图来代表该工作流。存在像XPDL(XML处理描述语言)这样的专门(ad hoc)语言来格式化工作流描述。

规则是声明当发生一组特定条件/事件时必须执行哪些动作。

管理器模块MM包括处理描述数据库PDB，其被安排为存储代表平台的行为和功能方面的所有处理，即，工作流和规则。

数据库PDB还包括例如由工作流和规则处理的数据模型。

处理描述数据库PDB例如可以与本领域普通技术人员公知的任何常规网络存货清单系统的目录部分相关联。

图1的架构包括多个多层代理模块，作为示例示出分别包括某些代理A1、A2、A3的三层。属于同一层级的代理可以相互连接或者可以相互独立。如果可能，将它们耦合到更高层级的代理。在较低层级处，将代理耦合到受控的网络单元(通常表示为通信网络N)，例如耦合到ATM交换机、或者耦合到其它服务应用APP，如邮件服务器应用或者VAS服务器应用，即，诸如移动电话应答机服务的增值业务应用。

管理器模块MM本身例如通过通信总线B连接到平台的其它操作支持系统OSS。

用作协调器的一主机代理MA或根据实施类型的多个主机代理MA(在图1中未公开)被提供在多层代理架构的根部，与管理器模块MM相关联。

每个代理A1、A2和A3包括处理引擎PE，并且负责使用处理引擎PE执行一些处理。

处理引擎是执行工作流和/或规则的软件模块。

处理引擎PE有利地嵌入每个代理内，因为处理引擎的外部位置将意味着具有可能导致性能恶化的远程调用。

优选地，每个代理的处理可以由具有相同层级或更高层级的其它代理外部地调用，并对应于每个代理提供给调用代理的服务。

用于任一层的处理引擎将是例如工作流和能够相应地管理工作流和规则的规则引擎的组合。例如，最好将规定处理表示为工作流，而最好将告警相关性表示为规则的组合。在可能的时候，使用工作流是优选的，因为它并不涉及处理规则冲突和规则管理的复杂性。

图1所示的多层架构允许在不同层级中的处理的分段。对于可以安排代理的层级数量不存在限制。这样，可以建立该架构，从而在具有最低的可能层数和允许在分布式与集中式组织之间的处理的自由分配之间的折衷。这一分段还使得能够提供不同的服务观点，从商业观点到系统观点。

在下文中，将工作流引擎视为优选的，但是也可以应用规则引擎。

运行代理(主代理和子层级代理)的每个主机优选地包括一个或多个控制代理CA。它们是负责对资源使用和本地代理(即在主机上运行的代理)的性能进行测量以及执行资源管理的本地优化的模块。控制代理CA耦合到管理器模块和其它控制代理，并将测量数据发送给管理器模块和/或其它控制代理。

管理器模块MM(其架构将随后描述)负责平台的管理、配置和控制。其被安排为用于分析来自人工操作员和外部OSS的输入数据，并确定如何调整平台配置以符合商业性能目标。其主要任务如下：

将来自处理数据(PDB)的处理描述和数据模型分发给代理；

利用控制代理提供的信息监视平台状态，该信息包括在主机上代理的分发、域管理(在代理之间的整个网络的划分)、性能监视；

由代理通过与相关控制代理的交互而执行动作以最佳地使用对于处理执行而分配的资源；这些动作的示例是修改在代理之间的负载平衡和工作流优先级的改变，即，重新调度在一个或多个代理内的排队作业；

与外部系统的交互，如其它操作支持系统。

主代理MA，其架构随后将要描述，负责处理执行的最高层级协调。实际上，顶层的代理负责的处理可能涉及子层代理负责的子处理。而且，存在特征在于提供需要与外部实体(除了代理之外)的交互或者代理之间的协调的功能，而所述与外部实体(除了代理之外)的交互或者代理之间的协调不能轻易地或有效地以分布式方式由低层代理执行。将由代理执行的处理是必需以分布式方式执行的那些处理。

每个代理(A1、A2、A3)可以支持任何网络和服务管理功能(即处理)，如FCAPS(故障、配置、计费、性能、安全)功能。这使得能够基于任务优先级和资源需要来进行代理的运行时间任务定制和代理的功能重新分配，例如在日间将更多代理专用于服务提供而在夜间将更多代理专用于网络优化。

在代理中提供处理引擎PE使得能够监视由每个功能(即处理)执行对资源的使用以及功能调用的发生。这些数据是用于由管理器模块MM操作的自动平台控制的主要信息源。

每个代理(A1、A2、A3)表现出反应和前摄(proactive)行为，因事件而触发并且提高处理的自发启动。

优选地，代理模块可以由控制代理或管理器模块在处理机之间移动以便于更轻易的部署，例如实现容错。

图2表示根据本发明优选实施例的管理器模块MM的内部结构。

例如在子模块内组织集中式管理器模块MM。

子模块之一是MNG_CNS控制台，通常表示为管理控制台MNG_CNS；在优选实施例中，管理控制台MNG_CNS包括：

-具有保持平台性能数据的相关性能数据库PFM_DB的监视控制台MC；

-目标和约束控制台GC；

-重新分配器控制台RC；

-管理控制台AC，具有包括由管理控制台管理的管理数据的相关管理数据库ADB；和

-服务创建环境控制台SCC，

以致于

-容量规划模块(未表示)；和

-预测控制台(未表示)。

目标控制台GC、管理控制台AC和服务创建控制台SCC全部耦合到处理描述数据库PDB。

管理器模块MM包括直接耦合到目标和约束控制台GC和重新分配器控制台RC的资源分配器RA。

资源分配器RA还例如耦合到管理数据库ADB以及保持平台性能数据的性能数据库PFM_DB。

在优选实施例中，管理器模块MM还包括监视数据获取模块MDM和平台控制器PC。

监视数据获取模块MDM被安排为用于将性能数据从平台控制器PC传送给性能数据库PFM_DB。

此外，例如，资源分配器可以耦合到外部接口模块I，用于监视在外部OSS和管理平台之间的交互。

平台控制器PC通常作为在管理器模块和代理之间的媒介而运行。

具体而言，平台控制器PC实现与管理器模块外部的主代理MA(未表示)的连接和与资源分配器模块RA的连接，并与监视控制台MC、监视数据获取模块MDM、管理控制台AC和管理数据库ADB相耦合，从而与处理描述数据库PDB相耦合。

目标和约束控制台GC旨在定义与存储在处理描述数据库PDB中的处理相关联的商业目标(如服务层级协议或SLA)和约束，统称为目标数据。

服务层级协议或SLA是(契约化或简单同意的)商业处理层级质量的量化。SLA基于性能指示符(平均执行时间、百分点或其它)并声明要在平台上保证的用于这些指示符的值。通常，可以通过专用语言(“语法”)描述SLA，所述专用语言标识SLA目标(性能指示符)和SLA罚则(基于在SLA目标和所收集的性能数据之间比较的SLA代价函数)，例如违反SLA的经济处罚的估计。

可以将SLA关联到普通商业处理(如工作流)或者(可以一个或多个工作流属性标识的)其规范之一，其中用于规范的SLA通常重写根部商业处理，如果存在的话。

约束涉及资源使用相关数据。它们最好包括：

-在将要保证的最低吞吐量和可管理网络单元的最小数量方面表示的预分配资源(最好使用术语“吞吐量”替代使用百分比，以使用更容易理解的商业量度)；

-可分配资源的最大数量(用代价或全局资源的百分比表示，例如缺省值可以是50％)。

如果修改商业约束，则需要检查以验证预分配资源是否超过最大可分配功率。

根据本发明的优选实施例，资源分配器RA(下文中的重新分配器)是集中式的，并管理将资源分配给代理，从而自适应地控制平台。其被安排为接收例如：

(i)来自目标控制台GC的商业目标；

(ii)监视每个主机的性能数据(如执行时间)和硬件资源使用，从性能数据库PFM_DB获取这些数据；

(iii)可选地，来自负载测试的信息，即，与对于较重的工作流使用的资源使用有关的测量；

(iv)关于可用主机及其硬件特征的数据(标准化的CPU速度，例如由标准性能评估公司使用SPECINT2000速度)；这是监视整体处理能力(例如以参考CPU的每小时秒数测量的)；

(v)每个主机的硬件资源使用(来自性能数据库PFM_DB)。

重新分配器RA优选地包括两个子模块：评估模块和确定模块，在下文中将提供其示例性描述和功能。

评估模块被安排为接收关于以下内容的数据：

-最高层级(MA)工作流执行请求；和

-在所有代理内的工作流执行请求队列。

而且，评估模块被安排为分析过去工作流执行请求的历史趋势和在单元和复杂性方面的所管理通信网络的趋势。

确定模块被安排为根据先前信息确定该平台是否能够根据随后将要描述的某些准则来处理所有请求。

如果该平台不能管理所有请求，则确定模块例如被安排为发送告警消息并确定哪一动作可以改善情况。具体而言，如果资源足够，但是不完全符合SLA，则确定模块被安排为在平台间重新分配处理(即工作流执行)。优选地，这些动作处理与工作流的不同实例相关的约束和优先级。

管理控制台AC旨在定义和监视例如至少一组下述内容：

i)该平台(即承载用于由所分发代理执行处理的处理能力的主机H)的硬件配置；例如，当将新主机添加到主机预先定义组时，将其自动地加入到整个平台，如因为主机通知其存在，或者可替代地，管理控制台通过接收由操作员例如通过其GUI输入的命令，来识别该主机H；

ii)用于定义软件分布/分配的GUI(即，在目标和约束控制台GC内接收约束相关数据的接口)。具体而言，该GUI例如用于根据下述内容来设置主机组：

-地理约束(例如仅可以在一个区域而不能在另一个区域内安装的代理上执行某些工作流，或者可以仅在特定主机上执行它们)；

-分级约束(例如，在特定机器上仅可以运行秒级工作流)；

-服务约束(即，对于特定处理类型的约束)；

iii)工作流调度表(例如，仅在早晨时间内调度服务规定工作流)。

重新分配器控制台RC被安排为用于定义资源重新分配策略，即指示何时和如何重新分配资源，以根据商业约束和所监视的数据来优化商业目标满意度。重新分配器控制台允许输入同时用于集中式和分布式控制的策略。具体而言，它允许定义：

i)用于集中式控制的规则，定义何时和如何作用于工作流优先级，以达到SLA满意度的最佳可能层级；这些规则在所管理的平台上视为整体(即它们并不直接作用于机器)，并基于所有的资源分配器模块输入数据和预测数据而工作；

ii)用于分布式控制的规则，借助于优化本地软件和硬件资源的目的而通过相关CA(线程平行和本地平衡)作用于单个代理；

iii)计算在规则内涉及的复杂表达式的函数。

监视控制台MC被安排来测览监视信息，如：

i)平均每小时吞吐量(如每日)、在队列内的请求数量(如每日)、平均执行时间(如每日)、已经设置了目标的每个商业交易的期限；

ii)在SLA指示符的协议值和测量值之间的差值和相关代价函数的评估方面，在抽样间隔时间上计算出的SLA(突出违反的多个)的情况；

iii)用于每个工作流的硬件资源使用，例如CPU使用和/或使用的RAM的秒数(对于单个层级或者对于低于其的每个层级)方面；当每个主机具有不同于其它主机的计算能力时，将硬件资源使用，例如CPU使用，标准化成参考CPU；

iv)计费信息：由每个工作流使用的资源(在全部资源中的百分数方面和代价方面)。

监视控制台MC能够以分级方式浏览工作流的性能和资源使用(具体而言，每块工作流)。对于每个SLA，可以发布关于由于资源的重度使用导致哪些工作流值得优化的报告。如果在不同层级的工作流上设置其它测量点，则这些测量点也可以呈现在MC上。此外，MC在由工作流使用的资源方面显示关于计费的信息。

服务创建环境控制台SCC被安排为用于定义、创建和修改在PDB内的处理，因而定义、创建和修改在管理平台内提供的每个商业功能。其基于图形接口以便于执行此任务。该控制台还允许在工作流上插入新的监视点。

在又一实施例中，通过给MM模块添加预测控制台和容量规划模块，还使用由MM模块管理的数据来实现有用的容量规划。

预测控制台被安排为设置使用预测，从而实现有用的容量规划活动。该控制台的输入是：

i)预期吞吐量；和

ii)网络主机的预期数量和类型(可将此图计算为数据在处理描述数据库内的投影)。

容量规划模块被安排为保证在时间上的硬件资源。它被安排为接收来自预测控制台和其它控制台(目标和约束控制台、管理控制台和重新分配器控制台)的输入并验证资源的可用性。如果资源不足够，则容量规划模块被安排为向控制台操作员警告对于满足预期增加趋势所需要的硬件量。该模块将其分析基于包括至少下述之一的一组参数：

i)预期吞吐量(在历史趋势方面)；

ii)每个工作流(尤其是第一层级工作流)的资源使用信息；

iii)地理约束。

因为容量规划模块基于不确定的数据(尤其是长期数据)，其被安排为主要用于信息目的。它可以强调未来需要，但是它优选地并不与资源分配器RA交互。

图3表示包括代理模块A和控制代理CA的主机的内部结构的示例，所述控制代理CA负责主机的整体性能和在主机上运行的所有代理的控制。

每个代理A包括至少一组下述组件：

-工作流队列或队列WFQ；它是多层级优先级队列，其中每个子队列保持具有相同优先级的请求。将发送给代理的每个工作流请求基于其优先级插入相应的子队列内。在图3中将不同的工作流表示为WF1、......WFn。为了避免在子队列中工作流请求的资源缺乏，队列WFQ例如基于超时准则，为子队列内的请求执行优先级升级。与队列WFQ相关的，存在队列WFQ的相关信息，尤其是：

估计的CPU消耗时间，将对于每种类型工作流而测量的队列中的工作流的CPU消耗时间(这些数据从PFM_DB获得)相加而计算出的；和

请求输入速率，其统计地估计请求由另一个代理(请求在代理内排队)执行的特定类型工作流的速率(例如工作流/小时)。

-与工作流队列WFQ相关联的工作流调度器WFS：其被安排为用于根据其优先级来调度在队列内包含的工作流WFn。每次代理的一个或多个处理引擎准备执行工作流时，调度器将队列中较高优先级的工作流发送给等待处理引擎线程之一。

-由工作流调度器WFS控制的多个处理引擎线程TH1、......、THn；每个代理能够同时运行可配置数量的工作流。这通过在代理中配置多个处理引擎线程TH1、......、THn(独立执行器)来实现。每个处理引擎线程TH1、......、THn能够一次执行一个工作流，如，用java语言实现的线程。

控制代理CA包括至少一组下述组件，优选地以软件实现：

-资源监视器RM：该组件被安排为用于监视并收集在其控制下的代理中的硬件和软件资源使用的相关数据。其任务是测量在包括代理(代理主机)的主机上的当前资源使用和由于工作流执行而实现的CPU和存储器消耗。将测量值同时发送给管理器模块MM和线程控制器TC；

-线程控制器TC：其耦合到资源监视器RM和工作流队列WFQ，被安排为用于本地性能控制。其目标在于有效地管理代理线程的并行化。其被安排为作为输入接收在队列内等待执行的工作流数量、CPU使用和正在执行的机器PE线程的总数量。根据上述输入，线程控制器TC增加或减少处理引擎线程(PE线程)的数量，以实现最佳工作流执行并行化。例如，它创建新的PE线程，如果该队列包含等待被执行的工作流，如果PE线程的总量低于允许的最大数量，并且如果CPU使用低于规定的阈值。如果该代理负责与外部资源(例如设备、网络装置、等)的直接交互，但是PE线程的最大许可数量受可允许的同时外部资源的限制。而且，当线程控制器检测到某些PE线程在定义的时间周期内不被使用时，线程控制器运行PE线程的垃圾收集器。

-耦合到处理引擎线程的调度器：该组件被安排为用于将工作流执行请求发送给其它代理。每个PE线程使用调度器D发送这样一个请求。

调度器使用例如如下的负载平衡算法将请求发送给其它代理。它选择最佳代理在两个步骤中发送请求。

首先，它选择在CPU和存储器方面最低负载的主机。其次，它根据代理队列的估计CPU消耗时间的最小量来选择选定主机的可用代理。

另外，控制代理CA优选地具有根据优选实施例的重要特征。它们能够主动地管理其处理线程的并行化(本地优化)。将队列重新排序和并行化管理的这两个能力联合在一起是根据本发明一个方面的自适应机制的基础。

根据本发明的替代实施例，如图4所示，可以将资源监视器RM、线程控制器TC和调度器D附加到代理模块，例如如果在主机H上存在单个代理模块A。

使用用于实施具有移动性特征的代理的JADE(Java代理开发框架)、用于处理定义的XPDL(XML处理定义语言)和例如Shark的XPDL工作流引擎，来实施本发明系统的优选实施例。

在下文中，提供资源分配器模块的更详细的描述，目的在于说明其操作。

可以将重新分配器RA实施为带有约束处理、数据处理和配置改变功能的基于专家规则的系统。来自所管理网络的所有数据、约束和规则，外部系统，人类知识和内部分析构成其知识基础，这本质上可以用相关知识数据库表示。

重新分配器模块RA以预定的分析间隔上执行评估和确定模块，所述预定的分析间隔可以根据场景情况而逐情况地设置。

首先，重新分配器通过总线B获取来自外部系统的处理请求相关数据，从而评估对于随后的时间间隔而预测的服务/功能请求的数量，并将此信息保存在相关知识数据库内。

随后，确定模块启动资源重新分配规则，从而发现将要执行的动作以通过最佳方式实现预定的商业目的。

详细地说，在每个间隔T上，资源分配器模块基于历史基础考虑排队请求的数量和预测请求的数量。它执行可用硬件资源(主要是CPU和RAM)量的第一次评估。可以使用在间隔结束时的实际测量数据，考虑随后将要描述的“背景错误校正”，来调整这些数据。

以统计方式收集下述数据：

-在每个层级上每个工作流的CPU需求；和

-在子工作流请求方面的最高层级工作流组成(以及与架构的每个层级相关联的CPU需求；此信息还必需考虑地理约束，如果存在的话)。

使所收集的信息与在时间t时队列的长度和组成关联，并与在间隔[t，t+T]期间(通过预测)预期的请求数量关联，以计算对于随后间隔的CPU功率的总请求，将作为包括位于多个间隔之后的一随后间隔或一组间隔的集合。

随后，将CPU总量，即对于新间隔的所请求计算功率(考虑层级和地理约束)，与可用的CPU功率进行比较。如果不够，则生成对于控制台的告警(请求新硬件)，工作流的优先级将确定如何处理负载。

如果考虑“背景错误校正”以调整可用硬件资源的相关数据，则在每个间隔上，对于每个工作流和每个主机，比较在先前间隔期间使用的CPU量与由不同工作流使用的CPU量。在随后的间隔期间，使用这个数值来“校正”CPU的实际可用性。

根据本发明的方法和系统使用基于优先级的策略，由此存在不同层级的优先级。在每个间隔T上，确定模块根据管理算法可以使用优先级队列来实现商业目的。为了避免资源缺乏，如果工作流请求在低优先级队列中花费过多时间，则自动地更新其优先级，以便将该请求移动到更高优先级的队列。

根据本发明优选实施例的管理算法基于用于改进在每个步骤中的资源配置和用于努力利用递增行为达到最佳配置的自适应解决方案。通过使用分析间隔来保证本方法的结果，所述分析间隔是平均工作流执行时间的至少两倍或三倍(合理间隔将取决于应用场景，并可以从5分钟改变成1小时或更长)。

考虑到以下因素，优先级与工作流的每次执行相关联：

-同意的SLA的情况(风险越大的工作流将保持越高的加权)；

-在用于工作流的目标控制台内定义的初始优先级，以致于每个SLA的优先级和经济暗示；

-用于工作流的最小预先分配资源的数量；和

-(在SLA初始协商过程中定义的)最大可分配资源的数量。

这意味着优先级是取决于时间的。如果工作流性能的实例正在接近SLA(即其性能在降低)，则将其优先级设置得越高。

代替处理引擎，可以使用用于定义和测量功能执行的任何装置，例如利用统计技术的CPU估计。

在下文中，示出基于推荐架构的性能自适应情况的示例。将要优化的资源是CPU负载。

根据该情况，最高层级工作流是与特征在于优先级属性的SLA相关联的服务，所述优先级属性以在时间t＞＞ΔT内将要完成的工作流百分比来表示，其中ΔT是观察时间间隔。需要最后一个假定从而给予平台足够的时间来在周期t内重新校准。

最高层级工作流是许多子工作流的组成。所有工作流具有影响在执行之前的其队列等待时间和工作流CPU时间片的优先级属性。

输入数据是：

-用于每个工作流和每个主机的CPU负载[秒]；

-约束，即相同工作流仅可以对于一个主机子集运行；

-在子工作流方面的第一层级工作流组成；

-在过去的ΔT时间段内抵达的工作流数量；和

-在过去的ΔT时间段内的工作流执行数量。

目标是：

-预测计算资源是否足以执行在下一ΔT间隔内的所有工作流执行；

-预测计算资源是否足以符合SLA；和

-工作流执行优先级的自适应，从而实现SLA兼容。

性能自适应处理基于每个ΔT时间间隔执行的监视，所述ΔT时间间隔表示最小平台自适应时间。

参考图5的流程图，其报告每ΔT时间间隔执行的监视的示例，对于每个ΔT，由资源分配器RA管理下述步骤：

1)评估在每个主机上每个工作流的CPU负载(步骤100)。这应当通过在样机主机上执行负载测试工作流和使用CPU文件编制(documentation)(先验预测)来实现。考虑对于工作流执行的约束，使用与在前一ΔT内执行的每个工作流相关联的实际CPU时间，可以精确地调整所获得的值；

2)预测用于执行在队列内仍然等待的工作流以及根据预测将在下一个ΔT内到达的工作流所需要的CPU时间(步骤120)；

3)比较(步骤140)在步骤120中估计的CPU时间与可用CPU时间，以识别在计算资源方面临界的主机群，并据此识别与受影响的SLA相关联的第一工作流；在所需要的CPU资源大于可用CPU资源的情况下，通知低CPU资源(步骤150)。

4)对于每个SLA，预测(步骤160)执行最低数量工作流以符合SLA需求所需要的CPU时间，随后比较(步骤170)其与可用CPU时间以确定计算资源是否足以符合SLA；

5)如果前一步骤说明在运行工作流内的当前平台优先级配置不能承载SLA约束，则必需利用工作流优先级的重新平衡(考虑在计算资源方面的工作流加权)，通过工作流优先级自适应方法调整该配置(步骤180)；

6)当不需要优先级自适应，或者已经执行了优先级自适应时，该系统结束性能自适应处理并等待下一个ΔT监视间隔。

在下文中详细描述性能自适应处理的预测方法的示例。进行下述定义：

-ΔT：监视间隔和最小系统自适应时间；

-L_wf(n)：在主机n上用于工作流wf执行的CPU负载[秒]。可以先验(或者使用自学习方法)估计这些值，随后在平台操作过程中对这些值进行调整。例如，利用随时间变化的移动平均值。

-V_wf(n)：由下式给出对主机n上的工作流wf的约束：

对于执行在下一个ΔT内预测的所有工作流所需的CPU时间的预测被如下计算：