Planning Your Exchange Cluster Deployment
Careful planning is the key to a successful Exchange Server 2003 cluster deployment. When developing your cluster-implementation plan, you should consider areas such as training; choosing the right cluster model, hardware, and storage; preparing the Windows and Exchange infrastructures; and permissions.
Training for Cluster Administrators
Cluster hardware configurations are more complex than single-server deployments, and cluster deployments often fail because IT employees aren't adequately prepared. Training should familiarize administrators with cluster concepts such as the quorum, failover and failback operations, and using the Cluster Administrator tool. Microsoft Virtual Server 2005, Enterprise Edition, which lets you create virtual clusters, provides an ideal way for cluster novices to play around with clusters without having to deploy additional cluster hardware for training purposes.
Choosing the Right Cluster Model
Active/passive is the preferred cluster model because it lets you deploy Exchange clusters that can support many users. However, you should understand some of the limitations that govern failovers on active/passive clusters that have more than two nodes. On such clusters, only one Exchange Virtual Server (EVS) can be hosted on a node at a time. Any attempt to move a second EVS to a node currently hosting an EVS will fail. (This failover constraint is described at http://support.microsoft.com/?kbid=329208.) If you attempt to move an EVS to a node that already hosts an EVS, you'll get the error message An error occurred attempting to bring the System Attendant resource online: The cluster resource could not be brought online by the resource monitor. Error ID: 5018 (0000139a). These limitations exist to enforce active/passive failovers on clusters with more than two nodes.
Active/passive clusters can be deployed in many different combinations (e.g., an eight-node cluster with four active and four passive nodes; a seven-node cluster with four active and three passive nodes). If this is your first cluster deployment, I recommend keeping it simple and using a two-node active/passive cluster. If you deploy it successfully, you can look at deploying larger clusters.
Choosing the Right Hardware for Cluster Nodes
The goal of your cluster deployment is to provide high availability. In the event of a hardware failure, a failover operation moves resources from the failed node to another cluster node. During failovers, users might experience timeouts for a short time as resources are taken offline on the failed node and brought online on the other node. For each cluster node, you should implement redundant hardware components—such as redundant NICs, power supplies, connections to shared storage (host bus adapters—HBAs, array controllers), power supplies, and fans—to reduce the impact of a hardware failure and thus avoid a failover. Connect redundant power supplies to separate power distribution units to ensure power if a unit fails. Many hardware vendors offer "packaged" clustering solutions that take the guesswork out of building a cluster hardware specification. A packaged cluster typically includes two nodes, a built-in heartbeat network between the nodes and a SAN. An example of a packaged cluster is the HP ProLiant DL380 Packaged Cluster with MSA1000. Whether you choose a packaged cluster solution or choose to build your own cluster configuration, you must use hardware that's listed on the Windows Server Catalog site (http://www.microsoft.com/windows/catalog/server/default.aspx?subid=22&xslt=hardwarehome). Microsoft doesn't support configurations that include hardware not in the catalog.
Choosing the Right Storage
Choosing the right shared-storage infrastructure is a critical part of the planning process. Exchange databases expand over time, and you might start to run out of disk space if you haven't provided capacity. Having spare capacity is also useful for performing database maintenance and disaster recovery exercises. Adding disk space to a cluster might require future downtime if your storage infrastructure doesn't support dynamic volume expansion. Estimating your storage requirements depends on many factors, such as the number of mailboxes you plan to host on each EVS and the standard mailbox size limit you'll implement. HP provides a downloadable storage-sizing calculator at http://h71019.www7.hp.com/activeanswers/cache/71108-0-0-0-121.html.
Preparing the Windows Infrastructure
You should verify that your configuration meets the requirements for deploying an Exchange 2003 cluster. The first requirement is to have the necessary IP addresses for the cluster. For a two-node cluster that has one EVS, you'll need one IP address for each node, one IP address for the cluster, and one IP address for the EVS.
The next requirement is to make sure that all Global Catalog (GC) servers or domain controllers (DCs) in the same Windows site as the EVS run Windows 2003 or Windows 2000 SP3 or later. Exchange 2003 stores configuration information in the Active Directory (AD) DCs and GC. DCs hold a complete copy of all objects belonging to a domain plus a copy of objects replicated in the forestwide configuration naming context (NC). GCs hold a complete copy of all objects in their own domain plus partial attributes of objects from all other domains within the forest. I recommend you deploy at least two GCs in the same AD site as your EVS for redundancy. If a GC goes offline, Exchange can bind to the other GC in the site.
The third requirement is to create a cluster service account, which the Microsoft Cluster service uses to log on at boot time and form or join a cluster. The cluster service account has logon as service rights on each node and requires membership in the local Administrators group on each node. I recommend that you don't use the default Administrator account as the cluster service account. If the administrator account is disabled, it might cause the cluster service to fail. I also recommend creating one service account per cluster and linking the username to the cluster name. For example, for the DARA-CL1 cluster, the service account could be SVC-DARACL1. Creating one account per cluster reduces the impact of the account being locked out or accidentally disabled. If you have 10 clusters all using the same cluster service account, this cluster account service account becomes a potentially large single point of failure (a lockout event on that account will cause all clusters to fail). Finally, to reduce the risk of the service account being disabled, don't use the service account to log on to a cluster. Instead, create a separate security group for cluster administrators. Add the users who manage clusters to this security group, and add this security group to the local Administrators group on each cluster.
Finally, you'll need to create a Computer account in AD using the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in for each EVS. I suggest that you create and properly secure this account in advance. If you're running your cluster in a security-hardened environment, consult “How to Run Exchange Server 2003 Clusters in a Security-Hardened Environment” at http://www.microsoft.com/technet/prodtechnol/exchange/guides/howtorune2k3clusters/c6e8057e-b4f8-4d3f-b488-b27ab3a0255d.mspx, which describes how you can create a special organizational unit (OU) in AD to hold the computer accounts belonging to EVS, how to grant the OU permissions to the Cluster Service account, and how to apply the Exchange Security templates provided by Microsoft as part of the "Exchange Server 2003 Security Hardening Guide." (You can download the guide at http://www.microsoft.com/downloads/details.aspx?familyid=6a80711f-e5c9-4aef-9a44-504db09b9065&displaylang=en.)
Preparing the Exchange Infrastructure
A number of Exchange components aren't supported or can't be installed on an Exchange cluster, so you might have to deploy additional Exchange servers before deploying the cluster. For example, Site Replication Service (SRS), which replicates configuration between AD and the Exchange Server 5.5 Directory Service (DS), doesn't run on an Exchange cluster. Thus, if you plan to implement your cluster in an existing Exchange 5.5 site, you must deploy a standalone Exchange 2003 server in the site to meet the requirements for your migration. You can find a list of Exchange components and whether or not they're supported in a cluster at http://support.microsoft.com/?kbid=259197.
Setting Permissions
Microsoft built many security enhancements into Exchange 2003, and a number of these improvements are cluster-specific. In Exchange 2000 Server, the cluster service account required Exchange Full Administrator rights at the Administrative Group level to create an EVS. With Exchange 2003, the cluster service account doesn't require any Exchange-specific permissions delegated to the Administrative Group. To install an EVS, the account you use to perform the installation must be delegated Exchange Full Administrator rights at the Administrative Group level (or be a member of a security group that's been delegated Exchange Full Administrator rights). If the EVS is the first EVS to be installed in your Exchange organization, the account you use to perform the installation also requires Exchange Full Administrator rights at the Organization level. (For more information and best practices for setting Exchange permissions, see the document Working with Active Directory Permissions in Microsoft Exchange 2003 at http://www.microsoft.com/downloads/details.aspx?familyid=0954b157-5add-48b8-9657-b95ac5bfe0a2&displaylang=en.)
