Clustering your Exchange Server 2003 or Exchange 2000 Server systems can provide the high availability that's so important for a business-critical email application. If you're considering clustering Exchange, you can take several steps to improve your deployment, such as getting cluster-specific training, planning ahead, building extra redundancy into the cluster, and deploying a solid Windows infrastructure before building the cluster. (This article requires knowledge of clustering concepts. For clustering basics, see "Clustering in Exchange 2000," November 15, 2001, http://winnetmag.com, InstantDoc ID 22772, and the Microsoft article "Deploying Microsoft Exchange 2000 Server Clusters" at http://www.microsoft.com/downloads/details.aspx?familyid=824a63a2-f722-4bff-a223-e71b856f83c4. For a comparison of Exchange 2003 and Exchange 2000 clusters, see "Exchange Server 2003 Clusters," November 2003, InstantDoc ID 40457.)
1. Training
Clusters are more complex than single-server Exchange deployments, so you need training that focuses on clustering concepts and operations such as the quorum, failover/failback operations, and using Cluster Administrator. You also need to understand the requirements of clustering-hardware configurations. For example, shared storage must be accessible to all nodes, so you must correctly configure any hardware that manages storage connections (e.g., array controllers, Storage Area Network—SAN—switches) to avoid contention or corruption of databases. Attention to detail is necessary to ensure that you correctly install Windows before installing Exchange and that you install and configure Exchange in the correct sequence to work on a cluster—a process that differs significantly from installing Exchange on one server. For example, to install a two-node, active/passive cluster, you need to perform the following tasks in sequence:
- Run Exchange Setup on node 1.
- Run Exchange Setup on node 2.
- Create a cluster group for the Exchange Virtual Server (EVS).
- Move disk resources that the EVS will use to the Exchange cluster group.
- Create the resources that the EVS requires (e.g., Microsoft Distributed Transaction Coordinator—MSDTC—an IP Address resource, a Network Name resource).
- Create a System Attendant resource for the EVS. As part of this step, you must supply the name of the EVS, the administrative group and routing group in which the EVS will reside, and a shared-storage folder in which Exchange will create and store its databases, transaction logs, and SMTP folders at installation.
- Cluster Administrator automatically creates Exchange cluster resources for the EVS (e.g., the Information Store—IS; HTTP and IMAP servers for the virtual server; the required dependencies for the IP Address and Network Name resources).
- Use Exchange System Manager (ESM) to relocate the Exchange components (i.e., databases, transaction logs, and SMTP folders) to shared-storage drives or folders, according to established best practices (see "Customizing Your Exchange 2000 Server Installation," June 2002, http://www.winnetmag.com/microsoftexchangeoutlook, InstantDoc ID 24774, for suggestions). Exchange needs to be able to access these resources from each node as the EVS fails over.
You need to have a firm grasp of Microsoft Cluster service clustering concepts (see the Microsoft white paper "Windows Clustering Technologies—An Overview" at http://www.microsoft.com/windows2000/techinfo/planning/clustering.asp for more information about these concepts). You also need to understand the limitations and constraints of running Exchange 2003 or Exchange 2000 on a cluster. For example, the Lotus Notes connector is unsupported on Exchange 2003 or Exchange 2000 clusters, as the Microsoft article "Status of Exchange 2000 Server and Exchange Server 2003 Components on a Server Cluster" (http://support.microsoft.com/?kbid=259197) explains. You must deploy additional standard servers to support any components that aren't supported on clusters. Be aware that many third-party products fall into this category, and I definitely recommend against installing unsupported products on a cluster, given the complexity of clustering.
As important as training is, deploying production-quality test clusters that match the specifications of your production clusters can be prohibitively expensive because of the additional hardware necessary (compared with single-server deployments). Therefore, getting the necessary experience on a cluster before deployment is often difficult. To deploy low-cost clusters as training aids, consider using virtual server technology such as VMware or Microsoft Virtual Server. Windows Server 2003 introduces the concept of a local quorum, which lets you deploy single-node clusters. However, you can't test failover and failback operations or rolling upgrades on this type of cluster.
2. Planning
Plan your cluster deployment carefully. A poorly implemented cluster can perform erratically and can increase downtime rather than maximize uptime. When planning, consider hardware specifications, node configuration, and the limitations of Exchange clustering memory management.
Hardware specifications. All the hardware components you use in a Windows 2000 cluster (e.g., disk drives, array controllers) must appear on the Microsoft Hardware Compatibility List (HCL—http://www.microsoft.com/whdc/hcl/default.mspx). For Windows 2003 clusters, consult the Windows Catalog (http://www.microsoft.com/windows/catalog/server), which replaces the HCL. If you implement hardware that isn't on the HCL or in the Windows Catalog, Microsoft won't support your configuration. The HCL lets you view devices by category, as Figure 1 shows; the Windows Catalog does the same.