对云应用中的虚拟机进行分组的制作方法

文档序号:11160872阅读:561来源:国知局
对云应用中的虚拟机进行分组的制造方法与工艺

若干个软件平台包括使得能够对基于虚拟机的云应用进行建模的应用管理服务器。使用这样的应用管理服务器,应用设计者完成应用模型,其中应用可以由许多个虚拟机组成,其中每个虚拟机运行建模的应用的不同组件。因此,n层虚拟化云应用可以包括n个虚拟机服务器(简称“虚拟服务器”)。第一虚拟服务器可以运行第一应用组件(比如认证模块),第二虚拟服务器可以运行第二应用组件(比如数据库服务)等等。这样的应用管理服务器的实施例是可从加州帕洛阿尔托市的VMware,Inc.购得的Application DirectorTM

应用管理服务器也可以用作部署引擎。也就是说,一旦应用已经被建模,建模平台就提供对云计算环境部署该应用(以及其中建模的所有虚拟机)的手段。然而,一旦虚拟机被物理部署到云,部署的虚拟机通常就不可供应用管理服务器使用。为了便利建模/部署平台和部署在云中的应用之间的集成,使用单个应用标识符对部署到云基础设施的虚拟机中的一个或者更多个进行逻辑分组和标识已经变得是有用的。作为实施例,在基于云的应用正被部署时,方便的是使用单个标识符同时检索关于所有的部署的虚拟机的信息,而不是单个地访问众多(可能成千上万个)虚拟机。

此外,应用管理服务器引用部署在云中的每一个虚拟机也是方便的。这使得应用设计者能够改变先前部署的应用的应用模型并且将改变部署到已经在云中执行的虚拟机。另外,当云应用的虚拟机被云系统管理员(云系统管理员通常独立于应用设计者行动)向上或者向下扩展时,正被扩展的虚拟机通常被删除,并且用新近扩展的系统参数重新创建。要求应用管理服务器跟踪新近扩展的虚拟机将是繁重的。另一方面,为应用管理服务器提供用更抽象的(且独立的)标识符引用部署的虚拟机的手段缓解这个负担。



技术实现要素:

一个或者更多个实施方案为通过使用应用管理服务器被部署到云计算环境的虚拟机提供两个标识符。第一标识符标识虚拟机是其一部分的应用,并且当该应用的所有虚拟机都需要被应用管理服务器访问时是有用的。此外,第二标识符单个地标识虚拟机,并且当只有特定的一个虚拟机或者有限的一组部署的虚拟机需要被应用管理服务器访问时是有用的。

根据实施方案的在云计算环境下部署在多个虚拟机中执行的应用的方法包括以下步骤:产生应用标识符并且对第一虚拟机产生第一虚拟机标识符的步骤。所述方法进一步包括在云计算环境下对第一虚拟机进行实例化并且对第一虚拟机产生第二虚拟机标识符的步骤。所述方法进一步包括创建应用标识符、第一虚拟机标识符和第二虚拟机标识符之间的关联的步骤。

进一步的实施例提供一种包括指令的非暂时性计算机可读介质,所述指令当被执行时使得多个主机计算机能够实现以上方法的一个或者更多个方面。

进一步的实施例还提供一种被配置为实现以上方法的一个或者更多个方面的虚拟化计算系统。

附图说明

图1是描绘在其下可以实现一个或者更多个实施方案的虚拟化云计算环境的组件的框图。

图2是图示根据一个或者更多个实施方案的在基于云的应用内配置的虚拟机的标识符的产生和关联的概念图。

图3是图示根据一个或者更多个实施方案的部署多VM的基于云的应用的方法的流程图。

图4是图示根据一个或者更多个实施方案的多VM的基于云的应用的部署的概念图。

图5是根据一个或者更多个实施方案的在基于云的计算环境下向上扩展虚拟机的方法的流程图。

图6是图示根据实施方案的虚拟机在基于云的计算环境下的向上扩展的概念图。

图7是图示根据一个或者更多个实施方案的横向扩展(scaling out)虚拟化的基于云的应用的方法的流程图。

图8是描绘根据一个或者更多个实施方案的单VM的基于云的应用横向扩展为双VM的基于云的应用的概念图。

具体实施方式

