使用动作中心方案来提供对网络化系统的自主管理的系统和方法

摘要

根据本发明，提供了一种存储区域网络管理系统，用于利用动作中心方案来提供存储系统的自主管理。该存储区域网络管理系统包括策略规定逻辑块(26)，以保持与被管理系统相关联的策略规定。此外，该存储区域网络管理系统包括推理逻辑块，以利用逻辑和从策略规定中获得的信息的组合来确定动作规则。此外，存储区域网络管理系统包括学习逻辑块(30)，以耦合策略规定逻辑块(26)与推理逻辑块(30)，从而改善对于被管理系统的了解。该学习是连续的，提供了系统的自主演化，其中在该系统中对于用户手动输入的依赖性得以减轻。

说明书

技术领域

本发明涉及网络化系统管理领域，更具体而言，涉及一种用于提供网络化系统的自主管理的系统和方法。

背景技术

复杂性和易损性(brittleness)是存储系统内的运行时行为管理方面的现有问题。复杂性源自规定策略所需的细节的级别。这些细节是不可忽视的，并且需要对于系统内部的完全了解和熟悉。更准确地说，管理员和系统构建者难以进行如下操作：从一大组可观察量(observable)中选择要观察的系统参数的组合；在考虑到一大组系统变量的交互之后确定适当的阈值；以及从这样一大组竞争选项中选择出特定校正动作。随着用户、存储设备、存储管理动作以及服务级别协议(service level agreement)的数量的增加，对于系统管理员和存储管理工具开发者而言，考虑所有可能情况将使计算变得很费劲。

关于易损性，供应商难以在他们的产品内提供预先整装(pre-packaged)的转换代码，这是因为该代码相对于系统结构、用户工作量以及部门/商业限制的变化而言，是易损的。因此，由于存储管理的供应商难以提前预料到所有可能的使用情况，因此，许多当前存储管理解决方案提供工作流环境，这些工作流环境继而把转换高级别服务质量(QoS)目标的任务(经由工作流脚本)转嫁给组织的系统管理员和基础结构设计者。

本发明旨在提供存储系统中的自主管理，其中解决了与复杂性和易损性相关联的问题。

发明内容

根据本发明，提供了一种网络管理系统，用于使用动作中心(action-centric)方案来提供网络化系统的自主管理。该网络管理系统包括策略规定(policy specification)逻辑块，以保持与被管理系统相关联的策略规定。此外，该网络管理系统包括推理(reasoning)逻辑块，用于利用逻辑和从策略规定中获得的信息的组合来确定动作规则。此外，网络管理系统包括学习(learning)逻辑块，以耦合策略规定逻辑块和推理逻辑块，从而改善对于被管理系统的了解。该学习是连续的并且用于系统的自主演化(evolvement)，其中减轻了对于用户手动输入的依赖性。

附图说明

图1是根据本发明的一个示例性实施例的系统模型的框图，其中提供了使用动作中心方案的存储系统自主管理。

图2是根据本发明的一个示例性实施例的包含在系统管理器内的逻辑块的框图，其中系统管理器用来动态管理计算机系统的行为。

图3是根据本发明的一个示例性实施例，在系统管理器内执行推理的方法。

图4例示了N维行为空间。

图5示出基于Blackwell定理的矢量加法，其中利用基于Blackwell定理的递归算法来组合矢量。

图6是根据本发明的一个示例性实施例的系统管理器以及与其功能模块(functionality)的交互作用的框图。

图7例示了根据本发明的一个示例性实施例，执行用于在被管理系统中进行规定、推理以及自学的动作中心方案的方法。

具体实施方式

本发明主要说明了一种使用动作中心方案在存储系统中提供自主管理的系统和方法。在下面的描述中，为了说明的目的，提出了许多特定细节，以便充分理解本发明。然而，对于本领域技术人员显而易见，没有这些特定细节也可以实现本发明。

本领域技术人员应认识到，一种诸如数据处理系统的、包括CPU、内存、I/O、程序存储器、连接总线以及其它适当组件的设备可以被编程或者被设计为便于实现本发明。这样的系统包括用于执行本发明的操作的适当程序部分。

一种制造品，例如预记录盘或者其它的、通过数据处理系统使用的类似计算机程序产品，可以包括存储介质和其上所记录的用于指示该数据处理系统以便实现本发明方法的程序部分。这种设备和制造品也落在本发明的精神和范围内。

图1例示了根据本发明的一个示例性实施例的系统模型10，用于利用动作中心方案来提供存储系统12的自主管理。

系统模型10包括系统管理器14。系统管理器14用于根据管理员所规定的目标调整被管理系统12。

被管理系统12包括一组资源<R>16，其用来服务于来自应用的请求。资源16的示例包括处理器、网络、内存以及存储器。此外，被管理系统12还包括一组可观察量<O>18。这组可观察量<O>18代表对于应用而言可视的被管理系统12的特性(例如，吞吐量、等待时间、可靠性、可用性、安全性)。被管理系统12的目标被表示为<R>16或者<O>18的值的阈值。

对于被管理系统12的进入请求(incoming requests)的流可以沿多个维度(dimension)来表征。例如，在存储系统中，典型的维度是读/写比率、访问模式(顺序/随机)、请求的块大小，等等。在示例性实施例中，获取沿不同维度的信息(例如，请求的块大小，等等)来确定进入流的工作量特性<W>。

为了实现与被管理系统12相关联的目标，由于从监测器22接收了状态信息(例如，工作量特性、来自资源16的资源信息、来自可观察量18的可观察量信息，等等)，所以系统管理器14在被管理系统12内或者调用服务或者调整结构参数。服务调用和参数变化限定了被管理系统12可以执行的该组适应(adaptive)动作<A>20。

在示例性实施例中，动作<A>20是第一级实体。它们对行为维度(包括资源16和可观察量18)有影响。动作的定量效果依赖于被管理系统12内的当前工作量特性、资源利用级别和可观察量。动作20具有良好定义并标准化的功能(基于存储网络工业协会的存储管理计划标准(SMI-S))。

图2是根据本发明的一个示例性实施例的包含在系统管理器14内的逻辑块的框图24。框图24包括策略规定逻辑26、推理逻辑28以及学习逻辑30。

策略规定

策略规定逻辑26保持与被管理系统12相关联的策略规定。策略规定可以由多个策略组成。根据本发明的一个示例性实施例，由策略规定逻辑26保持的策略规定将动作作为软件对象，并且管理员简单地定义动作的特性(而不是现有方案的复杂的“how to”细目)。

策略规定逻辑26提供了动作中心(相对于事件中心(event-centric)而言)方案，其中动作20被表示为软件对象。现有方案是“事件中心”的，其中策略定义不同状态下的系统行为。该策略规定定义这些对象的属性，也就是校正动作的特性。该策略规定没有定义当不满足目标时被管理系统12应当如何反应。动作20的特性被定义，并且通过推理，系统管理器14动态地(on-the-fly)导出准确行为。就动作调用的成本/有益效果而言，这些特性是简单的、说明性的、以及非易损的。

在一个示例性实施例中，动作20的属性分为两个类别，包括元属性(meta attribute)和基本属性(base attribute)。

元属性

元属性使得系统管理器14可以对选择动作时所涉及的权衡(tradeoff)进行推理，决定要调用动作20中的多个可选动作中的哪一个动作。元属性提供沿两个维度的信息：

·动作调用的效果；它们由一组行为影响(implication)来规定。行为影响包括行为影响矢量(behavior impact vector)，其描述该动作如何影响被管理系统12的资源<R>16和/或可观察量<O>18。

·动作的“有效性”所依赖的前提条件。这些前提条件是工作量条件<W>或者资源<R>16限制方面的断定(predicate)。

基本属性

该组属性规定如何精确地调用动作，其中该动作是通过使用元属性而选择的。这包括选择调用该动作的参数的值，同时符合这些值的限制条件。

除了该元属性类别和基本规定类别，策略规定还包括某些例外。

表格1-用于对象的策略规定的模板

Action-object<A>

{

[Observable Implications]//动作所影响的可观察量维度

[Resource Implications]//动作所影响的资源

[Pre-conditions]//动作对于低级别状态的依赖性

[Workload Dependency]

[Resource Dependency]

[Base Specification]//用于调用动作的功能

[Exception handling]//错误事件

}

根据本发明的一个示例性实施例，表格1提供了在策略规定中规定对象的模板。

