We recently helped a customer who had dozens of virtual machines (called Droplets) from Digital Ocean spanning multiple countries. Digital Ocean doesn’t have a load balancer, but even if they did, he was looking for a way to load balance traffic in each of 3 geographically diverse regions all without having to use DNS. He was using round-robin DNS to distribute the load among the group of servers, but it wasn’t working anywhere near the way he wanted it to, often distributing load unevenly. Plus, to keep the traffic going to the correct region, he had to give out 3 application URLs, ensuring that each customer received and utilized the correct one for their part of the world. Furthermore, when a Droplet was overloaded, clients received error pages or timeouts until it was detected by his third-party monitoring and DNS was updated manually to remove the IP from distribution.
His challenge for Total Uptime consisted of three objectives:
Sounds like a tall order, right? Not for Total Uptime! This client’s situation is not at all unusual and simply requires a combination of GEO DNS and multiple load balancing packs. To begin, it really doesn’t matter where servers reside. So long as they are publicly accessible, we can route traffic to them. So whether they are at Digital Ocean, AWS, RackSpace or your basement, we can make it all work together.
The first thing we did was create all of his servers within our console. We created an HTTP monitor to look for the content on the home page, and attached it to the server. We then configured port 80 and 443 per his requirements and watched the servers come up to ensure our monitoring was reliable.
Secondly, we created 3 “packs”, essentially load balanced configurations in our portal. Each pack was assigned a unique public IP in the cloud. We then placed the servers within each region into their own pack… a USA pack, Europe Pack and APAC Pack. To make things completely redundant, we configured a Failover Group within each pack for devices in another region as the ultimate backup strategy, which is hopefully never necessary.
Next, we published each pack and confirmed that traffic routed to the regional servers exactly the way he wanted. And lastly, we created a GEO DNS pool and assigned the correct regional pack Ip to each part of the world.
Now, when someone from Europe requests his URL, they are given out the IP of the load balancer in Europe, which exclusively directs traffic to his Amsterdam and Frankfurt servers. Should either of those two data centers go down, the one remaining in service will continue to serve traffic. And in the extremely unlikely event that both go down, European customers would be routed to his servers in New York, all without an IP change in DNS.
While this scenario might be overly complex for your situation, and whether you have two Droplets to load balance, or dozens like this client, Total Uptime probably has a solution that will take care of your needs. Our unique advantage is to create data center independence and application resilience. Hopefully we can do the same for you!
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 […]
Are you looking to create an active/passive server failover configuration using our Cloud Load Balancer? It’s easier than you think. This video will walk you through the entire configuration process, taking a standard active/active load balancing scenario and changing it to active/passive, active/active/passive and even active/passive/passive with a tertiary failover group setup. Total Uptime […]
IT systems go down for a lot of reasons. Some downtime causes are obvious, while others take some time to understand. And still others are just plain comical. In this article we’ll have a look at different approaches to assigning blame for outages, and we’ll offer a short list of our own. The concept of downtime applies […]
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 […]