CN104813614A - 用于iaas的管理的异步框架 - Google Patents

Abstract

一种系统，包括基础设施即服务（IaaS）层以提供基础设施服务的集合来管理云计算环境中的计算资源。所述系统包括与IaaS层分离的服务框架层，服务框架层包括异步接口以与IaaS层通信并创建框架服务来响应于来自上等级服务的命令而扩展IaaS层，框架服务采用异步接口来利用来自基础设施服务集合的基础设施服务。

Description

用于IAAS的管理的异步框架

背景技术

云计算是指可伸缩和池化的计算、存储和联网能力以及容量的递送作为到终端接收者的网络的服务。名字来自于将云用作对复杂的网络基础设施和在云内操作的相关联硬件的抽象。云计算提供例如通过网络的针对用户的数据存储、软件及计算的服务。这样的计算能力依赖于资源的共享以实现通过网络（典型地因特网）的类似于公用事业（比如电网）的缩放的相关性和经济性。

支持云计算的服务的一个方面涉及基础设施即服务模型（IaaS），其中云服务提供商供给计算机，作为物理的或更经常地作为虚拟机，以及其它计算资源。虚拟机可以例如由监管者（hypervisor）服务作为客户机来运行。通过云操作支持系统的监管者的池（pool）的管理导致缩放的能力以支持大量虚拟机。IaaS云中的其它资源包括虚拟机图像库中的图像、原始（块）和基于文件的存储、防火墙、负载平衡器、IP地址、虚拟局域网（VLAN）和软件包（bundle）。

附图说明

图1图示了一种提供服务框架层以控制用于云应用的基本基础设施即服务层的系统的示例。

图2图示了一种提供服务框架层以管理用于云应用的IaaS层的系统的示例。

图3图示了示例系统300，系统300提供其中可以定义不由底层IaaS层提供的新异步粗粒度服务的框架。

图4图示了与服务框架层交互的示例拓扑供应服务。

图5和6图示了服务框架示例，其中服务框架可以与在图9中图示并关于图9描述的自动化部署系统集成。

图7图示了由服务框架层提供的多租户和混合配置的示例。

图8图示了一种用于控制用于云应用的基本基础设施即服务层的方法。

图9图示了与服务框架层交互并促进用于云应用的自动化部署的系统的示例。

具体实施例

系统和方法通过控制操作云资源的基本基础设施即服务（IaaS）层而提供增强的云服务。在一个示例中，IaaS供给单独的资源作为服务，诸如服务器、虚拟机、存储实例或网络实例，但是通常不组合这样的资源。用户通常必须手动地配置和组合资源。提供一种服务框架层，其通过在服务框架层中创建服务并利用异步接口向IaaS层发布命令以实现相应服务来控制（例如供应/实例化和管理生命周期）底层IaaS层。这样的命令允许创建不直接由IaaS层供给的框架服务。框架服务可以包括通过提供标识用于云区和域的资源池的方法以及提供选择和/或供应这样的资源的方法来创建支持异构的、混合和多租户云资源、资源池和应用（公共和/或私有）的服务。例如，这可以包括经由异步拓扑定义、绑定到池中的资源以及相关联的供应的复杂基础设施供应。异步方法还使得能够实现“云可伸缩性”（例如，处理大规模资源来进行管理的能力，其还包括以这样的资源来缩放对应量的管理请求的能力）。

图1图示了提供服务框架层110以控制用于云应用的基本基础设施即服务（IaaS）层120的系统100的示例。如本文中所使用的，术语IaaS可以指代控制被标识为云基础设施130（或其部分）的资源的任何较低级别等级的服务。这样的资源可以包括处理器、存储器、服务器、软件、应用等以及IaaS服务（例如安全性、图像管理），其协作而为期望利用云资源而非自己单独地提供它们的用户提供云计算能力。另外，术语层可以指代协作以提供服务的处理器可执行的指令的任何集合。在一个示例中，IaaS层120可以是如下面关于图2示出和描述的OpenStack技术。OpenStack是模块化、开源的云计算项目，其已知为OpenStack项目并由众多公司支持，在来自OpenStack基金会的许可下可用（参见例如www.openstack.org）。在其它示例中，IaaS层120可以根据其它技术（例如专有、商用或开源）来实现，诸如包括VMWare, Eucalyptus, Amazon AWS, Azure, Citrix技术, HP Matrix等。

