The history of Microsoft Exchange Server clusters is one of peaks and valleys, with cycles of enthusiasm generated by new releases followed by depression as the releases don't work out so well in practice. Exchange Server 5.5 first supported Windows clusters, but the clusters were expensive to deploy and were limited to two nodes configured in an active-passive cluster. Exchange 2000 Server promised clusters spanning as many as four active nodes. However, Microsoft has been forced to rescind that promise and now requires you to maintain a passive node because of memory-fragmentation problems. In addition, you can deploy four-node Exchange 2000 clusters on only Windows 2000 Datacenter Server, so the solution is expensive. The net result is that clusters represent a small percentage of the hundreds of thousands of Exchange servers deployed today. No one is willing to say exactly how many clusters are in production, but anecdotal evidence suggests that fewer than 2 percent of all the deployed Exchange servers are in clusters.
On the surface, clusters seem to be an extremely effective way to achieve high degrees of robustness and reliability. Indeed, UNIX and OpenVMS administrators have been deploying clusters for these reasons for years. So, why haven't Windows administrators been deploying Exchange 2000 and Exchange 5.5 clusters? The reasons why include added complexity, Exchange components that can't run on clusters, the lack of third-party product availability, memory fragmentation, and high costs.
For clusters to work well, the email application and the OS must join forces. So far, Microsoft hasn't been able to make those two entities work together seamlessly. Microsoft promises better clusters with Windows Server 2003 and Exchange Server 2003, but will the company keep that promise? To answer this question, you need to know how clusters work, how Exchange in general operates in a cluster, how Exchange 2000 specifically operates in a cluster, and what improvements Exchange 2003 offers.
Understanding Clusters and How Exchange Operates in Them
The process of setting up and configuring hardware and software for clusters is more complex than that for standard servers. Clusters typically boast multiple NICs. You need at least one NIC for the public network and one NIC for the cluster "heartbeat," which is the network signal between nodes that lets the nodes know that the cluster is alive and well. Clusters use shared storage instead of direct-connected drives because services depend on being able to move data between nodes when problems occur—and the services can't move the data if the data is restricted to a specific server.
Managing clusters differs from managing standard servers. Instead of controlling the set of services for Exchange or other applications through the Computer Management console, you manage them through the Cluster Administrator console, which Figure 1, page 52, shows. In this example, Cluster Administrator shows a set of Exchange services running on a cluster. The console shows the additional resources that combine to form an Exchange virtual server, such as the disks, IP address, and network name.
The concept of virtual servers is crucial to clusters. Exchange runs on a cluster as one or more virtual servers. Each virtual server represents the set of resources (e.g., disks, a network name, the Store) that Exchange needs to provide services to users. Exchange virtual servers run on physical nodes within the cluster. The virtual servers manage the data in mailbox and public stores, which are gathered into storage groups (SGs). An SG is the basic unit of storage for Exchange clusters. If a physical node fails and the cluster has to move work within the cluster, the cluster distributes the SGs from the failed server to other nodes rather than moves individual stores. After the failover, the SGs come under the control of the Exchange virtual server running on that physical node.
After you understand the basic concepts of clusters and how Exchange operates in clusters, you have to face the fact that not all Exchange components can run on a cluster. The reason why is simple. In some cases, the Exchange component is old and wasn't designed to run on anything other than a standard server. Because the component is old and perhaps not needed by the majority of Exchange installations, Microsoft never upgraded the component to support clusters. In other cases, the component is used only in specific circumstances (e.g., for interoperability between Exchange 2000 and Exchange 5.5 servers), so that component doesn't need to support clusters in the long term. Table 1 lists the optional Exchange components and the degree of cluster support for those components.
In the past, some Independent Software Vendors (ISVs) didn't support clusters because these vendors preferred to concentrate on the largest market: support software for standard Exchange servers. The lack of add-on software for clustered Exchange servers caused a problem if organizations wanted to deploy the same antivirus, antispam, and backup software and messaging connectors across both standard and clustered servers. Fortunately, this situation has improved tremendously since Exchange 2000 first appeared, and you now have a reasonable choice of add-ons for clustered servers.
Prev. page
[1]
2
3
4
next page 
