用于多个可用性管理器的简化和协调编排的开放弹性框架

摘要

可用性管理器编排系统和方法，具体地说，用于多个可用性管理器的简化和协调编排的开放弹性框架。

说明书

技术领域

本公开一般地涉及可用性管理器编排(orchestration)系统和方法， 具体地说，涉及用于多个可用性管理器的简化和协调编排的开放弹性框架。

背景技术

通常，正确管理IT系统的弹性(广义概念，包括容错(“FA”)、 高可用性(“HA”)、容灾和计划中断)极具挑战性。通常，客户非常难 以描述、阐明和量化可用性机制，并且难以配置、操作和监视这些可用性 机制。进一步，各种客户参与和调查强调客户需要能够更容易地理解使用 各种可用性机制的效用、性能和成本，这些可用性机制可以在现在和将来 的虚拟化IT基础架构中提供。

当今应用可用性管理技术本身(例如HA集群)的分析、安装、配置、 部署和操作相当复杂。20世纪90年代早期到中期，当大多数供应商引入 商用Unix(以及仅次于它的Microsoft)HA集群时，预计相对廉价的技术 (与它之前的专用FT相比)将变得无处不在。但是，由于复杂性导致的 人力成本和技能的局限性通常限制这些技术的采用。至今，这通常仍是客 户采用这些技术的一个严重障碍。

此外，客户工作负载及其嵌入式可用性管理越来越多地在虚拟基础架 构上部署，这些基础架构可能具有它们自己的可用性管理功能。尽管前者 通常提供更精确的恢复，而后者通常稍微更易于配置并且应用范围更广泛， 但白盒可用性管理与黑盒可用性管理之间的潜在(破坏性和建设性)交互 使得这些结构的一致可用性管理甚至更令人生畏。

VMware和Veritas集群服务提供一种常规机制。在该配置中，VMware 提供黑盒可用性管理功能，而Veritas集群服务提供白盒可用性管理功能。 VMware提供到其专用虚拟化管理功能的非常复杂的接口，Veritas集群服 务使用该功能与虚拟化层密切交互以便实现其白盒可用性目标。然后必须 修改Veritas代码以便使用这些接口在VMware环境中操作。这种类型的 配置通常极具限制性、繁琐并受限，因为它通常限于单个虚拟化层提供方 (例如，VMware)，并且通常需要对白盒可用性管理器(例如，Veritas) 进行虚拟化层特定的修改，以便实现协调的可用性管理。

发明内容

各种实施例提供一种机制，以便允许用户在对该用户有意义的抽象级 别指定他或她的弹性目标，然后自动初始化和配置白盒和黑盒可用性管理 器以便满足所述弹性目标(当然，可以在一个用户或多个用户的上下文中 应用各种实施例)。在一个实例中，各种实施例提供一种称为“弹性框架 编排器”的新颖系统管理组件，所述组件基于用户输入和部署在用户环境 中的可用性管理器，自动计算最佳配置参数和设置，然后采用不修改可用 性管理器的内部操作的方式，并且在许多情况下，采用可用性管理器不需 要知道它们在组合式可用性管理器系统中操作的方式，使用其现有接口和 行为配置可用性管理器。因此，本发明的各种实施例解决客户复杂性问题 (通过降低向用户暴露的复杂性)，并且旨在用于各种黑盒和白盒可用性 管理系统和环境。

此外，各种实施例可以提供以下一项或多项：

●提供简化的“弹性层”用户接口，所述用户接口抽象并定义多个可 用性管理系统的能力和行为，所述可用性管理系统负责管理多个级 别的IT层次结构，例如硬件、虚拟化基础架构、虚拟机、操作系 统、中间件和应用级资源。

●在弹性层中，使用客户指定的品质因数(“FOM”)指示客户的最 大可允许应用中断概率(例如但不限于，指示最大可允许服务水平 协议(“SLA”)违反概率)。

●基于该最大可允许应用中断概率和所选择的弹性层，执行应用、虚 拟和物理资源的最佳分配和放置的自动确定(自动生成空间组成 (spatial composition)目标)。

●基于该最大可允许应用中断概率和所选择的弹性层，执行组件可用 性管理器的所需行为的自动确定(自动生成行为组成(behavioral  composition)目标)。

●自动将空间和行为约束转换为可由组件可用性管理器使用的输入 语义和语法。

●使用所转换的空间和行为约束，自动初始化和配置组件可用性管理 器。可以执行该操作而无需对组件可用性管理器进行任何内部修改， 并且无需组件可用性管理器知道它们在组合式可用性管理器集合中 操作。

●自动编排组件可用性管理器之间的任何所需交互，以便确保它们平 稳并正确地互操作。

在另一个实施例中，提供一种用于配置至少第一可用性管理器和第二 可用性管理器的计算机实现的系统，所述系统包括：用户接口，其中所述 用户接口从用户处接收可用性管理目标，所述可用性管理目标与至少以下 项关联：(a)所述第一可用性管理器，和(b)所述第二可用性管理器； 处理元件，其在操作上与所述用户接口通信，其中所述处理元件至少部分 地基于所述可用性管理目标，确定：(a)与所述第一可用性管理器关联的 至少一个设置，和(b)与所述第二可用性管理器关联的至少一个设置； 以及控制元件，其在操作上与以下项通信：(a)所述处理元件，(b)所 述第一可用性管理器，和(c)所述第二可用性管理器；其中所述控制元件 从所述处理元件接收与所述第一可用性管理器关联的所述至少一个设置， 并且向所述第一可用性管理器提供所关联的设置；以及其中所述控制元件 从所述处理元件接收与所述第二可用性管理器关联的所述至少一个设置， 并且向所述第二可用性管理器提供所关联的设置。

在另一个实施例中，提供一种用于配置至少第一可用性管理器和第二 可用性管理器的在计算机系统中实现的方法，所述方法包括：提供用户接 口，其中所述用户接口从用户处接收可用性管理目标，所述可用性管理目 标与至少以下项关联：(a)所述第一可用性管理器，和(b)所述第二可 用性管理器；至少部分地基于所述可用性管理目标，确定：(a)与所述第 一可用性管理器关联的至少一个设置，和(b)与所述第二可用性管理器 关联的至少一个设置；向所述第一可用性管理器提供与所述第一可用性管 理器关联的所述至少一个设置；向所述第二可用性管理器提供与所述第二 可用性管理器关联的所述至少一个设置；以及使用处理器单元运行程序以 便执行所述(a)提供用户接口；(b)确定；(c)向所述第一可用性管理 器提供与所述第一可用性管理器关联的所述至少一个设置；以及(d)向 所述第二可用性管理器提供与所述第二可用性管理器关联的所述至少一个 设置中的一个或多个。

在另一个实施例中，提供一种可由机器读取的程序存储设备，其有形 地包含可由所述机器执行的指令程序以便执行一种用于配置至少第一可用 性管理器和第二可用性管理器的方法，所述方法包括：提供用户接口，其 中所述用户接口从用户处接收可用性管理目标，所述可用性管理目标与至 少以下项关联：(a)所述第一可用性管理器，和(b)所述第二可用性管 理器；至少部分地基于所述可用性管理目标，确定：(a)与所述第一可用 性管理器关联的至少一个设置，和(b)与所述第二可用性管理器关联的 至少一个设置；向所述第一可用性管理器提供与所述第一可用性管理器关 联的所述至少一个设置；向所述第二可用性管理器提供与所述第二可用性 管理器关联的所述至少一个设置；以及使用处理器单元运行程序以便执行 所述(a)提供用户接口；(b)确定；(c)向所述第一可用性管理器提供 与所述第一可用性管理器关联的所述至少一个设置；以及(d)向所述第 二可用性管理器提供与所述第二可用性管理器关联的所述至少一个设置中 的一个或多个。

附图说明

附图仅用于示例性目的并且不一定按比例表示本发明的实际实例。在 附图中，相同的参考标号用于表示相同或相似的部分，这些附图是：

图1是根据本发明的一个实施例的系统的框图；

图2是根据本发明的一个实施例的系统的框图；

图3是根据本发明的一个实施例的系统的框图；

图4是根据本发明的一个实施例的系统的框图；

图5是根据本发明的一个实施例的系统的框图；

图6A是根据本发明的一个实施例的系统的框图；

图6B是根据本发明的一个实施例的系统的框图；

图7是根据本发明的一个实施例的软件程序的屏幕截图；

图8是根据本发明的一个实施例的系统的框图；以及

图9是根据本发明的一个实施例的系统的框图。

具体实施方式

为了描述和要求保护本发明，术语“可用性管理器”或(“AM”) 旨在指系统管理元件(例如，包括程序代码和/或硬件)，其在信息技术 (“IT”)环境中检测和响应故障和其它不需要的异常(例如，在不同级 别)。

为了描述和要求保护本发明，术语“白盒可用性管理器”旨在指检测 和响应与一个或多个应用级资源(以下有时称为“应用资源”或“AR”) 关联的故障的可用性管理器，这些应用级资源例如包括操作系统进程、容 器、文件系统、存储器件、磁盘卷、网络接口或IP号码(地址)。

为了描述和要求保护本发明，术语“黑盒可用性管理器”旨在指检测 和响应与一个或多个虚拟机(“VM”)或逻辑分区(“LPAR”)关联的 故障的可用性管理器。

为了描述和要求保护本发明，术语“可用性管理目标”旨在指从一组 量化值中选择的一个值，其中所述一组量化值表征多个相关可用性管理器 的操作(在一个实例中，可以采用对用户有意义的术语表达量化值)。注 意，量化值可以是定量的(例如，特定的数量或数量范围)，或者量化值 可以是定性的(例如，诸如以下项的描述符：“良好”、“更好”、“最 好”；或者“金牌”、“银牌”、“铜牌”；或者“价值”、“标准”、 “企业”)。在另一个实例中，量化值可以包括“层”。在另一个更具体 的实例中，量化值可以包括“弹性层”(这种“弹性层”例如可以涉及某 一级别的可能服务可靠性)。

为了描述和要求保护本发明，术语“空间组成”旨在指如何相对于彼 此放置多个IT资源(例如，以便限制故障影响)。

为了描述和要求保护本发明，术语“行为组成”旨在指如何将多个可 用性管理器配置为协同工作以便对故障做出反应(例如，以便限制故障影 响)。

为了描述和要求保护本发明，术语“语法结构”旨在指信息(例如， 脚本、配置文件等)，该信息采用可由给定可用性管理器理解的形式，以 便给定可用性管理器能够对以这种语法结构提供的信息执行操作。在一个 实例中，语法结构可以包括语义和句法。

为了描述和要求保护本发明，术语“实时”旨在指原因和结果大约同 时发生(例如，原因和结果之间没有明显的时间滞后，但不一定即时)。

现在参考图1，示出根据本发明的一个实施例的计算机实现的系统 100。系统100用于配置至少第一可用性管理器102和第二可用性管理器 104。系统100包括用户接口106，其中用户接口106从用户处接收可用性 管理目标，所述可用性管理目标与至少以下项关联：(a)第一可用性管理 器102，和(b)第二可用性管理器104。进一步，处理元件108在操作上 与用户接口106通信，其中处理元件108至少部分地基于可用性管理目标， 确定：(a)与第一可用性管理器102关联的至少一个设置，和(b)与第 二可用性管理器104关联的至少一个设置。更进一步，控制元件110在操 作上与以下项通信：(a)处理元件108，(b)第一可用性管理器102， 和(c)第二可用性管理器104；其中控制元件110从处理元件108接收与 第一可用性管理器102关联的至少一个设置，并且向第一可用性管理器102 提供所关联的设置；以及其中控制元件110从处理元件108接收与第二可 用性管理器104关联的至少一个设置，并且向第二可用性管理器104提供 所关联的设置。

