Load Balancing Droplets from Digital Ocean
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:
- First, he wanted to route clients from a specific geography to the Droplets within that region. For example, visitors from Europe should go to his VMs in Frankfurt and Amsterdam. Visitors from the USA should go to his VMs in New York and San Jose, and finally all APAC traffic to Singapore.
- Secondly, he wanted to gain complete and precise control over the traffic flow to each VM. He wanted the ability to immediately take a VM out of service when it became sluggish, or when it required maintenance. He also wanted the ability to weight them, so larger or better performing Droplets could receive a greater amount of traffic, all without using DNS.
- Lastly, he wanted to implement protection so that if one of Digital Ocean’s entire data centers went offline, he could fail traffic completely to the other region. For example, New York would fail over to San Jose, Amsterdam to Frankfurt, and Singapore to an AWS EC2 group of servers within that region.
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!
Other posts you might like...
Downtime costs $7900 per minute, on average
The cost of datacenter downtime has increased more than 40% for many companies over the last 3 years, according to a recent study by Ponemon Institute, sponsored by Emerson Network Power. The report analyzes 67 datacenters...read more
What are the key differences between DNS Failover and Cloud Failover so I can better understand which one is right for my application?
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...read more