Issues concerning using Google Global Load Balancer with JasperReports Server (JRS)

Configuring Google Global Load Balancer (GLB) With Sticky Session

JasperReports Server (JRS) supports partial session replication but not full replication, the load balancer must be configured so that browser users are always connected to the same server during a continuous session. This requirement is referred to as "sticky or pinned sessions" (refer to https://community.jaspersoft.com/documentation/tibco-jasperreports-server-ultimate-guide/v790/session-management-and-failover). 

To fulfill this requirement, when using Google Global Load Balancer (GLB) to host multiple JRS instances, our users deploy a "ring hash" load balancing strategy. The ring hash approach is used for both “sticky sessions” with a cookie and for “session affinity” based on primarily the client IP address to send all requests from a given client to the same server node.

The Challenge

However, with the ring hash load balancing strategy, our users had discovered based on their trial run, that all their 300 users' requests only hit one JRS node defeating the LB distribution functionality. There's an inherited tradeoff with ring hash which can be more challenging to evenly distribute workload because the hashing is involved with the distribution of keys or requests in the system. To support full session replication in order to lift the restriction on sticky session requirement and avoid use ring hash, JRS will have to go through a major architecture design change to make it possible.

Recommendations to GLB System Admin 

- Ensure that the hash keys are well-distributed across the ring. If the keys used for hash mapping are not distributed uniformly across the ring, it can lead to hotspots where all requests are directed to the same node.

- Verify that the hash function used is suitable for the specific use case. If the hash function has poor distribution properties, it can lead to an uneven distribution of keys and, consequently, uneven traffic to the server nodes.

- Adding more nodes to the hash ring can help mitigate this issue. With only a few nodes, the distribution of keys is inherently less even.

- Using a hash function with a low collision rate and handling collisions properly is important. Hash collisions occur when different keys or requests are mapped to the same position on the hash ring which can lead to uneven distribution.

- Implement weighted distribution to account for data skew. If certain keys or requests are more common than others, this can lead to uneven distribution.

- Explore the option to use L7 proxy for round robin load balancing.

Reference Materials

https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/load_balancing/load_balancers

https://blog.getambassador.io/load-balancing-strategies-in-kubernetes-l4-round-robin-l7-round-robin-ring-hash-and-more-6a5b81595d6c#:~:text=the%20given%20service.-,Ring%20hash,client%20to%20the%20same%20Pod

https://www.toptal.com/big-data/consistent-hashing

============================

TTC-20231017