图1是在其下可以实现一个或者更多个实施方案的虚拟化云计算环境的组件的框图。虚拟化云计算环境通常包括支持基于虚拟机的云应用的创建、部署和管理的一个或者更多个平台。一个这样的平台是可从加州帕洛阿尔托市的VMware,Inc.购得的Automation Center(或vCAC)。图1描绘了在所示的云计算环境下作为应用部署平台的vCAC 100。虽然vCAC 100是在图1中所描绘的环境下图示的,但是应注意到支持虚拟化云应用的创建和部署的任何计算平台都在本发明的范围内。

如图1所示,vCAC 100包括两个组件。首先,vCAC包括应用管理服务器110。在一个或者更多个实施方案中,应用管理服务器110包括一个或者更多个基于计算机的处理,这些处理实现支持云计算环境下的应用的创建和部署的应用布建平台。应用管理服务器110的终端用户(在图1中称为管理用户160)定义基于云的应用的结构和拓扑。在基于云的应用的管理用户160创建和互连的组件之中的是运行基于云的应用的各种软件组件的虚拟机。例如,管理用户160可能希望定义基于云的数据存储应用。在这样的情况下,管理用户160访问应用管理服务器110以对数据存储应用进行建模和创建。作为实施例,讨论中的数据存储应用可以被定义为“三层”应用,该应用包括负责存储数据的组件、负责提供数据安全性的组件以及用于发布数据以供在基于web的应用中查看的组件。这样的应用可以在应用管理服务器110中被建模为包括用于前述每个组件的单独的虚拟机(或者虚拟服务器)。一旦管理用户160已经完成了对基于云的应用的建模,应用管理服务器110就对建模的应用产生应用蓝图(未示出)。另外,应用部署计划(未示出)被保存在应用管理服务器110中,其中,一旦应用被选择被部署到云基础设施,该应用部署计划就被执行。

图1还描绘了vCAC 100包括使得能够在基于云的计算环境下布建虚拟化基础设施组件的组件。为了实现这一点,IaaS 120是使得能够选择将与基于云的应用一起部署的虚拟硬件元件的软件组件。也就是说,IaaS 120包含用于各种类型的虚拟装置(比如虚拟服务器)的模板,这些模板可以在云中被实例化。例如,IaaS 120可能已经配置和存储用于具有某些处理、记忆和存储能力的虚拟机的模板。因此,在特定实施方案中,IaaS 120可能已经在其中存储用于第一类型的虚拟服务器的模板以及用于第二类型的虚拟服务器的模板,第一类型的虚拟服务器具有32千兆字节(GB)的随机存取存储器(RAM),第二类型的虚拟服务器具有64GB的RAM。

如所示,IaaS 120与应用管理服务器110直接通信。当虚拟化应用将被部署到云时,应用通常需要在其上将安装应用和系统软件并且该应用在其中执行的虚拟硬件装置(例如,虚拟机)。在一个或者更多个实施方案中,应用管理服务器110(在管理用户160的指导下)从IaaS 120提供的模板选择虚拟机类型,其中在应用的建模阶段中定义的每个虚拟机对应于IaaS 120提供的虚拟机模板的类型。因此,使用以上提及的数据存储应用的实施例,管理用户160可以确定数据存储应用组件将在64GB RAM虚拟机上运行,但是数据安全性组件和数据发布组件均可以在32GB RAM虚拟机上运行。在这样的情况下,当数据存储应用被部署时,应用管理服务器110与IaaS 120进行通信,以便为被建模为虚拟化应用的一部分的每个虚拟机选择适当的虚拟机类型。

在实施方案中,IaaS 120与云计算平台(或者云“提供商”)直接通信。云计算平台通常包括支持基于云的应用的执行所需的计算资源。因此,云计算平台中的基础设施通常包括虚拟计算硬件和物理计算硬件,连同应用和系统软件。一些云基础设施平台(即,支持多个基于云的应用的平台)包括使得可以基于应用需求来平衡和重新分配虚拟硬件资源和物理硬件资源的机制。

如图1所示,IaaS 120与VM管理服务器130进行通信,VM管理服务器130是实现基于云的计算平台的系统软件的实施例。在一个实施例中,VM管理服务器130可以包括可从VMware,Inc.购得的vCenter ServerTM和程序产品。在图1所示的实施方案中,VM管理服务器130包括支持多个虚拟机(VM)的实例化和执行的一个或者更多个基于计算机的处理。因此,在该图中,VM 1401-140n被描绘为在VM管理服务器130中被实例化。此外,VM 1401-140n每个均被示为是应用150的一部分。应用150是如前面所提及的“分层”虚拟化应用的实施例。因此,应用150中的每个VM 140对应于应用管理服务器110中定义的对应应用的特定组件。再次参照基于云的数据存储应用,管理用户160使用应用管理服务器110对应用进行定义和建模,使用应用管理服务器110与IaaS 120结合地部署应用,并且应用通过IaaS 120将部署请求传送给VM管理服务器130而在云环境(即,VM管理服务器130)中被实例化。应注意到,VM 140在云中的实际实例化是由VM管理服务器130应IaaS 120的请求执行的。此外,下面将更详细地描述VM 140如何被关联为单个应用150的一部分。

