第二天操作的基于拓扑的管理的制作方法

背景技术：

越来越多数量的商业实体和个体转向通过云计算系统提供的云计算和云服务，以便例如出售商品或服务、维护商业记录、和为个体提供对计算资源的访问、以及其他与云有关的目标。云计算为云消费者提供可扩展并且集中的计算、存储、和网络容量以作为服务或以以上这些为基础的此类服务的组合。可以由(或者针对)创建云计算系统的实体对云进行设计、规定、部署、和维持。设计、规定、部署、和维持云计算系统可能是艰难的任务。

附图说明

图1是根据本公开的蓝图的框图。

图2是根据本公开示出架构导出的拓扑的框图。

图3根据本公开描绘示出用于设计、规定、部署、监视、和管理云服务的基于拓扑的管理代理的功能性概览的框图。

图4根据本公开描绘示出用于设计、规定、部署、监视，和管理云服务的基于拓扑的管理代理的功能性概览的框图。

图5描绘了示出用于基于拓扑的管理代理的公共平台的框图。

图6是根据本公开示出设计拓扑的方法的流程图。

图7是根据本公开的系统的示例。

图8是根据本公开的系统的示例。

图9是根据本公开的系统的示例。

图10是根据本公开示出构成与拓扑节点相关联的组件的拓扑的组件的示例平台的框图。

具体实施方式

当利用具有多个实例的拓扑时，云计算系统能够向用户提供服务。先前的系统和方法可能需要由系统所熟知和/或规定的拓扑。例如，先前的系统可能依赖于根据系统规定拓扑并且管理所规定的拓扑。在一些实施例中，管理不由系统生成的拓扑能够是有利的。本文所描述的系统和方法能够提供发现并管理不由系统生成的拓扑(例如，推断出的实现拓扑)的能力。在一些实施例中，通过拓扑设计、拓扑模型。拓扑模板的分立从实现拓扑实例实现系统。系统能够管理不具有模型和/或设计的实现的示例。另外，系统能够运行从外部系统输入、发现、和/或修改实现拓扑，并且保持对实现拓扑的跟踪以管理该实现拓扑。

云计算为用户的数据、软件、和计算提供服务。可以手动地部署在云服务内的资源上部署的应用。这种手动部署消耗相当多的管理时间。部署应用的手动步骤可以包括基础结构的规定和实例化。这可以包括在有或者没有对所部署的基础结构的充分了解的情况下连结诸如中间软件与db+应用或图像的部署之类的应用或平台的安装。手动部署可以另外包括由尝试部署应用的用户所启动的多个步骤的序列。因此，将应用手动连结至所部署的基础结构消耗大量的计算和人员资源，并且可能导致应用和底层基础结构之间的错误和不可调和的问题。可以利用多个工具、脚本、和可执行体以利用对这些过程的执行序列进行自动化的编排器来自动地将应用连结到所部署的基础结构的。用于设计、规定、部署、和维持在云服务内的资源上部署的应用的多个设备可以包括数据中心、私有云、公共云、管理云、混合云、及其组合。

更具体地，可以使用云服务管理器来设计、规定、部署、和管理通过网络提供给用户的云服务。云服务提供商或其它实体或个体设计、规定、并且可以部署云服务。云服务管理器管理云服务，该云服务由在云环境中部署、执行、和管理的多个服务、应用、平台、或基础结构功能适当地组成。这些设计然后可以经由市场或经由api调用而提供给可能从目录对它们进行订购、请求、和订阅的用户，并且然后通过相同的机制来管理基于设计部署的云服务的使用循环。云服务提供商(例如，第一天操作)和云服务管理器(例如，第二天操作)可以是相同或不同的实体。利用“蓝图”来表示以下更详细地描述的由惠普公司设计和发布的诸如云服务自动化(cloudserviceautomation)(csa)之类的云服务管理器中的服务设计。

蓝图在工作流程集合方面来描述服务，执行该工作流程集合以用于规定或管理构成服务的所有组件以便执行特定的使用循环管理动作。通过蓝图定义的工作流程的一些功能是随着对资源提供商的调用然后被执行的实际的使用循环管理动作。资源提供商将调用转换为被指定为由资源提供商提供的特定资源或实例的被妥善格式化和交换的指令。

图1是根据本文所描述的原理的一个示例的蓝图(100)的框图。蓝图中的每个对象(102-1、102-2、102-3、102-4、102-5、102-6、102-7、102-8、102-9、102-10、102-11、102-12)可以与调用资源提供商的动作工作流程相关联。使用蓝图(100)设计、规定、部署、和管理云服务的方法存在多个挑战。尽管由包括通过关系连结的属性和动作的对象组成，但蓝图的结构不识别诸如像支持云服务的系统的实际的物理架构之类的物理拓扑的关系。这致使难以将额外的元数据与蓝图(100)相关联以描述例如与系统相关联的策略。另外，策略与蓝图(100)中的节点的这种关联对于要被部署的云服务的设计者或管理员而言不是直观的。

另外，由于同样的原因，难以如持续交付自动化(cda)一样将蓝图(100)的结构用作应用的模型或基础结构的模板。cda是在拓扑设计器内使用的系统工具，该系统工具在对版本、配置、和其它应用组件进行管理时独立地对基础结构和应用需求进行建模。惠普公司还开发并且发布了cda1.2。由于本文给出的同样的原因，蓝图(100)的结构难以用作应用的模型，这是因为蓝图不描述应用的架构。另外，蓝图难以用作基础结构的模板，这是因为它们也不描述基础结构的架构。结果，以对应用模型和基础结构或平台模板进行建模并且将应用模型和基础结构或平台模板彼此映射作为目标的系统不容易与蓝图协调，这是因为它们基于不同的对这些服务进行建模的方法。

本系统和方法描述架构描述性拓扑，该架构描述性拓扑定义构成云服务的系统的物理架构。图2是根据本文所描述的原理的一个示例的示出架构导出的拓扑(200)的框图。如在图2中所描绘的，架构导出的拓扑(200)可以包括彼此相关联的多个节点(201、202、203、204、205、206、207、208、209、210、211、212、213、214、215)。由空白箭头来指示拓扑(200)内的节点之间的关联。拓扑(200)内的多个节点(201、202、203、204、205、206、207、208、209、210、211、212、213、214、215)还可以彼此聚合，如被填充的箭头所指定的。聚合是用于描述并行地组合(聚合)多个网络连接以将吞吐量增加到超过单个连接能够维持的吞吐量并且在链路中的一个出故障的情况下提供冗余的计算术语。

例如，负载平衡器(201)、web服务器服务(202)、应用企业存档(203)、和数据库(204)彼此相关联。web服务器服务(202)与web虚拟机(205)和其安全组(213)以及web虚拟局域网(209)聚合。类似地，应用企业存档(203)与诸如javabeans开源软件应用服务器(jboss)服务(206)之类的应用服务器服务、jboss虚拟机(208)和其相关联的安全组(214)、以及安全应用虚拟局域网(210)聚合。再次，类似地，数据库(204)与数据库虚拟机(207)和其安全组(215)、以及安全数据库虚拟局域网(211)聚合。web虚拟局域网(209)、安全应用虚拟局域网(210)、和安全数据库虚拟局域网(211)然后与路由器(212)相关联。

因此，基于架构导出的拓扑(200)的实例化的云服务可以利用在拓扑内的多个节点之间定义的多个关系而表示为节点的拓扑。多个属性和动作与多个节点、多个节点组、拓扑的一部分、整个拓扑、或者其组合相关联。另外,多个策略与多个节点、多个节点组、拓扑的一部分、整个拓扑、或者其组合相关联。更进一步，多个使用循环管理动作(lcma)与多个节点、多个节点组、拓扑的一部分、整个拓扑、或者其组合相关联。

因此，本系统和方法描述了使用相同的使用循环管理引擎支持拓扑和蓝图两者的云服务代理或管理器。如结合图3所描述的，使用循环管理引擎支持云服务的使用循环管理以及应用模型与基础结构模板的映射。本系统和方法还描述了用于管理云服务内的规定、部署、监视、和补救过程的基于策略的框架。另外，如以下将更详细地描述的，本系统和方法为由csa、cda支持的使用模型以及蓝图提供支持。

如在本说明书中并且在所附权利要求中所使用的，术语“自主计算”、“自治计算”旨在被宽泛地理解为当对用户和运营商隐藏内部复杂的事物时适应无法预测的变化的分布式计算资源的自管理特性。自管理可以包括自配置、自优化、自监视、自补救、自动规定、自动补救、或者其组合。

如在本说明书中并且在所附权利要求中所使用的，术语“代理”旨在被宽泛地理解为对云内的拓扑的设计、规定、部署、以及基于该拓扑的实例化的服务的维护和使用循环管理进行管理的计算设备网络中的任何计算设备或者计算设备的集合。

如在本说明书中并且在所附权利要求中所使用的，术语“云服务”旨在被宽泛地理解为通过实时通信网络连接的多个计算设备提供的任何数量的服务。云服务可以包括在实施分布式硬件和软件资源的分布式系统上提供的服务。在一个示例中，云服务可以是在私有云、公共云、管理云、混合云、或者其组合上提供的任何服务。在另一个示例中，云服务可以是在诸如例如数据中心之类的物理地独立的机器上提供的服务。

如在本说明书中并且在所附权利要求中所使用的，术语“混合云”旨在被宽泛地理解为被绑定在一起以提供多个云服务的多个独特的计算云。

另外，如在本说明书中并且在所附权利要求中所使用的，术语“节点”或“计算设备”旨在被宽泛地理解为任何硬件设备、虚拟设备、硬件设备组、虚拟设备组、或者网络内的其组合。节点例如可以包括服务器、交换机、数据处理设备、数据存贮设备、负载平衡器、路由器、和其虚拟实施例等多个其他类型的硬件和虚拟设备。另外，节点可以是在节点是其中一部分的拓扑的执行和实例化之前的本文所描述的硬件和虚拟设备的表示。

更进一步，如在本说明书中并且在所附权利要求中所使用的，术语“拓扑”旨在被宽泛地理解为对节点的图进行表示的数据，其中节点之间的分支表示节点之间的关系。节点可以包括位于网络内的任何数量的计算设备。因此，网络的拓扑可以包括网络化计算设备的物理和逻辑布局，以及计算设备之间的关系的定义。本文所进一步定义的多个策略和使用循环管理动作(lcma)可以与拓扑、拓扑的部分、拓扑内的节点、拓扑内的节点组、以及其组合相关联。

更进一步，如在本说明书中并且在所附权利要求中所使用的，术语“蓝图”旨在被宽泛地理解为允许云服务部署的自动化和云服务的使用循环管理的执行流。蓝图可以包括服务内所包括的诸如例如操作系统、应用栈、数据库之类的多个硬件和/或虚拟化组件的功能性描述。蓝图可以另外包括硬件和虚拟化组件之间的配置和连接的功能性描述。蓝图还可以包括多个部署模型以实现要被部署的功能性描述。蓝图可以另外包括用户可配置选项的集合以允许用户配置所部署的服务的多个可选示例。蓝图是非架构导出的可执行的拓扑的示例。

更进一步，除本文所描述的蓝图之外，本公开提供可执行的拓扑的使用。因此，本系统和方法提供蓝图导出的拓扑和架构导出的拓扑两者的执行和实例化。蓝图导出的拓扑和架构导出的拓扑两者都是可执行的。因此，如在本说明书中并且在所附权利要求中所使用的，术语“拓扑”旨在被宽泛地理解为可执行的逻辑或可以被表示为定义将被实例化的网络的特性的可执行的逻辑或可判读的逻辑的任何集合。拓扑可以定义多个节点。另外，拓扑可以将与节点相关联的多个策略和使用循环管理动作独立地定义为多个组或其组合。在一个示例中，蓝图可以被表示为拓扑。在这种示例中，蓝图导出的拓扑还可以定义多个节点以及与拓扑内的节点相关联的多个策略和使用循环管理动作、拓扑内的节点组、拓扑的部分、整个拓扑、以及其组合。

更进一步，如在本说明书中并且在所附权利要求中所使用的，术语“策略”旨在被宽泛地理解为用于协助云服务内的规定、部署、监视、发现、执行、以及补救的管理的任何数据或元数据。策略可以表示可应用于与云服务环境内的多个计算设备相关联的规定、部署、监视、发现、执行、以及补救任务的多个规则或规则集合。

更进一步，如在本说明书中并且在所附权利要求中所使用的，术语“用户”旨在被宽泛地理解为任何个体的或实体，对于或者通过该个体或实体，云服务被设计、规定、部署、监视、被强制执行策略、事故被补救，以其他方式被管理，或者对云服务进行上述动作中的动作的组合。在一个示例中，用户可以以一价格购买云服务的使用。例如，用户可以支付预订以使用云资源和服务，并且，在这种情况下，用户还被分类为订阅者。在另一个示例中，用户可以是云服务的设计者或管理员。在又一个示例中，用户可以是管理云服务的任何个体。

再进一步，如在本说明书中并且在所附权利要求中所使用的，术语“多个”或类似的语言旨在被宽泛地理解为包括1至无穷大的任何正数；零不是数量、而是数量不存在。

在以下描述中，为了解释目的，阐述多个的特定细节以便提供对本系统和方法的彻底的理解。然而，对于本领域技术人员将明显的是，可以在没有这些特定细节的情况下实践本装置、系统、和方法。在说明书中对“示例”或者类似的语言的引用意指与示例结合描述的特定特征、结构或特性如所描述的那样被包括，但在其他的示例中可以不被包括。