现在参考图2，示出根据本发明的一个实施例的弹性框架编排器系统 管理组件(被示出为弹性框架编排器201)。如该图2中所示，弹性框架 编排器201可以使用来自用户接口(未示出)的简化弹性设置203，然后 编排在此描述的白盒可用性管理器和黑盒可用性管理器的部署和配置。在 一个实例中，与弹性框架编排器201关联的功能可以位于该图2中所示的 位置。在另一个实例中，与弹性框架编排器201关联的功能可以位于系统 中的其它位置。在另一个实例中，可以将弹性框架编排器201产品化为现 有系统管理产品(例如，IBM Systems Director、诸如TSAM之类的Tivoli 产品，或者这两者)的组件。注意，该图2示出编排适用于一系列白盒可 用性管理器(例如，TSA205A、PowerHA205B和WebSphere Cloudburst 205C)和黑盒可用性管理器(例如，VMware207A、VMControl207B和 VMControl207C)。如在此描述的，白盒可用性管理器负责管理AR209A、 209B、209C的可用性，它们通常按照惯例由HA(高可用性)基础架构管 理。也如在此描述的，黑盒可用性管理器负责管理虚拟机或逻辑分区，而 不知道其内容或内部工作。尽管此处的大部分讨论专注于使用IBM Tivoli  System Automation产品作为白盒可用性管理器，使用IBM VMControl 产品作为黑盒可用性管理器，但应该理解，这些仅是实例，并不表示范围 限制，并且旨在是示例性的(非限制性的)。

如在此描述的，可以在IT环境的上下文中应用各种实施例，其中安 装多个可用性管理器并且它们需要协同工作。

在各种实例中，可以将各实施例应用于IT环境，其中黑盒可用性管 理器(例如，VMware HA服务、IBM的VMControl以及例如Amazon EC2 中的基于云的可用性管理器)和白盒可用性管理器(例如，Veritas集群服 务、Microsoft的集群服务、IBM的Tivoli System Automation以及IBM 的PowerHA)处于使用状态(并且可以有利地同时使用)。

在一个实例中，可以通过“弹性框架编排器”(例如，软件组件；硬 件组件；或者包括软件和硬件组合的组件)实现各实施例。

其它实例可以提供以下一项或多项：

●经由量化弹性层的简化可用性规范。单个可用性管理器的常规配置 通常非常困难。预计(如果没有本发明)使可用性管理器交互以便 更好地协同工作(例如在本公开的上下文中)的配置非常困难(如 果并非几乎不可能)。因此，本发明实施例的一个贡献是通过定义 一小组量化用户可见“弹性层”，简化可用性管理目标的规范，这 些弹性层采用对客户有意义的术语表达。(这也可以称为级别、策 略、目标或目的。在本公开中，我们将使用通用术语“弹性层”， 并且应该理解它说明该通用概念。)例如，客户可以从以下项中选 择：良好、更好、最好；或者金牌、银牌、铜牌；或者价值、标准、 企业，或者甚至定量品质因数，例如经过适当量化的服务水平协议 概率。注意，必须强调各种实施例提供将可用性管理器行为领域量 化为某个对客户有意义的定义明确的行为组，而不是一组特定层或 层定义本身。还应注意，可以以各种方式确定特定弹性层，例如以 算法方式(例如，通过计算系统中的每个可用性管理器的每个行为 组合，并且让一个弹性层表示每个组合)，或者以手动方式(例如， 通过让熟悉各种可用性管理器的人员根据对弹性层的能力和交互的 分析和理解，定义弹性层)。

●将可用性规范变换为空间和行为组成目标。本申请公开空间和行为 组成的概念，并且表明如何可以调整它们以便实现选定弹性层。在 这点上，注意(如上定义)空间组成描述如何相对于彼此放置IT 资源(例如，以便限制故障影响)。例如，将所有虚拟机放在单个 物理服务器上，虽然最小化物理服务器的数量并因此最小化其成本， 但让它们全部受到该单个物理服务器故障的影响，而将它们跨多个 物理服务器分布则降低这种脆弱性。前者可以对较低弹性层有意义， 而后者可以是较高弹性层需要的。在此公开了基于选定弹性层，自 动确定满足该弹性层的要求所必需的应用、虚拟和物理资源的最佳 分配和放置(空间组成的自动生成)。进一步，行为组成(如上定 义)指如何将系统中的各种可用性管理器配置为协同工作以便对故 障做出反应(例如，以便限制故障影响)。例如，在某些弹性层中， 可以从处理故障中禁用黑盒可用性管理器，然而可以启用白盒可用 性管理器。或者(例如)，如果未安装白盒可用性管理器(例如， 为了降低成本)，则黑盒可用性管理器将单独负责处理故障。基于 选定弹性层和安装的各种可用性管理器的能力，我们公开了自动确 定每个可用性管理器的行为以便满足该弹性层的要求。

●将空间和行为组成目标变换为可用性管理器语法。如在此描述的， 公开了一组量化弹性层的概念，以及独立于任何给定可用性管理器 描述表征的空间和行为组成。提供了将这些空间和行为约束转换为 给定安装中的每个可用性管理器理解的语法结构(例如，脚本、配 置文件等)。例如，IBM的VMControl具有特定语法结构以便表 达两个虚拟机不能位于同一物理机上。IBM的Tivoli System  Automation可用性管理器具有另一个语法结构以便表达两个应用 不能位于同一虚拟机上。需要任何这种分离的给定弹性层必须以适 当的语法结构表达分离。在这点上，在此公开了以下概念：将与选 定弹性层关联的空间和行为组成转换为可由组件可用性管理器使用 的语法结构。

●自动初始化和配置多个可用性管理器。如果给出弹性层、一组空间 和行为组成目标，以及用于实现以组成的可用性管理器可以理解的 语法结构表达的这些目标的一组定制规则，则还公开了以下过程： 自动使用以可用性管理器语法结构表达的规则来初始化、配置和启 动组成的可用性管理器，以便实现选定弹性层的目标。在一个实例 中，弹性框架编排器(如在此描述的)执行这种初始化和配置。

●自动编排(例如，在运行时)组件可用性管理器之间的任何所需交 互，以便确保它们平稳并且正确地互操作。一旦包括多个可用性管 理器的系统启动并根据此处描述的初始化和配置过程运行，就可能 在故障处理行为期间(或者在其它时间)需要弹性框架编排器干预， 以便针对一个或多个可用性管理器实行实时控制。例如，在由黑盒 可用性管理器和白盒可用性管理器两者管理的系统中，弹性框架编 排器可能必须防止白盒可用性管理器将白盒可用性管理器的某些运 行时动作解释为故障(例如主动迁移，其可能临时中断白盒可用性 管理器的心跳，因此导致白盒可用性管理器无故响应)。为了处理 所有这些情况，在此公开了以下过程：标识和自动编排组件可用性 管理器之间的任何所需交互，以便确保它们在运行时平稳并正确地 互操作，以满足选定弹性层的要求。

在一个实施例中，提供一种用于配置至少第一可用性管理器和第二可 用性管理器的计算机实现的系统，所述系统包括：用户接口，其中所述用 户接口从用户处接收可用性管理目标，所述可用性管理目标与至少以下项 关联：(a)所述第一可用性管理器，和(b)所述第二可用性管理器；处 理元件，其在操作上与所述用户接口通信，其中所述处理元件至少部分地 基于所述可用性管理目标，确定：(a)与所述第一可用性管理器关联的至 少一个设置，和(b)与所述第二可用性管理器关联的至少一个设置；以 及控制元件，其在操作上与以下项通信：(a)所述处理元件，(b)所述 第一可用性管理器，和(c)所述第二可用性管理器；其中所述控制元件从 所述处理元件接收与所述第一可用性管理器关联的所述至少一个设置，并 且向所述第一可用性管理器提供所关联的设置；以及其中所述控制元件从 所述处理元件接收与所述第二可用性管理器关联的所述至少一个设置，并 且向所述第二可用性管理器提供所关联的设置。

在一个实例中，所述第一可用性管理器可以包括白盒可用性管理器， 并且所述第二可用性管理器可以包括黑盒可用性管理器。

在另一个实例中，所述用户接口可以经由网络从所述用户处接收所述 可用性管理目标。

在另一个实例中，所述可用性管理目标可以包括来自一组预定量化值 的一个值。

在另一个实例中，可以经由所述用户接口为所述用户提供所述一组预 定量化值。

在另一个实例中，所述用户接口可以被配置为从所述用户处接收对来 自所述一组预定量化值的一个值的选择。

在另一个实例中，所述处理元件可以至少部分地基于所述可用性管理 目标，确定与所述第一可用性管理器和所述第二可用性管理器关联的空间 组成；可以在由所述处理元件确定的与所述第一可用性管理器关联的所述 至少一个设置中反映所述空间组成；以及可以在由所述处理元件确定的与 所述第二可用性管理器关联的所述至少一个设置中反映所述空间组成。

在另一个实例中，所述处理元件可以至少部分地基于所述可用性管理 目标，确定：(a)与所述第一可用性管理器关联的行为组成，和(b)与 所述第二可用性管理器关联的行为组成；可以在由所述处理元件确定的与 所述第一可用性管理器关联的所述至少一个设置中反映与所述第一可用性 管理器关联的所述行为组成；以及可以在由所述处理元件确定的与所述第 二可用性管理器关联的所述至少一个设置中反映与所述第二可用性管理器 关联的所述行为组成。

在另一个实例中，所述处理元件可以至少部分地基于所述可用性管理 目标，确定：与所述第一可用性管理器和所述第二可用性管理器关联的空 间组成；所述处理元件可以至少部分地基于所述可用性管理目标，确定： (a)与所述第一可用性管理器关联的行为组成，和(b)与所述第二可用 性管理器关联的行为组成；所述处理元件可以至少部分地基于与所述第一 可用性管理器关联的所述空间组成和所述行为组成，确定用于向所述第一 可用性管理器表达与所述第一可用性管理器关联的所述空间组成和所述行 为组成的语法结构；以及所述处理元件可以至少部分地基于与所述第二可 用性管理器关联的所述空间组成和所述行为组成，确定用于向所述第二可 用性管理器表达与所述第二可用性管理器关联的所述空间组成和所述行为 组成的语法结构。

在另一个实例中，可以在由所述处理元件确定的与所述第一可用性管 理器关联的所述至少一个设置中反映用于表达与所述第一可用性管理器关 联的所述空间组成和所述行为组成的所述语法结构；以及可以在由所述处 理元件确定的与所述第二可用性管理器关联的所述至少一个设置中反映用 于表达与所述第二可用性管理器关联的所述空间组成和所述行为组成的所 述语法结构。

在另一个实例中，所述配置可以包括控制以下项中的至少一个的故障 处理和其它行为：(a)当所述第一可用性管理器处于初始化后状态时的所 述第一可用性管理器，和(b)当所述第二可用性管理器处于初始化后状 态时的所述第二可用性管理器。

在另一个实例中，所述配置可以包括实时控制以下项中的至少一个的 故障处理和其它行为：(a)所述第一可用性管理器，和(b)所述第二可 用性管理器。

