1

We currently have a Java based web application that runs on WebSphere and accesses SQL Server 2008.

The application requires frequent code and file changes and hence we update the EAR files in WebSphere at least once in a month, but typically more often. It is a database intensive application.

Downtimes are extremely expensive for us and right now we try to do it during our least load times (around 3am on weekdays). Going forward it looks like this isn't going to be an option (especially considering the frequent updates to our application) and we are looking for a better hosting setup like a cluster. We are hoping to resolve some of our other problems as well through the new setup (for which, till now, we have been resorting to workarounds).

We have a multi-node cluster in mind. My understanding of clusters is primitive, so if any assumption below is wrong, please let me know.

The following are our new requirements:

  • We should be able to deploy new versions of the application without any (or just a few seconds) downtime.
  • Load balancing of web requests.
  • Capable of handling a failover.

Here are a few questions I have:

  1. What kind of server setup would you recommend?
  2. Considering we have a database, is it really possible to ensure near zero downtime unless we have two clusters - one for the DB and one for the web layer of the application?
  3. If we had just one cluster for the web layer (and the DB on a dedicated server), would that enable us to deploy new versions of the application without downtimes on WebSphere?
  4. Our Java application was written to be run on a single JVM. If we deploy it on WebSphere, would WS automatically make the application run on a cluster? Or would we have to make use of a cluster-aware JVM like Terracota?
Skylark
  • 21
  • 1

2 Answers2

1

Sounds like you need two clusters. You need a load balanced cluster for the web application with a load balancer in front of the web servers to balance the web traffic so that if one server goes down the other handles the load. This way you can take one machine out of the cluster, upgrade it make the database changes, then remove the machine with the old version and put in the machine with then new version in.

On the database side you'll want an Active/Passive cluster. This will allow the service to be restarted within seconds in the event of a hardware failure on the note which is running the SQL instance. This will not do anything to prevent outages in the event of a bad release, or if the database release process locks database objects. This will also not scale the load of the database between the two (or more) nodes of the cluster. SQL Clusters run the SQL instance on a single physical node at any one time.

mrdenny
  • 27,074
  • 4
  • 40
  • 68
  • Thanks for that answer! Unfortunately, our release process includes database locks. But we are trying to see if we can do without it. – Skylark Oct 04 '10 at 16:38
0

This probably goes without saying, but don't forget that anything you rely on JVM synchronization or singleton/global data for will no longer be safe across clustered WebSphere servers.

I can't address anything about using a cluster-aware JVM with WebSphere. I know WebSphere generally doesn't support running on any JVMs other than its own, but Google does indicate some people are combining those products.

With WebSphere, you also want to think about what you have in front of the Application Server to maintain Session affinity to a particular cluster member and to support failover when a cluster member is down. This is normally handled by the WebSphere Plugin for a particular Web Server like IBM HTTP Server or Microsoft IIS.

However, our experience has been that even when you deliberately take one cluster member down, it's still not instantaneous that requests start being routed to the other(s).

And if you need Session failover (IMO, not necessarily required), you must configure the Session Manager for distributed sessions too (either via Database storage or via Memory-to-Memory Session Replication). Which also brings additional constraints on what you store in the session since its contents will now have to be Serializable. And you'll have to select one of the available strategies for deciding when to store or replicate the data from memory to the distributed location.

dbreaux
  • 301
  • 1
  • 7