可以在任何数据处理情景中利用本系统，所述数据处理情景例如包括在网络内，所述网络包括网络内的多个计算设备的设计、规定、部署、以及管理。例如，可以在云计算情景中利用本系统，在该云计算情景中，在服务型的网络内设计、规定、部署、和管理多个真实或虚拟的计算设备。在另一个示例中，可以在独立的数据中心中或者云计算情景内的数据中心中利用本系统。服务型的网络可以例如包括以下方面：作为托管多个应用的服务的软件(saas)；作为托管例如包括操作系统、硬件，以及存贮器，等等的计算平台的服务的平台(paas)；作为托管诸如像服务器、存储组件、网络，以及组件等等的装备的服务的基础结构(laas)；作为服务的应用编程接口(api)(apiaas)、以及其他形式的云服务、或者其组合。可以在一个或多个硬件平台上实施本系统，其中在一个平台上或跨多个平台执行系统中的模块。此类模块可以以各种形式的云技术以及混合云技术运行或者被提供为可以在云上或离开云而实施的saas(作为服务的软件)。

另外，可以在公共云网络、私有云网络、混合云网络、其他形式的网络、或者其组合中使用本系统。在一个示例中，由例如第三方通过网络来将本系统所提供的方法作为服务来提供。在另一个示例中，由本地管理员来执行本系统所提供的方法。在又一个示例中，可以在单个计算设备内利用本系统。在这种数据处理情景中，单个计算设备可以利用设备和在本文描述的相关联的方法来部署云服务并且管理云服务的使用循环。在本文的示例中，可以将云服务的设计、多个计算设备和云服务内的相关联的软件的规定、所设计和所规定的云资源和服务的部署、云资源和服务的管理、以及其组合作为服务来提供。

本公开的示例可以被实现为系统、方法、或计算机程序产品，并且可以采取完全硬件实施例、或对可以总体上在本文被称为“电路”、“模块”或“系统”的软件和硬件示例进行组合的实施例的形式。此外，本公开的示例可以采取以多个计算机可读介质的方式实现的计算机程序产品的形式，该计算机可读介质包括在其上实现的计算机可读的程序代码。可以利用一个或多个计算机可读介质的任何组合。

计算机可读非暂时性介质可以是与计算机可读信号介质形成对比的计算机可读存储介质。计算机可读存储介质例如可以是电子、磁性、光学、电磁、红外、或半导体系统、装置，或设备，或者前述项的任何适当的组合。计算机可读存储介质的更多特定示例可以包括以下方面：具有一个或多个布线的电气连接、便携式计算机磁盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦除可编程序只读存储器(eprom或闪存存储器)、光盘只读存储器(cd-rom)、光存贮设备、磁存贮设备，或前述项的任何适当的组合。在本公开的上下文中，计算机可读存储介质可以是能够包含或存储程序以供指令执行系统、指令执行装置、或指令执行设备使用的或者与指令执行系统、指令执行装置、或指令执行设备结合使用的任何有形介质。

贯穿本公开描述了各种计算设备。计算设备可以包括计算元件，该计算元件包括数据处理设备、数据存贮设备、和数据通信设备的真实或虚拟。尽管可以与真实和物理设备结合来描述这些各种设备，但虚拟设备的数量可以是任意的。尽管虚拟设备描述基于真实世界计算机的仿真计算机架构和功能的规范的基于软件的计算机，但虚拟设备包括相关联的硬件设备或者功能性地连接到多个相关联的硬件设备。相应地，可以由硬件元件、软件元件(包括固件、常驻软件、微代码，等等)、或者硬件和软件元件的组合来实施本公开的示例。

在一些示例中，自配置可以指的是基于进行“部署”的指示或指令来部署其本身并且配置其本身的应用特性。例如，拓扑可以与支配部署和配置的多个策略相关联。在另一个示例中，拓扑可以包括支配应用的部署和配置的规定逻辑。因为逻辑、策略、或者其组合与拓扑一起封装，因此它们能够由云管理系统自部署。此类自配置可以包括执行工作流程，其中动作对云环境的多个应用编程接口(api)进行调用以提供服务。

在一些示例中，应用可以被自动规定。例如，应用(其可以包括可执行体、拓扑、以及与拓扑相关联的策略)可以被选择以便被实例化为服务。策略可以包括描述监视、事件处理、事故处理的策略，并且策略可以包括补救拓扑。策略可以被传递至诸如结合图3和图4描述的系统之类的平台以进行部署。规定策略可以是对规定策略引擎的输入，该规定策略引擎可以利用环境信息和资源提供商策略来评估包括能力和需求的规定策略以确定使用哪个资源提供商来执行lcma。监视策略相似地在本文中描述。

在另一个示例中，应用可以被自规定。在这种示例中，可以使用api并且在图3和图4的系统上构建api。api传递可执行体、或可安装人工制品、拓扑、以及策略，以使系统对服务进行规定以及优化。

图3和图4根据本文所描述的原理的一个示例描绘了基于拓扑的管理代理(300)以及用于规定、部署、监视、发现、保护、和补救云服务的设计阶段的框图。如以下将更详细地描述的，图3和图4的系统使用相同的使用循环管理引擎支持拓扑和蓝图两者。

在一个示例中，可以通过经由多个拓扑设计器(301)重新设计拓扑(302)来生成拓扑(302)。在这种示例中，拓扑(302)可以被设计为包括多个规定策略(303)。系统(300)和拓扑(302)可以定义将服务(312)实例化的特定方式。相应地，被实例化的服务(312)在实例化的服务(312)的规定期间可以是自配置的。在另一示例中，可以使用不同的管理工具或管理代理(300)来发现拓扑(302)。在这些示例中，可以由另一实体和/或系统规定现存的实现拓扑，并且使用使用不同的管理工具或管理代理(300)管理现存的实现拓扑。

在另一个示例中，可以通过使用多个拼接方法将多个应用模型(319)和多个基础结构模板(320)拼接在一起来生成拓扑(302)。在这种示例中，具有对应的能力策略、需求策略、和规定策略的系统(300)和应用模型(319)可以自选择最佳基础结构模板(320)以用于拓扑(302)。在这种示例中，拓扑(302)可以是自设计的。拓扑(302)然后可以自配置或者本文所述地定义将服务(312)实例化的特定方式。

除自配置之外，应用可以是自修复的。自修复可以指的是服务(312)的或者应用的这种能力：监视本身并且基于诸如度量之类的所收集的数据自补救所生成的事故。在一些示例中，自修复可以包括根据拓扑(302)中所包括的策略(303)来进行监视和补救。在另一个示例中，自修复可以包括执行拓扑(302)本身所包括的补救逻辑和监视逻辑。

图5是根据在本文所描述的原理的一个示例的示出在高层级的用于图3和图4的基于拓扑的管理代理(300)的公共平台(500)的框图。如图5中所描绘的，通过常规地使用服务设计方面(504)和服务实施方面(505)来表示用于csa(501)和cda(506)的公共平台。在csa(501)的情况下，csa(501)的自助门户(502)和服务消费(503)方面与进行cda(506)的cda扩展(507)方面使用相同的资源。以这样的方式，由公共平台来支持对云服务进行实例化的所有使用案例。因此，尽管可以经由多个拓扑设计器和/或经由应用模型和基础结构模板拼接过程来重新设计拓扑，但系统和方法也在相同的系统内提供使用本文所描述的系统和方法的蓝图的执行。现将结合图3和图4更详细地描述此方面。

如在图3和图4中所描绘的，一个或多个拓扑设计器(301)有助于设计云服务拓扑的各种示例。可替换地，可以如结合图6-9更多地讨论的那样发拓扑。在一个示例中，经由使用硬件设备和诸如图形用户界面(gui)与编码脚本之类的软件模块的设计工具来执行拓扑设计。人类设计者使用设计工具(301)来设计拓扑。因此，通过自主方法和/或人类提供设计的方法来实现拓扑(302)的设计。在一个示例中，拓扑设计器(301)可以是利用api的接口，其使得能够进行应用模型(图4，319)与它的相关联的组件的分立创建，并且指定基础结构和用于基础结构的使用循环条件的基础结构模板的创建。如在图3中所示的，在至少一个示例中，这些方法用于将策略关联到应用基础结构，其中策略定义阶段、版本、和/或兼容性。

全部基于拓扑的管理代理(300)的在图3中描绘的子系统包括能够规定、部署、监视、发现、强制执行云服务内的策略的子系统，以及补救云服务内的事故的子系统。不管拓扑是蓝图还是架构导出的，都使用利用lcma和策略的拓扑来执行这些任务。因此，本系统和相关联的方法还支持csa支持或者其它支持的所有使用案例(例如，cloudfoundry、heroky、openshift、亚马逊网页服务(aws)、魔豆、azure和/或没有管理代理(300)的通知的自动补救或修改)。在通过引用全部包含于此的梅斯的名称为“管理混合云服务(managingahybridcloudservice)的国际专利申请公开号pct/us2012/045429中描述了csa。如以下将更详细地描述的，图3中描绘的子系统使用多个类型的策略和使用循环管理动作(lcma)来规定、部署、监视、强制执行所部署的云服务内的策略，并且补救所部署的云服务内的事故。

另外，全部基于拓扑的管理代理(300)的在图4中描绘的子系统包括能够与在图3中描绘的子系统一样在相同的堆栈上独立地对拓扑的基础结构和应用需求进行建模的子系统。本系统和相关联的方法还支持诸如那些使用cda支持或其它支持的情况之类的cda子系统支持的所有使用案例(例如，cloudfoundry、heroky、openshift、亚马逊网页服务(aws)、魔豆、azure和/或没有管理代理(300)的通知的自动补救或修改)。在通过引用全部包含于此的梅斯的称为“云应用部署(cloudapplicationdeployment)”的国际专利申请公开号pct/us2012/041625中描述了cda。

以这样的方式，图3和图4的子系统作为具有常规地使用拓扑、实现拓扑、推断出的拓扑、推断出的实现拓扑、和策略的能力的计算系统在共用堆栈下工作并且在相同的和/或不同的基于拓扑的管理代理(300)内一起工作，以支持构建拓扑并且支持多个提供商的相关联的技术的所有使用案例。因此，在一个示例中，本系统和方法通过在相同的堆栈上和/或不同的堆栈上利用云服务的设计的拓扑(例如，架构导出的)、多个策略、与拓扑节点的拓扑节点子集，和/或拓扑节点的全集相关联的多个lcma来协调分别由cda和csa使用的不同模型、模板、和蓝图。

如在图3中所描绘的，拓扑设计器(301)可以设计并且向基于拓扑的管理代理(300)呈现使用循环管理(lcm)拓扑(302)。在一个示例中，本文所描述的拓扑设计器(301)可以是基于拓扑的管理代理(300)的集成的部分。在另一个示例中，拓扑设计器(301)可以与基于拓扑的管理代理(300)分离。在另一个示例中，多个人可以使用拓扑设计器(301)来设计拓扑(302)。这些个体可以是服务设计者、基础结构建筑师或管理员、系统管理员、信息技术操作员、报价经理、或用户等具有设计拓扑角色的其他人员。在又一个示例中，拓扑设计器(301)可以由第三方来操作。

lcm拓扑(302)可以定义多个节点(302-1、302-2、302-3、302-4、302-5、302-6、302-7)，以及节点(302-1、302-2、302-3、302-4、302-5、302-6、302-7)之间的多个关系。尽管在图3中描绘了七个节点，但可以将任何数量的节点设计到拓扑(302)中以便实现任何数据处理目标。在一个示例中，基于拓扑的管理代理(300)可以将拓扑(302)表示为可扩展标记语言(xml)文件。在另一个示例中，基于拓扑的管理代理(300)可以：以javascript对象标记(json)格式来表示拓扑(302)；以为从用于表示对象的javascript脚本语言导出的人类可读取的数据交换而设计的基于文本的开放标准来表示拓扑(302)。在又一个示例中，基于拓扑的管理代理(300)可以：以yaml语法格式来表示拓扑(302)；以人类可读取的数据序列化格式来表示拓扑(302)。

在图3中，节点(302-1、302-2、302-3、302-4、302-5、302-6、302-7)之间的关系被描绘为连接节点(302-1、302-2、302-3、302-4、302-5、302-6、302-7)的线。节点(302-1、302-2、302-3、302-4、302-5、302-6、302-7)中的每一个、整个拓扑(302)、节点(302-1、302-2、302-3、302-4、302-5、302-6、302-7)的组、拓扑(302)的部分，或者其组合与多个策略(303)相关联。策略(303)是提供于描述节点或拓扑的同一文件中或与此相关联的文件中的数据或元数据。在一个示例中，可以在拓扑(302)的设计期间——例如由管理员在提供设计时执行拓扑(302)内的策略(303)的关联。在另一个示例中，可以在拓扑(302)的设计期间——当例如用户作为预订或请求而选择设计时执行拓扑(302)内的策略(303)的关联。

在一些实施例中，拓扑(302)可以是实现拓扑。实现拓扑可以是由也利用拓扑(302)的实体所生成的拓扑(302)。在一些实施例中，拓扑(302)可以是推断出的实现拓扑。推断出的实现拓扑能够不是由尝试利用拓扑(302)的实体所创建的拓扑。推断出的实现拓扑能够是被发现的拓扑(302)。推断出的实现拓扑能够通过在cmdb(配置管理数据库)中或者在其他系统中检验关系而被发现，该其他系统能够检验域中的关于所部署的系统的关系或者检验所部署的系统之间的关系。

能够通过企业映射数据和/或人工编辑、指导编辑、和/或由具有数据中心知识的操作者完成的设计、和由数据中心部署的服务来促进发现推断出的实现拓扑。在一些实施例中，如本文所描述的，能够以通过人工输入和/或人工设计来创建多个推断出的实现的实例来促进发现推断出的实现拓扑。推断出的实现拓扑能够是由系统给所规定的云服务的拓扑(302)，该系统不用于管理拓扑(302)服务的系统。例如，推断出的实现拓扑能够应用于与例如，cloudfoundry、heroky、openshift、亚马逊网页服务(aws)、魔豆、azure和/或没有管理代理(300)的通知的自动补救或修改相似的部署到paas中的服务。推断出的实现拓扑能够与实现拓扑相似地操作和/或被利用。在一些实施例中，能够在管理代理(300)上构建多个应用以用于第二天操作。在一些实施例中，可以在没有第一天操作的情况下在管理代理(300)上构建多个应用以用于第二天操作。

