High availability and load balancing

Although it is possible to run all Datacap components on a single server, it is rarely done for several reasons, which include the need for redundancy and scalability. In this section, we describe high availability and load balancing options in Datacap version 9. For the purposes of this description, we refer to high availability and load balancing as simply “load balancing.” Load balancing is a method for scaling a system horizontally by distributing the work across many compute nodes in a “farm.” It also provides high availability by redirecting clients to a working node in case of failure. A load balancer presents a single address for communication with multiple servers, for one or more Datacap applications. Configure the load balancer to send requests that are directed to each pooled or balanced address to one of the servers in the farm. You can select round-robin scheduling or another method.

Clients access the Datacap server by using a TCP/IP socket-based protocol. You configure the server’s name or IP address and port in Datacap Application Manager. The server normally listens on port 2402, but you can change the port in Datacap Server Manager. In that case, you must also configure the port number in Datacap Application Manager.

The socket keeps the TCP/IP session active until the client disconnects. As a result, the load balancer connection for Datacap server must not be persistent. If a load-balanced server fails, further client requests will be directed to a different server. In that case, the older session will be invalidated and the user or client will have to log in again. Any outstanding server requests will terminate unsuccessfully, and any batches that were in process using that server will typically be left in running status. Users who logged in to this server will receive an error message and must log in again. Datacap Maintenance Manager can be used to reset batches left in error state so they can be processed by another server.

Datacap Web Servers can also be farmed. Designate one or more IP addresses or ports on your network for your Datacap website home pages. Client browsers connect to this load balancer port using HTTP or HTTPS protocol. Configure your load balancer to redirect those requests to individual web servers using round-robin scheduling or another method. Ports 80 and 443 are standard. You can configure an alternate port in Microsoft IIS Manager.

Datacap Web uses session cookies, so you must configure the load balancer to persist sessions based on the client’s IP address. Set the load balancer’s session time-out to match the IIS session time-out. If a Datacap Web Server fails, users who connect to the failed server receive an error message and must log in again.

Datacap Web Services can run on IIS or as a Windows service and can be farmed. Clients connect to the address and port for the load balancer and are redirected to a specific server. Sessions must be persistent, based on the client IP address, and the session time-out must match that of the web service. Failure of a web services server will generate an error for requests in progress. The requested operations might or might not have completed.

Datacap Report Viewer servers can be farmed, Clients connect to an address and port for the load balancer and are redirected to a specific server. Sessions must be persisted, based on IP address, and the session time-out must match that of the IIS server. Failure of a Report Viewer server will end any existing sessions.

Datacap Fingerprint Service can be farmed if the fingerprints are static during normal system operation. Updates and deletions of fingerprints are not synchronized automatically between servers. Fingerprint servers must either be restarted or their contents programmatically reset to keep them synchronized if changes are made to the set of fingerprints.

Datacap Rulerunner Servers independently poll Datacap servers for pending work, they do not require or benefit from load balancing. To achieve redundancy of servers, threads should be duplicated on at least one additional server. For example, if Rulerunner server A has a thread running for Application 1, Profiler and Export, setting up an Application 1, Profiler and Export, thread on server B provides redundancy.

Table 3-1 summarizes load balancing options for Datacap servers. Table 3-1 Load balancing options

Grant network access to the back-end server addresses if possible. This makes initial setup and subsequent problem solving much easier. Test your system without load balancing at first. Add load balancing to one component at a time, reconfiguring as needed, and testing each balanced address, including failover to each back-end server, before moving on to the next component. If policy requires that you disable connections to the back-end servers, be prepared to re-enable for troubleshooting, if required.

Figure 3-13 illustrates a sample load balanced architecture.

Figure 3-13 Sample load balanced architecture

Server Load-balanced Protocol

Datacap server Yes TCP/IP socket

Datacap Web Services Yes, persistent connections HTTP/HTTPS

Datacap Web (IIS) Yes, persistent connections HTTP/HTTPS

Report Viewer (IIS) Yes, persistent connections HTTP/HTTPS

Fingerprint server (IIS) Yes, persistent connections HTTP/HTTPS

Rulerunner Yes

Content Navigator (withWebSphere

Application Server)

For more information, see the IBM Technote titled “Load Balancing and Farming Datacap Servers”: