A common inquiry we receive is whether or not any of our solutions have the capability to automate switching inbound traffic between common office WAN Internet connections, such as DSL, Cable and T1 lines. The quick answer is “absolutely!” Total Uptime Failover solutions are perfect for automatically failing inbound traffic over these types of WAN links if your organization has something that needs to be accessed externally, like a Remote Desktop server, mail server, web server, VPN or almost any IP accessible device.
Dual WAN devices are handy pieces of hardware that allow you to use common internet connections from redundant providers to create a more highly available Internet service. There are a plethora of hardware vendors that have this type of capability baked into their hardware ranging from true load balancers to simple routers and firewalls. For example, Cisco has several options including the simple Linksys RV042 WAN Router all the way to the more complex ASA5500 series Firewall. And while these devices do an excellent job at making sure that the people in your office have uninterrupted Internet access for all outbound connectivity, they do very little to ensure that inbound traffic continues to flow. That’s where Total Uptime comes in. We can detect when your WAN fails from one ISP to another and can redirect traffic accordingly to ensure your public facing services continue to operate. If you’ve ever investigated the cost and effort behind implementing BGP at your office just to keep the traffic flowing in both directions, you’ll love how simple, effective and affordable our failover solutions are.
We have two solutions to address this inbound traffic issue, and either one will probably do the trick. Both of our solutions use advanced monitors to check the availability of your devices. We can do much more than a ping, we can load a web page and look for content, we can see if your mail server is responding on port 25 and a whole lot more. Essentially, if you can dream it, we most likely can monitor it.
The first solution we offer is DNS-based and updates your DNS records accordingly. This is our DNS Failover solution, and few think of it for WAN load balancing, but it works very well. Let’s assume your ‘A’ record for exchange.example.com is pointing to the IP address behind your primary ISP, 126.96.36.199 and your second ISP has given you 188.8.131.52. You configure both of these in your firewall to NAT over to your mail server, and we monitor both but only publish in DNS the one that is working at any given time. We do this because most of the link load balancing devices we’ve seen only allow one active at a time. But if yours supports two active WAN connections, then why not use both! We can easily publish a DNS record for two at the same time (or 3, 4, 5 etc. there really isn’t a limit). The beauty of this design is that when 184.108.40.206 stops responding, the monitor detects it right away and immediately updates DNS to change exchange.example.com to resolve to the other IP, 220.127.116.11. When this happens, users will see a short outage of 2 to 3 minutes at the most, but it is fairly seamless and straightforward to implement and use.
The second solution we offer is network-based and does not update DNS at all. This is our Network Failover solution, a component of our Cloud Load Balancer. The monitoring is the same, but the difference lies in the implementation and the fact that you do not need to migrate your DNS hosting to Total Uptime to make it work (although there are ways to work around that). So if you like your existing DNS provider, this may be the option for you. We give you an IP address on our cloud platform that is both everywhere and highly redundant at the same time. You update DNS to point to this IP address as if it were a load balancer sitting at your premise (except more redundant). We monitor your servers and send traffic to the IP address that is responding. When there is an outage, unlike DNS Failover, DNS does not change, we simply make a traffic routing change from one IP to the next… and it happens almost instantaneously. This means users can fail over much faster than 2 to 3 minutes, but it also allows for some advanced features like session-state management and true load balancing if both of your WAN links can be active at the same time.
In another article we’ll cover implementation, but both are quite easy. All we really need to know is the public IP addresses for your devices and the ports you wish to pass through. With that information monitors and failover groups can be configured easily and you’ll be up and running in just a few minutes.
Curious how this might work for you? Try DNS Failover, Cloud Load Balancing (or both) solutions at no cost or obligation for two weeks. We’ll even help you configure everything to show you how easy it is to use. You’ll wish you’d found a solution like this a long time ago!
Total Uptime’s DNS Service along with our DNS Failover solution are often compared to Amazon Route 53, and for good reason. Organizations are increasingly looking for a reliable DNS provider in light of frequent outages at various Domain Registrars like Network Solutions. IT experts understand that because DNS is the first link in the chain, it must be the […]
As we talk to people during the week, we periodically make suggestions for using Cloud Load Balancing or Failover that are often met with surprise, such as “Oh, I didn’t know it could be used for that”. So we thought it might be helpful to compile a list of 8 potential uses. Of course, it […]
If you went to bestbuy.com and the site was unavailable, how long would it take for you to go to amazon.com or elsewhere to find what you wanted? On average, it’s less than 30 seconds; it used to be much longer, but our society has grown impatient. If you’re not available when customers are looking […]
When implementing a failover solution, the most common questions we receive are: How can we architect a failover solution for our application? How quickly can we failover from the primary site to the secondary site? How quickly can it fail back when the primary comes back online? Is there a way to prevent automatic failback […]