如本文所使用的，第一天操能够指的是在管理器(300)上的应用开发。此外，第一天操作能够使得应用开发者和/或拓扑开发者获得管理代理(300)的所部署的系统的关系的映射。如本文所使用的，第二天操作能够包括在云服务的应用被部署之后的云服务的操作、部署、管理和规定。因此，在没有第一天操作的情况下的第二天操作包括在没有管理代理(300)上开发应用的情况下的云服务的云服务的管理和/或规定。在一些实施例中，可以通过将多个服务实例映射到推断出的拓扑实现拓扑并且以与在本文描述的实现拓扑相同和/或相似的方式利用推断出的实现拓扑来实现在没有第一天操作的情况下的第二天操作。

策略(303)是提供于描述节点或拓扑的同一文件中或与此相关联的文件中的数据或元数据。在一个示例中，可以在拓扑(302)的设计期间——例如由管理员在提供设计时来执行拓扑(302)内的策略(303)的关联。在另一个示例中，可以在拓扑(302)的设计期间——当例如用户作为预订或请求而选择设计时来执行拓扑(302)内的策略(303)的关联。

在一些实施例中，策略(303)能够被关联到节点(302-1、302-2、302-3、302-4、302-5、302-6、302-7)中的每一个。在一些实施例中，策略(303)能够被关联到多个如在图4中引用的应用模型(319)中的每一个。此外，在一些实施例中，策略(303)能够被关联到多个如在图4中引用的基础结构模板(320)中的每一个。例如，策略(303-1、303-2、303-3、303-4、303-5、303-6、303-7)能够被指配给对应的节点(302-1、302-2、302-3、302-4、302-5、302-6、302-7)。如在本文进一步所描述的，策略(303-1、303-2、303-3、303-4、303-5、303-6、303-7)能够包括应用的兼容性。

如本文所使用的，应用的兼容性和/或节点的兼容性分别是应用的期望的状态和/或节点的期望的状态。兼容性能够包括由不同的系统所规定的测量。例如，兼容性能够由能够由第二系统管理的第一系统和拓扑来规定。即，能够分立地规定和/或管理拓扑和/或系统。用于建模如本文所描述的兼容性的基于策略的方法和系统能够支持第二天操作、csa、和/或利用能够与遗留sa型解决方案兼容的云服务的操作。

能够将多个泛化策略映射到拓扑。如在本文进一步描述的，多个泛化测量(例如，泛化兼容策略)包括诸如fips、安全性策略、和/或拼接策略之类的策略，以及在本文描述的其他泛化策略。泛化策略能够被预处理并且映射至利用多个方法的拓扑，该方法包括行走拓扑(walkingthetopology)、识别节点类型、识别具有相同或相似范围和/或表示节点的期望的状态的兼容性泛化策略。

如本文所进一步描述的，能够利用通知策略来对拓扑和/或系统的管理器和/或开发者进行通知。在一些实施例中，可以通过指定应用和/或节点的定义的期望的状态和实际状态之间的距离来引起和/或发送通知。在一些实施例中，如以下更详细地所描述的，能够基于事故类型将通知指定为发送给特定用户和/或系统。在一些实施例中，发送通知能够包括在期望的状态和实际状态之间的距离超出特定阈值时识别脚本以进行运行。

另外，在一个示例中，将策略(303)添加到拓扑或拓扑的部分可以使拓扑的设计发生变化。在此示例中，增加到拓扑(302)的元素的策略(303)可能影响多个其他策略。例如，与拓扑(302)相关联的指示节点高度可用的策略可以将策略(303)和拓扑(302)进化为要求例如一群节点的整体。以这样的方式，策略可以驱使拓扑(302)的设计。

节点(302-1、302-2、302-3、302-4、302-5、302-6、302-7)中的每一个、整个拓扑(302)、节点(302-1、302-2、302-3、302-4、302-5、302-6、302-7)的组、拓扑(302)的部分，或者其组合进一步与多个使用循环管理动作(lcma)(304)相关联。在lcma(304)能够与节点相关联的示例中，单个lcma与给定节点相关联。在多个lcma能够与拓扑(302)的部分或作为整体的拓扑(302)相关联的示例中，lcma经受资源提供商的编排。

lcma被表示为多个应用编程接口(api)，其中，在拓扑(302)的执行期间调用lcma，并且规定多个计算资源以管理给定云能力的使用循环。在一个示例中，可以经由应用编程接口(api)的统一资源标识符(uri)来访问lcma以执行目的为执行api的调用。在一个示例中，通过引用在包括本文结合策略(303)描述的数据或元数据的文件内提供lcma。

在一个示例中，根据节点或多个节点(302-1、302-2、302-3、302-4、302-5、302-6、302-7)表示什么计算设备，默认lcma与拓扑的示例相关联。在另一个示例中，通过明确地提供多个函数faction，lcma与拓扑的多个示例相关联,其中，faction基于与拓扑、应用的示例相关联的策略和不同的有关的资源提供商的策略来定义如何选择资源提供商以实施动作。这些函数基于与拓扑、应用的示例相关联的策略和不同的有关的资源提供商的策略来定义如何选择资源提供商以实施动作。

将分别通过元素303和304在本文表示策略和lcma，以表示策略(303)和lcma(304)与节点(302-1、302-2、302-3、302-4、302-5、302-6、302-7)、整个拓扑(302)、节点(302-1、302-2、302-3、302-4、302-5、302-6、302-7)的组、拓扑(302)的部分、应用模型(319)、基础结构模板(320)、或者其组合相关联。在一个示例中，经由拓扑设计器(301)来执行策略和lcma与拓扑的示例的关联，和/或如在图6-9中所描述的发现此关联。

在一个示例中，尽管未描绘，构成组的节点的子集还可以与多个策略(303)和多个lcma(304)相关联。在此示例中，多个节点——例如节点(302-2、302-3、302-4、302-6、302-7)可以作为组与和其相关联的多个策略(303)和多个lcma(304)相关联。可以在整个拓扑(302)内呈现节点的若干分组。在一个示例中，节点的组可以重叠，其中第一组节点中的单个节点也可以属于第二组节点，并且经受第一和第二组节点的策略(303)和lcma(304)两者。以下将更详细地描述策略和它们与独立节点和节点的组的关联。

与节点相关联的策略(303)可以以任何方式利用节点(302-1、302-2、302-3、302-4、302-5、302-6、302-7)进行表示并且与所述节点附接。在一个示例中，通过定义节点(302-1、302-2、302-3、302-4、302-5、302-6、302-7)的属性使策略(303)与节点(302-1、302-2、302-3、302-4、302-5、302-6、302-7)相关联。在另一个示例中，通过元语言表示使策略(303)与节点(302-1、302-2、302-3、302-4、302-5、302-6、302-7)相关联。

与应用模型相关联的策略(303)可以以任何方式利用应用模型(319-1,319-2，319-3)进行表示并且与所述应用模型附接。在一个示例中，通过定义应用模型(319-1,319-2，319-3)的属性使策略(303)与应用模型(319-1,319-2，319-3)相关联。在另一个示例中，通过元语言表示使策略(303)与应用模型(319-1,319-2，319-3)相关联。

与基础模板相关联的策略(303)可以以任何方式利用基础结构模板(320-1,320-2,320-3,320-4,320-5)进行表示并且与所述应用模型附接。在一个示例中，通过定义基础结构模板(320-1,320-2,320-3,320-4,320-5)的属性使策略(303)与基础结构模板(320-1,320-2,320-3,320-4,320-5)相关联。在另一个示例中，通过元语言表示使策略(303)与基础结构模板(320-1,320-2,320-3,320-4,320-5)相关联。

策略(303)是多个描述、元数据、工作流程、脚本、规则、或规则集合，这些可适用于指引在拓扑(302)将被或已经被实施的云服务环境内的与多个节点(302-1、302-2、302-3、302-4、302-5、302-6、302-7)、多个应用模型(319-1,319-2，319-3)、和/或多个基础结构模板(320-1,320-2,320-3,320-4,320-5)的使用循环管理相关联的规定任务、监视任务、发现任务、强制执行任务、支配任务、以及补救任务。策略(303)定义基于拓扑的管理代理(300)的api的访问控制和使用控制。另外，策略(303)定义用于管理或使用实体化的服务的api的访问控制和使用控制。例如，当由监视系统(313)检测到安全威胁时，补救选项可以包括对多个访问控制策略作出变化。

策略(303)可以与多个独立节点、多个节点组、一类节点的多个节点、云服务的整个拓扑内的节点的子集相关联，并且对于其可操作；可以与作为整体的云服务的整个拓扑相关联，并且对于其可操作，或者与其组合相关联，并且相对于其可操作。如果在独立节点、节点组、或作为整体的云服务的整个拓扑上启动策略(303)，则策略将相对于独立节点、节点组、一类节点的节点、云服务的整个拓扑内的节点的子集来指引使用循环管理动作的发生，或者在独立节点、节点组、一类节点的节点、云服务的整个拓扑内的节点的子集上执行使用循环管理动作。

策略(303)类型的一个示例是规定策略，该规定能够与“第一天操作”相关联。当拓扑被规定、部署、和执行时，如果被实施，则规定策略可以定义包括云和云服务的计算设备和/或应用模型(319)的特性。兼容性策略能够和/或阶段和版本策略能够是规定策略的一部分。此规定能够包括拓扑(302)的基础结构模板320和平台。规定策略可以包括诸如像节点的物理位置之类的特性的定义。规定策略还可以(诸如在有或没有对因特网的访问的情况下或者是否在防火墙后的情况下)包括诸如像网络区之类的地理位置或部署类型位置、测试、预生产、生产、阶段、版本、发布、和/或拼接之类的特性的定义，以及其他地理或部署类型规定策略的定义。在此示例中，策略可以具有可以与服务器设备相关联的规定策略组件，其要求服务器设备位于国家的特定地理区域、诸如像与西海岸相对的美国的东海岸这样的特定区域、特定服务器设施、或者任何其他特定需求和/或地理位置。

关于定义计算设备(例如，存储器、网络等)的物理位置的规定策略，其他特性例如可以包括位置的安全级别或对节点所在之处的对因特网的访问。其他规定策略还可以例如包括例如节点耦合到的网络的带宽中的速度、节点是否将被连接到因特网或者内联网(诸如像非军事区(dmz)或者边界网络)、节点是否经受防火墙、节点是否可以访问因特网、节点是否将位于另一个节点的顶部、以及节点是否将使用特定基础结构元件或者平台而位于另一个节点的顶部、其他规定策略等。

如果被实施，则规定策略还可以取决于基于拓扑(302)的提出的云服务内的节点的需求和能力。需求定义节点(302-1、302-2、302-3、302-4、302-5、302-6、302-7)的需要，诸如像与过程有关的服务器或网络需要、存储器和操作系统(os)需要、其他形式的需要等。例如，需求策略可以指示节点要求与其相关联的特定软件或者特定软件版本，诸如特定操作系统。作为另一个示例，需求策略还可以指示特定结点可以要求与其相关联的额外的硬件设备，诸如像、服务器设备、服务器群组、或者高可用性配置等。

如处理器的性质、存储器、容量、os、中间软件类型、和版本等等之类的能力定义每个节点(302-1、302-2、302-3、302-4、302-5、302-6、302-7)、多个应用模型(319-1，319-2，319-3)、和/或多个基础结构模板(320-1，320-2，320-3,320-4,320-5)提供什么。因此，在一个示例中，能力策略(303)可以指示节点能够以特定速率处理数据。在另一个示例中，能力策略可以指示存储器设备可以具有太字节(tb)的数据存贮空间。

在又一个示例中，需求策略(303)可以指示节点要求特定计算平台、测试、预生产、生产、阶段、版本、发布、和/或拼接。当设计拓扑(302)时，元数据的拓扑或关联支持捕获数据，该数据定义包括硬件架构与和软件框架(包括应用框架)的计算平台内的多个硬件设备。当元数据被呈现或被关联时，其用于指引规定策略(303)，以便更好地选择计算平台内的合适的元素，诸如像适当的数据中心。当被呈现或被关联时，元数据还可以用于指引将拓扑的片段匹配到其他片段，如以下将结合把应用模型(319)拼接到基础结构模板(320)所更详细地讨论的。

关于能力策略(303)，节点可以定义它们是哪种设备、它们能够进行或者执行执行软件的什么版本、以及它们能够完成什么。能力策略的示例可以包括与节点相关联的定义，该定义把节点定义为应用服务器、节点提供java平台、企业版(j2ee)环境、节点运行特定操作系统、操作系统的版本，或者操作系统的版本的特定发布，以及多个其他能力。如本文所描述的，这可以用于确定例如可以部署什么其他方面或者什么其他设备可以使用云服务。

可以被指配的另一类型的策略(303)包括监视策略。监视策略是如下策略(303)，如果被实施，则定义节点(302-1、302-2、302-3、302-4、302-5、302-6、302-7)的操作监视、节点的安全监视、节点的兼容性监视、节点和节点的组之间的分析、节点的使用监视、性能监视、以及诸如像度量收集的智能监视、商业智能(bi)和业务活动监视(bam)、以及分析/大数据集成等其他类型的与监视有关的策略(303)。

监视策略(303)还可以定义预期哪种监视以及如何实施监视。关于节点操作的监视策略(303)的示例包括性能、监视网络内的各种节点的cpu级别和负载、监视通过节点或者多个节点处理数据或者在节点之间交换数据的速度、以及监视在任何级别的网络运行一个或多个节点上的应用的操作状态、等节点或节点的组以及作为整体的云服务的多个其他操作参数。