一旦基于云的应用被部署到VM管理服务器130,应用就可以被应用用户170访问和使用。如图1所示,应用用户170通过网络180访问应用150,网络180又连接到VM管理服务器130。在实施方案中,VM管理服务器130(云“提供商”)通过接收通过不同的统一资源定位符(URL)的对应用的web请求来使其中部署的特定应用可以使用。

还应注意到,在一些实施方案中,应用管理服务器110可以被配置为与某些云基础设施(例如,公共云)(比如Amazon Web服务或者Microsoft)直接通信。该通信由应用110与云150之间的连接描绘。因此,在一些实施方案中,应用管理服务器110可以被配置为利用公共云提供商提供的基础设施服务将应用直接部署到这些云提供商。

此外,尽管图1的实施方案将vCAC 100和VM管理服务器130描绘为在单独的主机计算机(即,单独的物理服务器)上运行,但是应注意到,VM管理服务器130的一些或者全部功能可以由驻留在与vCAC 100相同的主机计算机上的模块执行。在这样的实施方案中,这些模块被配置为执行通常由VM管理服务器130执行的某些虚拟机管理功能(例如,平衡云计算环境内的虚拟机之间的或者几个云计算环境之间的工作负荷)。vCAC 100的还有的其他的实施方案包括被配置为在云计算环境下对虚拟机进行实例化的模块。实际上,vCAC 100和VM管理服务器130(在图1中被描绘)的组合功能可以在单个主机计算机上实现或者分布在几个主机计算机之间。

当基于云的应用通过使用应用管理服务器110和IaaS 120被建模并且被部署到云时,对于连接到应用管理服务器110的管理用户160来说可取的是能够通过根据部署的虚拟机在应用管理服务器110中的标识方式引用这些虚拟机来访问这些虚拟机。例如,在包括100个虚拟机的基于云的应用的部署操作期间,当这100个虚拟机在应用管理服务器110中被引用时,管理用户160可能希望检查这100个虚拟机中的一个或者全部的状态。因此,在一些实施方案中,管理用户160可以将请求正在为特定应用部署的所有虚拟机的列表的查询发送到IaaS 120和VM管理服务器130。对这样的询问的响应对于确定基于云的应用的部署的进展以及在VM管理服务器130是否已经发生任何部署故障将是有帮助的。在其他情况下,管理用户160可以发送查询以确定作为基于云的应用的当前在部署中的组件的一个特定虚拟机的状态。对这样的询问的响应对于确定正被查询的该特定虚拟机是否可以被实例化或者在它上是否已经安装有某个应用或者系统软件将是有帮助的。

图2是图示根据一个或者更多个实施方案的在基于云的应用中配置的虚拟机的标识符的产生和关联的框图。如图2所示,应用管理服务器110已经在其中对单VM的基于云的应用进行了建模。该应用的建模通过管理用户160访问应用管理服务器110而被执行(图1中已经示出)。在当基于云的应用被建模并且被部署时应用管理服务器110产生并且存储的元件之间的是与作为整体的该基于云的应用以及该基于云的应用中所包括的单个的虚拟机有关的标识符。在实施方案中,关于基于云的应用的这个元数据被存储在数据结构(比如图2所示的表格225)中。可替换地,该元数据被存储在应用管理服务器110可访问的文件系统中。

当管理用户160使用应用管理服务器110对基于云的应用进行建模、保存和部署时,应用管理服务器110产生唯一标识符。对于图2所示的实施方案,应用管理服务器110产生唯一应用ID(在图2中所描绘的实施例中称为AppID1),该唯一应用ID是作为整体的应用的标识符。例如,如果管理用户160对将运行并且访问Oracle数据库的数据库应用进行建模,则应用管理服务器110产生与该数据库应用对应的单个应用ID(例如AppID1)。因此,使用应用管理服务器110,管理用户将能够使用所产生的应用ID来引用或者查询数据库应用的任何元素。