在另一个实例中，所述配置可以包括初始化以下项中的至少一个：(a) 当所述第一可用性管理器处于初始化前状态时的所述第一可用性管理器， 和(b)当所述第二可用性管理器处于初始化前状态时的所述第二可用性 管理器。

在另一个实施例中，提供一种用于配置至少第一可用性管理器和第二 可用性管理器的在计算机系统中实现的方法，所述方法包括：提供用户接 口，其中所述用户接口从用户处接收可用性管理目标，所述可用性管理目 标与至少以下项关联：(a)所述第一可用性管理器，和(b)所述第二可 用性管理器；至少部分地基于所述可用性管理目标，确定：(a)与所述第 一可用性管理器关联的至少一个设置，和(b)与所述第二可用性管理器 关联的至少一个设置；向所述第一可用性管理器提供与所述第一可用性管 理器关联的所述至少一个设置；向所述第二可用性管理器提供与所述第二 可用性管理器关联的所述至少一个设置；以及使用处理器单元运行程序以 便执行所述(a)提供用户接口；(b)确定；(c)向所述第一可用性管理 器提供与所述第一可用性管理器关联的所述至少一个设置；以及(d)向 所述第二可用性管理器提供与所述第二可用性管理器关联的所述至少一个 设置中的一个或多个。

在一个实例中，可以按照所列举的顺序执行所述步骤。

在另一个实例中，所述第一可用性管理器可以包括白盒可用性管理器， 并且所述第二可用性管理器可以包括黑盒可用性管理器。

在另一个实例中，所述配置可以包括控制以下项中的至少一个的故障 处理和其它行为：(a)当所述第一可用性管理器处于初始化后状态时的所 述第一可用性管理器，和(b)当所述第二可用性管理器处于初始化后状 态时的所述第二可用性管理器。

在另一个实例中，所述配置可以包括实时控制以下项中的至少一个的 故障处理和其它行为：(a)所述第一可用性管理器，和(b)所述第二可 用性管理器。

在另一个实例中，所述配置可以包括初始化以下项中的至少一个：(a) 当所述第一可用性管理器处于初始化前状态时的所述第一可用性管理器， 和(b)当所述第二可用性管理器处于初始化前状态时的所述第二可用性 管理器。

在另一个实施例中，提供一种可由机器读取的程序存储设备，其有形 地包含可由所述机器执行的指令程序以便执行一种用于配置至少第一可用 性管理器和第二可用性管理器的方法，所述方法包括：提供用户接口，其 中所述用户接口从用户处接收可用性管理目标，所述可用性管理目标与至 少以下项关联：(a)所述第一可用性管理器，和(b)所述第二可用性管 理器；至少部分地基于所述可用性管理目标，确定：(a)与所述第一可用 性管理器关联的至少一个设置，和(b)与所述第二可用性管理器关联的 至少一个设置；向所述第一可用性管理器提供与所述第一可用性管理器关 联的所述至少一个设置；向所述第二可用性管理器提供与所述第二可用性 管理器关联的所述至少一个设置；以及使用处理器单元运行程序以便执行 所述(a)提供用户接口；(b)确定；(c)向所述第一可用性管理器提供 与所述第一可用性管理器关联的所述至少一个设置；以及(d)向所述第 二可用性管理器提供与所述第二可用性管理器关联的所述至少一个设置中 的一个或多个。

在一个实例中，可以按照所列举的顺序执行所述步骤。

在另一个实例中，所述第一可用性管理器可以包括白盒可用性管理器， 并且所述第二可用性管理器可以包括黑盒可用性管理器。

在另一个实例中，所述配置可以包括控制以下项中的至少一个的故障 处理和其它行为：(a)当所述第一可用性管理器处于初始化后状态时的所 述第一可用性管理器，和(b)当所述第二可用性管理器处于初始化后状 态时的所述第二可用性管理器。

在另一个实例中，所述配置可以包括实时控制以下项中的至少一个的 故障处理和其它行为：(a)所述第一可用性管理器，和(b)所述第二可 用性管理器。

在另一个实例中，所述配置可以包括初始化以下项中的至少一个：(a) 当所述第一可用性管理器处于初始化前状态时的所述第一可用性管理器， 和(b)当所述第二可用性管理器处于初始化前状态时的所述第二可用性 管理器。

在另一个实施例中，提供一种用于配置至少第一可用性管理器和第二 可用性管理器的系统，所述系统包括一个或多个处理器单元，所述处理器 单元被配置为：提供用户接口，其中所述用户接口从用户处接收可用性管 理目标，所述可用性管理目标与至少以下项关联：(a)所述第一可用性管 理器，和(b)所述第二可用性管理器；至少部分地基于所述可用性管理 目标，确定：(a)与所述第一可用性管理器关联的至少一个设置，和(b) 与所述第二可用性管理器关联的至少一个设置；向所述第一可用性管理器 提供与所述第一可用性管理器关联的所述至少一个设置；向所述第二可用 性管理器提供与所述第二可用性管理器关联的所述至少一个设置；以及使 用处理器单元运行程序以便执行所述(a)提供用户接口；(b)确定；(c) 向所述第一可用性管理器提供与所述第一可用性管理器关联的所述至少一 个设置；以及(d)向所述第二可用性管理器提供与所述第二可用性管理 器关联的所述至少一个设置中的一个或多个。

在另一个实施例中，提供一种制造品，包括：至少一个有形计算机可 读设备，其中有形地包含计算机可读程序代码逻辑以便在至少一个处理单 元中执行用于配置至少第一可用性管理器和第二可用性管理器的至少一个 机器指令，所述计算机可读程序代码逻辑在执行时，执行以下步骤：提供 用户接口，其中所述用户接口从用户处接收可用性管理目标，所述可用性 管理目标与至少以下项关联：(a)所述第一可用性管理器，和(b)所述 第二可用性管理器；至少部分地基于所述可用性管理目标，确定：(a)与 所述第一可用性管理器关联的至少一个设置，和(b)与所述第二可用性 管理器关联的至少一个设置；向所述第一可用性管理器提供与所述第一可 用性管理器关联的所述至少一个设置；向所述第二可用性管理器提供与所 述第二可用性管理器关联的所述至少一个设置；以及使用处理器单元运行 程序以便执行所述(a)提供用户接口；(b)确定；(c)向所述第一可用 性管理器提供与所述第一可用性管理器关联的所述至少一个设置；以及 (d)向所述第二可用性管理器提供与所述第二可用性管理器关联的所述 至少一个设置中的一个或多个。

如在此描述的，描述了弹性框架的各种原理，该弹性框架允许客户以 可使用的方式指定、部署、管理和分析复杂IT系统的弹性。还描述了各 种客户需要，以及旨在满足这些需要的弹性框架原理。这些原理可以包括 以下一项或多项：

○从复杂性中抽象而成的有意义的弹性层的定义；

○弹性层与客户价值度量的明确关联；

○实际IT系统中必不可少的多个可用性管理组件的操作的组成和协 调；以及

○约束这些可用性管理器的行为以便限制通常为指数的组合式结构 行为复杂性，并且使行为组成完全可行。

进一步，展示了使用这些原理中的某些原理指定、部署和管理IT结 构的可用性，该IT结构包含(例如)x86服务器、Xen系统管理程序、SLES 虚拟机、使用Tivoli System Automation作为应用级别可用性管理器以及 VMControl的简化解释作为虚拟机级别可用性管理器的应用资源。

进一步，展示了使用分析技术将客户的简化弹性层和该弹性层中的所 需品质因数(“FOM”)转换为通知弹性结构部署必需的参数。

进一步，公开了资源关系建模框架，其可以是强大的规范和分析工具， 以便在系统生命周期中的不同点对各种弹性相关行为进行建模和理解。

在其它实施例中，可以提供一种弹性框架，其缓解在此讨论的部分或 全部客户“痛点”。可以提供这些实施例以便具体支持以下一个或多个活 动：

■指定工作负载及其弹性要求指定“工作负载”。工作负载可以包 括非常大量(例如，数万)的异构应用和虚拟机映像。由于工作负 载的规模，可能需要可抽象/分层的逻辑和图形表示。按照彻底简化 模式，指定全部或部分给定工作负载的抽象弹性要求。注意，并非 给定工作负载的所有元素都需要具有相同的抽象弹性要求。这可以 通过以下操作实现：针对拓扑中的每个资源定义一小组可用性策略， 并且定义从资源到其相关资源的一致映射(例如，包括行为约束)， 例如从中间件(例如，DB2、WebSphere、MQ)到OS、池、硬件 的映射。

■指定托管环境托管环境可以表示可托管工作负载的相互依赖的 (例如，建模的或实例化的)物理和/或逻辑资源。托管环境可以包 括非常大量的异构物理和/或逻辑资源，可能在地理上分散到多个 “云”中，这些云可以具有多个所有者(例如，内部与外部)。

■确定将工作负载放到其环境中计算将工作负载映射到托管环境的 托管关系(放置)，以便满足所有约束和要求。包括工作负载预测 和提前预留。

■将工作负载部署到其环境中自动在托管环境中配置和初始化多个 可用性管理器，以便支持工作负载的弹性要求。按照适当的顺序将 工作负载部署到托管环境中并且提高效率。

■在环境中管理工作负载允许多个可用性管理器针对可能重叠的资 源执行其功能，以便有利于客户并且具有最少的内部更改。

■监视托管环境监视托管环境并明确确定故障对相关组件的影响， 并且随着环境更改，执行持续的弹性策略合规性监视。

■相对于托管环境分析工作负载开发资源关系模型，该模型足够丰 富以便支持所需的弹性拓扑规范、分析和部署。分析现有或建模的 托管关系以便判定是否满足所有约束和要求。这包括以下能力：经 由动态调整任何所需资源属性，模拟资源利用、故障/错误等的波动。 这可以包括评估给定拓扑是否满足给定弹性层，确定给定拓扑能够 支持何种弹性层，模拟资源删除(故障)的影响。

在其它实施例中，可以应用以下一个或多个弹性框架原理：

○弹性层弹性框架的一个原理可以是将该环境中的可用性管理的所 有方面简化到可能的程度。这种简化可以首先提取和严格限制提供 给客户的可用性管理选项。在一个实例中，可以向虚拟机可用性管 理领域(例如，VMControl)应用一组弹性层(例如，“金牌/银牌 /铜牌”或者“良好/更好/最好”)。

○将弹性层明确关联/映射到客户价值度量每个层不仅可以按照名称 表征，而且还可以采用与其业务相关的术语按照以下项表征：(1) 其对客户的价值，和(2)其对客户的成本。在一个实例中，每个层 的一组定量弹性品质因数可以表达潜在故障的业务影响，以及该层 的资源成本。

○支持多个自动协调可用性管理器为了实现可能需要的简化级别， 该框架中可能需要定义多个可用性管理器功能并将它们捆绑到合理 的包中，其中它们均可以自动执行，对它们进行测试，将它们作为 实体交付，并且提供生命周期实体管理。

○受限行为弹性框架的另一个原理可以是不仅包含和利用各种可用 性管理子系统的自动恢复操作，而且还谨慎地约束这些子系统的行 为范围，从而认识到这种大量可能行为通常导致子系统在过去如此 难以使用。这尤为重要，因为弹性框架的一个重要功能可以是将来 自多个可用性管理器的行为组成为一致和交互的整体，并且如果组 件行为本身不受约束，则可以使该操作更加困难。因此，在一个实 例中，可以创建明确定义和有限数量的资源特定恢复操作。