IaaS层120提供基础设施服务的集合来管理云计算环境130中的计算资源。服务框架层110与IaaS层120分离并包括异步接口140来经由异步消息与IaaS层通信并且它可以以异步编程模式来实现。如本文中所使用的，术语“异步”指代其中消息/任务对于服务框架层110和相关联的上等级层是非阻塞的基于异步的编程，其中任务可以被定义和排队以供在那些相应层处执行而不用等待来自IaaS层（或其它层）的完成。因此，异步接口140是异步的，因为相关联的接口逻辑于是不必等待其完成（阻塞行为）而是代替地执行其它任务的调度，直到其被通知结果或错误事件可用（例如通过处理来自IaaS的响应的队列）。

于是服务框架层110可以基于在之前的任务完成之前它被编程来执行什么而继续进行到下一任务。该方法的可伸缩性产生于在服务框架层110处提供了这样的非阻塞行为。一般而言，无论接收了多少请求，并且无论每个请求需要在IaaS层120处处理多久，它们都可以被并行化，因为它们对于可能需要在IaaS以上的上等级层处发生的其它任务是非阻塞的。因此，可以采用异步协议来扩展在IaaS层120上供给的基础服务以及在创建目前不存在于IaaS层上的新服务（例如框架服务170）时编配（orchestrate）IaaS管理。在另一示例中，等待来自IaaS的响应也可以被支持。

如所示，服务框架层响应于来自诸如拓扑、供应和资源层150和/或接口层160之类的上等级服务的命令来创建框架服务170（示出为框架服务1-N，其中N是正整数）。框架服务170采用异步接口140来创建除了IaaS层120中的基础设施服务的基本集之外的对应的基础设施服务（或根据基础设施操作的平台服务）。尽管在服务框架层110中示出，但是框架服务170还可以发布为要在IaaS层120中执行的命令集（例如，由处理资源可执行的指令）。这还可以包括混合执行，其中框架服务170的部分在服务框架层中执行，并且部分在IaaS层中执行。

如本文中将描述的，框架服务170可以用于开发和提供不由底层IaaS层120供给的功能性。这样的框架服务170可以包括对多租户云应用和混合部署的支持，其可以包括对公共、私有和/或管理的云应用和/或配置和混合组合的支持。框架服务170还可以提供异构应用支持，其中不同的供应商和软件应用可以向由服务框架层110提供的共同框架发布请求。在一个示例中，可以创建框架服务170来管理给定的IaaS（例如，利用给定技术或针对给定的供应商HW或虚拟资源供应商来构建）。在另一示例中，可能的是使用框架服务170来控制来自另一供应商（例如，诸如Open Stack, Amazon, VMWare等之类的其它技术）的IaaS。

其它框架服务170可以包括动态绑定、多版本支持以及对构建在框架上的应用生命周期管理的支持。这还可以包括对不同资源、部署模型和租用模型的支持。

如本文将示出和描述的，系统100可以包括180处的一组管控/设计/管理接口以用于与本文描述的各种层交互。作为在服务框架层110上实现的服务的特定示例，接口层160可以被编程为理解和操纵在请求时（从上面）传递的或由设计者接口所设计的各种模板和拓扑模型，其定义被传递至拓扑、供应和资源层150的云资源和配置。拓扑、供应和资源层150可以构建在110框架层上/使用110框架层来构建以解释经由请求或设计者/管控者所接收的模板和拓扑以编配IaaS层120 API。拓扑、供应和资源层150可以将请求转化为发布的命令，并且由于它被构建在服务框架层110上，使用服务框架层110来经由异步接口140向IaaS层120发布命令以实现被请求实现的模板或拓扑。

为了简化解释的目的，在图1 的示例中，系统100的不同组件被图示和描述为执行不同的功能。然而，本领域普通技术人员将理解和领会到所描述组件的功能可以由不同组件执行，并且若干组件的功能性可以在单个组件上组合和执行。组件可以被实现，例如计算机可执行指令、硬件（例如专用集成电路或其它处理资源）或作为两者的组合。在其它示例中，组件可以分布在跨网络的远程设备之中。如本文中所使用的，指令可以存储在非暂时性计算机可读资源（例如介质）中由处理资源可执行。处理和存储器资源中的每一个可以存在于单个设备上或跨多个设备而分布，诸如数据中心或云环境。

在一个示例中，拓扑可以通过接口层160来定义，其中应用模板可以包括对于给定应用应当部署哪个应用组件（例如什么组件将被部署在云中的哪个位置处）的拓扑模型。作为另外的示例，部署管理器（在下面说明和描述）可以被提供有用于给定应用的拓扑模型（例如包括模型和各种基础设施资源），并且然后确定基本上匹配针对给定应用而实例化的拓扑模型的云130中的基础设施资源。在另一示例中，在针对给定应用供应了资源和部署了应用组件之后，然后可以针对给定应用而创建拓扑实例。拓扑实例可以被存储并用于稍后的管理和/或监控，诸如本文所公开的。

