支持不同部署架构的可扩展框架

摘要

描述了一种用于管理在多个部署架构间的服务和资源的方法。该方法由定义对应的部署架构的配置文件开始。依据元模型定义每一配置文件。元模型包括：表示通过网络可访问的服务的服务对象，表示由服务消耗的资源的资源对象，在服务和资源之间的相互关系，在资源之间的相互关系。针对每一配置文件，基于配置文件生成拓扑。该拓扑包括用于执行任务的资源。

说明书

交叉参考

本申请要求申请于2009年7月31日，题目为“Management of  Services and Resources”的美国临时申请第61/230,584号的优先权，以及 申请于2010年3月5日，题目为“Extensible Framework to Support  Different Deployment Architectures”的美国申请第12/718,924号，它们的 全部通过引用被结合于此。

技术领域

本申请一般地涉及在数据中心或者云计算环境中的服务和资源的管 理，以及在一个具体的示例中，涉及支持不同部署架构的可扩展框架。

背景技术

在数据中心环境中，存在完成商业目标或者支持其它服务的许多服 务。在一些上下文中，这些服务可以包括交易(卖物品，查看出售的物品 等)，消息传送和搜索。这些服务都消耗硬件和软件资源。硬件资源的示 例包括计算机(服务器)，网络(交换机，负载均衡器，防火墙等)，存 储(SAN，NAS等)，软件资源的示例的包括操作系统，应用平台堆 (java虚拟机，tomcat servlet容器等)，以及数据库。将这些硬件和软件 资源根据具体服务的需求安排在不同的配置中。配置被称为“部署架 构”。部署架构的示例包括传统三层架构(网络层，应用层，数据库层， 它们的每一个可以具有用于流量分布的负载均衡器)，消息传送基础结构 等。在这些内可以存在变化，例如，可以将负载均衡器成对地部署以提供 高可用性(HA)。传统上，存在针对数据中心环境的每一子集的管理系 统。例如，存在关注管理(例如，配置，健康检查，性能监视等)交换机 的网络管理系统。其它关注应用(例如，应用部署等)。这导致管理系统 的激增。

附图说明

在附图中通过举例而非限制图示了一些实施例，在附图中：

图1是在其中可实践多种实施例的网络环境的框图。

图2是依据多种实施例的管理系统的框图。

图3是依据多种实施例用于使用在域布置中的模型框架的处理的流程 图。

图4是依据多种实施例在资源分类内的对象的层次结构。

图5是依据一些实施例的硬件和软件资源的模型结构的框图。

图6是依据多种实施例与群组相关联的模型架构的框图。

图7是依据多种实施例用于存储数据的模型结构的框图。

图8是在其内可以执行指令集的机器的图表表示，该指令集用于令机 器执行在这里讨论的任何一个或者多个方法。

图9是依据多种实施例的配置文件(profile)创建器的框图。

图10是依据一些实施例构建在两个层中的信息模型的框图。

具体实施方式

描述了使用可扩展模型框架管理在数据中心环境中的服务和服务消耗 的资源的方法和系统。在以下的描述中，针对说明的目的，为了提供示例 实施例的彻底地理解，陈述了许多具体的细节。然而，对于本领域的技术 人员将显而易见的是可以没有这些具体的细节地来实践本发明。对在这里 使用的，可以将以术语“或者”理解为包括或者排除的意义。

在大型企业计算系统中，使用不同系统来提供服务。该系统的示例提 供交易服务，搜索服务，消息传送服务，支付服务以及网络发布服务。因 为每一系统执行单独的功能，所以作为整体的企业计算系统的操作依赖其 它系统的每一个的性能。在使用多于一个系统来执行贸易或者“流程”时 这尤其正确。例如，为了完成在英特网商务系统中的销售，在流程中的特 定时刻可以使用对应于搜索，网络发布，支付和消息传送服务的系统。

使用一个或者多个资源实现系统。系统资源可以是硬件资源和/或软件 资源。硬件资源的示例包括服务器，路由器，负载均衡器等。软件资源的 示例包括操作系统，应用等。