另外,当管理用户160使用应用管理服务器110对基于云的应用进行建模、保存和部署时,应用管理服务器110为作为基于云的应用的组件的每个虚拟机产生唯一标识符。参照图2,该唯一标识符被标识为VM ID1。在图2所示的实施例中,对AppID1标识的基于云的应用产生单个VM ID1(即,VMID1_a)。因此,AppID1标识的基于云的应用是单VM应用,其中为该应用定义的单个VM在应用管理服务器110中由VMID1_a标识。例如,管理用户160可以对单VM的基于云的数据库应用进行建模,其中虚拟机被配置为运行Oracle数据库软件以及用户定义的应用软件。作为整体的数据库应用由其唯一应用ID(即,AppID1)引用,而只有作为数据库应用的一部分的虚拟机由其唯一VM ID1(即,VMID1_a)引用。因此,如果管理用户160希望(使用应用管理服务器110)检索图2中所描绘的应用的所有组件(例如,虚拟机和任何其他的虚拟硬件元件,比如虚拟交换机和盘)的状态,则管理用户160制定引用AppID1的查询并且将该查询从应用管理服务器110发送到云。如果管理用户160希望(使用应用管理服务器110)检索图2中所描绘的应用中的唯一一个虚拟机,则管理用户160制定引用VMID1_a的查询并且将该查询从应用管理服务器110发送到云。

如图2所示,应用管理服务器110与IaaS 120直接通信。IaaS 120又与VM管理服务器130直接通信。如前所述,IaaS 120提供管理用户160可以将其与在应用管理服务器110中建模的虚拟机相关联的预定义虚拟机类型(或者模板)的选择。当管理用户160部署应用时,应用管理服务器110将部署请求发送到IaaS 120。在实施方案中,IaaS 120将一个或者更多个请求发送到VM管理服务器130以便对请求的虚拟机进行实例化。因此,在图2所示的实施例中,应用管理服务器110将部署基于云的应用的请求发送到IaaS 120,该基于云的应用具有应用ID(AppID1),并且与具有VM ID1标识符(VMID1_a)的虚拟机相关联。在一个或者更多个实施方案中,IaaS 120接收部署请求(该部署请求包括应用ID和VM ID1标识符),并且将对所需虚拟机进行实例化的请求发送到VM管理服务器130。如图2所示,IaaS 120将应用ID(AppID1)和VM ID1标识符(VMID1_a)作为相关联的项存储在数据结构(例如表格230)中。另外,IaaS 120中的表格230包括另一个列,以使得AppID1和VMID1_a可以与另一个待标识的VM相关联。

如图2的下部分所示,VM管理服务器130从IaaS 120接收虚拟机实例化请求,并且作为对该请求的响应,对云内的虚拟机进行实例化。如该图所示,VM 140响应于从IaaS 120接收的请求而被实例化,该请求对应于IaaS 120从应用管理服务器110接收的请求。在所示的实施方案中,VM 140还包含元数据,该元数据要么被存储在虚拟存储器中,要么被存储在被配置为VM 140的一部分的虚拟存储装置上。该元数据包括AppID1和VMID1_a,如前所述,AppID1和VMID1_a是当基于云的应用在应用管理服务器110中被建模时由应用管理服务器110产生的标识符。另外,VM 140还包括附加标识符VMID2_a。VMID2_a是当虚拟机在VM管理服务器130中被实例化时VM管理服务器130产生的唯一虚拟机标识符(一般称为VM ID2)。VM ID2可以被存储在实例化的虚拟机中。可替换地,VM ID2可以被存储在虚拟机的外部,然而在逻辑上与虚拟机相关联。参照图2,因为VMID2_a是独立于AppID1和VMID1_a产生的,所以仍存在将应用管理服务器110产生的标识符(即,AppID1和VMID1_a)与VM管理服务器130产生的标识符(即,VMID2_a)相关联的任务。

