Thoughts on Clustering: Part 4 - Need More WEB

After a long quiet spell I decided to continue the story about branching out the server lineup. That phrase came out vague. It’ll make sense as we go.

In previous articles I covered configuration options for separate database servers, servers for serving static content and caching servers.

Previous articles:
Thoughts on Clustering: Part 1
Thoughts on Clustering: Part 2
Thoughts on Clustering: Part 3

Next I’ll talk about increasing the number of servers serving dynamic content.

In the second article I recommended moving all the content to the App server, setting up an NFS server on it and mounting the whole site’s folder on the Web server. In this article that’s no longer a recommendation, it’s a requirement.

That gives you a central content store that multiple sources can hit. The weak spot is network bandwidth between the servers, but within a single datacenter it’s several times higher than the data transfer speed between clients and the servers themselves. Obviously it’s better to use NAS, but not every hosting provider offers it on reasonable terms, and in most cases you can’t attach NAS to virtual (cloud) servers anyway.

Back to the following diagram:

The second requirement is a load balancer. Most hosting providers offer ready-made solutions. Back in the days when trams didn’t run yet and bearded admins were beating on tambourines next to mammoths, you had to get creative and use other solutions. In order of functionality/popularity:

1. Setting up HaProxy for load balancing
2. Load balancing with NginX
3. Load balancing with Apache
4. Varnish can also be used for load balancing

Now that you have a load balancer and a file store, you can spin up another web head:

Or even 2 or 3:

A less popular way to route traffic is DNS load balancing. Right away I’ll say this method isn’t for everyone. The idea is that for each web head you create a separate A record in the DNS zone, and your site starts resolving to multiple ip addresses. Sounds cool, right? The catch is that if one of the servers goes down, some visitors will see an error saying the site is unavailable. That’s because DNS servers don’t check whether the site is actually alive at the ip address listed in the zone.

You can use the DNS balancing trick if your hosting provider doesn’t hard-tie a public ip address to each server, but lets you bring up virtual network interfaces and assign them other servers’ ip addresses from your allocated subnet, effectively letting you move ip addresses between servers.

In that case you can use HeartBeat’s functionality and set up all the servers so they bring up virtual network adapters with the unavailable ip addresses.

Both the first and second method have their pros and cons. One downside of using a load balancer is that it’s an extra link in the chain, which affects site response time. But if you want to automate horizontal cluster scaling, you’ll run into the problem of automatically creating DNS records if you don’t have a single entry point like a load balancer. Sure, some hosters have an API that lets you create records on their nameservers with a simple POST request (RackSpace), but none of the popular domain registrars have that functionality.

For fault tolerance it’s a good idea to combine these methods. Meaning, having 2 load balancers … you get the idea 🙂