Embrace the cloud: Max uptime with clusters

ozgurGuest blogger Andreas BergmanLeave a Comment

City CloudMy daily work is to make sure my customers systems, mostly web systems stay online. I’ve made it a personal matter to make sure that the systems keep an 100% uptime, it’s not always possible due to external factors, but I try to make sure that there is nothing more I can do to keep the systems online.

One of the methods I use to keep the uptime, is load balancing and redundancy, thanks to the Linux Virtual Server project(LVS),RedHat and the City Cloud Service it’s fairly simple to build a high availability cluster. LVS can be used to load balance and cluster virtually any application or system, in my example I’m load balancing a HTTP-server, in my example I’m using what’s called a three tier cluster, ie that the cluster have three different load balanced levels.

Tier 1, This level is load balancers, or the cluster directors, they route the traffic to and from the right sources and is the key component of the cluster. Each pool of "Real Servers", have a "virtual server" pointing at them.
Tier 2, The HTTP-servers, serving all the web pages and  each server is configured as a "Real Server" in the load balancers.
Tier 3, This is the shared storage, in my demo I’m just using a CentOS server with a NFS share and a MySQL database shared to the web servers in tier 2.Cluster

Tier 1

This is the level with the cluster directors, two of them to be exact, one is active and the other one is at standby and takes over the work if the first load balancer goes down. The two load balancers "shares" a virtual IP which is floating between the machines. The clients connects to the virtual IP and the load balancers directs the TCP/IP packets to the virtual servers (in facts the virtual servers is only specific network ports on the real server). This means that i can have a virtual server on port 8080 on my real server but the client connects to port 80, standard HTTP. Based on what configuration you use then the answering packets from the virtual servers can be directed directly to the client or through the load balancer, NATed.

Tier 2

This is the level that contains the web servers, it could be web servers, directory servers or storage to, it all depends from what angle you look at the cluster. Anyhow, the web servers are standard Apache2, no special config, since the load balancers forwards the HTTP-header, the web server can use standard virtual hosts if desired. The web server stores it’s config files and the web scripts on a NFS volume shared with the other web server.

The load balancers directs the incoming requests between the web servers based on the rules in the config file, I use sticky sessions which means that a client will be directed to the same web server during the session, in this way sessions will be kept and you don’t need a session store like terracotta, on very well visited websites a session store can speed up the performance and you might want to use another load balancing algorithm.

Tier 3

This level is the storage level, I won’t mention how it’s done cause storage clustering is a rather complicated matter, but in most cases one use a Storage Area Network or Network Attached Storage to provide storage over iSCSI or NFS. The SAN or NAS is then handling all the disk management, failover etc.

A solution like this provides a fairly simple way of building a cluster, not said that building cluster is easy, but this is not the most advanced way to do it. Later on I’ll make an more in dept example on how to use Nginx and Apache2 to create a simple load balanced cluster.