High Availability for Uptime Infrastructure Monitor

Contents

Overview

The purpose of this article is to outline a few implementation options that provide high availability to an Uptime Infrastructure Monitor environment. The options shown are sample configurations that customers have deployed and are not the only options available. Which option to choose will largely depend on the desired level of availability and redundancy.

Each option has an Uptime Infrastructure Monitor instance called Self Monitor. The sole purpose of Self Monitor is to monitor vital health and performance information of Uptime Infrastructure Monitor and execute any self-healing actions if needed. It is tuned to consume very little resources.

Uptime Infrastructure Monitor Overseer

The goal of this option is to ensure the availability of the production Uptime Infrastructure Monitor instance by configuring a Self Monitor instance. Alerts will be sent out when the production instance is down or degraded. Moreover, self-healing actions can be performed to minimize downtime of the production instance. This option will ensure the production instance does not silently become unavailable.

The advantage of this option is it's simple to setup and it's cost-effective. The downside is it does not offer any redundancy. However, it does provide alerts and self-healing capabilities that would increase Uptime Infrastructure Monitor availability.

Partial Redundancy

In addition to Self Monitor monitoring the production instance of Uptime Infrastructure Monitor, this option consists of a Passive instance on standby. The Active and Passive instances share a single database so that the configuration and historical data will be consistent. Self Monitor monitors whether the Active instance is available and when it's unavailable, Self Monitor will execute actions to failover to the Passive instance by starting the Uptime Infrastructure Monitor services. Self Monitor also monitors the database so alerts will be sent when it's unavailable and self-healing actions can be executed.

This option is in the middle of the pack in terms of availability, simplicity and budget-friendly. It offers redundancy by having a Passive instance of Uptime Infrastructure Monitor on standby. When needed, Uptime Infrastructure Monitor can failover to the Passive instance. The single point of failure is the database in this option. One needs to be cautious and make certain the database is backed up regularly.

Full Redundancy

This option not only has redundant instances of Uptime Infrastructure Monitor, it also utilizes redundant databases. Similar to the previous option, Self Monitor monitors the Active and Passive instances of Uptime Infrastructure Monitor and the databases. The Master database is connected to the Active instance and the data is replicated to the Slave database. A few failover scenarios can occur:

• If the Active instance is down, the Passive one can be started
• If the Master database is down, the Active instance can connect to the Slave database
• When the Passive instance is connected to the Slave database, if the Slave database goes down, the Passive instance can connect to the Master database

As with the other options, alerts will be sent out if any of the components are down or degraded and self-healing actions can be executed to attempt to recover prior to failover.

This option offers the most redundancy due to the pair of Uptime Infrastructure Monitor instances and the pair of databases. However, with redundancy comes complexity and cost. There is more to configure and one will need more servers to implement such a configuration.

Summary

The above chart summarizes how each of the options compares to each other. Any of the options can be used and/or customized to meet the requirements.