Google Compute Engine 负载平衡保持会话
Google Compute Engine load balancing keep session
我在 google 的机器上有 2 个 TomEE 服务器。他们都服务于同一个应用程序。
Web 应用程序具有带有 jaas 的登录页面。两台服务器都使用同一个数据库。
当我尝试分别访问服务器时，一切正常。
但是当我尝试通过负载均衡器访问时，看起来负载均衡器在两个服务器之间跳转我的请求，因此我的网络应用程序无法正常工作，因为我没有登录的虚拟机拒绝了我的请求.
我的问题是如何在负载平衡服务器时使会话正常工作？
你想看看负载均衡器的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.
我在 google 的机器上有 2 个 TomEE 服务器。他们都服务于同一个应用程序。 Web 应用程序具有带有 jaas 的登录页面。两台服务器都使用同一个数据库。 当我尝试分别访问服务器时，一切正常。
但是当我尝试通过负载均衡器访问时，看起来负载均衡器在两个服务器之间跳转我的请求，因此我的网络应用程序无法正常工作，因为我没有登录的虚拟机拒绝了我的请求.
我的问题是如何在负载平衡服务器时使会话正常工作？
你想看看负载均衡器的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_PROTO3-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_IP2-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_PROTOorCLIENT_IPoptions.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_PROTOorCLIENT_IP. Using them would end up sending all the traffic from those clients to the same instance.