Server Clustering

Context

You are designing an infrastructure tier upon which an application will be deployed. Your operational requirements include availability or performance capabilities that cannot be met because either performance bottlenecks or single points of failure exist in your infrastructure.

Problem

How do you provide an infrastructure for your application that meets specific operational requirements such as availability and scalability?

Forces

• As you are designing your infrastructure, consider the following forces:

• Users expect applications to be available and responsive when they use them.

• Continuous uptime in a production environment, whether it is a database powering a critical client/server application or an e-commerce Web site, is becoming a common business requirement.

• There is a potential for high monetary loss when an application fails. For example, a high-volume online store bringing in $25,000 per hour goes down due to a single server that fails in the infrastructure. The monetary impact can become quite severe if the outage lasts for several hours.

• All systems within an application infrastructure require maintenance. Individual systems must be able to accommodate both hardware and software upgrades without incurring application downtime. For example, a patch is released to repair a security issue associated with a component running on a server that delivers the application. If this is the only server, the application will experience downtime. If it is one of a series of servers, only the server will experience downtime, not the application.

• Adding hardware can increase the cost and complexity of the solution. For example, new or more capable hardware requires additional development and testing to enable an application to take full advantage of the more capable environment. Additional maintenance and training costs are also associated with managing a more complex environment.

Solution

Design your application infrastructure so that your servers appear to users and applications as virtual unified computing resources. One means by which to achieve this virtualization is by using a server cluster. A server cluster is the combination of two or more servers that are interconnected to appear as one, thus creating a virtual resource that enhances availability, scalability, or both.

Clustering servers might include the goal of increasing availability by ensuring that if a server becomes unavailable due to failure or planned downtime, another server in the cluster can assume the workload (see the Failover Cluster pattern). This type of clustering avoids loss of service to the users or applications that access the cluster and can occur transparently, without the users’ knowledge.

You can also use clustering to enhance scalability. Server clusters can support more users at the current level of performance or improve application performance for the current number of users by sharing the workload across multiple servers. A byproduct of clustering servers for scalability is that the additional redundancy of the multiple servers helps increase system availability, as mentioned earlier (see the Load-Balanced Cluster pattern).

Figure 7.2: Basic clustering concepts

Figure 7.2 illustrates how server clustering can make two or more servers (Server 1 through Server n) appear as one virtual resource to a dependent application.

Asymmetric Clusters

In asymmetric clusters, a standby server exists only to take over for another server in the event of failure. This type of cluster is usually used to provide high availability and scalability for read/write stores such as databases, messaging systems, and file and print services. If one of the nodes in a cluster becomes unavailable, due to either planned downtime for maintenance or unplanned downtime due to failure, another node takes over the function of the failed node.

The standby server performs no other useful work and is either as capable as or less capable than a primary server. A less capable, less expensive standby server is often used when primary servers are configured for high availability and fault tolerance with multiple redundant subsystems. One common type of asymmetric cluster is known as a failover cluster (see the Failover Cluster pattern).

Figure 7.3: Asymmetric cluster

Figure 7.3 illustrates how an asymmetric cluster presents a virtual resource to an application. Under normal conditions, the primary server handles all requests. In the event of a failure, the standby server takes over handling all requests.

Symmetric Clusters

In symmetric clusters, every server in the cluster performs useful work. Typically, each server is the primary server for a particular set of applications. If one server fails, the remaining server continues to process its assigned set of applications as well as the applications on the failed server. Symmetric clusters are more cost-effective because they use more of the cluster’s resources more often; however, in the event of a failure, the additional load on the remaining servers could cause them to fail as well.

Figure 7.4: Symmetric cluster

Figure 7.4 illustrates how a symmetric cluster presents a virtual resource to an application. Requests are divided among healthy servers to distribute load and increase scalability.

One common type of symmetric cluster is a load-balanced cluster (see the Load-Balanced Cluster pattern). Load-balanced clusters enhance the performance, availability, and scalability of services such as Web servers, media servers, VPN servers, and read-only stores by distributing requests across all of the healthy servers in the server cluster.

Example

See the Load Balanced Cluster and Failover Cluster patterns.

Resulting Context

Server Clustering results in the following benefits and liabilities:

Benefits

• Improved scalability. Server Clustering enables applications to handle more load.

• Higher availability. Server Clustering helps applications avoid interruptions in service.

• Greater flexibility. The ability of clustering to present a virtual unified computing resource provides IT personnel with more options for configuring the infrastructure to support application performance, availability, and scalability requirements.

Liabilities

• Increased infrastructure complexity. Some clustering designs significantly increase the complexity of your solution, which may affect operational and support requirements. For example, clustering can increase the numbers of servers to manage, storage devices to maintain, and network connections to configure and monitor.

• Additional design and code requirements. Applications may require specific design and coding changes to function properly when used in an infrastructure that uses clustering. For example, the need to manage session state can become more difficult across multiple servers and could require coding changes to accommodate maintaining state so that session information is not lost if a server fails.

• Incompatibility. An existing application or application component may not be able to support clustering technologies. For example, a limitation in the technology used to develop the application or component may not support clustering even through code changes.

Related Patterns

For more information, see the following related patterns:

• Tiered Distribution. Tiered Distribution organizes the system infrastructure into a set of physical tiers to optimize server environments for specific operational requirements and system resource usage.

• Load-Balanced Cluster. Load-balanced clusters can improve application performance for the current number of users by sharing the workload across multiple servers.

• Failover Cluster. Failover clusters can increase availability by creating redundancy in the infrastructure.

Acknowledgments

[Microsoft03] Microsoft Corporation. “Technical Overview of Windows Server 2003 Clustering Services.” Available on the Microsoft Windows Server 2003 Web site at: http://www.microsoft.com/windowsserver2003/techinfo/overview/clustering.mspx.

[Marcus00] Marcus, Evan, and Hal Stern. Blueprints for High Availability: Designing Resilient Distributed Systems. John Wiley & Sons, 2000.