A cluster is a group of two or more independent servers operating as a single system. Using a cluster rather than a single server as powerful as the sum of the independent servers offers benefits:
- Increase the availability
- Facilitate the rise in system load
- Allow for load distribution
- Allow the use of low-cost servers
Scaling up from a single server solution
The first recommended step when scaling up your web solution is to place your web and database services on two separate servers. The web server will handle requests from your clients and communicate with the database server to obtain dynamic data. Such a configuration is compatible with most control panel software available on the market. The control panel will be installed on the web server and will connect with the remote database server. Your web pages configured via the control panel will then have database functionality.
The partition of the web and database services on two different servers has several advantages.
First, both services have different requirements in terms of security and access control. Putting them on two different servers allows the creation of a more secure design for your whole web solution. While the web server will accept all incoming connections on the HTTP and maybe the HTTPS ports, the database server should only accept connections on the SQL port from the web server. The use of a private network (not shown on the diagram above) provides a much more secure communication channel.
Second, the resource allocation requirements for the web and database servers are different. The web server must have enough space to store your text, image, music and video files. A single SATA drive or a RAID 1 configuration should provide enough space and IO performance in most cases. Also, a multi-core CPU with a low clock speed should provide enough computational power for your web service (apache, nginx, IIS, etc). On the other hand, your database may have higher IO and CPU requirements. The use of SAS or SSD drives in a RAID 1 or RAID10 configuration will provide an higher IO throughput. A single or dual multi-core CPU with an higher clock speed will provide higher CPU performance for your database service (MySQL, PostgreSQL, MSSQL, Oracle, etc).
Third, a split between the web and databases services will allow you to move seamlessly toward high availability with web and database clustering in the future. A different approach is required to put both of these services into a highly available cluster. Separating them at this stage of the evolution of your web solution will simplify a future migration toward an high availability configuration.
Web server clustering
To achieve high availability and increase the performance of your web service, you will need a redundant load balancing solution and at least a pair of back-end servers. There are two major ways to load balance network connections:
- Reverse proxy with layer 7 (application layer) packet filtering
- Direct routing with layer 4 (transport layer) content switching
In the diagram shown below, the load balancing appliance is formed by an active/passive pair of reverse proxy servers. The network traffic from the Internet is dispatched to the back-end web servers via the load balancing appliance. The IP address associated with the domain name of your web service is bonded to the load balancing appliance. All incoming connections to this IP address are treated by the active load balancer server and forwarded according to its configuration to the web servers through Network Address Translation (NAT). Web server responses are forwarded back to the clients via the active load balancer.
With such a configuration, the load balancing appliance may also work as a firewall device to protect your web and database servers from hostile intrusion. Moreover, your database server is now in a much more secure location as it can respond to SQL requests from the private network and safely ignore requests from the public network.
Various scheduling algorithms are used to distribute connection requests to the back-end servers. A simple algorithm could consist of a random choice or the round robin technique where connection requests are assigned to each back-end server in equal portions and in circular order. Some sophisticated methods taking into account additional factors, such as the back-end server loads and response time are also available depending on your choice of load balancing appliance.
Handling information that must be conserved between multiple client requests is an important issue when operating a load balancing appliance. When this information is kept locally on each server, subsequent requests must be sent to the appropriate server. Storing session data on the client browser instead of the web server is an elegant solution as it does not require connection persistence. The load balancing appliance can then use a simple round robin scheduling algorithm to distribute client requests. However, this method of handling session data is not always suitable or desirable.
A simple solution to the connection persistence problem is to send all requests from a user session consistently to the same back-end server to provide network connection persistence. However, if a server goes down, its local information is lost and any session depending on it must be restarted. The persistence can be established using the client IP address or by inserting a browser cookie into the web session. This cookie containing information about the back-end server is analyzed by the load balancing appliance before the transmission of the request to the appropriate back-end web server.
Configuration and data files need to be synchronized between all cluster node servers. Under Linux where the configuration is a set of files, the web server configuration can be copied from the first web server toward the other ones on a regular basis using a scheduled task. Under Microsoft Windows, the configuration of IIS is not stored directly on a file and the configuration needs to be replicated manually on every web server.
Text, image, music and video files can be copied from the first web server toward the other ones on a regular basis using a scheduled task under Linux and Microsoft Windows. However, if you need to maintain a continuous synchronization of data content between the web servers, you will most likely need a Network Attached Storage (NAS) solution. To illustrate this requirement, we could imagine two clients surfing your web site. While the first client is connected to web server A, the second one is connected to web server B. The first client uploads a picture of himself on your website. Without continuous synchronization, the picture will not be visible to the second client until the synchronization script is executed between server A and server B. While this situation is acceptable on most situations, you may have a requirement for continuous synchronization for your web solution.
Control panel compatibility
An important drawback of a web cluster architecture is its incompatibility with the majority of control panel software. The required synchronization of the web server configuration and data files is the main obstacle to the use of a control panel on a web cluster solution.
Theoretically, since multiple back-end web servers are able to respond to client requests, the performance of such a web solution measured in terms of data throughput and responsiveness will be superior compared to an equivalent solution with only one web server. However, the performance may not scale up linearly for different reasons:
- the database may have insufficient resources to answer web server SQL requests quickly enough;
- the bandwidth of the load balancing appliance with the Internet may be saturated;
Until now, we only discussed about clustering the web servers. However, to achieve true high availability, the database service should also be transformed into a cluster. We discuss how to create a database cluster in this article.