Windows Clustering Technologies - An Overview

This article is written for IT managers and examines the cluster technologies available on the Microsoft® Windows® server operating system. Also discussed is how cluster technologies can be architected to create comprehensive, mission-critical solutions that meet the requirements of the enterprise.

On This Page

Introduction Cluster Architecture Essentials Server Cluster Architecture Network Load Balancing Architecture Component Load Balancing Architecture Summary Related Links Acknowledgements

Introduction

Microsoft® listened to customers and has worked steadily to improve the underlying technology architecture of the Windows® operating system.

Microsoft Cluster Technologies

While Windows 2000 represents a dramatic improvement over its predecessors in terms of total uptime (availability), reduced system failure (reliability) and ability to add resources and computers to improve performance (scalability), Windows Server 2003 takes the availability, reliability and scalability of the Windows operating system to the next level by enhancing existing features and providing new options.

Three Part Clustering Strategy

Microsoft clustering technologies are the key to improving availability, reliability and scalability. With Windows 2000 and Windows Server 2003, Microsoft uses a three-part clustering strategy that includes:

• Network Load Balancing provides failover support for IP-based applications and services that require high scalability and availability. With Network Load Balancing (NLB), organizations can build groups of clustered computers to support load balancing of TCP (Transmission Control Protocol), UDP (User Datagram Protocol) and GRE (Generic Routing Encapsulation) traffic requests. Web-tier and front-end services are ideal candidates for NLB.

• Component Load Balancing provides dynamic load balancing of middle-tier application components that use COM+. With Component Load Balancing (CLB), COM+ components can load balanced over multiple nodes to dramatically enhance the availability and scalability of software applications.

• Server Cluster provides failover support for applications and services that require high availability, scalability and reliability. With clustering, organizations can make applications and data available on multiple servers linked together in a cluster configuration. Back-end applications and services, such as those provided by database servers, are ideal candidates for server cluster.

Protection Against Failure

Microsoft cluster technologies guard against three specific types of failure:

• Application/service failure affects application software and essential services.

• System/hardware failure affects hardware components (for example, CPUs, drives, memory, network adapters, power supplies).

• Site failure could be caused by natural disaster, power outages or connectivity outages.

Clustering Technologies—Purposes and Requirements

Each technology has a specific purpose and is designed to meet different requirements.

• Network Load Balancing is designed to address bottlenecks caused by front-end Web services.

• Component Load Balancing is designed to address the unique scalability and availability needs of middle-tier applications.

• Server Cluster is designed to maintain data integrity and provide failover support.

Organizations can use Microsoft cluster technologies to increase overall availability, while minimizing single points of failure and reducing costs by using industry-standard hardware and software.

E-Commerce Scenario

The clustering technologies outlined above can be (and typically are) combined to architect a comprehensive service offering. The most common scenario where all three solutions are combined is an e-commerce site where front-end Web servers use NLB, middle-tier application servers use CLB, and back-end database servers use Server Cluster.

These technologies alone are not enough to ensure the highest levels of availability. To ensure the highest availability for line-of-business applications and mission-critical services, organizations must take an end-to-end service approach to operations and availability. This means treating the entire service offering as a whole and designing, implementing, and operating the service solution following industry-standard best practices, such as those used by Microsoft Enterprise Services.

Topics Covered

The main topics covered in the rest of this article include:

• Cluster Architecture Essentials

• Server Cluster Architecture

• Network Load Balancing Architecture

• Component Load Balancing Architecture

Cluster Architecture Essentials

This section introduces the concept of clustering and its benefits and limitations. It then goes on to discuss cluster organization, infrastructure scaling, cluster operating modes, and how clustering is used on multiple, geographically dispersed sites.

The Concept of a Cluster

The concept of a cluster is to take two or more computers and organize them to work together to provide higher availability, reliability and scalability than can be obtained by using a single system. When failure occurs in a cluster, resources can be redirected and the workload can be redistributed. Typically the end user experiences a limited failure, and may only have to refresh the browser or reconnect to an application to begin working again.

Cluster Benefits and Limitations

A server cluster provides high availability by making application software and data available on several servers linked together in a cluster configuration. If a server stops functioning, a process called failover automatically shifts the workload of the failed server to another server in the cluster. The failover process is designed to ensure continuous availability for critical applications and data.