表格2-策略规定语法

specification:=<entry><specification>|<entry>

entry:=<name><behaviorimplications><preconditions><usage>

name:=<string-value>

resource:=cpu|memory|network|storage

behavior_implications:=<behavior_implication><behavior_implications>|<behavior_implication>

behavior_implication:=<dimension><impact>

impact:=up|none

dimension:=latency|throughput|reliability|availability

preconditions:=<precondition><preconditions>|null

precondition:=<workload-characteristic>|<resource-precondition>

workload-characteristic:=rw-ratio<rw-ratio-value>|access-pattern<access-pattern-value>|request-block-size<integer-value-inslusive>|request-rate<integer-value-inclusive>

rw-ratio-value:=mostly-reads|mostly-wires|reads-writes|*

access-pattern-value:=sequential|random|*

resource-precondition:=<resource><value>

value:=<interval-value>|<list-value>

interval-value:=<float-value>to<float-value>|<integer-value>to<integer-value>

list-value:=<list-value>*<list-item>

list-item:=<float-value>|<integer-value>

integer-value-inclusive:=<integer-value>|*

表格3-预取按钮(prefetch knob)定义

<action name=prefetch>

<behavior_implications>

<implication dimension=memory impact=down>

<implication dimension=storage impact=none>

</behavior_implications>

<preconditions>

<precond dimension=access-pattern value=sequential>

<precond dimension=memory value=20-60>

</preconditions>

</action>

表格3提供了根据本发明的示例性实施例的利用表格2的语法进行预取按钮的示例性定义。

推理

推理逻辑28用于使用逻辑和基本属性的组合，动态地确定动作规则。系统管理器14是告警驱动的，仅当被管理系统12指示违背了一个或多个目标时，系统管理器14才调用推理程序。被管理系统12通过产生一个告警来指示违背了一个或多个目标。系统管理器14使用基于用于推理的策略规定而构建的知识库，并决定调用一个或多个动作20，以使被管理系统12回到满足所有目标的状态。

图3是根据本发明的一个示例性实施例的用于在系统管理器14的推理逻辑28内执行推理的方法32。在块34，方法32开始。

在块36，识别与被管理系统12相关联的行为目标。该行为目标由负责运行该系统的管理员规定。这些目标类似于服务级别协议(SLA)，并且定义对于被管理系统12的被观察行为的限制。行为目标的示例包括：小于5毫秒的等待时间、大于100Mbps的吞吐量、小于一年5分钟的系统停机时间，等等。

在块38，确定被管理系统12的工作量特性。

在块40，确定由被管理系统12使用的资源。

在块42，确定是否满足在块36所识别的行为目标。如果是，那么方法32回到块36。

回到块42。如果不是，那么在块44，启动一个对系统管理器14内的推理逻辑28进行启动的触发器。

在块46，识别与被管理系统12相关联的参考结构。该参考结构是用于被管理系统12的先前结构，其中满足所识别的行为目标(见步骤36)。

在块48，比较所识别的参考结构与被管理系统12的当前结构，以识别出使得所识别的行为目标(见步骤36)不被满足的系统特性(例如，工作量、资源、环境、目标，等等)或者系统特性的组合。该比较有助于了解行为级别和状态级别的变化。

某些系统特性的示例包括但是不限于以下特性：

a.资源利用(百分比)[c₁]：这导致失败、资源添加以及应用活动限制。

b.应用请求特性[c₂]

c.指定的目标[c₃]

d.环境[c₄]：这导致对于系统内其它组件的依赖性。该方面是将来工作的一部分，因为当前工作集中于单机系统。

在大多数情况，[c₂]及[c₄]的组合效果将反映在[c]中。

表格4-系统特性文件-系统参数

Resources utilization(percentage)[c₁]

·    Storage sub-system

·    Network

·    Memory

·    CPU

Application request-characteristics[c₂]

·      Access-characteristics

             Request block size

             Request rate

             Skew/Locality

·      Async operations

·      Pathname translation operations

·      Read/write ratio

Assigned goals[c₃]

·      Throughput

·    Latency

·    Availability

·    Security

