**********************************************************************
Upgrading and Installing on Cluster Nodes
Release Notes, Part 4 of 4
Beta 2
**********************************************************************
(c) 2001 Microsoft Corporation. All rights reserved.
These notes support a preliminary release of a software program that
bears the project code name Whistler.
With Whistler Datacenter Server, you can use clustering to ensure
that users have constant access to important server-based resources.
With clustering, you create several cluster nodes that appear to
users as one server. If one of the nodes in the cluster fails, another
node begins to provide service (a process known as failover).
Mission critical applications and resources remain continuously
available.
Sections to read if you are upgrading:
1.0 Upgrading or Installing Clustering
1.2 Options for Upgrading or Installing Clustering
2.0 Upgrading a Cluster from Windows 2000 to Whistler
2.1 How Rolling Upgrades Work
2.2 Restrictions on Rolling Upgrades
2.3 Resource Behavior During Rolling Upgrades
2.4 Alternatives to Rolling Upgrades from Windows 2000
Sections to read if you are performing a new installation:
1.0 Upgrading or Installing Clustering
1.2 Options for Upgrading or Installing Clustering
3.0 Installation on Cluster Nodes
======================================================================
1.0 Upgrading or Installing Clustering
======================================================================
Before installing or upgrading clustering, you should familiarize
yourself with the basic preparations needed and the options available
for upgrading and installing. The following sections provide
information on these topics.
1.1 Preparing for Upgrading or Installing Clustering
======================================================================
To prepare for installing or upgrading clustering, review the
sections earlier in this text file series. As described in those
sections, check the Hardware Compatibility List to ensure that all
your hardware (including your cluster storage) is compatible with
Whistler Datacenter Server. In addition, check with the manufacturer
of your cluster storage hardware to be sure you have the drivers you
need in order to use the hardware with Whistler Datacenter Server.
1.2 Options for Upgrading or Installing Clustering
======================================================================
When installing or upgrading clustering, you can choose among several options. You can:
* Upgrade a cluster that is running Windows 2000, possibly
through a rolling upgrade. For more information, see "How
Rolling Upgrades Work" and "Restrictions on Rolling Upgrades"
later in this text file.
* Perform a new installation of Whistler Datacenter Server and
install Cluster service at the same time. For important
information about preparing for cluster installation,
see "Installation on Cluster Nodes" later in this text file.
Note: For cluster disks, you must use the NTFS file system and
configure the disks as basic disks. You cannot configure cluster disks
as dynamic disks, and you cannot use features of dynamic disks such as
spanned volumes (volume sets). For more information about the
limitations of server clusters, see Whistler Help and Support
Services. To open Help and Support Services, after completing Setup,
click Start, and then click Help.
For more information about reinstalling clustering on one of the
cluster nodes, see Whistler Help and Support Services.
======================================================================
2.0 Upgrading a Cluster from Windows 2000 to Whistler
======================================================================
If you are upgrading from Windows 2000 to Whistler on cluster nodes,
you might be able to perform a rolling upgrade of the operating
system. In a rolling upgrade, you sequentially upgrade the operating
system on each node, making sure that one node is always available to
handle client requests. When you upgrade the operating system, the
Cluster service is automatically upgraded also. A rolling upgrade
maximizes availability of clustered services and minimizes
administrative complexity. For more information, see the following
section, "How Rolling Upgrades Work."
To determine whether you can perform a rolling upgrade and understand
the effect that a rolling upgrade might have on your clustered
resources, see "Restrictions on Rolling Upgrades" later in this text
file series. For information about ways to upgrade your cluster nodes
if you cannot perform a rolling upgrade, see "Alternatives to Rolling
Upgrades from Windows 2000" later in this text file series.
2.1 How Rolling Upgrades Work
======================================================================
This section describes rolling upgrades on server clusters. For
information about methods, restrictions, and alternatives to rolling
upgrades, see the following sections.
There are two major advantages to a rolling upgrade. First, there is
a minimal interruption of service to clients. (However, server
response time might decrease during the phases in which one node
handles the work of the entire cluster.) Second, you do not have to
recreate your cluster configuration. The configuration remains intact
during the upgrade process.
A rolling upgrade starts with two cluster nodes that are running
Windows 2000. In this example, they are named Node 1 and Node 2.
Phase 1: Preliminary
Each node runs Windows 2000 Datacenter Server with the following
hardware and software:
* A cluster storage unit using Fibre Channel, not SCSI. Fibre
Channel is the only type of cluster storage on the Hardware
Compatibility List for Datacenter Server. (Note that SCSI can be
used for a two-node cluster with Advanced Server, not Datacenter
Server.)
* The Cluster service component (one of the optional components of
Windows 2000 Datacenter Server).
* Applications that support a rolling upgrade. For more information,
see the product documentation and "Resource Behavior During
Rolling Upgrades" later in this text file.
At this point, your cluster is configured so that each node handles
client requests (an active/active configuration).
Phase 2: Upgrade Node 1
Node 1 is paused, and Node 2 handles all cluster resource groups while
you upgrade the operating system of Node 1 to Whistler Datacenter
Server.
Phase 3: Upgrade Node 2
Node 1 rejoins the cluster. Node 2 is paused and Node 1 handles all
cluster resource groups while you upgrade the operating system on
Node 2.
Phase 4: Final
Node 2 rejoins the cluster, and you redistribute the resource groups
back to the active/active cluster configuration.
Important: For cluster disks, you must use the NTFS file system and
configure the disks as basic disks. You cannot configure cluster disks
as dynamic disks, and you cannot use features of dynamic disks such as
spanned volumes (volume sets).
2.1.1 Performing a Rolling Upgrade
----------------------------------------------------------------------
For an outline of the rolling upgrade process, see the preceding
section, "How Rolling Upgrades Work."
Important: For information about what resources are supported during
rolling upgrades, see "Restrictions on Rolling Upgrades" and "Resource
Behavior During Rolling Upgrades" later in this text file series.
>>> To perform a rolling upgrade:
1. In Cluster Administrator, click the node that you want to upgrade
first.
2. On the File menu, click Pause Node.
3. In the right pane, double-click Active Groups.
4. In the right pane, click a group, and then on the File menu, click
Move Group. Repeat this step for each group listed.
The services will be interrupted during the time they are being
moved and restarted on another node. After the groups are moved,
one node is idle, and the other nodes handle all client
requests.
5. Use Whistler Datacenter Server Setup to upgrade the paused node
from Windows 2000. For information about running Setup, see
sections earlier in this text file series.
Setup detects the earlier version of clustering on the paused node
and automatically installs clustering for Whistler Datacenter
Server. The node automatically rejoins the cluster at the end of
the upgrade process, but is still paused and does not handle any
cluster-related work.
6. To verify that the node that was upgraded is fully functional,
perform validation tests on it.
7. In Cluster Administrator, click the node that was paused, and then
on the file menu, click Resume Node.
8. Repeat the preceding steps for any remaining node or nodes.
2.2 Restrictions on Rolling Upgrades
======================================================================
There are several basic restrictions to the rolling-upgrade process.
They involve the beginning of Phase 3, in which you operate a mixed-version cluster: a cluster in which the nodes run different versions
of the operating system. For a mixed-version cluster to work, the
different versions of the software running on each node must be
prepared to communicate with one another. This requirement leads to
several basic restrictions on the rolling-upgrade process.
* For a successful rolling upgrade, every resource that the cluster
manages must be capable of a rolling upgrade. For more
information, see "Resource Behavior During Rolling Upgrades"
later in this text file.
* During the mixed-version phase of a rolling upgrade, when the
cluster nodes are running different versions of the operating
system, do not change the settings of resources (for example, do
not change the settings of a printer resource).
If preceding restrictions cannot be met, do not perform a rolling
upgrade. For more information, see "Alternatives to Rolling Upgrades
from Windows 2000" later in this text file.
2.2.1 Operation of New Resource Types in Mixed-Version Clusters
----------------------------------------------------------------------
If a resource type that you add to the cluster is supported in one
version of the operating system but not in the other, the operation of
a mixed-version cluster is complicated. For example, Cluster service
in Whistler (part of the Advanced Server and Datacenter Server
products) supports the Generic Script resource type. However, older
versions of Cluster service do not support it. A mixed-version
cluster can run a Generic Script resource on a node running Whistler
but not on a node running Windows 2000.
Cluster service transparently sets the possible owners of new resource
types to prevent these resources from failing over to a Windows 2000
node of a mixed-version cluster. In other words, when you view the
possible owners of a new resource type, a Windows 2000 node will not
be in the list, and you will not be able to add this node to the list.
If you create such a resource during the mixed-version phase of a
rolling upgrade, the resource groups containing those resources will
not fail over to a Windows 2000 node.
2.3 Resource Behavior During Rolling Upgrades
======================================================================
Although Cluster service supports rolling upgrades, not all
applications have seamless rolling-upgrade behavior. The following
table describes which resources will be supported during a rolling
upgrade. If you have a resource that is not fully supported during
rolling upgrades, see "Alternatives to Rolling Upgrades from
Windows 2000" later in this text file.
RESOURCE ROLLING UPGRADE NOTES
-------------- ------------------------------------------------
DHCP Supported during rolling upgrades.
File Share Supported during rolling upgrades.
IP Address Supported during rolling upgrades.
Network Name Supported during rolling upgrades.
NNTP Supported during rolling upgrades.
Physical Disk Supported during rolling upgrades
Time Service Supported during rolling upgrades.
SMTP Supported during rolling upgrades.
WINS Supported during rolling upgrades.
Print Spooler The only Print Spooler resources supported
during a rolling upgrade are those on LPR ports
or standard monitor ports. See the following
section, "Upgrades that Include a Print Spooler
Resource."
IIS Internet Information Server (IIS) 6.0 is not
supported during rolling upgrades. For more
information, see "Upgrades the include an IIS
resource" later in this text file.
MS DTC Microsoft Distributed Transaction
Coordinator is not supported during a rolling
upgrade. However, you can perform a process
similar to rolling upgrades. See "Upgrades that
Include an MS DTC Resource" later in this text file.
MSMQ Microsoft Message Queuing is not supported
during a rolling upgrade. To upgrade a cluster
which includes MSMQ, see "Upgrades that Include
an MSMQ Resource" later in this text file.
Other resource See Readme.doc in the root
types directory of the Whistler Datacenter Server CD.
Also see the product documentation that comes
with the application or resource.
2.3.1 Upgrades that Include a Print Spooler Resource
----------------------------------------------------------------------
If you want to perform a rolling upgrade of a cluster that has a
Print Spooler resource, you must consider two issues.
First, the Print Spooler resource only supports upgrades (including
rolling upgrades or any other kind of upgrade) on printers on
cluster-supported ports (LPR or Standard Monitor ports). For
information about what to do if your printer is not supported, see
"Alternatives to Rolling Upgrades from Windows 2000" later in this
text file series.
Second, when you operate a mixed-version cluster including a Print
Spooler resource, note the following:
* Do not change printer settings in a mixed-version cluster with a
Print Spooler resource.
* If you add a new printer, when you install the drivers for that
printer, be sure to install both the driver for Windows 2000 and
the driver for Whistler on all nodes.
* If printing preferences or defaults are important, be sure to
check them. Printing preferences in Whistler won't necessarily
correspond to document defaults for the same printer in Windows
2000. This can be affected by differences in the drivers for the
two operating systems.
When the rolling upgrade is complete and both cluster nodes are
running the updated operating system, you can make any modifications
you choose to your printer configuration.
2.4 Alternatives to Rolling Upgrades from Windows 2000
======================================================================
Certain resources are not supported during rolling upgrades,
including:
* Internet Information Server (IIS)
* Microsoft Data Transaction Coordinator (MS DTC)
* Microsoft Message Queuing (MSMQ)
Special procedures, described below, must be followed when performing
an upgrade of a cluster that contains these resources. In addition to
the three resource types above, you might also have other resources that are not supported during rolling upgrades. Be sure to read
Readme.doc in the root directory of the Whistler CD, as well as the
product documentation that comes with the application or resource.
2.4.1 Upgrades that Include an IIS Resource
----------------------------------------------------------------------
IIS 6.0 is not supported during rolling upgrades. With earlier
versions of IIS, you could configure an individual Web site to fail
over as a cluster resource. However with IIS 6.0, the entire IIS
service must fail over, not individual Web sites. If you have
individual Web sites or the IIS service configured as a cluster
resource, you must use the following procedure to upgrade to Whistler.
>>> To upgrade from Windows 2000 on a cluster that includes an IIS
resource:
1. Remove any individual Web sites that you have configured as
cluster resources from their cluster group. You can no longer
designate a single site as a cluster resource.
2. If you have the IIS service configured as a cluster resource, take
this resource offline. To take the resource offline, follow the
procedures described in "Upgrades for Other Non-Supported
Resources" later in this text file.
3. Perform a rolling upgrade, as described in the procedure "To
perform a rolling upgrade" earlier in this text file.
4. Once you have completed the upgrade, you can bring the IIS service
back online.
Important: With IIS 6.0, you can only configure the IIS service as a
cluster resource. You cannot configure individual Web sites as cluster
resources.
2.4.2 Upgrades that Include an MS DTC Resource
----------------------------------------------------------------------
Microsoft Distributed Transaction Coordinator (MS DTC) is not
Supported during rolling upgrades. However, you can perform a process
similar to a rolling upgrade.
>>> To upgrade from Windows 2000 on a cluster that includes an MS DTC
resource:
1. Take the MS DTC resource offline by using the Cluster Administrator
and clicking the Resources folder. In the details pane, click the
MS DTC resource, then on the File menu, click Take Offline.
Caution: Taking a resource offline causes all resources that depend
on that resource to be taken offline.
2. Configure the MS DTC resource so that the only allowable owner
is the node it is currently on by using the Cluster
Administrator and clicking the Resource folder. In the details
pane, click the MS DTC resource. On the File menu, click
Properties. On the General tab, next to Possible owners, click
Modify. Specify Node 2 as an Available node, and if necessary,
remove Node 1 from the Available nodes list.
3. Upgrade a node that does not contain the MS DTC resource from
Windows 2000 to Whistler. For general information about Setup,
review the sections earlier in this text file series.
4. Move the MS DTC resource to the upgraded nodes, following the
procedures as described in step 1.
5. Configure the MS DTC resource so that the only allowable owner
is the upgraded node, following the procedures as described in
step 2.
6. Upgrade the remaining nodes from Windows 2000 to Whistler.
7. Configure the allowable owners for the MS DTC resource as
appropriate for your configuration.
8. Manually restart all dependent services, and then bring the MS DTC
resource back online by using the Cluster Administrator
and clicking the Resources folder. In the details pane, click
the MS DTC resource, and then on the File menu, click Bring Online.
2.4.3 Upgrades That Include an MSMQ Resource
----------------------------------------------------------------------
Microsoft Message Queuing (MSMQ) does not support rolling upgrades.
The MSMQ resource is dependent on the MS DTC resource, so be sure to
follow the steps outlined in the preceding section "Upgrades that
Include an MS DTC Resource."
>>> To upgrade from Windows 2000 on a cluster that includes an MSMQ
resource:
1. Upgrade the operating system of the nodes to Whistler.
2. Click Start, point to Programs, point to Administrative Tools, and
then click Configure Your Server.
3. In Configure Your Server, click Finish Setup, and then click
Configure Message Queuing Cluster Resources.
4. Follow the instructions that appear in the Configure Message
Queuing Cluster Resources Wizard.
2.4.4 Upgrades for Other Non-Supported Resources
----------------------------------------------------------------------
If you have other resources on your cluster that are not supported
during a rolling upgrade, but are not described above, take those
resources offline prior to performing the rolling upgrade.
>>> To take a resource offline and perform a rolling upgrade:
1. Confirm that your systems are running Windows 2000.
2. Using the information in "Resource Behavior During Rolling
Upgrades" earlier in this text files, list the resources
in your cluster that are not supported during rolling upgrades.
3. In Cluster Administrator, click the Resources folder.
4. In the right pane, click the resource you want.
5. On the File menu, click Take Offline.
6. Repeat the preceding steps until you have taken offline all
resources that do not support rolling upgrades.
7. Perform a rolling upgrade, as described in the procedure "To
perform a rolling upgrade" earlier in this text file series.
8. For each resource that you listed in step 2, follow the
product's instructions for installing or reconfiguring the
application so that it will run with Whistler.
======================================================================
3.0 Installation on Cluster Nodes
======================================================================
The following sections provide important information about how to
prepare for cluster installation, begin hardware installation for a
cluster, and start Setup on the first cluster node.
3.1 Planning and Preparing for Cluster Installation
======================================================================
Before carrying out cluster installation, you will need to plan
hardware and network details.
Caution: Make sure that Datacenter Server and Cluster service are
installed and running on one node before starting the operating system
on another node. If the operating system is started on multiple nodes
before Cluster service is running on one node, the cluster storage
could be corrupted. Once Cluster service is running properly on one
node, the other nodes can be installed and configured simultaneously.
Each node of your cluster must be running Datacenter Server.
In your planning, review the following items:
* Cluster hardware and drivers.
Check that your hardware, including your cluster storage and
other cluster hardware, is compatible with Whistler Datacenter
Server. To check this, see the Hardware Compatibility List (HCL) on
The Whistler CD, in the Support folder, in Hcl.txt. For the most
up-to-date list of supported hardware, see the Hardware
Compatibility List by visiting the Microsoft Web site at:
http://www.microsoft.com/
You must have a separate PCI storage host adapter (SCSI or Fiber
Channel) for the shared disks. This is in addition to the bootdisk
adapter.
Also check that you have the drivers you need in order to use the
cluster storage hardware with Whistler Datacenter Server. (Drivers
are available from your hardware manufacturer.)
Review the manufacturer's instructions carefully before you begin
installing cluster hardware. Otherwise, the cluster storage could
be corrupted.
To simplify configuration and eliminate potential compatibility
problems, consider using identical hardware for all nodes.
* Network adapters on the cluster nodes.
In your planning, decide what kind of communication each network
adapter will carry.
Note: To reduce the risks with having a single point of failure,
plan on having two or more network adapters in each cluster node,
and connecting each adapter to a physically separate network. The
adapters on a given node must connect to networks using different
subnet masks.
The following table shows recommended ways of connecting network
adapters:
ADAPTERS
PER NODE RECOMMENDED USE
-------- --------------------------------------------------------
2 One private network (node-to-node only), plus
one mixed network (node-to-node plus client-to-cluster).
3 Two private networks (node-to-node), plus
one public network (client-to-cluster).
With this configuration, the adapters using the private
network must use static IP addresses (not DHCP).
or
One private network (node-to-node), plus
one public network (client-to-cluster), plus
one mixed network (node-to-node plus client-to-cluster).
The following list provides more details about the types of
communication that an adapter can carry:
* Only node-to-node communication (private network).
This implies that the server has one or more additional adapters to
carry other communication.
For node-to-node communication, you will connect the network
adapter to a private network used exclusively within the
cluster. Note that if the private network uses a single hub or
network switch, that piece of equipment becomes a potential
point of failure in your cluster.
The nodes of a cluster must be on the same subnet, but you can use
virtual LAN (VLAN) switches on the interconnects between two
nodes. If you use a VLAN, the point-to-point, round-trip latency
must be less than 1/2 second and the link between two nodes must
appear as a single point-to-point connection from the perspective
of the operating system. To avoid single points of failure, use
independent VLAN hardware for the different paths between the
nodes.
If your nodes use multiple private (node-to-node) networks, the
adapters for those networks must use static IP addresses (not
DHCP).
* Only client-to-cluster communication (public network).
This implies that the server has one or more additional adapters to
carry other communication.
* Both node-to-node and client-to-cluster communication (mixed
network).
If you have only one network adapter per node, it must
carry both these kinds of communication. If you have multiple
network adapters per node, a network adapter that carries both
kinds of communication can provide backup for other network
adapters.
* Communication unrelated to the cluster.
If a clustered node also provides services unrelated to the
cluster, and there are enough adapters in the cluster node, you
might want to use one adapter for carrying communication unrelated
to the cluster.
Consider choosing a name for each connection that describes its
purpose. The name will make it easier to identify the connection
whenever you are configuring the server.
* Cluster IP address.
Obtain a static IP address for the cluster itself. You cannot use
DHCP for this address.
* IP addressing for cluster nodes.
Determine how to handle the IP addressing for the cluster nodes.
Each network adapter on each node will need IP addressing. You can
provide IP addressing through DHCP, or you can assign each network
adapter a static IP address. If you use static IP addresses, the
addresses for each linked pair of network adapters (linked
node-to-node) should be on the same subnet.
Note: If you use DHCP for the cluster nodes, it can act as a
single point of failure. That is, if you set up your cluster nodes
so that they depend on a DHCP server for their IP addresses,
temporary failure of the DHCP server can mean temporary
unavailability of the cluster nodes. When deciding whether to use
DHCP, evaluate ways to ensure availability of DHCP services, and
consider the possibility of using long leases for the cluster nodes.
This will help ensure that they always have a valid IP address.
* Cluster name.
Determine or obtain an appropriate name for the cluster. This is
the name administrators will use for connections to the cluster.
(The actual applications running on the cluster will typically have
different network names.) The cluster name must be different from
the domain name, from all computer names on the domain, and from
other cluster names on the domain.
* Computer accounts and domain assignment for cluster nodes.
Make sure that the cluster nodes all have computer accounts in the
same domain. Cluster nodes cannot be in a workgroup.
* Operator user account for installing and configuring the Cluster
service.
To install and configure Cluster service, you must log on to
each node with an account that has administrative privileges on
those nodes.
* Cluster service user account.
Create or obtain Cluster service user account. This is the
name and password under which Cluster service will run. You
will need to supply this user name and password during cluster
installation.
The Cluster service user account should be a new account. The
account must be a domain account; it cannot be a local account. The
account also must have local administrative privileges on all of the
cluster nodes. Be sure to keep the password from expiring on the
account (follow your organization's policies for password renewal).
* Volume for important cluster configuration information (checkpoint
and log files).
You need to plan to set aside a volume on your cluster storage
for holding important cluster configuration information. This
information makes up the quorum resource of the cluster, needed
when a cluster node stops functioning. The quorum resource provides
node-independent storage of crucial data needed by the cluster.
The recommended minimum size for the volume is 500 MB. You should
use a different volume for the quorum resource than you use for user
data.
* List of storage devices or disks attached to the first server on
which you will install clustering.
Unless the first server on which you will install clustering has
relatively few storage devices or disks attached to it, you should
make a list that identifies the ones intended for cluster storage.
This makes it easy to choose storage devices or disks correctly
during cluster configuration.
Note: When planning and carrying out disk configuration for the
cluster disks, configure them as basic disks with all partitions
formatted as NTFS. Do not configure them as dynamic disks, and do
not use Encrypting File System, volume mount points, spanned volumes
(volume sets), or Remote Storage on the cluster disks.
The following section describes the physical installation of the
cluster storage.
3.2 Beginning the Installation of the Cluster Hardware
======================================================================
The steps you carry out when first physically connecting and
installing the cluster hardware are crucial. Be sure to follow the
hardware manufacturer's instructions for these initial steps.
Important: Carefully review your network cables after connecting them.
Make sure no cables are crossed by mistake (for example, private
network connected to public).
Caution: When you first attach your cluster hardware (the shared bus
and cluster storage), be sure to work only from the firmware
configuration screens on the cluster nodes (a node is a server in a
cluster). On a 32-bit computer, use the BIOS configuration screens. On
a 64-bit computer, use the Extensible Firmware Interface (EFI)
configuration screens. The instructions from your manufacturer will
describe whether these configuration screens are displayed
automatically or whether you must, after turning on the computer,
press specific keys to open them. Follow the manufacturer's
instructions for completing the BIOS or EFI configuration process.
Remain in the BIOS or EFI, and do not allow the operating system to
start during this initial installation phase.
3.3 Completing the Installation
======================================================================
After the BIOS or EFI configuration is completed, start the operating
system on one cluster node only and carry out the installation of
Cluster service. Before starting the operating system on another node,
make sure that Whistler Datacenter Server and Cluster service are
installed and running on that node. If the operating system is started
on multiple nodes before Cluster service is running on one node, the
cluster storage could be corrupted.
While remaining in the BIOS or EFI configuration screens, ensure that
you can scan the bus and see the drives from all cluster nodes.
3.4 Installation on the First Cluster Node
======================================================================
It is important that you work on one node (never two nodes) when you
exit the BIOS or EFI configuration screens and allow the operating
system to start for the first time.
Caution: Make sure that Whistler Datacenter Server and Cluster service
are installed and running on one node before starting the operating
system on another node. If the operating system is started on multiple
nodes before Cluster service is running on one node, the cluster
storage could be corrupted.
3.4.1 Completing the Installation on the First Cluster Node
----------------------------------------------------------------------
If you have not already installed Whistler Datacenter Server on the
first cluster node, install it now. For information about decisions
you must make, such as decisions about licensing and about the
components to install, see the sections earlier in this text file
series.
When Whistler Datacenter Server is installed, use the following
procedure to obtain specific information about how to complete the
installation of the cluster.
>>> To obtain additional information about how to install and
configure Cluster service:
1. With Whistler Datacenter Server running on one cluster node, click
Start, and then click Help and Support.
2. Click Enterprise Technologies, and then click Windows Clustering.
3. Click Server Clusters.
4. Click Checklists: Creating Server Clusters, and then click
Checklist: Creating a server cluster.
5. Use the checklist to guide you through the process of completing
the installation of your server cluster.