4

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

4

3 回答 3

9

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

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

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

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

您的大部分测试都应该集中在数据库争用上。如果您有一个高度事务性的应用程序（即对同一个表进行多次写入），请确保查看您的数据库隔离级别，以免不必要地持有锁。您的事务标记也是如此。使交易尽可能简短。如果您自己没有数据库技能，请确保您有一名数据库分析师来帮助您在测试时监控数据库。

于 2011-10-18T13:16:03.910 回答
0

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

于 2011-10-07T10:59:25.217 回答