Google Compute Engine load balancing keep session

I have 2 TomEE servers on google's machines. they both serve the same application. The web application have login page with jaas and both servers work with the same DB. when I'm trying to access the servers separatly everything works fine.

but when I try to access via the load-balancer It's look like the load balancer hopping my requests between the two servers and therefore my web app not working well since the VM that I didn't login to rejects my requests.

my problem is how to make the session works well when loadbalancing the servers?

You want to look at the sessionAffinity feature of load balancer.

Specifically, per 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.