Skip to main content
Documentation & User Guides | Fotoware

Configuring indexes for load balancing using unions

How to configure a load balancing solution using unions in Index Manager Enterprise.

How load balancing works

When creating a union you can attach member indexes to it. Having added a primary index, you can add a secondary index as well and choose the type of backup solution you would like to use.

You have three options: BackupParallel , and Round Robin.

Round Robin solution works such that when a search comes in from a client, it is distributed 50%-50% between the primary and the secondary member index. Should one of the index servers fail, the union will distribute searches to only the active index and poll to see if the other one comes back online again and then switch back to 50-50 load balancing when that happens.

Prerequisites

For this scenario to work satisfactorily, it stipulates three Index Manager servers; one for hosting the union and two other ones to host the primary and secondary index. Both member servers are configured identically and may for example index document folders on a SAN.

While it is possible to make do with only two Index Manager servers, where one of them hosts the union service, this is not a recommended setup. If the main Index Manager server fails, the union service will also stop, rendering the backup server unusable.

Example setup

The standard setup is almost as described for a passive backup union scenario. The difference is that the backup union member is always online and accessible. A round-robin backup is used to balance the load on the Index Manager servers. The search requests are evenly distributed between the primary and the backup union member, with the first search going to the primary union member, the second to the backup union member, the third to the primary union member, and so on.

 

During normal operation, a client sends a search request to the Enterprise server (1), which in turn forwards the request to the primary union member (2). The search is carried out by the primary union member and the search result is returned to the Enterprise server (3), which in turn passes it on to the client (4). The next search request sent from the client to the Enterprise server (5) is now forwarded to the backup union member (6). The search is carried out by the backup union member and the search result is returned to the Enterprise server (7), which in turn passes it on to the client (8).

The next search request sent from the client to the Enterprise server is now forwarded to the primary union member, and so on.

800_appg.1.jpg

If the primary union member fails (note that the same would apply if the backup union member fails), then the situation is as follows (see the below screenshot):

A client sends a search request to the Enterprise server (1), which in turn forwards the request to the primary union member (2). Since the primary union member is not accessible, the search will time out after a while, and the client will receive a “Search Failed” error message. (The search timeout period is set when adding the primary union member to the union, and it can be changed by selecting the primary union member in question and clicking on the Properties button.)

The next search from the client is sent to the Enterprise server (3) and then forwarded to the backup union member as expected (4). The backup union member will now continue to receive search requests until the primary union member comes back online. Note that the Enterprise server continues to send search requests to the primary union member (4b) in an attempt to see if it becomes active again. The moment it does become active, the system returns to normal operation as described at the beginning of this chapter (i.e. round-robin distribution), and the distribution of searches between the primary and the backup union member is restored.

 

800_appg.2.jpg

 

  • Was this article helpful?