Weblogic Apache 插件和会话粘性

Weblogic Apache plugin and session stickiness

提问by h4tech

If two web servers are configured in between a load balancer and a weblogic cluster, will the two Apache server maintain session stickiness?

如果在负载均衡器和 weblogic 集群之间配置了两台 Web 服务器，两台 Apache 服务器是否会保持会话粘性？

Say for example, the load balancer forwards the first request to the 1st apache and in turn 1st apache forwards to 1st WL managed instance. Even if the second req from the same user is forwarded by the load balancer to the second apache, will the second apache be able to forward it to the 1st WLManaged instance which served the first request rather than the second WLManaged instance which is not aware of the session information at all.

例如，负载均衡器将第一个请求转发到第一个 apache，然后第一个 apache 转发到第一个 WL 托管实例。即使来自同一用户的第二个请求被负载均衡器转发到第二个 apache，第二个 apache 是否能够将其转发到服务第一个请求的第一个 WLManaged 实例，而不是不知道的第二个 WLManaged 实例会话信息。

What should ideally be the behaviour of the weblogic apache plugin? The catch is I don't want to enable session replication on the wl server cluster.

理想情况下，weblogic apache 插件的行为应该是什么？问题是我不想在 wl 服务器集群上启用会话复制。

回答by Pascal Thivent

According to the section "Failover, Cookies, and HTTP Sessions" of the Apache HTTP Server Plug-In:

根据Apache HTTP Server Plug-In 的“ Failover, Cookies, and HTTP Sessions”部分：

When a request contains session information stored in a cookie or in the POST data, or encoded in a URL, the session ID contains a reference to the specific server instance in which the session was originally established (called the primary server) and a reference to an additional server where the original session is replicated (called the secondary server). A request containing a cookie attempts to connect to the primary server. If that attempt fails, the request is routed to the secondary server. If both the primary and secondary servers fail, the session is lost and the plug-in attempts to make a fresh connection to another server in the dynamic cluster list. See Figure 3-1 Connection Failover.

Note:If the POST data is larger than 64K, the plug-in will not parse the POST data to obtain the session ID. Therefore, if you store the session ID in the POST data, the plug-in cannot route the request to the correct primary or secondary server, resulting in possible loss of session data.

Figure 3-1 Connection Failover

当请求包含存储在 cookie 或 POST 数据中或编码在 URL 中的会话信息时，会话 ID 包含对最初建立会话的特定服务器实例（称为主服务器）的引用和对复制原始会话的附加服务器（称为辅助服务器）。包含 cookie 的请求尝试连接到主服务器。如果该尝试失败，则请求将路由到辅助服务器。如果主服务器和辅助服务器都失败，会话就会丢失，插件会尝试与动态集群列表中的另一台服务器建立新的连接。请参见图 3-1 连接故障转移。

注意：如果POST数据大于64K，插件将不会解析POST数据获取会话ID。因此，如果将会话 ID 存储在 POST 数据中，插件将无法将请求路由到正确的主服务器或从服务器，从而可能导致会话数据丢失。

图 3-1 连接故障转移

In other words, yes, both Apache servers will be able to forward an incoming request to the "right" WebLogic instance as the session ID contains all the required information for that. Note that there is no real need to confirm this with testing but it would very easy though.

换句话说，是的，两个 Apache 服务器都能够将传入的请求转发到“正确的”WebLogic 实例，因为会话 ID 包含所有所需的信息。请注意，实际上没有必要通过测试来确认这一点，但这会很容易。

UPDATE:Answering the following comment from the OP

更新：回答来自 OP 的以下评论

I think this document stands good for only one apache server. In my case I have two and the load balancer forwards the requests to both the servers in a 50:50 manner. I did test this and the weblogic plugin is not maintaining the stickiness.

我认为本文档仅适用于一台 apache 服务器。在我的情况下，我有两个，负载平衡器以 50:50 的方式将请求转发到两个服务器。我确实对此进行了测试，并且 weblogic 插件没有保持粘性。

I understood you are using two apache fontend and I'm not sure this document applies to configuration with one apache server only. As explained, the session ID contains a reference of the primary server (and the secondary server as well) so both apache should be able to deal with it. At least, this is my understanding. Actually, I've worked with a similar configuration in the past but can't remember if things were working as I think they should or if the load balancer was configured to handle stickiness too (i.e. forward to a given Apache server). I have a little doubt now...

我知道您正在使用两个 apache fontend，我不确定本文档是否仅适用于使用一个 apache 服务器的配置。如前所述，会话 ID 包含主服务器（以及辅助服务器）的引用，因此两个 apache 都应该能够处理它。至少，这是我的理解。实际上，我过去曾使用过类似的配置，但不记得事情是否像我认为的那样工作，或者负载平衡器是否也被配置为处理粘性（即转发到给定的 Apache 服务器）。我现在有点怀疑...

Could post your plugin configuration (of both apache server if they differ)? Could you also confirm that things are working as expected when only one apache server is up (and test this with both apache if their configuration differ, which shouldn't be the case though)?

可以发布您的插件配置（如果它们不同，则是两个 apache 服务器）？您是否还可以确认当只有一个 apache 服务器启动时，事情是否按预期工作（如果配置不同，则使用两个 apache 进行测试，但不应该是这种情况）？

回答by metatech

When you have 2 Apache instances with a TCP load balancer in front, the stateflow diagram is not applicable anymore, because the Apache instances do not share their states. I guess that the WebLogic plug-in maintains a state with a directional mapping [IPAddress+Port -> JVMID]. If it receives a cookie with a JVMID it does not know yet (for instance, it has never sent a request to this server yet), it has no way to know which IPAdress+Port it refers to, so it will not be able to reuse these JVMID and it will reassign new primary/secondary ones, which will be identical for 2 instances (maybe swapped), and which might be different if there are strictly more than 2 instances. I did not confirm it by running specific tests, but on paper it seems not to work in all cases.

如果前面有 2 个带有 TCP 负载均衡器的 Apache 实例，则状态流图不再适用，因为 Apache 实例不共享它们的状态。我猜想 WebLogic 插件维护一个带有方向映射 [IPAddress+Port -> JVMID] 的状态。如果它收到一个带有它还不知道的 JVMID 的 cookie（例如，它从未向该服务器发送请求），它无法知道它所指的是哪个 IPAdress+Port，因此它将无法重用这些 JVMID，它将重新分配新的主要/次要 JVMID，这对于 2 个实例（可能交换）是相同的，如果严格超过 2 个实例，它们可能会有所不同。我没有通过运行特定测试来确认它，但在纸面上它似乎并非在所有情况下都有效。

回答by user2557938

The answer is yes. We've got a write up of this on our blog http://blog.c2b2.co.uk/2012/10/basic-clustering-with-weblogic-12c-and.htmlwhich provides step by step instructions on setting up web session failover in a cluster.

答案是肯定的。我们已经在我们的博客http://blog.c2b2.co.uk/2012/10/basic-clustering-with-weblogic-12c-and.html上写了这篇文章，其中提供了有关设置的分步说明集群中的 Web 会话故障转移。

Essentially the jsessionid cookie encodes the primary and secondary weblogic servers. Mod-wl parses the cookie and routes the request to the primary server. In your case Managed Server 1. If it is down it will automatically route the request to the backup server Managed Server 2.

本质上，jsessionid cookie 对主要和辅助 weblogic 服务器进行编码。Mod-wl 解析 cookie 并将请求路由到主服务器。在您的情况下托管服务器 1。如果它关闭，它将自动将请求路由到备份服务器托管服务器 2。

回答by Joseph

The diagram above holds true for 2 Apache servers connected to the same WL cluster. The cookie session info contains details on what WLS to connect to and the plugin will respect that. If the primary (the server it originally connected to) WL server ins't available, then the request would be sent to the secondary server (designated such at the time of the first request based on the rules defined in selecting a "Preferred Replication Group"). This secondary server maintains the same session state as the primary WLS server and should be able to handle the request.

上图适用于连接到同一个 WL 集群的 2 个 Apache 服务器。cookie 会话信息包含有关要连接到的 WLS 的详细信息，插件将尊重该信息。如果主要（它最初连接到的服务器）WL 服务器不可用，那么请求将被发送到辅助服务器（根据选择“首选复制组”中定义的规则在第一次请求时指定”）。此辅助服务器与主 WLS 服务器保持相同的会话状态，并且应该能够处理请求。

If session replication isn't setup (I think this is OFF by default), then there would be no session copied to another server and if the original/primary WL server goes down, you lose the session.

如果未设置会话复制（我认为默认情况下这是关闭的），则不会将会话复制到另一台服务器，如果原始/主要 WL 服务器出现故障，您将丢失会话。

回答by Shankha

The answer is NO. As you have 2 Apache webserver, you need to implement stickiness at both hardware and software loadbalancer level in order to achieve your requirement.

答案是不。由于您有 2 个 Apache 网络服务器，您需要在硬件和软件负载均衡器级别实现粘性才能满足您的要求。

Means you already have sticky session implemented in Weblogic plug-in for Apache level, but you also need Source IP based stickiness at the hardware loadbalancer level. This will allow your hardware loadbalancer to send the subsequent request from same user to same apace web server.

意味着您已经在 Apache 级别的 Weblogic 插件中实现了粘性会话，但您还需要在硬件负载均衡器级别基于源 IP 的粘性。这将允许您的硬件负载均衡器将来自同一用户的后续请求发送到同一 apace 网络服务器。