在另一个示例中，监视策略还定义如何处理出现在实例化的拓扑中的被监视的事件。在此示例中，监视策略协助事件处理器(316)接收和处理事件、并且做出关于由事件引起的事故的补救的决策、以及发送关于事故的通知消息。以下将更详细地描述规定(例如，第一天操作)或不同的(例如第二天操作)基于拓扑的管理代理(300)内的事件处理。既，监视策略包括这样的部分：定义怎样处理由监视引起的被监视的事件，诸如像如何处理事件、将事件发送到哪里、什么设备或个体解决事件、如何处理由事件的处理引起的事故、如何对事件和事故进行处理(例如，以聚合的、过滤的、或者关联的事件的形式进行处理，以及其他形式的处理)、以及如何处理产生的事故。

监视策略(303)还可以包括关于安全性的监视策略(303)。安全性策略(303)定义如何监视异常行为或被熟知为与已知的或可疑的安全性问题相关联的行为。关于安全性的监视策略(303)的示例包括：监视节点或者监视节点组是否经历攻击、在云服务或与云服务的交互内是否有奇怪的行为发生、以及关于节点或节点组是否存在病毒或其他异常、以及其他与安全性有关的监视策略(303)。

监控策略(303)还包括关于兼容性的监视策略(303)。关于兼容性的监视策略(303)包括关于节点或节点组是否在合适的版本或操作系统上运行的确定，确定与在节点上运行的软件程序的发布相关联的大部分最近的补丁是否已被安装，确定所安装的补丁是否是正确的补丁，检查已被用于规定节点和云服务的代码或人工制品以被关于任意弱点或问题适当地检查和诊断，对节点和云服务或节点和云服务的管理的支配和访问控制是否适当，以及所规定的系统的设定是否匹配诸如正确的登入层级、访问控制的正确设置、以及密码的正确设置之类的规定、安全性、或其他兼容性需求，以及其他与兼容性有关的监视策略(303)。

监视策略(303)还可以包括关于使用的监视策略。关于使用的监视策略(303)的示例包括：确定用户多大程度地使用了节点或节点组的cpu、确定用户多达程度地利用了存储器、确定对用户记了多少花费、以及用户是否已经支付通过网络拓扑的设计、规定、部署、以及监视所以提供的服务、以及其他与使用有关的监视策略(303)。

策略(303)可以进一步包括支配策略(303)，如果该支配策略被实施，则定义拓扑(302)或云服务内的节点(302-1、302-2、302-3、302-4、302-5、302-6、302-7)或者节点的组的访问控制。例如，支配策略(303)可以包括这样的策略(303)：定义谁可以访问拓扑(302)或云服务内的节点以及在什么条件下那些个体可以获得此类访问。

策略(303)可以进一步包括分析策略(303)，如果该分析策略被实施，则定义需要什么来确保节点(302-1、302-2、302-3、302-4、302-5、302-6、302-7)或者拓扑(302)内的节点组内的或者当中的分析和大数据监视，并且确保这如预期那样出现。例如，分析策略(303)可以定义多个工作流程，通过该多个工作流程监视系统(313)可以操作以配置云服务、提供分析、收集大数据、以及处理数据。

更进一步，策略(303)可以包括补救策略(303)，该补救策略定义如果在拓扑(302)的部署和执行期间出现问题或者发生事故，在拓扑(302)内将进行什么动作。补救策略可以(303)包括这样的策略(303)：定义由规定(例如，第一天操作)或不同(例如，第二天操作)基于拓扑的管理代理(300)在补救过程期间采取的多个动作，并且能够包括：(1)向用户、消费者、或管理员提供通知；(2)从用户、消费者、或管理员获得指令；(3)采取由用户、消费者、或管理员输入的手动动作；(4)在接收到来自用户、消费者、或管理员的指令之后采取自主动作；(5)在没有接收到来自从用户、消费者、或管理员接收指令的情况下采取自主动作；(6)在没有通知用户、消费者、或管理员或者没有从用户、消费者、或管理员接收指令的情况下采取自主动作；(7)向用户或管理员提出补救动作以求批准，并且如果被用户或管理员或者其组合批准则执行提出的补救动作。

作为示例，可能发生由拓扑(302)实例化的实现的或推断出的云服务的故障，并且补救策略(303)可以基于本文所描述的潜在的方案来定义可以如何处理故障。另外，补救策略(303)提供动作的实际的规则和工作流程以执行在任何数量的条件下补救事故或者指示把这些补救动作的决策制定和编排以及实施委派给谁或哪些设备。另一个补救示例可以基于例如基于拓扑(302)实现的云服务内的服务级协定(sla)或者服务质量(qos)来考虑维持服务的级别的潜在需要。在此示例中，可以基于本文所描述的潜在的方案来处理为支持对资源的需求的增加而进行的资源的添加。以下将更详细地描述关于实例化的实现的或推断出的所部署的拓扑的监视以及在其中的事件处理的更多细节。

如本文所描述的，节点(302-1、302-2、302-3、302-4、302-5、302-6、302-7)可以包括与节点(302-1、302-2、302-3、302-4、302-5、302-6、302-7)相关联的多个使用循环管理动作(lcma)(304)。lcma(304)是与当由(在其中实施拓扑(302)的)云服务环境内的策略(303)触发时由处理器执行的策略(303)相关联的多个动作。lcma可以与多个独立节点、多个节点组、一类节点中的多个节点、云服务的整个拓扑内的节点子集；作为整体的云服务的整个拓扑，或者其组合相关联，并且相对于其可操作。如果关于独立节点、节点组、或作为整体的云服务的整个拓扑来执行lcma，则lcma将关于在lcma内定义的关于独立节点、节点组、一类节点中的节点、云服务的整个拓扑内的节点子集、或者作为整体的云服务的整个拓扑采取动作。lcma(304)包括这样的动作：诸如像规定拓扑内的计算资源(例如，第一天操作)、发现和/或更新实现的或推断出的拓扑(例如，第二天操作)、复制拓扑的所有或多个部分、修改拓扑内的计算资源、移动拓扑内的计算资源、破坏或删除拓扑内的资源的动作、以及其他使用循环管理动作。

在本文描述的各种策略(303)定义在基于拓扑(302)的服务的实例化之前、期间、以及之后将通过拓扑(302)的使用循环执行什么动作。另外，在本文描述的各种策略(303)定义将如何执行这些动作。更进一步，在本文描述的各种策略(303)定义动作将被委派给哪些设备、个体、或者其组合。再进一步，在本文描述的各种策略(303)定义组合。例如，在事件处理和过程(handingandprocessing)或补救中使用的任何监视策略(303)可以定义监视或补救什么设备或云服务的什么部分、如何执行此类监视和补救、把监视和补救的功用委派给谁或什么设备、或其组合。

如本文所描述的系统和方法的结果，向用户提供实例化的服务(312)以进行使用。实例化的服务(312)包括匹配所设计的拓扑(302)和拓扑(302)内的节点(302-1，302-2，302-3，302-4，302-5，302-6，302-7)的多个计算设备。所实例化的服务(312)基于本文所描述的策略(303)发挥功能。组成所实例化的服务(312)的计算设备可以包括例如服务器、转换器、客户设备、和数据库、以及许多其他计算设备。实现的和/或推断出的拓扑(314)由lcm引擎(311)或其他基于所实例化的服务(312)的设备导出。

除所实例化的服务(312)之外，如果不存在监视系统(313)的话还部署监视系统(313)，或者如果监视系统(313)已经可用的话设置并且配置监视系统(313)，以监视所实例化的服务(312)。在规定(例如，第一天操作)或不同的(例如，第二天操作)基于拓扑的管理代理(300)中包括监视系统(313)的情况下，基于拓扑的管理代理(300)提供收敛的管理和安全性(cm&s)环境。在一个示例中，cm&s环境可以是由惠普公司开发并且发布的cm&s环境。在另一示例中，cm&s环境可以是通过引用全部包含于此的梅斯等的在称为“混合云环境”的公开号为pct/us2012/059209的国际专利申请中描述的cm&s环境。利用在部署的时间将管理和安全性能力绑定至服务模型的能力，cm&s环境向应用和服务的开发和部署提供基于模板和基于模型的方法，以保证跨混合云系统的公共能力。cm&s还提供跨私有云环境和公共云环境的可移植性，其可以包括异构基础结构、管理、和安全工具。另外，cm&s应用发布的高效交付和管理，不管基础结构资源是预置在公共云中的还是在跨公共云和私有云的混合环境中。cm&s还提供基于角色的、可预测的、并且实时的性能及风险洞察及分析，诸如业务智能(bl)、业务活动监视(bam)、和跨异构系统、网络和云环境的大数据分析。

此外，cm&s还可以用作支持自管理服务或自主管理服务的平台。相应地，cm&s可以支持本文所描述的编程模型。

在一个示例中，监视系统(313)基于与本文所描述的拓扑(302)和拓扑(302)的节点(302-1，302-2，302-3，302-4，302-5，302-6，302-7)相关联的监视策略(303)来操作。在此示例中，监视系统(313)用于监视操作、安全性、兼容性、和拓扑(302)和拓扑(302)的节点(302-1，302-2，302-3，302-4，302-5，302-6，302-7)的使用、以及在所实例化的服务(302)中监视的其他项。

在一个示例中，在其中监视系统(313)已经现存的情况下，监视系统(313)被部署以监视所实例化的服务(312)。在此示例中，通过将现存的监视系统(313)配置为匹配在设计拓扑(302)时定义的监视策略(303)，多个现存的监视系统可以用于自主地或通过人工干预来监视所实例化的服务。在此示例中，已经现存的监视系统(313)可以基于与所实例化的、实现的、和/或推断出的拓扑(302)相关联的监视策略(303)来配置并且用于实例化和/或本文所描述的拓扑(302)的所发现的节点302-1，302-2，302-3，302-4，302-5，302-6，302-7)，基于来自用户的输入来配置，或其组合。

相应地，在进行规定时修改诸如像例如通过自动或手动地将处理与与拓扑(302)的节点相关联的策略和lcma相匹配而生成的架构拓扑之类的所设计的拓扑。这可以通过利用规定策略引擎(502)或资源提供管理器(308)来执行规定策略以确定完美地满足或以最可能获得的方式满足规定策略的拓扑来执行。获得最合适的拓扑可以涉及由描述资源提供商的能力和选择脚本的资源提供管理器(308)提供的多个资源提供商策略(308-1)。

拓扑(302)由由箭头507所指示的规定策略引擎(502)按照接收到的规定策略(308-1)进行修改，并且拓扑(302)被发送至解译器(503)。解译器(503)是解译规定策略以创建由箭头508指示的执行计划的任意硬件设备或硬件设备和软件的组合。然后将结果解译并且转换成执行计划(508)，该执行计划(508)包括串行和/或并行的脚本的工作流或序列以创建拓扑(图1a，312)的实例。在一个示例中，编译器(503)是独立的装置或者包含于lcm引擎(图1a，311)之内。执行计划(508)包括串行和/或并行脚本的多个工作流或序列。拓扑lcm引擎(311)获得串行和/或并行脚本的工作流或序列，如箭头509所指示地经由资源提供管理器(308)调用资源提供商，并且创建在框505处创建所实例化的服务(312)。假设串行和/或并行脚本的工作流或序列是可执行的，其中它应当处于这种情况：架构描述性拓扑、与串行和/或并行脚本的多工作流或序列相关联的动作可由lcm引擎(311)来执行。

利用上述基于拓扑的序列，执行计划(508)可以被表示为蓝图。相反地，蓝图可以被表示为执行计划(508)。具有通过策略(303)和lcma(304)扩展的节点的蓝图可以以与过程基础结构拓扑相似的方式来相似地过程、替换。在此示例中，序列式服务设计(506)的形式的揽入被输入到如以上结合图5所描述的编译器中以进行处理。

由拓扑使用循环管理引擎(311)执行的执行计划(508)导致云服务的实例化，包括如以下将更详细地描述的规定设备以用于监视、事件处理、以及事件和事故的处理和补救。执行由运行计划(508)定义的串行和/或并行脚本的工作流或序列的拓扑使用循环管理引擎(311)的结果是由框508指示的所实例化的服务(312)。另外，实现拓扑(314)可以基于所实例化的服务(312)来创建，并且将如以下更详细地描述的内容来进行存储。

关于本文所描述的监视和补救策略，可以施加相同类型的过程，但是利用在所实例化的服务(312)内定义的多个实现的策略，并且利用它的实现拓扑(314)作为输入。在这种过程中，可以创建并且使用额外的lcma(304)来促进被更新的实例化的服务(312)中的规定资源。以下跨csa/cda使用案例的解释利用构架拓扑或利用蓝图示出了跨所有这些情况的公共引擎、模式、和平台的概念。

本系统和方法可以结合任意第三方建模来使用，诸如像heat命令语言编译器，该heat命令语言编译器是由openstackfoundation基于apache许可的事项开发并且发布的开源软件。尽管heat可以促进适用于执行计划的空间的一系列脚本的创建，但heat可以通过解译或翻译数据、并且将数据转换成脚本来提供支持。本系统和方法可以向heat编译器添加策略(303)和lcma(304)，并且可以如以上所述来执行。

另外，本系统和方法可以使用云应用的拓扑和编制oasis说明、用于表示拓扑的云计算标准。在此示例中，策略(303)和lcmas(304)添加至基于tosca的拓扑。

因此，在策略(303)和lcma(304)触发此类规定和部署时，策略(303)和lcma(304)可被实施为函数调用(305)或脚本以规定和部署拓扑(302)。资源提供管理器(308)可以被提供于基于拓扑的管理代理(300)内以基于策略(302)和lcma(304)来管理和提供计算资源。

资源提供管理器(308)提供多个插件以执行使用循环管理器(311)。如本文所描述的，资源提供管理器(308)将多个资源策略(308-1)与多个资源提供商的插件相关联，以使资源提供商可以促进指引多个资源提供商的选择过程。诸如与节点相关联的策略(103)之类的非资源提供商策略的不同之处在于：在拓扑(302)的设计期间，他们与节点(302-1、302-2、302-3、302-4、302-5、302-6、302-7)相关联。

