我们目前有一个基于Java的Web应用程序，它运行在WebSphere上并访问SQL Server 2008。
应用程序需要频繁的代码和文件更改，因此我们至less在一个月内更新WebSphere中的EAR文件，但通常更新一次。 这是一个数据库密集型应用。
停机时间对我们来说是非常昂贵的，现在我们在最短的时间内（平日上午3点左右）尝试这样做。 向前看，这看起来不会是一个选项（特别是考虑到我们的应用程序的频繁更新），我们正在寻找一个更好的托pipe设置像一个集群。 我们希望通过新的设置来解决我们其他的一些问题（为此，我们一直在寻求解决办法）。
我们有一个多节点集群。 我对集群的理解是原始的，所以如果下面的任何假设是错误的，请让我知道。
以下是我们的新要求：
以下是我的一些问题：
听起来像你需要两个群集。 您需要Web应用程序的负载均衡集群，并在Web服务器之前使用负载均衡器来平衡Web通信量，以便在一台服务器停机时另一台服务器处理负载。 这样你就可以从集群中取出一台机器，升级它使数据库发生变化，然后用旧版本删除机器，然后把机器放入新版本。
在数据库方面，你需要一个主动/被动群集。 这将允许在正在运行SQL实例的笔记上发生硬件故障的情况下，在几秒内重新启动该服务。 如果数据库发布过程locking了数据库对象，这将不会做任何事情来防止在发布错误的情况下停机。 这也不会扩大集群的两个（或更多）节点之间的数据库负载。 SQL群集可以在任何时候在单个物理节点上运行SQL实例。
这可能不言而喻，但不要忘记，任何依赖于JVM同步或单例/全局数据的东西在集群式WebSphere服务器中都不再安全。
我无法解决使用集群感知型JVM和WebSphere的问题。 我知道WebSphere通常不支持在自己以外的任何JVM上运行，但Google确实表示有人正在合并这些产品。
使用WebSphere，您还需要考虑在Application Server前面拥有什么，以维护与特定集群成员的会话亲缘关系，并在集群成员closures时支持故障切换。 这通常由WebSphere Plugin为特定Web服务器（如IBM HTTP Server或Microsoft IIS）处理。
但是，我们的经验是，即使你故意把一个集群成员放下，现在仍然不是即时的，请求开始被路由到其他的（s） 。
如果您需要会话故障转移（IMO，不一定是必需的），则还必须为分布式会话configuration会话pipe理器（通过数据库存储或通过内存到会话会话复制）。 这也会给你在会话中存储的内容带来额外的限制，因为它的内容现在必须是可序列化的。 而且您必须select其中一种可用策略来决定何时将数据从内存存储或复制到分布式位置。