在块50，搜索由策略规定逻辑26保持的策略规定，以定位适应对象，其中该适应对象的属性与在块48中识别的系统特性或系统特性的组合匹配。该搜索产生了影响c₁、c₂和c₄中参数的所有适应对象的短列表(shortlist)。

该策略规定搜索基于一个简单的基于表格的方案：对于c₁、c₂&c₄中的每一个参数，适应对象被设置成表格的形式，也就是，影响所需资源组、应用特性和环境的对象。使用结合操作来选择影响两个或更多种类的参数的对象。

在块52，基于适应对象前提条件对短列表进行过滤。前提条件是对于系统状态和工作量特性的要求，其确保动作将是有效的(如果被调用)。例如，在预取动作的情况下，前提条件是工作量是连续的并且内存可用。

在块54，产生一列表，该列表包括部分或完全地对未得到满足的目标进行影响的适应对象。

对动作进行更高阶操作

图4例示了N维行为空间56。目标(c₃)的维度用于决定需要调用的适应对象以及这些对象的相应度(degree)的改变的组合。

回到图3。

在块58，决定需要调用的适应对象以及这些对象的相应度的改变的组合。短列表适应对象和受影响的行为维度的估计被提供给目标(c₃)的维度(见上述图4)。通过策略规定内容和自学的组合，导出行为维度。

从矢量空间操作方面来解释块58内的操作。该矢量空间表示如图4所示的n维行为空间。每一个适应对象被表示为n维行为空间内的单位矢量。该矢量的方向是对其所影响的行为维度的估计。长度表示对于适应对象的基本调用而言的度的变化。

对单位矢量(见图4)和它们相关联的长度的组合进行确定。

图5的图表59示出了基于Blackwell定理的矢量加法，其中使用基于Blackwell定理的递归算法来组合矢量。

产生一个目标矢量60，其起点为当前状态62，终点为期望状态64。

选择一个与目标矢量60的余弦夹角最大的单位矢量。该矢量的步长为k，其中‘k’表示系统的不稳定度(k＜目标矢量的长度)。重复产生目标矢量60以及选择与目标矢量的余弦夹角最大的单位矢量的操作。在该示例性实施例中，重复产生目标矢量的步骤，直到该单位矢量(具有步长k)等于目标矢量。在每一次重复中，算法都选择对于给定状态而言最佳的可能动作(例如，基于当前状态的局部优化)。

利用基本规定来决定如何调用动作

在块66，一旦已经决定调用哪一个或哪几个动作，则确定沿每一个行为维度所需的量的变化(资源和可观察量)。利用增量法来决定为该动作设置什么参数值。例如，调用在一个方向上具有参数值的单位变化的动作。如果该步骤的影响如预期那样，那么随着参数值增大来重复调用该动作，直到系统达到一个满意状态。如果不是，那么动作参数值的变化方向反向，并重复块66中的动作。

因此，当系统指示出违背了被管理系统12的一个或多个目标时，调用该推理模块。

在块68，方法32结束。

学习

回到图2。学习逻辑30提供一种用于耦合学习与策略规定(策略规定逻辑26)和推理(推理逻辑28)的方法。学习逻辑30用于利用测量值和阈值来提纯(refine)知识库。现有的方法，比如那些用于机器学习的方法(例如，神经网络、决策树、“K最近邻居”(K NearestNeighbours，K-NN)等等)被均衡使用(leverage)。这些现有方法已经被用于分类，以及在这里用于从对于较早决定的响应中学习。

学习在多个级别中系统地展开，包括元规定(meta specification)级别(见上述元属性)、基本规定级别(见上述基本属性)、涵盖动作之间的关系的级别，以及实现从管理员学习的级别。

元规定级别

管理员可以提供关于动作的影响的不完全的或者不准确的信息。例如，这些信息可能不能规定该动作未施加上述影响的一个或多个前提条件维度的值。系统在常规操作中学习关于这些附加前提条件，并相应地修改策略规定。

作为学习的另一个例子，该架构可以允许管理员规定提示(hint)，该提示可以在推理时引导系统。例如，在可以调用多于一个的动作从而校正系统状态的情况下，管理员可以(基于他们先前的经验)规定在特定工作量条件下调用哪一个动作。这可以通过使用决策树规定工作量条件来实现，其中该决策树的叶包含管理员对于待调用动作的选择。