图2图示了提供服务框架层210来管理用于云应用的IaaS层220的系统200的示例。IaaS层220包括IaaS组件222，IaaS组件222具有管控（administration）服务224以用于IaaS的配置。层中的IaaS组件222可以包括各种基本服务226，示为服务1-N，其中N是正整数。这样的open stack（开放栈）服务226可以包括例如计算控制器服务、以及标识和访问管理器服务、云图像目录服务、存储管理、以及网络管理。

服务框架层210可以包括服务基础设施管控组件212，其可以包括云配置管理服务214和云封装储存库服务216。服务框架层210可以包括对各种云服务218的支持。在一些示例中，如所示，服务框架层210的云服务218可以包括执行服务、框架服务、集成服务、授权服务和云管理服务。服务框架层210中的服务基础设施228可以包括诸如JAVA SE服务、Apache Tomcat和Wink服务、对Rabbit MQ异步通信的支持、以及SQL数据库管理服务之类的示例。除所示的特定示例之外，可以提供其它的基础设施服务来与底层IaaS层220对接——在本示例中的open stack（开放栈）层。

服务框架层210包括用于构建和部署web规模的、无状态的、线程控制的、非阻塞的粗粒度服务的服务。这样的服务提供例如长的运行执行、多租户和基于角色的安全支持服务。如所示，服务可以与IaaS集成以用于标识管理服务。该服务框架层210可以促进开发异步服务，所述异步服务在其中IaaS是基于OpenStack的一个示例中遵循使用比如RabbitMQ的消息队列的IaaS异步模式。利用服务框架层210，可能的是以新的粗粒度服务（创建并构建在较低级别服务顶部的服务）补充IaaS。粗粒度服务例如可以表示新的系统能力，其作为之前在底层IaaS中不可用的服务而可用。该服务框架功能性可以包括供应商可能想要展露（expose）的基础设施的有区别的服务。在一些示例中，所展露的服务可以包括灾难复原（DR）、容量分析、退费、安全性、存储器备份和存储器还原。这还可以包括例如不能经由现有IaaS服务所展露的现有资源的能力的变型。

在图2的示例中，拓扑、供应和资源层230包括配置环境管控组件231。配置环境管控组件231可以包括一个或多个配置服务233来帮助管控者管理层230中的云服务。例如，云服务可以包括拓扑供应服务232、资源池注册服务234和拓扑文档储存库服务236。拓扑服务可以从接口层240接收描述各种云拓扑的拓扑模板。注册服务可以配置各种硬件组件来操作给定的云配置。这可以包括对资源池以及它们的品质（例如网络类型——Flat（扁平）或VLAN等等）和能力（例如网络系统——O~S Nova API或O~S Quantum API等等）的注册和描述的支持。注册服务还提供用于对不同资源池能力（例如网络分段——Nova安全性或量子（Quantum）网络）进行抽象化的共同API。

文档储存库服务236可以管理可以在（虚拟和物理的）云（例如在IaaS层220下面）上供应的不同配置。这可以包括提供用于基础设施拓扑文档（例如，类型、模板、绑定等）的注册和查找。文档储存库服务236可以被提供为插件模型并可以支持各种底层的存储和储存库类型。

如所示，接口层240可以指定可以用于经由较低服务级别来供应和使能云服务的各种拓扑和模板。具有接口A的配置设置工具242可以被管控者用来定义接口层240的接口能力。这可以包括支持和对接至虚拟器具（appliance）递送模型。这还可以包括对裸金属供应和利用例如Open Stack Crowbar的云服务配置管理以及被包括的软件封装储存库的支持。配置设置工具还可以包括管控控制台和各种云配置的增值的服务管控者接口视图。

仪表板组件244采用接口B来实现较低层。仪表板组件244可以提供环境来配置模板以定义用于拓扑、供应和资源层230的云拓扑。拓扑设计器246使用户能够定义可以潜在地供应在云上的系统。拓扑设计器246还定义具体的配置来在IaaS层处供应（配置和实例化）。拓扑设计器246支持针对给定拓扑的所定义的节点类型和关系。这可以包括生成可以被系统200的较低等级的级别利用的基础设施拓扑模板。这还可以包括绑定服务，所述绑定服务提供方法来指定抽象拓扑到资源池的绑定以用于输入至拓扑供应服务。层210、220、230和240的各个方面现在将在本文中关于图3-8来描述。