在图2所示的实施方案中,一旦VM管理服务器130对VM 140进行了实例化并且产生了VMID2_a,VM管理服务器130就将VMID2_a发送到IaaS 120。当IaaS 120从VM管理服务器130接收到VMID2_a时,IaaS 120以将AppID1和VMID1_a与VMID2_a相关联的方式将VMID2_a存储在表格230中。VMID2_a的这个存储在图2中由箭头240概念性地图示,箭头240从VM 140内的VMID2_a延伸到IaaS 120内的表格230中的空数据字段。一旦VMID2_a被存储在IaaS 120的表格230中,AppID1和VMID1_a就与VMID2_a相关联。因此,在应用管理服务器110中配置的应用(即,具有应用ID AppID1的应用)和在VM管理服务器130内实例化的虚拟机(即,VM 140)之间创建了关联。该关联通过将VM 140显示为在应用150内被分组而被概念性地图示。应注意到,应用150用作标识在VM管理服务器130中实例化的虚拟机被分组在具有单个唯一应用标识符(例如AppID1)的单个应用内的方式。因此,在图2中,VM 140被分组到应用150中,应用150在逻辑上对应于在应用管理服务器110中建模的由AppID1标识的应用。

图3是图示根据一个或者更多个实施方案的部署多VM的基于云的应用的方法300的流程图。为了图示的目的,结合图4的框图对图3进行描述。如所示,方法300从步骤310开始,在步骤310,对具有一个或者更多个VM的应用进行建模。如前所述,这通常通过管理用户使用应用管理服务器110来实现。作为实施例,在图4中,应用管理服务器110已经在其中对具有三个单独的虚拟机的基于云的应用进行了建模。回头参照基于云的数据存储应用的实施例,第一虚拟机可以是存储服务器,第二虚拟机可以是安全服务器,而第三虚拟机可以是发布服务器。

参照图3,一旦基于云的应用在步骤310被建模,方法300就继续进行到步骤320。在步骤320,应用管理服务器110接收将建模的应用部署到云基础设施的请求。响应于在步骤320接收到部署请求,应用管理服务器110在步骤330产生与建模的应用对应的唯一应用ID。参照图4,AppID1(其被存储在应用管理服务器110内的表格225中)对应于建模的应用。

一旦唯一应用ID已经被产生,方法300就继续进行到步骤340。在步骤340,对在基于云的应用内被建模的下一个虚拟机产生唯一VM ID1。在图4中所描绘的实施例中,在应用管理服务器110中对三VM的基于云的应用进行建模。因此,在步骤340,对这三个虚拟机中的第一虚拟机产生并且存储VMID1_a。

在本实施方案中,方法300然后继续进行到步骤350,在步骤350,将其VM ID1已经在步骤340产生的虚拟机部署到云(或者在云中实例化)。在实施方案中,VM到云的部署包括将对VM的部署请求从应用管理服务器110发送到IaaS 120。部署请求包括所产生的应用ID和VM ID1(例如,AppID1和VMID1_a,来自于图4)。IaaS 120然后将对与部署请求对应的VM进行实例化的进一步请求发送到云基础设施(例如,VM管理服务器130)。如图4所示,IaaS 120接收对在应用管理服务器110中建模的第一VM(即,由VMID1_a标识的VM)的部署请求。IaaS 120将AppID1和VMID1_a存储在表格230中,并且将与应用管理服务器110中由VMID1_a标识的VM对应的实例化请求发送到VM管理服务器130。VM管理服务器130然后对第一虚拟机(即,VM 1401)进行实例化。如图4所示,VM 1401存储包括AppID1和VMID1_a的元数据。另外,作为VM 1401的实例化的结果,VM管理服务器130产生VMID2_a,VMID2_a被存储在VM 1401中(或者在逻辑上与VM 1401相关联)。

一旦在应用中被建模的下一个VM被部署到云(即,在云中被实例化),方法300就继续进行到步骤360。在步骤360,IaaS 120从云接收所产生的VM ID2,如前所述,该VM ID2是当云对VM进行实例化时由云(例如,VM管理服务器130)产生的。因此,参照图4,在步骤360,VM管理服务器130将VM ID2_a(其由VM管理服务器130在步骤350产生)发送到IaaS 120。

在步骤370,IaaS 120将在步骤360接收的VM ID2_a与应用ID AppID1和VM ID1 VMID1_a相关联,AppID1和VMID1_a分别是在步骤330和340中产生的。因此,如图4所示,IaaS 120从VM管理服务器130接收VM ID2_a,并且将它存储在表格230的包含AppID1和VMID1_a的条目中。因此,以这种方式,在AppID1和VMID1_a(从应用管理服务器110的角度来讲,VMID1_a唯一地标识建模的第一虚拟机)与VM 1401(其是在VM管理服务器130内实例化的对应虚拟机)之间建立了关联。