在其它实施例中，可以应用以下一个或多个弹性框架元素(弹性框架 可以位于整体系统管理结构的上下文中，如图3中所示)，其允许客户机：

○选择应用及其弹性层(图3的元素301)。还可以选择应用的定量 品质因数。

○基于弹性层和品质因数，创建弹性模式(可以存储在库中以便将来 重用)(图3的元素303)。

○使用诸如Rational或TSAM之类的常规部署工具，实例化和部署 弹性模式(图3的元素305)。

○支持正在执行的弹性结构的运行时管理和分析(图3的元素307)。

现在将参考根据另一个实施例的实例工作负载模型。

在该实例工作负载模型中，定义和理解将工作负载部署到复杂弹性结 构中并且配置这些结构的分支中的一个步骤是明确指定工作负载本身的特 征和要求。因为需要支持的大量工作负载通常不可能有单一描述，所以在 该实例中，我们标识可以将工作负载分类到其中的公共区别轴，客户可以 使用它“标记”其工作负载，并且它通知弹性服务的一致配置和操作。

在该实例中，我们尤其专注于通知可用性管理的那些轴，从而认识到 (并且针对该实例忽略)来自其它管理准则的因素(例如性能和安全性) 可能与可用性管理强交互。

出于该实例的目的，工作负载包括一个或多个“应用资源”，例如客 户定义的特定任务，其中某一数量的任务必须可用于实现客户的业务目标。 客户的工作负载中可以具有多个应用资源(AR)。在该实例中，每个AR 被视为原子可管理应用资源，例如进程、容器、HA资源或进程组，它们 的可用性可以潜在地由诸如HACMP、TSA、Veritas集群服务、WPAR 管理器、LinuxHA、WebSphere CloudBurst、DB2HA/DR或Microsoft 集群服务之类的白盒可用性管理(WAM)产品管理。

在该实例中，客户的应用资源集合部署在包括一个或多个操作系统、 系统管理程序和物理服务器的基础架构上。因为该实例专注于虚拟化环境， 所以假设操作系统以及在其中执行的任何应用资源和关联的可用性管理封 装在虚拟机中。

在该实例中，将服务降级事件定义为减少操作中的应用资源数量的任 何资源中断(例如，应用资源、操作系统、系统管理程序或物理服务器)。

在该实例中，任何工作负载都具有固有的功能特征，例如其组件(在 这种情况下为AR)如何相关或独立协同工作，如何在它们之间分配工作， 以及在发生故障的情况下必须如何恢复它们。简单的分类实例为：

○服从应用级别(即，白盒)可用性管理<->不服从应用级别AM

○独立工作负载单元<->相关工作负载单元

○粒度可扩展<->不可扩展

○可从容降级<->不可从容降级

○无状态<->有状态

在一个实例中，应用可以服从包括独立工作负载单元的WAM，粒度 可扩展，并且可从容降级。在一个实例中，不会针对应用资源的有状态性 做出特定假设，因为这可以被视为WAM恢复脚本的内部问题。

在一个实例中，客户的工作负载及其独有的弹性品质因数(“FOM”) 可以确定弹性的最低成本(例如，空间组成)资源分配策略(例如，在弹 性层中)。

在该实例中考虑的主要FOM是面向可靠性的工作负载(例如，SOA 或电子商务工作负载)，其中主要问题是在任何给定时间点满足最低服务 水平协议。这些工作负载通常需要给定的最少数量应用资源始终可用以便 提供可接受的吞吐量，并且受一个或多个服务降级事件(SDE)在任何给 定时间禁用的应用资源数量的影响。对于这种面向可靠性的工作负载，在 该实例中断言要最小化的FOM是满足SLA所需的少于给定基准数量的应 用资源在任何时间点始终可用的概率，以及当发生这种情况时AR短缺的 持续时间。

在一个实例中，可以将该特定FOM表示为：P(SLA Violation)。这可 以是用户向弹性编排器提供的参数，其用于允许编排器判定应该在何处以 及如何跨IT系统分配资源以便实现弹性目标。

在该实例中，可能感兴趣但未显式计算的其它弹性相关品质因数包括 (但不限于)：

○由可能长时间运行的网格型应用例示的第二大类工作负载，其中在 某一时间间隔内可用的预期应用资源数量是要最大化的量。这些工 作负载通常涉及的任何给定SDE的点影响不大于在某一时间段内 发生的所有SDE的总影响(就在该时间内不可用的应用资源小时而 言)。这可以更大程度上被视为面向可用性的工作负载。对于这种 面向可用性的工作负载，要最小化的FOM可以是在某一时间段内 相对于某一基准期望应用资源数量，由于服务降级事件而失去的应 用资源小时总数。

○每年的服务降级事件

○预期的服务降级事件持续时间

○每个服务降级事件影响的应用资源数量

在各种实施例中，可以提供分析框架，其允许计算和最小化其它FOM， 因为这些FOM被确定为很重要。

现在参考成本品质因数，在一个实例中，对于每个工作负载、弹性层 (和结果映射)以及组件成本，可以将实现该层所需的服务器、系统管理 程序实例、操作系统实例和各种许可的数量相加。但是，在这点上，成本 计算元素可以是执行特定可用性管理子系统的空间和时间开销的准确预 测。在可行的范围内，这些成本可以基于定量基准测试。

现在将参考根据本发明另一个实施例的服务器弹性层定义。在一个实 例中，可以针对计划外中断和计划中断，考虑服务器及其关联的软件栈和 工作负载的弹性。计划外中断可以包括对IT栈中任何元素的可靠性的任 何不可预测的损害。在计划中断的标题下，可以包括预测故障以及用户无 论由于何种目的而启动的选定IT元素中断。

在一个实例中，用于计划外和计划中断的弹性层是解耦的，因为客户 可能需要针对这两种中断具有不同级别的能力。将计划中断和计划外中断 的处理捆绑到单一级别时，解除两种中断的捆绑以增加灵活性(如在演示 中确定的)通常具有压力。但是，在该实例中，为了概念简单性，可以在 用于这两种情况的层之间保持并行性。

术语“恢复”用于指示在发生故障之后恢复资源(例如，VM或更高 级元素)的操作。可以具有多种形式的恢复，范围为从引导映像恢复，到 重新启动应用，到从(微)检查点恢复。术语“撤离”用于指示资源(例 如，VM或更高级元素)要从容地从报废元素迁移到IT栈中的批准元素。 撤离模式的范围可以从虚拟机的已知主动迁移能力，到受影响组件的彻底 关闭和重新启动。

与计划外中断相关的各种实例包括以下项：

○5层–物理服务器、虚拟机和应用资源(包括中间件)故障的自动 恢复。向用户通知事件和解决方案。

○4层–物理服务器和虚拟机故障的自动恢复。没有AR故障的自动 恢复。向用户通知事件和解决方案。

○3层–某些自动恢复过程，但需要人为干预以便恢复。

○2层–状态信息可用，用于恢复的指导式手动过程。

○1层–状态信息可用(可能为手动过程)，用于恢复的非指导式手 动过程。

○0层–系统故障，不知道用于恢复的状态或步骤。

与计划中断相关的各种实例包括以下项：

○5层–响应于物理服务器、虚拟机和应用资源(包括中间件)事件 的自动撤离。向用户通知事件和解决方案。

○4层–响应于物理服务器和虚拟机事件的自动撤离。没有响应于 AR事件的自动撤离。向用户通知事件和解决方案。

○3层–某些自动撤离过程，但需要人为干预。

○2层–状态信息可用，用于撤离的指导式手动过程。

○1层–状态信息可用(可能为手动过程)，用于撤离的非指导式手 动过程。

○0层–系统受损，不知道用于撤离的状态或步骤。

现在将参考根据本发明的一个实施例的弹性能力的自动层内配置。在 一个实例中，上面描述的弹性层可以主要由包括这些层的软件资源和关联 管理结构的能力定义。在每个层中，可以基于用户对所需弹性FOM的指 定，自动设置这些资源的组成和配置(包括冗余级别、冗余管理策略、位 置约束等)。在本文其余部分描述了简单优化计算的一个实例。

在一个实例中，可以通过客户输入覆盖任何这种自动选择的配置。在 这种情况下，弹性框架的弹性审计能力可以负责向客户定量指示这种覆盖 的影响。

现在将参考根据本发明的一个实施例的组成。在一个实例中，使多个 可用性管理器一致地协同工作可以是高维问题。弹性框架可以容纳、抽象 和协调受管资源的组成以及资源管理器。在该实例中，可以存在三个主要 的可组合性维度：垂直-水平组成、空间组成以及行为组成。在针对解决高 维可组合性问题定义有用的弹性框架中，存在的挑战是在该空间中隔离有 用的轴和主题，分析它们，并且证明可以实现它们。现在将参考根据本发 明的一个实施例的垂直、水平和混合组成。复杂的弹性结构可以包括多个 可用性管理器，每个在它自己的控制域中操作。

在某些情况下，给定AM的受管资源将封装在另一个AM的受管资源 中。这种情况的一个实例是当诸如TSA之类的WAM在集群(该集群本 身运行在VAM(黑盒可用性管理器)管理的虚拟机集合上)上运行时。 使负责这些嵌套资源的AM一致地协同工作的重要问题称为垂直组成。

在其它情况下，可以存在由一个或多个AM管理的分散资源组。这种 情况的一个实例是其中一个服务器和应用资源集合位于一个裸机TSA集 群中，而另一个分散但相关的服务器和应用资源集合位于裸机HACMP集 群中。使负责这些分散资源的AM一致地协同工作的问题称为水平组成。

垂直组成的受管资源还可以在某些级别被水平组成。例如，由TSA WAM管理的资源可以位于由VAM管理的VM集合的一个子集上，并且 由HACMP WAM管理的资源可以位于由该同一VAM管理的该VM集合 的另一个子集上。此问题在此称为混合组成(在一个具体实例中，可以考 虑与HACMP集群协同工作的TSA集群(它们都不由VAM管理)，或 者可以考虑VAM管理的两个集群(例如一个在x上，一个在P上，它们 必须协同工作))。

现在将参考根据本发明的一个实施例的空间组成。垂直、水平或混合 组成结构(例如，弹性IT结构)的实现需要考虑如何针对对等资源和针 对组成这些结构(和/或这些结构所依赖)的资源，在空间定位活动和不活 动(即，备份)资源，如在此描述的那样。这称为空间组成问题，并且通 常通过不同管理器可以收集的并置、反并置、亲和性和反亲和性约束集合 确定。这些要求影响虚拟机中的应用(白盒)资源、物理服务器中的黑盒 VM以及数据中心中的物理服务器的初始和后续放置、故障转移和迁移。 在一致的弹性配置中，通常必须始终共同满足所有这些约束。

在一个实例中，以下操作可以是关键属性：基于弹性层和用户的弹性 品质因数的定量指定，自动确定和实现适当的空间组成约束。

因为许多管理问题可以收集空间组成约束，所以构造管理域中性的分 类很有用。一个实例—弹性激发的成对约束的层次结构—可以定义如下(仅 针对故障给出反并置约束实例，但还可以具有并置的计划维护方面)：

●站点—资源必须在不同站点中，以便单一站点故障不会同时禁用指 定的活动或不活动(即，备份)资源。

●域—资源必须在不同IT(例如，故障包含区域、SPOF、网络、电 源、存储、管理)域中，以便单一IT域级别故障不会同时禁用资 源。

●机架—资源必须在不同机架或子机架基础架构中，以便单一机架或 子机架范围故障不会同时禁用资源。

●服务器—资源必须在不同服务器中，以便单一服务器硬件故障不会 同时禁用资源。这是在VAM系统中表达的典型反并置级别。

●OS—资源必须在不同OS中，以便单一OS实例故障不会同时禁用 资源。但是，如果未断言服务器反并置并且使用虚拟化，则单一物 理服务器故障可以同时禁用它们。

●容器—资源必须在不同容器中，以便单一容器故障不会同时禁用资 源。但是，如果未断言OS反并置，则单一OS故障可以同时禁用 它们，并且如果未断言服务器反并置并且使用虚拟化，则单一物理 服务器故障可以同时禁用它们。

●无—没有关于资源的反并置约束。

在另一个实例中，协调的可用性管理器(AM)操作的两个关键元素 可以是：(1)在可用性管理器之间正确解释和传送空间组成要求；以及(2) 将一组给定空间组成要求准确地变换为特定可用性管理器的通用语言。因 为不同的AM通常具有不同的放置接口、能力和底层模型，所以通常不会 将单个放置模型应用于所有可用性管理器。因此，以下操作可以很重要： 能够从下面描述的通用放置约束概念转换为给定AM的特定放置能力。

现在将参考根据本发明的一个实施例的行为组成。在该实例中，行为 组成指除了禁用一个或多个AM的简单但有时不可避免的原理之外的原 理，组合式可用性管理器响应于故障而使用这些原理动态互操作。可以具 有多个复杂因素。组合式AM机制可以干预，AM机制可以在给定AM中 不一致，并且根据事件类型不一致(例如，Web/应用/数据库服务器AM 机制可以在给定弹性层中有所变化)。

在一个实例中，行为组成可以主要由弹性层的规范确定，并且其次由 组成的可用性管理器中的详细配置参数(例如心跳间隔、检查点间隔等) 的设置确定。

一个重要的弹性框架原理可以是寻找互操作性模式，其中组成中的可 用性管理器不需要修改以便在该组成中一致地操作。因此，在一个实例中， 解决方案不需要修改例如HACMP或VMControl。相反，操纵现有功能和 接口以便实现一致的互操作性。这可以通过另一个弹性框架原理促进，该 原理可以用于将组成的可用性管理器的可能行为限于明显小于它们能够的 数量。

多个管理器的这种受限组成可以由称为弹性框架编排器(例如参见图 2)的系统管理实体执行。在一个实例中，这种弹性框架编排器可以提供一 个或多个有用的聚合行为。

现在将参考根据本发明的一个实施例的体系架构设置。“弹性框架编 排器”可以使用来自用户接口的简化弹性设置，然后编排白盒和黑盒可用 性管理器的部署和配置。图2示出其中可以驻留该功能的一个实例。在一 个具体实例中，可以将“弹性框架编排器”产品化为现有系统管理产品(例 如IBM Systems Director)、Tivoli产品(例如TSAM)或者这两者的一 个组件。

在一个实例中，可能希望弹性框架编排器不在编排对故障的响应中具 有运行时角色(在该实例中，该功能可以是单独可用性管理器的职责，单 独可用性管理器可以处理其业务，而不知道它们是较大弹性管理结构的一 部分)。在另一个实例中，弹性框架编排器可以在编排对故障的响应中具 有运行时角色。

现在将参考根据本发明的一个实施例的地理分散的灾难-弹性。

在各种实例中，弹性框架还旨在描述具有以下能力的IT结构：在地 理上分散，并且容忍通过站点级别空间组成术语描述的计划和/或计划外站 点级别中断。

图4示出使用IBM的系统管理产品的地理分散的灾难-弹性配置的一 个实例，其包括站点A(框图元素401)和站点B(框图元素403)。每个 站点包含能够支持应用的物理服务器资源以及工作负载的虚拟资源。该配 置可以被视为以主动-主动或主动-被动模式运行。该实例将涉及支持主动- 被动模型的配置。

在该实例中，Tivoli Systems Automation(TSA)产品负责确定站点受 损，以及需要恢复工作负载或者以其它方式将工作负载迁移到另一个站点 (作为整个站点故障、整个站点计划中断或者部分站点故障的结果)。在 每个地理分布的站点中，TSA包含关于服务器(或VM)的至少一个实例。 它执行跨站点心跳和某些元数据的交换，监视它所在的站点，并且编排资 源在主站点上的清除以及资源在辅助站点上的提供。

在该实例中，IBM System Director的VMControl功能负责站点中的 黑盒VM的详细监视和操纵(包括可用性管理)。为此，ISD/VMC的至 少一个实例位于每个站点上。TSA包含脚本，其负责经由调用VMControl  REST API，在给定硬件池上提供虚拟机。根据在此描述的原理，如果适 于使用弹性框架编排器同样一致地部署和配置白盒可用性管理器，则可以 扩展该脚本。

在该实例中，该脚本还负责配置虚拟机所需的共享存储器。这包括确 保将来自主站点的VM元数据(OVF文件等)和其它元数据复制到某个 位置，辅助站点可以从该位置访问该数据并且执行VM恢复。这可以经由 使用共享存储的常规复制特性(例如，高端存储系统中的PPRC)实现， 或者使用更高级的基于云的存储方案实现。

现在将参考根据本发明的一个实施例的使用虚拟化的容灾(参见图 5)。

演示模拟以下能力的原型：检测和编排将虚拟机集合的较小站点范围 故障转移到备份站点。该项目展示多种方法(但不一定是灾难恢复(DR) 解决方案的基本原理的所有方法)。

在该实例中，创建两个x86服务器集合(类似于站点)，每个集合能 够运行CAM(连续可用性管理器)产品(参见元素507和509)。(该 CAM产品在2007年作为Director虚拟系统管理产品的一部分发布。)开 源LinuxHA产品监视两个站点(参见元素501—广域集群；503—集群控 件；以及505—集群控件)。编写多个LinuxHA脚本以便编排站点监视、 数据复制和站点故障转移。编写“sitemon”脚本以便判定CAM集群是否 操作，并且使用专用CAM命令行API(相当于最终的VMC REST API) 在另一个站点上提供CAM集群。实现“replicamon”脚本，其负责每当 向CAM集群中添加新VM时，将VM映像复制到辅助站点，并且确保将 该VM重新启动所需的记录复制到辅助站点。在站点故障转移时，将该信 息提供给虚拟资源放置服务的研究版本，以便确定将VM放在辅助站点上 的何处(未假设主站点和辅助站点相同)。基于推荐的放置，sitemon脚 本在辅助站点上的物理服务器上部署和启动VM。

在该实例中，没有在运行时将VM映像和数据从主站点复制到辅助站 点。如上所述，仅当在主站点上实例化VM时，才复制映像和数据。更频 繁地更新辅助站点的映像和应用数据是一种能力，其可以应用于可用DR 解决方案，并且(在一个实例中)可以利用IBM的数据地理复制产品和研 究活动。

在该实例中，使用专用CAM命令行API执行在辅助站点上实例化 VM。在另一个实例中，可以使用VMControl REST API执行在辅助站点 上实例化VM。

在该实例中，使用LinuxHA集群产品。在另一个实例中，可以使用 IBM TSA产品。

现在将参考根据本发明的一个实施例的垂直组成的白盒和黑盒可用性 管理器。在演示中，关于白盒和黑盒可用性管理器协同工作的可行性，根 据弹性框架原理和选定弹性层，执行以下操作：通过自动创建和执行基于 弹性层配置可用性管理器的脚本，在两个弹性层下使用两个垂直组成的可 用性管理器进行部署和故障处理。

针对垂直组成的可用性管理器，在该实例中，实现针对VMControl 产品建模的简单虚拟机可用性管理器。该软件具有以下能力：检测物理服 务器或VM出现故障，并且通过通知用户或者重新启动受影响的VM(在 隔离VM故障的情况下，在本地重新启动，或者在物理服务器故障的情况 下，在另一个物理服务器上重新启动)来响应该故障。这种简单的VAM 使用脚本实现，并且能够管理x86硬件上的Xen VM的可用性。在该实例 中，在VM中使用SLES10操作系统。

在该实例中，使用Tivoli Systems Automation产品在Xen VM中实现 白盒可用性管理器。该产品具有以下能力：监视用户定义的应用资源(例 如进程和其它用户级别对象)的运行状况，并且重新启动它们(使用其资 源特定的恢复脚本)或者忽略故障，具体取决于弹性层。如果启用，则执 行资源恢复，在隔离资源故障的情况下，在本地执行，或者在OS或服务 器故障的情况下，在另一个OS上执行。在另一个实例中，可以应用基于 HACMP(或PowerHA)和WebSphere的更复杂白盒行为。

针对空间组成和控件，在该实例中，空间组成指如何将受管资源放到 其包含资源中。注意，在几乎任何弹性层中，都可能需要在某种程度上考 虑空间组成。

在该实例中，具有两组受管资源：应用资源和虚拟机。使用TSA实现 应用资源放置(在该实例中)，使用VMControl管理VM放置(在该实 例中)。

针对分散，出于本公开的目的，速记符号适合于在垂直组成结构中跨 其包含资源分散资源的程度。

更具体地说，定义实值“应用资源分散”，其确定如何跨虚拟机分配 这些AR。AR_Dispersion为0意味着将AR全部放在一个VM上， AR_Dispersion为1意味着将每个AR放在不同VM上。中间值意味着相 应中间分散程度。在该实例演示中，仅可实现少量的AR_Dispersion因数， 因为x86服务器上的有限磁盘空间限制了可以实例化的VM映像数量(3)。

同样，定义实值“虚拟机分散”，其确定如何跨物理机分配VM。 VM_Dispersion为0意味着将VM全部放在一个物理机上，VM_Dispersion 为1意味着将每个VM放在不同物理机上。在该实例演示中，仅可实现少 量的VM_Dispersion(0和1)，因为演示仅具有四个物理机。

在图6A的实例中示出这些分散的效果，其中垂直地组成应用资源 601A-601D、虚拟机603A-603D和物理服务器605A-605D。

该实例的演示支持AR_Dispersion为0和1。AR_Dispersion为0意味 着可以将所有应用资源放到单个OS映像中，AR_Dispersion为1意味着 不应将任何两个应用资源放到同一OS映像中。

在该实例中，可以通过以下因素增强每个层，其中每个因素可以强烈 影响层中的弹性品质因数，并且可以基于客户的弹性要求自动确定每个因 素。

●工作负载要求之外的其它应用资源数量。

●实值“应用资源分散”，其确定如何跨虚拟机分配这些AR。 AR_Dispersion为0意味着将AR全部放在一个VM上， AR_Dispersion为1意味着将每个AR放在不同VM上。中间值意 味着相应中间分散程度。

●实值“虚拟机分散”，其确定如何跨物理机分配VM。VM_Dispersion 为0意味着将VM全部放在一个物理机上，VM_Dispersion为1意 味着将每个VM放在不同物理机上。

现在将参考根据本发明的一个实施例的白盒空间组成的解释和实现。

在TSA中，在创建资源的脚本中使用mkrel命令执行应用资源的OS 级别反并置约束的指定(尽管可以在定义资源之后的任何时间执行 mkrel)。在一个实例中，弹性框架编排器基于弹性层和AR_Dispersion自 动生成TSA关系，并且将这些关系插入到资源创建脚本中。如果 AR_Dispersion等于0，则不需要反并置约束。以下自动生成的脚本片段描 述了三个反并置(例如，AR_Dispersion＝1)应用资源“wally”、“betty” 和“elizabeth”的集合。

