Clustering overview2

Windows Clustering Technologies—An Overview
Published: November 2001
Abstract
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.

Microsoft® Windows® 2000 Server Technical Article
The information contained in this document represents the current view of
Microsoft Corporation on the issues discussed as of the date of
publication. Because Microsoft must respond to changing market
conditions, it should not be interpreted to be a commitment on the part of
Microsoft, and Microsoft cannot guarantee the accuracy of any
information presented after the date of publication.
This document is for informational purposes only. MICROSOFT MAKES
NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the
user. Without limiting the rights under copyright, no part of this document
may be reproduced, stored in or introduced into a retrieval system, or
transmitted in any form or by any means (electronic, mechanical,
photocopying, recording, or otherwise), or for any purpose, without the
express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights,
or other intellectual property rights covering subject matter in this
document. Except as expressly provided in any written license agreement
from Microsoft, the furnishing of this document does not give you any
license to these patents, trademarks, copyrights, or other intellectual
property.
© 2001 Microsoft Corporation. All rights reserved. Microsoft, Windows,
and Windows NT are either registered trademarks or trademarks of
Microsoft Corporation in the United States and/or other countries.
Other product and company names mentioned herein may be the
trademarks of their respective owners.
Microsoft Corporation • One Microsoft Way • Redmond, WA 98052-6399 •
USA

Contents
Contents........................................................................................................................................3
Acknowledgements.....................................................................................................................iv
Introduction ..................................................................................................................................1
Cluster Architecture Essentials...................................................................................................3
Server Cluster Architecture.......................................................................................................13
Network Load Balancing Architecture......................................................................................18
Component Load Balancing Architecture................................................................................21
Summary......................................................................................................................................24
Related Links...............................................................................................................................25

Acknowledgements
Manoj Nayar, Product Manager, Microsoft Corporation
Greg Rankich, Product Manager, Microsoft Corporation
Michael Kessler, Technical Editor, Microsoft Corporation
iv

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 .NET Server 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 .NET Server, 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.
Windows Clustering Technologies—An Overview 1

 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
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.
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.
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 .Net Server.
Majority Node Clustering
Windows .NET Server 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 .NET Server, 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 .NET Server 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 .NET Server 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 .NET Server 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 .NET Server
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 .NET server 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 at http://www.microsoft.com/windows2000/server/
• Windows .NET at http://www.microsoft.com/net/
• Application Center 2000 at http://www.microsoft.com/applicationcenter/
• Server Clusters & Load Balancing at www.microsoft.com/windows2000/technologies/clustering/
• Increasing System Reliability and Availability with Windows 2000 at
http://www.microsoft.com/windows2000/server/evaluation/business/relavail.asp
• Hardware Compatibility List at http://www.microsoft.com/hcl/
• Windows 2000 Server Family: Advanced Scalability at
www.microsoft.com/windows2000/advancedserver/evaluation/business/overview/scalable/default.a
sp

Clustering overview2

More Related Content

What's hot (20)

Similar to Clustering overview2 (20)

Recently uploaded (20)

Clustering overview2