图3图示了用于提供其中可以定义不由底层IaaS层提供的新异步粗粒度服务的框架的示例系统300。系统300促进开发过程粒度的服务并包括被定义为从API 302（例如从另一组件或从上面的层或从门户）接收API请求的逻辑。如所示，Web UI 304、命令行解释器（CLI）工具306、和/或服务消费者应用308是可以生成这样的请求的示例。请求被请求处理器310接收，请求处理器310接收和/或安置来自队列的请求，并发起解决请求的逻辑。请求处理器310定义被安置在队列上的任务，其中请求工作器（worker）312处理请求并从那里产生任务。状态调查器（pollster）314被告知针对来自请求工作器312的并被安置在队列上以用于响应插件320来处理（例如返回对请求的应答或前进到下一任务）的完成（或错误）结果进行监控（轮询）。

API 302和服务框架可以用作模式模板并形成以开发不存在于底层IaaS上的新服务。例如，可以根据拓扑来提供组件以用于资源供应和管理，所述拓扑可以通过开发用于响应插件320和请求工作器312上的客户端330的组件来实现。工具304到308、请求处理器310经由API 302来与该新服务交互（通过调用它的API，如由响应插件320所定义的。

如所示，请求处理器302可以包括MQ（消息队列）库接口和340处的功能的持久库。这还可以提供共享的数据库访问以用于响应和异步消息队列访问。请求工作器312可以包括用于342处所示的任务插件的线程池化的、异步工作控制器。这还可以包括共享的数据库访问以用于任务工作和用以使服务客户端330能够调用其它服务。这还可以提供用于资源状态轮询的消息队列访问。状态调查器314可以提供线程池化的、一般化的资源状态轮询。例如，这可以包括服务客户端350来检查状态并提供对数据库360的消息队列访问以重初始化工作。如所示，请求处理器310和请求工作器312还可以采用数据库370用于附加的通信和跨任务的持久性。

图4 图示了构建在框架服务上的示例拓扑供应服务400。服务400使得能够经由拓扑模板的创建来供应基础设施。拓扑可以描述将供应的基础设施元素（节点类型）和这些元素之间的关系。这可以包括生命周期管理诀窍（recipe），所述诀窍指明这些资源和关系可以如何设置，诸如可以以基本上任何计算机语言来定义。

可以经由拓扑模板抽象化接口410和资源绑定池420来提供分离的模板创建和资源池绑定以用于更简单的和可重使用的模板。这些组件可以被设计器工具用来生成模板和绑定（或者两者），或者一个可以从另一系统交换并经由抽象化接口410接收。绑定可以包括显式地指出什么IaaS池（域/区）和什么API/服务将被用于实现拓扑（例如可以是将使用API的什么实现——在OpenStack IaaS的示例中，还可以是选择OpenStack插件来使用）。抽象化接口410和绑定池420可以向拓扑API 430提交抽象拓扑以创建内部拓扑模型440。这是形成整体拓扑功能抽象化444的部分的绑定拓扑。相应的拓扑可以抽象成一组功能步骤，所述功能步骤经由动态加载器460被加载为驱动器集合450中的各种驱动器。每个步骤可以动态地加载为匹配功能接口和接收自上部接口层的绑定定义的驱动器。用于功能的驱动器接口接受内部拓扑模型444的片段。驱动器集合450然后可以然后变换成例如提供给资源API 470的命令。

拓扑API 400可以经由插件模型而与云IaaS API的（例如，Open Stack Nova或可能地构建在框架上的任何其它服务）集成以用于编配基本的供应以提供例如复合的、混合的和分布式的基础设施拓扑。在一个示例中，插件是在不同的底层资源（不同的供应商、技术服务提供商、位置等等）上实现IaaS API（服务）（例如OpenStack）的不同驱动器。API 400还支持例如创建和配置诸如虚拟负载平衡器和配置管理服务之类的网络服务。

图5和6图示了服务框架示例，其中服务框架可以与自动化部署系统（例如关于图9所公开的）集成。在继续进行图5和6的详细描述之前，指出的是，图5和6供给了异步框架服务如何可以在如上文描述的IAAS的顶部上创建以及与在下文中关于图9更详细描述的连续递送自动化（CDA）服务协作的特定示例。在该示例中，云管控者可以供应云——例如在一个数据中心或多个数据中心上部署IaaS层。然后，云架构师可以设计由IaaS支持的拓扑。这些拓扑然后可以存储在拓扑储存库502中。