…

mkrel-p AntiAffinity-S IBM.Application:betty-G IBM.Application:wally  betty_anticolloc_wally

mkrel-p AntiAffinity-S IBM.Application:elizabeth-G IBM.Application:wally  elizabeth_anticolloc_wally

mkrel-p AntiAffinity-S IBM.Application:wally-G IBM.Application:betty  wally_anticolloc_betty

mkrel-p AntiAffinity-S IBM.Application:elizabeth-G IBM.Application:betty  elizabeth_anticolloc_betty

mkrel-p AntiAffinity-S IBM.Application:wally-G IBM.Application:elizabeth  wally_anticolloc_elizabeth

mkrel-p AntiAffinity-S IBM.Application:betty-G IBM.Application:elizabeth  betty_anticolloc_Elizabeth

…

注意，在该有限资源演示中，使用反亲和性约束代替反并置约束。这 允许TSA跨OS分配资源，此时OS足以用于支持整个反并置，但在将 OS数量降低到少于资源数量的OS故障的情况下并置资源，因此尽管在不 期望的并置状态下也保持所有资源在线。当足够的OS映像在线以便支持 整个反并置时，TSA重新分配资源。

现在将参考根据本发明的一个实施例的黑盒空间组成的解释和实现。

在虚拟机可用性管理器中，使用虚拟资源放置服务建议(VRPS)接 口指定服务器级别反并置。基于VM_Dispersion因数，可以动态创建这些 反并置建议，并且在请求VM放置之前将它们提供给VRPS。

以下XML实例片段示出VRPS合并建议的句法，该建议指示VM  websrv2和websrv3不能位于同一物理机上。当VM_Dispersion等于1时， 在该实例中针对所有VM设置类似的成对反并置。注意，维护这些约束， 并且当要求VRPS在服务器发生故障或退出服务的情况下计算重新放置时 实施这些约束。

现在将参考根据本发明的一个实施例的行为组成控件。

在该实例中，选定弹性层主要影响可用性管理器的行为组成。在该弹 性框架演示中创建的任何组成中，未修改各种可用性管理器的行为。

在该实例中，当选择弹性层5时，VAM和WAM均被激活并且能够 响应故障。注意(在该实例中)必须在初始部署时或者在故障恢复之后使 VM反并置约束与AR反亲和性约束保持一致。弹性框架负责这一点，因 为WAM或VAM通常互不知晓。

下面表1示出在故障模式下执行的操作，这些操作在该实例(弹性层 5)中展示。注意，通用术语“恢复”在该演示中指重新启动应用资源或 VM，但在更复杂的VAM和WAM策略中，它可以表示更复杂的恢复机 制，例如“从检查点恢复”。

表1—执行的操作

当在该实例中激活弹性层4时，激活VAM但停用WAM。这对应于 通常由常规黑盒虚拟机可用性管理器提供的可用性管理级别。下面表2示 出该实例的该层的故障处理行为(弹性层4)。

表2—执行的操作

在另一个行为组成实例中：

●白盒

○如果请求弹性层5，则弹性编排器使用TSA samctrl-M F命令 自动启用完全TSA自动化(导致白盒可用性管理)。如果请求 弹性层4，则弹性编排器使用TSA samctrl-M T命令自动禁用 TSA自动化。

●黑盒

○在层4和5中均启用黑盒可用性管理。当针对较低弹性层禁用 黑盒可用性管理时，使用适用于选定黑盒可用性管理器的API 执行该管理。

例如，如果使用IBM VMControl产品，则可以将其配置为经由其外 部发布的REST API响应或不响应相关故障— http://publib.boulder.ibm.com/infocenter/director/sdk/index.jsp？topic＝/com.ibm.vmcontrol.ws.doc/html/vmc2_2_api_sdk.html(其全部内容在此引入作为参 考)。

现在将参考根据本发明的一个实施例的演示结构(参见图6B)。

针对该实例的受管环境，方框685A、685B、685C和685D表示用于 托管VM和AR的x86物理服务器集合。这种异构服务器整体(ensemble) 以不同方式运行Xen系统管理程序(其中SLES10或SLES11在dom0 中运行，参见方框690A、690B、690C和690D)、Red Hat裸机、Windows 裸机和Windows Hyper-V。共享存储器不可用，因此直接将所有VM映像 放在物理服务器的本地存储器中。此外，不将虚拟可用性管理代理代码本 身放到dom0中—在该演示中，经由受管系统外部的ssh监视实现所有VM 和服务器故障检测。

在该实例整体中，所有VM(方框683A、683B、683C)基于SLES10， 并且仅与基于SLES10的系统管理程序兼容。因此，检测服务器的体系架 构能力，并且实施虚拟资源放置服务中的体系架构兼容性约束能力以便防 止不兼容的放置。这通过以下操作自动确定：检查VM的vmconfig文件， 将其内容与获得的物理服务器的OS参数相比较，并且适当地设置VRPS 约束文件。

该实例的每个VM都预先安装了Tivoli System Automation(方框 684A、684B、684C)(尽管在另一个实例中，弹性编排器(方框686)可 以在部署时安装它)。此外，配置每个VM以便它能够运行任何或全部应 用资源(方框681A、681B、681C)。注意，每个VM/Tivoli System Automation 组合683A/684A、683B/684B、683C/684C都具有在方框699/698示出的类 型。进一步，注意每个应用资源681A、681B、681C都具有在方框697示 出的类型。

针对该实例的管理组件，提供各种组件，它们负责管理受管环境的初 始部署和运行时可用性。

在该实例中，可以实现“简单便携式可用性管理器”(SPAM)(方 框687)代替产品级别VMControl软件。另请参见图7，其示出简单便携 式可用性管理器窗口701和websrv1窗口703。在该实例中，该SPAM组 件负责收集所有硬件和软件清单，评估物理服务器及其关联的系统管理程 序的运行状况，检测体系架构不兼容性，并且评估它负责的每个VM的运 行状况。

当要求执行VM部署时，SPAM引入物理和虚拟服务器列表以及弹性 层，动态构造包含体系架构兼容性和反并置约束的VRPS建议文件，从 VRPS原型代码请求放置，并且使用ssh会话执行将VM放置到dom0中。 当要求执行运行时可用性管理时，SPAM使用到dom0的ssh命令以及到 VM本身的ssh命令，监视它负责的所有VM以便评估其运行状况。如果 VM发生故障，则SPAM指示dom0确认删除VM，然后在同一服务器上 重新启动该VM。

SPAM还使用到dom0的ssh命令监视所有物理服务器。如果一个或 多个物理服务器发生故障，则SPAM从其配置文件中删除该物理服务器 (多个)，对VRPS进行另一个调用以便确定孤立虚拟机的新放置，并且 针对这些VM执行重新部署过程。

当(例如)启用弹性层5时，Tivoli Systems Automation使用资源管 理脚本的“监视”方法监视所有应用资源，并且当确定资源失败时，在本 地或远程执行“启动”脚本。弹性框架编排器按照下面描述的方式配置 TSA。在该实例中，配置、初始化并且在较小程度上编排上述组件的中央 组件是弹性框架编排器。它引入应用资源及其关联TSA资源定义文件和管 理脚本列表、VM列表、物理服务器列表、弹性层以及AR_Dispersion和 VM_Dispersion。

当要求部署特定弹性层时，编排器(在该实例中)执行以下功能：

1.部署VM。这需要获得物理服务器整体的描述，创建体系架构兼容 性约束，基于VM_dispersion创建VM反并置约束，计算初始VM放置， 并且使用到dom0的ssh命令部署和启动VM。

2.部署TSA应用资源。这需要获得部署的VM的描述，基于 AR_dispersion计算AR反亲和性约束，创建TSA AR定义，创建TSA域 和AR部署脚本(如果需要，则包括上面列出的mkrel命令)，并且最后 使用到选择用于托管资源的VM的ssh命令启动TSA资源。

a.如果请求弹性层5，则使用TSA samctrl-M F命令启用完全TSA 自动化。

b.如果请求弹性层4，则使用TSA samctrl-M T命令禁用TSA自 动化。

在一个实例中，上述各种故障恢复中未涉及编排器。在另一个实例中， 可以在各种故障恢复中涉及编排器。在这点上，考虑以下情况，其具有其 中采用WAM和VAM两者的弹性层5配置：

1.当由于VM故障或服务器故障而导致VM消失时，TSA通常首先响 应并且在另一个VM上恢复受影响的AR(这可以导致可能需要管 理的争用条件)。TSA驱动的恢复可能违反也可能不违反AR反亲 和性约束，具体取决于在故障之后剩余多少个VM。这对于当前点 并不重要。

2.因为采用VAM，所以最终将在同一物理服务器或另一个物理服务器 上重新启动该VM。在一个实例模型中，可以从任意状态重新启动 VM映像，范围从崩溃的VM映像到已设置检查点的VM，到原始 VM映像。

3.如果没有全面调查该恢复的映像的配置，则通常无法知道已针对该 VM映像执行何种TSA配置，因此最安全的做法是从映像的完整 TSA配置开始。可能需要其它参与，因为取决于故障映像的状态， 它可能自动重新加入TSA集群，或者它(和TSA集群本身)可能 必须被重新配置以便允许该VM重新加入集群。

4.因此，在一个实例中，编排器必须对VAM恢复的任何VM映像执 行TSA配置。该实例演示执行完全恢复弹性配置所需的所有已知配 置，但这并没有指出故障恢复中可能需要涉及编排器。

现在将参考根据本发明的一个实施例的用于部署的多个高级命令(该 部分包含弹性框架编排器演示使用的主要脚本的列表和简要描述)：

RF_deploy_Framework<Resilience_Tier><AR_dispersion> <VM_dispersion><Physical Server List><Virtual Machine List>

该顶级脚本经由调用下面描述的较低级脚本，部署VMS，准备TSA 集群，以及部署TSA应用资源。在该演示中，TSA资源在脚本自动扫描 的单独目录中列出。在另一个实例中，目录路径是参数。

RF_deploy_VMs<Resilience_Tier><VM_dispersion><Physical  Server List><Virtual Machine List>

该脚本在<Physical Server List>上的<Virtual Machine Lis>上部署和 启动VM，并且根据弹性层设置反并置约束和可用性管理。

RF_prep_TSA_cluster<Resilience_Tier><AR_dispersion><Virtual  Machine List>

该脚本准备和启动包括<Virtual Machine List>的TSA域，以便接受 应用资源。

RF_deploy_TSA_resources<Resilience Tier><AR_dispersion> <Virtual Machine List>

该脚本基于包含在单独目录中的期望TSA资源列表，动态创建TSA 元数据(资源管理脚本和资源定义文件)并且将其部署到<Virtual Machine  List>。该例程还创建和执行mkrel命令以便创建任何所需的反亲和性约束， 以及创建和执行samctrl命令以便启用或禁用TSA自动化。

RF_recover_VM_TSA<Resilience_Tier><VM_dispersion><Virtual  Machine List><Physical Machine List>

该脚本负责在VM故障之后编排VM恢复。基于假设按照<Virtual  Machine List>指示运行的虚拟机、按照<Physical Server List>指示的当前 可用物理服务器，该脚本判定是否缺少任何VM，根据弹性层计算所述VM 的放置，并且部署和启动它们。

此外，它执行少许WAM/VAM编排，因为它必须等待TSA集群通知 (或不通知)新恢复的VM，并且如果未将VM正确添加到TSA集群， 则强制TSA集群接受它。

