Increased Complexity
Many systems administrators and managers are initially intimidated by the thought of managing clustered Exchange Server deployments. Microsoft has gone to great lengths to make the administration of clustered Exchange Server machines similar to that of standalone servers. (Figure 2 shows ESM's view of a four-node cluster; the view is similar to ESM's view of a standalone server.) Exchange 2000's dependence on AD simplifies this task and makes necessary administration fairly intuitive. Adding and deleting users, managing storage, and other administrative tasks are no different in a clustered environment than in a nonclustered environment. Permissions and administrative rights are also the same for clustered and nonclustered Exchange 2000 organizations. However, despite the similarities, several aspects of clustering Exchange 2000 can add to the system's administration challenge.
Resource administration. The primary resource-management differences involve Exchange Server services. Cluster resources administration has a somewhat steeper learning curve than does noncluster service and resource administration, but mastering this skill is key to successfully managing clustered applications. Before you deploy Exchange 2000 clusters, ensure that your operations and systems management staff understands the idiosyncrasies of Win2K clusters and services and how Exchange 2000 runs on top of this platform.
Load planning. Another management challenge is cluster load planning. Three basic load-planning strategies exist. I call these strategies Maximum Load-All Nodes, Maximum Load-Standby Node (i.e., N+1 failover), and Balanced Cluster Loading (of which there are two variants: cascading and distributed failover). Limitations in the number of SGs supported per node will somewhat alleviate the problem by limiting the matrix of possibilities. Which strategy you select will depend on several factors. You might select the Standby Node strategy if you simply want a failover node for any downtime. You might select the Balanced Cluster Loading scenario—the cascading variant can tolerate multiple node failures—if you're protecting your EVSs from multiple node failures. Cost constraints, performance considerations, storage design, and management factors can also affect your choice. Each strategy has strengths and weaknesses, so take the time to understand and test each strategy to determine which one best suits your environment. The clustering section of the Exchange 2000 documentation discusses these load-planning strategies.
Backup and restore. A solid and consistent backup-and-restore strategy should be an integral part of your Exchange 2000 deployment. In a cluster environment, you must address additional configuration considerations when you choose the method for your high-availability requirements. Most of these considerations result from non-cluster-aware tape-backup software and relate to performing scheduled backups during regular cluster operation as well as during failover. Because online backup and restore is the recommended method for Exchange Server (the backup software communicates with the IS through an API), disaster-recovery scenarios for Exchange Server clusters can be more complex than for standalone Exchange Server machines. Whether the server is local or remote to the backup device and backup software will add different complexities to clustered Exchange Server environments. You need to study clustering's effect on your backup-and-restore solution; you might need to develop specific policies and procedures for your clustered Exchange Server machines because you must plan for not only OS and Exchange Server information recovery but cluster recovery as well. To determine the best disaster-recovery scenario for Exchange Server running on Cluster service, consult with your backup software and hardware vendors regarding backup-and-restore support for Cluster service and Exchange 2000.
Clustering tends to become more complicated in direct proportion to the number of cluster nodes. Managing, allocating shared storage for, and planning failover for four-node clusters will be the most challenging scenario but will also offer the highest Return on Investment (ROI). You can cope with this challenge by gaining a thorough understanding of Win2K clustering and by planning and testing your Exchange 2000 cluster before putting it into use.
Best Practices
Most organizations are still in the midst of deploying Exchange 2000 and have yet to discover or fine-tune many best practices or rules of thumb. Testing Exchange 2000 clustering at Compaq and working with customers over the past year, I've learned many things about deploying Exchange 2000 clusters. To help make your deployment smoother, I leave you with some of the important lessons I've learned.
Delegate proper permissions. Use care when configuring Exchange Admin accounts and privileges as well as Cluster services accounts (which must have Exchange Full Admin rights). Creating and managing an EVS require Exchange Full Admin account privileges. You can use the Exchange Delegation Wizard to grant these rights.
Use standardized and simplified IP addressing and naming. In a clustered scenario, the cluster nodes and the services they host require IP addresses and unique names. Cluster service requires static IP addresses for the cluster, nodes, and services. (In other words, you can't use DHCP to assign IP addresses.) In addition, each EVS requires a unique IP address. You must preallocate IP addresses to all nodes and services (i.e., EVSs) before you set up and install Exchange 2000. Structure these addresses to permit simplified configuration and management of nodes and services. Likewise, name nodes and EVSs to permit simplified configuration and management. Table 1 shows a good IP addressing and naming strategy for a four-node Exchange 2000 cluster. Note that the IP addresses for the node name and EVS name are closely related.
Configure resource ownership and failover. When you configure EVSs, Cluster Administrator will automatically configure any Exchange 2000 cluster node as a Possible Owner for each resource. However, if you create resources before a node has joined the cluster or before you've installed Exchange 2000 on the node, the EVS's resource properties won't list that node as a Possible Owner. In this situation, you must manually configure the resource properties to permit the resources to fail over to that node. Be careful when you configure hardware (i.e., Disk and Network), addressing (i.e., IP and Network Name), and Exchange Server (i.e., System Attendant) resources to ensure that Cluster Administrator includes all these resources as Possible Owners. In addition, when you configure failover and failback scenarios, you must list all nodes (in the order required to manage failover operations according to the failover scenarios and load strategy you've selected) in each resource group's Properties, Cluster Administrator Preferred Owners dialog box. Doing so will ensure proper failover and failback operations.
Take care when removing EVSs and binaries from a cluster. When you remove Exchange Server from a cluster, be careful not to interfere with other nodes' operations. When removing an EVS, take the cluster group offline first. Next, delete the Exchange Server resources. When you remove the System Attendant resource, Cluster Administrator will remove all other resources (according to resource dependency). After AD has been automatically updated with the configuration change, the EVS will no longer be visible in ESM. Finally, to remove the Exchange binary files from the cluster node, you must run the Exchange 2000 setup program and select the Remove option. The program will prompt you to choose whether to remove the Exchange Server cluster resources; remove these resources only when the node that you're removing is the last cluster node running Exchange Server services.
Design storage before you configure the cluster. Because of Exchange 2000's support for active/active clustering and multiple SGs and databases, storage design can be complex. Consider all aspects before you configure your cluster. In a cluster, Exchange 2000 SGs are a subset of an EVS, so each SG must fail over with the EVS. This requirement affects storage design. If you choose—based on performance considerations—to allocate separate physical storage arrays for transaction log files and database files, each SG will have a minimum of two arrays (one for logs and one for databases) that must provide the necessary independence and granularity to facilitate failover. You must carefully consider the implications of granularity, failover, and EVS-to-SG mapping. Also consider that Exchange 2000 limits the number of SGs to four per node, both before and after failover. Failure to follow this restriction might result in EVS problems or failures. The best recommendation is to start with SLAs in mind and design storage to meet those service levels.
New Opportunities and Challenges
Exchange 2000 offers greatly improved clustering capabilities, making clustering a viable option for significantly increasing availability and facilitating server consolidation. Although the new capabilities are worth investigating, they also create additional complexity. As part of your deployment planning, you need to evaluate clustering along with other new Exchange 2000 capabilities. By starting with a solid understanding of how Win2K implements and Exchange 2000 leverages Cluster service, you'll have a foundation on which to build a successful Exchange 2000 cluster.