Across the world in Ireland, Waratek recently announced availability of Waratek Cloud VM for Java. This JVM extends OpenJDK (HotSpot VM) with a virtualization layer that isolates applications in Java Virtual Containers. In addition to application isolation, Waratek’s solution offers a container management interface based on Virsh, and resource monitoring… I think this is a very cool solution that could potentially shape ideas to JVM multi-tenancy implementation. You can watch a presentation on their solution here, and find more information on their solution here.
-----
Background: The current model of one JVM per application is inefficient. It leads to JVM sprawls and inefficient usage of infrastructure resources.
The JVM specification defines the JVM as an abstract computing machine. It describes the Class file format, machine instruction set, rules/constraints on class loading, etc., but contains no requirements or models for the implementation of the JVM’s internal processes, task management or resource management for secure sharing of the JVM by multiple applications.
Over the last decade, before multi-tenancy had become such a popular (and overused) term, there have been a number of related efforts to address the issues:
- JSR 121: Application Isolation API – Proposes a language construct called “Isolate” as the means to instantiate isolated Java applications on the JVM. The spec also addresses isolate-to-isolate communication.
- JSR 284: Resource Consumption Management (RCM) API – Since there will be different applications sharing a JVM, there needs to be a way to make sure a rogue app does not impact the performance of another app. JSR 284 proposes a standard API to bind RCM policies to applications running on the JVM. This JSR is quite interesting, as it has provisions for resource reservation as well setting constraints / quota for resource consumption.
SAP also did its own implementation of application isolation scheme by implementing a pool of VMs and a dispatcher to schedule work in the VMs (see Process Attachable Virtual Machines, Virtual Machine Container).
-----
Java multi-tenancy
There are two usecases for JVM multi-tenancy:
N.B. In the diagram above, I specify App, but App Server should be implied as well.
In option B, you have multiple applications using the JVM. This is pretty straight forward. In option A, you have a situation where multiple customers or business units (i.e. shared services) need to share the application securely.
In the case of option A, let’s assume an application has been implemented as a multi-tenant solution using JEE framework. The App Server interfaces with the underlying JVM to provision new tenants (new isolates). As part of the tenant provisioning, the App Server uses the RCM interface to set tenant policies. The JVM monitors the RCM policies, and takes appropriate action. As application requests hit the App Server, the App Server uses some tenant context scheme to determine which isolate it should go to….As the request flows through the different tiers of the JEE solution, the App Server makes sure only the tenant only accesses the JEE resources that it is authorized to use. In case of an isolate loop or application runtime environment crash, the JVM applies RCM policies to handle the situation…
In the example above, we can see that there are requirements for the JEE framework as well as JVM runtime to support multi-tenancy. And, we also should not forget that there re other languages running on the JVM. Additional requirements may need to be considered.
-----
So, where are we now?
The JCP will standardize multi-tenancy in the Java Platform, but this will probably not happen in JDK8 given the current schedule and the focus for JDK8 (productivity, modularity, performance).
There should be more information available by Jan 2013.
-----
Final thoughts
With JDK8, there will be a new Java module system (Jigsaw) replacing the old JAR format and class loading from Classpath… The new format will contain metadata about the packages, classes, and dependencies using a new set of annotations (i.e. version, imports, exports, …), and reflection APIs to improve class loading and sharing, performance,… For some background, have a look at JSR 294 and JSR 277. This will play an important supporting role in implementing multi-tenancy support in the JVM efficiently.
Clearly, JVM multi-programming / multi-tenancy capabilities will bring economic benefits to both enterprise customers and vendors. It think it might also trigger a new wave of JVM innovations like Waratek.
3 comments:
Hi there! Keep it up! This is a good read. I will be looking forward to visit your page again and for your other posts as well. Thank you for sharing your thoughts about rcm solutions in your area. I am glad to stop by your site and know more about rcm solutions .
The important functions (of a piece of equipment) to preserve with routine maintenance are identified, their dominant failure modes and causes determined and the consequences of failure ascertained. Levels of criticality are assigned to the consequences of failure. Some functions are not critical and are left to "run to failure" while other functions must be preserved at all cost. Maintenance tasks are selected that address the dominant failure causes. This process directly addresses maintenance preventable failures. Failures caused by unlikely events, non-predictable acts of nature, etc. will usually receive no action provided their risk (combination of severity and frequency) is trivial (or at least tolerable). When the risk of such failures is very high, RCM encourages (and sometimes mandates) the user to consider changing something which will reduce the risk to a tolerable level.
The RCM Blitz™ Solutions process was put together to allow companies to complete a traditional RCM analysis on a major critical asset by defining the envelope, completing the upfront tasks, and then setting up your meeting to complete the analysis in less than 5 days.
Post a Comment