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. . . .
Register