在管理系统的上下文中，将每一被管理的实体(即，服务或者资源) 以它的操作配置，性能和状态(例如，活动状态)的形式来建模。此外， 每一该建模的实体与一个或者多个建模的实体有关以反映现实世界关系。 例如，计算机程序(应用)在操作系统上运行，并且因此在管理系统内的 对应的建模的实体也反映这个关系。所产生的建模的实体(每一实体由指 定它的配置，性能和状态的属性组成)的模型和它们的相互关系的模型称 为信息模型。在建模工具中创建该信息模型并将信息模型存储在模型库中 以例如由系统设计师来使用。

每一服务类型具有部署架构，该部署架构示出多种构成资源，它们的 相互关系以及它们与其它服务的相关性(如果适用的话)。在模型驱动的 管理系统的上下文中，可以以具体的信息模型的形式指定每一服务的部署 架构。在该上下文中，称信息模型为部署配置文件(“配置文件”)。因 此使用该配置文件以其功能的和非功能的准则的形式来指定部署架构。例 如，最简的配置文件可以是“N个服务器”，其中可以将服务器连续地指 派。另一配置文件可以对应于传统的三层架构，该三层架构包括：负载均 衡器，要用作网络服务器的服务器，要用作应用服务器的服务器，要用作 数据库服务器的服务器，以及提供LAN交换和在VLANs之间的第三层路 由的第三层交换机。这三种类型的服务器可以具有不同的能力(例如，数 据库服务器可以为大铁箱，网络服务器可以为刀片服务器或者甚至是虚拟 机)。其它变化可以导致不同的配置文件，例如，可以将负载均衡器安排 为主动—主动(或者主动—被动)配置以提供高可用性。

另一配置文件可以使用三层配置文件以生成另一服务的配置文件。例 如，配置文件可以指定网络服务器(软件)将要被部署在层1服务器上， 应用服务器(软件)将要被部署在层2服务器上，以及数据库将要被部署 在层3服务器上等。在这些配置文件中，在应用服务器中要被部署的应用 代码可以依赖其它服务(例如，日志记录服务)。

在数据中心或者云计算环境中的多种部署架构具有诸如服务器，负载 均衡器，操作系统等之类的许多共同的资源类型。为了让单个管理系统理 解多个部署架构，在配置文件间重用共同的资源类型定义。这通过如图10 示出的那样在两个层中构建信息模型来实现。基模块1002提供诸如服务 器，操作系统等之类的共同的资源类型的定义，而顶层提供专用于诸如交 易1004，消息传送1006，搜索1008，支付1010，网络发布1012之类的 特定服务的资源和服务类型的定义。接着通过将在特定域的服务和资源类 型与在基模块1002中的类型相结合来构建配置文件。

当要部署服务时，关于如下方面来指定它的部署配置：资源的数目和 类型，单独的和/或根据类型的资源的配置参数，接着将合适的资源实例进 行识别和分配。这样做允许管理系统将部署和其它生命周期管理任务自动 化。在本发明的上下文中，在被称为部署拓扑(以下称为拓扑)的规约中 捕获该信息。拓扑是配置文件的实现。拓扑的规约在两个级中进行：逻辑 的和物理的。逻辑拓扑指定资源和它们的基数(例如，10个刀片服务器) 的抽象类型，并且物理拓扑指定资源的具体类型和它们的具体实例(例 如，有资产识别码54321 abcde的IBM LS 20刀片服务器)。

管理系统管理对应于不同配置文件的服务，允许新配置文件的引入， 并且因此随着数据中心或者云计算环境的进化而管理新的服务。此外，其 不修改管理系统的子系统，或者重部署管理系统或者重启管理系统的运行 地来实现此。可以通过提供通用服务管理器，元模型和插件框架来实现这 些目标。

服务管理器负责服务的完整生命周期和服务水平管理。生命周期操作 的示例包括部署，配置，启动，激活，更新等，并且可以作为一个整体在 服务上实施这些操作，或者在由服务使用的具体的或者成组的资源上实施 这些操作。服务管理器的每一实例可以管理遵从同一配置文件的多个服务 实例。具体性在于专用于抽象资源类型(例如，负载均衡器)的控制器 中，以及在于专用于具体资源类型(例如，Citrix NetScaler负载均衡器) 的适配器中。当首先部署服务时，服务管理器分析拓扑并且针对指定的每 一独特的服务和资源来动态加载相对应的控制器和相关联的适配器。

