Content

Concept:

In a distributed Datacap environment we often see this type of topology:

Here load balancers are placed at 3 levels:

1. Between users and ICN/WAS servers
2. Between ICN/WAS and wTM servers
3. Between wTM and TMS servers

While load balancers can provide scalability and high availability, it is important that they are configured correctly to avoid introducing functional errors. There are a variety of load balancers available today, but all of them have some basic common properties which are discussed in following section.

LB Configuration parameters:

Following things need to be ensured while configuring LB for Datacap :

1. Session persistence:

To understand this parameter, first you need to understand the type of sessions maintained by Datacap components.

HTTP(s) sessions can be persisted by cookie or by source IP. Cookie is preferred. For Datacap Navigator, the cookie name is “JSESSIONID”, for wTM the cookie name is “wTmId”.

TCP/IP sessions must be persisted based on source IP. All connections / requests from a given wTM or TMWeb server instance (with own IP) will be processed by one TM Server

2. Persistence timeout:

LB session timeout must always be longer than application session timeout, e.g. default Navigator session timeout is 20 mins so the LB persistence timeout should be 25 mins.

3. Request timeout:

Request timeout defines for how long the LB should wait before marking a request as failed. The default would be 30 secs for http(s) requests. However, in some scenarios (like rule execution) a request can take longer to complete depending on the configured rulesets.

4. Request buffer length:

The load balancers usually have a default buffer length for every request. Normally you will not need to change this setting unless you see some issues with a particular LB implementation. For example if you find that the requests are getting delayed when going through LB, and you see lot of connection drops, you may need to increase the buffer length.

5. Load balancing method:

There are some commonly used load balancing methods. Most popular are – round robin and least connections.

You can choose other methods as per requirement, but make sure that the session persistence works with the selected method.

6. Additional cookies:

If you are developing a custom client that is calling wTM rest APIs and if there are more than 1 wTM servers with a load balancer to distribute load, then this is something you need to consider while writing code for the custom client.

Some load balancers introduce an additional cookie along with the wTmId that is returned by the wTM Logon request. In such a scenario, the client must maintain both the cookies and send them along with each request going to wTM server in a session.

References:

• Knowledge Center https://www.ibm.com/support/knowledgecenter/en/SSZRWV_9.0.0/com.ibm.dc.install.doc/dcplb001.htm
  • “TCP/IP sessions are inherently persistent and there is no need for the load balancer to persist Datacap Server sessions. However, you might want to configure the load balancer to persist sessions based on the client IP address to force all threads from any Rulerunner server to use the same Datacap Server.”
• Datacap Load Balancing Tech Note
  • https://www.ibm.com/support/pages/datacap-highly-available-configuration
• MS article :  http://ilantz.com/2013/01/14/tcpip-keepalive-session-timeout-rpc-timeout-exchange-outlook-and-you/
  • Consider modifying the server TCP/IP KeepAlive to reduce the chance of “IDLE” connections being terminated – (Default is Two hours – The recommended value is 30 minutes , and no less then 15 minutes) – this controls the OS TCP behavior with idle connections, could greatly improve responsiveness and scalability – http://support.microsoft.com/kb/314053/EN-US
  • Make sure that you are aware of any router, firewall or any other network device that is placed between your clients and your servers. Once you do – note their session timeout, session TTL or session ageing setting for the relevant protocol and port! (this could be tricky, so do not treat this lightly)
  • The trick for success here is that timeout settings should be configured without overlapping one another while following the client access “path” – for example – Client > FW > Load Balancer > Server, with increasing timeouts
• HAProxy: http://blog.haproxy.com/2012/03/29/load-balancing-affinity-persistence-sticky-sessions-what-you-need-to-know/