资源提供管理器(308)可以由例如管理员或服务提供商来操作，以规定将要经由拓扑(302)的部署创建的云服务内的资源。如以上所讨论的，资源提供管理器(308)包括定义多个资源提供商策略(308-1)的硬件和软件，将那些多个资源提供商策略与多个节点(302-1、302-2、302-3、302-4、302-5、302-6、302-7)、拓扑(302)、或拓扑(302)的部分相关联。当拓扑(302)被部署时，资源提供商管理器(308)向将基于策略(303)、lcma(304)、和资源提供商策略(308-1)实施拓扑(302)的用户提供计算资源。结果，lcma是与拓扑(302)相关联的策略以及资源提供商策略(308-1)的功能。

因此，在一个示例中，资源提供商管理器(308)可以实施多个资源提供商策略(308-1)，该资源提供商策略(308-1)定义在什么情况下可以从多个服务提供商选择计算资源以在拓扑(302)中部署。在此示例中，策略(303)与节点相关联，并且与资源提供商策略(308-1)相关联，该资源提供商策略(308-1)定义从资源提供商管理器(308)选择哪个资源以用于在将要被部署的所实例化的拓扑(312)中进行规定。例如，如果与节点(302-1)相关联的策略要求所规定的计算资源位于安全设施内，并且由资源提供管理器(308)提供的资源的策略指示那些可用的计算资源不位于安全设施内，则将不选择那些由特定服务提供商所提供的非安全计算资源。以这种方式，与节点(302-1、302-2、302-3、302-4、302-5、302-6、302-7)相关联的策略和与资源提供管理器(308)相关联的策略确定可以在拓扑(302)内规定并且部署哪些计算资源。

基于拓扑的管理代理(300)可以将拓扑(302)存储于目录(310)中。在一个示例中，在目录(310)中设计和存储的拓扑可以经由自助门户(309)而对于任意感兴趣的方面是可用的。在另一示例中，替代自助门户，或者另外地提供的，可以提供应用程序接口(api)。在此示例中，可以由在基于拓扑的管理代理(300)内执行的程序来使用api，其可以针对多个拓扑(302)从目录(310)进行请求。

在另一示例中，可以给予用户这样的机会：查看所存储的拓扑的目录(310)以获得针对第一用户或组织创建的拓扑，并且通过订购或订阅拓扑(302)来将那些多个拓扑用作用户的拓扑。在又一示例中，可以给用户这样的机会：查看所存储的拓扑的目录(310)以获得针对第一用户或组织创建的拓扑，获得那些多个拓扑，以及向其添加多个其他拓扑，诸如在这样的一个示例中：使用以下描述的拼接过程，在基础结构模板上构建应用模型。

在又一示例中，可以给用户这样的机会：查看所存储的拓扑的目录(310)以获得针对第一用户或组织创建的拓扑，获得那些多个拓扑，以及向其添加多个其他拓扑，诸如，重新设计的拓扑或存储在目录(310)中的拓扑。在又一示例中，可以给用户这样的机会：查看所存储的拓扑的目录(310)以获得针对第一用户或组织创建的拓扑，获得那些多个拓扑，并且构建新的云服务，该云服务包括所有预定义的拓扑的方面以及由该预定义的拓扑所描述的相应的服务。

在另一示例中，用户、服务设计者、或其组合可以重新设计拓扑、基于存储在目录(310)中的拓扑设计拓扑、或者部分地基于存储在目录(310)中的拓扑设计拓扑。拓扑(302)的设计可以在多个用户、设计者、管理员之间分解。拓扑(302)的设计可以包括将拓扑的设计分离成多个多个拓扑，并且将单个拓扑的分离的片段和拓扑附接为多个特性、lcma、和策略的一个整体。用户还可以订购期望的拓扑、被给予同意所选择的拓扑的机会、以及通过在合成的云服务上执行多个应用来查看并且操作拓扑。

在另一示例中，应用程序接口(api)可以可用于唤醒与期望的拓扑(302)相关联的调用函数。在自助门户(309)的示例中，目录(310)对于用户可以是可用的、可以对用户识别与期望的拓扑(302)相关联的项、可以为用户提供订购多个服务的能力、和提供所选择的拓扑(302)的部署。在一个示例中，拓扑(302)的部署可以由用户或者通过基于例如服务层级同意(sla)、云服务的消耗、和策略、以及其他条件来同意部署之前的工作流来定义的管理器来同意拓扑(302)的部署。在另一示例中，当在目录(310)中设计和存储拓扑时，拓扑(302)可以由商业事项和可以如何使用拓扑(302)的相关联的描述符来识别。

在拓扑已被设计时，可以为了用户规定拓扑(302)以创建sla中的订阅。拓扑使用管理(lmc)引擎(311)是数据处理装置，该装置将执行拓扑(302)以规定并且部署计算资源以形成由用户使用的云服务。拓扑lcm引擎(311)分析所创建的拓扑，并且创建形成执行计划的形式的执行逻辑的一系列脚本以实例化并且实现拓扑(302)。在一个示例中，一系列脚本定义计算资源的规定和部署的序列。拓扑lcm引擎(311)应用与拓扑(302)和拓扑(302)的节点(302-1、302-2、302-3、302-4、302-5、302-6、302-7)相关联的策略、以及为由资源提供管理器(308)管理的资源设置的策略。

如本文所描述的系统和方法的结果，向用户提供实例化的服务(312)以进行使用。实例化的服务(312)包括匹配所设计的拓扑(302)和拓扑(302)内的节点(302-1，302-2，302-3，302-4，302-5，302-6，302-7)的多个计算设备。所实例化的服务(312)基于本文所描述的策略(303)发挥功能。组成所实例化的服务(312)的计算设备可以包括例如服务器、转换器、客户设备、和数据库、以及许多其他计算设备。实现的和/或推断出的拓扑(314)由lcm引擎(311)或其他基于所实例化的服务(312)的设备导出。

除所实例化的服务(312)之外，如果不存在监视系统(313)的话还部署监视系统(313)，或者如果监视系统(313)已经可用的话设置并且配置监视系统(313)，以监视所实例化的服务(312)。在基于拓扑的管理代理(300)中包括监视系统(313)的情况下，基于拓扑的管理代理(300)提供收敛的管理和安全性(cm&s)环境。在一个示例中，cm&s环境可以是由惠普公司开发并且发布的cm&s环境。在另一示例中，cm&s环境可以是通过引用全部包含于此的梅斯等的在称为“混合云环境”的公开号为pct/us2012/059209的国际专利申请中描述的cm&s环境。利用在部署的时间将管理和安全性能力绑定至服务模型的能力，cm&s环境向应用和服务的开发和部署提供基于模板和基于模型的方法，以保证跨混合云系统的公共能力。cm&s还提供跨私有云环境和公共云环境的可移植性，其可以包括异构基础结构、管理、和安全工具。另外，cm&s应用发布的高效交付和管理，不管基础结构资源是预置在公共云中的还是在跨公共云和私有云的混合环境中。cm&s还提供基于角色的、可预测的、并且实时的性能及风险洞察及分析，诸如业务智能(bl)、业务活动监视(bam)、和跨异构系统、网络和云环境的大数据分析。

在一个示例中，监视系统(313)基于与本文所描述的拓扑(302)和拓扑(302)的节点(302-1，302-2，302-3，302-4，302-5，302-6，302-7)相关联的监视策略(303)来操作。在此示例中，监视系统(313)用于监视操作、安全性、兼容性、和拓扑(302)和拓扑(302)的节点(302-1，302-2，302-3，302-4，302-5，302-6，302-7)的使用、以及在所实例化的服务(302)中监视的其他项。

在一个示例中，在其中监视系统(313)已经现存的情况下，监视系统(313)被部署以监视所实例化的服务(312)。在此示例中，通过将现存的监视系统(313)配置为匹配在设计拓扑(302)时定义的监视策略(303)，多个现存的监视系统可以用于自主地或通过人工干预来监视所实例化的服务。在此示例中，已经现存的监视系统(313)可以基于与所实例化的、实现的、和/或推断出的拓扑(302)相关联的监视策略(303)来配置并且用于实例化和/或本文所描述的拓扑(302)的所发现的节点(302-1，302-2，302-3，302-4，302-5，302-6，302-7)，基于来自用户的输入来配置，或其组合。

在另一示例中，可以基于定义和/或发现拓扑(302)的监视策略(303)来规定和部署之前不存在的监视系统(313)。在此示例中，在所实例化的服务(312)的规定和部署的同时规定和部署监视系统(313)。另外，在此示例中，基于与拓扑(302)和本文所描述的拓扑(302)的节点(302-1，302-2，302-3，302-4，302-5，302-6，302-7)相关联的监视策略部署和管理监视系统(313)。在本文所描述的示例中的任意示例中，创建由拓扑(302)描述的完成服务，包括所实例化的系统(312)和监视系统(313)。

基于拓扑的管理代理(300)进一步可以包括实现拓扑系统管理(rtsm)数据库(315)。rtsm数据库(315)是实现拓扑(314)和/或推断出的实现拓扑的逻辑系统存储库，并且可以是任意形式的数据存储库。在一个示例中，rtsm数据库(315)包括数据库管理系统(dbms)。dbms是与用户、其他应用、以及数据库本身交互以捕获并且分析数据的硬件设备与软件模块的组合。在一个示例中，rtsm数据库(315)是配置管理数据库(cmdb)。cmdb是与实现拓扑(314)的所有组件有关的信息的存储库。

rtsm数据库(315)的dbms被设计为允许实现拓扑(314)的数据库的定义、创建、询问、更新、和管理。实现拓扑是具有本文所描述的与此相关联的策略的的拓扑(302)的模型。因此，现的拓扑(314)包括拓扑(302)的模型，具有应用于各个节点(302-1，302-2，302-3，302-4，302-5，302-6，302-7)的策略。在实现拓扑(314)内定义实现拓扑(314)的节点(302-1，302-2，302-3，302-4，302-5，302-6，302-7)的多个属性。这些属性包括经由基于拓扑管理代理(300)所创建或更新的任何所实例化的服务(312)的任意细节，并且可以包括例如节点的互联网协议(ip)地址、以及节点的特性和计算参数，以及多个其他属性。

拓扑(302)能够是实现拓扑和/或推断出的拓扑。如本文所述的实现拓扑能够是这样的拓扑：由也利用实现拓扑的组织开发或映射的拓扑。推断出的拓扑能够是被发现的拓扑(302)。推断出的拓扑能够是利用多个方法发现的拓扑。发现推断出的实现拓扑能够包括将多个服务实例映射到推断出的实现拓扑中。在一些实施例中，发现推断出的实现拓扑能够包括在通用cmdb(例如，ucmdb)或相似系统中检验多个关系。在一些实施例中，检验多个关系包括发现关于云系统的所部署的系统的信息，以及检验关于所部署的系统的所发现的信息之间的关系。

发现推断出的实现拓扑能够包括利用企业地图数据来促进检验关于所部署的系统所发现的信息之间的关系。另外，发现推断出的实现拓扑能够包括执行多个人工编辑、人工指引、和/或推断出的实现拓扑的人工设计。在一些实施例中，能够通过推断出的实现拓扑的人工输入和/或人工设计，通过创建多个推断出的实现的实例，来发现推断出的实现拓扑。推断出的实现拓扑能够以与本文所描述的拓扑(302)和实现拓扑相同和/或相似的方式被利用。

在一些实施例中，拓扑(302)、实现拓扑、和/或推断出的拓扑能够被施加至由其他系统和/或其他实体规定或者由其他系统和/或实体管理的云服务。例如，云服务能够由诸如paas系统之类的服务规定或管理，该paas系统诸如cloudfoundry、heroky、openshift、亚马逊网页服务(aws)、魔豆、azure、由对于管理代理(300)未知的实体进行的自补救。

发现推断出的实现拓扑和/或实现拓扑能够使得管理代理(300)具有在管理代理(300)上构建/开发的应用，以在没有第一天操作的情况下用于第二天操作。如本文所描述的，在没有第一天操作的情况下的第二天操作能够包括规定和/或管理不由同一实体开发的云服务，如本文所描述的。另外，实现的和推断出的实现拓扑能够被管理代理(300)利用以管理和/或规定没有在之前被管理代理(300)管理和/或规定的服务。

rtsm(315)是存储实现拓扑(314)的每个实例的存储库。以这种方式，每次设计、规定、和部署拓扑(302)时，基于拓扑的管理代理(300)捕获那个拓扑(302)的实现拓扑(314)。因此，rtms(315)包含已经在基于拓扑管理代理(300)内实例化的每个拓扑(302)的实现拓扑(314)，或者通过以下所述补救进程，存储了实现拓扑或所实例化的服务(312)的修改。因此，在一个示例中，在已有拓扑(302)的修改的每个实例中，来自修改的实现拓扑(314)也存储在rtsm(315)内。基于拓扑的管理代理(300)进一步包括实现拓扑系统管理(rtsm)数据库(315)。rtsm数据库(315)是实现拓扑(314)的逻辑系统储存库并且可以是任何形式的数据储存库。在一个示例中，rtsm数据库(315)包括数据库管理系统(dbms)。dbms是与用户、其他应用程序以及数据库自身交互以捕获并分析数据的硬件装置与软件模块的组合。在一个示例中，rtsm数据库(315)是配置管理数据库(cmdb)。cmdb是与实现拓扑(314)的所有部件相关信息的储存库。