在步骤380,方法300确定是否存在被建模为应用管理服务器110中的基于云的应用的一部分的更多个VM。如果存在更多个VM,则方法300返回到步骤340,在步骤340,对下一个VM产生下一个VM ID1。因此,参照图4,对第二VM产生VMID1_b。方法300然后继续进行步骤350-370以将第二VM部署到云并且将部署的第二VM与在应用管理服务器110中建模的第二VM相关联。如图4所示,VM管理服务器130对VM 1402进行实例化,并且产生VMID2_b。AppID1和VMID1_b然后被与VMID2_b关联在表格230的第二条目中。应注意到,方法300对应用管理服务器110中建模的第三虚拟机(即,由VMID1_c标识的虚拟机)以相似的方式继续进行步骤340-370。

如果在步骤380,方法300确定不存在被建模为应用管理服务器110中的基于云的应用的一部分的更多个VM,则所有应用VM都被部署,方法300终止。

如前所述,将应用管理服务器110为虚拟机产生的标识符(即,应用ID和/或VM ID1)与当虚拟机被部署到云(即,VM ID2)时VM管理服务器130为同一个虚拟机产生的标识符相关联是有用的。一个益处是直接从应用管理服务器110跟踪虚拟机的部署的进展的能力。另一个益处是在虚拟机被部署过后每次访问已经部署的虚拟机的能力,以便在该虚拟机上更新或者安装新的软件。然而,当虚拟机被系统管理员向上扩展或者向下扩展时,应用ID和VM ID1(由应用管理服务器110产生)与VM 102(由VM管理服务器130产生)之间的关联可能断开。

在虚拟机被部署到云基础设施(比如VM管理服务器130)之后,系统管理员可以对该虚拟机执行“扩展(scaling)”。对虚拟机进行扩展是指动态地改变该虚拟机的系统参数(比如可用RAM的量、可用CPU的数量等等)。可以使用独立于应用管理服务器110操作的系统管理工具来对虚拟机进行向上或者向下扩展。例如,系统管理员可以使用VSphere管理工具套装来对基于云的虚拟机执行管理任务,VSphere管理工具套装可从VMware,Inc.购得。通常,对基于云的虚拟机进行扩展有必要包括以下操作:为云中的新的虚拟机分配所需的向上扩展(或者向下扩展)参数,将现存虚拟机的运行时状态和数据复制到新近扩展的虚拟机,对新近扩展的虚拟机进行实例化并且启动,并且摧毁(或者释放)先前存在的虚拟机。以这种方式,新近扩展的虚拟机取代先前存在的虚拟机。

然而,如果先前存在的虚拟机已经通过应用管理服务器110被部署到云,则由应用管理服务器110产生的标识符(应用ID和VM ID1)与由VM管理服务器130产生的标识符(VM ID2)之间的关联断开。这种情况的原因是由于当VM管理服务器130创建新近扩展的虚拟机时在该过程中产生新的VM ID2的事实。应注意到,先前存在的虚拟机的VM ID2不被复制到新近扩展的虚拟机或者不与新近扩展的虚拟机相关联。另外,一旦新近扩展的虚拟机被启动,先前存在的虚拟机就被连同关于该虚拟机的元数据一起摧毁。因此,先前存在的虚拟机的VM ID2不再引用现存的虚拟机。

尽管如此,先前存在的虚拟机的应用ID和VM ID1被持久存储,在实施方案中,被持久存储在IaaS 120的表格230以及应用管理服务器110的表格225中。因此,应用管理服务器110维持应用以及先前已经被建模和部署的对应虚拟机的唯一句柄。因此,可以在应用管理服务器110中建模的虚拟机被独立于应用管理服务器110向上或者向下扩展之后(例如,当这些虚拟机新近使用VSphere管理工具被扩展时)在应用ID与这些虚拟机的VM ID1之间建立关联。

图5是根据一个或者更多个实施方案的在基于云的计算环境下向上扩展虚拟机的方法500的流程图。将结合图6来描述图5,图6是概念性地图示基于云的计算环境下的虚拟机的向上扩展的框图。如图6所示,VM 1401是作为先前用一个虚拟机(在应用管理服务器110和IaaS 120中由VM ID1 VMID1_a标识)部署应用(在应用管理服务器110和IaaS 120中由应用ID AppID1标识)的结果在VM管理服务器130中实例化的虚拟机。在VM管理服务器130对VM 1401进行实例化时,VM管理服务器130产生VMID2_a,并且将该标识符与VM 1401相关联。方法500从步骤510开始,在步骤510,接收向上扩展虚拟机的请求。如图6所示,扩展请求610被VM云管理员600接收。在实施方案中,VM云管理员600可以包括可从VMware,Inc.购得的管理工具套装。在实施方案中,请求610被系统管理员通过例如系统控制台发送到VM云管理员600。

