CN107005421A - 利用阶段和版本策略的基于拓扑的管理 - Google Patents

利用阶段和版本策略的基于拓扑的管理 Download PDF

Info

Publication number
CN107005421A
CN107005421A CN201480083719.4A CN201480083719A CN107005421A CN 107005421 A CN107005421 A CN 107005421A CN 201480083719 A CN201480083719 A CN 201480083719A CN 107005421 A CN107005421 A CN 107005421A
Authority
CN
China
Prior art keywords
topology
stage
application
version
topological
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201480083719.4A
Other languages
English (en)
Other versions
CN107005421B (zh
Inventor
斯蒂芬·H·麦斯
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Antite Software Co., Ltd.
Original Assignee
Hewlett Packard Enterprise Development LP
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hewlett Packard Enterprise Development LP filed Critical Hewlett Packard Enterprise Development LP
Publication of CN107005421A publication Critical patent/CN107005421A/zh
Application granted granted Critical
Publication of CN107005421B publication Critical patent/CN107005421B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12—Discovery or management of network topologies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1416—Event detection, e.g. attack signature detection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0893—Assignment of logical groups to network elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5041—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5041—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
    • H04L41/5048—Automatic or semi-automatic definitions, e.g. definition templates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0894—Policy-based network configuration management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12—Discovery or management of network topologies
    • H04L41/122—Discovery or management of network topologies of virtualised topologies, e.g. software-defined networks [SDN] or network function virtualisation [NFV]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/508—Network service management, e.g. ensuring proper service fulfilment according to agreements based on type of value added network service under agreement
    • H04L41/5096—Network service management, e.g. ensuring proper service fulfilment according to agreements based on type of value added network service under agreement wherein the managed service relates to distributed or central networked applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Stored Programmes (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

在一种实施方式中，用于利用阶段和版本策略的基于拓扑的管理的方法能够包括：将开发中的应用的拓扑关联，确定多个策略，其中，该多个策略包括阶段和版本策略，该阶段和版本策略针对应用的给定阶段和版本定义多个可用基础结构，将多个策略与拓扑的多个节点相关联，并且利用关联的多个策略来规定拓扑。

Description

利用阶段和版本策略的基于拓扑的管理
背景技术
越来越多数量的商业实体和个体转向通过云计算系统提供的云计算和云服务，以便例如出售商品或服务、维护商业记录、和为个体提供对计算资源的访问、以及其他与云有关的目标。云计算为云消费者提供可扩展并且集中的计算、存储、和网络容量以作为服务或以以上这些为基础的此类服务的组合。可以由(或者针对)创建云计算系统的实体对云进行设计、规定、部署、和维持。设计、规定、部署、和维持云计算系统可能是艰难的任务。
附图说明
图1是根据本公开的蓝图的框图。
图2是根据本公开示出架构导出的拓扑的框图。
图3根据本公开描绘示出用于设计、规定、部署、监视、和管理云服务的基于拓扑的管理代理的功能性概览的框图。
图4根据本公开描绘示出用于设计、规定、部署、监视，和管理云服务的基于拓扑的管理代理的功能性概览的框图。
图5描绘了示出用于基于拓扑的管理代理的公共平台的框图。
图6是根据本公开示出设计拓扑的方法的流程图。
图7是根据本公开的系统的示例。
图8是根据本公开的系统的示例。
图9是根据本公开的系统的示例。
图10是根据本公开示出构成与拓扑节点相关联的组件的拓扑的组件的示例平台的框图。
具体实施方式
在先前的云计算环境中，阶段和版本策略可能是云计算平台的独立的产品和/或部分。另外，先前的云计算环境能够包括不基于云计算环境的拓扑的阶段和版本策略。在本公开的一些实施例中，系统和方法能够包括基于云计算环境的拓扑并且被映射至拓扑和/或拓扑实例的阶段和版本策略。本公开的实施例相比先前的系统和方法的优点在于：在没有第一天操作的情况下为第二天操作提供支持、为CSA提供支持、和/或提供兼容遗留系统的阶段和版本策略。
云计算为用户的数据、软件、和计算提供服务。可以手动地部署在云服务内的资源上部署的应用。这种手动部署消耗相当多的管理时间。部署应用的手动步骤可以包括基础结构的规定和实例化。这可以包括在有或者没有对所部署的基础结构的充分了解的情况下连结诸如中间软件与DB+应用或图像的部署之类的应用或平台的安装。手动部署可以另外包括由尝试部署应用的用户所启动的多个步骤的序列。因此，将应用手动连结至所部署的基础结构消耗大量的计算和人员资源，并且可能导致应用和底层基础结构之间的错误和不可调和的问题。可以利用多个工具、脚本、和可执行体以利用对这些过程的执行序列进行自动化的编排器来自动地将应用连结到所部署的基础结构的。用于设计、规定、部署、和维持在云服务内的资源上部署的应用的多个设备可以包括数据中心、私有云、公共云、管理云、混合云、及其组合。
更具体地，可以使用云服务管理器来设计、规定、部署、和管理通过网络提供给用户的云服务。云服务提供商或其它实体或个体设计、规定、部署、和管理云服务，该云服务由在云环境中部署、执行、和管理的多个服务、应用、平台、或基础结构功能适当地组成。这些设计然后可以经由市场或经由API调用而提供给可能从目录对它们进行订购、请求、和订阅的用户，并且然后通过相同的机制来管理基于设计部署的云服务的使用循环。利用“蓝图”来表示以下更详细地描述的由惠普公司设计和发布的诸如云服务自动化(CLOUD SERVICEAUTOMATION)(CSA 3.2)之类的云服务管理器中的服务设计。
蓝图在工作流程集合方面来描述服务，执行该工作流程集合以用于规定或管理构成服务的所有组件以便执行特定的使用循环管理动作。通过蓝图定义的工作流程的一些功能是随着对资源提供商的调用然后被执行的实际的使用循环管理动作。资源提供商将调用转换为被指定为由资源提供商提供的特定资源或实例的被妥善格式化和交换的指令。
图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是在拓扑设计器内使用的系统工具，该系统工具在对版本、配置、和其它应用组件进行管理时独立地对基础结构和应用需求进行建模。惠普公司还开发并且发布了CDA 1.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)与多个节点、多个节点组、拓扑的一部分、整个拓扑、或者其组合相关联。
因此，本系统和方法描述了使用相同的使用循环管理引擎支持拓扑和蓝图两者的云服务代理或管理器。使用循环管理引擎支持云服务的使用循环管理以及应用模型与基础结构模板的映射。本系统和方法还描述了用于管理云服务内的规定、部署、监视、和补救处理的基于策略的框架。另外，如以下将更详细地描述的，本系统和方法为由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)的规定期间可以是自配置的。
在另一个示例中，可以通过使用多个拼接方法将多个应用模型(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)有助于设计云服务拓扑的各种方面。在一个示例中，经由使用硬件设备和诸如图形用户界面(GUI)与编码脚本之类的软件模块的设计工具来执行拓扑设计。人类设计者使用设计工具(301)来设计拓扑。因此，通过自主方法和人类提供设计的方法的组合来实现拓扑(302)的设计。在一个示例中，拓扑设计器(301)可以是利用API的接口，其使得能够进行应用模型(图4，319)与它的相关联的组件的分立创建，并且指定基础结构和用于基础结构的使用循环条件的基础结构模板的创建。
全部基于拓扑的管理代理(200)的在图3中描绘的子系统包括能够规定、部署、监视、强制执行云服务内的策略的子系统，以及补救云服务内的事故的子系统。不管拓扑是蓝图还是架构导出的，都使用利用LCMA和策略的拓扑来执行这些任务。因此，本系统和相关联的方法还支持CSA3.2支持的所有使用案例。如上所述，CSA 3.2是用于部署和管理云计算应用的自动化系统工具，并且由惠普公司开发和发布。CSA 3.2技术能够支持蓝图或架构拓扑。另外，在通过引用全部包含于此的梅斯的名称为“管理混合云服务(Managing a HybridCloud Service)”的国际专利申请公开号PCT/US2012/045429中描述了CSA。如以下将更详细地描述的，图3中描绘的子系统使用多个类型的策略和使用循环管理动作(LCMA)来规定、部署、监视、强制执行所部署的云服务内的策略，并且补救所部署的云服务内的事故。
另外，全部基于拓扑的管理代理(200)的在图4中描绘的子系统包括能够与在图3中描绘的子系统一样在相同的堆栈上独立地对拓扑的基础结构和应用需求进行建模的子系统。本系统和相关联的方法还支持诸如那些使用CDA 1.2的情况之类的CDA子系统支持的所有使用案例。如上所述，CDA是在拓扑设计器内使用的自动化系统工具，其在对版本、配置、和其它应用组件进行管理时独立地对基础结构和应用需求进行建模。CDA 1.2也是由惠普公司开发并且发布的。另外，在通过引用全部包含于此的梅斯的称为“云应用部署(CloudApplication Deployment)”的国际专利申请公开号PCT/US2012/041625中描述了CDA。
以这样的方式，图3和图4的子系统作为常规地使用拓扑、实现的拓扑、和策略来的单个计算系统在共用堆栈下工作并且在基于拓扑的管理代理(200)内一起工作，以支持构建拓扑并且支持多个提供商的相关联的技术的所有使用案例。因此，在一个示例中，本系统和方法通过在相同的堆栈上利用云服务的设计的拓扑(优选地架构导出的)、多个策略、与拓扑节点/子集/全部相关联的多个LCMA来协调分别由CDA和CSA使用的不同模型、模板、和蓝图。
如在图3中所描绘的，拓扑设计器(301)可以设计并且向基于拓扑的管理代理(200)呈现使用循环管理(LCM)拓扑(302)。在一个示例中，本文所描述的拓扑设计器(301)可以是基于拓扑的管理代理(200)的集成的部分。在另一个示例中，拓扑设计器(301)可以与基于拓扑的管理代理(200)分离。在另一个示例中，多个人可以使用拓扑设计器(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)中以便实现任何数据处理目标。在一个示例中，基于拓扑的管理代理(200)可以将拓扑(302)表示为可扩展标记语言(XML)文件。在另一个示例中，基于拓扑的管理代理(200)可以：以JavaScript对象标记(JSON)格式来表示拓扑(302)；以为从用于表示对象的JavaScript脚本语言导出的人类可读取的数据交换而设计的基于文本的开放标准来表示拓扑(302)。在又一个示例中，基于拓扑的管理代理(200)可以：以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)的关联。在一些实施例中，策略303能够被关联到节点(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)能够被指配给对应的节点(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)能够包括例如与应用和/或拓扑相关联的应用的阶段和版本。在至少一个示例中，如在本文所使用的术语“阶段”旨在表示应用的开发和/或部署的测试、试生产、以及生产阶段。在一些实施例中，拓扑(302)可以是实现的拓扑。实现的拓扑可以是由也利用拓扑(302)的实体所生成的拓扑(302)。
策略(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)能够包括应用的阶段和版本。
如本文所进一步描述的，能够利用通知策略来对拓扑和/或系统的管理器和/或开发者进行通知。在一些实施例中，如以下更详细地所描述的，能够基于事故类型将通知指定为发送给特定用户和/或系统。
另外，在一个示例中，将策略(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)的部分、或者其组合相关联。在一个示例中，经由拓扑设计器(301)来执行策略和LCMA与拓扑的方面的关联。
在一个示例中，尽管未描绘，构成组的节点的子集还可以与多个策略(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)是多个描述、元数据、工作流程、脚本、规则、或规则集合，这些可适用于指引在拓扑(302)将被或已经被实施的云服务环境内的与多个节点(302-1、302-2、302-3、302-4、302-5、302-6、302-7)的使用循环管理相关联的规定任务、监视任务、强制执行任务、支配任务、以及补救任务。策略(303)定义基于拓扑的管理代理(200)的API的访问控制和使用控制。另外，策略(303)定义用于管理或使用实体化的服务的API的访问控制和使用控制。例如，当由监视系统(313)检测到安全威胁时，补救选项可以包括对多个访问控制策略作出变化。
策略(303)可以与多个独立节点、多个节点组、一类节点的多个节点、云服务的整个拓扑内的节点的子集相关联，并且对于其可操作；可以与作为整体的云服务的整个拓扑相关联，并且对于其可操作，或者与其组合相关联，并且相对于其可操作。如果在独立节点、节点组、或作为整体的云服务的整个拓扑上启动策略(303)，则策略将相对于独立节点、节点组、一类节点的节点、云服务的整个拓扑内的节点的子集来指引使用循环管理动作的发生，或者在独立节点、节点组、一类节点的节点、云服务的整个拓扑内的节点的子集上执行使用循环管理动作。
策略类型的一个示例是规定策略，该规定测量包括在拓扑内的应用和/或节点的阶段和版本。如果被实施，则规定策略可以定义包括(当拓扑被规定的、部署、和执行时与拓扑相关联的)云的应用的测试、试生产、和/或生产的特性。此规定能够包括拓扑(302)的基础结构和平台。规定策略可以包括诸如像节点的物理位置之类的特性的定义。规定策略还可以包括诸如像地理位置或部署类型位置(诸如在有或没有对因特网的访问的情况下或者是否在防火墙后的网络区)之类的特性的定义，以及其他地理或部署类型规定策略的定义。在此示例中，策略可以具有可以与服务器设备相关联的规定策略组件，其要求服务器设备位于国家的特定地理区域、诸如像与西海岸相对的美国的东海岸这样的特定区域、特定服务器设施、或者任何其他地理位置。
阶段和版本策略能够包括指定特定阶段和/或版本(例如，阶段和版本策略，等等)的定义和/或指引。例如，第一策略能够包括与应用的第一版本相对应的定义和/或指引，并且第二策略能够包括与应用的第二版本相对应的定义和/或指引。在此示例中，应用的第一版本能够是应用的早期版本，并且应用的第二版本能够是同一应用的稍晚开发的(例如，更高级的版本)。定义和/或指引能够包括诸如什么基础结构或位置可用于对应的阶段之类的信息。另外，定义和/或指引能够包括诸如什么拓扑层可用于对应的阶段之类的信息。例如，信息能够包括什么层满足应用的拓扑和/或哪些层能够被应用的对应的版本所利用。
在一些实施例中，能够以代码(例如，YAML、TOSCA YAMAL配置文件)来编写拓扑(302)的设计和/或阶段和版本策略(303)。这能够不同于先前的方法和系统，因为一些先前的方法和系统利用设计者来设计拓扑(302)和设计策略(303)。
在一些实施例中，与阶段化或版本化有关的信息(例如，阶段和版本策略内的信息，等等)能够被传递和/或能够指向基于拓扑(302)和策略(303)来规定和/或管理应用的请求。在一些实施例中，对规定和/或管理的请求能够来自开发工具链。例如，能够从应用的开发所涉及的不同的流(例如，IDE、包括eclipse插件的工具、在测试已经通过之后，等等)触发对规定和/或管理的请求。这些实施例相比先前的方法和系统能够是有利的，这是因为包括对规定和/或管理的请求的实施例能够是持续集成(CI)和/或持续交付(CD)链的一部分。
阶段和版本策略(303)还能够包括能够被利用以指向能够用于部署实例的人工制品的DSL和/或资源库的信息。在一些实施例中，能够使实现的拓扑的LCM可用于开发者以经由代码(例如，调入用于API的代码，等等)来管理实现的拓扑。在特定实施例中，能够利用阶段和版本策略(303)来确定如何执行其他策略(303)或管理计划。例如，能够作出在应用的不同阶段和/或版本监视应用的不同的方面的确定。例如，在应用的第一阶段，阶段和版本策略(303)能够包括对应用的全部操作和使用进行监视的信息。在此示例中，在应用的第二阶段，阶段和版本策略(303)能够包括停止监视应用的全部操作和使用的信息。
关于定义计算设备(例如，存储器、网络等)的物理位置的规定策略，其他特性例如可以包括位置的安全级别或对节点所在之处的对因特网的访问。其他规定策略还可以例如包括例如节点耦合到的网络的带宽中的速度、节点是否将被连接到因特网或者内联网(诸如像非军事区(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)提供什么。因此，在一个示例中，能力策略可以指示节点能够以特定速率处理数据。在另一个示例中，能力策略可以指示存储器设备可以具有太字节(TB)的数据存贮空间。
在又一个示例中，需求策略可以指示节点要求特定计算平台。当设计拓扑(302)时，元数据的拓扑或关联支持捕捉数据，该数据定义包括硬件架构与和软件框架(包括应用框架)的计算平台内的多个硬件设备。当元数据被呈现或被关联时，其用于指引规定策略，以便更好地选择计算平台内的合适的元素，诸如像适当的数据中心。当被呈现或被关联时，元数据还可以用于指引将拓扑的片段匹配到其他片段，如以下将结合把应用模型拼接到基础结构模板所更详细地讨论的。
关于能力策略，节点可以定义它们是哪种设备、它们能够进行或者执行执行软件的什么版本、以及它们能够完成什么。能力策略的示例可以包括与节点相关联的定义，该定义把节点定义为应用服务器、节点提供Java平台、企业版(J2EE)环境、节点运行特定操作系统、操作系统的版本，或者操作系统的版本的特定发布，以及多个其他能力。如上所述，这可以用于确定例如可以部署什么其他方面或者什么其他设备可以使用云服务。
可以被指配的另一类型的策略(303)包括监视策略。监视策略是如下策略，如果被实施，则定义节点(302-1、302-2、302-3、302-4、302-5、302-6、302-7)的操作监视、节点的安全监视、节点的阶段和版本监视、节点和节点的组之间的分析、节点的使用监视、性能监视、以及诸如像度量收集的智能监视、商业智能(BI)和业务活动监视(BAM)、以及分析/大数据集成等其他类型的与监视有关的策略。
监视策略还可以定义预期哪种监视以及如何实施监视。关于节点操作的监视策略的示例包括性能、监视网络内的各种节点的CPU级别和负载、监视通过节点或者多个节点处理数据或者在节点之间交换数据的速度、以及监视在任何级别的网络运行一个或多个节点上的应用的操作状态、等节点或节点的组以及作为整体的云服务的多个其他操作参数。
在另一个示例中，监视策略还定义如何处理出现在实例化的拓扑中的被监视的事件。在此示例中，监视策略协助事件处理器(316)接收和处理事件、并且做出关于由事件引起的事故的补救的决策、以及发送关于事故的通知消息。以下将更详细地描述基于拓扑的管理代理(200)内的事件处理。如以下将更详细地描述的，监视策略包括这样的部分：定义怎样处理由监视引起的被监视的事件，诸如像如何处理事件、将事件发送到哪里、什么设备或个体解决事件、如何处理由事件的处理引起的事故、如何对事件和事故进行处理(例如，以聚合的、过滤的、或者关联的事件的形式进行处理，以及其他形式的处理)、以及如何处理产生的事故。
监视策略还可以包括关于安全性的监视策略。安全性策略定义如何监视异常行为或被熟知为与已知的或可疑的安全性问题相关联的行为。关于安全性的监视策略的示例包括：监视节点或者监视节点组是否经历攻击、在云服务或与云服务的交互内是否有奇怪的行为发生、以及关于节点或节点组是否存在病毒或其他异常、以及其他与安全性有关的监视策略。
监视策略还可以包括关于使用的监视策略。关于使用的监视策略的示例包括：确定用户多大程度地使用了节点或节点组的CPU、确定用户多达程度地利用了存储器、确定对用户记了多少花费、以及用户是否已经支付通过网络拓扑的设计、规定、部署、以及监视所以提供的服务、以及其他与使用有关的监视策略。
策略(303)可以进一步包括支配策略，如果该支配策略被实施，则定义拓扑(302)或云服务内的节点(302-1、302-2、302-3、302-4、302-5、302-6、302-7)或者节点的组的访问控制。例如，支配策略可以包括这样的策略：定义谁可以访问拓扑(302)或云服务内的节点以及在什么条件下那些个体可以获得此类访问。
策略(303)可以进一步包括分析策略，如果该分析策略被实施，则定义需要什么来确保节点(302-1、302-2、302-3、302-4、302-5、302-6、302-7)或者拓扑(302)内的节点组内的或者当中的分析和大数据监视，并且确保这如预期那样出现。例如，分析策略可以定义多个工作流程，通过该多个工作流程监视系统(313)可以操作以配置云服务、提供分析、收集大数据、以及处理数据。
更进一步，策略(303)可以包括补救策略，该补救策略定义如果在拓扑(302)的部署和执行期间出现问题或者发生事故，在拓扑(302)内将进行什么动作。补救策略可以包括这样的策略：定义由基于拓扑的管理代理(200)在补救处理期间采取的多个动作，并且包括：(1)向用户、消费者、或管理员提供通知；(2)从用户、消费者、或管理员获得指令；(3)采取由用户、消费者、或管理员输入的手动动作；(4)在接收到来自用户、消费者、或管理员的指令之后采取自主动作；(5)在没有接收到来自从用户、消费者、或管理员接收指令的情况下采取自主动作；(6)在没有通知用户、消费者、或管理员或者没有从用户、消费者、或管理员接收指令的情况下采取自主动作；(7)向用户或管理员提出补救动作以求批准，并且如果被用户或管理员或者其组合批准则执行提出的补救动作。
作为示例，可能发生由拓扑(302)实例化或实现的云服务的故障，并且补救策略可以基于以上所述的潜在的方案来定义可以如何处理故障。另外，补救策略提供动作的实际的规则和工作流程以执行在任何数量的条件下补救事故或者指示把这些补救动作的决策制定和编排以及履行委派给谁或哪些设备。另一个补救示例可以基于例如基于拓扑(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)包括这样的动作：诸如像规定拓扑内的计算资源、更新拓扑、复制拓扑的所有或多个部分、修改拓扑内的计算资源、移动拓扑内的计算资源、破坏或删除拓扑内的资源的动作、以及其他使用循环管理动作。
在本文描述的各种策略定义在基于拓扑(302)的服务的实例化之前、期间、以及之后将通过拓扑(302)的使用循环执行什么动作。另外，在本文描述的各种策略定义将如何执行这些动作。更进一步，在本文描述的各种策略定义动作将被委派给哪些设备、个体、或者其组合。再进一步，在本文描述的各种策略定义上述的组合。例如，在事件处理和处理(handing and processing)或补救中使用的任何监视策略可以定义监视或补救什么设备或云服务的什么部分、如何执行此类监视和补救、把监视和补救的功用委派给谁或什么设备、或其组合。
图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)的设计、执行、监视和补救时的功用的其他人员。
在本文参考根据在本文描述的原理的示例的方法、装置(系统)、和计算机程序产品的流程图图示和/或框图来描述本发明的系统和方法的方面。可以通过计算机可用程序代码来实施流程图图示和框图中的每个框以及流程图图示和框图中的框的组合。可以向通用计算机、专用计算机，或其它可编程数据处理装置的处理器提供计算机可用程序代码以生产机器，使得当计算机可用程序代码经由例如包括基于拓扑的管理代理(200)或其它可编程数据处理装置的设备内的多个处理器执行时，实施在流程图和/或框图块中指定的功能或动作。在一个示例中，计算机可用程序代码可以在计算机可读存储介质内实现；计算机可读存储介质是计算机程序产品的一部分。在一个示例中，计算机可读存储介质是非暂时性计算机可读介质。
说明书和附图描述了对被建模为拓扑的云服务的使用循环进行管理的方法和系统。在处理器的情况下，这些系统和方法包括：生成拓扑，该拓扑表示云服务，将多个使用循环管理动作(LCMA)与拓扑内的多个节点以及使用循环管理引擎相关联，以及执行拓扑。
被建模为拓扑的云服务的使用循环的这种管理可以具有多个优点，包括：(1)在利用相同的技术并且支持多个提供商的相关联的技术时，提供公用堆栈以及拓扑、实现的拓扑、和策略的共同使用可以用于支持构造拓扑的云服务自动化(CSA)和持续交付自动化(CDA)平台和服务两者的所有使用案例；(2)提供计算环境，在该计算环境中CSA和CDA使用诸如像可扩展标记语言(XML)或JavaScript对象变化(JSON)之类的相同的拓扑表示；(3)通过重新使用现存的CSA内容、创建迁移资源提供商的路径、以及重新使用提供商来提供对用于CSA的内容的迁移进行管理的方法；(4)避免或减轻永久保存CSA CDA混淆、重复付出、以及危及未来的CSA机会的风险；(5)可以在不要求用户也理解如何执行此类操作的情况下，将复杂的应用自动地部署在所请求的基础结构上，(6)支持CM&S环境，以及(7)提供云环境内的自动计算、工缀荷管理、以及基于策略的自动补救和自补救、以及多个其他优点。
图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是基于HP CSA的)。在一些实施例中，CSA策略能够包括分享CMDB中的实现拓扑实例。在另一个示例中，像HP SA(服务器自动化)的系统能够使用所存储的信息来执行监视(例如，对操作、使用安全性的监视)、管理、和/或补救。在一些实施例中，能够并行地进行与系统(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)进行变化的选项还能够包括变化代码(即，不使用设计器)。在一些实施例中，当利用TOSCA YAML分布表示拓扑时，能够由YAML做出这些变化。
系统(700)能够包括目录(704)。在一些实施例中，目录(704)能够包括能够被利用以存储与云系统有关的信息的计算机可读介质。在一些实施例中，能够利用目录(704)来存储与云系统的部署的系统有关的信息。因此，可以不在最初通过系统(700)规定实现的拓扑，而是通过系统(700)之外的不同的系统在一些点更新和/或管理实现的拓扑。
系统(700)能够包括基于策略的履行、编排、和集成工具(706)。基于策略的履行、编排、和集成工具(706)能够包括多个策略(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)能够包括集成的或独立的报告系统(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)，等等)。另外，如本文所使用的，“一”或“多个”之类的术语能够指的是一个或多个此类项。例如，“多个小组件”能够指的是一个或多个小组件。
说明书、示例、和数据提供对本公开的方法以及系统和方法的应用和使用的描述。因为能够在不背离本公开的系统和方法的精神和范围的情况下作出多个示例，本说明书仅仅阐述多个可能的实施例配置以及实施方式中的一些。

