session - Google Compute Engine 负载平衡保持 session

Question

我在谷歌的机器上有 2 台 TomEE 服务器。他们都服务于同一个应用程序。Web 应用程序具有带有 jaas 的登录页面。两台服务器都使用同一个数据库。当我尝试单独访问服务器时，一切正常。

但是当我尝试通过负载均衡器访问时，看起来负载均衡器在两个服务器之间跳转我的请求，因此我的网络应用程序无法正常工作，因为我没有登录的虚拟机拒绝了我的请求。

我的问题是如何在负载平衡服务器时使 session 正常工作？

Answer 1

您想查看 sessionAffinity feature负载均衡器。

具体来说，根据 the load balancer target pool docs :

sessionAffinity

[Optional] Controls the method used to select a backend virtual machine instance. You can only set this value during the creation of the target pool. Once set, you cannot modify this value. The hash method selects a backend based on a subset of the following 5 values:

• Source / Destination IP
• Source / Destination Port
• Layer 4 Protocol (TCP, UDP)

Possible hashes are:

• NONE (i.e., no hash specified) (default)

  5-tuple hashing, which uses the source and destination IPs, source and destination ports, and protocol. Each new connection can end up on any instance, but all traffic for a given connection will stay on the same instance if the instance stays healthy.

• CLIENT_IP_PROTO

  3-tuple hashing, which uses the source and destination IPs and the protocol. All connections from a client will end up on the same instance as long as they use the same protocol and the instance stays healthy.

• CLIENT_IP

  2-tuple hashing, which uses the source and destination IPs. All connections from a client will end up on the same instance regardless of protocol as long as the instance stays healthy.

5-tuple hashing provides a good distribution of traffic across many virtual machines. However, a second session from the same client may arrive on a different instance because the source port may change. If you want all sessions from the same client to reach the same backend, as long as the backend stays healthy, you can specify CLIENT_IP_PROTO or CLIENT_IP options.

In general, if you select a 3-tuple or 2-tuple method, it will provide for better session affinity than the default 5-tuple method, but the overall traffic may not be as evenly distributed.

Caution: If a large portion of your clients are behind a proxy server, you should not use CLIENT_IP_PROTO or CLIENT_IP. Using them would end up sending all the traffic from those clients to the same instance.