如可能在基于拓扑的管理代理(300)中，在基于拓扑的管理代理(300)中可能发生多个事件。这些事件可以包括例如所实例化的服务(312)中的策略故障、所实例化的服务(312)中的一个或多个硬件或软件组件的故障、和所实例化的服务(312)的未授权的访问、以及多个与计算有关的事件。另外，监视系统(313)监视可能在所实例化的服务(312)中发生的多个与性能有关的事件和与使用有关的事件。这些与性能有关的事件和与使用有关的事件可以包括例如多个节点内的处理器利用、例如由用户商务的顾客进行的多个节点的利用、和数据存储设备内的剩余数据存储空间的水平、以及多个其他与性能有关的事件和与使用有关的事件。

在一个示例中，监视系统(313)通知事件处理器(316)由监视系统(313)检测到的任意事件。事件处理器(316)是从检测系统(313)接收与检测到的事件相关联的数据、并且处理数据以创建可能从检测到的事件引起的多个事故的任意计算系统。

因此，基于拓扑的管理代理(300)处理由监视系统(300)检测到的事件。由监视系统(313)检测到的事件的过程可以由事件处理器(316)执行。事件处理器(316)可以从监视系统(313)接收任意种类或数量的数据。如以上所描述的，由事件处理器(316)从监视系统(313)接收的数据可以包括与作为整体的所示例化的服务(312)的操作和使用相关联的任意数据，以及作为节点组和单个节点的所实例化的服务(312)内的节点(302-1，302-2，302-3，302-4，302-5，302-6，302-7)。在一个示例中，事件处理器(316)执行事件数据的多个请求。在此示例中，事件处理器(316)可在预定义的时间段之后、随机地、在由另一事件触发时(或其组合)针对事件数据轮询监视系统(313)。如以上所描述的，在一个示例中，事件处理和过程可以被指派至另一系统或第三方服务。例如，诸如事件和事故的校正和过滤之类的事件处理和事故识别可以被指派至hp商业服务管理：由惠普公司开发并且发布的一套服务管理软件工具。补救过程可以被指派至hp操作管理器i(hpomi)或者sitescope：两者均包括一套由惠普公司开发并且发布的软件工具。安全性之间通知、过程、和补救可以被指派至hparcsight：一套由惠普公司开发并且发布的服务管理软件工具。在一个示例中，hparcsight可以参考与所实例化的服务(312)相关联的服务管理(sa)以遵从sa。

从监视系统(313)接收到的数据由事件处理器(316)处理，并且事件处理器(316)确定事件是否需要补救动作、是否以如何向用户、管理员、第三方、或基于拓扑的管理代理(300)或所实例化的服务(312)的其他用户呈现事件的通知。如果事件处理器(316)确定要结合事件采取补救动作，则事件处理器(316)基于事件生成事故，并且将与事件相关联的数据发送至补救引擎(317)。在一个示例中，事件处理器(316)可以使用多个过程类型处理从监视系统(313)接收到的事件。事件处理器(316)可以执行的处理的类型包括事件的过滤、校正、和聚合、以及其他形式的事件处理、以及其组合。在一个示例中，多个事件可以共同遭受多个形式的事件处理以创建事故。在此示例中，事件可以单独地不支持需要补救的事故的创建，而当由事件处理器(316)分析时，多个事件可以指示所实例化的拓扑(312)内的问题不同意策略(303)、或者另外地需要补救。

在另一示例中，可以由多个票券支持系统识别事故。例如，信息技术(it)服务管理系统(itsm)(316-1)也可以是事故的来源。itsm系统(316-1)实施并管理满足用户需求的it服务的质量。在一个示例中，由用户、服务提供者、第三方或其组合管理itsm系统(316-1)，其中由这些群组或个人的一个开启服务票券。在另一示例中，itsm系统(316-1)可以基于由监控系统所检测的事件而自动地输入服务票券。如果itsm系统(316-1)确定实例化的系统(312)或其多个节点(302-1，302-2，302-3，302-4，302-5，302-6，302-7)并未恰当地提供而是错误地提供、或者另外不适用于所实例化的系统(312)，itsm系统(316-1)可以与事件处理器(316)类似而以发送至补救引擎(317)的事故为形式提供补救决定。

由事件处理器(316)和itsm系统(316-1)所产生的事故可以以通知的形式引起用户、管理员、第三方、或者基于拓扑的管理代理(300)或被实例化的服务(312)的其他用户的注意。如上所述，补救策略定义了如何执行补救动作，并且可以包括：(1)向用户、消费者或管理员提供通知；(2)从用户、消费者或管理员获得指令；(3)采取由用户、消费者或管理员输入的手动动作；(4)在从用户、消费者或管理员接收指令之后采取自动动作；(5)采取自动动作而并未从用户、消费者或管理员接收指令；(6)采取自动动作而并未通知用户、消费者或管理员，或者从用户、消费者或管理员接收指令；或者其组合。以这种方式，由补救策略定义了系统内通知的发布。

补救引擎(317)经由处理器执行逻辑以校正由事件处理器(316)和/或itsm系统(316-1)报告的事件。在多个其他补救动作之中，由补救引擎(317)发布的补救可以例如包括额外计算资源的分配、不同计算资源的分配、以及从一个地理区域至另一个的计算资源的重新分配。在一个示例中，实施由补救引擎(317)采取的补救动作以补救并未遵从与所设计的拓扑(302)相关联的策略的计算资源的错误分配。在另一示例中，实施由补救引擎(317)采取的补救动作以补救所实例化的服务(312)内多个计算资源的故障。在另外又一示例中，实施由补救引擎(317)采取的补救动作以调整所实例化的服务(312)以及其中群组和单个计算资源的安全水平。为了任意多个原因可以由补救引擎(317)实施任意多个其他补救动作。

在一个示例中，由补救引擎(317)采取补救动作而通知或不通知用户、管理员、第三方、或如上所述的其他用户。进一步，在另一示例中，自动地实施由补救引擎(317)采取的补救动作，并未与用户交互或者由用户确认。

在另外又一示例中，实施由补救引擎(317)采取的补救动作而具有与消费者、管理员、第三方或其他用户的用户交互。在该示例中，补救引擎(317)发送数据至自助订购管理引擎(318)。自助订购管理引擎(318)经由处理器执行逻辑以向用户展示关于由监控系统(313)所检测的事件以及由事件处理器(316)和itsm系统(316-1)所生成的事故。自助订购管理引擎(318)也经由处理器执行逻辑以向用户展示用于事件和事故的补救的多个推荐。

在一个示例中，自助订购管理引擎(318)经由处理器执行逻辑以向用户展示多个图形用户界面(guis)(318-1)。在该示例中，guis(318-1)允许用户查看实现的的拓扑(314)，以及由监控系统(313)检测的事件和由事件处理器(316)和itsm系统(316-1)生成的事故。以这种方式，用户能够经由自助订购管理引擎(318)所生成的guis(318-1)而识别实现拓扑(314)内的问题。进一步，guis(318-1)允许用户选择被推荐的补救动作并且定义可以如何执行补救动作。

在另一示例中，自助订购管理引擎(318)可以经由处理器执行api以在实现拓扑(314)的表示内向用户提供多个指示器，代表了在实现拓扑(314)内的问题，与关于问题以及在实现拓扑(314)内问题与哪些节点(302-1，302-2，302-3，302-4，302-5，302-6，302-7)相关联的信息配对出现。

当补救引擎(317)执行其逻辑以校正由事件处理器(316)和itsm系统(316-1)所报告的事故时，和/或当用户经由自助订购管理引擎(318)选择待采取的补救动作时，基于拓扑的管理代理(300)执行对多个使用循环管理动作(lcma)的多个调用以补救事故。lcma可以例如包括复制、移动、复写、或关停多个计算资源，在其他lcma之中，包括实现拓扑(314)的全部或一部分。

拓扑lcm引擎(311)执行通过补救进程所创建的新拓扑(302)以提供并部署计算资源以形成新的所实例化的服务(312)。因此，拓扑lcm引擎(311)迭代地将从自助订购管理引擎(318)和补救引擎(317)接收的lcma应用至实现拓扑(314)以创建新的和后续所实例化的服务(312)。

补救进程包括监控系统(313)、事件处理器(316)、itsm系统(316-1)、补救引擎(317)、自助订购管理引擎(318)、拓扑lcm引擎(311)、或其组合的功能的全部。该补救进程的任意数目迭代可以应用于后续实现拓扑(314)以创建后续新的所实例化的服务(312)。以这种方式，新的所实例化的服务(312)将包括与所设计的拓扑(302)以及由被执行的lcma经由补救进程做出的变化相匹配的多个计算资源。因此，具有拓扑lcm引擎(311)的基于拓扑的管理代理(300)从新的和后续的所实例化的服务(312)导出新的和后续的实现拓扑，并且在rtsm(315)中存储了后续实现的的拓扑。

基于以上，基于拓扑的管理代理(300)能够自动地提供、部署、和维持所实例化的服务(312)而具有或不具有用户交互。因此，以这种方式，在所实例化的服务(312)上执行的多个应用程序能够通过例如调用api而在所实例化的服务(312)上自动执行。

如上所述，蓝图(100)的结构难以与持续交付(cda)相同而用作应用模型或基础结构模板。cda是在拓扑设计器内所利用的系统工具，独立地对基础结构和应用需求建模而同时管理了版本、配置和其他应用程序部件。cda也由惠普公司研发并发售。对于以上给出的相同原因，蓝图(100)的结构难以用作应用程序模型，因为蓝图并未描述应用程序的架构。进一步，蓝图难以用作基础结构的模板，因为它们也并未描述基础结构的架构。结果，目的在于对应用程序模型和基础结构或平台模板建模、并且将应用程序模型和基础结构或平台模板相互映射的系统并未容易地与蓝图顺从一致，因为它们是基于对这些服务建模的不同方法。现在将描述在被部署服务上执行的多个应用程序的模型与服务的基础结构模板之间的顺从。

如图4中所示，基于拓扑的管理代理(300)进一步包括能够独立地对在与图3a中所示子系统相同堆叠上拓扑的基础结构和应用需求建模的子系统。然而，如上所述，本发明的系统和相关联的方法也支持所有使用情形，cda支持诸如那些cda所支持的。如上所述，cda是在拓扑设计器内利用的多个软件工具，独立地对基础结构和应用需求建模而同时管理了版本、配置和其他应用程序部件。cda也由惠普公司研发并发售。

图4中所示的基于拓扑的管理代理(300)的子系统可以用于设计用于将要执行在所实例化的服务(312)上的多个应用程序的拓扑。图4的子系统帮助提供、部署、并维持支持了应用程序并且提供了与合适的基础结构模板匹配的应用程序模型的拓扑。在一个示例中，执行在被部署拓扑上的应用程序的模型应用被设计的拓扑，其易于顺从定义了拓扑的基础结构拓扑的模板。

拓扑设计器(301)可以用于设计并创建应用程序模型(319)。应用程序模型(319)由使用循环管理拓扑所定义。如上结合lcm拓扑(302)所述，应用程序模型(319)包括多个节点(319-1，319-2，319-3)。多个策略和使用循环管理动作(lcma)与应用程序模型(319)的每个节点(319-1，319-2，319-3)相关联。

拓扑设计器(301)还可以用于创建多个基础结构和/或平台模板(320)。模板(320)由使用循环管理拓扑所定义。如上结合lcm拓扑(302)所述，模板(320)包括多个节点(320-1，320-2，320-3，320-4，320-5)。多个策略和使用循环管理动作(lcma)还与模板(320)的每个节点(320-1，320-2，320-3，320-4，320-5)相关联。

在一个示例中，拓扑设计器(301)、自助端口(309)和资源提供管理器(308)单独地或组合地可以将多个策略(303)和lcma(304)与应用程序模型(319)和基础结构模板(320)的节点(319-1，319-2，319-3，320-1，320-2，320-3，320-4，320-5)相关联。在另一示例中，可以提供分立的策略引擎和lcma引擎以将应用程序模型(319)和基础结构模板(320)的节点(319-1，319-2，319-3，320-1，320-2，320-3，320-4，320-5)与如上所述的策略和lcma相关联。

如图4中所示，多个模型(319)可以表示为对于多个基础结构模板(320)可能匹配或近似匹配。在一个示例中，不同于使用拓扑设计器(301)，可以在基于拓扑的管理代理(300)内提供多个应用程序模型(319)资源。在该示例中，基于拓扑的管理代理(300)可以从例如目录(310)、rtsm(315)、另一模型资源、或其组合获得应用程序模型(319)。用户可以完整浏览这些模型资源并获得可以顺从基础结构模板(320)的多个应用程序模型(319)。以这种方式，拓扑设计器(301)可以设计多个应用程序模型(319)，或者可以从上述资源获得多个应用程序模型(319)。因此，应用程序模型(319)可以是由拓扑设计器(301)所设计的应用程序拓扑，或者如上所述的实现的的应用程序拓扑。

类似地，如图4中所示，多个模板(320)表现为对于应用程序模型(319)可能匹配或近似匹配。在一个示例中，不同于使用拓扑设计器(301)，可以在基于拓扑的管理代理(300)内提供多个模板(320)资源。在该示例中，基于拓扑的管理代理(300)可以从例如目录(310)、rtsm(315)、另一模板资源、或其组合而获得模板(320)。用户可以完整浏览这些模板资源并获得可以顺从应用程序模型(319)的多个模板(320)。以这种方式，拓扑设计器(301)可以设计多个模板(320)，或者可以从如上所述资源获得多个模板。因此，模板(320)可以是由拓扑设计器(301)设计的基础结构拓扑，或者如上所述的实现的的基础结构拓扑。

基于拓扑的管理代理(300)进一步包括实现拓扑系统管理(rtsm)数据库(315)。rtsm数据库(315)是实现拓扑(314)的逻辑系统储存库，并且可以是数据储存库的任意形式。在一个示例中，rtsm数据库(315)包括数据库管理系统(dbms)。dbms是与用户、其他应用程序以及数据库自身交互以捕获并分析数据的硬件装置和软件模块的组合。在一个示例中，rtsm数据库(315)是配置管理数据库(cmdb)。cmdb是与实现拓扑(314)的所有部件相关信息的储存库。