Claims (15)

1.一种利用阶段和版本策略的基于拓扑的管理的方法，该方法包括：
将拓扑与开发中的应用相关联；
确定阶段和版本策略，以针对所述应用的多个阶段和版本中的每一个定义可用基础结构；
在所述开发中的应用的试生产和生产期间，将所述阶段和版本策略与所述拓扑的多个节点关联；并且
利用关联的所述阶段和版本策略来规定所述拓扑并且然后管理所述拓扑。
2.根据权利要求1所述的方法，其中，将所述拓扑与所述阶段和版本策略相关联包括：以代码的方式定义所述拓扑并且将所述拓扑与所述阶段和版本策略相关联。
3.根据权利要求1所述的方法，包括：基于所述应用的变化属性将所述应用从第一阶段和版本策略演变到第二阶段和版本状态，以用于阶段化和版本化策略的评估。
4.根据权利要求1所述的方法，包括：基于所述应用的开发阶段经由API来触发所述阶段和版本状态，以用于所述阶段化和版本化策略的评估。
5.根据权利要求1所述的方法，其中，所述阶段和版本策略包括：
针对所述应用的所述拓扑中所包含的多个层，指示在每个阶段所述多个层需要什么的信息；以及
指引多个层中的哪些层必须用于或不必用于应用的对应阶段、版本、或能力的信息。
6.根据权利要求1所述的方法，其中，以YAML来编写所述拓扑以及所述阶段和版本策略，其中所述阶段和版本策略绑定到所述拓扑。
7.根据权利要求1所述的方法，其中，规定所述拓扑包括：在所述应用的所述开发、测试、试生产、和生产中封装应用人工制品、所述拓扑、以及所述阶段和版本策略以从IDE触发规定，其中，能够通过值或者通过在包括数据的文件内的引用来提供所封装的应用人工制品、拓扑、以及阶段和版本策略中的任何项。
8.根据权利要求1所述的方法，包括：经由开发工具链请求在特定阶段对所述应用进行规定并管理，以在试生产和生产的不同步骤期间测试所述应用。
9.根据权利要求1所述的方法，包括：基于与所述应用的阶段和版本相关联的阶段和版本策略对所述拓扑进行实例化。
10.一种用于促进利用阶段和版本策略的基于拓扑的管理的系统，所述系统包括：
用于开发、测试、阶段化、执行、并且支持云服务管理的平台，所述平台包括多个引擎，以：
将开发中的应用的拓扑关联；
确定多个策略，其中所述多个策略包括阶段和版本策略，所述阶段和版本策略针对所述应用的给定阶段和版本定义多个可用基础结构或底层；
将所述多个策略与所述拓扑的多个节点相关联；并且
利用关联的所述多个策略来规定所述拓扑。
11.根据权利要求10所述的系统，其中，所述阶段和版本策略为应用开发的每个对应的阶段和版本指引规定和管理。
12.根据权利要求10所述的系统，其中，所述拓扑包括由所述平台管理的云服务。
13.根据权利要求10所述的系统，包括拓扑使用循环管理(LCM)引擎，用于执行管理过程以基于所述多个策略对服务进行实例化。
14.根据权利要求10所述的系统，其中，所述平台包括代理，所述代理包括在所述代理上构建的多个应用，所述代理被配置为基于所述多个策略来管理所规定的应用。
15.一种用于促进利用阶段和版本策略的基于拓扑的管理的计算机程序产品，所述计算机程序产品包括：
包括计算机可用程序代码的计算机可读存储介质，所述计算机可用程序代码利用所述计算机可读存储介质来实现，所述计算机可用程序代码包括：
在由处理器执行时将开发中的应用的拓扑关联的计算机可用程序代码；
在由处理器执行时确定多个策略的计算机可用程序代码，其中，所述多个策略包括阶段和版本策略，所述阶段和版本策略针对所述应用的给定阶段和版本定义多个可用基础结构；
在由处理器执行时将所述多个策略与所述拓扑的多个节点关联的计算机可用程序代码；并且
在由处理器执行时利用关联的所述多个策略规定所述拓扑的计算机可用程序代码。
CN201480083719.4A 2014-09-30 2014-09-30 利用阶段和版本策略的基于拓扑的管理方法、系统和介质 Active CN107005421B (zh)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2014/058330 WO2016053301A1 (en) 2014-09-30 2014-09-30 Topology based management with stage and version policies