While clusters can be designed to handle failure, they are not fault tolerant with regard to user data. The cluster by itself doesn't guard against loss of a user's work. Typically, the recovery of lost work is handled by the application software; the application software must be designed to recover the user's work, or it must be designed in such a way that the user session state can be maintained in the event of failure.

Solving Three Typical Problems

Clusters can be used to solve three typical problems in a data center environment:

• Need for High Availability. High availability refers to the ability to provide end user access to a service a high percentage of scheduled time while attempting to reduce unscheduled outages. A solution is highly available if it meets the organization's scheduled uptime goals. Availability goals are achieved by reducing unplanned downtime and then working to improve total hours of service operation.

• Need for High Reliability. High reliability refers to the ability to reduce the frequency of system failure, while attempting to provide fault tolerance in case of failure. A solution is highly reliable if it minimizes the number of single points of failure and reduces the risk that failure of a single component/system will result in the outage of the entire service offering. Reliability goals are achieved using redundant, fault tolerant hardware components, application software and systems.

• Need for High Scalability. High scalability refers to the ability to add resources and computers while attempting to improve performance. A solution is highly scalable if it can be scaled up and out. Individual systems in a service offering can be scaled up by adding more resources (for example, CPUs, memory, disks). The service can be scaled out by adding additional computers.

A well-designed service solution uses redundant systems and components so that the failure of an individual server doesn't affect the availability of the entire service.

Limitations

While a well-designed solution can guard against application failure, system failure and site failure, cluster technologies do have limitations. Cluster technologies depend on compatible applications and services to operate properly. The software must respond appropriately when failure occurs. Cluster technology cannot protect against failures caused by viruses, software corruption or human error. To protect against these types of problems, organizations need solid data protection and recovery plans.

Cluster Organization

Clusters are organized in loosely coupled groups that are often referred to as farms or packs. In most cases, as shown in Figure 1 below, front-end and middle-tiers services are organized as farms using clones, while back-end and critical support services such as component routing, are organized as packs.

IT Staff Considerations

As IT staff architect clustered solutions, they need to look carefully at the cluster organization they plan to use. The goal should be to organize servers according to the way the servers will be used and the applications they will be running. Typically, Web servers, application servers and database servers are all organized differently.

Figure 1: Clusters are organized as farms or packs.

Cluster Farm

A farm is a group of servers that run similar services, but don't typically share data. They are called a farm because they handle whatever requests are passed out to them using identical copies of data that is stored locally. Because they use identical copies of data (rather than sharing data), members of a farm operate autonomously and are also referred to as clones.

Front-end Web servers running Internet Information Services (IIS) and using NLB are an example of a farm. With a Web farm, identical data is replicated to all servers in the farm, and each server can handle any request that comes to it using local copies of the data. Because the servers are identical and the data is replicated to all the servers in the Web farm, the servers are also referred to as clones.

Example—A Load Balanced Web Farm

In a load balanced Web farm with ten servers, you could have:

• Clone 1—Web server using local data

• Clone 2—Web server using local data

• Clone 3—Web server using local data

• Clone 4—Web server using local data

• Clone 5—Web server using local data

• Clone 6—Web server using local data

• Clone 7—Web server using local data

• Clone 8—Web server using local data

• Clone 9—Web server using local data

• Clone 10—Web server using local data

Cluster Pack

A pack is a group of servers that operate together and share partitioned data. They are called a pack because they work together to manage and maintain services. Because members of a pack share access to partitioned data, they have unique operations modes and usually access the shared data on disk drives to which all members of the pack are connected.

Example—A 4-node SQL Server Cluster Pack

An example of a pack is a database Server Cluster running SQL Server 2000 and a server cluster with partitioned database views. Members of the pack share access to the data and have a unique chunk of data or logic that they handle, rather than handling all data requests.

In a 4-node SQL Server cluster:

• Database Server 1 may handle accounts that begin with A-F.

• Database Server 2 may handle accounts that begin with G-M.

• Database Server 3 may handle accounts that begin with N-S.

• Database Server 4 may handle accounts that begin with T-Z.

Combining Techniques— A Large-scale E-Commerce Site

Servers in a tier can be organized using a combination of the above techniques as well. An example of this combination is a large-scale e-commerce site that has middle tier application servers running Application Center 2000 and CLB.

To configure CLB, two clusters are recommended.

• The Component Routing Cluster handles the message routing between the front-end Web servers and the application servers.

• The Application Server Cluster activates and runs the components installed on the application servers.

While the component routing cluster could be configured on the Web tier without needing additional servers, a large e-commerce site may want the high availability benefits of a separate cluster. In this case, the routing would take place on separate servers that are clustered using Server Cluster. The application servers would then be clustered using CLB.

Infrastructure Scaling

With proper architecture, the servers in a particular tier can be scaled out or up as necessary to meet growing performance and throughput needs. Figure 2 below provides an overview of the scalability of Windows clustering technologies.

IT Staff Considerations

As IT staff look at scalability requirements, they must always address the real business needs of the organization. The goal should be to select the right edition of the Windows operating system to meet the current and future needs of the project.

The number of servers needed depends on the anticipated server load, and the size and types of requests the servers will handle. Processors and memory should be sized appropriately for the applications and services the servers will be running, as well as the number of simultaneous user connections.

Figure 2: Windows clustering technologies can be scaled to meet business requirements.

Scaling by Adding Servers

When looking to scale out by adding servers to the cluster, the clustering technology and the server operating system used are both important. As Table 1 below shows, the key difference in the outward scaling capabilities of Advanced Server and Datacenter Server is the number of nodes that can be used with Server Cluster.

• Under Windows 2000, the maximum number of Server Cluster nodes is four.

• Under Windows .NET, the maximum number of Server Cluster nodes is eight.

Table 1 Cluster Nodes Supported by Operating System and Technology.

Operating System	Edition	Network Load Balancing	Component Load Balancing	Server Cluster
Windows 2000
	Advanced Server	32	8	2
	Datacenter Server	32	8	4
Windows .NET
	Advanced Server	32	8	4
	Datacenter Server	32	8	8

Scaling by Adding CPUs and RAM

When looking to scale up by adding CPUs and RAM, the edition of the server operating system used is extremely important.

In terms of both processor and memory capacity, Datacenter Server is much more expandable.

• Advanced Server supports up to eight processors and eight gigabytes (GB) of RAM.

• Datacenter Server supports up to 32 processors and 64 GB of RAM.

Thus, organizations typically scale up from Advanced Server to Datacenter Server as their needs change over time.

Cluster Operating Modes

With NLB and CLB, cluster nodes usually are identical clones of each other. Because of this, all members of the cluster can actively handle requests, and they can do so independent of each other. When members of a cluster share access to data, however, they have unique operating requirements, as is the case with Server Cluster.

IT Staff Considerations

As IT staff consider the impact of operating modes in their cluster architecture, they need to look carefully at the business requirements and the expected server loads.

With NLB and CLB, all servers are active and the architecture is scaled out by adding additional servers, which typically are configured identically to the existing NLB or CLB nodes.

With Server Cluster, nodes can be either active or passive, and the configuration of nodes depends on the operating mode (active or passive), as well as how failover is configured. A server that is designated to handle failover must be sized to handle the workload of the failed and the current workload (if any). Additionally, both average and peak workloads must be considered. Severs need additional capacity to handle peak loads.

Server Cluster Nodes

Server Cluster nodes can be either active or passive.

• Active Node. When a node is active, it is actively handling requests.

• Passive Node. When a node is passive, it is idle, on standby waiting for another node to fail.

Multi-node clusters can be configured using different combinations of active and passive nodes.

Architecting Multi-node Clusters

When architecting multi-node clusters, the decision as to whether nodes are configured as active or passive is extremely important. To understand why, consider the following:

• If an active node fails and there is a passive node available, applications and services running on the failed node can be transferred to the passive node. Since the passive node has no current workload, the server should be able to assume the workload of the other server without any problems (providing all servers have the same hardware configuration).

• If all severs in a cluster are active and a node fails, the applications and services running on the failed node can be transferred to another active node. Since the server is already active, the server will have to handle the processing load of both systems. The server must be sized to handle multiple workloads or it may fail as well.

In a multi-node configuration where there is one passive node for each active node, the servers could be configured so that under average workload they use about 50% of CPU and memory resources.

In the 4-node configuration depicted in Figure 3 below, where failover goes from one active node to a specific passive node, this could mean two active nodes (A1 and A2) and two passive nodes (P1 and P2)—each with four processors and 4GB of RAM. In this example, node A1 fails over to node P1 and node A2 fails over to node P2 with the extra capacity used to handle peak workloads.