在服务管理器内的每一控制器管理同一服务或者资源类型的多个实 例，这是因为它是针对每一抽象类型而定义的。例如，使用单个负载均衡 器控制器来管理服务中的全部负载均衡器而不管使用的负载均衡器的特定 样式或型号。适配器专用于具体类型(例如，特定的样式或型号)并且将 通用命令翻译为专用于实现方式的命令。例如，存在NetScaler负载均衡器 适配器，F5BigIP负载均衡器适配器等。像这样，为了引入对Zeus负载均 衡器的支持，仅提供它的适配器。为了引入例如SSL加速器的新类型，提 供针对具体类型的控制器和适配器(例如，用于Coyote Point’s SSL加速器 的适配器)。以上引用的示例是硬件专用的，但是该概念也适用于软件类 型。

对应于多种资源和服务类型的信息模型元件和相关联的管理语义被局 限于在服务管理器内部的控制器和适配器。管理系统的剩余部分(包括除 了控制器和配置器之外的服务管理器组件)在信息模型的较高的抽象水平 上操作。称该抽象为元模型。因为子系统将要在元模型水平上操作，所以 只要配置文件遵从元模型，它们就不受在现有配置文件中做出的改变或者 新配置文件的引入的影响。因此，使用元模型允许新服务的管理，该新服 务的配置文件可能包括新模型元件(例如，诸如SSL加速器之类的新类 型)。

元模型定义了以下八个元对象：服务，资源，部件，配置，性能，能 力，群组和应用数据。资源元对象还具有子类型。元模型还指定这些元对 象之间的关系。将在配置文件中的每一类型分类(即，子类型化)为元对 象之一。例如，将在配置文件中的每一资源子类型化为元模型中的资源子 类型之一。作为一个具体的示例，将负载均衡器，交换机，路由器，防火 墙从网络元件子类型化，进而，该网络元件是从硬件资源子类型化的。进 而，将该硬件资源从资源子类型化。为了引入例如SSL加速器的新实体， 可从网络元件(通过概括也使它成为硬件资源和资源)导出该新实体。

可以将元模型视为用于创建配置文件的模型。希望引入针对新服务的 管理能力的用户或者域专家(例如，应用设计师)可以检查模型库并且从 可用的资源类型中进行选择，以及创建(如果需要)专用于他的域的新资 源或者服务类型。将新创建的类型从现有的元对象或者子类型中子分类出 来。接着，域专家可以创建在多种服务和资源类型之间的适当的关系和基 数，从而创建新配置文件。接着将该配置文件编排版本并存储在管理系统 中。

为了让管理系统使用拓扑中所指定的配置，基数，资源绑定和关系信 息，该管理系统内部创建类型的程序化表示。这是通过从配置文件创建类 定义实现的。当指定拓扑为输入时，管理系统可以生成对应的对象，可以 从该对象获得所述信息。在一种示例实现方式中，可以通过XML模式和 XML实例文档的拓扑表示配置文件。接着使用JAXB框架，可以生成 Java类表示，并且在运行时，可以分析拓扑以创建对应的Java对象。

提供了使管理系统能够动态加载能力以管理可能具有新部署架构的新 服务的插件框架。具体地，该插件框架允许将配置文件中的模型元件的类 表示，和所需要的对应的控制器和适配器捆绑到库中。将如此创建的库称 为插件，并且使用插件框架，将该库存在在管理系统中。将类和插件编排 版本以防止动态类/库加载错误。插件框架维护在[配置文件名称，配置文 件版本]二元组和[插件名称，插件版本]二元组之间的映射。当必须部署服 务时，服务管理器检查其中存储了对应的配置文件的名称和版本号的拓扑 元数据。使用该信息，服务管理器识别有正确版本的对应的插件，并且使 用可用语言和操作系统设施将它动态地加载到它的地址空间中。这是在不 需要重新部署管理系统或者不用重启正在运行的管理系统的情况下完成 的。另外，因为系统的剩余部分操作在元模型的水平上，所以不需要做出 子系统修改。因此，使用通用服务管理器，元模型和插件框架，实现了可 扩展性。

