Data & System Availability

Data & System Availability - Failover sites

Storage replicated failover site

The story doesn't end when the datacenter is protected against hardware component failures. Bigger calamities can cause a whole site to fail because of a flood or fire or simply because of a power outage that lasts longer than UPS's can handle. There are different scenarios that help insure against these kinds of catastrophes. Requirements on how much data may be lost (Recovery Point Objective, RPO) and how long systems can be down (Recovery Time Objective, RTO) dictate the right solution.

First of all, to failover to another site, the data has to be available there. It's a matter of requirements what the right method of replication is. If no data can be lost, the only option is synchronous replication. This is however the most critical and expensive solution. With asynchronous replication, the data loss is typically very low, but not zero. The disadvantage of storage replication is that it's unaware of applications or data consistency. If data corruption occurs on the main site, it gets replicated to the standby site immediately.

Once the data is available at the failover site, servers are needed to access it and provide services. Servers at the recovery site can be virtual as well as physical, identical to the main datacenter. With physical servers it is generally speaking more difficult to deliver services again than it is with virtual servers. The main reason for this lies in the fact that virtual machines are hardware independent and can move, even without downtime, from one physical machine to another. When a fallout of the main site takes longer, data changes by clients and applications need to be backed up. This means that a replication site that can take over production needs its own full offsite infrastructure.

Application replication failover site

In order to replicate on application level, both sides need to have an active server. These servers run an application that has its own method of synchronizing application data. For example, databases or mail servers store transactions in local log files that are transmitted to a secondary system. This passive system injects the transactions logs into its own copy of the data. This method can result in data loss if closed transactions on the main site are not replicated to the standby system before the main system crashes. If setup properly this data loss can be minimized but will never be zero. The advantage of having application replication is that the standby system can be guaranteed to be consistent.