Figure 3: Example Active/Passive cluster configurations.

In a multi-node configuration where there are more active nodes than passive nodes, the servers can be configured so that under average workload they use a proportional percentage of CPU and memory resources.

In the 4-node configuration illustrated in Figure 3 above, where nodes A, B, C, and D are configured as active and failover could go to between nodes A and B or nodes C and D, this could mean configuring servers so that they use about 25% of CPU and memory resources under average workload. In this example, node A could fail over to B (and vice versa) or node C could fail over to D (and vice versa).

Because the servers in this example would need to handle two workloads in case of a node failure, the CPU and memory configuration would at least be doubled, so instead of using four processors and four GB of RAM, the servers may use eight processors and eight GB of RAM.

Shared-nothing Database Configuration

When Server Cluster has multiple active nodes, data must be shared between applications running on the clustered servers. In most cases, this is handled with a shared-nothing database configuration.

In a shared-nothing database configuration, the application is partitioned to access private database sections. This means that a particular node is configured with a specific view into the database that allows it to handle specific types of requests, such as account names that started with the letters A-F, and that it is the only node that can update the related section of the database. (This eliminates the possibility of corruption from simultaneous writes by multiple nodes.)

Note: Both Microsoft Exchange 2000 and Microsoft SQL Server 2000 support multiple active nodes and shared-nothing database configurations.

Multiple Sites and Geographically Dispersed Clusters

Most organizations build disaster recovery and increased availability into their infrastructure using multiple physical sites. Multi-site architecture can be designed in many ways. In most cases, the architecture has a primary site and one or more remote sites. Figure 4 below shows an example of a primary site and a remote site for an e-commerce operation.

The architecture at the remote site mirrors that of the primary site. The level of integration for multiple sites, and the level at which components are mirrored between sites, depends on the service-level agreement and the business requirements.

Full Implementation Design

With a full implementation, the complete infrastructure of the primary site could be recreated at remote sites. This allows for a remote site to operate independently, or to handle the full load of the primary site if necessary. In this case, the design should incorporate real-time replication and synchronization for databases and applications.

Real-time replication ensures a consistent state for data and application services between sites. If real-time updates are not possible, databases and applications should be replicated and synchronized as rapidly as possible.

Figure 4: Multiple site architecture

Partial Implementation Design

With a partial implementation only essential components are installed at remote sites to:

• Handle overflow in peak periods

• Maintain uptime on a limited basis in case the primary site fails

• Provide limited services as needed.

Replicating static content on Web sites and read-only data from databases. This partial implementation technique would allow remote sites to handle requests for static content and other types of data that is infrequently changed. Users could browse sites, access account information, product catalogs, and other services. If they needed to access dynamic content or modify information (add, change, delete), the sites' geographical load balancers could redirect users to the primary site.

Implement all layers of the infrastructure, but with fewer redundancies in the architecture, or implement only core components, relying on the primary site to provide the full array of features. With either of these partial implementation techniques the design may need to incorporate near real-time replication and synchronization for databases and applications. This ensures a consistent state for data and application services.

Geographically Dispersed Clusters

A full or partial design could also use geographically dispersed clusters running Server Cluster. Geographically dispersed clusters use virtual LANs to connect storage area networks (SANs) over long distances.

• A VLAN connection with latency of 500 milliseconds or less ensures that cluster consistency can be maintained.

• Storage extensions and replication, if any, are handled by the hardware, and the clustering infrastructure is not aware of any such implementations. Site failures, which could include failure of primary storage, may require manual intervention to keep clustering functional.

Geographically dispersed clusters are also referred to as stretched clusters and are available in Windows 2000 and Windows Server 2003.

Majority Node Clustering

Windows Server 2003 offers many improvements in the area of geographically dispersed clusters, including a new type of quorum resource called a majority node set. Majority node clustering changes the way the cluster quorum resource is used. This allows cluster servers to be geographically separated while maintaining consistency in the event of node failure.

With a standard cluster configuration, as illustrated in Figure 5 below, the quorum resource writes information on all cluster database changes to the recovery logs; this ensures that the cluster configuration and state data can be recovered. The quorum resource resides on the shared disk drives and can be used to verify whether other nodes in the cluster are functioning.

Figure 5: Comparing local and geographically dispersed clusters.

