Clustering Strategies For Web Environments.

Traditional computer and network architectures work well for most enterprise applications, but begin to break down when applied to the task of reliably serving up Internet content. Providing static and streaming content in an Internet environment requires seamless scalability, manageability, distrib-uted storage, and impressive levels of reliability. These goals are very difficult to achieve using the "big iron" approach. Better suited to this application space is server clustering, where multiple specialized servers (or server appliances) are harnessed to work together as one.

Clusters are constructed by connecting different types of systems and other devices (such as storage arrays) to one another. The elements that comprise a cluster, nodes, come in several different types. There are compute nodes that provide raw computation. These are typically server-class computers that contain a large amount of memory and have multiple high-speed processors. Scientific computing labs often have clusters of nothing but compute nodes, with parallel processing software distributing a single application between computers. These may also be general-purpose computers that are applied to solv-ing specific problems.

Another common type of cluster element is the storage node. The storage node may offer up its content via the normal TCP/IP network. This type of storage delivery is known as a Network Attached Storage (NAS) device. Alternately, the storage node may be attached to the other nodes within a cluster directly through a Storage Array Network (SAN) such as Fibre Channel or directly to a NAS device via a SCSI channel. This type of device is called a storage array.

Other types of nodes can be lumped into the category of application specific server appliances. These nodes are, then, named for their specific function. For example, a basic Web-serving appliance might become a Web server node. A computer outfitted with encryption acceleration hardware would be a commerce accelerator node. The types of server appliances being delivered to solve particular problems are ever growing.

There are several views into the underlying technologies employed in building a cluster. Some approach clustering simply as an exercise in reliability, using fail-over pairs to allow servers to provide levels of redundancy between nodes. Others view clustering as a single point of management for a grouping of machines. Clustering also takes on the issues of load balancing and cluster-level storage networks, where many servers share responsibility of serving content for a single Web site from a common view of the content. Add to this mix the idea of specialized appliances for SSL encryption and streaming media acceleration and the choices grow quickly.

Management Clusters

The most basic and common type of clustering is the management cluster. A management cluster is the grouping of nodes into a single entity that is easy to manage. There are two principal types of management employed in these sorts of clusters: in-band and out-of band management.

In-band management is the ability to monitor and administer a cluster of computers using on-board software called agents. This is applicable in a management cluster if the agents can be partitioned into logically managed com-munities of machines. This type of management is called "in-bound" because it utilizes the resources of the underlying operating system.

A basic example of a management cluster using inband management is the SNMP community. SNMP allows an administrator to logically associate nodes in order to apply monitoring and management policies as a group. SNMP is not the only in-band management path for cluster management. There are a number of proprietary approaches offered by the various clustering vendors.

Monitoring and administering clusters using out-of-band management leverages maintenance processors that are independent of the cluster node being monitored. This is a back door" into the server hardware that allows access, regardless of the state of the operating system and applications software run-ning on the node.

Most maintenance processors provide control of the front panel functions of the node, allowing for things like remote power-off and power-on. They are also often tied into the System Management Bus (SMBus) on the node being monitored, allowing remote monitoring of on-board sensors (such as voltage, temperature, fan speed, etc.).

Communication between the maintenance processors and the administering machine is provided by an external connection dedicated to the maintenance processors. Examples of these interconnects include serial ports, dedicated network interfaces, and extended 12C buses. The most flexible in building clus-ters are those interconnects that allow daisy chaining of machines into a physical cluster. Other interconnects may require concentrators or other external hardware.

Effective management of a cluster involves the integration of in-band and out-of-band management paths. This allows the administrator to control the cluster node in the event of a hard failure and also allows the OS to be managed. This is illustrated in Fig 1.

Availability Clusters

High Availability refers to the notion that nodes within a cluster can automatically take over for nodes that fail. There are typically two views of availability within a cluster: redundancy and fail-over.

A properly partitioned cluster serving static Web content through a load balanced provides automatic redundancy. If a Web-serving node fails, then the load balancer just stops sending traffic to that node. This provides a level of innate redundancy that wouldn't be available outside of a cluster.

The more popular view of availability clustering is that of fail-over. Using fail-over technology, machines within a cluster are assigned backup nodes. Each protected machine sends periodic "heartbeat" messages to its back-up node. If the heartbeat fails to appear in some configurable time period, then the applications (and other resources such as the node's virtual IP address) are taken over by the back-up node.

When nodes that are actively running applications back each other up, this is known as an "active-active" configuration (since both machines are actively doing work). The opposite of this is "active-standby," where a back-up machine is dedicated to no other purpose than providing back up to an application server.

The benefit of an active-active fail-over solution is that each node within a cluster is doing work. Setting up an active-active configuration requires some amount of capacity planning to ensure that the workload that each would assume in the case of a failure doesn't overwhelm the machine.

Applications that migrate from a failing node to a backup node may require that application's data to be available on both nodes. This is typically achieved through shared storage. This storage may be a shared SCSI disk drive or virtual shared storage through a volume of file level disk mirroring software.

Storage Architectures

Cooperating nodes within a cluster often require access to the same data files. In the case of static content such as Web pages, these files may be periodically distributed to each node within a cluster. This is achieved using replication software.

Dynamic data such as a shared database or rapidly changing data files must reside on storage that is easily accessible to each node within a cluster. There are a couple of ways to achieve this. A cluster can contain a Network Attached Storage device or may access shared drives on a storage array network.

Network Attached Storage (NAS) is, perhaps, the simplest and most flexible method to add storage to a cluster. A NAS device is a specialized appliance that controls some amount of storage and looks to the nodes within a cluster as if they are a collection of file shares. Most NAS appliances export NFS (for sharing file systems in UNIX environments) and CIFS (the file sharing mechanism used in the Windows world).

Back-end storage on a NAS device could be anything from a collection of disks to high-level RAID arrays. The choice of which to use is highly dependent upon the problem being solved by the cluster. The network connection between the storage nodes and the other nodes within a cluster is, typically, a high-speed network such as l00Mbit or Gigabit Ethernet.

The other common storage architecture used in clusters is the Storage Area Network (SAN). The most popular type of SAN is the Fibre Channel Arbitrated Loop (FCAL). SANs allow direct, very high speed, connection between the storage and the cluster nodes.

SAN architectures provide a very high-end and expensive solution to the storage problem. It is most valuable in applications that require very fast access to shared drives. In contrast, NAS devices are economical and usually offer more than enough performance for Web content serving applications where the performance of the application is often bounded by the speed of the incoming Internet connection.

Application Specific Server Appliances

Some tasks within a content serving cluster cannot be satisfied using generic servers or storage nodes. These problems are often solved with server appliances tuned to easily solve a particular problem. Examples of application specific server appliances include devices such as load balancers, commerce accelerators, and content cache engines.

Load balancers are widely used in Web serving clusters. These appliances provide a single point of interface to an IP address. Incoming requests to a Web site or IP address are, then, routed by the load balancer to one of an array of Web serving nodes within the cluster.

Web sites that require the user to enter confidential information such as credit card numbers or stock-trading information use an encrypted communication path known as Secure Socket Layer (SSL). Commerce acceleration engines provide a highly tuned hardware and software package to very quickly process SSL traffic. Combined with load balancers that can differentiate SSL traffic from non-SSL traffic, commerce acceleration appliances can provide great benefit by directing traffic to the servers most capable of handling it.

Content caching engines provide storage for very frequently accessed Web content. These appliances live between the back-end Web servers and a user's Internet Service Provider to offer up Web pages without impacting the backend servers. Properly configured and placed, these can offer a great performance boost to an active Web site.

Building the Cluster

There are no great secrets to building an effective cluster. Choose wisely and building a cluster becomes the simple matter of plugging the necessary components together. A typical cluster is illustrated in Fig 2.

The important thing is to understand the problem to be solved. Research and fully understand the benefits offered by the underlying technologies (this article has barely scratched the surface). High traffic Web sites that perform a large number of SSL transactions may benefit from commerce accelerators and caching engines, while application service providers may need high-speed SAN storage arrays.

Whatever cluster is developed, it should have a consistent management interface. Out-of-band management is essential to limit the amount of time required for a technician to be standing in front of a machine. This becomes crucial as co-location sites become more and more prevalent for content serving on the Web.

Steven McDowell leads the platform software team at Network Engines, Inc. (Canton, MA).