Table of Contents
Configuring indexes for load balancing using unions
How to configure a load balancing solution using unions in Index Manager Enterprise.
30. April 2025
Table of Contents
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: Backup, Parallel, and Round Robin.
A 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 others for hosting 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 use only two Index Manager servers, one of which 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 balances 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 primary union member carries out the search, 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,r 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.
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 screenshot below):
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 inaccessible, 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 continue receiving search requests until the primary union member returns 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.
