Paul McGurn wrote:
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.
Indeed.
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 main difficulty with this is consistency. Many parts of our data are
tagged with dynamically generated id's (order id's for example) that
are printed out and referenced by our customers, and even their customers.
Running on multiple databases allows for the possibility (at this
point certainty) of generating duplicate ids across different regions.
This could result in a lot of confusion, particularly for support calls.
We may need to learn to live with that but I still am not crazy about it.
This may be the only reasonable way to do this without completely
re-architecting our app (which is not really doable any time soon).
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
