8.6 Second-generation Exchange clusters

---

The release of Exchange 2000 promised a new beginning for Exchange clusters. Many factors had changed to improve matters, including a new version of the underlying cluster software provided by Windows, the partitioning of the Store into storage groups to allow greater granularity during transitions, support of four-way active-active clusters, and the experience of almost three years of real-life deployments. Unfortunately, some of the same hurdles to customer acceptance of clusters remain, including:

• Complexity

• Cost

• Lack of support for third-party products

The lack of support from third parties is entirely due to market acceptance of clusters. Because clusters remain strictly a minority interest within the general Exchange community, third-party developers focus their efforts on supporting mainstream standard servers. The result is that it is often difficult to find a version of an add-on product for Exchange that supports a clustered environment.

Soon after Exchange 2000 shipped, customers began to report problems with memory management on clusters. The problems appeared on active- active clusters and caused Exchange to freeze and be unable to service client requests. Administrators also reported similar problems on high-end standard Exchange 2000 servers that handle heavy workloads over extended periods. SharePoint Portal Server 2001, which uses a modified version of the Exchange database engine and Store, can also run into memory management problems under heavy load.

Microsoft has steadily improved the quality and robustness of Windows clusters and the applications that support clusters, including Exchange. However, even six years after Microsoft first shipped Exchange clusters, the two biggest problems that cause operating issues with Exchange clusters are still the overall complexity of the solution and operational management. Microsoft now says that all support above two nodes must be active/passive. In other words, you must always keep a passive node available to handle failovers. To those used to other cluster implementations (such as VMSclusters), the need to keep a passive node around is a condemnation of Microsoft clustering technology.

8.6.1 The complexity of clusters

Successful operation of Exchange clusters requires:

• Appropriate hardware

• Attention to detail

• Administrator knowledge of Windows, Exchange, and cluster services

• Cluster-aware operational procedures and third-party products

Cluster hardware should include high-quality servers with balanced configuration of CPU and memory to allow the servers to handle workload equally. A SAN is almost mandatory for anything but entry-level clusters, so you need to pay attention to controller configuration and resilience, basic disk technology (speed and placement), file layout across available volumes, and so on. Commissioning procedures differ across storage technologies, so be sure that you take the right approach for the chosen technology.

Clusters depend on a complex interaction between hardware, operating system, applications, and people. You need to pay attention to detail to ensure that you properly install and configure the cluster before you introduce any application into the equation. This is particularly important when you deal with a SAN, since technology differs greatly across SANs provided by different vendors-and almost every production-quality cluster uses a SAN.

Applications often follow a different installation procedure on clusters. It is not enough to assume that Windows and Exchange behave only slightly differently on a cluster-practice makes perfect! For example, in the case of Exchange, you must manage the basic services that make up the application through the cluster administration tool rather than performing actions such as stop and start services through the Services Manager utility or ESM. However, because clusters are expensive, it is often difficult for administrators to get the necessary experience on clusters before deploying the first production cluster. Few test environments incorporate a fully configured production-quality cluster, but it is perfectly possible to commission an entry-level cluster and use that for testing. Many companies use virtual systems to test clusters, which is an effective approach to solve the need.

Administrators must understand how Microsoft has implemented cluster services for Windows and then what modifications occur for applications to support cluster services. For example, you can only install Exchange on a cluster in a mixed-mode site if another Exchange 2000/2003 server is already present, because some of the services (such as SRS) required for mixed mode cannot run on a cluster. Administrators must understand the differences between standard servers and clusters and understand how to manage and troubleshoot both environments, including how to correctly back up and restore a cluster, as well as how to cope with various disaster recovery scenarios, such as a catastrophic hardware failure.

It is essential that you modify operational procedures developed for standard servers for clusters. The software used to monitor servers and applications may not support clusters and may require a change or replacement. Some third-party software may not be supported and may force you to change the operational procedures to accommodate a different package. In addition, clusters are sensitive to change, so you must carefully plan and test any upgrades and installations of new software before you make changes to production environments.

---