作为一个示例，不是开发他们自己的管理系统以管理搜索基础结构 (由多个服务和资源构成)，搜索领域专家(或者“搜索团队”)可以利 用可扩展模型的框架能力(监视，配置管理，资源管理等)，并且仅添加 专用于搜索域的那些部分。更具体地，搜索团队可以重用服务器，负载均 衡器，操作系统等的定义来建立它们的配置文件，并且引入例如搜索查询 节点(软件资源)的新元件。搜索团队可以使它们的(一个或者多个)配 置文件与元模型一致。针对新类型，搜索团队可以写相关的控制器和适配 器。搜索团队可以创建将模型元件的类定义封装在配置文件中的适当插 件，以及所需要的相关的控制器和适配器。接着可以对该插件编排版本并 存储在管理系统中，并且当必须部署对应的服务时将该插件动态地加载。

图1是诸如数据中心之类的示例性基础结构环境的框图100，并且示 出其包括服务170，资源180以及管理系统110之间的关系。服务170例 如可以包括搜索服务175A，版本3市场服务175B，管理服务175C，版本 4市场服务175D，消息传送服务175E，以及使用资源且可被管理的任何 其它服务175N。资源180例如可以包括计算机资源185A，存储资源 185B，操作系统资源185C，VLAN资源185D，网络资源185E，IP地址 资源185F，应用资源185G，以及服务170可以使用的任何其它资源 185N。在示例实施例中，管理系统110包括操作生命周期(OLCM)引擎 120，用于部署服务170使得它们使用从资源180选择的资源，等等。在 示例实施例中，管理系统110还包括服务水平管理(SLM)引擎150，用 于监视服务170和资源180，并且动态地分配资源180中的至少一者使得 每一服务170维持关键性能指示(KPI)所定义的指定的服务水平，等 等，该服务水平诸如平均响应时间或者吞吐量。

在示例实施例中，服务170和资源180耦接到管理系统110，使得管 理系统110使用OLCM引擎120和SLM引擎150可以管理服务170和资 源180。在示例实施例中，可以将服务170的一些与资源180的一个或者 多个耦接，使得为服务170的一些将资源180的一个或者多个进行分配， 或者部署服务170的一些使得它们使用资源180的一个或者多个。

图2是依据多个实施例的管理系统102的框图。管理系统102包括可 选的配置文件创建器202，一个或者多个服务管理器204，微内核210，分 配器212，配置管理器214，供应管理器216，资源管理器218，以及锁定 管理器220。管理系统102提供针对被管理的服务和构成资源的操作生命 周期管理，动态资源分配，以及服务水平管理能力。

现在参考图9，描述了示例配置文件创建器202。在某些实例中，配 置文件创建器202可以在管理系统102的外部。配置文件创建器接收来自 用户902(例如，域专家)的一个或者多个输入并且访问模型库904。模 型库904存储服务和资源的元模型和模型。用户902适当地重用来自模型 库904的模型元件以部署被创建的服务类型的架构。如果需要创建新模型 元件，则用户902在该工具中创建它们的定义。此外，将每一新创建的模 型元件从元对象或者从资源子类型之一适当地子分类。可以按照需要创建 模型元件之件的相关性和亲子关系。如果在目标配置文件和其它配置文件 之间存在相关性(即，目标服务类型依赖另一服务类型)，那么也可以创 建该相关性。在一个示例实施例中，可以以UML形式创建部署架构的模 型，并且接着将UML表示变换为XML模式表示。接着，使用JAXB可以 将XML模式编译以产生Java类表示。一旦创建了配置文件，接着将其从 工具导出并且编排版本以及存储在管理系统中。

当创建并部署了新服务实例时，用户(例如，操作设计师)使用拓扑 编辑器来创建拓扑。如此创建的拓扑是逻辑拓扑。逻辑拓扑指示抽象的资 源类型(例如，“服务器”，“负载均衡器”，“交换机”等)以及将使 用资源的每一个的多少(例如，基数)。接着，在两步处理中为抽象资源 创建资源绑定——将抽象资源类型绑定到具体资源类型(例如， “NetScaler负载均衡器”，“Cisco 3550交换机”，“LS20服务器” 等)，接着绑定到实际的资源实例。这导致物理拓扑的创建。在某些实例 中，当部署了服务时，管理系统102可以缓慢地将具体的资源类型绑定到 实际资源实例。

服务管理器204依据数据中心104或者云计算环境106内的配置文件 来管理服务和构成资源。更具体地，服务管理器204为服务和构成资源提 供服务水平管理(SLM)和操作生命周期管理(OLCM)。基于物理拓 扑，服务管理器204启动，管理，和/或终止在数据中心104和/或云计算 环境106中的实际资源的执行以提供服务。

服务管理器204包括专用于服务或者资源类型的控制器206。它负责 在它的控制下全部服务/资源实例的完整生命周期和服务水平管理。这样， 每一服务管理器204可以包括针对消耗多于一种资源类型的服务的多于一 个控制器206。

服务管理器204还包括适配器208，该适配器208提供如下转换：从 控制器206接收的命令到(一个或者多个)具体资源实例可执行的本地命 令。控制器206针对每一具体资源类型可以访问不同的适配器208。可以 使用单个适配器以与同一具体资源类型的多于一个的实例进行通信。

微内核210为每一子系统(例如，服务管理器204，分配器212，配 置管理器214，供应管理器216，资源管理器218，以及锁定管理器220) 提供生命周期和服务水平管理。它还提供服务注册能力和服务查找能力以 分别注册和查找子系统的服务端点。

分配器212作为到管理系统102的进入点来服务。它接收全部的客户 请求，通过在微内核210中进行查找来判定哪个子系统作为请求的目标， 并且接着将请求分配到目标子系统。它还为管理系统102提供用户认证和 授权，并且创建和维护用户会话。可以将用户认证降级到不同于管理系统 102的另一服务器。可以基于特定用户的角色和特权内部地执行用户认 证。在成功地认证和授权后，创建用户会话，并且该用户会话持续直到经 过一段时间周期或者当用户退出时。

配置管理器214可以存储和/或访问现有的配置文件和/或存储在配置 库的它们的对应的拓扑(例如，逻辑的或者物理的)。在一些实例中，可 以使用关系数据库管理系统(RDBMS)实现该配置库，或者该配置库可 以是配置管理数据库(CMDB)。

配置管理器214可以操作在元模型水平而不是在配置文件中的模型元 件水平，以保持与单独的部署架构/模型的独立性。配置管理器214基于对 应的元对象可以将拓扑(例如存储为XML文档)转换为关系数据库表。 配置管理器214还可以为在拓扑中的配置文件，拓扑(逻辑的和物理的) 以及单独的对象创建和维护版本向量，以允许管理系统102将服务回滚 (或者向前)到它的部署的拓扑的之前(或之后)的版本。配置管理器 214还可以核实部署的配置并且保证在资源中不存在配置漂移。当检测到 配置漂移时，受影响的资源的相关的服务管理器204可以采取适当的正确 的行动。

供应管理器216负责资源的部署，资源包括用于计算元件(例如，服 务器)的应用代码，应用堆(例如，Java虚拟机(JVM)，Servlet容器) 和操作系统。因为多种专门化产品和工具是可用的，所以供应管理器216 提供服务层以使用适配器208抽象那些产品和工具。该工具的示例包括但 不限于用于OS部署的Symantec的Altiris和用于应用堆和代码部署的 eBay的TurboRoller。

资源管理器218负责保留和分配实际的，具体的资源。保留是被租用 的，即，如果在特定的时间内特定的服务没有使用，那么保留到期。可以 通过基于用户(例如，系统管理员)发出的服务部署命令执行资源分配使 保留是永久的(或者到达指定的最大持续时间)。资源管理器218还可以 动态地指派资源并且周期地调节服务间的资源分配。

