Table of Contents
Creating a backup index solution using unions
How to configure a backup index solution for basic fault tolerance using unions in Index Manager Enterprise.
30. April 2025
Table of Contents
How backup indexes work
When creating a union, you can attach member indexes to it. After adding 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 so that when a client search comes in, 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 keep 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 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 screenshot below 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 primary union member then 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).
As you see, at this point, the union differs very little in functionality from a standard archive setup with a regular Index Manager archive. However, the difference lies in what happens when the primary union member goes offline, for instance, because of network problems, a server restart, 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 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.)
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 backup union member then carries out the search, 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.
