Clustering Microsoft Exchange Server 2003 servers can potentially improve service levels by reducing downtime—especially planned downtime, when you have to reboot servers after applying monthly Microsoft patches. Windows Server 2003 includes enhancements that make setting up and deploying a cluster much easier than under Windows 2000 Server. If you believe clustering can benefit your Exchange organization and are ready to get started, this article can help guide you through the cluster-setup process. In part 1, I explain Exchange clustering basics and the preparatory steps you must take before building a new two-node Exchange 2003 Service Pack 1 (SP1) cluster running on Windows 2003 SP1. Part 2, which will appear in an upcoming issue of Windows IT Pro, will explain how to install Exchange 2003 on a Windows 2003 SP1 cluster and post-installation best practices.
Exchange Virtual Servers
Clusters are groups of servers configured to work together to provide the image of a single server. Microsoft Outlook clients access Exchange running on a cluster via the Exchange Virtual Server (EVS) service. To a user, an EVS looks like a typical standalone server. An EVS contains these Exchange cluster resources:
Before you can install an EVS, you must manually create the following cluster resources by using the Cluster Administrator program:
Later I'll outline the steps for creating an Exchange cluster group and the resources that the EVS requires. When you configure an Exchange 2003 cluster, the Exchange Setup program places all these resources in a resource group (called an Exchange cluster group). An EVS can't be split across separate resource groups, which ensures that the resources and virtual servers all fail over as a single unit and that resource-group integrity is maintained.
Exchange Cluster Models
Exchange 2003 supports two cluster models: active/active (two-node clusters only) and active/passive (two- to eight-node clusters). A node is considered active if it hosts an EVS and passive if it doesn't host an EVS. Active/active clusters were first introduced in Exchange 2000 Server, and for backward-compatibility reasons, Microsoft continues to support them in Exchange 2003. Because of scalability limitations of active/active clusters, Microsoft's recommended cluster model for Exchange 2003 and Exchange 2000 is active/passive.
Although active/active clusters appear to be an attractive proposition (no servers are sitting idle waiting for a failover to occur), they have limitations. Early deployments of active/active clustering on Exchange 2000 had virtual memory problems, which led Microsoft to state that the maximum number of concurrent Outlook client connections that a node could support under Exchange 2000 release to manufacturing (RTM) was 1000. Microsoft made some improvements to Exchange 2000 SP1 and SP2 that allowed an active/active cluster to support more connections (1500 for SP1; 1900 for SP2). The 1900 limit in Exchange 2000 SP2 still applies to clusters running Exchange 2000 SP3, Exchange 2003 RTM, or Exchange 2003 SP1. Virtual memory fragmentation is less of an issue on active/passive clusters because an EVS can always be started on a passive cluster node (there's no active EVS on the passive node, so virtual memory fragmentation isn't an issue).
Additionally, active/passive clusters don't have the same constraints on the numbers of supported connections as active/active clusters. As I mentioned, Exchange 2003 SP1 supports a maximum of 1900 concurrent connections per node in an active/active configuration. A connection in this context means an active Outlook, Microsoft Outlook Web Access (OWA), or Outlook Express client connection and shouldn't be confused with the number of mailboxes residing on an Exchange server. Because of scalability limitations of active/active clusters, Microsoft's recommended cluster model for Exchange 2003 and Exchange 2000 is active/passive. With an active/passive cluster, the 1900-connections limit doesn't apply. In Exchange 2003, Microsoft has built functionality into Exchange System Manager (ESM) that enforces active/passive clustering guidelines on clusters that have more than two nodes. (You can find more information about these guidelines at http://support.microsoft.com/?kbid=329208.) You can create n − 1 EVSs, where n represents the number of nodes in the cluster. ESM prevents you from creating EVSs that equal or exceed the number of nodes in the cluster.
Preparing Your Cluster for the Exchange Installation
Planning is an essential ingredient in a successful Exchange 2003 cluster deployment. It involves considerations such as training, choosing a cluster model, choosing hardware and storage, and setting permissions. In the Web-exclusive sidebar "Planning Your Exchange Cluster Deployment," http://www/windowsitpro.com, InstantDoc ID 46687, I discuss Exchange cluster-planning considerations in detail.
After you've planned the Exchange cluster and created the Windows 2003 cluster, you're almost ready to begin installing Exchange 2003 on it. But before you install Exchange, you need to perform some additional tasks and checks to avoid problems during the installation.
Install layered products that Exchange requires. Exchange requires several Windows components, which you install via the Add or Remove Programs applet. You need to install these components on both cluster nodes. To install the components, in Add or Remove Programs click Add/Remove Windows components, check Application Server, click Details, and check ASP.NET and Internet Information Services (IIS). Click Details, then check Common Files, NNTP Service, SMTP Service, and World Web Service. Click OK to close each box and install the components.
Install Windows 2003 SP1 and the latest security patches. It's a good time to install the latest patches to your cluster since no mailboxes or users are connected to it.
Verify the network connection configurations on each cluster node. Each node has two network connections: a public connection to the LAN, which Outlook clients use to access the EVS and administrators use to remotely manage the cluster, and a heartbeat connection, which the cluster service uses to detect whether a cluster node is online or offline. (The public network can also be used for heartbeat communication.) Occasionally, Windows clusters can be built with the cluster heartbeat set at a higher priority in the binding order (i.e., the order in which they're accessed by network services) than the public-facing LAN.
Modify the binding order so that the public-facing connection is highest, followed by the heartbeat, as Figure 1 shows. To check the binding order, in Control Panel, go to Network Connections, Advanced, Advanced Settings, and select the Adapters and Bindings tab. Standardize the binding order on each node. Follow the steps described at http://support.microsoft.com/?kbid=258750 to remove NetBIOS from the heartbeat connections, set the appropriate cluster communication priority, and define the correct NIC speed and duplex mode on the heartbeat connection.
Create cluster groups and the Microsoft Distributed Transaction Coordinator (MS DTC) resource. Before installing Exchange, you need to create the required cluster groups and resources. By default, the cluster installation program creates an initial configuration that includes a cluster resource group containing the cluster IP address resource, a cluster network name, and a quorum disk resource (the quorum drive is usually assigned drive letter Q). This group is commonly known as the cluster group. The cluster installation program also creates a cluster resource group for each disk resource (called Group 0, Group 1, and so on). Figure 2 shows my initial cluster configuration for DARA-CL1.
Exchange 2003 requires MS DTC to be configured as a cluster resource. MS DTC is a service based on the OLE transactions-interface protocol, which provides an object-oriented (OO) interface for initiating and controlling transactions. The Microsoft article at http://www.support.microsoft.com/?kbid=301600 describes the procedure for configuring MS DTC in a cluster environment and recommends placing MS DTC in a separate cluster resource group with its own disk, IP address, and network name resources. In my opinion, the advice in this article is appropriate for applications such as Microsoft SQL Server that make heavy use of MS DTC. Exchange, on the other hand, makes very light use of MS DTC and unless you've deployed some workflow applications that use MS DTC, you can actually take MS DTC offline without affecting Exchange. (See also some sound advice about this matter posted by Evan Dodds at http://blogs.technet.com/exchange/archive/category/3896.aspx.) Therefore, I recommend placing the MS DTC resource in the cluster group (along with the cluster network name, IP address, and quorum disk resources).
You should also create each EVS in a separate cluster resource group (i.e., an Exchange cluster group). To create a group, in Cluster Administrator click New, then click Resource Group. For my EVS, DARA-EVS1, I called my resource group DARA-EVS1-GRP to reflect the EVS's name. The New Resource wizard then prompts you for the possible owners (nodes) of this resource group. For a two-node cluster, add the two nodes as possible owners, as Figure 3 shows.
Next, move disk resources created by the cluster installation program to the new Exchange resource group. To move a resource, right-click the disk resource and select Move Group. Choose the Exchange resource group (here, DARA-EVS1-GRP). Repeat this procedure for each resource group created by the cluster installation program.
You can delete the disk resource groups you changed in the last step (e.g., Group 0, Group 1, Group 2) because they're now empty. To delete a resource group, in Cluster Administrator, right-click the resource group and click Delete. You should now have a similar cluster group configuration (two resource groups: a cluster group and a resource group for Exchange) similar to the one that Figure 4 shows.
At this point, you need to create the resources in the Exchange cluster group that each EVS requires, such as an IP address, a network name, and disk resources. Create the IP address resource in your Exchange cluster group. To create the IP address resource for the EVS, in Cluster Administrator, click File, New Resource, which displays the dialog box that Figure 5 shows. Select IP Address for the resource type and make sure you select the Exchange resource group (not the cluster group) as the group for the new IP address resource.
After you click Next, the wizard prompts you to select nodes that can own this resource and to accept that both nodes can be owners. Next, the wizard asks you to select resource dependencies for the IP address resource. You don't need to set any resource dependencies, so click Next. The wizard then asks you to supply an IP address and subnet mask and choose a network for the IP address. Make sure you choose Public Network because clients will use this network connection to connect to the EVS. The heartbeat network is for internal cluster communications only. Click Next, and you should see the message Cluster Resource created successfully. Bring the IP address resource online by right-clicking it and clicking Bring Online.
The procedure for creating the EVS network name resource is similar to that for creating the EVS IP address resource. As before, in Cluster Administrator, click File, New Resource, and select Network Name from the resource list. Make sure you select the Exchange resource group as the group. Select the Network Name resource, enter its name, and click Next. The wizard prompts you to accept that both nodes should be owners of this resource. Click Next. Next, you're asked to specify dependencies for the Network Name resource. This resource has a dependency on the IP address resource because the IP address resource must be online before the Network Name can come online. Choose the IP address resource you created in the previous step and click Next. The wizard now prompts you to specify the EVS name. At this point, you can also specify whether the EVS name should be authenticated against AD by using Kerberos authentication and whether it should be registered with a DNS server. Enable these settings, as Figure 6 shows, and click Next. You should see a message stating that the Network Name resource was created successfully. At creation time, the Network Name will be offline. Bring the resource online by right-clicking it and clicking Bring Online.
Ready for the Next Step
The cluster is now ready for Exchange 2003 to be installed. However, before you reach for the Exchange CD-ROM, I recommend that you perform some testing on the cluster to verify that everything is configured correctly. Microsoft provides a free tool for testing and verifying a cluster configuration, called the Cluster Diagnostics and Verification Tool (ClusDiag.exe). You can download the tool at http://www.microsoft.com/downloads/details.aspx?familyid=b898f587-88c3-4602-84de-b9bc63f02825&displaylang=en. Stay tuned for part 2, when I'll tell you how to install Exchange on your newly created cluster.