There is a term heavily used in enterprise level environments called “High Availability” or HA as it is also known. There is a previous article where we discussed some HA concepts.
As the term implies it refers to something being available most of the time, a “high” amount of the time. There are many different infrastructures and procedures which are required in a successful HA implementation. In the first post in this series we will look at one key component of HA; Clustering.
In my experience, Clustering is an overall term which also encompasses Load Balancing and Fail-Over. The concepts I am laying out here can apply to any hardware or software and are not limited to ColdFusion and/or JRun. We will get much more specific as we progress through this series and will show details of ColdFusion-JRun in clustered deployments.
Load Balancing
We often hear the term load balancing used when in my opinion the correct term is clustering. Here is a typical example that I have encountered many times. Clients will often refer to a Hardware clustering device such as a BigIP F5 or Cisco Content Service Switch; as a Load Balancer.
Here is a quick simple illustration of the relationship of Clustering to Load Balancing. In the drawing below we have stripped down illustration of Load Balancing. Requests come via the Public Internet and eventually to a Hardware Clustering device (not a Load Balancer because as we will see shortly, its job is to do far more than Load Balance).
The Clustering device directs the requests from the Internet to one of two Web Servers which sit behind the Clustering device. These requests are sent on an alternating basis to Webserver1> Webserver2> Webserver1> Webserver2> etc. This form of Load Balancing is known as “RoundRobin”. Load is distributed totally evenly among all servers in the Cluster. This is a simple Cluster and we are illustrating Load Balancing only within this Cluster of 2 servers.
Fail Over
In this second scenario, Webserver2 is no longer available to service requests so the Clustering device is sending requests only to Webserver1. Typically, the way the Clustering Device knows that Webserver2 is not available is by the use of a “Heartbeat” ping which could be as simple as a low level (ICMP) ping or possible a URL request to a page which could be a simple HTML page where the Clustering device is looking for a successful 200 response or possibly some particular text on that page.
Summary
As we have shown here, the hardware device is not simply balancing the load across multiple Web Servers but is also making sure both are available and failing over requests (Fail Over) in the event of a server becoming unavailable. The hardware device is a Clustering device any time it is connected to more than one other device and where it manages the connections of those devices and Load Balancing is only one of its jobs. We will continue this series with more detailed information on Clustering and HA.
DougHughes.net 
Comments on: "Clustering – The Father To The Man" (2)
Mike, good start on these concepts. I’d be interested in hearing more about how to implement frameworks such as MG:Unity and ORM tools like Reactor or Transfer in a clustered environment. I’ve started down that road, and run into complications related to the clustered architecture. We’re using F5 BigIP to handle load balancing, clustering, and SSL termination.
-matt
LikeLike
Yes Matt those are important considerations and we will get very exploratory and as detailed as we can in this series. There are other foibles too such as multiple instances of JRun-CF, virtual machines like VM-Ware. I think the main thing in all of this is to think of Clustering at the very beginning of Application planning because there is a very good chance Clustering will occur
By the way, can you expand on the complications you hit?
LikeLike