Publications (2)

Publication Number Publication Date
CN107005421A true CN107005421A (zh) 2017-08-01
CN107005421B CN107005421B (zh) 2021-06-01

Family

ID=55631157

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201480083719.4A Active CN107005421B (zh) 2014-09-30 2014-09-30 利用阶段和版本策略的基于拓扑的管理方法、系统和介质

Country Status (5)

Country Link
US (1) US11228497B2 (zh)
EP (1) EP3202084A4 (zh)
JP (1) JP2017536608A (zh)
CN (1) CN107005421B (zh)
WO (1) WO2016053301A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108388445A (zh) * 2018-03-09 2018-08-10 北京四方继保自动化股份有限公司 一种基于“平台+应用”模式的持续集成方法
CN110262995A (zh) * 2019-07-15 2019-09-20 北京一流科技有限公司 执行体创建系统和执行体创建方法

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3063661B1 (en) 2013-10-30 2020-05-06 Hewlett-Packard Enterprise Development LP Topology remediation
WO2015065389A1 (en) 2013-10-30 2015-05-07 Hewlett-Packard Development Company, L.P. Execution of a topology
WO2015065374A1 (en) 2013-10-30 2015-05-07 Hewlett-Packard Development Company, L.P. Management of the lifecycle of a cloud service modeled as a topology
EP3063657B1 (en) 2013-10-30 2021-12-01 Hewlett Packard Enterprise Development LP Monitoring a cloud service modeled as a topology
EP3063668A4 (en) * 2013-10-30 2017-05-31 Hewlett-Packard Enterprise Development LP Managing the lifecycle of a cloud service modeled as topology decorated by a number of policies
EP3063663A4 (en) 2013-10-30 2017-04-19 Hewlett-Packard Enterprise Development LP Stitching an application model to an infrastructure template
US10862747B2 (en) * 2015-03-25 2020-12-08 Airwatch Llc Single user device staging
US10108411B2 (en) 2015-10-08 2018-10-23 Lightbend, Inc. Systems and methods of constructing a network topology
GB2552025B (en) 2016-07-08 2020-08-12 Sovex Ltd Boom conveyor
US10476948B2 (en) * 2016-09-21 2019-11-12 Microsoft Technology Licensing, Llc Service location management in computing systems
US10855757B2 (en) * 2018-12-19 2020-12-01 At&T Intellectual Property I, L.P. High availability and high utilization cloud data center architecture for supporting telecommunications services
US20200218566A1 (en) * 2019-01-07 2020-07-09 Entit Software Llc Workload migration
KR102464740B1 (ko) * 2019-02-28 2022-11-08 한국정보통신기술협회 빅데이터 분석용 dbms를 위한 테스트 자동화 프레임워크 및 테스트 자동화 방법
US11025489B2 (en) 2019-05-23 2021-06-01 Cisco Technology, Inc. Automated discovery of manual configuration changes
AU2020437843A1 (en) * 2020-03-27 2022-10-20 Nippon Telegraph And Telephone Corporation Resource management device, resource management method and resource management program
WO2021192268A1 (ja) * 2020-03-27 2021-09-30 日本電信電話株式会社 リソース管理装置、リソース管理方法、および、リソース管理プログラム
US20230123212A1 (en) * 2020-03-27 2023-04-20 Nippon Telegraph And Telephone Corporation Resource management device, resource managementmethod, and resource management program
CN113849364B (zh) * 2021-07-29 2023-12-26 浪潮软件科技有限公司 一种边缘应用管理方法、装置、设备及可读存储介质

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101521608A (zh) * 2009-01-22 2009-09-02 厦门东南融通系统工程有限公司 一种测试用例的版本管理方法
CN101635640A (zh) * 2009-09-04 2010-01-27 江苏天智互联科技有限公司 Web网站系统服务器终端程序的版本自动发布方法
US20110265164A1 (en) * 2010-04-26 2011-10-27 Vmware, Inc. Cloud platform architecture
US20130219361A1 (en) * 2012-02-18 2013-08-22 Software Ag System and method for controlling the development of a software application
CN103279365A (zh) * 2012-01-13 2013-09-04 西门子公司 部署、合并发行独立应用程序的方法、计算机可读媒体和系统
WO2013184140A1 (en) * 2012-06-08 2013-12-12 Hewlett-Packard Development Company, L.P. Version management for applications
US20140067779A1 (en) * 2012-09-06 2014-03-06 Advanced Micro Devices, Inc. Predictive information topology modeling and visualization
EP2760160A1 (en) * 2013-01-25 2014-07-30 Alcatel Lucent Provision of adapted information on a topology of a communication network

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6574663B1 (en) * 1999-08-31 2003-06-03 Intel Corporation Active topology discovery in active networks
US7228326B2 (en) 2002-01-18 2007-06-05 Bea Systems, Inc. Systems and methods for application deployment
US8271974B2 (en) * 2008-10-08 2012-09-18 Kaavo Inc. Cloud computing lifecycle management for N-tier applications
US20100095266A1 (en) * 2008-10-10 2010-04-15 Hewlett-Packard Development Company L.P. system and method for a policy-based management of a software service component
US8595715B2 (en) 2010-12-31 2013-11-26 International Business Machines Corporation Dynamic software version selection
EP2482148B1 (de) 2011-01-26 2018-06-13 Siemens Aktiengesellschaft Verfahren für die Projektierung und/oder Programmierung einer multifunktionalen Komponente einer industriellen Automatisierungsanordnung
US10678602B2 (en) 2011-02-09 2020-06-09 Cisco Technology, Inc. Apparatus, systems and methods for dynamic adaptive metrics based application deployment on distributed infrastructures
US9384058B2 (en) * 2011-03-02 2016-07-05 Radware, Ltd. Method for executing virtual application delivery controllers having different application versions over a computing device
US9645628B1 (en) * 2011-05-09 2017-05-09 EMC IP Holding Company LLC Combined data storage and computing appliance that provides scalable storage in a clustered computing environment
US9251033B2 (en) * 2011-07-07 2016-02-02 Vce Company, Llc Automatic monitoring and just-in-time resource provisioning system
CN103891201B (zh) 2011-09-19 2018-03-30 塔塔咨询服务有限公司 用于基于传感器数据的应用和服务的开发以及部署的计算平台
US9519520B2 (en) * 2011-10-25 2016-12-13 Viasat, Inc. Federated, policy-driven service meshes for distributed software systems
US9225604B2 (en) * 2012-04-05 2015-12-29 International Business Machines Corporation Mapping requirements to a system topology in a networked computing environment
US8874704B2 (en) 2012-07-11 2014-10-28 Bmc Software, Inc. Semi-automatic discovery and generation of useful service blueprints
CN105190557B (zh) 2012-10-16 2018-09-14 思杰系统有限公司 用于通过多级api集成在公共与私有云之间进行桥接的系统和方法
US9383984B2 (en) * 2014-01-13 2016-07-05 International Business Machines Corporation Seal-based regulation for software deployment management

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101521608A (zh) * 2009-01-22 2009-09-02 厦门东南融通系统工程有限公司 一种测试用例的版本管理方法
CN101635640A (zh) * 2009-09-04 2010-01-27 江苏天智互联科技有限公司 Web网站系统服务器终端程序的版本自动发布方法
US20110265164A1 (en) * 2010-04-26 2011-10-27 Vmware, Inc. Cloud platform architecture
CN103279365A (zh) * 2012-01-13 2013-09-04 西门子公司 部署、合并发行独立应用程序的方法、计算机可读媒体和系统
US20130219361A1 (en) * 2012-02-18 2013-08-22 Software Ag System and method for controlling the development of a software application
WO2013184140A1 (en) * 2012-06-08 2013-12-12 Hewlett-Packard Development Company, L.P. Version management for applications
US20140067779A1 (en) * 2012-09-06 2014-03-06 Advanced Micro Devices, Inc. Predictive information topology modeling and visualization
EP2760160A1 (en) * 2013-01-25 2014-07-30 Alcatel Lucent Provision of adapted information on a topology of a communication network

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108388445A (zh) * 2018-03-09 2018-08-10 北京四方继保自动化股份有限公司 一种基于“平台+应用”模式的持续集成方法
CN108388445B (zh) * 2018-03-09 2021-06-08 北京四方继保自动化股份有限公司 一种基于“平台+应用”模式的持续集成方法
CN110262995A (zh) * 2019-07-15 2019-09-20 北京一流科技有限公司 执行体创建系统和执行体创建方法