如果牵涉多个资源池，还可以根据池来布置它。使用504处的拓扑绑定器工具，CDA用户在506处可以设计（或者导出可以自动化）用于感兴趣的相应拓扑的绑定（例如以实现由CDA选择的基础设施模板来绑定至应用模型——参见图9以用于应用模型的讨论）。然后，CDA 506可以选择绑定并将之传递至拓扑供应器508（构建在框架上）。该方法于是可以编配对例如可能地在由下面关于图7讨论的域/区所定义的给定池中的IaaS API的（服务）的API的调用。供应的结果于是可以返回实现的拓扑实例，所述拓扑实例可以用于追踪什么被实例化（例如在CMDB中）并用于确定随时间要监控/管理什么。

最初地参照图5，IaaS层510与服务框架层的各种组件交互。连续递送自动化（CDA）系统506（参见图9以用于自动部署应用的CDA的描述）与开发者和拓扑供应器插件508交互。如所示，IaaS层510可以包括具有拓扑绑定器504和供应组件的仪表板。IaaS层510可以包括例如网络控制器、标识管理组件、对象存储装置、云控制器和图像储存库。仪表板的拓扑供应器与框架的拓扑供应器508、拓扑储存库502和资源池注册处530交互以指明给定的拓扑和资源，其进而与IaaS层510交互。管控接口560可以包括拓扑设计器、云供应器和管控控制台以用于与用于服务框架层的各种组件交互。如所示，在570处的开发者或用户可以与CDA 506交互。类似地，云管控者580或云架构师582可以与管控接口560交互。

图6图示了与图5中的系统500相似的系统600，其中IaaS组件610不包括用于与服务框架交互的仪表板接口。在该示例中，CDA系统620与提供到IaaS层610的接口的拓扑供应器交互。拓扑供应器630可以与拓扑储存库640、资源池注册处650和拓扑供应器插件660交互。系统600的其它组件可以包括拓扑设计器670和拓扑绑定器680以定义和实现给定的云拓扑。系统600还可以包括管控控制台684和云供应器，如前面所描述的。

图7图示了和由服务框架层提供的多租户和混合配置的示例。在该示例系统700中，不同的域可以与不同的云和/或不同的服务提供商或技术相关联以支持混合配置。不同的区（示为区1和区N，N是正整数）可以关联至不同的技术（异类的）和/或租户（资源的多租户分离（segregation））或其它特性（例如安全级别、顺从级别、向因特网的开放级别、专门化类型、能力等）。在一些示例中，每个区可以包括不同的网络配置、不同的容量模式，以及具有不同的或类似的计算实例的不同计算节点。在其它示例中，可以跨区共享类似的计算实例和/或资源。

区中的每一个可以属于域，其在该示例中示为域1。系统700还可以支持多个域，如描绘为域D，其中D是正整数。不同的域可以是不同的IaaS层，或由例如不同的服务提供商或不同的数据中心提供。在另一示例中，框架服务标识域或区来实现多租户云配置、混合云配置或异构云配置。在另一示例中，可以按照域或区地配置插件组件以用于IaaS层。

设置工具710可以配置如前面描述的各种组件，诸如拓扑设计器720、租户和模型服务目录730、图像注册处740、一个或多个实现的拓扑750、模板和绑定储存库760和资源池注册处770，其中这样的组件协作以形成抽象拓扑和可以实现为由服务框架对IaaS层的命令的供应请求。系统700可以包括对支持拓扑差异（特征或位置）的IaaS的不同插件。这可以包括对支持分离资源池和开放栈或用于控制的相关联插件的不同域和区的支持。类似地，例如可以通过使用不同的域用于每一个发布（release）来执行IaaS的不同版本（例如Open Stack发布、Vmware、Amazon、Rackspace、HP 矩阵、Azure等的不同版本）的支持。

鉴于上文描述的前述结构和功能特征，参考图8将更好地领会示例方法。虽然为了解释简单的目的，图8的示例方法被示出和描述为连续地执行，但要理解和领会的是，本示例不受所图示的次序限制，因为一些动作在其它示例中可以以与本文所示和所描述的不同的次序和/或同时发生。而且，没有必要执行所有描述的动作来实现方法。图8的示例方法可以实现为可以存储在非暂时性计算机可读介质中的机器可读指令，诸如可以是计算机程序产品或其它形式的存储器存储。对应于图8的方法的计算机可读指令还可以从存储器被访问并由处理资源（例如可以存在于单个设备上或跨多个设备而分布的一个或多个处理单元）来执行。