With a majority node cluster configuration in Windows Server 2003, the quorum resource is configured as a majority node set resource. This new type of quorum resource allows the quorum data, which includes cluster configuration changes and state information, to be stored on the system disk of each node in the cluster. Because the cluster configuration data is stored locally, even though the cluster itself is geographically dispersed, the cluster can be maintained in a consistent state. In such a setup one does not need to go through complex setups to maintain quorum information on storage located on the storage interconnect.

As the name implies, the majority of nodes must be available for this cluster configuration to operate normally.

Server Cluster Architecture

This section discusses Server Cluster and how to configure it for failover support for applications and services. Resource groups, cluster storage devices, network configuration, and storage area networks are also discussed.

Server Cluster

Server Cluster is used to provide failover support for applications and services. A Server Cluster can consist of up to eight nodes. Each node is attached to one or more cluster storage devices. Cluster storage devices allow different servers to share the same data, and by reading this data provide failover for resources.

Connecting Storage Devices

The preferred technique for connecting storage devices is fibre channel.

• When using three or more nodes, fibre channel is the only technique that should be used.

• When using 2-node clustering with Advanced Server, SCSI or fibre channel can be used to connect to the storage devices.

Configuring Server Clusters

Server clusters can be setup using many different configurations. Servers can be either active or passive, and different servers can be configured to take over the failed resources of another server. Failover can take several minutes, depending on the configuration and the application being used, but is designed to be transparent to the end-user.

Server Cluster and Failover

When a node is active, it makes its resources available. Clients access these resources through dedicated virtual servers.

Server Cluster uses the concept of virtual servers to specify groups of resources that failover together. When a server fails, the group of resources configured on that server for clustering fail over to another server. The server that handles the failover should be configured for the extra capacity needed to handle the additional workload. When the failed server comes back online, Server Cluster can be configured to allow failback to the original server, or to allow the current server to continue to process requests.

Figure 6: Multi-node clustering with all nodes active

Figure 6 above shows a configuration where all nodes in a database cluster are active and each node has a separate resource group. With a partitioned view of the database, each resource group could handle different types of requests. The types of requests handled could be based on one or more factors, such as the name of an account or geographic location. In the event of a failure, each node is configured to fail over to the next node in turn.

Resource Groups

Resources that are related or dependent on each other are associated through resource groups. Only applications that need high availability should be part of a resource group. Other applications can run on a cluster server, but don't need to be a part of a resource group. Before adding an application to a resource group, IT staff must determine if the application can work within the cluster environment.

Cluster-aware Applications. Applications that can work within the cluster environment and support cluster events are called cluster-aware. Cluster-aware applications can register with the Server Cluster to receive status and notification information.

Cluster-unaware Applications. Applications that do not support cluster events are called cluster-unaware. Some cluster-unaware applications can be assigned to resource groups and can be failed over.

Applications that meet the following criteria can be assigned to resource groups.

• IP-based protocols are used for cluster communications. The application must use an IP-based protocol for their network communications. Applications cannot use NetBEUI, IPX, AppleTalk or other protocols to communicate.

• Nodes in the cluster access application data through shared storage devices. If the application isn't able to store its data in a configurable location, the application data won't be available on failover.

• Client applications experience a temporary loss of network connectivity when failover occurs. If client applications cannot retry and recover from this, they will cease to function normally.

New Features for Resources and Resource Types

Windows Server 2003 adds new features for resources and resource types. A new resource type allows applications to be made cluster-aware using VBScript and JScript. Additionally, Windows Management Instrumentation (WMI) can be used for cluster management and event notification.

Architecting Resource Groups

When architecting resource groups, IT staff should list all server-based applications and services that will run in the cluster environment, regardless of whether they will need high availability. Afterward, divide the list into three sections:

• Those that need to be highly available

• Those that aren't part of the cluster and on which clustered resources do not depend

• Those that are running on the cluster servers that do not support failover and on which the cluster may depend.

Applications and services that need to be highly available should be placed into resource groups. Other applications should be tracked, and their interactions with clustered applications and services should be clearly understood. Failure of an application or service that isn't part of a resource group shouldn't impact the core functions of the solution being offered. If it does, the application or service may need to be clustered.

Note: In the case of dependent services that don't support clustering, IT staff may want to provide backup planning in case these services fail, or may want to attempt to make the services cluster-aware using VBScript and JScript. Remember that only Windows Server 2003 supports this feature.