方法500然后继续进行到步骤520,在步骤520,响应于扩展请求,在云中对新近向上扩展的虚拟机进行实例化。这在图6中由新虚拟机VM 1402的创建(通过VM云管理员600与VM管理服务器130进行通信来创建)图示。在实施方案中,VM 1402是用与先前实例化和部署的VM 1401相关的向上扩展系统参数创建的。VM 1402的点线轮廓表示VM 1402是新近创建的。应注意到,当VM 1402被创建时,VM管理服务器130产生VMID2_b,VMID2_b不同于VM 1401的VMID2_a。

接着,在步骤530,将VM 1401的数据复制到VM 1402。如图6所示,这包括元数据项AppID1和VMID1_a。然而,VMID2_a不被复制到VM 1402或者不与VM 1402相关联。

一旦VM 1401的数据(以及元数据)被复制到VM 1402,方法500就继续进行到步骤540。在步骤540,将先前存在的虚拟机的应用ID和VM ID1与新近向上扩展的VM的VM ID2相关联。参照图6所示的实施方案,该关联是通过VM管理服务器130将VMID2_b传送给IaaS 120来执行的。作为响应,IaaS 120(其在向上扩展VM 1401之前将AppID1、VMID1_a和VMID2_a作为相关联的数据元素存储在表格230中)将VMID2_b存储在表格230的与AppID1和VMID1_a对应的条目中。这在图6中由箭头620概念性地示出。另外,VM 1402在图6中被描绘为被作为应用150的一部分分组在VM管理服务器130内,如前所述,应用150对应于应用管理服务器110中由AppID1标识的应用。

一旦应用ID和先前存在的虚拟机的VM ID1(例如,图6中的AppID1和VMID1_a)与新近扩展的虚拟机的VM ID2(例如,图6中的VMID 2_b)相关联,方法500就继续进行到步骤550,在步骤550,释放先前存在的虚拟机(即,VM 1401)。在步骤550之后,方法500终止。

除了向上(或者向下)扩展基于云的应用内的单个的虚拟机之外,基于云的应用还可以被“向内扩展(scaled in)”或者“横向扩展”。向内扩展基于云的应用是指在云内继续执行应用的同时从应用移除一些虚拟机。横向扩展基于云的应用是指在应用在云中执行的同时将虚拟机添加到应用。虽然向上扩展和向下扩展虚拟机通常是通过访问独立于应用管理服务器110的系统管理工具(比如VM云管理员600)来执行的,但是向内或者横向扩展基于云的应用是由访问应用管理服务器110的管理用户(比如图1的管理用户160)执行的。

图7是图示根据一个或者更多个实施方案的用于横向扩展虚拟化的基于云的应用的方法700的流程图。在此结合图8来描述图7,图8是描绘单VM的基于云的应用横向扩展为双VM的基于云的应用的框图。参照图8,管理用户160访问应用管理服务器110,应用管理服务器110已经在其中对先前部署到VM管理服务器130的单VM应用进行了建模。部署的应用由应用ID AppID1标识,第一VM由VMID1_a标识。如图8所示,IaaS 120的表格230将AppID1和VMID1_a与VMID2_a相关联,VMID2_a是先前部署的虚拟机VM 1401的VM ID2。

方法700从步骤710开始,在步骤710,应用管理服务器110接收横向扩展图8中由AppID1标识的应用的请求。在所示的实施方案中,横向扩展请求是将一个虚拟机添加到基于云的应用。然而,任何数量的虚拟机可以用单个请求添加。此外,如前所述,在实施方案中,这样的请求是从管理用户160接收的。

接着,在步骤720,应用管理服务器110对新近请求的虚拟机产生新的VM ID1。如图8所示,应用管理服务器110对与AppID1对应的新的虚拟机产生VMID1_b。在步骤730,将该新的虚拟机部署到云。如前面关于图3所提及的,在一个或者更多个实施方案中,应用管理服务器110将对虚拟机的部署请求发送到IaaS 120,IaaS 120继而将请求发送到VM管理服务器130(即,云基础设施)。参照图8,在应用管理服务器110将对第二虚拟机(即,由VMID1_b标识的虚拟机)的部署请求发送到IaaS 120之后,IaaS 120将AppID1和VMID1_b作为相关联的数据存储在表格230中。另外,IaaS 120将在云中对新的虚拟机进行实例化的请求发送到VM管理服务器130。