图8图示了用于控制用于云应用的基本基础设施即服务层的方法800。方法800包括在810处操作用于基础设施即服务（IaaS）层的基础设施服务集合以管理云中的计算资源。在820处，所述方法包括通过处理器提供与IaaS层分离的服务框架层，服务框架层包括异步接口来与IaaS层通信并创建框架服务以响应于来自上等级服务的命令而扩展IaaS层。在830处，方法800包括采用来自框架服务的异步接口以利用来自基础设施服务集合的基础设施服务。所述方法还可以包括采用框架服务情况下的异步接口以及处理器来控制Open Stack服务。

图9图示了与服务框架层交互并促进用于云应用的自动化部署的系统900的示例。系统900可以通过利用部署管理器920以确定云基础设施930（也称为云930）的基础设施能力并还通过分析应用模型940和策略950来确定应用910的应用需求而提供应用910的自动化部署。在这样的确定（经由将应用需求与基础设施匹配，例如手动或自动的匹配）之后，可以供应基础设施，并且然后应用可以得以部署，且然后可以在其寿命的进程上得以进一步管理。

当已经基于匹配而部署了应用时，部署管理器920还可以管理应用的生命周期的其它方面。例如，部署管理器920可以监控反馈，并基于这样的反馈而调整基础设施资源。附加地或可替换地，部署管理器920可以基于这样的反馈或其它检测到的事件而动态地调整应用模型和对应的策略。类似地，这还可以包括引退应用组件（例如，代码、中间件（MW）、数据库、操作系统（OS）等）的较老版本并安装组件的新版本以使得能够实现云基础设施930中应用的连续部署。

云930可以是混合的，使得它可以是被使得表现得像基础设施资源、私有云（有前提而开发的云技术）、公共云（由服务提供商供给的和经管理的云配置（有前提而管理的或在公共云/虚拟私有云中）的传统数据中心的组合。如本文中所使用的，术语应用适用于组件的集合。另外，应用可以对于其组件中的每一个通过人工制品集合（例如，安装程序、可执行、配置等以及被安装并彼此交互的组件集合（例如代码、中间件（MW）、数据库、操作系统（OS）等）来表征。同样，如本文所使用的，术语确定可以包括编译、列举和匹配。

如本文中所使用的，术语“基本上”旨在指示虽然被修饰的术语的功能或结果是期望或意欲的结果，但一些变化可以发生。在该上下文中，例如，术语“基本上匹配”描述了如下情形：作为结果的分析和比较被执行以标识相同的资源；然而，在实践中，匹配可以对应于足够类似以使能部署的资源集。在多于一个这样的资源集可能对应于匹配的情况下，部署管理器可以选择可用资源的最佳匹配集。可以利用用于选择这样的匹配的其它方法。

可以采用应用模型940来表征用于在云930上部署的给定应用910，诸如通过用于应用的各种组件的元数据描述。部署管理器920可以经由通过处理器可读的数据或可执行的指令来实现以基于与给定应用相关联的应用模型940和策略950（或多个策略）来分析针对给定应用910的应用需求。如将在下文描述的，可以提供策略950来描述用于应用910的附加操作上下文（例如在午夜之后操作应用，仅使用东海岸服务器，维持服务器之间的负载平衡，在给定网络域内部署，确保负载处于服务器上的指定限制之间，确保在给定窗口内没有即将来临的维护等等，同样地对于匹配的“测量接近度”的技术）。然后部署管理器920可以确定足以满足如由模型940和策略950指定的应用910的应用需求的云930中的基础设施资源。如所示，部署管理器、应用模型940和策略950共同地形成连续递送自动化系统952（CDA）。

云930的基础设施能力可以经由与云相关联的资源供给和元数据960来确定。例如，支持云930的多个服务提供商可以提供文件，所述文件指定它们具有什么类型的资源可用，和描述对于相应资源供给的感兴趣的属性的元数据（例如，具有元数据的三个可用服务器的资源供给，所述元数据指定存储器大小和处理器速度、负载（如果已经实例化）、位置、租用期限、服务级别协定（SLA）、调度的维护等等）。

在一个示例中，部署管理器920可以在应用910的应用需求与如由资源供给和元数据960指定的云的能力匹配之后自动地在云930上部署给定的应用910。在该类型的示例中，它通常相当于执行其它下面的下文描述的示例的指令（可能地通过调用管理基础设施和/或应用的生命周期的外部系统）。如前面指出的，术语应用910可以包括将被安装和执行的组件的集合（例如多个分层的逻辑、用户接口（UI）、中间件（MW）、数据库（DB）、除了安装和配置这样的组件的代码之外的操作系统（OS））。因此，应用910是指组件和人工制品的这些集合，其也可以包括这样的组件和人工制品的储存库。应用还可以通过对组件和人工制品的指针来标识，所述指针包括单独的指针或对组件集合的指针。在另一示例中，部署管理器920可以生成指令以告知系统（或用户）关于如何在云930上部署给定应用910。在任一示例中，部署管理器920自动地将如由模型940和策略950指定的应用910的需求与如由资源供给和元数据960指定的云930的能力相互关联。