SPAM<Resilience Tier><Physical Server List><Automated  Recovery Mode>

在后台启动该脚本以便定期轮询物理服务器列表，确定在它们上运行 的虚拟机，并且如果VM缺少并启用自动恢复模式，则调用 RF_recover_VM_TSA。

各种实用工具脚本(此处未列出)可以注入应用资源、虚拟机和物理 服务器故障，恢复故障组件，关闭TSA资源，解散TSA集群和/或关闭虚 拟机集合。

现在将参考根据本发明的一个实施例的多个实例演示方案(在该演示 中，具有四个能够运行工作负载的物理服务器、三个VM和三个AR)：

1.弹性层4部署和操作

1.1.RF_deploy_Framework Tier4,AR_dispersion＝1, VM_dispersion＝1(无WAM，仅VAM)

1.2.弹性层4应用资源恢复

-射中AR，显示没有发生恢复，因为WAM不存在

-手动恢复AR

1.3.弹性层4VM恢复

-射中VM，显示发生VM恢复

-但没有AR恢复，因为WAM不存在，并且AR未在 OS初始化表中

-手动恢复AR

2.弹性层5部署和操作

2.1.RF_deploy_Framework Tier5,AR_dispersion＝1, VM_dispersion＝1(WAM和VAM)

2.2.弹性层5应用资源恢复

-射中AR，显示发生恢复

2.3.弹性层5VM恢复

-关闭SPAM自动恢复，因此可以控制如何快速发生操作。

-射中VM，显示在另一个VM上发生AR恢复

-手动恢复VM，显示该VM重新加入TSA域，并恢复AR冗余

2.4.弹性层5物理服务器恢复

-射中物理服务器，显示发生AR恢复

-在另一个服务器上手动恢复VM，显示恢复AR冗余

现在将参考根据本发明的一个实施例的弹性层分析。

通常与弹性框架的简化原理不一致，以便期望更多客户关注行为和空 间组成、分散、弹性编排等。他们通常对其工作负载的弹性以及实现弹性 所需的成本更感兴趣，具体地说，就在此描述的弹性品质因数而言的工作 负载弹性。

在这点上，面向可靠性的工作负载(例如SOA或电子商务工作负载) 是这样一种工作负载：其中主要问题是在每个时间点满足最低服务水平协 议。这些工作负载需要给定的最少数量应用资源始终可用以便提供可接受 的吞吐量，并且受由一个或多个服务降级事件在任何给定时间禁用的应用 资源数量的影响。对于这种面向可靠性的工作负载，要最小化的FOM可 以是满足SLA所需的少于给定基准数量的应用资源在任何时间点可用的 概率。出于该实例的目的，将该FOM表示为P(SLA Violation)。

具有多种可能的建模使用。该实例中展示的使用是确定层中的新部署 满足FOM所必需的参数(例如，备用AR数量、分散等)。

现在将参考根据本发明的一个实施例的建模策略。

对于该实例，因为假设客户想要指定P(SLA Violation)，所以必须将 这些要求转换为可操作参数，例如AR数量、VM、物理服务器和分散。 确定这些参数以便它们满足这些客户指定将组成多维搜索问题，该问题可 以表述为(这是用于将客户的弹性FOM要求转换为空间组成映射的实例 算法的概要)：

●给出：

○弹性层、满足SLA所需的AR数量以及最大P(SLA Violation)

●搜索

○AR数量,AR_Dispersion(暗示VM数量)和VM_Dispersion(暗 示物理服务器数量)

●以便满足要求

○P(SLA Violation)<max P(SLA Violation)

●同时最小化

○就服务器、VM和AR数量而言的成本

一种用于执行可以在本发明各种实施例的上下文中使用的分析优化 (例如，以便满足要求x同时最小化y)的实例方法，可以在Adam等人 于2009年2月21日提交的标题为“DECENTRALIZED APPLICATION  PLACEMENT FOR WEB APPLICATION MIDDLEWARE(WEB应用 中间件的分散应用放置)”的美国专利公开2009/0157855(其全部内容在 此引入作为参考)中找到。

一旦发现AR数量和分散，可以将这些设置映射成指定AM的空间组 成，如本公开中描述的那样。

还可以计算SLA违反的预期持续时间(MTTR，以小时为单位)，以 及可能导致也可能不导致SLA违反的个体服务降级事件之间的预期时间 (这不应与SLA违反混淆，而是主要是可用性管理活动的度量)。现在将 参考根据本发明的一个实施例的模型描述。提供一种用于展示原理的实例 分析模型。对例如故障和恢复率做出合理假设，以便结果在广泛的合理概 率内有效。下面进一步讨论建模假设。

在根据一个实施例的研究和优化循环中，按如下方式计算品质因数(计 算由于多个同时发生的服务降级事件而导致违反SLA的概率)：

○给出包含某一数量的应用资源、虚拟机和物理服务器的配置，并且 假设公平分散所有资源，通过以下操作计算给定数量应用资源在任 何给定时间不可用(因此，可能违反SLA)的概率：暴力枚举AR、 VM和物理服务器故障的所有可能组合，计算多少个AR可用于每 个故障组合，并且如果给出每个组件的故障和恢复率，则计算发生 该组合的概率。如果特定故障组合中的AR数量不足以满足所需的 SLA，则以该配置的概率来增大SLA违反概率(在一个具体实例中， 在T61p上使用该计算优化500个AR的放置需要大约4秒)。

现在将参考根据本发明的一个实施例的模型使用和结果。

如前所述，本发明的各种实施例可以提供一种分析建模框架，其用于 使客户免于了解配置详细信息，并且允许他们查看对其具有业务重要性的 系统弹性。因此，如果给出客户实现其业务目标所需的应用资源数量，以 及该数量AR不可用的最大可允许概率，则可以使用该建模确定最低成本 配置。在此提供这种使用的一个实例。

例如，假设客户指定他需要至少500个AR以便满足其SLA，并且接 受500个AR不可用的的概率最多为0.0001。所有这一切均以最低成本实 现。

首先参考例如弹性层5(在该实例中，弹性层5属于其中采用WAM 和VAM两者的情况)：

表3—输入参数

组件 MTBF(小时) MTTR(小时) 物理服务器 10000 0.083 系统管理程序 2000 0.083 VM 2000 0.083 AR 1000 0.083

表4—优化结果

svrs vms_svr vms ARs_vm AR MTBSDE MTTR_SLA_Viol P(SLA_Viol) 1 1 1 500 500 2.00 0.09 4.072509e-02 3 17 51 10 510 1.86 4.20 2.372791e-04 4 13 52 10 520 1.82 4.57 1.991574e-04 11 5 55 10 550 1.71 0.07 2.346053e-05

上面的表(优化结果)显示当实例优化运行(关于弹性层5)走出从 最低成本点(即，没有备用AR，并且所有分散均等于0)开始的搜索空间 时的汇总输出。表的每一行表示较之前一行的关于P(SLA Violation)的改 进。

对于该优化实例(在T61p上计算需要大约4秒)，如果需要500个 AR，并且具有少于500个AR的最大可接受概率为1.000000e-04，则最低 成本配置为11个服务器，每个服务器5个VM共计55个VM，每个VM 10 个AR共计550个AR(在另一个实例中，通过增加搜索粒度和/或更智能 地搜索，以更多计算时间为代价，可以发现更低的成本配置)。

现在将参考例如弹性层4(在该实例中，弹性层5和弹性层4之间的 建模区别是没有白盒可用性管理器。其分析影响是用于恢复AR的平均时 间不是5分钟(与自动恢复一致的间隔)，而是(任意)增加到50分钟— 该间隔被视为使管理人员注意并手动重新启动AR的时间范围)：

表5—输入参数

组件 MTBF(小时) MTTR(小时) 物理服务器 10000 0.083 系统管理程序 2000 0.083 VM 2000 0.083 AR 1000 0.83<<<<<

表6—优化结果

svrs vms_svr vms ARs_vm AR MTBSDE MTTR_SLA_Viol P(SLA_Viol) 1 1 1 500 500 2.00 0.56 3.380639e-01 3 17 51 10 510 1.86 11.91 8.650216e-04 4 13 52 10 520 1.82 45.62 1.998299e-04 11 5 55 10 550 1.71 0.54 1.858381e-04 15 4 60 9 540 1.73 3.71 1.988057e-06

上面的表(优化结果)显示关于弹性层4的汇总输出。对于该优化实 例，如果需要500个AR，并且具有少于500个AR的最大概率为 1.000000e-04(与层5要求相同)，则最低成本配置为15个服务器，每个 服务器4个VM共计60个VM，每个VM 9个AR共计540个AR。

在另一个实例中，可以增强优化循环以便最小化P(SLA Violation)和 MTTR_SLA_Viol两者。在这种分析中，目标函数可以是矢量而不是标量。

现在将参考根据本发明的一个实施例的多个分析建模假设。

1MTBF和MTTR是代表性的，而不是实际的

2每次仅一个资源发生故障

3即时故障检测

4准确故障标识

5修复是确定性的

6所有软件故障都是短暂的，所有硬件故障都是永久性的

7所有资源的故障率都不变

8资源故障是独立的

9不实施VM或Svr容量限制

10工作负载可从容降级—服务损失与不可用服务单元数量成线性比 例

11在故障处理期间停止时钟

12硬件故障不相关

现在将参考根据本发明的一个实施例的多个典型客户用例：

○客户可能想要针对给定整体中的VM指定给定SLA，并且确保可以 通过选定可用性策略满足该SLA，以及确保需要什么资源以便满足 该SLA。假设我们知道该SLA的响应时间能力和开销，则本发明 的实施例可以计算给定整体是否可以支持它，以及以什么成本支持 它。

○客户可能仅具有一组有限资源，并且想要知道如果给出这些资源， 则可以提供的最佳SLA是什么。本发明的实施例可以进行反向计 算。

○客户可能预测不断增长的工作负载或者构想配置更改，并且想要知 道该新的较大工作负载是否可以满足现有SLA，以及以什么成本满 足(成本将随工作负载而变化)。本发明的实施例可以提供答案。

○整体本身可能预测不断增长的工作负载，或者进行配置更改，并且 作为响应，可以评估它是否可以继续以便满足其SLA而不需要其它 资源。

○假设已知给定SLA的成本和值，则客户可以根据SLA计费。本发 明的实施例可以提供答案。

○SLA可以在每天的不同时间、每周或每月的不同天等内有所不同。 恢复操作或包括的资源可以更改。本发明的实施例可以响应严格日 历或者学习/预期不断变化的工作负载并且改变SLA。可以使用机器 学习和/或强化学习，针对给定操作简档确定适当的SLA。

现在将参考根据本发明的一个实施例的多个部署选项。

框架可以允许足够的通用性，以便允许使用多个部署引擎部署到多个 环境中。两个实例是Tivoli的TSAM和开源XCAT工具。

TSAM—在一个实例中，增强TSAM依赖性模型和TSAM执行环境， 以便支持该资源关系模式和所需能力。

使用TSAM以允许客户在最高级服务栈(应用服务)指定弹性策略， 自动创建该应用服务所依赖的资源(及其依赖性)，并且自动将所有可用 性策略传播到该高级资源所依赖的所有资源。这可以包括自动将其它资源 添加到服务拓扑以便满足所需可用性目标。这导致满足可用性目标的可重 用服务模板。