rtsm数据库(315)的dbms被设计为以允许实现拓扑(314)的数据库的定义、创建、查询、更新和管理。实现拓扑是具有如上所述与其相关联策略的拓扑(302)的模型。因此，实现拓扑(314)包括拓扑(302)的模型，具有应用于各个节点(302-1，302-2，302-3，302-4，302-5，302-6，302-7)的策略。在实现拓扑(314)内定义实现拓扑(314)的节点(302-1，302-2，302-3，302-4，302-5，302-6，302-7)的多个属性。这些属性包括经由基于拓扑管理代理(300)所创建或更新的任何所实例化的服务(312)的任何细节，并且可以包括例如节点的互联网协议(ip)地址、以及节点的特性和计算参数，以及多个其他属性。

rtsm(315)是存储了被设计和/或推断的实现拓扑(314)的每个实例的储存库。以这种方式，每次设计、提供、推断、并部署拓扑(302)时，基于拓扑的管理代理(300)捕获该(302)的实现拓扑(314)。因此，rtsm(315)包含已经在基于拓扑管理代理(300)内被实例化的每个拓扑(302)的实现拓扑(314)，或者通过以下所述补救进程，存储了实现拓扑或所实例化的服务(312)的修改。因此，在一个示例中，在已有拓扑(302)的修改的每个实例中，来自该修改的实现拓扑(314)也存储在rtsm(315)内。

rtsm数据库(315)的dbms被设计为允许对于实现拓扑(314)的数据库的定义、创建、查询、更新和管理。实现拓扑是具有如上所述与其相关联策略的拓扑(302)的模型。因此，实现拓扑(314)包括拓扑(302)的模型，具有应用于各个节点(302-1，302-2，302-3，302-4，302-5，302-6，302-7)的策略。在实现拓扑(314)内定义实现拓扑(314)的节点302-1，302-2，302-3，302-4，302-5，302-6，302-7)的多个属性。这些属性包括经由基于拓扑管理代理(300)所创建或更新的任何所实例化的服务(312)的任何细节，并且在多个其他属性之中可以包括例如节点的互联网协议(ip)地址，以及节点的特性和计算参数。

rtsm(315)是存储了被设计和/或推断的实现拓扑(314)的每个实例的储存库。以这种方式，每次设计、提供、推断、并部署拓扑(302)时，基于拓扑的管理代理(300)捕获该(302)的实现拓扑(314)。因此，rtsm(315)包含已经在基于拓扑管理代理(300)内被实例化的每个拓扑(302)的实现拓扑(314)，或者通过以下所述补救进程，存储了实现拓扑或所实例化的服务(312)的修改。因此，在一个示例中，在已有拓扑(302)的修改的每个实例中，来自该修改的实现拓扑(314)也存储在rtsm(315)内。

多个资源提供器策略(308-1)可以与拓扑(302)内多个节点(302-1，302-2，302-3，302-4，302-5，302-6，302-7)相关联(方框704)。资源提供器策略(308-1)是与多个资源提供器的提供物相关联的任何策略，其引导了多个资源的选择。在一个示例中，资源提供器策略(308-1)可以是定义了计算资源的计算能力的动态函数。在该示例中，如果计算资源的所定义水平满足拓扑(302)内多个需求，可以由lcm引擎(311)和资源提供管理器(308)提供计算资源，其提供了计算资源的所定义水平诸如例如处理能力。

图6是根据本文所描述的原理的一个示例示出的设计拓扑的方法的流程图。图6的方法可以由生成(框630)应用模型(图4，319)开始。在一个示例中，可以使用拓扑设计器(301)来设计和创建应用模型(图4，319)，并且，以这样的方式，生成应用模型(图4，319)。在另一个示例中，可以从多个应用模型(图4，319)源获得应用模型(图4，319)，该应用模型源诸如像目录(图3，310)、rtsm(图3，315)、或者dsl数据库(图4，323)、以及其他应用模型(图4，319)源。由使用循环管理拓扑来定义应用模型(图4，319)。如在本文结合lcm拓扑(图3，302)描述的，应用模型(图4，319)包括多个节点(图4，319-1、319-2、319-3)。

生成(框630)应用模型可以包括将应用设计(框532)为自管理、自动管理、或者其组合。还可以生成(框534)多个基础结构模板(图4，320)。在一个示例中，可以使用拓扑设计器(301)来设计并且创建基础结构模板(图4，320)。在另一个示例中，可以从多个基础结构模板(图4，320)源获得基础结构模板(图4，320)，该应用模型源诸如像目录(图3，310)、rtsm(图3，315)、或者dsl数据库(图4，323)、以及其他基础结构模板(图4，320)源。由使用循环管理拓扑来定义基础结构模板(图4，320)。如在本文结合lcm拓扑(图3，302)描述的，基础结构模板(图4，320)包括多个节点(图4，319-1、319-2、319-3)。在一个示例中，多个人可以使用拓扑设计器(301)来设计应用模型(图4，319)和基础结构模板(图4，320)。这些个体可以是服务设计者、基础结构建筑师或管理员、系统管理员、信息技术操作员、报价经理、或用户等具有设计拓扑时的功用的其他人员。

多个应用模型(图4，319)被拼接(框903)为多个基础结构模板(图4，320)。在一个示例中，拼接引擎(图4，321)可以获得存储在例如dsl数据库(图4，323)或者基础结构模板(320)的其他源中的多个基础结构拓扑(图4，320)，并且将多个应用模型(图4，319)拼接为多个合适的基础结构模板(图4，320)。在另一个示例中，可以由多个拓扑设计器(301)来重新设计基础结构模板(图4，320)。

拼接引擎(图4，321)可以使用任何类型的方法来基于将应用模型(图4，319)关联基础结构模板(图4，320)的策略和lcma将应用模型(图4，319)拼接为基础结构模板(图4，320)。在一个示例中，拼接引擎(图4，321)可以使用匹配过程，在此匹配过程中，拼接引擎(图4，321)使与应用模型(图4，319)的节点(图4，319-1、319-2、319-3)相关联的策略、需求、和能力与基础结构模板(图4，320)的节点(图4，320-1、320-2、320-3、320-4、320-5)的策略、需求、和能力相匹配。在此示例中，拼接引擎(图4，321)可以浏览在本文描述的模板源以找出匹配或接近匹配。一旦找出匹配，拼接引擎(图4，321)将应用模型(319)的多个节点(图4，319-1、319-2、319-3)与匹配的基础结构模板(图4，320)的多个节点(图4，320-1、320-2、320-3、320-4、320-5)相匹配。

可以被拼接引擎(图4，321)使用以将应用模型(图4，319)拼接到基础结构模板(图4，320)的另一种方法可以包括算法匹配方法。在此方法中，拼接引擎(图4，321)在执行匹配决策时经由采用策略的算法进行数学上的确定。在一个示例中，这可以包括推理方法，在该推理方法中，应用级别中的需求被标记或者利用在dsl数据库(图4，323)中支持它们的组件被标记或以另外方式与其相关联，其中，在将聚合被扩展到应用模型(图4，319)之前首先聚合全部基础结构拓扑(图4，320)。

多个策略和使用循环管理动作(lcma)与应用模型(图4，319)的节点(图4，319-1、319-2、319-3)以及基础结构拓扑(图4，320)的节点中的每一个相关联。在一个示例中，可以由拓扑设计器(301)、自助门户(309)、以及资源提供管理器(308)单独或组合地来执行多个策略(303)和lcma(304)与应用模型(319)和基础结构拓扑(320)的节点(319-1、319-2、319-3、320-1、320-2、320-3、320-4、320-5)的关联。在另一个示例中，可以提供分立的策略引擎和lcma引擎以使应用模型(319)和基础结构拓扑(320)的节点(319-1、319-2、319-3、320-1、320-2、320-3、320-4、320-5)与在本文所描述的策略(303)和lcma(304)相关联。

在一个示例中，可以在与框636结合描述的拼接过程之前、期间、或之后执行使策略(303)和使用循环管理动作(lcma)(304)与应用模型(319)的节点(图4，319-1、319-2、319-3)和基础结构拓扑(图4，320)的节点中的每一个关联过程。在一个示例中，在框634的拼接过程之前策略和lcma被关联的情况下，策略(303)和lcma(304)可以与应用模型(319)和基础结构拓扑(320)内的多个节点或者节点组相关联，以及与作为整体的应用模型(319)和作为整体的基础结构拓扑(320)相关联。在此示例中，额外的策略(303)和lcma(304)可以与经由拼接过程而创建的拓扑(302)相关联。在另一示例中，，使策略(303)和使用循环管理动作(lcma)(304)与应用模型(319)的节点(图4，319-1、319-2、319-3)和基础结构拓扑(图4，320)的节点中的每一个相关联的过程对于在框634的拼接过程之后进行的这些过程的执行而言可以是可选的。在又一个示例中，可以在框534的拼接过程之前和之后执行使策略(303)和使用循环管理动作(lcma)(304)与应用模型(319)的节点(图4，319-1、319-2、319-3)和基础结构拓扑(图4，320)的节点中的每一个相关联的过程。

在图6中描述的过程产生类似于结合本文的图3描述的拓扑(302)的完整设计的拓扑(302)。例如，根据图6的方法产生的拓扑(图4，302)可以用作输入拓扑(图3，302)。另外，在另一个示例中，根据图6的方法产生的拓扑(图4，302)可以用作输入拓扑(图3，302)以用于补救的实例化。更进一步，在一个示例中，多个人参与图6中所描述的方法。这些个体可以是服务设计者、基础结构建筑师或管理员、系统管理员、信息技术操作员、报价经理、或用户、以及具有在拓扑(302)的设计、执行、监视和补救时的功用的其他人员。

图7是根据本公开的系统(700)的示例。图7包括在没有第一天操作的情况下的第二天操作。例如，图7包括根据先前的拓扑被规定和/或修改的方式来对实现拓扑进行解耦。如在本文所描述的，系统(700)是这样的系统：实现拓扑能够不仅仅是由于它们已经被系统(600)规定和管理而被熟知，而且它们还能够是发现的实现拓扑和/或推断出的实现拓扑。系统(700)能够包括各种元件来规定和管理云系统。

发现的拓扑指的是从系统(700)之外的不同的系统获得与拓扑(即，未曾被规定或者可能已经与主系统(700)分立地管理和修改的拓扑)有关的信息的能力。

例如，拓扑能够来自规定了拓扑的另一个云控制器或系统(例如像vcenter的vmw控制器、像sa的遗留规定器、不与系统(700)连接的系统等等)。在另一个示例中，能够从资源库中推断出拓扑，其中，由设计和/或定义拓扑(例如hp企业地图-em)、规定(例如，hpucmdb)和/或管理/修改拓扑、或修改了由系统规定的实例的任何人或任何系统在资源库中存储了信息。

例如，推断出的拓扑能够是来自sa(服务器自动化)的设计和/或规范或者存储在cmdb中的信息。在推断出的情况中，来自资源库的信息能够被加载到系统(700)中并且利用策略(例如，利用与不同的元件和相关联的策略(例如，也从在用于节点类型的某上下文/数据中关联的策略推断出或由其产生)相关联的使用循环管理动作)映射至拓扑。在一些实施例中，推断出的拓扑和/或相关联的策略可能是最佳猜测。推断出的拓扑能够暴露什么是已知的(例如，就策略或lcm而言系统(700)能够使用什么以进行进一步管理)。然后能够使用类似于拓扑设计器的控制台来手动地更新遗漏的拓扑信息和/或对推断出的拓扑的校正(例如，lcm细节、依赖性/关系、策略)。

当实现拓扑不是系统(700)进行的规定、管理(例如，补救之外的管理)、或补救的结果时，以及当其他系统对实现拓扑的管理起作用时，系统(700)能够是重要的。例如，额外的系统能够独立地监视、管理、或补救实现拓扑(例如，系统700是基于hpcsa的)。在一些实施例中，csa策略能够包括分享cmdb中的实现拓扑实例。在另一个示例中，像hpsa(服务器自动化)的系统能够使用所存储的信息来执行监视(例如，对操作、使用安全性、和/或兼容性的监视)、管理、和/或补救。在一些实施例中，能够并行地进行与系统(700)无关的监视、管理、和/或补救。因此，不使用系统(700)完成兼容性监视和/活补救。在一些实施例中，拓扑可能需要被重新发现或推断，如在本文所描述的，或者简单地因为系统(700)被通知将信息输入回系统(700)或者被通知变化。发现系统因此能够跟踪对实例的变化或通知并且还在其存储和追踪的对实例的更新中反映这些。也就是说，在规定之后，能够通过外部系统(例如，系统(700)之外的系统)来执行一些步骤。结果，为了维护系统(700)的能力，可能重要的是，也把对实例的更新反映到系统(700)中。因此，系统(700)能够重新发现对实例或系统(700)的变化、能够被通知变化(即，通知)。

在一些实施例中，应用被部署在接管实现拓扑的一些或所有管理步骤的平台中。例如，应用被部署在像云铸造场的paas或其他执行和管理平台中，其中同时系统(700)能够用于部署应用和/或paas及其环境(例如，基础结构上的paas部署、清单生成、以及paas中的代码部署)。然后paas能够管理实现拓扑(例如自动定标)。当发生这种情况时，系统(700)可以不执行对实现拓扑的变化。继续涉及管理实现拓扑，需要在本文描述的当前解决方案(例如，通过将实现拓扑的更新作为从云铸造场输入(或者同步)的实现拓扑的更新来跟踪，实现拓扑的更新被系统(700)跟踪或者被通知给系统(700))。