如与常规系统的手动过程相对的，系统900利用策略和模型驱动的方法来使部署自动化。系统900可以基于模型940和策略950动态地（或静态地）优化和绑定基础设施资源（通过元数据属性来表征）到应用910，所述模型940和策略950表征它们在基础设施属性方面的需求。这可以包括将应用元数据与资源元数据匹配以及考虑策略和上下文以使应用及其组件/对云930的依赖性的优化的或优选的/标记的部署自动化，而没有还需要手动的部署步骤。在一个示例中，系统900允许追踪实例，同时还支持这样的实例的自动化管理（例如下文描述的自动化监控和反馈）。提供了不同的技术来摄取（ingest）、创作和设计还可以描述基础设施模板、应用模型和策略的元数据。这样的实例可以连同应用910、应用模型940和策略950一起存储在数据库或储存库（未示出）中。

系统900可以采用闭合的反馈环路用于监控应用。这样的监控应用可以基于策略诸如来按比例放大（scale up）或按比例缩小（scale down）应用执行需求，例如以及通知适当的接收者，诸如用户或系统应用。在一个示例中，可以在各种组件中安装收听器以从监控捕获事件。被收听器接收的事件可以触发处理机（handler），其可以生成系统上的生命周期管理操作（例如按比例放大、按比例缩小、移动、解供应（deprovision）、警告用户或系统、运行可以涉及本文描述的系统和其它应用的复合的另一可执行物，等等）。

系统900可以在一个或多个硬件平台上实现，其中系统中的模块可以在一个平台上或跨多个平台执行。这样的模块可以在云技术（各种形式/和混合云）上运行或被供给为可以在云上或离开云而实现的SaaS（软件即服务）。复杂的应用可以自动地部署在所需的基础设施上，而没有还需要用户理解如何执行这样的操作。策略950提供自动化指令用于操作帮助管控者减轻部署错误的指南（guideline）。元数据还可以通过标识应用的类型（例如经由UI或API）来与应用相关联，然而用户不需要理解应用特性。该方法基于应用与元数据的关联而允许用于应用的“最佳实践”、推荐的或强加的部署模型。策略还允许将应用特性与其它上下文考虑（例如关于用户、关于应用、关于基础设施、关于上下文、关于该特定用户、关于该特定应用等等）分离。这促进跨众多应用而重使用应用模型。还可以经由策略来实现特殊化。这也是例如系统如何强加：特性值的特定集合针对给定应用或版本被固定。例如，系统可以应用一般的应用模型以用于web应用，然而在另一情况下，明确地指定不同的模型或针对模型的属性的某些值。还可以从混合云提供资源（例如一些资源从本地数据库和服务器提供，并且一些资源从因特网服务提供）。

上文已描述的内容是示例。当然，不可能描述每一个可想到的组件或方法的组合，但是本领域普通技术人员将认识到许多另外的组合和置换是可能的。因此，本发明旨在包含落入包括所附权利要求的本申请的范围内的所有这样的变更、修改和变型。另外，在本公开或权利要求叙述“一”、“一个”、“第一”或“另一”元件或其等同物的地方，它应被解释为包括一个或多于一个这样的元件，既不要求也不排除两个或更多的这样的元件。如本文中所使用的，术语“包括”意味着包括但不限于，并且术语“包括了”意味着包括了但不限于。术语“基于”意味着至少部分地基于。

Claims (26)

1.一种系统，包括：

对应于由处理器可执行的指令的基础设施即服务（IaaS）层，以提供基础设施服务的集合来管理云中的计算资源，以及

与IaaS层分离的、对应于由处理器可执行的指令的服务框架层，服务框架层包括异步接口以与IaaS层通信并创建框架服务来响应于来自上等级服务的命令而扩展IaaS层，框架服务采用异步接口来利用来自基础设施服务集合的基础设施服务。

2.权利要求1的系统，其中服务框架还包括应用编程接口（API）以接收来自上等级服务的API请求以扩展IaaS层。

3.权利要求2的系统，上等级还包括web用户接口、命令行解释器（CLI）工具或服务消费者应用中至少一个以生成API请求。

4.权利要求2的系统，还包括请求处理器以接收来自队列的API请求，所述请求处理器发起框架逻辑来解决API请求。

