By O.S. Tezer
Albeit one of the more controversial techniques, a good method to geographically distribute your application by taking advantage of your provider’s global presence is to use and manage DNS responses (i.e. list of IP addresses returned). Unless you are willing to spend a little fortune on hardware and infrastructure costs, working with DNS to achieve high-availability is probably an excellent way to go.
In this article, we will see how to exploit some of the truly excellent and unique possibilities offered by DigitalOcean’s global cloud server / data-centre infrastructure to have a geographically-distributed, highly-available application set-up for minimal downtime (and thus dataloss) by managing DNS responses.
Traditional and most common application deployments depend on setups with all related components being located at the same place due to several reasons, such as:
Providers’ lack of means;
High costs, and/or;
Complicated engineering work.
Even if an application is served from multiple machines sitting behind load-balancers (or reverse-proxies), and even if the database is also set up in a way to offer reliability and prevent data-loss, these kind of arrangements are prone to different levels of errors, causing you, at times, downtime.
In order to prevent this, one must rely on and use a more dependable system architecture. One whereby data and servers are globally distributed at different areas (e.g. San Francisco and New York).
If your application is your business, you need to keep it accessible 24/7, if possible, almost without any interruption. Unfortunately, scaling horizontally over many servers at one location is not always the solution because of unexpected data-centre problems.
Globally-distributing your virtual servers across different geographical centres, however, can provide you the stability you require – thus, keeping applications’ up-time level as high as possible.
In terms of IT system-design, this kind of structure is referred to as high-availability.
Thanks to DigitalOcean’s presence in two continents, at five different locations, you can also spread your application stack globally.
You can connect a Reserved IP, which is a publicly-accessible static IP address that can be mapped to one of your Droplets, to your redundant infrastructure and launch your site or service with a single public IP. This Reserved IP can be instantly remapped to a new droplet, to allow for flexibility and responsiveness in your infrastructure. Read more about this new feature here.
Simply put, highly available application deployment structure, as we have just covered, depends on delivery and response to clients from different datacentres.
Although there are a number of possible ways to obtain this kind of structure, probably the simplest and the most affordable one is to take advantage of how DNS works.
A basic example set up can be considered as the following:
________________ | | | CLIENT | | WEB BROWSER | |________________| || || _______\/_______ | | | DNS SERVER | |________________| || || _______/ \_______ / \ / \ ____________________ ____________________ | | | | | SAN FRANCISCO | | SAN FRANCISCO | |____________________| |____________________| | ______________ | | ______________ | | | | | | | | | | | WEB SERVER | | | | WEB SERVER | | | | LOAD BALANCE | | | | LOAD BALANCE | | | | PROXY | | | | PROXY | | | |_____ _____| | | |_____ _____| | |________| |________| |________| |________| || __ __ || ||<=====||==================||=====>|| \/ \/ \/ \/ ____________________ ____________________ | | | | | SAN FRANCISCO | | NEW YORK | |____________________| |____________________| | ______________ | | ______________ | | | | | | | | | | | APP SERVER | | | | APP SERVER | | | |______ ______| | | |______ ______| | | ______||______ | | ______||______ | | | | | | | | | | | DATABASE |<==================>| DATABASE | | | |______________| | | |______________| | |____________________| |____________________|
When a user types the domain name of a website, through a set of defined rules (i.e. a protocol), the web-browser dials name-servers and asks them the address of the machines hosting the said web-site. Once it receives the IP address, then it sends the request to that computer, along with some additional data, and renders the response.
Since DNS allow multiple records to be kept (even the same kind), it becomes possible to list multiple hosts as the server.
Therefore, as demonstrated on the above schema, if you list the IP address of 2 load-balancers / reverse-proxies, located at two different locations, each set to balance the load between application servers, again located at at least two different data-centres, if one of the data-centres becomes unreachable, the client’s web-browser will try the next IP address records returned by the DNS server and repeat the process to get the web-site.
This kind of load-balancing is called Round Robin DNS load-balancing.
Things might look a little bit complex at a first glance. Let’s summarise them using step-by-step instructions:
DNS can hold multiple records for the same domain name.
DNS can return the list of IP addresses for the same domain name.
When a web-browser requests a web-site, it will try these IP addresses one-by-one, until it gets a response.
These IP addresses should point at not application servers but at load-balancers / reverse-proxies.
These reverse-proxies need to be balancing the load between multiple servers at multiple locations.
If a data-centre is down and the web-browser is unable to get a response from an IP address (i.e. a load-balancer), it will try to reach the address of the other.
Since it is very unlikely for both data-centres to be unreachable at the same time, the second load-balancer will return a response.
Web-application servers should be stateless to make the job of load-balancers easier.
Database servers should be set up in a replicated way.
Note: This tutorial is programming language or web-server type agnostic. Following these instructions, you can achieve high-availability regardless of your choice of frameworks, web or HTTP servers.
The first step to high-availability is to set up two or more load-balancing reverse proxies which are going to communicate between your application servers.
Instantiate two cloud servers at two locations:
Create two DigitalOcean droplets.
e.g. Article: How To Create A DO Cloud Server
Set up a load-balancer / reverse-proxy on each droplet:
Install and configure Nginx, Apache or HAProxy.
e.g. Article: Nginx as a Front End Proxy, HAProxy Load-balancing on Ubuntu
Get the IP Addresses of your load balancers:
/sbin/ifconfig and find out your droplets’ IP addresses.
DNS A Records translate domain names (e.g.
www.digitalocean.com) to machine-reachable IP addresses.
Once you are done configuring two droplets with a load-balancing reverse-proxy on each, the next step consists of adding 2 A records through DigitalOcean’s DNS service to point your domain name to the IP address.
Log-in to your DigitalOcean control panel:
DNS on the left-hand menu and add a new domain name pointing to a load-balancer droplet from the previous step.
Add a new A Records:
Once you are on the next step, click “Add Record” on the upper-hand side and create a new A record, with the IP address of the other load-balancer droplet.
Next step is setting up the application servers.
For global distribution to work, just like the first load-balancing servers you have created, you need two new droplets to host your application servers.
Note: You can also run each of your application servers on the same machine as the load-balancers; however, this would not be recommended.
Deploy or duplicate your application server droplet on two locations. For example:
In NY 1 and NY 2;
In AMS 1 and AMS 2;
In SF 1 and NY 2 etc.
Go back to the first step and following the load-balancer setting up articles, configure them to proxy incoming connections to these two application-serving droplets.
It is hard to imagine a web-application without a database. The hardest part of distributing applications over multiple servers is probably dealing with databases.
Depending on your choice of database server, create a duplicated configuration but across multiple locations.
How To Set Up Master Slave Replication in MySQL
How To Set Up MySQL Master-Master Replication
How To Set Up Master Slave Replication on PostgreSQL
Once you complete creating a replicated database structure, point your applications to use their addresses, as interacted in tutorials as the DB server.
<div class=“author”>Submitted by: <a href=“https://twitter.com/ostezer”>O.S. Tezer</a></div>
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
Click below to sign up and get $200 of credit to try our products over 60 days!
One sentence in this article is a huge lie and makes proposed solution unusable:
“When a web-browser requests a web-site, it will try these IP addresses one-by-one, until it gets a response.”
No, it doesn’t! Browser selects the random IP address and sticks to it no matter if the host is up or not! DNS round-robin is not a failover solution! What you say is only true for MX records and mail servers.
If you want to have a spare load-balancer, you need to implement a solution that will make it capture original IP address of failed one. I guess there is no way to use DO droplets for this. So - if any of your load balancers will be down - half of your visitors will see error message.
To proof my words: I setup a dns entry test1.pr1v.net which has 3 records:
Two of them (1.2.3.*) are unused addresses, and the third one is my host IP. Please see if the site works for you everytime you try. I bet not.
This looks a very conventional solution. Whether it works or not purely depends on if digitalocean’s DNS system does failover or not. can you confirm that?
Without this ability, DO’s dns can have still have chance to send back dead reverse proxy’s ip back to user, hence resulting in a no-responding/freezing web site or app.
Please, can someone from DO confirm that?
@Vincent: Check out <a href=“https://www.digitalocean.com/community/articles/how-to-create-a-redundant-storage-pool-using-glusterfs-on-ubuntu-servers”>https://www.digitalocean.com/community/articles/how-to-create-a-redundant-storage-pool-using-glusterfs-on-ubuntu-servers</a>.
Thank you for this tutorial. Would you be kind enough to also add the setup for replication of files please? many thanks
Why do you need reverse proxies behind the application servers? Why can’t you connect directly to the application servers?
With latest release Nginx support UDP/DNS load balancing http://www.techietown.info/2017/03/dns-loadbalancing-using-nginx/
Essentially this misses shared state servers (most DB’s are too slow for this)
I too would like to know if DigitalOcean DNS zoning provides health checks for server endpoints.
Currently, I’m using Amazon Route 53 for this purpose…
If i don not need load balancing (because each of the two servers can easily handle all my traffic) but i want to have a fall-over-server in case one of the servers is unreachable; can i then skip the load balancer proxies and just put the application servers in the dns?
@mateusz : Same is happening with me . DNS load Balancing does not work on the digital ocean side. Randomly it sticks to one IP and keep on calling the same, no matter what the situation is(doesn’t even change for failover) . :(