We talk to organizations every day looking to increase the availability of on-premise hosted applications using multihomed ISPs. The most common applications are Exchange and Remote Desktop, both essential components to ensuring workforce productivity for remote or offsite employees. While managing outbound connectivity through more than one ISP is a breeze today since so many firewall vendors offer multi-WAN failover capability, properly managing inbound connectivity is still a challenge that many organizations have not yet resolved.
A frequently recommended and effective solution is to implement BGP, but this is not a trivial task, nor is it entirely perfect. To start, you need a /24 of IPv4 or /48 of IPv6 space to announce. None of the major carriers will accept anything smaller than a /24 of IPv4, a common requirement due to the sheer size of the existing routing table. Even if you were fortunate to get IP space from your RIR before IPv4 was exhausted, or one of your ISPs has allocated one to you for portable use, you need to ensure that all of your ISPs support BGP. Not everyone does, especially in more rural markets and with smaller providers, and making assumptions could lead to an unusable contract. If you’re lucky enough to find out that BGP is supported, you’ll now need a router that is BGP capable, and then the skillset to manage it. These are just a few of the high-level requirements, but as you can see, it’s not something that can be done quickly or easily.
A second solution that is frequently used to control inbound connectivity over multihomed ISPs is DNS Failover. There are several managed DNS providers that offer DNS Failover, and it is simple and easy-to-use and can be programmed to attach to a specific DNS hostname and monitor it for availability. When the host becomes unresponsive, DNS is automatically updated to the IP address of the same device via the second ISP. And while this works great for many applications, it’s not perfect for everything. Increasingly we’re finding that mobile networks, like Verizon ignore low TTL values and continue to cache DNS records for up to 20 minutes. But if you can handle 20 minutes of downtime, then DNS Failover is by far the most affordable option and something you should seriously consider.
At Total Uptime, we believe we’ve come up with the perfect solution to make applications highly available through multiple static IP addresses on different ISPs. And that is our Network Failover service. It was specifically designed to address the issues organizations face when trying to host on-premise applications with flaky and unreliable last-mile Internet providers. We all know that Internet providers will not improve due to the commodity nature of their product, and the fact that there are so many potential breaking points between your customer and your server. And while you could spend more money to bring in better providers who may support diverse fiber routing, multi-line bonding, BGP etc., the costs may be astronomical.
Total Uptime’s Network Failover puts you back in control of inbound network routing. Here’s how it works. Our platform assigns you a static IP announced on our global multi-datacenter platform called a VIP, or Virtual IP. This IP becomes your new client-facing IP that is permanently published in DNS for your application. This IP never needs to change, so the issues with DNS TTL and cache are now gone. Behind the scenes and through our web-based management interface, you configure the “real IP” addresses of the devices you want us to route the traffic to. Now, when traffic destined to your application hits our VIP, it is proxied over to the real IP addresses of your choice. You can route over just one ISP, or multiple, the choice is yours. Have an ISP outage? Simply log into our interface and switch the routing. Or better yet, configure a monitor to automatically detect when one of your ISPs goes down to make the switch automatically and email or SMS you when it happens.
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 […]
Controlling traffic is a key facet of internet management. Sometimes primary connections will go down. Or too much traffic may cause congested links or overwhelmed devices to become unusable. We wrote about the implementation of load balancing in the cloud in a 2017 blog post. When people think of load balancing, they usually think about traffic that […]
One of the biggest trends in data center infrastructure is convergence. Actually it has been happening for some time. Equipment footprint has been getting smaller for years. Functions that used to be handled by huge dedicated machines are now accomplished by modular cards. Specialized servers, switches, routers, and other network devices have been combined into […]
A service provider that offers software-as-a-service or another cloud-based solution should understand what customers are looking for and what compels those very customers to choose an off-premise, “cloud-based” solution vs. the more traditional on-premise, self-hosted solution. As a cloud service provider ourselves, we set out to understand how our customers went about choosing one service […]