Skip to main content
The Administration and Monitoring Console and the web stations are clustered together.
An NLB (Network Load Balancing) cluster is used to install the Application Server as well as the Administration and Monitoring Console and web stations that use the IIS (Internet Information Services) service. To balance the workload and improve request processing speed, the Application Server can be deployed in an NLB cluster. Detailed information about the Network Load Balancing feature is available on this page of the Microsoft website.

​
Setting up an NLB cluster for the Application Server

In this section, you will find step-by-step instructions for setting up an NLB cluster for the Application Server. The Administration and Monitoring Console and the web stations are clustered together with the Application Server. A detailed overview of NLB cluster settings can be found on the Microsoft website.
The addresses, computer names, domain names, etc. used below are not mandatory and may be changed by the administrator.
Setting up the cluster To set up the cluster, complete the following steps:
  1. Install the Application Server on each cluster node. The database, file storage folder, Processing Server, Licensing Server, and Application Server clients must be located on a different computer, which must be accessible to all nodes in the cluster.
  2. In Windows Features, add Network Load Balancing to each node in the cluster. This is done by clicking the Add Features link in the main window of the Server Manager (click Start → Administrative Tools → Server Manager).
  3. Assign an IP address to the cluster via which the cluster can access the nodes as a unit (this will be a virtual cluster address). To do this, open the Network Load Balancing Manager on any of the nodes (click Server Manager → Tools → Network Load Balancing Manager) right-click the cluster and select the Cluster Properties item on the shortcut menu.
If a single network interface is used for client/cluster traffic and other network traffic on the nodes (as is usual in Multicast mode), each host in the cluster must have a dedicated IP address (in addition to the virtual address, which is common to all cluster nodes). A host will use its dedicated IP address instead of the virtual cluster address for incoming connections to the cluster nodes over Telnet, SSH, and other protocols, and for outbound connections from the cluster nodes.
All cluster nodes must receive all incoming cluster traffic. The balancing algorithm determines which cluster node should respond to a given query. The choice between Unicast and Multicast depends on your network configuration.
  1. You can use the Performance Monitor for IIS (accessible through the toolbar of the Microsoft Management Console) to monitor node activity. In the Web Service object, for each node, add the ISAPI Extension Requests/sec counter for Default Web Site (this is the location of the Application Server in the IIS).
Operating mode of the cluster The choice between the Unicast and Multicast methods depends on your network configuration. A detailed description of the two methods can be found on this page on the Microsoft website. Balancing workload in the cluster and setting up hosts You can set up cluster traffic to be balanced and filtered by port. ABBYY FlexiCapture requires the TCP protocol for its operation. There are two filtering modes, single host and multiple host.
  • Single host
    This mode provides fault tolerance but does not allow workload balancing. Only one cluster node is active at a time.
  • Multiple host
    Traffic from a predefined range of ports is handled by the node with the highest priority in the cluster. All cluster nodes function simultaneously. This mode provides both workload balancing and fault tolerance.
Traffic from a predefined range of ports is balanced among the nodes. Additionally, you can set the Affinity parameter to:
  • None (not recommended)
    If this option is selected, multiple connections (TCP sessions) from a single client can be handled by different nodes.
  • Single (recommended)
    If this option is selected, all connections from a single client are handled by one node.
  • Network (Class C) (recommended)
    If this option is selected, all queries from the TCP/IP Class C address space are handled by one node. This may be necessary if there is a proxy server between the client and the cluster.
Setting up the Application Server Complete the following steps to set up the Application Server:
  1. Create a shared folder that can be accessed by all of the nodes in the cluster.
  2. Install Microsoft SQL Server, an Azure server,an Oracle server, or a PostgreSQL server. The server must be available to all cluster nodes.
  3. Install the Application Sever on all cluster nodes.
  4. On the first cluster node, run the Administration and Monitoring Console and create a database and specify a shared folder for file storage.
  5. On each of the remaining cluster nodes, run the Administration and Monitoring Console and connect to the database you created.
    Important! For this operation, SQL authentication must be used.
  6. On the SQL Server, the Azure server, the Oracle server, or the PostgreSQL server, give full access permissions for the database to all users on all of the cluster nodes under whose accounts IIS is running (the World Wide Web Publishing Service must be running in the service list). Permissions for the first node are given automatically when the database is created. Other permissions must be given manually. By default, IIS runs under the user Network Service. In this case, assuming IIS is running on a computer named NodeN, you must give full access permissions to the user DomainName\NodeN$ on the server.
  7. If the Application Server is not available in the cluster, but PING requests still reach the cluster, check if IIS is available in the cluster. To do this check, place a static *.html file in the folder %systemdrive%\inetpub\wwwroot (typically this folder will already contain an iisstart.htm file) and open this file in a browser: \ClusterAddress\iisstart.htm. Check the proxy server settings in your browser when opening the file.
Running Application Server clients We recommend that you place all cluster nodes in one domain and run Application Server clients under domain user accounts. Running Application Server clients under local user accounts is not recommended for the following reason. In the usual (i.e. non-clustered) configuration of the Application Server, the following authentication method may be used: on the computer where the Application Server is installed, a local user is created, with its own user name and password; then any client will be able to connect to the Application Server under this user’s account. In a clustered configuration, the Application Server that processes client requests may be placed on different computers, and the actual user name will change accordingly: on the node1 computer, the user name will be node1\User, while on the node2 computer, the user name will be node2\User. This may disrupt the operation of the system. Running Application Server clients under domain users avoids this problem. To connect clients on remote computers which are not in the domain, you can use basic authentication and a user account in the domain to which the cluster belongs. Suppose the clustered Application Server is in the cluster domain and the computer of the verification operator is not in this domain. All you need to do is create in the cluster domain an account for the user cluster\VerificationOperator and communicate the account name and password to the verification operator. Now the verification operator will be able to connect to the Application Server using this account and basic authentication on the Verification Station.
To use basic authentication for clients, be sure to enable basic authentication for the folder FlexiCapture12\Server in IIS. Otherwise, users will get an HTTP 401 error when attempting to connect.