锁定管理器220可以操作以防止同时访问共享的资源。在一些实例 中，在不同服务之间资源被共享。如果多个服务管理器204同时访问共享 的资源，那么有可能创建在资源配置中的不一致性，这是因为不是全部的 资源施行或者提供串行化访问。因此，可以提供带外同步或者互斥机制。 为了访问资源，服务管理器204首先从锁定管理器220获取锁定，并且在 它与管理的资源的会话结束之后释放锁定。锁定是被租用的，即，在指定 的持续时间之后它们到期。依据需要，可在某可调的最大值之内延长该租 用。锁定还是在重启前后可重新进入并且不变的。

图3是用于创建配置文件和拓扑的处理300的流程图。每一服务(例 如，消息传送或者交易等)具有它的相对应的部署架构。在步骤302处以 及如以上所描述的，将该部署架构识别或者创建。

然而，该架构是软件程序不能使用的。因此，创建软件可以使用的配 置文件。在步骤304中，使用元模型和现有的模型库(该库将包括基模块 和可能的可以重用的其它用户贡献的模型元件)来创建该配置文件。如果 需要也可以创建新模型元件(通常是域专用的)。接着将该配置文件编排 版本并且存储在管理系统中。

在步骤306中，当要部署新服务实例时(例如，消息传送系统的新实 例)，基于用户提供的参数(例如，服务器数目，配置参数等)或者通过 某种策略来创建它的(部署)拓扑。如此创建的拓扑是逻辑拓扑。下一步 是进行资源绑定，资源绑定的结果是创建了物理拓扑。将逻辑的和物理的 拓扑两者都编排版本并存储在管理系统中(更精确地，在配置管理器 中)。可使用拓扑编辑器可视地或者通过另一程序程序化地创建该拓扑。 一旦接收到全部的预期的准许，则部署物理拓扑(更精确地，管理系统使 用物理拓扑以部署服务实例)。

图4是用于依据多种实施例对在元模型内的被用于分类资源的对象 400的层次结构。该层次结构一般地由不同类型的资源组成。

资源402可以被分类或者子类型化为一个或者多个资源类型。在该模 型的本示例中的这些资源被描述为在资源402下方的第二层，并且包括硬 件资源404，IP地址406，虚拟局域网(VLAN)406和软件资源410。元 模型可以允许更多的资源分类。

还可以将在元模型中的硬件资源404和软件资源410分类为子类型。 在图4的第三和第四层中描述了这些子类型。图4中的这些子类型不意图 成为在元模型中的限制。硬件资源404可以被子类型化为计算元件412 (例如，服务器，虚拟机，计算机，或者手持式设备)，或者网络元件 414(例如，路由器，负载均衡器，防火墙等)，或者存储元件416(例 如，存储器存储设备，光存储设备，存储局域网，网络附接的存储等)。 软件资源410可以被子类型化为操作系统418(例如，Windows，Linux 等)，或者应用420(例如，浏览器或者字处理)。应用420还可以被子 类型化为应用容器422(例如，Java虚拟机，Servlet容器等)。

图5是依据一些实施例示出在元模型中的硬件和软件资源的合成的框 图。硬件资源404和软件资源410两者都具有描述它们的配置502，性能 504和能力506的对象。在配置对象502中的信息被用于配置资源实例。 配置对象502自身可以由子配置对象构成(未示出)。通过监视相对应的 资源实例的性能度量而获取的信息被存储在性能对象504中。存储在能力 对象506中的信息描述了该资源类型的能力(例如，CPU的数目，存储器 的量，吞吐量，响应时间等)。可通过如下方式来在自动配对资源分配期 间使用存储在能力对象506中的信息：指定资源类型所需要的能力并且将 它与实际的具体类型提供的能力进行匹配。硬件资源404和软件资源410 两者都可以分别由硬件部件508(例如，网络接口卡)和软件部件510 (例如，动态链接库)建立。每一部件还可以具有一个相关联的能力对象 (未示出)。一些部件自身可以由子部件(硬件子部件512和软件子部件 514)构成，等等。可以将硬件部件连接到另一远程硬件部件516用于访 问远程硬件资源518。例如，可以通过外部线缆将在服务器(硬件资源 404)上的网络端口(硬件部件508)连接到在网络交换机(远程硬件资源 518)上的网络端口(远程硬件部件516)。

图6是依据多种实施例与群组对象602相关联的模型结构600的框 图。在一些实例中，将资源604(例如，硬件资源404和软件资源412) 和/或部件606编组以使能群组化操作。例如，可以将服务器(其是计算元 件)编组到一个池中，并且可以将连续的IP地址编组到一个子网中。可以 经由群组对象602提供编组。每一群组可选地具有相关联的配置对象610 和性能对象608。

图7是依据多种实施例在元模型中的应用数据702的模型结构700的 框图。可以将应用数据702存储在与操作系统418相关联的文件系统中， 并且由应用420提供服务或者由应用420使用。应用数据702的示例包括 数据库表和用于包括网页的内容的数据。

图8是在其中可以执行指令集的机器的图表表示，该指令集可以执行 用于令机器执行在这里讨论的方法的任何的一个或者多个。在可替代的实 施例中，机器作为独立设备来操作或者可以将机器连接(例如，网络连 接)到其它机器。在网络连接的部署中，机器可以以在服务器-客户机网络 环境中的服务器或者客户机的功能来操作，或作为在对等(或者分布的) 网络环境中的对等机器。该机器可以为服务器计算机，客户计算机，个人 计算机(PC)，桌面PC，机顶盒(STB)，个人数字助理(PDA)，蜂 窝电话，网络应用，网络路由器，交换机或者桥，或者能够执行指定了该 机器要采取的行动的指令集(连续的或者其它)的任何的机器。另外，虽 然仅图示了单个机器，术语“机器”还应当包括任何单独地或者联合地执 行指令集(或者多个集)以执行在这里讨论的任何一个或者多个方法的机 器的任何的集合。

示例计算机系统800包括处理器802(例如，中央处理单元 (CPU)，图形处理单元(GPU)，或者它们二者)，主存储器804和静 态存储器806，它们经由总线808相互通信。计算机系统800还包括视频 显示单元810(例如，液晶显示(LCD)或者阴极射线管(CRT))。计 算机系统800还包括字母数字输入设备812(例如，键盘)，光标控制设 备814(例如，鼠标)，盘驱动单元816，信号发生设备818(例如，扬声 器)和网络接口设备820。

盘驱动单元816包括机器可读介质822，在其上存储了包含在这里描 述的任何的一个或者多个方法或功能的一个或者多个指令集(例如，软件 824)。软件824也可以完全地或者至少部分地驻留在主存储器804内， 和/或驻留在由计算机系统800执行它的执行期间的处理器802内，主存储 器804和处理器802也构建机器可读介质。

可以进一步将软件824经由网络接口设备820通过网络826发送或接 收。

虽然在示例实施例中示出机器可读介质822是单个介质，但是术语 “机器可读介质”应当包括单个介质或者多个介质(例如，集中的或者分 布的数据库，和/或相关联的线缆和服务器)，其存储一个或者多个指令 集。术语“机器可读介质”还应当包括能够存储，编码或者承载指令集用 于通过机器执行的任何介质，该指令集令机器执行本发明的任何一个或者 多个方法。术语“机器可读介质”应当相应地包括但是不限于固态存储 器，光和磁介质，载波信号。

因此，描述了用于管理使用模型框架的多个域架构的方法和系统。虽 然参考具体示例实施例已经描述了本发明，将显而易见的是在不背离本发 明的更广的精神和范围的情况下可以对这些实施例做出多种修改和变化。 因此，该说明书和附图应当被视为解释的而不是限制的意义。

在这里描述的一些实施例可以被用于解决一个或者多个技术问题。例 如一些实施例可以便利更有效的资源管理和减少当添加或者修改一个架构 域时重新部署系统的需要。

提供了本公开的摘要以遵从37 C.F.R.§1.72(b)，其要求允许读者快速 地确定该技术公开的特征的摘要。理解该摘要不被用于解释或者限定权利 要求的范围或者意义地来提交该摘要。另外，在前述详细地描述中，可以 看出为了精简本公开的目的将多种特征在单个实施例中组合在一起。不将 本公开的方法解释为反映意图：要求的实施例比在每一权利要求中明确叙 述的要求更多的特征。相反，如权利要求反映的，发明的主题取决于少于 单个公开的实施例的全部特征。因此将权利要求结合在详细地描述中，位 于它自己上的每一权利作为一个单独的实施例。