将TSAM客户定义的服务拓扑和工作流程变换成EM API和操纵工具 (当可用时，可以例如有机会地使用现有CAM API，或者可以使用适当 的整体定义)。例如：

○将“整体(ensemble)”定义为TSAM资源。

○定义整体属性(包括可用性策略)。

○使用EM API定义整体操纵工具。

○定义设置CAM的FC LUN必需的存储整体操纵工具(可选)。

○定义和实现部署可用性整体必需的工作流程。

○在整体上，使用特定可用性属性，实现客户定义的虚拟系统集合的 TSAM驱动的定义和部署(例如，参见图3的元素305)。

XCAT—在一个实例中，与Toks协同工作，以便使用perl模块通过 REST API部署/设置KVM整体。

现在将参考本发明的另一个实施例。该实施例可提供定义、工具、实 验测量和分析任务的组合：

○定义SLA的定量属性。这些度量应该与由于计划和计划外中断导致 的每天客户动荡相关，并且表示当前和计划可用性产品的能力。计 划中断度量可以包括PFA预测水平、撤离能力、撤离时间和开销。 计划外中断度量可以包括响应时间、恢复时间、恢复点。开销度量 可以包括cpu/网络/存储监视开销、设置检查点成本等。感兴趣的领 域是以下情况：由于故障或高开销而导致的性能下降，以及如何查 看性能下降；未发出故障事件通知但缓慢阻塞的系统并不罕见，并 且是难题。如果知道某个恢复操作可以使其再次运行，则执行该操 作有意义。

○定义当前可以由CAM支持的SLA，以及可以在将来被支持的其它 度量(例如，主动复制)。

○设置CAM集群，并且在定义的工作负载集合下，评估不同的恢复 策略及其效用和成本。一个实例将SLA属性(例如，性能开销)参 数化为工作负载属性(例如，CPU利用率、I/O速率)的函数。当 执行时，存在SLA-成本-工作负载矩阵，其可以用于生成分析框架， 该框架要用于客户所需的假设评估以及恢复和故障转移的模拟。

○如果给出该分析能力，则定义客户需要回答的假设问题。

○构造支持该分析框架必需的资源关系模型。

○使用机器学习和强化学习构造分析框架，其可以使用这些关联评估 客户或整体本身需要回答的各种假设问题。

○提供白盒和黑盒可用性管理。

现在将参考根据本发明的一个实施例的工作负载指定。

在该实例中，工作负载(WL)包括虚拟机、操作系统映像、虚拟化 应用、非虚拟化应用、LPAR、xLPAR、WPAR或其它逻辑容器，该容器 用于计算以下工作：其可以被分配资源要求(CPU、存储器等)、约束(位 置、并置、反并置等)、启动和停止顺序依赖性、优先级以及指示WL“颜 色”的值(下面描述)。可以经由WL映像信息、系统管理或者从工作负 载表征和指定工具(例如TSAM)，提供工作负载资源要求。

注意，本公开的系统和方法可同样而不失一般性地适用于非虚拟化工 作负载、虚拟化和非虚拟化工作负载的组合、应用虚拟化容器、xLPAR分 区和WPAR。术语“WL”可以用于指任何这种环境中的单独工作单元。

现在将参考根据本发明的一个实施例的托管环境指定(参见图8)。

该实例中的硬件被视为位于一个或多个中央电子设备复合体(CEC) 中的“组件”集合。这些组件包括但不限于CPU、高速缓存、存储器、I/O 和存储装置，假设它们并非完全同构。在该实例中，组件本身不能用作服 务器。但是，在高度可配置的设计(例如，Phoenix)中，可以灵活地组合 组件以便产生所需大小的“逻辑服务器”。因此，可以将包含两个CPU 组件、两个存储器组件、两个I/O组件和两个存储装置组件的CEC(被示 出为图8左边的元素801)组合成两个更小的逻辑服务器(被示出为图8 中间的服务器1—元素803和服务器2—元素805)，每个包含每种组件中 的一个，或者组合成一个更大的逻辑服务器(被示出为图8右边的服务器 A—元素807)，其包含所有组件。当然可以设计包含更多或更少组件的 CEC，并且本公开旨在应用于包含任何数量组件的任何数量的CEC。

此外，有时可以从位于不同CEC中的组件组成逻辑服务器，并且可 能出现性能损失，因为组件可能比它们在同一CEC时相距更远。最后， 在某些情况下，根本不能相互组合组件，因为例如它们在不同CEC中并 且它们之间没有电连接，或者因为它们在体系架构上不兼容。

现在将参考根据本发明的一个实施例的可组合硬件的资源关系建模。

在该实例中，每个组件(CPU、存储器、…)可以被视为资源关系图 中的一个节点。该图称为硬件资源图(HRG)。如果两个组件由硬件资源 图中的可组合性关系连接，则可以组合这两个组件以便构成逻辑服务器的 部分或全部。如果组件未由可组合性关系连接，则它们不能组合在一起以 便构成服务器的部分或全部，可能因为它们在体系架构上不兼容，或者它 们没有位于同一CEC中，或者任何其它原因。

边例如可以是：成本(性能)、成本(重新配置时间)。

该方案的一种扩展是在潜在组合的任何两个组件之间关联成本，以便 允许表达如何期望/以何种成本组合这些组件的位置、偏好或其它度量。

如上面定义的，该实例的资源图仅允许描述潜在资源组成。为了允许 描述实现的资源组成为逻辑服务器，可以定义覆盖图(是资源图的子集)， 其称为组合式硬件资源图。在该图中，任何两个资源之间的边指示这两个 资源已组合成逻辑服务器的一部分。注意，为使组成有效，组合式资源图 中的边必须是硬件资源图中的边的子集。根据资源关系建模框架的合并规 则，在资源图中合并已组合成逻辑服务器的硬件资源。

除了灵活地从组件组合逻辑服务器之外，可能在服务器(逻辑或其它) 中创建固件分区方面实现进一步程度的配置，如可能在xLPAR或 PowerVM技术中实现的那样。这构成另一级别的可配置性，相当于将工 作负载静态分配给服务器，并且可以作为工作负载放置服务能力处理。

在另一个实例中，可以提供基于资源要求的存储分配和配置。

在本发明的各种实施例中，提供一种广义概念，其用于基于简化的弹 性设置，配置虚拟机和应用的弹性管理软件的复杂组合的设置。注意，所 公开的框架能够执行以下一个或多个：

●配置外部表的弹性相关参数(例如，自动基于客户提供的弹性设置)。

●提供可被自动配置并集成到更大弹性体系架构的故障转移。

●提供客户级别处的弹性，以及将该弹性指定自动转换为虚拟机和应 用级别可用性管理器的配置。

●提供“地铁图”概念(非常高级和通用的方式，用于跟踪提供和评 估高可用性的ITIL过程中涉及的步骤)和要实现的各种ITIL步骤， 以便调用在此所公开的弹性框架的接口和功能。

●经由基于简化客户弹性设置的自动化，简化与处理等相关的常规复 杂配置、设置和操作步骤(因此使管理员免于执行这些步骤)。

●经由基于简化客户弹性设置的自动化，简化与存储等相关的常规复

杂配置、设置和操作步骤(因此使管理员免于执行这些步骤)。

现在参考图9，该图示出根据本发明的一个实施例的计算系统900的 硬件配置。如图所示，该硬件配置具有至少一个处理器或中央处理单元 (CPU)911。CPU911通过系统总线912与以下各项互连：随机存取存 储器(RAM)914、只读存储器(ROM)916、输入/输出(I/O)适配器 918(用于将诸如磁盘机921和磁带驱动器940之类的外围设备连接到总线 912)、用户接口适配器922(用于将键盘924、鼠标926、扬声器928、麦 克风932和/或其它用户接口设备连接到总线912)、通信适配器934(用 于将系统900连接到数据处理网络、因特网、内联网、局域网(LAN)等)， 以及显示适配器936(用于将总线912连接到显示设备938和/或打印机939 (例如，数字打印机等))。

在其它实例中，可以以任何适当的所需顺序执行在此描述的任何步骤。

所属技术领域的技术人员知道，本发明的各个方面可以实现为系统、 方法或计算机程序产品。因此，本发明的各个方面可以具体实现为以下形 式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、驻留软 件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电 路”、“模块”或“系统”。此外，本发明的各个方面还可以实现为在一 个或多个计算机可读介质中的计算机程序产品的形式，该计算机可读介质 中包含计算机可读的程序代码。

可以采用一个或多个计算机可读介质的任意组合。计算机可读介质可 以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质 例如可以是—但不限于—电、磁、光、电磁、红外线、或半导体的系统、 装置或器件，或者上述的任意合适的组合。计算机可读存储介质的更具体 的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式计 算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦 式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储 器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。 在本文件中，计算机可读存储介质可以是任何包含或存储程序的有形介质， 该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

计算机可读的信号介质可以包括例如在基带中或者作为载波一部分传 播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号 可以采用多种形式，包括—但不限于—电磁信号、光信号或上述的任意合 适的组合。计算机可读的信号介质可以是计算机可读存储介质以外的任何 计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令 执行系统、装置或者器件使用或者与其结合使用的程序。

计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括 —但不限于—无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以任意一种程序设计语言或一种或多种程序设计语言的任意组合 来编写用于执行本发明的各个方面的操作的计算机程序代码，所述程序设 计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++等，或 者一种过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程 序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作 为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、 或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远 程计算机可以通过任意种类的网络—包括局域网(LAN)或广域网(WAN) —连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服 务提供商来通过因特网连接)。

在此参照根据本发明实施例的方法、系统和/或计算机程序产品的流程 图和/或框图描述本发明的各个方面。应当理解，流程图和/或框图的每个 方框以及流程图和/或框图中各方框的组合，都可以由计算机程序指令实 现。这些计算机程序指令可以提供给通用计算机、专用计算机或其它可编 程数据处理装置的处理器，从而生产出一种机器，使得这些指令在通过计 算机或其它可编程数据处理装置的处理器执行时，产生了实现流程图和/ 或框图中的一个或多个方框中规定的功能/动作的装置。

也可以把这些计算机程序指令存储在计算机可读介质中，这些指令使 得计算机、其它可编程数据处理装置、或其它设备以特定方式工作，从而， 存储在计算机可读介质中的指令就产生出包括实现流程图和/或框图中的 一个或多个方框中规定的功能/动作的指令的制造品(article of  manufacture)。

也可以把计算机程序指令加载到计算机、其它可编程数据处理装置、 或其它设备上，使得在计算机、其它可编程装置或其它设备上执行一系列 操作步骤，以产生计算机实现的过程，从而使得在计算机或其它可编程装 置上执行的指令提供实现流程图和/或框图中的一个或多个方框中规定的 功能/动作的过程。

附图中的流程图和框图显示了根据本发明的不同实施例的系统、方法 和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程 图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述 模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的 可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功 能可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上 可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的 功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/ 或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬 件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

注意，上面描述了本发明的某些目标和实施例。本发明可以用于许多 应用。因此，尽管针对特定布置和方法进行了描述，但本发明的意图和概 念适合和适用于其它布置和应用。所属技术领域的技术人员应该清楚，可 以实现对所公开的实施例进行修改而不偏离本发明的精神和范围。所述实 施例应该被解释为仅例示本发明的某些特性和应用。可以通过以不同方式 应用所公开的本发明，以及以熟悉所属技术领域的技术人员已知的方式修 改本发明，实现其它有利的结果。此外，在此所公开的所有实例旨在是示 例性的而非限制性的。