Managing service availability in a mega virtual machine

TECHNICAL FIELD

0001Particular embodiments relate generally to virtual machines and more particularly to managing service availability in a mega virtual machine.

BACKGROUND

0002A virtual machine (VM) may refer to a software implementation of a computer or other machine that runs programs. A virtual machine may be deployed in a cloud computing environment in which hardware resources may be distributed over a network, such as the Internet. The hardware resources in the cloud computing environment can be allocated to services that the cloud provides to users over the network. Examples of services that can be provided in a cloud computing environment include Software as a Service (SaaS), Infrastructure as a Service (IaaS), and Platform as a Service (PaaS).

SUMMARY

0003According to some embodiments, a virtual machine manager is operable to manage a virtual machine (VM) that spans a plurality of hardware appliances. The virtual machine manager receives a request to provide a service to a device, selects an application instance to provide the service to the device, and forwards the request for the service to the selected application instance. The selected application instance is running in an instance of the virtual machine associated with a first hardware appliance. The virtual machine manager determines session data associated with the service and provides the session data associated with the service to a second hardware appliance of the VM in order to enable the VM to provide high availability of the service to the device.

0004In some embodiments, a hardware appliance in communication with a virtual machine (VM) includes one or more processors and memory. The memory contains instructions executable by the processor, whereby the hardware appliance is operable to receive a request for a service from the VM and to provide the service to a device. The VM spans a plurality of hardware appliances, including the hardware appliance and a second hardware appliance. The hardware appliance provides session data associated with the service to a VM manager on behalf of the VM. The hardware appliance receives session data associated with services running in the second hardware appliance from the VM manager in order to enable the VM to provide high availability of services to devices.

BRIEF DESCRIPTION OF THE DRAWINGS

0005For a more complete understanding of the present invention and its features and advantages, reference is now made to the following description, taken in conjunction with the accompanying drawings, in which:

0006<figref idref="DRAWINGS">FIG. 1A</figref> is a block diagram illustrating an example embodiment of a system;

0007<figref idref="DRAWINGS">FIG. 1B</figref> is a block diagram illustrating an example embodiment of a virtual machine manager;

0008<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram illustrating an example embodiment of a system;

0009<figref idref="DRAWINGS">FIGS. 3-5</figref> are signaling diagrams illustrating an exchange of signals in example embodiments of the system;

0010<figref idref="DRAWINGS">FIGS. 6-8</figref> are flow diagrams illustrating example embodiments of steps that may be performed in the system; and

0011<figref idref="DRAWINGS">FIG. 9</figref> is a block diagram illustrating an example embodiment of a hardware appliance.

DETAILED DESCRIPTION

0012A virtual machine (VM) may refer to a software implementation of a computer or other machine that runs programs. The virtual machine may run on top of a hypervisor that may provide a specialized operating system for allocating processors, memory, and/or other physical hardware resources to the virtual machine as virtual hardware resources. Each underlying hardware appliance may support one or more virtual machines at a given time. For example, one or several virtual machines may be deployed on one hardware appliance. Or, one virtual machine may span several hardware appliances (e.g., a mega virtual machine (MVM)). A virtual machine may be deployed in a cloud computing environment in which the hardware resources may be distributed over a network, such as the Internet.

0013A goal of virtual machine design may be to provide high availability, which may prevent a single point of failure in software and hardware. Thus, if a failure occurs, high availability may allow for recovery to be completed with minimal downtime. However, existing approaches to virtual machine design fail to provide high availability (e.g., telecom grade high availability) at the service level. For example, if a hardware appliance becomes unavailable or if a virtual machine crashes, existing approaches may restart the virtual machine on a new hardware appliance using a stored backup configuration. Restarting the virtual machine may require several minutes of downtime during which services that were running on the failed hardware or failed virtual machine may remain unavailable. In addition, in existing approaches, the session data that was being used prior to the failure is not available on the new virtual machine on another hardware appliance (even after the same application instance is launched).

0014In an attempt to minimize downtime, certain existing approaches may include fault tolerance (FT) techniques. A fault tolerance technique may enable virtual machines to run in lockstep mode such that a standby virtual machine can take over the operations of a failed virtual machine. A problem with fault tolerance is that it requires a complete mirroring (copy) of the virtual machine which requires significant additional capacity both in terms of signaling overhead (to send configuration information between the primary and standby virtual machines) and resource capacity (to duplicate the primary virtual machine in the standby virtual machine). Furthermore, fault tolerance does not protect against faults at the service level because errors on the primary virtual machine are copied to the standby virtual machine.

0015Particular embodiments may provide a solution to these and other problems. For example, in some embodiments, session data associated with a service provided by a first hardware appliance may be replicated in a second hardware appliance under the same MVM. If a failure occurs in the first hardware appliance, the second hardware appliance may use the session data to recover the service thereby providing high availability at the service level. Particular embodiments are described in <figref idref="DRAWINGS">FIGS. 1-9</figref> of the drawings, like numerals being used for like and corresponding parts of the various drawings.

0016<figref idref="DRAWINGS">FIG. 1A</figref> illustrates an example of a system (e.g., a datacenter) that includes a virtual machine <b>105</b> spanning a plurality of hardware appliances <b>115</b>A, <b>115</b>B, and <b>115</b>C. In some embodiments, virtual machine <b>105</b> may be referred to as a mega container or a mega virtual machine (MVM). The system also includes a virtual machine manager <b>120</b>, such as one or more hypervisors spanning hardware appliances <b>115</b> associated with virtual machine <b>105</b>. The system may provide services <b>110</b> to devices, such as mobile phones, smart phones, personal digital assistants (PDAs), computers (e.g., desktop computers, laptop computers, tablet computers, servers, etc.), machine to machine (M2M) devices, and so on. As used in the present disclosure, examples of services may include any suitable services and/or applications that virtual machine <b>105</b> provides to device, such as services/applications provided in a cloud computing environment. Examples may include, but are not limited to, social networking applications, search engine applications, phone or video conference applications, and so on. In general, virtual machine <b>105</b> may provide services <b>110</b> to devices and virtual machine manager <b>120</b> may route traffic within virtual machine <b>105</b> and distribute session data <b>112</b> to provide high availability as described in more detail with respect to the examples below.