5.权利要求4的系统，其中请求处理器定义被安置在队列上的任务，其中请求工作器组件处理所述请求并从请求工作器产生框架任务以扩展IaaS层。

6.权利要求5的系统，还包括状态调查器，所述状态调查器针对来自请求工作器的完成或错误结果中的至少一个进行监控以指示服务框架任务何时已实现。

7.权利要求2的系统，其中API和服务框架可以被用作模式模板以开发扩展IaaS层的新服务。

8.权利要求1的系统，其中框架服务将依照如从上等级服务所命令的IaaS层而实现多租户云配置。

9.权利要求1的系统，其中框架服务将依照如从上等级服务所命令的IaaS层而实现混合云配置，其中混合云配置包括至少两个云，所述至少两个云包括私有云、公共云或管理的云配置。

10.权利要求1的系统，其中框架服务将依照如从上等级服务所命令的IaaS层而实现异构云配置，其中混合云配置在云配置中包括多个硬件供应商。

11.权利要求1的系统，其中框架服务标识域或区以实现多租户云配置、混合云配置或异构云配置中的至少一个。

12.权利要求11的系统，其中可以基于所述域或区而为IaaS层配置插件组件。

13.权利要求1的系统，其中框架服务跨根据基础设施服务集合的对应的基础设施服务而指定计算资源的计算域或区而被实现。

14.权利要求1的系统，其中服务框架层通过与IaaS层通信来与自动化的部署组件交互以自动地实现给定拓扑。

15.权利要求1的系统，其中IaaS层是OpenStack层，其响应于来自上等级服务的命令来实现给定拓扑。

16.权利要求1的系统，其中服务框架层实例化框架服务以促进灾难复原、容量分析、退费控制、安全性控制、存储器备份能力或存储器还原能力中的至少一个。

17.一种系统，包括：

对应于由处理器可执行的指令的基础设施即服务（IaaS）层，以提供基础设施服务的集合来管理云中的计算资源；

与IaaS层分离的、对应于由处理器可执行的指令的服务框架层，服务框架层包括异步接口以与IaaS层通信并创建框架服务来响应于来自上等级服务的命令而扩展IaaS层，框架服务采用异步接口来利用来自基础设施服务集合的基础设施服务；以及

拓扑供应服务，其根据框架服务而操作以与服务框架层交互以实现给定拓扑。

18.权利要求17的系统，其中拓扑供应服务创建描述将被供应的基础设施元素和基础设施元素之间关系的拓扑。

19.权利要求18的系统，其中拓扑供应服务创建生命周期管理诀窍，其指明基础设施元素和关系可以如何设置。

20.权利要求17的系统，其中拓扑供应服务采用拓扑模板抽象化接口和资源绑定池来生成拓扑模板和绑定，其中绑定可以包括标识什么池和什么服务将被用于实现给定拓扑。

21.权利要求20的系统，其中给定拓扑被抽象成一组功能步骤，所述功能步骤经由动态加载器被加载为驱动器集合中的各种驱动器。

22.权利要求21的系统，其中每个功能步骤被动态地加载为将功能接口和从上等级服务接收的绑定定义相匹配的驱动器。

23.一种方法，包括：

通过处理器操作用于基础设施即服务（IaaS）层的基础设施服务的集合以管理云中的计算资源；

通过处理器提供与IaaS层分离的服务框架层，服务框架层包括异步接口以与IaaS层通信并创建框架服务来响应于来自上等级服务的命令而扩展IaaS层；以及

采用来自框架服务的异步接口来利用来自基础设施服务集合的基础设施服务。

24.权利要求23的方法，还包括采用框架服务情况下的异步接口以及处理器以控制OpenStack服务。

25.一种系统，包括：

用于存储与计算机相关联的计算机可执行指令的存储器；和

用于访问存储器和执行计算机可执行指令的处理资源，计算机可执行指令包括：

对应于由处理资源可执行的指令的基础设施即服务（IaaS）层，以提供基础设施服务的集合来管理云计算环境中的计算资源；

与IaaS层分离的、对应于由处理资源可执行的指令的服务框架层，服务框架层包括异步接口以与IaaS层通信并创建框架服务来响应于来自上等级服务的命令而扩展IaaS层，框架服务采用异步接口来利用来自基础设施服务集合的基础设施服务；以及

对应于由处理资源可执行的指令的上等级服务，以生成命令，其中命令定义将由基础设施服务的对应集合实现的潜在拓扑。

26.权利要求25的系统，还包括指令来生成模板，所述模板描述拓扑并由基础设施服务集合的拓扑服务处理以生成命令。