响应于来自IaaS 120的请求,VM管理服务器130对VM 1402进行实例化,在该过程中产生VMID2_b。注意到,AppID1和VMID1_b包括在新近实例化的VM 1402的元数据中。

一旦第二虚拟机(即,VM 1402)在云中被实例化,方法700就继续进行到步骤740。在步骤740,IaaS 120从VM管理服务器130接收新近实例化的VM 1402的VMID2_b。最后,在步骤750,IaaS 120将AppID1和VMID1_b(这二者都是由应用管理服务器110产生)与VMID2_b(由VM管理服务器130产生)相关联。参照图8,IaaS 120通过将VMID2_b存储在表格230的将AppID1与VMID1_b相关联的条目中来建立该关联。因此,一旦在步骤750建立关联,管理用户160就可以从应用管理服务器110访问VM 1402。如果管理用户160希望在以后的某个时刻从应用管理服务器110将软件安装在VM 1402上,这是有用的。

尽管在本文中已经为了使理解清晰较为详细地描述了一个或者更多个实施方案,但是应认识到,在不脱离本公开的精神的情况下,可以做出某些改变和修改。本文中所描述的各种实施方案可以利用涉及存储在计算机系统中的数据的各种计算机实现操作。例如,这些操作可能需要物理量的物理操控——通常,但不是必要的,这些量可以采取电信号或者磁信号的形式,在这种情况下,它们或者它们的表示能够被存储、被传送、被组合、被比较或者被以其他方式操控。此外,这样的操控通常是用比如生产、产出、标识、确定或者比较的术语来论述的。本文中所描述的形成本公开的一个或者更多个实施方案的任何操作可以是有用的机器操作。另外,本公开的一个或者更多个实施方案还涉及用于执行这些操作的装置或者设备。该设备可以是为特定的所需目的专门构造的,或者可以是由存储在计算机中的计算机程序选择性地启动或者配置的通用计算机。具体地说,各种通用机器可以与根据本文中的教导编写的计算机程序一起使用,或者可能更方便的是构造更专门的执行所需操作的设备。

本文中所描述的各种实施方案可以通过其他计算机系统配置来实施,所述其他计算机系统配置包括手持装置、微处理器系统、基于微处理器的或者可编程的消费者电子产品、微计算机、大型计算机等等。

本公开的一个或者多个实施方案可以被实现为一个或者更多个计算机程序,或者被实现为包含在一个或者更多个计算机可读介质中的一个或者更多个计算机程序模块。术语计算机可读介质是指可以存储其后可以被输入到计算机系统的数据的任何数据存储装置——计算机可读介质可以基于任何现有的或者以后开发的用于以使得计算机程序能够被计算机读取的方式实施这些计算机程序的技术。计算机可读介质的实施例包括硬盘驱动器、联网存储(NAS)、只读存储器、随机存取存储器(例如,闪存装置)、CD(紧凑盘)——CD-ROM、CD-R或者CD-RW、DVD(数字多功能盘)、磁带以及其他光学和非光学数据存储装置。计算机可读介质还可以分布在联网计算机系统上以使得计算机可读代码被以分布式的方式存储和执行。

尽管已经为了使理解清晰较为详细地描述了本公开的一个或者更多个实施方案,但是将清楚的是,可以在权利要求书的范围内做出某些改变和修改。因此,所描述的实施方案要被认为是说明性的,而非限制性的,并且权利要求书的范围不限于本文中所给出的细节,而是可以在权利要求书的范围和等同形式内被修改。在权利要求书中,元件和/或步骤并不暗示操作的任何特定次序,除非权利要求书中有明确陈述。

各种变更、修改、添加和改进是可能的。可以对在本文中被描述为单个实例的组件、操作或者结构提供复数个实例。各种组件、操作和数据存储之间的边界是颇为任意的,并且具体操作是在特定的说明性配置的上下文下例示说明的。其他功能分配被预想,并且可以落在本公开的范围内。一般来说,在示例性配置中呈现为单独的组件的结构和功能可以被实现为组合式结构或者组件。类似地,呈现为单个组件的结构和功能可以被实现为分开的组件。这些以及其他变更、修改、添加和改进可以落在所附权利要求(一个或者更多个)的范围内。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1