Load balancer is an infra component in a network architecture used to manage the incoming requests to backend servers. Configuration at the load balancer determines the type of the HA Cluster. URL or IP or Port based routing configuration can be achieved in this layer. This device can also act as a reverse proxy when required.
The device will also have the provision to setup stickiness of the session, so that interruption in signaling and session connection is handled efficiently.
I.e., If requests from the users’ network (internet) are distributed to back-end application then it will be HA Active-Active setup.
If requests are routed only to primary server and to secondary (DR) during fail overs, then HA cluster is Active-Passive.
Configuration:
- When there is a web server (such as Tomcat) behind a load balancer, and has an application deployed which maintains a 'user sessions', it is important to make sure all the requests for a single user session is routed to same WebServer (Tomcat). If the LB keeps distributing the requests among all Tomcat servers, the application logic will fail to execute because it requires a user session to be there.
- To achieve this, a concept called 'session stickiness' is used. Load balancers has the ability to configure session stickiness which ensures the requests from a particular user session is sent to the same Web Server (Tomcat).
- A 'COOKIE' is used in achieving the session stickiness.
- For TCommProxy/ChatProxy, the cookie name is "JESSIONID".
- The "JSESSIONID" is created and inserted into each RESPONE by the 'livechat api'. The load balancer can detect this cookie and create a record in LB to map JSESSIONID to Web Server ID.
- Every subsequent requests coming from livechat sdk (UI/VIVR/ChatBot) will have the JSESSIONID cookie which got generated by server in the first response. When the request reaches LB, it can detect the JSESISONID cookie and find out the mapped Web Server ID. Then LB will forward the request to particular Web Server.
- Cookie Persistence Timeout should be more than the average user session active duration.
Troubleshooting:
LB will generate a cookie and insert to the session in the first request. Browser or client console can display the cookies used for the session. Client should send same cookies for every subsequent requests. If client fails to send then stickiness will not work. The cookie value for any signaling URL request should remain constant throughout the session. Constant cookie value acknowledges the stickiness of the client and server session. Screen shot below is for VIVR application where '/api' is the for which JSESSIONID is inserted at LB.
Most of web application running on a Tomcat might have cookie named as 'jsessionid' (all small letters) which might create some confusion with chat API's JSESSIONID. So, make sure you verify the case sensitivity and the application path (i.e /api) while checking the cookie.
When the TComm Proxies are deployed behind a LB and the LB has not configured the JSESSIONID cookie correctly, the UI application will face below behaviors:
The UI application will keep getting "No Session Found" errors. And if you check the TComm proxy logs, there should be a keyword 'UnOpenedSessionNotAllowed'. If this keyword is present, it is a strong indicator that there is something wrong in LB session stickiness.
References:
- https://javarevisited.blogspot.com/2012/08/what-is-jsessionid-in-j2ee-web.html#axzz721H78GWK
- https://swagger.io/docs/specification/authentication/cookie-authentication/
- https://www.f5.com/services/resources/white-papers/cookies-sessions-and-persistence
- https://www.haproxy.com/fr/blog/load-balancing-affinity-persistence-sticky-sessions-what-you-need-to-know/
- https://techdocs.f5.com/en-us/bigip-14-0-0/big-ip-local-traffic-manager-implementations-14-0-0/configuring-http-load-balancing-with-cookie-persistence.html