Focus on selecting the right hardware to meet the needs of the service offering. A cluster model should be chosen to adequately support resource failover and the availability requirements. Based on the model chosen, excess capacity should be added to ensure that storage, processor and memory are available in the event a resource fails, and failover to a server substantially increases the workload.

With a clustered SQL Server configuration, IT staff should consider using high-end CPUs, fast hard drives and additional memory. SQL Server 2000 and standard services together use over 100 MB of memory as a baseline. User connections consume about 24 KB each. While the minimum memory for query execution is one MB of RAM, the average query may require two to four MB of RAM. Other SQL Server processes use memory as well.

Optimizing Cluster Storage Devices

Cluster storage devices should be optimized based on performance and availability needs. While the Windows Datacenter Hardware Compatibility List provides a detailed list of acceptable RAID configurations for clusters, Table 2 below provides an overview of common RAID configurations. The table entries are organized from the highest RAID level to the lowest.

Table 2 RAID Configurations

RAID Level	RAID Type	RAID Description	Advantages & Disadvantages
5+1	Disk striping with parity + mirroring	Six or more volumes, each on a separate drive, are configured identically as a mirrored stripe set with parity error checking.	Provides very high level of fault tolerance but has a lot of overhead.
5	Disk striping with parity	Three or more volumes, each on a separate drive, are configured as a stripe set with parity error checking. In the case of failure, data can be recovered.	Fault tolerance with less overhead than mirroring. Better read performance than disk mirroring.
1	Disk mirroring	Two volumes on two drives are configured identically. Data is written to both drives. If one drive fails, there is no data loss because the other drive contains the data. (Does not include disk striping.)	Redundancy. Better write performance than disk striping with parity.
0+1	Disk striping with mirroring	Two or more volumes, each on a separate drive, are striped and mirrored. Data is written sequentially to drives that are identically configured.	Redundancy with good read/write performance.
0	Disk striping	Two or more volumes, each on a separate drive, are configured as a stripe set. Data is broken into blocks, called stripes, and then written sequentially to all drives in the stripe set.	Speed/Performance without data protection.

Optimizing Network Configuration

The network configuration of the cluster can also be optimized. All nodes in a cluster must be a part of the same domain and can be configured as domain controllers or member servers. Ideally, multi-node clusters will have at least two nodes that act as domain controllers and provide failover for critical domain services. If this isn't the case, the availability of cluster resources may be tied to the availability of the controllers in the domain.

Private and Public Network Addresses

Typically nodes in a cluster are configured with both private and public network addresses.

• Private network addresses are used for node-to-node communications.

• Public network addresses are used for client-to-cluster communications.

Some clusters may not need public network addresses and instead may be configured to use two private networks. In this case, the first private network is for node-to-node communications and the second private network is for communicating with other servers that are a part of the service offering.

Storage Area Networks

Increasingly, clustered servers and storage devices are connected over SANs. SANs use high-performance interconnections between secure servers and storage devices to deliver higher bandwidth and lower latency than comparable traditional networks. Windows 2000 and Windows .NET Datacenter Server implement a feature called Winsock Direct that allows direct communication over a SAN using SAN providers.

SAN providers have user-mode access to hardware transports. When communicating directly at the hardware level, the individual transport endpoints can be mapped directly into the address space of application processes running in user mode. This allows applications to pass messaging requests directly to the SAN hardware interface, which eliminates unnecessary system calls and data copying.

SANs typically use two transfer modes. One mode is for small transfers, which primarily consist of transfer control information. For large transfers, SANs can use a bulk mode whereby data is transferred directly between the local system and the remote system by the SAN hardware interface without CPU involvement on the local or remote system. All bulk transfers are pre-arranged through an exchange of transfer control messages.

Other SAN Benefits

In addition to improved communication modes, SANs have other benefits.

• They allow IT staff to consolidate storage needs, using several highly reliable storage devices instead of many.

• They also allow IT staff to share storage with non-Windows operating systems, allowing for heterogeneous operating environments.

Network Load Balancing Architecture

This section discusses Network Load Balancing and its role in providing failover support for IP-based applications and services that require high scalability and availability.

Network Load Balancing

Network Load Balancing (NLB) provides failover support for IP-based applications and services that require high scalability and availability. NLB allows IT staff to incrementally scale-out up to 32 servers as demand increases. NLB is ideally suited to improving the availability of Web servers, media servers, terminal servers and e-commerce sites. Load balancing these services ensures there is no single point of failure and that there is no performance bottleneck.

