Hi,

I would like to get some opinions about setting up an application served by multiple JVMs.    Cluster is the first thing that I can think of.  However,  I tried on WebSphere console and it did allow one application deployed on multipule application servers (but they are not created as a cluster).  I wonder how it will behave.  My guess will be that there is no session failover.    Anyway,  I just want to some other opinions to let me know if there is any advantage of setting up such non-cluster environment.

Thanks!

Samuel

Hi Sam,

I'm in no way an expert - I've only been a WebSphere Admin for a little over a year, but I was just curious, why wouldn't you want to cluster your environment?  If you have more than one app server, any changes you make would have to be implemented on each server individually.  Clustering takes less time and effort especially when dealing with deployments, configuration, updates; etc. 

Just wondering.....

I've never set up an app to be served by multiple jvms *unless* it's set up as a cluster within 1 profile/cell.  It's definitely IBM's intention for clusters to be the way one does this.  I guess it might be possible to have jvms in different profiles, and you manually hack together a plugin config file on the web server side to reference them...?  I would recommend using a cluster, though.

Thanks for the reply.  

My understanding is that cluster should be the right way to go.  I just wonder if there is any application that will have issue on cluster environment if they are not running on a cluster environment before.

Regarding for the deployment,  admin console actually allows you to deploy one application on multipule servers during one "install application" session. So, it is as simple as deploying on a cluster.

We've had a few problems when an app is on a single server in a test env but on a cluster in production.  If the app had any scheduled jobs, you need to be aware that they will run on each cluster member.  Maybe it's possible to change that somehow, but we've always just worked around it.  Also, if the app has any singleton objects, there will be 1 in each cluster member, which could lead to unexpected behavior, depending on design.  If you've got powerful enough test machines, it's a good idea to use a cluster in test also, so you find things like this before going to prod.

Sam What version of WebSphere are you running so I can send you a link to some IBM documentation on this subject? There are many reasons that you want to using clustering such as app availability and many more. If you properly build a WebSphere cell across multiple nodes with clustered application servers then WebSphere will never be the reason for an application outage. You can do all of the following with and maintain applications availability to your customer.

Ripple Deploy a new version
Update an existing version
Take one node down for maintenance such as OS updates, WebSphere SP’s, etc.

There is one catch the application needs to be built for a clustered environment which is not difficult if it’s a homegrown applications but can be difficult if it’s a third part application.

Sometimes it is possible that the code being given to you will not support failover or clustering of session data and therefore it is easier to avoid the cluster configuration.

We run 6 JVMs of the same application across two WAS servers (seperated phsyically) that are load balanced by IHS/Cisco ACE. There is no failover between the apps and as such if one goes down, the users are kicked back to the login screen of another JVM.