Creating a backup index solution using unions
How to configure a backup index solution for basic fault tolerance using unions in Index Manager Enterprise.
How backup indexes work
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 backup solution works such that when a search comes in from a client, it is always forwarded to the primary member, while the backup index remains idle. However, if the primary member should fail for any reason, the union will shift the next incoming search to the backup index. It will still keep on polling to see if the primary index comes back online, in which case it will shift back to using the primary member.
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 union member (2). The search is then 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).
As you see, at this point the union differs very little from a standard archive setup with a regular Index Manager archive as far as functionality goes. However, the difference lies in what happens in the event that the primary union member goes offline, for instance, because of network problems, a server being restarted, hardware failure, or any other reason.
The below screenshot illustrates how the system functions if the primary union member fails:
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.)
Since the server is not available, this search request is lost. But now that the Enterprise server knows that the primary union member is unavailable, a new search sent from the client (manually, by the user) to the Enterprise server (3) is automatically forwarded to the backup union member (4). The search is then carried out by the backup union member and the search result is returned to the Enterprise server (5), which in turn passes it on to the client (6).
Note that all search requests will also be sent to the primary union member (4b) in an attempt to see if this union member becomes active again. (The moment it does become active, the backup member becomes idle once more and future searches are forwarded directly to the primary member again.) In the unlikely event that both the primary and backup union members fail, a client searching the archive will receive a “Search Failed” error message.