Redundant Network Monitoring With Intermapper

 

Redundant monitoring is achieved by having two Intermapper servers with an identical set of maps. If the primary Intermapper server fails or loses connectivity, the secondary Intermapper server continues to monitor the network. For optimal results the Intermapper servers should be connected to two different points on your network.

Using two Intermapper Servers to achieve redundant monitoring requires regular synchronizing of maps from the primary server to the secondary server. Day-to-day map editing and probe updates are done only on the primary server.

The easiest way to synchronize is to use a script based on the Intermapper HTTP API. The HTTP API is described in the Intermapper Developer Guide.  Examples of the following scripts are found in the Intermapper User Guide:

• for Linux/Mac, cloneim.sh found in InterMapper_Settings/Scripts
• for Windows, cloneim.vbs found in InterMapper Settings\Scripts

You can run the script on the secondary server, say, once per day. The Intermapper on the secondary server must be stopped when you run the script, and restarted afterwards. The Intermapper on the primary server can be left running. The script copies the contents of the Custom Icons, Sounds, MIB Files, Probes, Tools, Web Pages, Fonts, Extensions, and Maps folders from the primary server to the secondary server. The contents of the Chart Data and Intermapper Logs are not copied.

With this approach both the primary and secondary Intermapper servers are active, and both generate notifications. This may seem less than ideal, but it has an advantage. Since the primary and secondary servers are connected to different points on the network, they see things from different perspectives. From time to time one server will see problems the other doesn?t and vice versa, because of network vagaries occurring between the Intermapper servers and the devices that are being monitored. Having two perspectives is useful to help differentiate whether problems are caused by the network or by non-network-related issues.