BACKGROUND
A number of software platforms include an application management server that enables the modeling of virtual machine-based cloud applications. Using such an application management server, an application designer completes an application model, where the application may consist of many virtual machines, each of which runs a different component of the modeled application. Thus, an n-tiered virtualized cloud application may comprise n virtual machine servers (“virtual servers” for short). A first virtual server may run a first application component (such as an authentication module), a second virtual server may run a second application component (such as database services), and so on. An example of such an application management server is Application Director™, which is available commercially from VMware, Inc. of Palo Alto, Calif.
Application management servers may also serve as deployment engines. That is, once an application has been modeled, the modeling platform provides a means of deploying the application (and all virtual machines modeled therein) to a cloud computing environment. However, once a virtual machine is physically deployed to a cloud, the deployed virtual machine is typically unavailable to the application management server. To facilitate integration between the modeling/deployment platform and applications deployed in the cloud, it has become useful to logically group and identify one or more of the virtual machines deployed to a cloud infrastructure using a single application identifier. As an example, while a cloud-based application is being deployed, it is convenient to retrieve information for all deployed virtual machines simultaneously using a single identifier, rather than access a multitude (perhaps thousands) of virtual machines individually.
Further, it is also convenient to refer to each individual virtual machine deployed in a cloud by the application management server. This enables an application designer to change an application model of a previously deployed application, and to deploy the changes to the virtual machines already executing in the cloud. In addition, when a virtual machine of the cloud application is scaled up or down by a cloud system administraor (who typically acts independently of an application designer), the virtual machine being scaled is usually deleted and recreated with newly scaled system parameters. Requiring the application management server to track the newly scaled virtual machine would be burdensome. On the other hand, providing the application management server with a means of referring to deployed virtual machines with a more abstract (and independent) identifier alleviates this burden.
SUMMARY
One or more embodiments provide two identifiers for a virtual machine that is deployed to a cloud computing environment using an application management server. A first identifier identifies the application that the virtual machine is a part of, and which is useful when all virtual machines of the application need to be accessed by the application management server. Further, a second identifier individually identifies the virtual machine, and is useful when only a particular virtual machine, or limited set of deployed virtual machines, needs to be accessed by the application management server.
A method of deploying an application that is executed in a plurality of virtual machines in a cloud computing environment, according to embodiments, includes the steps of generating an application identifier and generating a first virtual machine identifier for a first virtual machine. The method further comprises the steps of instantiating the first virtual machine in the cloud computing environment and generating a second virtual machine identifier for the first virtual machine. The method further comprises the step of creating an association among the application identifier, the first virtual machine identifier, and the second virtual machine identifier.
Further embodiments provide a non-transitory computer-readable medium that includes instructions that, when executed, enable a plurality of host computers to implement one or more aspects of the above method.
Further embodiments also provide a virtualized computing system that is configured to implement one or more aspects of the above method.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a block diagram depicting components of a virtualized cloud computing environment in which one or more embodiments may be implemented.
FIG. 2 is a conceptual diagram that illustrates the generation and association of identifiers for a virtual machine that is configured within a cloud-based application, according to one or more embodiments.
FIG. 3 is a flow diagram that illustrates a method of deploying a multi-VM cloud-based application, according to one or more embodiments.
FIG. 4 is a conceptual diagram that illustrates the deployment of a multi-VM cloud-based application, according to one or more embodiments.
FIG. 5 is a flow diagram of a method of scaling up a virtual machine in a cloud-based computing environment, according to one or more embodiments.
FIG. 6 is a conceptual diagram that illustrates the scaling up of a virtual machine in a cloud-based computing environment, according to embodiments.
FIG. 7 is a flow diagram that illustrates a method of scaling out a virtualized cloud-based application, according to one or more embodiments.
FIG. 8 is a conceptual diagram that depicts the scaling out of a single-VM cloud-based application to a dual-VM cloud-based application, according to one or more embodiments.
DETAILED DESCRIPTION
FIG. 1 is a block diagram of components of a virtualized cloud computing environment in which one or more embodiments may be implemented. Virtualized cloud computing environments typically comprise one or more platforms that support the creation, deployment, and management of virtual machine-based cloud applications. One such platform is the vCloud® Automation Center (or vCAC), which is commercially available from VMware, Inc. of Palo Alto, Calif. FIG. 1 depicts vCAC 100 as an application deployment platform in the cloud computing environment shown. While vCAC 100 is illustrated in the environment depicted in FIG. 1, it should be noted that any computing platform that supports the creation and deployment of virtualized cloud application is within the scope of the present invention.
As shown in FIG. 1, vCAC 100 includes two components. First, vCAC includes application management server 110. In one or more embodiments, application management server 110 comprises one or more computer-based processes that implement an application provisioning platform that supports the creation and deployment of applications in cloud computing environments. An end user of application management server 110 (referred to in FIG. 1 as management user 160) defines the structure and topology of a cloud-based application. Among the components of a cloud-based application that management user 160 creates and interconnects are virtual machines that run the various software components of the cloud-based application. For example, management user 160 may wish to define a cloud-based data storage application. In such a case, management user 160 accesses application management server 110 to model and create the data storage application. As an example, the data storage application in question may be defined as a “three-tiered” application, which includes a component that is responsible for storing data, a component that is responsible for providing data security, and a component for publishing data for viewing in a web-based application. Such an application may be modeled in application management server 110 as comprising a separate virtual machine (or virtual server) for each of the aforementioned components. Once management user 160 has completed modeling a cloud-based application, application management server 110 generates an application blueprint (not shown) for the modeled application. In addition, an application deployment plan (not shown) is saved in application management server 110, where the application deployment plan is executed once the application is selected for deployment to a cloud infrastructure.
FIG. 1 also depicts vCAC 100 as including a component that enables the provisioning of virtualized infrastructure components in a cloud-based computing environment. To accomplish this, IaaS 120 is a software component that enables the selection of virtual hardware elements to be deployed along with a cloud-based application. That is, IaaS 120 contains templates for various types of virtual devices (such as virtual servers), which may be instantiated in a cloud. For example, IaaS 120 may have configured and stored templates for virtual machines with certain processing, memory, and storage capacities. Thus, in a particular embodiment, IaaS 120 may have stored therein a template for a first type of virtual server with 32 Gigabytes (GB) of random access memory (RAM), and a template for a second type of virtual server with 64 GB of RAM.
As shown, IaaS 120 communicates directly with application management server 110. When a virtualized application is to be deployed to a cloud, the application typically requires virtual hardware devices (e.g., virtual machines) on which application and system software is to be installed and in which the application executes. In one or more embodiments, application management server 110 (under the direction of management user 160) selects virtual machine types from the templates provided by IaaS 120, where each virtual machine defined in the modeling phase of the application corresponds to a type of virtual machine template that is made available by IaaS 120. Thus, using the example of the data storage application mentioned above, management user 160 may determine that the data storage application component is to run on a 64 GB RAM virtual machine, but that the data security and data publishing components may each run on a 32 GB RAM virtual machine. In such a case, when the data storage application is deployed, application management server 110 communicates with IaaS 120 in order to select the appropriate virtual machine type for each of the virtual machines modeled as part of the virtualized application.
In embodiments, IaaS 120 communicates directly with a cloud computing platform (or a cloud “provider”). Cloud computing platforms typically include the computing resources required to support the execution of cloud-based applications. Thus, the infrastructure in a cloud computing platform typically includes virtual and physical computing hardware, along with application and system software. Some cloud infrastructure platforms (i.e. platforms that support multiple cloud-based applications) include mechanisms that allow for the balancing and reallocation of virtual and physical hardware resources based on application demand.
As shown in FIG. 1, IaaS 120 communicates with VM management server 130, which is an example of system software that implements a cloud-based computing platform. In one embodiment, VM management server 130 may comprise the vCenter Server™ and vSphere® program products, which are commercially available from VMware, Inc. In the embodiment shown in FIG. 1, VM management server 130 comprises one or more computer-based processes that support the instantiation and execution of multiple virtual machines (VMs). Thus, in the figure, VMs 1401-140n are depicted as instantiated in VM management server 130. Further, each of VMs 1401-140n is shown as being a part of application 150. Application 150 is an example of a “tiered” virtualized application as previously mentioned. Thus, each VM 140 in application 150 corresponds to a particular component of a corresponding application that is defined in application management server 110. Again referring to the cloud-based data storage application, management user 160 defines and models the application using application management server 110, deploys the application using application management server 110 in conjunction with IaaS 120, and the application is instantiated in a cloud environment (i.e. VM management server 130) by IaaS 120 communicating a deployment request to VM management server 130. It should be noted that the actual instantiation of VMs 140 in the cloud is performed by VM management server 130 at the request of IaaS 120. Further, it will be described in more detail below how VMs 140 are associated as part of a single application 150.
Once a cloud-based application is deployed to VM management server 130, the application may be accessed and used by an application user 170. As shown in FIG. 1, application user 170 accesses application 150 through network 180, which is, in turn, connected to VM management server 130. In embodiments, VM management server 130 (the cloud “provider”) makes available a particular application deployed therein by accepting web requests for the application over a distinct Uniform Resource Locator (URL).
It should also be noted that, in some embodiments, application management server 110 may be configured to communicate directly with certain cloud infrastructures (e.g., public clouds), such as Amazon Web Services or Microsoft. This communication is depicted by the connection between application 110 and cloud 150. Thus, in some embodiments, application management server 110 may be configured to deploy applications directly to public cloud providers, utilizing the infrastructure services provided by those cloud providers.
Further, although the embodiment of FIG. 1 depicts vCAC 100 and VM management server 130 as running on separate host computers (i.e., separate physical servers), it should be noted that some or all of the functionality of VM management server 130 may be performed by modules residing on the same host computer as vCAC 100. In such embodiments, these modules are configured to perform certain virtual machine management functions that are typically performed by VM management server 130 (e.g., balancing workloads between virtual machines within a cloud computing environment or between several cloud computing environments). Still other embodiments of vCAC 100 include modules that are configured to instantiate virtual machines in a cloud computing environment. Indeed, the combined functionality of vCAC 100 and VM management server 130 (as depicted in FIG. 1) may be implemented either in a single host computer or distributed among several host computers.
When a cloud-based application is modeled and deployed to a cloud using application management server 110 and IaaS 120, it is desirable for a management user 160 connected to application management server 110 to be able to access the deployed virtual machines by referring to the deployed virtual machines according to how the virtual machines are identified in application management server 110. For example, during a deployment operation of a cloud-based application comprising 100 virtual machines, management user 160 may wish to check the status of one or all of the 100 virtual machines as the virtual machines are referred to in application management server 110. Thus, in some embodiments, management user 160 may transmit a query to IaaS 120 and to VM management server 130, requesting a listing of all virtual machines being deployed for a particular application. The response to such an inquiry would be helpful in determining the progress of the deployment of the cloud-based application, and whether any deployment failures have occurred within VM management server 130. In other cases, management user 160 may transmit a query to determine the status of one particular virtual machine that is a component of a cloud-based application currently under deployment. The response to such an inquiry would be helpful in determining whether or not the particular virtual machine being queried may be instantiated or may have certain application or system software installed on it.
FIG. 2 is a block diagram that illustrates the generation and association of identifiers for a virtual machine that is configured within a cloud-based application, according to one or more embodiments. As shown in FIG. 2, application management server 110 has modeled therein one single VM cloud-based application. The modeling of the application is performed by management user 160 accessing application management server 110 (as was shown in FIG. 1). Among the elements that application management server 110 generates and stores when a cloud-based application is modeled and deployed are specific identifiers that pertain to the cloud-based application as a whole, and to individual virtual machines that are included in the cloud-based application. In embodiments, this metadata for the cloud-based application is stored within a data structure, such as table 225 illustrated in FIG. 2. Alternatively, the metadata is stored in a file system that is accessible to application management server 110.
When management user 160 models, saves, and deploys a cloud-based application using application management server 110, application management server 110 generates unique identifiers. For the embodiment illustrated in FIG. 2, application management server 110 generates a unique application ID (referred to in the example depicted in FIG. 2 as AppID1), which is an identifier for the application as a whole. For example, if management user 160 models a database application that is to run and access an Oracle database, then application management server 110 generates a single application ID (e.g., AppID1) that corresponds to that database application. Thus, using application management server 110, a management user would be able to refer to or query any element of the database application using the generated application ID.
In addition, when management user 160 models, saves, and deploys a cloud-based application using application management server 110, application management server 110 generates a unique identifier for each virtual machine that is a component of the cloud-based application. Referring to FIG. 2, this unique identifier is identified as VM ID1. In the example illustrated in FIG. 2, a single VM ID1 (i.e., VMID1—a) is generated for the cloud-based application identified by AppID1. Thus, the cloud-based application identified by AppID1 is a single-VM application, wherein the single VM defined for the application is identified in application management server 110 by VMID1—a. For example, management user 160 may model a single-VM cloud-based database application, where the virtual machine is configured to run the Oracle database software as well as user defined application software. The database application as a whole is referred to by its unique application ID (i.e., AppID1), while only the virtual machine that is a part of the database application is referred to by its unique VM ID1 (i.e., VMID1—a). Thus, if management user 160 wishes to retrieve (using application management server 110) the status of all components of the application depicted in FIG. 2 (e.g., the virtual machine and any other virtual hardware elements, such as virtual switches and disks), management user 160 formulates and transmits a query from application management server 110 to the cloud, referring to AppID1. If management 160 user wishes to retrieve (using application management server 110) the deployment status of only the single virtual machine in the application depicted in FIG. 2, management user 160 formulates and transmits a query from application management server 110 to the cloud, referring to VMID1—a.
As shown in FIG. 2, application management server 110 communicates directly with IaaS 120. IaaS 120, in turn, communicates directly with VM management server 130. As previously mentioned, IaaS 120 provides a selection of predefined virtual machine types (or templates) that management user 160 may associate with the virtual machines modeled in application management server 110. When management user 160 deploys an application, application management server 110 transmits a deployment request to IaaS 120. IaaS 120, in embodiments, transmits one or more requests to VM management server 130 in order to instantiate the requested virtual machines. Thus, in the example illustrated in FIG. 2, application management server 110 transmits a request to deploy the cloud-based application having an application ID, AppID1, and associated with a virtual machine having a VM ID1 identifier, VMID1—a, to IaaS 120. In one or more embodiments, IaaS 120 receives the deployment request (which includes the application ID and the VM ID1 identifier), and transmits a request to VM management server 130 to instantiate the required virtual machine. As shown in FIG. 2, IaaS 120 stores the application ID, AppID1, and the VM ID1 identifier, VMID1—a, as associated items in a data structure (e.g., table 230). In addition, table 230 in IaaS 120 includes another column so that AppID1 and VMID1—a can be associated with another yet to be identified VM.
As shown in the lower part of FIG. 2, VM management server 130 receives virtual machine instantiation requests from IaaS 120 and, in response thereto, instantiates virtual machines within the cloud. As shown in the figure, VM 140 is instantiated in response to a request received from IaaS 120, which corresponds to the request IaaS 120 receives from application management server 110. In the embodiment illustrated, VM 140 also contains metadata, which is either stored in virtual memory or on a virtual storage device that is configured as a part of VM 140. The metadata includes AppID1 and VMID1—a, which, as was mentioned previously, are the identifiers generated by application management server 110 when a cloud-based application is modeled therein. Additionally, VM 140 also includes an additional identifier, VMID2—a. VMID2—a is a unique virtual machine identifier (referred to generally as VM ID2) that is generated by VM management server 130 when a virtual machine is instantiated therein. VM ID2 may be stored in the instantiated virtual machine. Alternatively, VM ID2 may be stored external to the virtual machine while being logically associated with the virtual machine. Referring to FIG. 2, since VMID2—a is generated independently from AppID1 and VMID1—a, there remains the task to associate the identifiers generated by application management server 110 (i.e., AppID1 and VMID1—a) with the identifier generated by VM management server 130 (i.e., VMID2—a).
In the embodiment illustrated in FIG. 2, once VM management server 130 instantiates VM 140 and generates VMID2—a, VM management server 130 transmits VMID2—a to IaaS 120. When IaaS 120 receives VMID2—a from VM management server 130, IaaS 120 stores VMID2—a in table 230 in a way so as to associate AppID1 and VMID1—a with VMID2—a. This storing of VMID2—a is illustrated conceptually in FIG. 2 by arrow 240 extending from VMID2—a within VM 140 to the null data field in table 230 within IaaS 120. Once VMID2—a is stored in table 230 of IaaS 120, then AppID1 and VMID1—a are associated with VMID2—a. Hence, an association is created between the application configured in application management server 110 (i.e., the application with application ID AppID1) and the virtual machine instantiated within VM management server 130 (i.e., VM 140). This association is illustrated conceptually by showing VM 140 as grouped within application 150. It should be noted that application 150 serves as a way of identifying a grouping of virtual machines instantiated in VM management server 130 within a single application having a single unique application identifier (e.g., AppID1). Thus, in FIG. 2, VM 140 is grouped into application 150, which logically corresponds to the application modeled in application management server 110 identified by AppID1.
FIG. 3 is a flow diagram that illustrates a method 300 of deploying a multi-VM cloud-based application, according to one or more embodiments. For purposes of illustration, FIG. 3 is described in conjunction with the block diagram of FIG. 4. As shown, method 300 begins at step 310, where an application with one or more VMs is modeled. As previously mentioned, this is typically accomplished by a management user using application management server 110. As an example, in FIG. 4, application management server 110 has modeled therein a cloud-based application having three separate virtual machines. Referring back to the example of the cloud-based data storage application, the first virtual machine may be a storage server, the second virtual machine may be a security server, and the third virtual machine may be a publishing server.
Referring to FIG. 3, once the cloud-based application is modeled at step 310, method 300 proceeds to step 320. At step 320, application management server 110 receives a request to deploy the modeled application to a cloud infrastructure. In response to receiving the deployment request at step 320, application management server 110 generates, at step 330, a unique application ID that corresponds to the modeled application. With reference to FIG. 4, AppID1 (which is stored in table 225 within application management server 110) corresponds to the modeled application.
Once the unique application ID has been generated, method 300 proceeds to step 340. At step 340, a unique VM ID1 is generated for a next virtual machine that is modeled within the cloud-based application. In the example depicted in FIG. 4, a three-VM cloud based application is modeled in application management server 110. Hence, at step 340, VMID1—a is generated and stored for the first of the three virtual machines.
In the present embodiment, method 300 then proceeds to step 350, where the virtual machine whose VM ID1 has been generated at step 340 is deployed to (or instantiated in) the cloud. In embodiments, deployment of a VM to the cloud comprises transmitting a deployment request for the VM from application management server 110 to IaaS 120. The deployment request includes the generated application ID and VM ID1 (e.g., AppID1 and VMID1—a, from FIG. 4). IaaS 120 then transmits a further request to the cloud infrastructure (e.g., to VM management server 130) to instantiate a VM corresponding to the deployment request. As shown in FIG. 4, IaaS 120 receives a deployment request for the first VM modeled in application management server 110 (i.e., the VM identified by VMID1—a). IaaS 120 stores AppID1 and VMID1—a in table 230, and transmits an instantiation request to VM management server 130 corresponding to the VM identified in application management server 110 by VMID1—a. VM management server 130 then instantiates a first virtual machine (i.e., VM 1401). As shown in FIG. 4, VM 1401 stores metadata that includes AppID1 and VMID1—a. In addition, as a result of the instantiation of VM 1401, VM management server 130 generates VMID2—a, which is stored in (or is logically associated with) VM 1401.
Once the next VM modeled in the application is deployed to the cloud (i.e., instantiated in the cloud), method 300 proceeds to step 360. At step 360, the generated VM ID2, which, as previously mentioned, is generated by the cloud (e.g., VM management server 130) when the cloud instantiates a VM, is received by IaaS 120 from the cloud. Thus, with reference to FIG. 4, at step 360, VM management server 130 transmits VMID2—a (which VM management server 130 generates at step 350) to IaaS 120.
At step 370, IaaS 120 associates VMID2—a received at step 360 with application ID AppID1 and VM ID1 VMID1—a, which are generated, respectively, in steps 330 and 340. Thus, as shown in FIG. 4, IaaS 120 receives VMID2—a from VM management server 130 and stores it in the entry of table 230 that contains AppID1 and VMID1—a. Thus, in this way, an association is established between AppID1 and VMID1—a (which uniquely identify, from the perspective of application management server 110, the first modeled virtual machine) with VM 1401 (which is the corresponding virtual machine instantiated within VM management server 130).
At step 380, method 300 determines whether there are more VMs modeled as part of the cloud-based application in application management server 110. If there are more VMs, then method 300 proceeds back to step 340, where a next VM ID1 is generated for the next VM. Thus, referring to FIG. 4, VMID1—b is generated for the second VM. Method 300 then proceeds through steps 350-370 to deploy the second VM to the cloud and to associate the deployed second VM with the second VM as modeled in application management server 110. As shown in FIG. 4, VM management server 130 instantiates VM 1402 and generates VMID2—b. AppID1 and VMID1—b are then associated with VMID2—b in the second entry of table 230. It should be noted that method 300 proceeds through steps 340-370 in like manner for the third virtual machine modeled in application management server 110 (i.e., the virtual machine identified by VMID1—c).
If, at step 380, method 300 determines that there are no more VMs modeled as part of the cloud-based application in application management server 110, then all application VMs are deployed and method 300 terminates.
As was previously mentioned, it is useful to associate the identifier for a virtual machine as generated by application management server 110 (i.e., the Application ID and/or VM ID1) with the identifier generated by VM management server 130 for the same virtual machine when the virtual machine is deployed to the cloud (i.e., VM ID2). One benefit is the ability to track the progress of deployment of virtual machines directly from application management server 110. Another benefit is the ability to access an already-deployed virtual machine at a time well after its deployment in order to update or install new software on the virtual machine. However, when a virtual machine is scaled up or scaled down by a system administrator, the association between the Application ID and VM ID1 (as generated by application management server 110) with VM ID2 (as generated by VM management server 130) may be broken.
After a virtual machine is deployed to a cloud infrastructure (such as VM management server 130), a system administrator may perform “scaling” on the virtual machine. Scaling a virtual machine refers to dynamically changing system parameters (such as the amount of available RAM, the number of available CPUs, and the like) of the virtual machine. A virtual machine may be scaled up or down using system administration tools that are operated independently of application management server 110. For example, a system administrator may perform administration tasks on cloud-based virtual machines using the VSphere suite of administration tools, which is commercially available from VMware, Inc. Typically, scaling a cloud-based virtual machine entails allocating a new virtual machine in the cloud with the required scaled up (or scaled down) parameters, copying the runtime state and data of the existing virtual machine to the newly scaled virtual machine, instantiating and starting the newly scaled virtual machine, and destroying (or deallocating) the previously existing virtual machine. In this way, the newly scaled virtual machine replaces the previously existing virtual machine.
However, if the previously existing virtual machine had been deployed to the cloud through application management server 110, then the association between the identifiers generated by application management server 110 (Application ID and VM ID1) and the identifier generated by VM management server 130 (VM ID2) is broken. The reason for this is due to the fact that when VM management server 130 creates the newly scaled virtual machine, a new VM ID2 is generated in the process. It should be noted that the VM ID2 of the previously existing virtual machine is not copied to or associated with the newly scaled virtual machine. In addition, once the newly scaled virtual machine is started, the previously existing virtual machine is destroyed, along with the metadata for that virtual machine. Thus, the VM ID2 of the previously existing virtual machine no longer refers to an existing virtual machine.
Nonetheless, the application ID and VM ID1 of the previously existing virtual machine is stored persistently, in embodiments, in table 230 of IaaS 120, as well as in table 225 of application management server 110. Thus, application management server 110 maintains a unique handle to the applications and corresponding virtual machines that have been previously modeled and deployed. Therefore, it is possible to establish an association between the Application ID and VM ID1 of the virtual machines modeled in application management server 110 after such virtual machines are scaled up or down independently of application management server 110 (for example, when those virtual machines are newly scaled using VSphere administration tools).
FIG. 5 is a flow diagram of a method 500 of scaling up a virtual machine in a cloud-based computing environment, according to one or more embodiments. FIG. 5 will be described in conjunction with FIG. 6, which is a block diagram that illustrates conceptually the scaling up of a virtual machine in a cloud-based computing environment. As shown in FIG. 6, VM 1401 is a virtual machine instantiated in VM management server 130 as a result of a previous deployment of an application (identified in application management server 110 and IaaS 120 by application ID AppID1) with one virtual machine (identified in application management server 110 and IaaS 120 by VM ID1 VMID1—a). At the time VM management server 130 instantiates VM 1401, VM management server 130 generates VMID2—a and associates this identifier with VM 1401. Method 500 begins at step 510, where a request to scale up a virtual machine is received. As shown in FIG. 6, scaling request 610 is received by VM cloud administrator 600. VM cloud administrator 600 may, in embodiments, comprise the vSphere® suite of administration tools available from VMware, Inc. In embodiments, request 610 is transmitted to VM cloud administrator 600 by a system administrator through, for example, a system console.
Method 500 then proceeds to step 520, where, in response to the scaling request, a newly scaled up virtual machine is instantiated in the cloud. This is illustrated in FIG. 6 by the creation (by VM cloud administrator 600 communicating with VM management server 130) of a new virtual machine VM 1402. In embodiments, VM 1402 is created with scaled up system parameters in relation to previously instantiated and deployed VM 1401. The dotted outline of VM 1402 denotes that VM 1402 is newly created. It should be noted that when VM 1402 is created, VM management server 130 generates VMID2—b, which is different from VMID2—a of VM 1401.
Next, at step 530, the data of VM 1401 is copied to VM 1402. As shown in FIG. 6, this includes the metadata items AppID1 and VMID1—a. However, VMID2—a is not copied to or associated with VM 1402.
Once the data (and metadata) of VM 1401 are copied to VM 1402, method 500 proceeds to step 540. At step 540, the application ID and VM ID1 of the previously existing virtual machine are associated with VM ID2 of the newly scaled up VM. With reference to the embodiment illustrated in FIG. 6, this association is performed via VM management server 130 communicating VMID2—b to IaaS 120. In response, IaaS 120 (which, prior to the scaling up of VM 1401, stored AppID1, VMID1—a, and VMID2—a as associated data elements in table 230), stores VMID2—bin the entry of table 230 corresponding to AppID1 and VMID1—a. This is shown conceptually in FIG. 6 by arrow 620. In addition, VM 1402 is depicted in FIG. 6 as being grouped within VM management server 130 as part of application 150, which, as previously mentioned, corresponds to the application identified in application management server 110 by AppID1.
Once the application ID and VM ID1 of the previously existing virtual machine (e.g., AppID1 and VMID1—a in FIG. 6) is associated with the VM ID2 of the newly scaled virtual machine (e.g., VMID2—b in FIG. 6), method 500 proceeds to step 550, where the previously existing virtual machine (i.e., VM 1401) is deallocated. After step 550, method 500 terminates.
In addition to scaling up (or down) an individual virtual machine within a cloud-based application, cloud-based applications may be “scaled in” or “scaled out.” Scaling in a cloud-based application refers to removing some virtual machines from the application while continuing to execute the application within the cloud. Scaling out a cloud-based application refers to adding virtual machines to the application while the application executes in the cloud. While scaling up and scaling down a virtual machine is typically performed by accessing a system administration tool that is independent of application management server 110 (such as VM cloud administrator 600), scaling a cloud-based application either in or out is performed by a management user (such as management user 160 of FIG. 1) that accesses application management server 110.
FIG. 7 is a flow diagram that illustrates a method 700 for scaling out a virtualized cloud-based application, according to one or more embodiments. FIG. 7 is described herein in conjunction with FIG. 8, which is a block diagram that depicts the scaling out of a single-VM cloud-based application to a dual-VM cloud-based application. Referring to FIG. 8, management user 160 accesses application management server 110, which has modeled therein a single-VM application previously deployed to VM management server 130. The deployed application is identified by application ID AppID1 and the first VM is identified by VMID1—a. As shown in FIG. 8, table 230 of IaaS 120 associates AppID1 and VMID1—a with VMID2—a, which is the VM ID2 of previously deployed virtual machine VM 1401.
Method 700 begins at step 710, where application management server 110 receives a request to scale out the application identified in FIG. 8 by AppID1. In the embodiment illustrated, the scale out request is for the addition of one virtual machine to the cloud-based application. However, any number of virtual machines may be added in a single request. Further, as previously mentioned, such a request is received, in embodiments, from management user 160.
Next, at step 720, application management server 110 generates a new VM ID1 for the newly requested virtual machine. As shown in FIG. 8, application management server 110 generates VMID1—b for the new virtual machine, which corresponds to AppID1. At step 730, the new virtual machine is deployed to the cloud. As was previously mentioned with respect to FIG. 3, in one or more embodiments, application management server 110 transmits a deployment request for a virtual machine to IaaS 120, which, in turn, transmits a request to VM management server 130 (i.e., the cloud infrastructure). Referring to FIG. 8, after application management server 110 transmits the deployment request for the second virtual machine (i.e., the virtual machine identified by VMID1—b) to IaaS 120, IaaS 120 stores AppID1 and VMID1—b as associated data elements in table 230. In addition, IaaS 120 transmits a request to VM management server 130 to instantiate the new virtual machine the cloud.
In response to the request from IaaS 120, VM management server 130 instantiates VM 1402, generating VMID2—b in the process. Note that AppID1 and VMID1—b are included in the metadata of newly instantiated VM 1402.
Once the second virtual machine (i.e., VM 1402) is instantiated in the cloud, method 700 proceeds to step 740. At step 740, IaaS 120 receives from VM management server 130 VMID2—b of newly instantiated VM 1402. Finally, at step 750, IaaS 120 associates AppID1 and VMID1—b (which are both generated by application management server 110) with VMID2—b (which is generated by VM management server 130). Referring to FIG. 8, IaaS 120 makes this association by storing VMID2—b in the entry of table 230 that associates AppID1 with VMID1—b. Thus, once the association is made at step 750, management user 160 may access VM 1402 from application management server 110. This is useful should management user 160 wish to install software on VM 1402 from application management server 110 at a later point in time.
Although one or more embodiments have been described herein in some detail for clarity of understanding, it should be recognized that certain changes and modifications may be made without departing from the spirit of the disclosure. The various embodiments described herein may employ various computer-implemented operations involving data stored in computer systems. For example, these operations may require physical manipulation of physical quantities—usually, though not necessarily, these quantities may take the form of electrical or magnetic signals, where they or representations of them are capable of being stored, transferred, combined, compared, or otherwise manipulated. Further, such manipulations are often referred to in terms, such as producing, yielding, identifying, determining, or comparing. Any operations described herein that form part of one or more embodiments of the disclosure may be useful machine operations. In addition, one or more embodiments of the disclosure also relate to a device or an apparatus for performing these operations. The apparatus may be specially constructed for specific required purposes, or it may be a general purpose computer selectively activated or configured by a computer program stored in the computer. In particular, various general purpose machines may be used with computer programs written in accordance with the teachings herein, or it may be more convenient to construct a more specialized apparatus to perform the required operations.
The various embodiments described herein may be practiced with other computer system configurations including hand-held devices, microprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like.
One or more embodiments of the present disclosure may be implemented as one or more computer programs or as one or more computer program modules embodied in one or more computer readable media. The term computer readable medium refers to any data storage device that can store data which can thereafter be input to a computer system—computer readable media may be based on any existing or subsequently developed technology for embodying computer programs in a manner that enables them to be read by a computer. Examples of a computer readable medium include a hard drive, network attached storage (NAS), read-only memory, random-access memory (e.g., a flash memory device), a CD (Compact Discs)—CD-ROM, a CD-R, or a CD-RW, a DVD (Digital Versatile Disc), a magnetic tape, and other optical and non-optical data storage devices. The computer readable medium can also be distributed over a network coupled computer system so that the computer readable code is stored and executed in a distributed fashion.
Although one or more embodiments of the present disclosure have been described in some detail for clarity of understanding, it will be apparent that certain changes and modifications may be made within the scope of the claims. Accordingly, the described embodiments are to be considered as illustrative and not restrictive, and the scope of the claims is not to be limited to details given herein, but may be modified within the scope and equivalents of the claims. In the claims, elements and/or steps do not imply any particular order of operation, unless explicitly stated in the claims.
Many variations, modifications, additions, and improvements are possible. Plural instances may be provided for components, operations or structures described herein as a single instance. Boundaries between various components, operations and data stores are somewhat arbitrary, and particular operations are illustrated in the context of specific illustrative configurations. Other allocations of functionality are envisioned and may fall within the scope of the disclosure(s). In general, structures and functionality presented as separate components in exemplary configurations may be implemented as a combined structure or component. Similarly, structures and functionality presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements may fall within the scope of the appended claim(s).
Patent Application
20150347170
