High Availability for up.time

Article Contents

• Overview
• up.time Overseer
• Partial Redundancy
• Full Redundancy
• Summary

Overview

The purpose of this article is to outline a few implementation options that provide high availability to an up.time 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. If the following does not suit your environment or if there are any questions, please contact [email protected].

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

The goal of this option is to ensure the availability of the production up.time 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 up.time availability.

In addition to Self Monitor monitoring the production instance of up.time, 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 up.time 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 up.time on standby. When needed, up.time 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.

This option not only has redundant instances of up.time, it also utilizes redundant databases. Similar to the previous option, Self Monitor monitors the Active and Passive instances of up.time 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 up.time 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.

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. If there are any questions, please contact [email protected].