11.0

© 2014 ABBYY Production LLC. All rights reserved.
95
4. You can use the Performance Monitor for IIS (accessible through the toolbar of the Microsoft Management
Console (MMC)) 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).
Selecting the Unicast or Multicast Method of Distributing Incoming Requests
The choice between the Unicast and Multicast methods depends on your network configuration. A detailed description
of the two methods can be found on the Microsoft website.
Balancing Workloads in the Cluster, Setting Up Hosts
You can set up cluster traffic to be balanced and filtered by ports.
ABBYY FlexiCapture requires the TCP protocol for its operation. There are two filtering modes: Single Host and Multi-
ple Host.
Single host
This mode provides fault tolerance, but does not allow load 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 nodes. You can also 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. Microsoft SQL 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 spec-
ify a shared 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, give full access permissions for the database to all users on all 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 computer NodeN, you must give full access permissions to the user DomainName\NodeN$ on the SQL
Server.
7. If the Application Server is not unavailable 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 (usually this folder already contains an iisstart.htm file) and open this file in
a browser: \\ClusterAddress\iisstart.htm. Pay attention to the proxy server settings in your browser when
opening the file.
Running Server Application 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; now any client may 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 comput-
ers, and the actual user name will change accordingly: on the computer node1, the user name will be node1\User,
while on the computer node2, 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.