How to configure a union to produce the fastest possible search result
Explains to configure a parallel index solution that competes to deliver the search result to the client using unions in Index Manager Enterprise.
How a parallel backup index works
When creating a union you can attach member indexes to it. Having added a primary index, you can add a secondary one as well and choose the type of backup solution you would like to use.
You have three options: Backup, Parallel , and Round Robin.
A parallel solution works such that when a search comes in from a client, it is forwarded to both attached indexes. It then returns the search result to the client from the server that responds fastest.
If one of the indexes should fail for any reason, the union will query the remaining index and keep on polling to see if the failed index comes back online, in which case it will shift back to doing duplicate searches.
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 below screenshot outlines how a complete backup solution may be set up.
Under normal operation, a client sends a search request to the Enterprise server (1), which in turn forwards the request to the primary and backup union member (2a and 2b). The search is then carried out by both primary and backup union members, and the search result is returned to the Enterprise server (3a and 3b). The search result that reaches the Enterprise server first, is immediately sent back to the client (4), while any search result reaching the Enterprise after the first one is simply ignored.
The below screenshot illustrates how the system functions if the primary union member fails:
If the primary union member fails (note that the same would apply if the backup union member fails), then the situation is as follows:
A client sends a search request to the Enterprise server (1), which in turn forwards the request to the primary and backup union member (2a and 2b). The primary union member is not accessible, and the search sent to this union member (2a) will time out after a while. Since the backup union member is online and accessible, the search is carried out by this union member (2b), and the search result is returned to the Enterprise server (3). Since this search result naturally will be the first search result the Enterprise server receives, it is immediately sent back to the client (4).
As you see, at this point the setup differs very little from the passive backup setting where a primary union member fails. The most important difference is that no search requests are lost. While a passive backup member only becomes online and available when the primary member fails to respond, a parallel backup member is always active and online.