Many of the concepts that apply to Server Cluster also apply to NLB. NLB nodes work together to provide availability for critical IP-based resources, which can include: TCP (Transmission Control Protocol), UDP (User Datagram Protocol) and GRE (Generic Routing Encapsulation) traffic requests.

Note: Support for GRE traffic is supported in Windows Server 2003 and not in Windows 2000.

Failover and Failback Using a Virtual IP Address

As shown in Figure 7 below, NLB uses a virtual IP address. Client requests are directed to this virtual IP address which allows for transparent failover and failback. When a load balanced resource fails on one server, the remaining servers in the group take over the workload of the failed server. When the failed server comes back online, the server can automatically rejoin the cluster group and NLB starts to automatically distribute the load to the server. Failover takes less than 10 seconds in most cases.

Figure 7: Network load balancing using virtual IP addresses

No Clustered Storage Devices

NLB doesn't use clustered storage devices. Each server runs a copy of the IP-based application or service that is being load balanced, and the data necessary for the application or service to run is stored on local drives.

Directing Traffic to a Specific Server

Although NLB is normally used to distribute the workload for an application or service, NLB can also be used to direct a specific type of traffic to a particular server. For example, IT staff may want to load balance HTTP and FTP traffic to a group of servers, but may also want a single server to handle media services traffic. In this latter case, NLB allows traffic to flow to a designated server and only reroutes traffic to another server in case of failure.

No Hardware Changes Required

NLB runs as a network driver and requires no hardware changes to install and run. Its operations are transparent to the IP networking stack. Because NLB is IP-based, IP networking must be installed on all load balanced computers.

NLB Network Adapters

To provide high performance throughput and responsiveness, NLB normally uses two network adapters.

• Cluster adapter—handles network traffic for the cluster.

• Dedicated adapter—handles client-to-cluster network traffic, and other traffic originating outside the cluster network.

NLB uses unicast or multicast broadcasts to direct incoming traffic to all servers in the cluster. The NLB driver on each host acts as a filter between the cluster adapter and the TCP/IP stack, allowing only traffic bound for the designated host to be received. NLB only controls the flow of TCP, UDP and GRE traffic on specified ports. It doesn't control the flow of TCP, UDP and GRE traffic on non-specified ports, and it doesn't control the flow of other incoming IP traffic. All traffic that isn't controlled is passed through without modification to the IP stack.

Using a Single NLB Network Adapter

NLB can work with a single network adapter. When it does so, there are limitations.

Unicast mode. With a single adapter in unicast mode, node-to-node communications are not possible—meaning nodes within the cluster cannot communicate with each other. Servers can, however, communicate with servers outside the cluster subnet.

Multicast mode. With a single adapter in multicast mode, node-to-node communications are possible, as are communications with servers outside the cluster subnet. However, the configuration is not optimal for handling moderate-to-heavy traffic from outside the cluster subnet to specific cluster hosts.

For handling node-to-node communications and moderate to heavy traffic, two adapters should be used.

Optimizing NLB Servers

As with Server Cluster, servers that use NLB can benefit from optimization. Servers should be optimized for their role, the types of applications they will run and the anticipated local storage they will use.

While IT staff may want to build redundancy into the local hard drives on NLB servers, this adds to the expense of the server without significant availability gains in most instances. Because of this, NLB servers often have drives that do not use RAID and do not provide fault tolerance; the idea being that if a drive causes a server failure, other servers in the NLB cluster can quickly take over the workload of the failed server.

Synchronizing Data

If it seems odd not to use RAID, keep in mind that servers using NLB are organized as clones with identical copies of data on each server. Because many different servers have the same data, maintaining the data with RAID sets isn't as important as it is with server clusters. A key consideration IT staff does have to make when using NLB, however, is data synchronization. The state of the data on each server must be maintained so that the clones are updated whenever changes are made. This need to synchronize data periodically is an overhead that needs to be considered when designing the server architecture.

Component Load Balancing Architecture

This section discusses CLB and its key structures. Also discussed are routing servers; designing and optimizing CLB clusters; and storage and memory requirements.

Component Load Balancing

