将应用程序移动到Websphere集群

Question

在将应用程序从单个Websphere Application Server移动到Websphere集群之前，我们应该注意什么？

Answer 1

这是我的经验清单。它不完整，但应涵盖最常见的问题领域：

• 计划分布式会话管理配置（即，您将使用内存到内存或基于数据库的复制）。请注意，如果您仍在32位平台上，如果您的应用程序使用了大量内存，则群集的资源需求开销可能会导致您出现不稳定问题。
• 确保您放入用户会话的所有内容都可以使用默认序列化程序进行序列化（实现Serializable）。否则，您可能会遇到分布式会话的问题。
• 同样适用于DynaCache的所有内容。确保所有内容都正确序列化。
• 指定并确保将所有资源定义（JDBC提供程序等）设置为适当的范围。我通常建议将实际的Cluster范围用于应用程序安装到群集的所有内容。这样可以确保测试功能在适当的位置正常工作，并且不会产生相互矛盾的定义。
• 确保您的应用程序使用Web界面中资源的相对路径。一旦你开始负载平衡和东西，你可能会遇到一些严重的问题，如果你已经搞砸了很多东西。
• 如果您有任何类型的计时器，请确保它们适用于群集。使用Quartz可能意味着您应该将JDBC存储用于计时器任务。使用EJB计时器确保只注册一次计时器（如果有几个节点在同一时间尝试注册，则可能损坏WAS的计时器数据库）并确保将它们安装到集群范围。
• 确保使用WAS提供的SSO机制。如果您有自定义实现，请确保它处理群集中服务器之间的用户移动。

Answer 2

保持简单，根据您的要求，尝试配置负载均衡器以使用粘性会话而不是在HTTP会话中保持状态。这样，您就不需要在内存会话复制中使用饥饿资源。

单点登录不是单个群集的问题，因为您的HTTP客户端不会移出相同的http://server.acme.com/ ...主机域名。

您的大多数测试都应关注数据库争用。如果您有一个高度事务性的应用程序（即对同一个表的许多写入），请确保查看数据库隔离级别，以便不会保持锁定。您的交易demarkaction也是如此。保持交易尽可能简短。如果您没有自己的数据库技能，请确保在测试时获得数据库分析师以帮助您监视数据库。

Answer 3

在任何重大更改（如此版本或升级到新版本等）之前，将PMR提升为IBM支持也是一个很好的建议。将其提升为“软件使用问题”，他们可以为您提供反馈基于其他客户输入的知识库。同样适用于您有支持协议的任何类型的产品 - 在问题发生之前询问支持。