An increasing number of software applications are written to platform independent execution environments such as the Java Runtime Environment and the .NET Common Language Runtime. These applications generally execute within a virtual machine (VM) that provides a level of abstraction between the program execution environment and the external software interface. Applications often use middleware frameworks on top of these execution environments. Examples of such frameworks are J2EE application servers and .NET application servers.
A general purpose device, such as a computer, commonly has finite resources. If each VM's execution resources is provided by the general purpose device, any such device can only support a limited number of applications and VM's. Data centers often need to support a significant number of applications. As a result, a large number of general purpose devices are deployed for resource planning purposes, with each application allotted enough resources for its peak needs, making such a setup costly to deploy and administer.
Traditionally in order to support a large number of applications, a large number of general purpose devices are deployed to accommodate the peak resource needs of the applications. It is desirable to have a way to provide large scale application support at reduced deployment and administration costs. Also, given the existing investment in middleware frameworks and applications, an effective solution to the problem should be backward compatible with the existing applications and frameworks.
In one solution, the VM segments its functionality into a shell VM and a core VM that are separate. The shell VM performs interactions with the external environment. The core VM performs VM internal execution functions including managing memory, performing computations, transferring data, processing data and processing logic. The core VM communicates through the shell VM for interaction with the external environment. Resources consumed by the core VM are separate, both logically and physically, from those consumed by the shell VM. The external environment does not need to be aware of the VM segmentation and can interact solely with the shell VM. To the external environment, the distribution of VM internal execution functions and shell functions appears transparent. The shell VM appears as a complete VM, even though it does not consume resources needed for VM internal execution.
Since all external network and I/O communications are performed via the shell VM, scaling the performance of the segmented VM can become limited by capabilities of the shell VM host to perform the external communications. Therefore, there exists a need to perform external communications on the segmented VM more efficiently.
Various embodiments of the invention are disclosed in the following detailed description and the accompanying drawings.
The invention can be implemented in numerous ways, including as a process, an apparatus, a system, a composition of matter, a computer readable medium such as a computer readable storage medium or a computer network wherein program instructions are sent over optical or communication links. In this specification, these implementations, or any other form that the invention may take, may be referred to as techniques. A component such as a processor or a memory described as being configured to perform a task includes both a general component that is temporarily configured to perform the task at a given time or a specific component that is manufactured to perform the task. In general, the order of the steps of disclosed processes may be altered within the scope of the invention.
A detailed description of one or more embodiments of the invention is provided below along with accompanying figures that illustrate the principles of the invention. The invention is described in connection with such embodiments, but the invention is not limited to any embodiment. The scope of the invention is limited only by the claims and the invention encompasses numerous alternatives, modifications and equivalents. Numerous specific details are set forth in the following description in order to provide a thorough understanding of the invention. These details are provided for the purpose of example and the invention may be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical material that is known in the technical fields related to the invention has not been described in detail so that the invention is not unnecessarily obscured.
The shell VM may utilize one or more communications interfaces on the shell VM device to communicate with the external applications as well as with the core VM on a core VM device. In some embodiments, the shell VM also communicates with one or more data storage devices, and optionally with the resource manager. The interfaces are separate in some embodiments and shared in others. The shell VM may also communicate with applications that reside on the shell VM device. The core VM may utilize one or more communication interfaces on the core VM device to communicate with the shell VM on a shell VM device. In some embodiments, the core VM also communicates with the data storage device, and optionally the resource manager.
Both the shell and core VM devices may communicate with the data storage device to load necessary software components. A resource manager 204 may communicate with the shell VM, the core VM, the shell VM device and the core VM device, allocating and managing system resources. The resource manager is an optional part of the system and may be omitted in some embodiments.
The shell and core VM segment the functionality of a conventional VM. In the example shown, the shell VM performs interactions with the external environment. For a user, a web server or a database that comes from the external environment, the interaction with the shell VM device is transparent; that is, the interaction appears to be substantially the same as the interaction with the general purpose device shown in
The external environment interacts with the system by sending requests to the shell VM device. Examples of the external environment includes a web server, a user, a messaging engine, a journaling facility, a load distributor, a network storage device, a database, and any networked node, system, process, service, and entity. There are many ways to conduct the interaction, including through system calls, networking calls, file input/output (I/O) calls, etc. In some embodiments, the interaction includes using a native interface call such as Java Native Interface (JNI) calls for Java VMs or calls using the platform invoke mechanism in a .NET VM.
Requests to the VM (e.g., calls into the VM) are intercepted by shell VM 208 and forwarded to core VM 214 on core VM device 202. The calls are forwarded to the core VM using a predefined communication scheme. In one embodiment, the forwarding is performed via remote procedure calls (RPC's). The calls are received and processed by core VM 214, and then further processed by application server 212 and application 210. The processed result is sent to the shell VM, and eventually passed back to the caller. The core VM supports VM internal execution functionality such as maintaining memory and performing data processing in a way similar to a conventional VM.
Segmenting functionality between a shell VM and a core VM improves the system's scalability, manageability, flexibility and efficiency. Since a shell VM is relatively lightweight and consumes fewer resources than a conventional VM, many instances of the shell VM can run on the same shell VM device. Similarly, many instances of core VM's, application servers and applications can run on the same core VM device. Since the shell VM's and the core VM's communicate via a network, there does not need to be a strict physical correspondence between the devices. A core VM device can concurrently host multiple core VM's and support multiple applications invoked by shell VM's from heterogeneous shell VM devices having different operating systems. Similarly, a shell VM device can concurrently support multiple shell VM's invoking applications on heterogeneous core VM devices.
In some embodiments, the core VM device includes specialized hardware designed to improve the performance of the core VM functionality. Many instances of core VM's executing application servers and applications can simultaneously reside on the same core VM device. The core VM device can concurrently support multiple applications invoked from heterogeneous shell VM devices. In one embodiment, a multiprocessor device with specialized hardware assists the core VM functionality. The device has the capacity to concurrently support many instances of the core VM software, executing applications and application servers, simplifying administration and increasing efficiency compared to a multitude of general purpose systems as shown in
Typically the shell VM supports interactions with the external environment such as system calls, file I/O, networking in a way similar to a conventional VM. Calls originating from the VM or the application executing within it are intercepted by core VM 214 and forwarded to shell VM 208 on shell VM device 200. The calls are forwarded to the shell VM using a predefined communication scheme. In one embodiment, the forwarding is performed via RPC's. The calls are received and processed by shell VM 208 which translates them into the proper interactions with the external environment. The processed result is sent to the core VM, and eventually passed back to the caller.
Using the core VM of a segmented VM to directly support interactions with the external environment is disclosed. In some embodiments, if an external communication is determined to be potentially supported by the core VM, the core VM attempts to support the external communication. If the external communication is determined to be not supported by the core VM, the shell VM supports the external communication. In some embodiments, a portion of the external communications is supported by the core VM while another portion of the external communications is supported by the shell VM. By allowing the core VM to support interactions with the external environment, less resource of the shell VM device is required for external environment interaction support. This allows greater scalability for the segmented VM.
If the requested connection not only allowed for the shell VM, at 406 a core VM socket is opened and the connection initiated through the core VM socket. Using the socket is merely an example. In various embodiments, one or more other and/or additional types of connection identifiers can be opened and used to initiate the connection. For an external connection, opening the core VM socket includes using an external communication interface of a core VM device hosting the core VM. For an internal connection to another application on the core VM device, an internal communication interface is used. For example, cross-memory communication is performed within the core VM device. In some embodiments, initiating the connection includes attempting to communicate with an external resource using the connection. If at 408 it is determined the connection is not successful, at 410 the core VM socket is closed. If at 404, the requested connection is determined to be only allowed for the shell VM, or at 408 the connection is determined to be successful and at 410 the core VM socket is closed, at 412 a shell VM socket is opened and the connection is initiated through the shell VM socket. In some embodiments, although the external resource of the requested communication is reachable by the core VM, the shell VM initiates the connection. For example, the external resource of the connection requires authentication using the shell VM because the external destination uses the network address of the shell VM to authenticate the VM. In some embodiments, the shell VM initiates connection at least in part because a connection through the shell VM device is of a more desirable network characteristic (e.g., higher bandwidth, lower latency, lower cost, etc.) than a connection through the core VM device. At 414, the socket information of either the core VM or the shell VM is returned to the requestor of the connection. For example, the information of the successfully initiated socket is returned to the application that requested the connection. In some embodiments, if the connection through the shell VM is not successful, an error is raised and/or an error is return to the connection requestor.
Although the foregoing embodiments have been described in some detail for purposes of clarity of understanding, the invention is not limited to the details provided. There are many alternative ways of implementing the invention. The disclosed embodiments are illustrative and not restrictive.
Number | Name | Date | Kind |
---|---|---|---|
4849880 | Bhaskar et al. | Jul 1989 | A |
5479643 | Bhaskar et al. | Dec 1995 | A |
5774728 | Breslau et al. | Jun 1998 | A |
6003065 | Yan et al. | Dec 1999 | A |
6112279 | Wang | Aug 2000 | A |
6230118 | Bader et al. | May 2001 | B1 |
6345311 | Breslau et al. | Feb 2002 | B1 |
6385643 | Jacobs et al. | May 2002 | B1 |
6397242 | Devine et al. | May 2002 | B1 |
6463459 | Orr et al. | Oct 2002 | B1 |
6625751 | Starovic et al. | Sep 2003 | B1 |
6738977 | Berry et al. | May 2004 | B1 |
6802062 | Oyamada et al. | Oct 2004 | B1 |
6968539 | Huang et al. | Nov 2005 | B1 |
7036122 | Bennett et al. | Apr 2006 | B2 |
7080378 | Noland et al. | Jul 2006 | B1 |
7114157 | Chaffee et al. | Sep 2006 | B2 |
7213246 | van Rietschote et al. | May 2007 | B1 |
7272799 | Imada et al. | Sep 2007 | B2 |
7313793 | Traut et al. | Dec 2007 | B2 |
7401178 | Tene et al. | Jul 2008 | B1 |
7480908 | Tene et al. | Jan 2009 | B1 |
7536688 | Tene et al. | May 2009 | B2 |
7620953 | Tene et al. | Nov 2009 | B1 |
7669202 | Tene et al. | Feb 2010 | B1 |
7742398 | Tene et al. | Jun 2010 | B1 |
7801154 | Schrock | Sep 2010 | B2 |
20010034771 | Hutsch et al. | Oct 2001 | A1 |
20020138578 | Zhou | Sep 2002 | A1 |
20020184287 | Nunally | Dec 2002 | A1 |
20030217092 | Veselov | Nov 2003 | A1 |
20030229794 | Sutton et al. | Dec 2003 | A1 |
20040073552 | Bailey et al. | Apr 2004 | A1 |
20040148608 | Gendreau et al. | Jul 2004 | A1 |
20040172629 | Tene et al. | Sep 2004 | A1 |
20050076326 | McMillan et al. | Apr 2005 | A1 |
20050108709 | Sciandra et al. | May 2005 | A1 |
20050132367 | Tewari et al. | Jun 2005 | A1 |
Entry |
---|
Wheeler, James G., “SmartArrays and Java Frequently Asked Questions”, Feb. 5, 2002, SmartArrays, Inc. p. 1-5. |
Mayers, Chris, “Using Remote Procedure Call Standards”, Mar. 24, 1996, Architecture Projects Management Limited, p. 1-14. |
Czajkowski, Grzegorz et al., “Automated and Portable Native Code Isolation”, Sun Microsystems, SMLI TR-2001-96, Apr. 2001. |