Also Published As

Publication number Publication date
US11228497B2 (en) 2022-01-18
JP2017536608A (ja) 2017-12-07
EP3202084A1 (en) 2017-08-09
US20170302532A1 (en) 2017-10-19
CN107005421B (zh) 2021-06-01
WO2016053301A1 (en) 2016-04-07
EP3202084A4 (en) 2018-06-13

Similar Documents

Publication Publication Date Title
CN107005421A (zh) 利用阶段和版本策略的基于拓扑的管理
CN107005422A (zh) 第二天操作的基于拓扑的管理
US20210392056A1 (en) Systems and methods for domain-driven design and execution of metamodels
US20190028356A1 (en) Management of the lifecycle of a cloud service modeled as a topology
CN106464736B (zh) 用于基于云的服务交换的实时配置和管理的互连平台
US10284427B2 (en) Managing the lifecycle of a cloud service modeled as topology decorated by a number of policies
US10447538B2 (en) Facilitating autonomous computing within a cloud service
US10620927B2 (en) Method, arrangement, computer program product and data processing program for deploying a software service
US20210150411A1 (en) Secure artificial intelligence model training and registration system
AU2019232804A1 (en) Decision tables and flow engine for building automated flows within a cloud based development platform
CN109240900A (zh) 区块链网络服务平台及其智能合约检测方法、存储介质
US20170302531A1 (en) Topology based management with compliance policies
CN108989389A (zh) 一种建立智能合约微服务化的方法
US20160254965A1 (en) Stitching an application model to an infrastructure template
WO2015065368A1 (en) Realized topology system management database
EP3063666A1 (en) Management of the lifecycle of a cloud service modeled as a topology
CN105897805A (zh) 对多层架构的数据中心的资源进行跨层调度的方法和装置
CN104169939B (zh) 一种实现虚拟化安全的方法和系统
US11907708B2 (en) Application and infrastructure template management to easily create secure applications for enterprises
Rios et al. SLA-based continuous security assurance in multi-cloud DevOps
de Aguiar Monteiro et al. A Survey on Microservice Security–Trends in Architecture Privacy and Standardization on Cloud Computing Environments
Tretola et al. Reactive behavioural adaptation of service compositions
US20230342694A1 (en) System and method for providing resilient enterprise operation and management
Alfred Quantifying Change Risk in Cloud Computing Environments
Taheri et al. Edge Intelligence

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
TA01 Transfer of patent application right
TA01 Transfer of patent application right

Effective date of registration: 20180613

Address after: American California

Applicant after: Antite Software Co., Ltd.

Address before: American Texas

Applicant before: HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP

CB02 Change of applicant information
CB02 Change of applicant information

Address after: Utah, USA

Applicant after: Weifosi Co., Ltd

Address before: California, USA

Applicant before: Antiy Software Co.,Ltd.

GR01 Patent grant
GR01 Patent grant