【问题标题】:Concerns on the webpshere session memory to memory replication关于 websphere 会话内存到内存复制的问题
【发布时间】:2012-09-18 13:20:08
【问题描述】:

我有一个 WAS 环境,其拓扑如下所示:(这里有一个错字,'IH' 应该是 'IHS')

来自最终用户的请求通过 IHS 并到达 WAS1,然后来自 WAS1 的应用程序将从其后端 WAS2 CLUSTER 调用应用程序服务,F5 设备负责负载平衡工作。

我的问题是关于 WAS2 集群的会话跟踪机制。一旦我启用Memory-to-memory replication,我可以在这里使用cookiesURL rewriting 吗?如果是这样,我需要进行任何手动配置吗?如果没有,我可以使用哪种跟踪方式?哪个不能?为什么?

请帮忙解释的越详细越好!

提前致谢

【问题讨论】:

    标签: websphere websphere-7 websphere-6.1


    【解决方案1】:

    Cookie 或 URL 重写与 Session 复制无关。它们是客户端将会话 ID 发送回服务器的工具。默认支持 Cookie,您需要勾选一个框以启用 URL 重写。

    我有几个问题要问你。

    (1) 为什么WAS 1 没有集群? (或者你不想在这张照片中展示它)。

    (2) 它起什么作用?能否通过普通 IHS 实现该功能?

    (3) 为什么在 WAS 1 和 WAS 集群之间使用 F5?我不明白 F5 负载均衡器的工作原理。通常 IHS 使用 WAS 生成的克隆 ID 来了解将请求路由到哪个 WAS 服务器。这就是在 IHS+WAS 中实现会话亲和性的方式。 F5 可能会也可能不会。

    除了启用 URL 重写并确保应用程序代码中的所有链接都使用编码的 URL 之外,上述结构中不需要任何配置。我宁愿坚持使用 Cookie,因为这是默认方法,事实上,如果关闭 cookie,WAS 将无法工作(因为用于安全性(auth/auth)的 LTPAToken 作为 cookie 发送回客户端) .

    除了一个“未编码的 URL 链接”可能会丢失用户的会话之外,使用 URL 重写没有任何害处。

    HTH

    【讨论】:

    • 嗨@Manglu,请看我的回答如下: 1. WAS 1 实际上是集群,但我没有在这里显示。 2.也许可以通过IHS实现,但目前是客户定义的架构,我无法更改。 3. 正如我所说,F5 设备确实在这里使用。我需要做的是在当前情况下帮助弄清楚。
    猜你喜欢
    • 1970-01-01
    • 2011-10-08
    • 2016-03-14
    • 1970-01-01
    • 2013-05-02
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多