What’s the difference between DNS failover and cloud failover and why should you combine both options for the most robust safeguard against a network outage?
If your business uses connected applications to provide services to customers, or your business relies on 100% website uptime, it’s vital to have a failover strategy in place should there be a block between the user and their destination (ie., where your app or site sits).
Failover refers to switching resources to an alternative destination should the original method of transfer be disrupted. Of course, this could happen along the route or it could happen closer to home – at the user. Wherever the failure happens, whether an internet carrier outage or an unavailable cloud datastore, it’s vital a failover strategy is put in place to re-route the traffic to its end destination, resulting in a seamless experience with little – or no – outage experienced by the user.
Cloud failover and DNS failover are two methods a business can implement to protect their systems, but how do both work and is there a way to implement the best of both worlds?
Why doesn’t cloud failover tick all the boxes?
All large-scale cloud vendors have multisite DNS where you can house your applications, whether in a localized data center or in other locations that can replicate fail architecture.
But what happens if you have a failure of equipment in the data centre, sitting in the cloud, and you have triple redundancies? If you replicated your data, you’d have replicated access for users too, and if one node fails, you can easily switch to the other nodes at the cloud provider’s multiple locations. This cloud infrastructure could create a pretty solid failover strategy, jumping around the locations to provide a seamless experience for the user.
However, the issue with relying on a cloud-only failover is two-fold. First, getting to the cloud that hosts the failover could be an issue if the problem sits between the user and the cloud, because there’s no route through. The second issue is trying to keep all the data in sync when you are in multiple locations. Although most cloud companies have that ability, it’s usually not free and not cheap if there is a fee involved.
So if you decide to use cloud failover as your primary security blanket and are using different cloud locations, it becomes a challenge for companies to replicate their data in each location.
Of course, once you’ve set up your failover chain strategy, you can use geolocation with DNS to decide how someone is routed if the application fails in their primary location. If there is a failure, then you send them to a secondary location. This way, you’ll use less network to get them there, offering a much faster way of re-routing traffic.
The benefits of DNS failover
DNS differs because it resets the DNS using A records if there’s a networking failure. Because DNS is the first thing in the session flow that happens, the traffic can be re-routed immediately by re-assigning the DNS and sending it to another location, without worrying about where the issue lies.
This means the failover strategy extends all the way out to the user, addressing many more types of problems than you would if you were cloud reliant for failover.
However, using DNS doesn’t absolve you from data synchronisation – it just isn’t designed for synchronising data. But because you’re making decisions way back at the user, you can be a lot more selective on where you direct them.
For example, if you’re using four cloud sites with a multi-tier back-up strategy. Your strategy may define your east coast failover methodology as having the west coast cloud as your primary back-up, then secondary as the Frankfurt, Germany cloud and then as a last resort an on-premises data center as the third failover point. For your west coast’s failover methodology your primary back-up is Germany and then the east coast cloud and then an on-premises data center. In this scenario, you don’t have to replicate the data in all places when using DNS.
You can choose closer locations for the data transfers to happen, making it faster and often cheaper than synchronising all the data in the cloud.
DNS Cloud Failover: the ultimate failover solution?
When DNS and Cloud Failover are combined, you get the benefits of both worlds. It’s important to note that with a combined offering, the advantages of both are being served for the appropriate reason and the type of application you’re trying to keep online.
DNS cloud failover won’t default to an expensive or limited approach, but it will use the most appropriate solution for the individual scenario. For example, DNS should never be used for any kind of database updates as a synchronisation option, because that’s not what it’s been designed for.
On the other hand, most cloud companies don’t have a comprehensive failover strategy unless they include failover across the internet, but that isn’t practical for situations – for example where there’s a problem between the user and the endpoint.
Using a combined solution with intelligent detection about where the issue is and how it can be rectified in the most efficient way is the best policy to make sure you’ve got all bases covered.
But of course, you also need to have a monitoring system in place to make sure you know if there is an outage. Without these two elements working together, you’ll probably find your users are unhappy if their service goes down and there’s a delay getting it back up again.