系统(700)能够包括用户接口(702)。能够利用用户接口(702)来显示与云系统有关的信息。在一些实施例中，能够利用用户接口(702)来输入与云系统有关的数据。能够利用系统(700)来可视化在本文描述的推断出的实现拓扑。在一些实施例中，能够利用系统(700)来修改推断出的实现拓扑。例如，修改推断出的实现拓扑能够包括：编辑、校正、和/或补充推断出的实现拓扑(例如，利用lcm、策略(303)、和/或与推断出的实现拓扑有关的其他信息)。在一些实施例中，能够利用系统(700)来从其他系统和/或推断出的实现拓扑的文件驱动和/或加载信息。如在本文所描述的，还能够利用系统(700)以与将管理实现拓扑和/或发现的拓扑的系统相同的和/或类似的方式来管理推断出的实现拓扑。另外，系统(700)能够实现进行lcm动作的选择。在一些实施例中，补充拓扑能够包括将策略(303)绑定到拓扑。例如，补充拓扑能够包括把从数据中心上的策略导出的策略(303)绑定到拓扑的相同的和/或类似的节点类型。也就是说，能够通过把策略(303)绑定到发现的和/或推断出的拓扑的多个节点来更新发现的和/或推断出的拓扑。因此，能够由系统(700)规定和管理这些发现的和/或推断出的拓扑的发现的和/或推断出的实例。

此外，系统(700)能够包括提出对拓扑、关系、依赖性、和/或策略(303)进行变化的选项。能够由系统(700)在实现拓扑上制定提出的变化。例如，提出的变化能够包括用于移动节点、复制拓扑、和/或退出拓扑的指令。在一些实施例中，系统(700)能够批准由推荐引擎推荐的补救。提出对拓扑、关系、依赖性、和/或策略(303)进行变化的选项还能够包括变化代码(即，不使用设计器)。在一些实施例中，当利用toscayaml分布表示拓扑时，能够由yaml做出这些变化。

系统(700)能够包括目录(704)。在一些实施例中，目录(704)能够包括能够被利用以存储与云系统有关的信息的计算机可读介质。在一些实施例中，能够利用目录(704)来存储与云系统的部署的系统有关的信息。因此，可以不在最初通过系统(700)规定实现拓扑，而是通过系统(700)之外的不同的系统在一些点更新和/或管理实现拓扑。

系统(700)能够包括基于策略的实施、编排、和集成工具(706)。基于策略的实施、编排、和集成工具(706)能够包括多个策略(303)，该多个策略(303)能够被利用以用于云系统上的服务的部署。如在本文所描述的，策略(303)能够是状态和版本策略(303)、和/或兼容性策略(303)、以及等其他策略(303)。在一些实施例中，策略(303)然后被应用(例如，自动地应用、通过补充应用，等等)于不是最初由系统(700)规定的实现拓扑。

系统(700)能够包括服务和实例资源库(708)。服务和实例资源库(708)能够包括计算机可读介质，能够利用该计算机可读介质以存储与来自云系统的多个服务和/或多个实例有关的信息。系统(700)能够包括模型资源库(710)。模型资源库(710)能够包括计算机可读介质，该计算机可读介质能够存储与云系统的应用模型(319)、云系统的拓扑(302)、云系统的实例、云系统的环境、和/或期望的云系统的环境有关的信息。

系统(700)能够包括发现模块(712)，该发现模块(712)能够启动拓扑的自动和/或手动发现。如在本文所描述的，发现模块(712)能够发现系统(700)的实现拓扑和/或推断出的拓扑。系统(700)能够包括报告平台(714)。能够利用报告平台(714)来发送错误的报告和/或云系统状态的报告。系统(700)能够包括公共数据存储库(716)。公共数据存储库(716)能够包括计算机可读介质，该计算机可读介质能够用于存储与报告平台(714)有关的数据。在一些实施例中，可以通知发现模块(712)要发现的项。例如，如果存在拓扑的变化，则可以通知发现模块(712)存在对拓扑实施的变化并且通知发现模块(712)以发现拓扑。在一些实施例中，还能够通知系统(700)要发现的项，并且然后随后通知发现模块(712)要发现什么项。

在一些实施例中，系统(700)通过将拓扑设计、拓扑模型、以及拓扑模板从实现拓扑实例分离出来而实现。系统(700)能够管理实现的实例，其中，不具有针对该实现的实例的模型和/或设计。另外，系统(700)能够允许从外部系统输入、发现、和/或修改实现拓扑并且保持对实现拓扑的跟踪以用于管理实现拓扑。

图8是根据本公开的包括在图7中图示出的组件、平台、和模块的系统(800)的示例。系统(800)包括如本文所描述的云系统的示例性架构。图8对于用于发现不由管理代理(300)规定的拓扑的示例性方法是有用的。能够以与系统(700)类似的方式利用系统(800)。

如图8中所示的，系统(800)能够包括发现部分(810)。发现部分(810)能够包括在图7中引用的发现模块(712)。发现部分(810)能够包括被利用以发现实现拓扑和/或推断出的实现拓扑的系统(800)的部分。

系统(800)包括第二天操作部分(820)。通过这种组件的子集来实现第二天操作部分(820)。如本文所描述的，第二天操作能够包括硬件、软件、和/或逻辑的开发之后的云系统的操作。例如，第二天操作能够包括使用其他管理工具规定或发现由另一个进行规定以便由在图3中引用的管理代理(300)来管理的拓扑，和/或管理云系统。在一些实施例中，如在本文所描述的，系统(800)能够包括进行规定然后第二天操作、报告的多个不同部分，包括但不限于：建模部分、设计部分。因此，即使拓扑不是由系统(800)规定的，现在也能够由系统(800)执行第二天操作(例如，在系统的规定之后执行的第二天操作)。

系统(800)能够包括报告部分(830)。系统(800)的报告部分(830)能够包括系统(800)的元件，该元件被利用以报告错误和/或提供云系统分析信息。

图9是根据本公开的系统(900)的示例。系统(900)能够包括建模部分(940)。建模部分(940)能够包括系统(900)的部分，该系统(900)的部分包括与由系统(900)表示的云系统的建模相对应的系统(900)的元件。建模部分(940)能够包括服务资源库和/或实例资源库(708)、发现模块(712)、模型资源库(710)、和/或能够被利用以对云系统进行建模的云系统的其他元件。

系统(900)能够包括云管理部分(950)。云管理部分(950)能够包括系统(900)的元件，该元件能够被利用以服务、管理、规定、和/或代理结合图1-6描述的云系统。

图10是示出根据本公开的组件的示例性平台(1000)的框图。平台(1000)包括能够被利用以规定和管理云系统的多个组件。平台(1000)能够包括结合图1-6描述的云系统的拓扑(302)相关联的组件。

平台(1000)能够包括用于第一天操作和管理的云控制和管理系统。平台(1000)能够包括集成的或独立的开发和操作系统(1004)。开发和应用发布自动化系统(1004)能够促进在适当的基础结构上部署应用以用于阶段(例如，测试、试生产、生产)以及相关联的监视和补救。

在一些实施例中，能够将多个管理解决方案能视为平台(1000)上的应用。例如，典型地在数据中心中完成的诸如像csa的第一天操作和管理之类的应用或诸如第二天操作之类的应用现在能够在数据中心和云网络之间被移动和共用。

平台(1000)可以包括集成的或单独的兼容性和第二天操作系统(1006)。即，第二天应用能够与应用(1002)或操作系统(1004)集成以提供还管理没有由应用(1002)或操作系统(1004)生成的实例的能力，或者其能够在相同的平台上构建而在独立的模式中使用。如本文所描述的，应用或系统的兼容性能够集成到多个策略(303)中。另外，第二天操作可以是硬件和/或软件应用的开发之后的操作。

所述平台(1000)能够包括集成的或独立的报告系统(1008)。报告系统(1008)能够报告在云系统中发生的错误。在一些实施例中，报告系统(1008)能够生成包括关于云系统的操作和功能的信息的报告。

平台(1000)能够包括集成的或独立的监视系统(910)。能够利用监视系统(1010)来监视云系统的部署的服务的性能和状态。如本文所描述的，可能已经由应用1002或者由不同的系统规定和管理或者补救了所部署的服务。如本文所描述的，能够利用监视系统(1010)来监视云系统的各种关系。

平台(1000)能够包括核心平台(1012)，该核心平台(1012)能够包括用于经由诸如结合图1-6描述的云系统来提供服务的多个特征。核心平台(1012)能够包括用户接口(1014)。能够利用用户接口(1014)来显示来自报告系统(1008)的报告和/或对平台(1000)作出变化。核心平台(1012)能够包括目录(1016)。该目录(1016)能够包括计算机可读介质，该计算机可读介质能够存储个体设计、规定、部署、和管理适当地由在云环境中部署、执行、和管理的多个服务、应用、平台、或基础结构功能组成的此类云服务。如本文所描述的，然后可以将这些设计提供给可能从目录(1016)对它们进行订购、请求、和订阅的用户。

核心平台(1012)能够包括策略服务(1018)，该测量服务(1018)能够管理、处理、并且存储/绑定多个策略(303)。多个策略(303)能够包括阶段和版本策略、提供商选择策略、安全性策略、访问控制策略、监视策略、事件处理策略、通知策略、和补救策略、和/或兼容性策略等能够被管理、处理、和/或存储/绑定的各种其他策略。核心平台(1012)能够包括实施引擎服务(1020)。实施引擎(1020)能够包括多个方法来实施请求、规定、和/或更新云系统的请求，同时也遵循其应用的策略的指引。

核心平台(1012)能够包括通知服务(1022)。通知服务(1022)能够包括事件处理器并且能够处理事件(例如，利用对应的策略处理事件)以提取事故并且根据策略发送事故以通知用户。在一些实施例中，通知服务(1022)能够利用补救推荐进行通知。在一些实施例中，通知服务(1022)能够利用补救菜单来来进行通知以进行补救。在一些实施例中，通知服务(1022)能够发送作出接受或不同于补救推荐而进行补救的通知。此外，在一些实施例中，通知服务(1022)能够通知用户补救已经发生。通知服务(1022)能够包括计算机可读介质以存储由报告系统(1008)生成的诸如在图1-6中描述的通知和/或报告。通知数据库(1022)是实现拓扑(314)和/或推断出的实现拓扑的逻辑系统资源库，并且可以是任何形式的数据资源库。

核心平台(1012)能够包括拓扑模型(1024)。拓扑模型(1024)能够包括多个拓扑(302)的模型表示。能够利用拓扑模型(1024)来规定和/或管理云系统。核心平台(1012)能够包括模型资源库(1026)。在一些实施例中，模型资源库(1026)能够是模型和实例资源库以存储系统模型、拓扑(302)、和/或实例。模型资源库(1026)能够包括能够被利用以存储多个系统模型和/或拓扑(302)的计算机可读介质。

核心平台(1012)能够包括内容资源库(1028)。在一些实施例中，能够利用内容资源库(1028)来设计拓扑服务和/或策略。此外，能够利用内容资源库(1028)来实施资源提供商或lcma。内容资源库(1028)能够包括能够被利用以存储来自云系统的内容的计算机可读介质。核心平台(1012)能够包括编排系统(1030)。能够利用编排系统(1030)来规定和/或管理由诸如结合图7-9描述的云系统提供的服务。

核心平台(1012)能够包括发现系统(1032)。能够利用发现系统(1032)来发现云系统的拓扑(302)。另外，能够利用发现系统(1032)来发现如在本文结合图7-9描述的实现拓扑和/或推断出的实现拓扑以及由外部系统执行的对的实例的变化。核心平台(1012)能够包括集成和执行环境(1034)。集成和执行环境(1034)能够包括执行平台，该执行平台能够被利用以执行云系统上的服务以及运行于平台(1000)中的/运行于平台(1000)上的应用和服务。

平台(1000)能够包括提供商部分(1040)。提供商部分能够包括如本文所描述的资源提供商策略(308-1)，该资源提供商策略(308-1)是与指引多个资源的选择的多个资源提供商的供应相关联的任何策略。提供商部分(1040)能够包括资源(1042)提供商、管理(1044)提供商、变化控制(1046)提供商、监视(1048)提供商、安全(1050)提供商、以及其他提供商。资源(1042)能够包括能够经由云系统提供服务的网络资源。能够利用管理(1044)来管理在云系统上的服务的规定。能够通过在图3中的第三方提供来执行管理(1044)。能够利用变更控制(1046)来用于对云系统的手动变更和/或对拓扑(302)的手动变更。监视(1048)能够包括网络监视器以监视资源在云系统上的规定和部署。安全(1050)能够包括能够用于防止各种安全风险的独立或第三方网络安全性元件。

如本文所描述的系统和方法使对被不同地规定和/或管理的云服务的管理成为可能。例如，如本文所描述的系统和方法能够为没有第一天操作的情况下的第二天操作提供实例化、规定、和/或云系统管理。即，本文所描述的系统和方法在应用由管理器开发的并且拓扑是如本文所描述的那样被发现的推断出的拓扑和/或推断出的实现拓扑时提供实例化、规定、和/或云系统管理。另外，本文所描述的系统和方法在应用不是由管理器开发的并且拓扑是如本文所描述的那样被发现的推断出的拓扑和/或推断出的实现拓扑时提供实例化、规定、和/或云系统管理。此外，本文所描述的系统和方法在应用不是由管理器开发的、但是云服务由如在本文引用的不同的管理代理(300)管理时提供实例化、规定、和/或云系统管理。

如本文所使用的，“逻辑”是执行在本文描述的特定动作和/或功能等等的替换或额外的处理资源，其包括与存储在存储器中并且可由处理器执行的计算机可执行指令(例如，软件、固件，等等)不同的硬件(例如，各种形式的晶体管逻辑、专用集成电路(asic)，等等)。另外，如本文所使用的，“一”或“多个”之类的术语能够指的是一个或多个此类项。例如，“多个小组件”能够指的是一个或多个小组件。

说明书、示例、和数据提供对本公开的方法以及系统和方法的应用和使用的描述。因为能够在不背离本公开的系统和方法的精神和范围的情况下作出多个示例，本说明书仅仅阐述多个可能的实施例配置以及实施方式中的一些。