Thoughts on Clustering. Part 1 - The Concept of a Cluster
A cluster means using several servers to run a single, integrated application. Each server in this setup plays its own assigned role. This article starts a series about clusters, their setup and capabilities.
Everyone knows you can take a dedicated server and put a website on it. Install a web server like Apache or NginX. Upload the content files. Install a database server, like MySql, and set up a database on it. Install a script interpreter, like php or python, and configure it to generate dynamic content, then serve it through the web server.
In this case everything sits in one place. As traffic to the site grows, load on the server keeps climbing, and if the site gets popular enough, you’ll need more capacity. There are 2 ways to go:
- Rent a more powerful server and move all the content to it.
- Split the resources and store them across several servers.
When the number of servers serving the site grows (horizontal scaling), that’s when we start talking about a cluster. The example above covers one of the reasons for clustering.
The second reason can be fault tolerance. In the spirit of the old saying the squad didn't even notice it lost a man - if your site runs on a dozen servers, one of them going down won’t take the whole site with it.
The simplest option is to use two servers:
- Web server
- Database server.
This is the most basic cluster setup. No extra components. The site resolves through the web server’s ip address. The site/application config points at the database server’s ip address for the db connection.
Here’s how it works:
For most popular CMS and frameworks, the bulk of the load lands on the web server, so it makes sense not to order servers of the same specs. If you’re unsure how to split capacity between the servers you’re getting - lean toward a beefier web server.
Next article:
Thoughts on Clustering: Part 2