基本规定级别

系统能够从增量调用中学习。为了决定调用动作所需的参数值，除了增量法之外，动作代理(agent)可以使用基于神经网络的方法来从先前的调用中学习该参数的约值应为多少。然后它可以从该点开始遵循增量法。

动作与从管理员学习之间的关系

除了学习动作属性，还可以通过记录动作调用与试图导出模式(pattern)之间的关系来导出模式(例如，动作A和B通常一起调用，动作C和D相互抵消，等等)。

还可以通过监测管理员来实现学习。当管理员响应于目标没有满足而调用一个动作时，系统产生一个记录，并记录一些细节，如资源级别、工作量特性、目标的值以及打算进行的动作。该记录用于产生一个“事例”，并使用现有的基于事例的推理(Case-based Reasoning：CBR)的方法。

图6是根据本发明的一个示例性实施例的系统管理器14以及与其功能模块(例如，监测器、致动器，等等)的交互作用的框图70。决定作出模块72通过多个组件代理之间的交互作用来实现。下面简要描述这些组件代理。

系统代理74协调系统中所有其它代理与监测器之间的通信，从而从管理员获得关于动作属性的输入，并基于策略规定提供自主功能性。系统的管理员直接与系统代理74交互，监测器和致动器也一样。系统代理74使用轮询模型(poll-model)来获得系统状态。它定期地轮询监测器，并更新其状态变量。然后它检查是否有任何目标被违背。如果有，则它调用决定作出进程，以矫正该情形。

输入代理76负责将用户提供的策略规定转换为永久存储器中的某些表征。该输入代理76当前分析所提供的XML(可扩展标记语言)规定，并将数据输入数据库表格。以这种形式存储动作属性可以在需要时容易地找出信息，以及在学习时由管理器容易地进行更新。

决定代理72决定管理器应当调用多个可能动作中的哪一个。为了实现这一点，决定代理72使用元规定，以在动作之间进行推理，并选择一个或多个将要调用的动作，从而使系统回到所有目标都满足的状态。如果不存在这样的动作，则它返回一个空组。

动作代理78采用由该决定代理产生的由一个或多个动作组成的组，并使用基本规定来确定调用该动作所需的参数的值。

图7例示了根据本发明的示例性实施例的执行用于在被管理系统12中进行规定、推理以及自学的动作中心方案的方法86。

在块88，方法86开始。

在块90，系统的管理员将一个包含动作属性规定的XML文件发送到系统代理74。

在块92，系统代理74将该请求转发到输入代理76，该输入代理分析该文件，并产生永久逻辑结构。当被管理系统12启动时，该操作被进行一次，并且仅当动作属性需要改变时才需要再次调用，而这种情况发生得不太频繁。

在块94，系统代理74检查系统的状态，该系统的状态是利用监测器收集的信息构建而成的。在该示例性实施例中，这种检查由系统代理74定期地进行。该定期是可由管理员和/或软件配置的单位时间。

在块96，系统代理74将资源及可观察量的当前值与针对目标规定的期望范围进行比较。

在块98，确定是否所有的被管理系统12的目标都满足。如果是，则在块110，方法86结束。

回到块98，如果不是，则在块100，启动一变化分析，以产生一个适当的请求。当一个或多个目标未满足时，系统执行变化分析，其中它对资源和/或可观察量的值中所需的最小数量变化进行汇总，从而使得系统达到所有目标都满足的状态。

在块102，对块100的变化分析汇总进行记录，并将其作为分解(resolution)请求发送到决定代理72。

在块104，决定代理72在动作之间进行推理，并选择一个或一组需要调用的动作。

在块106，然后动作代理78采用该组动作以及系统的当前状态和目标状态，并基于基本规定中给出的使用语义，选择与所识别的动作相关联的参数的值。

在块108，基于在块106中由动作代理78选择的参数值，系统代理74调用动作。

在块110，方法86结束。

因此，描述了一种使用动作中心方案来提供存储系统中的自主管理的系统和方法。虽然已经参照具体的示例性实施例描述了本发明，但是，很明显的是，可以在不脱离本发明的较宽的实质和范围的情况下，对这些实施例进行多种变型和改变。因此，说明书正文和附图应当理解为例示性的，而不是限制性的。