Using ColdFusion to enhance scalability and high availability

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.

An introduction to high availability

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

Failover means that if any single piece of equipment of functionality needed to run a website fails, there is another to take its place.

Load-balancing

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.

Hardware needs in HA environments

This section addresses all major hardware pieces required to build a High Availability (HA) architecture for ColdFusion.

The Network

Figure 2 below shows all major network hardware pieces followed by an overview description of each.

• The router ― plays a pivotal role in moving data through a network. It looks at packets of data and knows only where the packet came from and where it needs to go next. It spans two different subnets and its job is to connect those two and allow data to flow from one to the other. Routers rarely fail and either pass data properly or not at all. However a faulty router can be difficult to diagnose and typically a network "sniffer" is needed. Also pay attention to speed settings on the network connection, fixed rather than auto-sense.
• The firewall ― should be configured in a deny-allow mode. Its job is to look at communications via TCP/IP ports, from and to IP addresses and also the protocols being used or requested. It should first deny all such requests and rule-sets are then created to allow safe acceptable traffic to pass through. Most firewall problems usually come down to insufficient rule-sets for a particular need. One item I have found useful is to document all ports and protocols needed to operate ColdFusion applications before deploying such applications to production. Keep an eye on those network connections.
• The clustering device (often wrongly called the load balancer) ― has two main jobs. The first is to regularly check the health of all servers it is directing traffic to, ensuring that they are able to accept traffic (failover). The second is to send traffic evenly around the available servers (load-balancing). To facilitate in memory session scope stability, "sticky-sessions" should be enabled. The most critical part in setting up a clustering device is how it is configured to monitor server health. Make sure you are not simply looking for a "200" response or hitting a page buried deep in a heavy-duty ColdFusion application. Keep an eye on those network connections.
• Network switches― come in various different types of switches. Some are very basic while some are simply connecting (bridging) devices which exist on the same subnet (known as level 2 switches). Some act like routers connecting (routing) between devices which exist on different subnets (known as level 3 switches). The main point is that they are all connection devices. Things to watch out for with switches are to make sure the backplane (which all ports go through) is adequate to deliver the required throughput if all ports are busy. Also keep an eye on those network connections.

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.

Server considerations

Keep in mind the following:

• 64-bit: Do not buy 32-bit server hardware. The latent performance difference between 32-bit and 64-bit is dramatic. 64-bit is much more powerful.
• Hard drives: This is often overlooked but hard drive configuration is an important aspect, particularly with regard to database servers. The diagram below shows two kinds of groupings or "arrays" of hard drives. These are known as RAID (Redundant Array of Inexpensive Disks) arrays. Their primary job is to provide redundancy so if there is a hard drive failure, service will still be maintained. There are two very important considerations when configuring RAID which are illustrated below. Firstly, the kind of array chosen should reflect the needs. This is especially important with database servers where heavy writing of transaction logs is typical. Use a RAID 1 or 10 array for this. Secondly, where a large amount of storage is needed, for instance, for the database files themselves, RAID 5 or 6 is optimal. Figure 3 below illustrates this and shows RAID 1 and 5.

Software best practices in HA environments

Follow these best practices in HA environment:

Website code

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:

1. We can maintain multiple copies of the code, one on each cluster member's physical server. This means we will have to set up a replication mechanism to ensure that the code on all cluster members is identical at all times. However, there is a danger that code may be different within each cluster member. The replication mechanism is the key here.
2. Alternatively, we can maintain a central copy of the code on file servers, on network attached storage (NAS) or a storage area network (SAN). Nevertheless, we are adding another network-connection hop and still require the added level of storage to be redundant. Figure 4 below shows a NAS or SAN solution.

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:

• Application scope ― available to all users in a single ColdFusion application created by using the <cfapplication tag.
• Server scope― available to all applications and all users on a single ColdFusion instance server.
• Session scope― applicable to a single user in a ColdFusion application.

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

• Application scope ― The Request Scope can be interchanged with the Application Scope in many cases. As the Request Scope is not memory resident it does not cause problems if users are moved around a cluster.
• Session scope ― In the Java world session state can be maintained in different areas, memory being one, a database being another. In ColdFusion the Client Scope is equivalent to maintaining session state in the database. The downside is that complex variables cannot natively be stored in a database.

Figure 5 shows the alternatives we have if we plan well ahead of time.

ColdFusion clustering (J2EE clustering)

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).

ColdFusion coding for clustering note points

Note the following points:

• The more items that we store in local memory, the harder it is to cluster applications reliably.
• It is very important that nothing server locale specific is hard-coded, such as directory paths.
• Synchronizing large amounts of data across the network layer is costly and can be unpredictable and debilitating.

ColdFusion Enterprise – J2EE multiple instances

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.

Where to go from here

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:

• High availability clustering ColdFusion: Using ColdFusion Enterprise Manager