0017In some embodiments, a user may send a request for a particular service, such as service <b>110</b>A, via the user's device. As an example, service <b>110</b>A may display the user's social networking profile. The system may receive the request at virtual machine manager <b>120</b>. Virtual machine manager <b>120</b> may select an application instance of virtual machine <b>105</b> to provide service <b>110</b>A to the device. In the example, the application instance may correspond to an instance of the social networking site running in virtual machine <b>105</b>. The application instance (e.g., the social networking site) may provide the requested service (e.g., display the user's social networking profile).

0018In some embodiments, virtual machine manager <b>120</b> may select the application instance based on the current traffic load. For example, virtual machine manager <b>120</b> may select an application instance if the load associated with the application instance is relatively low. As an example, an application instance may have an associated capacity, such as 100 calls. If a first application instance is handling 10 calls and a second application instance is handling 90 calls, virtual machine manager <b>120</b> may select the first application instance to provide the requested service <b>110</b>A. Or, as another example, virtual machine manager <b>120</b> may select the application instance based on the current traffic load of an underlying hardware appliance <b>115</b>. If a first application instance is running on a lightly loaded hardware appliance <b>115</b> and a second application instance is running on a heavily loaded hardware appliance <b>115</b>, virtual machine manager <b>120</b> may select the first application instance to provide service <b>110</b>A. Thus, in some embodiments, virtual machine manager <b>120</b> may act as a load balancer to route traffic within virtual machine <b>105</b>.

0019Virtual machine manager <b>120</b> may send a request to use the selected application instance to provide service <b>110</b>A to the device (e.g., so that the device can use the service provided by the application instance). In some embodiments, virtual machine manager <b>120</b> may send the request to the selected application instance via first hardware appliance <b>115</b>A. The selected application instance may provide service <b>110</b>A and may create or update session data <b>112</b>A associated with service <b>110</b>A to the device. In some embodiments, session data <b>112</b>A may include service level data related to the use of service <b>110</b>A. In some embodiments, session data <b>112</b>A may include user content used within the service, such as one or more of text, drawings, photographs, video, audio, messages, and user files (e.g., word processing files, slide presentations, spreadsheets, etc.). As an example, if the user uses service <b>110</b>A to upload a photograph to the user's social networking profile, the photograph may be included in session data <b>112</b>A. As another example, if the user requests a communications service, such as a video conference, session data <b>112</b> may include user identifiers associated with the participants in the video conference.

0020In some embodiments, the selected application instance stores session data <b>112</b>A in its cache. Virtual machine <b>105</b> manages this cache so that when session data <b>112</b>A is created and stored, virtual machine <b>105</b> is notified. This may be a trigger for VM <b>105</b> to send a request to virtual machine manager <b>120</b> to duplicate session data <b>120</b> to the other hardware appliances <b>115</b> under the same VM <b>105</b>. Virtual machine <b>105</b> may provide session data <b>112</b>A to virtual machine manager <b>120</b> through first hardware appliance <b>115</b>A (the underlying hardware appliance for the selected application instance). Virtual machine manager <b>120</b> may receive the session data <b>112</b>A according to any suitable model, such as a sub-notify model, a broadcast model, or a multicast model.

0021Virtual machine manager <b>120</b> may replicate session data <b>112</b>A associated with service <b>110</b>A across one or more other hardware appliances <b>115</b> of virtual machine <b>105</b>. For example, virtual machine manager <b>120</b> may replicate session data <b>112</b>A to a second hardware appliance <b>115</b>B and/or a third hardware appliance <b>115</b>C. Replicating session data <b>112</b>A to other hardware appliances <b>115</b> may facilitate recovering a failure associated with first hardware appliance <b>115</b>A. For example, if service <b>110</b>A fails on first hardware appliance <b>115</b>A (e.g., due to a failure at the service level, the VM level, or the hardware appliance level), one of the other hardware appliances <b>115</b> may resume service <b>110</b>A using the replicated session data <b>112</b>A.

0022Certain examples described throughout the disclosure may refer to communications that virtual machine manager <b>120</b> has with or via a hardware appliance <b>115</b>. In general, such communications may refer to communications between virtual machine manager <b>120</b> and an instance of virtual machine <b>105</b> that runs on the particular hardware appliance <b>115</b>. In some embodiments, virtual machine manager <b>120</b> determines which VM instance to communicate with based on virtual machine manager <b>120</b>'s knowledge of the mapping between the VM instance and the underlying hardware appliance <b>105</b> for that VM instance.

0023<figref idref="DRAWINGS">FIG. 1B</figref> illustrates an embodiment of virtual machine manager <b>120</b>. Virtual machine manager <b>120</b> may include a communication module <b>130</b>, a traffic management module <b>140</b>, and a session data management module <b>150</b>. Communication module <b>130</b> may send and receive communications between virtual machine manager <b>120</b> and hardware appliances <b>115</b>. Communication module <b>130</b> may also send and receive communications between virtual machine manager <b>120</b> and devices to which virtual machine <b>105</b> provides services.

0024Traffic management module <b>140</b> may allocate services <b>110</b> to application instances associated with hardware appliances <b>115</b>, for example, based on traffic load. The capacity of the application instance could depend on the service design. For instance, one application instance may be able to handle one request at time and another application instance may be able to handle multiple requests, such as 10 requests at a time. Traffic management module <b>140</b> may monitor traffic at the application instance level, the VM level, and/or the hardware appliance level in order to assess the traffic load and select resources available to provide service <b>110</b>. Traffic management module <b>140</b> may allocate new requests for services <b>110</b>. Traffic management module <b>140</b> may also allocate existing services <b>110</b> (e.g., services that are serving devices), for example, during recovery of a failure. As an example, if hardware appliance <b>115</b>A becomes unavailable, traffic management module <b>140</b> may move a service <b>110</b> that was running on hardware appliance <b>115</b>A to an available application instance (such as an application instance on hardware appliance <b>115</b>B). In some embodiments, traffic management module <b>140</b> may determine to add a new hardware appliance <b>115</b> to virtual machine <b>105</b> if the current hardware appliances <b>115</b> are becoming overloaded or for any other suitable reason.

0025Session data management module <b>150</b> may make decisions as to when and where to replicate session data <b>112</b> associated with service <b>110</b>. Session data <b>112</b> may allow for recovering a failure associated with one hardware appliance <b>115</b>A by resuming a failed service <b>110</b> at another hardware appliance <b>115</b>B using the replicated session data <b>112</b>. Session data management module <b>150</b> may determine to replicate the session data <b>112</b> at any suitable time, such as when service <b>110</b> has been setup (e.g., in response to receiving session data <b>112</b> from the application instance/hardware appliance <b>115</b> providing service <b>110</b> to the device), when a new hardware appliance <b>115</b> has been added to virtual machine <b>105</b>, and/or on a periodic basis. Session data <b>112</b> is replicated at the virtual machine level.

0026In some embodiments, communications module <b>130</b> receives a request to provide a service <b>110</b> to a device. For example, communications module <b>130</b> may receive the request initiated from the device itself or from a network component that would like to page the device or push data to the device. Communication module <b>130</b> may send the request to traffic management module <b>140</b>, and traffic management module <b>140</b> may select an application instance of virtual machine <b>105</b> to provide service <b>110</b> to the device. Communication module <b>130</b> forwards the request for service <b>110</b> to the selected application instance via the underlying hardware appliance <b>115</b> (e.g., first hardware appliance <b>115</b>A associated with the selected application instance).

0027Communication module <b>130</b> may also obtain session data <b>112</b> associated with service <b>110</b> in order to handle the replication of session data <b>112</b> throughout the other hardware appliances <b>115</b> of virtual machine <b>105</b>. Communication module <b>130</b> may obtain session data <b>112</b> in any suitable manner. As an example, the virtual machine running on the first hardware appliance <b>115</b>A may send session data <b>112</b> to communication module <b>130</b> of virtual machine manager <b>120</b> according to a sub-notify model, a broadcast model, a multicast model, or other suitable model. Or, session data management module <b>150</b> may instruct communication module <b>130</b> to read session data <b>112</b> from first hardware appliance <b>115</b>A through virtual machine <b>105</b> according to the identity of the application instance. Session data management module <b>150</b> may locate one or more other hardware appliances <b>115</b> of virtual machine <b>105</b> to send session data <b>112</b> associated with service <b>110</b>. Session data management module <b>150</b> may determine to send session data <b>112</b> to some or all of the other hardware appliances <b>115</b>.

0028In some embodiments, session data management module <b>150</b> may communicate with traffic management module <b>140</b> to determine where to send session data <b>112</b>. For example, session data management module <b>150</b> may determine to send session data <b>112</b> to one or more hardware appliances <b>115</b> having a relatively low traffic load. Session data management module <b>150</b> may instruct communication module <b>130</b> to provide session data <b>112</b> associated with service <b>110</b> to the one or more other hardware appliances <b>115</b> in order to enable virtual machine <b>105</b> to provide high availability of service <b>110</b> to the device.

0029<figref idref="DRAWINGS">FIG. 2</figref> illustrates an example in which hardware appliances <b>115</b> support multiple virtual machines <b>105</b>. In the illustrated example, virtual machine <b>105</b>A spans hardware appliances <b>115</b>A, <b>115</b>B, and <b>115</b>C, virtual machine <b>105</b>B spans hardware appliances <b>115</b>A and <b>115</b>C, and virtual machine <b>105</b>C spans hardware appliances <b>115</b>A and <b>115</b>B. Thus, virtual machines <b>105</b>A, <b>105</b>B, and <b>105</b>C each correspond to separate/distinct virtual machine containers.

0030Virtual machine <b>105</b>A provides application instances <b>111</b>A, <b>111</b>B, and <b>111</b>C (each corresponding to App<b>1</b>) and application instance <b>111</b>D (App<b>2</b>). Application instances <b>111</b>A, <b>111</b>B, and <b>111</b>C may form an application instance pool for App<b>1</b>. Thus, if a device requests App<b>1</b>, any one of application instances <b>111</b>A, <b>111</b>B, and <b>111</b>C may be selected to provide the service, for example, depending on traffic load. As an example, App<b>1</b> may correspond to a social networking site and App<b>2</b> may correspond to a video conference service. Application instances <b>111</b>A, <b>111</b>B, and <b>111</b>C may each provide an instance of the social networking site. Each instance may have an associated capacity (such as a certain number of users or call operations supported). Each application instance <b>111</b>A-D (e.g., App<b>1</b> and App<b>2</b>) may run on any hardware appliance <b>115</b> associated with virtual machine <b>105</b>A (e.g., hardware appliance <b>115</b>A, <b>115</b>B, or <b>115</b>C). Thus, instances <b>111</b>A-C of App<b>1</b> may be provided on the same or different hardware appliances associated with virtual machine <b>105</b>A. In some embodiments, session data <b>112</b> associated with services <b>110</b> provided by application instances <b>111</b>A-D is replicated to each hardware appliance of the same virtual machine <b>105</b>A. So, even if all of the instances of App<b>1</b> (e.g., instances <b>111</b>A-C) occur on the same hardware appliance (e.g., hardware appliance <b>115</b>A), the associated session data <b>112</b> may be replicated in hardware appliance <b>115</b>B and/or hardware appliance <b>115</b>C. This may allow virtual machine <b>105</b>A to provide high availability to App<b>1</b> services <b>110</b>, for example, in the event that hardware appliance <b>115</b>A fails.

0031In <figref idref="DRAWINGS">FIG. 2</figref>, virtual machine <b>105</b>B provides application instances <b>111</b>E and <b>111</b>F (the pool of application instances for App<b>3</b>) and application instances <b>111</b>G and <b>111</b>H (the pool of application instances for App<b>4</b>). Each application instance <b>111</b>E-<b>111</b>H may run on any hardware appliance <b>115</b> associated with virtual machine <b>105</b>B (e.g., hardware appliance <b>115</b>A or <b>115</b>C). Virtual machine <b>105</b>C provides application instances <b>111</b>I and <b>111</b>J (the pool of application instances for App<b>5</b>) and application instances <b>111</b>K and <b>111</b>L (the pool of application instances for App<b>6</b>). Each application instance <b>111</b>I-<b>111</b>L may run on any hardware appliance <b>115</b> associated with virtual machine <b>105</b>C (e.g., hardware appliance <b>115</b>A or <b>115</b>B).

0032<figref idref="DRAWINGS">FIG. 3</figref> is an example of a signaling diagram illustrating an exchange of signals in example embodiments. <figref idref="DRAWINGS">FIG. 3</figref> illustrates an exchange of signals between a device, a virtual machine manager <b>120</b>, and a virtual machine <b>105</b> managed by virtual machine manager <b>120</b>. Virtual machine <b>105</b> spans a plurality of hardware appliances <b>115</b>(<i>a</i>) through <b>115</b>(<i>n</i>). At step <b>304</b>, the device requests a service <b>110</b> to be provided by virtual machine <b>105</b>. As an example, the device may request to setup a video conference call as service <b>110</b>. In some embodiments, the device may send the request to an address associated with the requested service <b>110</b> offered by an application instance <b>111</b> running in virtual machine <b>105</b>. The address may correspond to an IP address for service <b>110</b> published via the Internet. In some embodiments, requests to the address may be received at virtual machine manager <b>120</b>. For example, the request may first arrive at a firewall of the data center (or cloud center) then proceed to virtual machine manager <b>120</b> which may act as a load balancer to route traffic throughout VM <b>105</b>. Thus, at step <b>308</b>, virtual machine manager <b>120</b> receives the request to provide service <b>110</b>. Receiving the request at virtual machine manager <b>120</b> allows virtual machine manager <b>120</b> to route the request to the application instance <b>111</b> that virtual machine manager <b>120</b> selects to fulfill the request to provide the service to the device.

0033At step <b>312</b>, virtual machine manager <b>120</b> selects an application instance <b>111</b> to provide service <b>110</b> to the device. In the example, application instance <b>111</b> may correspond to a video conference service that can provide the requested service (the video conference call) to the device. The selected application instance <b>111</b> may be running in an instance of virtual machine <b>105</b> associated with a first hardware appliance, such as first hardware appliance <b>115</b>(<i>a</i>) of virtual machine <b>105</b>. In some embodiments, virtual machine manager <b>120</b> selects which application instance <b>111</b> should provide service <b>110</b> based on traffic load as discussed with respect to traffic management module <b>140</b> of <figref idref="DRAWINGS">FIG. 1B</figref>.

0034Virtual machine manager <b>120</b> forwards the request for service <b>110</b> to the selected application instance <b>111</b> at step <b>316</b>. The request may be communicated to the selected application instance <b>111</b> through hardware appliance <b>115</b>(<i>a</i>) associated with the selected application instances (as described in <figref idref="DRAWINGS">FIG. 4</figref> below). At step <b>320</b>, hardware appliance <b>115</b>(<i>a</i>) receives the request for service <b>110</b> to be provided from VM <b>105</b> to the device.

0035At step <b>324</b>, the selected application instance <b>111</b> provides service <b>110</b> to the device. While providing service <b>110</b>, application instance <b>111</b> may create or update session data <b>112</b> associated with service <b>110</b>. In some embodiments, session data <b>112</b> may include service level data related to the use of service <b>110</b>. As an example, in a communications service, such as the video conference call requested for service <b>110</b> in the example, session data <b>112</b> may include user identifiers associated with the participants in the video conference. If the video conference call supports multi-media functionality, session data <b>112</b> could also include user content exchanged within the video conference call, such as one or more of text, drawings, photographs, video, audio, messages, and user files (e.g., word processing files, slide presentations, spreadsheets, etc.). At step <b>328</b>, VM <b>105</b> provides session data <b>112</b> associated with service <b>110</b> to VM manager <b>120</b>. VM <b>105</b> provides session data <b>112</b> through its hardware appliance <b>115</b>(<i>a</i>), which is the underlying hardware appliance for the selected application instance <b>111</b> that provides service <b>110</b>. Session data <b>112</b> may be provided according to any suitable model, such as a sub-notify model, a broadcast model, or a multicast model.

0036Virtual machine manager <b>120</b> determines session data <b>112</b> associated with service <b>110</b> at step <b>332</b>. Virtual machine may determine session data <b>112</b> in any suitable manner. Thus, determining the session data could include one or more of reading, obtaining, and/or receiving the session data. For example, virtual machine manager <b>120</b> may determine session data <b>112</b> from a message provided by hardware appliance <b>115</b>(<i>a</i>) at step <b>328</b>. Or, in some embodiments, virtual machine manager <b>120</b> may read session data <b>112</b> from hardware appliance <b>115</b>(<i>a</i>). In some embodiments, virtual machine manager <b>120</b> may determine the session data <b>112</b> by receiving a notification of the creation or update of session data <b>112</b> related to application instance <b>111</b> executing in the instance of virtual machine <b>105</b> that runs in first hardware appliance <b>115</b>(<i>a</i>). Virtual machine <b>120</b> may determine session data <b>112</b> from or in response to receiving a request to replicate session data <b>112</b> associated with service <b>110</b> from one hardware appliance (<b>115</b>(<i>a</i>)) to the other hardware appliances (<b>115</b> (<i>b</i>)-(<i>n</i>)) under the same virtual machine <b>105</b>.

0037At step <b>336</b>, virtual machine manager may provide service <b>110</b>'s session data <b>112</b> (such as the user identifiers of participants in the video conference call) to a second hardware appliance <b>115</b>(<i>n</i>) of the VM in order to enable the VM to provide high availability of service <b>110</b> to the device. For example, if any of application instance <b>111</b>, a virtual machine instance running on hardware appliance <b>115</b>(<i>a</i>), or hardware appliance <b>115</b>(<i>a</i>) itself fails/becomes unavailable, a second application instance associated with second hardware appliance <b>115</b>(<i>n</i>) may resume service <b>110</b> using session data <b>112</b> previously received by hardware appliance <b>115</b>(<i>n</i>) at step <b>336</b>. In some embodiments, virtual machine <b>105</b> may include other hardware appliances <b>115</b> in addition to the first hardware appliance <b>115</b>(<i>a</i>) and the second hardware appliance <b>115</b>(<i>n</i>), and at step <b>336</b> virtual machine manager <b>120</b> also sends session data <b>112</b> to all of the other hardware appliances <b>115</b> (the remaining hardware appliances <b>115</b>).

0038With respect to failures at the service level, virtual machine manager <b>120</b> may determine that the selected application instance <b>111</b> has become unavailable to service <b>110</b> due to a failure at a service level and may select a second application instance <b>111</b> to provide service <b>110</b> to the device. If virtual machine <b>105</b> is fine (no failure at the VM level), service <b>110</b> can be recovered on the VM running on the same hardware appliance as before (<b>115</b>(<i>a</i>)) or the VM running on a different hardware appliance under the same virtual machine <b>105</b>, such as hardware appliance <b>115</b>(<i>n</i>). The selection may be made based on traffic load and based on the underlying hardware appliance <b>115</b>(<i>n</i>) having previously received session data <b>112</b> associated with service <b>110</b>. Virtual machine manager <b>120</b> may then request the second application instance <b>111</b> to provide service <b>110</b> to the device. A more detailed example of handling a failure at the application instance level is described with respect to <figref idref="DRAWINGS">FIG. 6</figref> below.

0039With respect to a failure at the VM level, virtual machine manager <b>120</b> may be further operable to determine that the first hardware appliance <b>115</b>(<i>a</i>) has become unavailable to a plurality of existing services (e.g., services that are serving devices, including service <b>110</b>) due to a failure at the VM level. For each of the existing services, virtual machine manager <b>120</b> may select one of the plurality of hardware appliances <b>115</b> of VM <b>105</b> to provide the existing service based on traffic load and availability of session data <b>112</b> associated with the existing service at the selected hardware appliance <b>115</b>. A more detailed example of handling a failure at the VM level is described with respect to <figref idref="DRAWINGS">FIG. 6</figref> below.

0040With respect to a failure at the hardware appliance level, virtual machine manager <b>120</b> may be further operable to determine that the first hardware appliance <b>115</b>(<i>a</i>) has become unavailable to a plurality of existing services (e.g., services that are serving devices, including service <b>110</b>) due to a failure at the hardware appliance level. Virtual machine manager <b>120</b> may determine whether the plurality of existing services can be provided by one or more of the plurality of hardware appliances <b>115</b> of VM <b>105</b> other than first hardware appliance <b>115</b>(<i>a</i>). Upon a determination that the plurality of existing services cannot be provided by one or more of the plurality of hardware appliances <b>115</b> other than first hardware appliance <b>115</b>(<i>a</i>), virtual machine manager <b>120</b> may add a new hardware appliance <b>115</b> to VM <b>105</b>. Adding a new hardware appliance <b>115</b> may include providing session data <b>112</b> associated with service <b>110</b> (and any other existing service) to the new hardware appliance <b>115</b>. A more detailed example of handling a failure at the hardware appliance level is described with respect to <figref idref="DRAWINGS">FIG. 8</figref> below. A more detailed example of adding a new hardware appliance <b>115</b> is described with respect to <figref idref="DRAWINGS">FIG. 5</figref> below.

0041Returning to <figref idref="DRAWINGS">FIG. 3</figref>, at step <b>340</b> virtual machine manager <b>120</b> may send first hardware appliance <b>115</b>(<i>a</i>) session data <b>112</b> associated with other services running on other hardware appliances <b>115</b>, such as a second hardware appliance <b>115</b>(<i>n</i>) of virtual machine <b>105</b>. For example, virtual machine manager <b>120</b> may send session data <b>112</b> to first hardware appliance <b>115</b>(<i>a</i>) on a periodic basis (e.g., to synchronize session data <b>112</b> among all hardware appliances <b>115</b> of the same virtual machine <b>105</b>) or in response to receiving new/updated session data <b>112</b> from one or more of the other hardware appliances <b>115</b>.

0042At step <b>344</b>, first hardware appliance <b>115</b>(<i>a</i>) may receive session data <b>112</b> associated with other services running in the second hardware appliance <b>115</b>(<i>n</i>) from VM <b>105</b> (e.g., via virtual machine manager <b>120</b>). Thus, session data <b>112</b> associated with services <b>110</b> provided by VM <b>105</b> may be replicated to multiple (or all) hardware appliances <b>115</b> included within VM <b>105</b>. Replicating session data <b>112</b> in multiple (or all) hardware appliances <b>115</b> may enable VM <b>105</b> to provide high availability of services to devices. If the particular hardware appliance <b>115</b> supporting a service <b>110</b> becomes unavailable to the service <b>110</b>, another hardware appliance <b>115</b> may resume service <b>110</b> using the associated session data <b>112</b>. In some embodiments, service <b>110</b> may be resumed without incurring the downtime (e.g., several minutes) that may be required to restart a virtual machine and/or without incurring the penalties to signaling overheads and/or capacity that may be associated with fault tolerance techniques.

0043<figref idref="DRAWINGS">FIG. 4</figref> illustrates an example signal flow for handling session data in an MVM, such as a virtual machine <b>105</b> spanning a plurality of hardware appliances <b>115</b> (HWs). At step <b>1</b>, a device requests a service <b>110</b> (e.g., App). At step <b>2</b>, a virtual machine manager <b>120</b>, such as a hypervisor, receives the request and selects an application instance <b>111</b> to provide service <b>110</b> to the device. Application instance <b>111</b> may be selected from a pool of application instances in the MVM. In some embodiments, virtual machine manager <b>120</b> selects application instance <b>111</b> based on traffic load. For example, virtual machine manager <b>120</b> may select an application instance <b>111</b> that has a relatively low traffic load or virtual machine manager <b>120</b> may select an application instance <b>111</b> associated with a hardware appliance <b>115</b> of the MVM that has a relatively low traffic load. As an example, virtual machine manager <b>120</b> may select an application instance <b>111</b>A on HW<b>1</b> to provide service <b>110</b>.

0044At step <b>3</b>, virtual machine manager <b>120</b> sends a request to virtual machine <b>105</b> requesting that the selected application instance <b>111</b>A running on HW<b>1</b> provide service <b>110</b> to the device. In particular, virtual machine manager <b>120</b> may send the request to a VM instance running on HW<b>1</b> (a VM instance may refer to VM <b>105</b> running on a particular hardware appliance <b>115</b>). At step <b>4</b>, the VM instance on HW<b>1</b> forwards the request to the selected application instance <b>111</b>A to provide service <b>110</b> to the device. In the process of handling the request, application instance <b>111</b>A may create or update some session data <b>112</b> associated with service <b>110</b>. Session data <b>112</b> may be used for high availability (HA) at the service level by providing session data <b>112</b> to other hardware appliances <b>115</b> of the same MVM, such as HW<b>2</b> and/or HW<b>3</b>. For example, at step <b>5</b>, the selected application instance <b>111</b>A may communicate session data <b>112</b> to the VM instance running on HW<b>1</b>. At step <b>6</b>, the VM instance running on HW<b>1</b> updates session data <b>112</b>, for example, the session might be stored locally in HW<b>1</b>. At step <b>7</b>, the VM instance running on HW<b>1</b> communicates session data <b>112</b> to virtual machine manager <b>120</b>.

0045Virtual machine manager <b>120</b> may communicate with the virtual machine instances that run on different hardware appliances <b>115</b> under the same MVM to share session data <b>112</b> among some or all of the hardware appliances <b>115</b> in the MVM. Virtual machine manager <b>120</b> may determine which of the hardware appliances <b>115</b> to send session data <b>112</b> to at step <b>8</b>. As an example, virtual machine manager <b>120</b> may determine to send session data <b>112</b> to all of the other hardware appliances <b>115</b> in the MVM, such as HW<b>2</b> and HW<b>3</b> in the example. At step <b>9</b>, virtual machine manager <b>120</b> may send session data <b>112</b> to the VM instance running on HW<b>2</b>. The VM instance running on HW<b>2</b> may be responsible for storing session data <b>112</b> in persistent memory of HW<b>2</b>. At step <b>10</b>, the VM instance running on HW<b>2</b> may acknowledge successful receipt of session data <b>112</b>. At step <b>11</b>, virtual machine manager <b>120</b> may send session data <b>112</b> to the VM instance running on HW<b>3</b>. The VM instance running on HW<b>3</b> may be responsible for storing session data <b>112</b> in persistent memory of HW<b>3</b>. At step <b>12</b>, the VM instance running on HW<b>3</b> may acknowledge successful receipt of session data <b>112</b>.

0046At step <b>13</b>, virtual machine manager <b>120</b> may notify the VM instance running on HW<b>1</b> that the other hardware appliances <b>115</b> have received session data <b>112</b>. At step <b>14</b>, the VM instance running on HW<b>1</b> may notify the selected application instance <b>111</b>A that the other hardware appliances <b>115</b> have received session data <b>112</b>. At step <b>15</b>, selected application instance <b>111</b>A may send a response to the VM instance running on HW<b>1</b> indicating that it has received the notification that the other hardware appliances <b>115</b> have session data <b>112</b>. At step <b>16</b>, the VM instance running on HW<b>1</b> may send the response to virtual machine manager <b>120</b> and at step <b>17</b> virtual machine manager <b>120</b> may send the response to the device (e.g., on behalf of the selected application instance <b>111</b>A).

0047At step <b>18</b>, the device requests a service <b>110</b> from the same MVM. At step <b>19</b>, virtual machine manager <b>120</b> receives the request and selects one of the application instances <b>111</b> to provide service <b>110</b>. In some embodiments, virtual machine manager <b>120</b> selects application instance <b>111</b> based on traffic load. For example, virtual machine manager <b>120</b> may select an application instance <b>111</b> that has a relatively low traffic load or virtual machine manager <b>120</b> may select an application instance <b>111</b> associated with a hardware appliance <b>115</b> of the MVM that has a relatively low traffic load. As an example, virtual machine manager <b>120</b> may select an application instance <b>111</b>B on HW<b>2</b> to provide service <b>110</b>.

0048At step <b>20</b>, virtual machine manager <b>120</b> sends a request to virtual machine <b>105</b> requesting the selected application instance <b>111</b>B running on HW<b>2</b> to provide service <b>110</b> to the device. At step <b>21</b>, the VM instance running on HW<b>2</b> requests the selected application instance <b>111</b>B running on HW<b>2</b> to provide service <b>110</b> to the device. In the process of handling the request, application instance <b>111</b>B may create or update some session data <b>112</b> associated with service <b>110</b>. Session data <b>112</b> may be used for high availability (HA) at the service level by providing session data <b>112</b> to other hardware appliances <b>115</b> of the same MVM. For example, at step <b>22</b> selected application instance <b>111</b>B may communicate session data <b>112</b> to the VM instance running on HW<b>2</b>. At step <b>23</b>, the VM instance running on HW<b>2</b> may update session data <b>112</b>, for example, the session data may be stored locally in HW<b>2</b>. At step <b>24</b>, the VM instance running on HW<b>2</b> may communicate session data <b>112</b> to virtual machine manager <b>120</b>.

0049Virtual machine manager <b>120</b> may communicate with the virtual machine instances that run on different hardware appliances <b>115</b> under the same MVM to share session data <b>112</b> among some or all of the other hardware appliances <b>115</b> in the MVM. Virtual machine manager <b>120</b> may determine which of the hardware appliances <b>115</b> to send session data <b>112</b> to at step <b>25</b>. As an example, virtual machine manager <b>120</b> may determine to send session data <b>112</b> to all of the other hardware appliances <b>115</b> in the MVM, such as HW<b>1</b> and HW<b>3</b> in the example. At step <b>26</b>, virtual machine manager <b>120</b> may send session data <b>112</b> to the virtual machine instance running on HW<b>1</b>. The VM instance running on HW<b>1</b> may be responsible for storing session data <b>112</b> in persistent memory of HW<b>1</b>. At step <b>27</b>, virtual machine manager <b>120</b> may send session data <b>112</b> to the VM instance running on HW<b>3</b>, for example, so that session data <b>112</b> is available or accessible within this VM instance. The VM instance running on HW<b>3</b> may be responsible for storing session data <b>112</b> in persistent memory of HW<b>3</b>. At step <b>28</b>, the virtual machine instance running on HW<b>1</b> may acknowledge successful receipt of session data <b>112</b>. At step <b>29</b>, the virtual machine instance running on HW<b>3</b> may acknowledge successful receipt of session data <b>112</b>.

0050At step <b>30</b>, virtual machine manager <b>120</b> may notify the virtual machine instance running on HW<b>2</b> that the other hardware appliances <b>115</b> have received session data <b>112</b>. At step <b>31</b>, the virtual machine instance running on HW<b>2</b> may notify the selected application instance <b>111</b>B that the other hardware appliances <b>115</b> have received session data <b>112</b>. At step <b>32</b>, the selected application instance <b>111</b>B may send a response to the virtual machine instance running on HW<b>2</b> indicating that it has received the notification that the other hardware appliances <b>115</b> have session data <b>112</b>. At step <b>33</b>, the virtual machine instance running on HW<b>2</b> may send the response to virtual machine manager <b>120</b> and at step <b>34</b> virtual machine manager <b>120</b> may send the response to the device (e.g., on behalf of the selected application instance).

0051<figref idref="DRAWINGS">FIG. 5</figref> illustrates an example of a signal flow for adding new hardware to an existing virtual machine <b>105</b>. As an example, when the load on virtual machine <b>105</b> is approaching the maximum capacity of virtual machine <b>105</b>, a cloud management system (CMS) may determine to extend virtual machine <b>105</b> into a new hardware appliance <b>115</b> (e.g., HW<b>3</b> in <figref idref="DRAWINGS">FIG. 5</figref>). In response to the determination, the CMS may send a request to virtual machine manager <b>120</b> (e.g., a hypervisor) to extend virtual machine <b>105</b> at step <b>1</b>. At step <b>2</b>, virtual machine manager <b>120</b> may locate all the existing hardware appliances <b>115</b> for virtual machine <b>105</b>, such as HW<b>1</b> and HW<b>2</b>. At step <b>3</b>, virtual machine manager <b>120</b> adds HW<b>3</b> to a list of hardware appliances <b>115</b> under virtual machine <b>105</b>. At step <b>4</b>, virtual machine manager <b>120</b> retrieves an image file for virtual machine <b>105</b> and uses the image file to launch virtual machine <b>105</b> on HW<b>3</b> at step <b>5</b>. After virtual machine <b>105</b> has been successfully launched on HW<b>3</b>, virtual machine manager <b>120</b> is notified at step <b>6</b>. Virtual machine manager <b>120</b> proceeds to step <b>7</b> to synchronize/replicate session data <b>112</b> to HW<b>3</b>. Thus, the VM instance on HW<b>3</b> receives session data <b>112</b> associated with services <b>110</b> provided by other hardware appliances <b>115</b> under the same virtual machine <b>105</b> (e.g., HW<b>1</b> and HW<b>2</b>). Receiving session data <b>112</b> may prepare the VM instance on HW<b>3</b> to recover services <b>110</b> in the event of a failure. Thus, the VM instance on HW<b>3</b> may use session data <b>112</b> to provide high availability at the service level. At step <b>8</b>, the VM instance running on HW<b>3</b> notifies virtual machine manager <b>120</b> that session data <b>112</b> has been synchronized and at step <b>9</b> virtual machine manager <b>120</b> notifies CMS that HW<b>3</b> has been successfully added to virtual machine <b>105</b>.

0052Although the preceding example describes the CMS initiating the addition of a new hardware appliance <b>115</b>, in other embodiments virtual machine manager <b>120</b> may initiate adding the new hardware appliance <b>115</b> itself as described with respect to <figref idref="DRAWINGS">FIGS. 6-8</figref> below.

0053<figref idref="DRAWINGS">FIG. 6</figref> illustrates an example of a mechanism that may provide high availability in the event of a failure at the service level. At step <b>602</b>, virtual machine manager <b>120</b> may identify the crash of an application instance <b>111</b> in virtual machine <b>105</b>. For example, virtual machine manager <b>120</b> may identify the crash of application instance X(k). At step <b>604</b>, virtual machine manager <b>120</b> removes application instance X(k) from its routing table for that service type so that no new request will be sent to application instance X(k). Other instances of service X (e.g., service X(<b>1</b>), X(<b>2</b>), etc.) may remain in the routing table and may continue to run in virtual machine <b>105</b>. At step <b>606</b>, virtual machine manager <b>120</b> may retrieve the current traffic load from all the hardware appliances <b>115</b> under virtual machine <b>105</b>, such as HW<b>1</b>, HW<b>2</b>, . . . HW(N). Based upon the traffic optimization done across all hardware appliances <b>115</b> under the same virtual machine <b>105</b>, at step <b>608</b> virtual machine manager <b>120</b> may select the best hardware appliance <b>115</b> to launch the application instance again (if any).

0054If at step <b>610</b> virtual machine manager <b>120</b> succeeds in finding a hardware appliance <b>115</b> to launch application instance X(k), virtual machine manager <b>120</b> proceeds to step <b>614</b> to send an instruction to virtual machine <b>105</b> components running on that hardware appliance <b>115</b> to launch application instance X(k). If at step <b>610</b> virtual machine manager fails to find an available hardware appliance <b>115</b> under virtual machine <b>105</b>, virtual machine manager <b>120</b> may go to step <b>612</b> and start the procedure to extend virtual machine <b>105</b> into a new hardware appliance <b>115</b> (as described with respect to <figref idref="DRAWINGS">FIG. 5</figref>). Virtual machine manager <b>120</b> may then launch application instance X(k) on the new hardware appliance at step <b>614</b>. When application instance X(k) is ready to handle incoming requests, virtual machine manager <b>120</b> adds application instance X(k) into its routing table list at step <b>616</b>.

0055<figref idref="DRAWINGS">FIG. 7</figref> illustrates an example of a mechanism that may provide high availability in the event of a failure at the virtual machine level. At step <b>702</b>, virtual machine manager <b>120</b> may identify a crash of virtual machine <b>105</b>. As an example, virtual machine manager <b>120</b> may determine that a virtual machine instance VM(i) crashed on hardware appliance HW(i). In response, virtual machine manager <b>120</b> may remove virtual machine instance VM(i) from its routing table at step <b>704</b>. This may prevent new service/application requests from being sent to virtual machine instance VM(i) running on HW(i). Thus, all application instances <b>111</b> (and existing services <b>110</b>) under virtual machine instance VM(i) on HW(i) may not be accessible anymore. However, application instances for the same service running under the same virtual machine <b>105</b> but on the other physical hardware appliances <b>115</b> (HWs) may still be available and may take in new requests such that service may continue uninterrupted.

0056At step <b>706</b>, virtual machine manager <b>120</b> retrieves the current traffic load from all the HWs under the same virtual machine <b>105</b>. Based upon the traffic optimization done across all the HWs under the same virtual machine <b>105</b>, virtual machine manager <b>120</b> selects the best HW to launch the virtual machine at step <b>708</b>. Here the selected HW might be HW(i) which is the same one as used for the crashed virtual machine instance VM(i). Or, the selected HW might be a different HW. At step <b>710</b>, if virtual machine manager <b>120</b> succeeds in finding a HW within a list of HWs under the same virtual machine <b>105</b>, virtual machine manager <b>120</b> may send the instruction to launch virtual machine <b>105</b> on the selected HW at step <b>714</b>. If at step <b>710</b> virtual machine manager <b>120</b> fails to find available HW within the existing HWs under the same virtual machine <b>105</b>, at step <b>712</b> virtual machine manager <b>120</b> will start the procedure to add a new HW into virtual machine <b>105</b> (as described with respect to <figref idref="DRAWINGS">FIG. 5</figref> above). After launching virtual machine <b>105</b> successfully at step <b>714</b>, virtual machine manager <b>120</b> may proceed to step <b>716</b> to launch all the application instances in virtual machine <b>105</b> (e.g., the application instances affected by the crash of VM(i) on HW(i)). When the application instances are ready for handling incoming requests, virtual machine manager <b>120</b> may add these application instances into the routing table list.

0057<figref idref="DRAWINGS">FIG. 8</figref> illustrates an example of a mechanism that may provide high availability in the event of a failure at the hardware appliance level. At step <b>802</b>, virtual machine manager <b>120</b> may identify a crash of a hardware appliance <b>115</b>, such as HW(i). At step <b>804</b>, virtual machine manager <b>120</b> may remove HW(i) from its routing table so that no new service/application request will be sent to this crashed HW. Any service/application that used to run on HW(i) may become unavailable on HW(i). Similarly, any virtual machines <b>105</b> that used to run on HW(i) may become unavailable on HW(i). At step <b>806</b>, virtual machine manager <b>120</b> goes through a list of virtual machines <b>105</b> that were previously running on the crashed HW(i). At step <b>808</b>, for each virtual machine <b>105</b>, virtual machine manager <b>120</b> determines the load on all hardware appliances (HWs) that have been assigned to the virtual machine <b>105</b> (excluding the crashed HW(i)). At step <b>810</b>, virtual machine manager <b>120</b> selects a potential HW candidate for each virtual machine <b>105</b> based upon the outcome of traffic optimization within the list of HWs that have been assigned to that virtual machine <b>105</b>. The crashed HW(i) may not be included as a candidate (as indicated in <figref idref="DRAWINGS">FIG. 8</figref>).

0058If at step <b>812</b> virtual machine manager <b>120</b> fails to find available HW from the list of the involved HWs, it may request to add a new HW into the corresponding virtual machine <b>105</b> at step <b>814</b>. Example steps for adding a new HW were discussed with respect to <figref idref="DRAWINGS">FIG. 5</figref> above. At step <b>816</b>, virtual machine manager <b>120</b> launches virtual machine <b>105</b> on the HW selected at step <b>810</b> (if any) or on the HW added at step <b>814</b> (if no HW was selected at step <b>810</b>). After VM <b>105</b> is successfully launched on the selected HW or newly added HW, virtual machine manager <b>120</b> instructs virtual machine <b>105</b> to launch the corresponding application instances in step <b>818</b>. At step <b>820</b>, virtual machine manager adds these services/applications into its routing table after these services/applications are ready for use. The same procedure is repeated for all of the VM instances in the list (e.g., all of the VMs associated with the crashed HW(i)).

0059<figref idref="DRAWINGS">FIG. 9</figref> is a block diagram illustrating embodiments of a hardware appliance <b>115</b>. Hardware appliance <b>115</b> includes interface <b>910</b>, processor <b>920</b>, and memory <b>930</b>. In some embodiments, interface <b>910</b> communicates signals to and from hardware appliance <b>115</b>, processor <b>920</b> executes instructions to provide some or all of the functionality described above as being provided by hardware appliance <b>115</b>, and memory <b>930</b> stores the instructions executed by processor <b>920</b>.

0060Processor <b>920</b> may include any suitable combination of hardware and software implemented in one or more modules to execute instructions and manipulate data to perform some or all of the described functions of hardware appliance <b>115</b>. In some embodiments, processor <b>920</b> may include, for example, one or more computers, one or more central processing units (CPUs), one or more microprocessors, one or more applications, and/or other logic.

0061Memory <b>930</b> is generally operable to store instructions, such as a computer program, software, an application including one or more of logic, rules, algorithms, code, tables, etc. and/or other instructions capable of being executed by a processor. Examples of memory <b>930</b> include computer memory (for example, Random Access Memory (RAM) or Read Only Memory (ROM)), mass storage media (for example, a hard disk), removable storage media (for example, a Compact Disk (CD) or a Digital Video Disk (DVD)), and/or or any other volatile or non-volatile, non-transitory computer-readable and/or computer-executable memory devices that store information.

0062Other embodiments of hardware appliance <b>115</b> may include additional components beyond those shown in <figref idref="DRAWINGS">FIG. 9</figref> that may be responsible for providing certain aspects of the hardware appliance's functionality, including any of the functionality described above and/or any additional functionality (including any functionality necessary to support the solution described above). In some embodiments, virtual machine <b>105</b> and/or virtual machine manager <b>120</b> may run on one or more hardware appliances <b>115</b> and may comprise any interfaces, processors, or memory (e.g., virtualized from/provided by interface <b>910</b>, processor <b>920</b>, and/or memory <b>930</b> of hardware appliance <b>115</b>) that may be needed in order to perform any of the functionality described above and/or any additional functionality (including any functionality necessary to support the solution described above).

0063The following summarizes particular embodiments of the disclosure: a virtual machine manager manages a virtual machine (VM) that spans a plurality of hardware appliances. The virtual machine manager receives requests from devices. For example, the virtual machine manager intercepts a request from an end user device that requests to use a service provided by the VM. The virtual machine manager selects an application instance from a pool of application instances running in the virtual machine. Then it forwards the request to the selected application instance. The selected application instance is running on a hardware appliance, which is part of the hardware associated with the virtual machine. The application instance creates/updates session related data (i.e., session data) when providing the service to the device. To provide continuous service to the end user, the application instance runs at different states corresponding to different session data and configuration data. When the application instance creates/updates session related data, the virtual machine instance in which this application instance is running notifies the virtual machine manager. For example, the application instance generates and caches the session data while providing the service to an end user, and the virtual machine instance (which manages the cache) informs the VM manager to replicate the session related data cached by the application instance. The virtual machine manager then replicates the session related data on the remaining hardware appliances that are associated with the same VM. In this way, this service's session data is available across different hardware appliances under this VM. When one of the hardware appliances under the VM is crashed, the application instance on the remaining hardware appliances can access this session related data and provide/continue the service toward the end user's device.

0064Some embodiments of the disclosure may provide one or more technical advantages. As an example, in some embodiments, session data associated with a service may be replicated to multiple hardware appliances of a virtual machine to offer high availability at the service level, virtual machine level, and/or the hardware level. A technical advantage of some embodiments may allow a virtual machine to logically stretch over multiple physical hosts such that if one physical host fails, the virtual machine may survive on another physical host. Thus, the impact of a physical host failure may be limited to a capacity loss corresponding to the hardware capabilities of the failed physical host. In some embodiments, this may be achieved by decoupling the virtual machine from the virtual machine manager and the physical host. A technical advantage of some embodiments may enable deployment of clustered services in a cloud environment without having to apply complex virtual machine deployment rules in order to preserve redundancy and resilience. In some embodiments, the solution enables services to be deployed in the cloud without having to use built in resilience mechanisms in the platform which may reduce the complexity of software applications.

0065Some embodiments may benefit from some, none, or all of these advantages. Other technical advantages may be readily ascertained by one of ordinary skill in the art.

0066Modifications, additions, or omissions may be made to the systems and apparatuses disclosed herein without departing from the scope of the invention. The components of the systems and apparatuses may be integrated or separated. Moreover, the operations of the systems and apparatuses may be performed by more, fewer, or other components. Additionally, operations of the systems and apparatuses may be performed using any suitable logic comprising software, hardware, and/or other logic. As used in this document, “each” refers to each member of a set or each member of a subset of a set.

0067Modifications, additions, or omissions may be made to the methods disclosed herein without departing from the scope of the invention. The methods may include more, fewer, or other steps. Additionally, steps may be performed in any suitable order.

0068Although this disclosure has been described in terms of certain embodiments, alterations and permutations of the embodiments will be apparent to those skilled in the art. Accordingly, the above description of the embodiments does not constrain this disclosure. Other changes, substitutions, and alterations are possible without departing from the spirit and scope of this disclosure, as defined by the following claims.

0069Abbreviations used in the preceding description include:

0070AS Application Server

0071CMS Cloud Management System

0072FT Fault Tolerance

0073HW Hardware

0074MVM Mega Virtual Machine

0075OS Operating System

0076UE Use Equipment

0077VM Virtual Machine