Кластерная рекомендация установки для приложения Java-WebSphere-SQL

Кажется, что Вам нужны два кластера. Вам нужна загрузка сбалансированный кластер для веб-приложения с подсистемой балансировки нагрузки перед веб-серверами для балансировки веб-трафика так, чтобы, если один сервер спускается по другим дескрипторам загрузка. Таким образом, можно вынуть одну машину из кластера, обновление, которое это вносит изменениями базы данных, затем удаляет машину со старой версией и вставило машину с затем новой версией в.

На стороне базы данных Вы захотите Активный/Пассивный кластер. Это позволит сервису быть перезапущенным в течение секунд в случае отказа оборудования на ноте, которая выполняет экземпляр SQL. Это не сделает ничего для предотвращения отключений электричества в случае плохого выпуска, или если процесс выпуска базы данных блокирует объекты базы данных. Это не будет также масштабировать загрузку базы данных между двумя (или больше) узлы кластера. Кластеры SQL выполняют экземпляр SQL на единственном физическом узле в любой момент.

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.