I think the ideal approach here (potentially) is segregating your customer base. Here's an idea directly from how Salesforce.com does it.
Segregate, geographically, your customer base's target infrastructure. The way they do this is by tying their customers to a specific "cluster" of their cloud, and then everything that customer does in the application is tied back to that "cluster". The layer of redundancy (on top of being a cluster of course), is having a hot failover infrastructure that is synched with the production infrastructure at whatever feasible cycle works for the amount of data. By doing this, they can then schedule maintenance windows geographically, to ensure that impact is low no matter where the customer is. In your case, this would likely require some effort in architecting the data storage part of things to be partition-able to some extent, but this would really be maintaining what would be the effect of multiple datacenters/clusters/clouds. The only alternative I can personally offer is ensuring that the intended webapp upgrade is backwards compatible, and that the intended database upgrade is backwards/forwards compatible, so you can roll them separately (which would probably be more of a challenge than geo-separate environments). Paul McGurn -----Original Message----- From: Bill Davidson [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 17, 2008 5:06 PM To: Tomcat Users List Subject: Server Maintenance Across Timezones (global) My company's main webapp is used around the world (Europe, North America, Australia, etc.). We're using Tomcat as our app server and Oracle (10g) for our database. When we want to do an upgrade, that usually involves DDL changes to the database as well as corresponding changes to the webapp which means we have to make our users log out so we can shut down the app, update the DDL and restart the updated webapp. The changes are interdependent. It's all or nothing. This was not a big problem when we were just doing business in the U.S. We'd do upgrades late at night when nobody (or hardly anyone) was using the system. The problem now is that late at night here is middle of the day in other places and downtime in the middle of the day is a real problem. Our customers use our app to run parts of their business so downtime in the middle of the day is very very bad. They understandably don't like telling their customers: "I'd like to help you but I need to wait for the Americans to upgrade their systems." I'm not sure how to deal with this. I've been trying to think of a way to use multiple servers and multiple databases but that seems like a synchronization nightmare. Losing data consistency is not an option. I'm sure that plenty of others on this list have had to deal with this problem. Any suggestions? How have others dealt with it? --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