Unlike Server Cluster and NLB, which are built into the Advanced Server and Datacenter Server editions of the Windows operating system, CLB is a feature of Microsoft Application Center 2000. It is designed to provide high availability and scalability for transactional components. CLB is scalable up to eight servers and is ideally suited to building distributed solutions.

CLB makes use of the COM+ Services supplied as part of the Windows 2000 and Windows Server 2003 operating systems. COM+ Services provide:

• Enterprise functionality for transactions

• Object management

• Security

• Events

• Queuing

COM+ components use the Component Object Model (COM) and COM+ Services to specify their configuration and attributes. Groups of COM+ components that work together to handle common functions are referred to as COM+ applications.

CLB—Key Structures

Figure 8 below provides an overview of CLB. CLB uses several key structures:

• CLB Software handles the load balancing and is responsible for determining the order in which cluster members activate components.

• The router handles message routing between the front-end Web servers and the application servers. It can be implemented through component routing lists stored on front-end Web servers, or a component routing cluster configured on separate servers.

• Application server clusters activate and run COM+ components. The application server cluster is managed by Application Center 2000.

Figure 8: Component Load Balancing

Routing List

The routing list, made available to the router, is used to track the response time of each application server from the Web servers. If the routing list is stored on individual Web servers, each server has its own routing list and uses this list to periodically check the response times of the application servers. If the routing list is stored on a separate routing cluster, the routing cluster servers handle this task.

The goal of tracking the response time is to determine which application server has the fastest response time from a given Web server. The response times are tracked as an in-memory table, and are used in round robin fashion to determine to which application server an incoming request should be passed. The application server with the fastest response time (and theoretically, the least busy and most able to handle a request) is given the next request. The next request goes to the application server with the next fastest time, and so on.

Designing CLB Clusters

The architecture of CLB clusters should be designed to meet the availability requirements of the service offering. With small-to-moderate sized implementations, the front-end Web servers can host the routing list for the application server cluster. With larger implementations, dedicated routing clusters are desirable to ensure that high availability requirements can be met.

Optimizing CLB Servers

As with NLB, servers in CLB clusters should be optimized for their role, the types of applications they will run and the anticipated local storage they will use.

High Speed Connections

Routing servers maintain routing lists in memory and need high-speed connections to the network.

Storage and Memory Requirements

Whether configured separately or as part of the front-end, CLB doesn't require a lot of storage, but a limited amount of additional RAM may be required. Application servers on the other hand, typically need a lot of RAM, fast CPUs and limited redundancy in the drive array configuration. If redundant drive arrays are used, a basic configuration, such as RAID 1 or RAID 5, may be all that is needed to maintain the level of availability required.

Summary

Cluster technologies are becoming increasingly important to that ensure service offerings meet the requirements of the enterprise. Windows 2000 and Windows Server 2003 support three cluster technologies to provide high availability, reliability and scalability. These technologies are: NLB, CLB and Server Cluster. These technologies have a specific purpose and are designed to meet different requirements.

• Server Cluster provides failover support for applications and services that require high availability, scalability and reliability, and is ideally suited for back-end applications and services, such as database servers. Server Cluster can use various combinations of active and passive nodes to provide failover support for mission critical applications and services.

• NLB provides failover support for IP-based applications and services that require high scalability and availability, and is ideally suited for Web tier and front-end services. NLB clusters can use multiple adapters and different broadcast methods to assist in the load balancing of TCP, UDP and GRE traffic requests.

• Component Load Balancing provides dynamic load balancing of middle-tier application components that use COM+ and is ideally suited for application servers. CLB clusters use two clusters. The routing cluster can be configured as a routing list on the front-end Web servers or as separate servers that run Server Cluster.

Cluster technologies by themselves are not enough to ensure that high availability goals can be met. Multiple physical locations may be necessary to guard against natural disasters and other events that may cause complete service outage. Effective processes and procedures, in addition to good architecture, are the keys to high availability.

Related Links

See the following resources for further information:

• Windows 2000 Server

• Microsoft TechNet

• Application Center 2000

• Server Clusters & Load Balancing

• Increasing System Reliability and Availability with Windows 2000

• Hardware Compatibility List

• Windows 2000 Server Family: Advanced Scalability

Acknowledgements

Manoj Nayar, Product Manager, Microsoft Corporation

Greg Rankich, Product Manager, Microsoft Corporation

Michael Kessler, Technical Editor, Microsoft Corporation