2 December 2008
To understand this article, you should be familiar with basic hardware and networking concepts and know how to use ColdFusion 8 Enterprise.
ColdFusion is used in thousands of large enterprise environments, many of which inevitably employ clustering of resources to provide redundancy and scalability. In a previous article we focused on the internal specifics of clustering ColdFusion. In this article we will look at every layer involved in an overall ColdFusion high availability (HA) environment.
There is often a perception that only large-scale enterprise installs of web applications need to apply high availability (HA) concepts. Unless a website can sustain long periods of unavailability for clients it absolutely needs to be highly available.
HA breaks down into two main subsections: 1) failover and the equitable balancing of web site load; 2) load-balancing. As mentioned above, we already covered the overall subject of clustering internally in ColdFusion in a previous article. Failover and load-balancing are also subsets of clustering and clustering is a component part of HA.
Failover means that if any single piece of equipment of functionality needed to run a website fails, there is another to take its place.
If multiple pieces of equipment or functionality need to reliably sustain a website, load-balancing spreads the load evenly across all such items.
Figure 1 below shows all pieces of equipment necessary to create an HA environment in a single location. This is a distinction to bear in mind as for maximum HA we could create this setup in more than one geographical location. In that case, even a catastrophic occurrence (earthquake, hurricane, etc.) could be covered. However that sort of HA setup is very costly, mainly because of the cost of real-time replication of data.
Figure 1 illustrates a typical redundant infrastructure as it could be created in a single location such as in a data center. In this case most devices are operating in an "active-active" mode.
The active-active mode means that devices are handling traffic and participating in the request-response cycle of a web application. The exception is the firewalls and clustering devices which are in active-passive mode. In this case only one of the devices is actively participating in the request-response cycle of a web application. The other is ready to take over should the active device fail.
The clustered ColdFusion devices are actually clustered at the instance level using Java-J2EE clustering. It is good to note that as we are typically using external web servers, such as Apache, IIS, SunOne, etc., ColdFusion clustering is not operating at the external web server level. This means there needs to be either hardware or software clustering at the external web server level.
This section addresses all major hardware pieces required to build a High Availability (HA) architecture for ColdFusion.
Figure 2 below shows all major network hardware pieces followed by an overview description of each.
Before we leave the overview of network hardware, there is one item upon which everything which needs to communicate depends ― the NIC ("the faucet or tap").
It is almost certain that there will be more than one NIC in a typical server, so make sure you use all of them for something. For example, use one NIC for all incoming-outgoing requests to the web-tier and another for communicating with a dependency, such as a database. Also bear in mind that any connection point, such as a NIC, is a potential bottleneck.
In addition, take care with settings on the NICs. Always fix them and do not leave them on "auto-sense". If your switch runs at Gigabit Full Duplex then set the NICs on all servers to that setting.
Keep in mind the following:
Follow these best practices in HA environment:
As we add cluster members we need to consider that each member will need access to the ColdFusion code (and possibly other media). We have two main alternatives in this to consider:
ColdFusion coding for clusters
Shared scope variables reside in memory and as such are in the memory space of a single ColdFusion instance server. Here are the three current scopes in ColdFusion:
If a user is moved from one instance to another in the middle of a session, their session variables will not be there. The application variables should be there, providing the application is initialized with all those instantiations being in one place, preferably in the Application.cfm or .cfc. It is very important that the code used by all instances is identical.
ColdFusion coding for clusters alternatives to shared scopes
Figure 5 shows the alternatives we have if we plan well ahead of time.
We covered this in detail in a previous article, however this point is worthy of further emphasis. ColdFusion clustering is based on J 2EE clustering which is peer-to-peer clustering (see Figure 6 below). The external web server is not clustered and still needs to be clustered using either a hardware clustering device such as an F5 Big-IP or software clustering such as Windows Network Load Balancing (NLB).
Note the following points:
The base functionality which enables clustering in J2EE and thereby ColdFusion is the ability to create multiple application server instances. In essence, these are literally full ColdFusion servers in their own right with individual ColdFusion administrator GUIs. Instances do not need to be clustered. They can simply be used to encapsulate heavy processes such as scheduled tasks. Figure 7 below shows a clustered example.
In this article we had an overview of all the items that we need to consider when architecting ColdFusion HA applications. To learn more about the basics and theory of clustering high availability as it pertains to ColdFusion, read the following article by me: