Activity Based Resource Management for Multitenant JVM Services

Home

News: Activity Based Resource Management for Multitenant JVM Services

  1. The growth of the cloud computing and cloud based applications over the last few years has spurred renewed interest in multi-tenancy architectures with companies such as IBM actively researching ways of bringing multi-tenancy to the JVM in the cloud in which an application (and its context) serves as a tenant within a shared JVM runtime. Other companies today are also exploring ways to “innovate” in areas of service differentiation, recognizing different classes of customers in terms of cost and quality (performance, reliability, etc), and invariably multi-tenancy plays a significant role in achieving this.

    “Multitenancy is the fundamental technology that clouds use to share IT resources cost-efficiently and securely” - Salesforce.com

    Whilst multi-tenancy offers many advantages to the service provider in reducing operational cost and improving resource utilization it presents its own challenges in particular how to effectively managing the underlying resources in a way that ensures a certain level of quality of service (QoS) is maintained across different execution contexts. Fortunately various techniques, generally falling under the QoS heading, exist today to help meet such challenges inprotectingpolicing (and shaping)prioritizing and predicting consumption within a shared (execution & resource) environment.

    http://www.jinspired.com/site/activity-based-resource-management-for-multitenant-jvm-services

     

    Threaded Messages (5)

  2. It's simple[ Go to top ]

    It's all quite simple - you can't have multitenancy without separate garbage collectors.

  3. It's simple[ Go to top ]

    The whole internet is multi-tenent depending on your perspective of what a tenant is, how long tenancy exists for and what constitutes a shared resource. 

    Garabage collection to some degree can be managed by way of the underlying cause - object allocation. It is very easy to control (to some degree) this aspect of the runtime via adaptive control vaves (http://www.jinspired.com/site/canceling-uncontrolled-jitter-with-adaptively-controlled-jitter) when the tenant is viewed as transient as a single web request. Applications are a whole different beast in this regard.

    The deployment of applications to a single JVM is very much complicated by such things as endpoint ports (sockets). The whole illusion falls flat on its face when you target runtime must exist on separate hosts because of fixed port addresses that can't be shared across multitenant runtimes on the sam host.

    Salesforce force.com is viewed as many as a multi-tenant service not because of JVM magic but because it monitors and manages execution of Apex code which is mapped to Java along with many other things related to the data storage itself.

    If we are really going to go down this route of multitenant JVM's then it would be far better for us to focus on layering a grid (task based) programming model/language on top without the whole Java SDK baggage which is kind of what Google has attempted with GAE for Java.

  4. It's simple[ Go to top ]

    It's all quite simple - you can't have multitenancy without separate garbage collectors.

    You're not making any sense, although you claim it's quite simple. Try to be a bit more informative with your witty replies.

    Peace,

    Cameron.

  5. It's simple[ Go to top ]

    Why? It IS really simple.

    A misbehaving application in a multitenant JVM can crash all other applications. There are no guarantees about who's going to get OutOfMemory exceptions. And JVM's behavior in conditions close to OOM is often quite pathological: endless GC loops, slowdowns, concurrent GC suddenly starting to use lots of CPU.

    We've actually tried multitenant JVMs for our computational biology stuff. The idea was to allocate all of the RAM to one humongous JVM and run everything on it. Hasn't worked at all - too many abstraction leaks everywhere.

    Now, if you want to host multiple simple, trusted processes that don't take a lot of RAM then it might be OK. In all over cases, JVM multenancy doesn't work.

  6. It's simple[ Go to top ]

    Ah, so you are saying that for a multi-tenanted system, you want to be able to limit the memory consumption per tenant. Yes, that is true, and the JVM team has been working on being able to do just that (among a few other things required by multi-tenanted systems).

    That's a bit different, BTW, from what you originally said.

    Peace,

    Cameron Purdy | Oracle

    The opinions and views expressed in this post are my own, and do not necessarily reflect the opinions or views of my employer.