Both solutions require that you tell us what the IP address(es) are for your ‘real servers’. That way we know how to alter DNS or route traffic when one or more servers go up or down. These IP addresses must be publicly accessible, not private. Also, both solutions use the same type of monitors to check your ‘real servers’ to determine their availability. The monitors can check as frequently as every 60 seconds and the results are used to make automated changes.
With DNS FAILOVER, when a server goes up or down, the corresponding IP address for that server is added or removed to DNS by manipulating ‘A’ record(s). This means that your users out on the Internet see different IP addresses at different times based on how you’ve configured failover to behave when servers become unavailable. For most customers who average only one or two outages a year or who aren’t going to lose millions of dollars with every minute of downtime, this is a nice easy and clean solution to automate rerouting traffic.
With the NETWORK FAILOVER component of Cloud Load Balancing, you are given a permanent proxy IP address in the Cloud. You publish that IP in DNS and it never needs to change after that. Traffic from users on the Internet routes to that IP at any one of many datacenters we operate, and from there we make the routing decision on where to send traffic. So in essence, all traffic between you and your ‘clients’ is handled by our routers in the cloud without the need to ever change an IP address in DNS.
With DNS FAILOVER, there is some reliance on various ISPs who operate recursive name servers around the world to obey the TTL (time to live) associated with your ‘A’ records to be sure end-users see the change when you want them to, as quickly as possible. But in general, this works very smoothly and can fail traffic from one IP to another within 2 to 3 minutes. Very rarely do we hear of cache issues. If we do, it is generally from mobile networks.
With DNS FAILOVER, we point clients to different IPs based on server availability, so we really never see the traffic or otherwise touch it. This makes it light, effective and our most affordable option.
With DNS FAILOVER, pricing is pretty low unless you have an excessive number of queries, but even so, overage costs are minimal. So for budget-conscious users who can withstand the typical 2 to 3 minutes of downtime as IP addresses are changed in DNS around the world, DNS Failover is an ideal choice.
With CLOUD FAILOVER, there is no reliance on DNS at all since the IP never changes, so you remove the ability for ISPs to mess with things. But this does add an extra hop to the round trip, and may introduce a little extra latency – usually around 20 to 30ms – but nothing significant unless you’re in the online trading or gaming business.
With CLOUD FAILOVER, all traffic (to and from clients) goes through our global network. Our network is very redundant, and is designed with no single points of failure, but it does add bandwidth costs to the equation, especially for high traffic sites or applications. While most pricing packages have generous bandwidth allotments, it is something to keep in mind.
With CLOUD FAILOVER, the IP address seen by your site or application will be that of one of our cloud nodes. This doesn’t impact Google Analytics or similar tools, but could affect other things that require the client’s source IP. Of course, we have easy ways to remedy this.
Hopefully this quick overview helps you make the best decision between our two solutions. But if not, feel free to call or chat online with us. We’ll ask a few questions to understand your application so we can help you choose the solution that addresses your needs.