As you can see, these improvements address many of the reasons why Windows administrators haven't implemented clusters. Some of the other reasons why administrators haven't considered clusters are going away on their own. For example, as organizations complete their Exchange 2000 deployments or finish migrating from a legacy email system, they no longer need some of the older Exchange components that can't run on a cluster. Even some of the newer components introduced in Exchange 2000 that couldn't run in a cluster have been replaced by new products that can run in a cluster. All the core Exchange 2003 components can run in a cluster. Thus, problems with noncluster compliance are now likely to be found in only third-party products. And even that problem is going away because, as I mentioned previously, an increasing number of ISVs are offering add-ons for clustered servers.
The Microsoft Experience
Surprisingly, Microsoft never used clusters in its Exchange deployment in the past, but that situation changed dramatically with the arrival of Exchange 2003 and Microsoft's server consolidation program. Microsoft has replaced its old set of standard Exchange servers with a new set of large clusters. The most interesting configuration is the data-center design, which supports 16,000 mailboxes spread across four Exchange virtual servers. The cluster consists of seven physical nodes, four of which handle the load that the four mailbox servers generate. Another server is passive, waiting to spring into action should one of the mailbox servers fail. The mailbox servers (and the passive node) boast substantial power: They're HP ProLiant DL580G2 models with quad 1.9GHz Intel Xeon III processors, 4GB of memory, and a 400MHz front-side bus. Microsoft has enabled hyperthreading on these servers and reports that this feature provides an increase of about 20 percent of CPU headroom. Microsoft follows its own advice and tunes the servers by setting the /3GB switch and setting the /Userva= switch to 3030 (this value is in megabytes) in the boot.ini file.
The two remaining servers—each of which is an HP ProLiant DL380G2 model with two CPUs and 2GB of RAM—handle backup and other administrative functions. Because they're auxiliary servers and don't host Exchange, these servers have lower-specification configurations.
Microsoft's standard mailbox quota went from 100MB to 200MB, although considerable variation exists in actual quotas based on business demand. Not surprisingly, Microsoft has a lot of mailbox data to back up daily. The best backup solutions can stream data to tape as fast as 100GB per hour, but this rate isn't satisfactory for a 16,000-mailbox cluster. For a cluster this size, you want the mailbox servers delivering the best possible response to users and not handling the load that tape backups generate. Microsoft's operations team solved the backup problem by first backing up the disks to volumes that are temporarily available to the mailbox servers. After the disk backups are finished, the volumes are failed over to the auxiliary nodes and moved to the control of the two auxiliary servers, which copy the backup to tape. Moving disks between servers in this fashion demonstrates how to use cluster features to solve administrative problems. In the future, Microsoft plans to deploy VSS-enabled hot snapshot backups in addition to hot snapshot backups. (Hot snapshot backups are designed to complement, not replace, tape backups.)
An HP StorageWorks Enterprise Virtual Array 5000 (EVA5000) Storage Area Network (SAN) manages all the storage. This SAN is an important contributor to Microsoft's large cluster because of its redundancy and management features. Because SGs, transaction logs, and SMTP work directories all require drives, Microsoft's large cluster has numerous drives. Microsoft heavily uses mount points to get around the drive-letter limitation that would otherwise render these drives almost impossible to configure in a satisfactory manner.
I haven't heard of similar clusters running in production, so Microsoft might take the blue ribbon for large Exchange clusters with this design. Microsoft reckons that it achieves a better service level with the cluster than it achieved with standard servers. The company says it reached the "four nines" territory (i.e., 99.99 percent availability). However, this feat hasn't been independently audited because Microsoft deployed the cluster with beta versions of Exchange 2003, then continually upgraded the software until the final release. Getting anywhere close to such an uptime record would be remarkable.
Don't Be a Fool
Only fools rush in and deploy clusters. Administrators who plunge into cluster deployment without investing the necessary time to research, plan for, and design clusters generally encounter problems. Exchange 2003 clusters are more complex than standard Exchange servers, and experience demonstrates that you must carefully set up and manage Exchange 2003 clusters to generate the desired levels of uptime and resilience. Only those administrators who take the time up front to properly design clusters and successfully manage those clusters will likely achieve their desired results.
The improvements in Exchange 2003 and Windows 2003 are helping make Exchange clusters a viable option. The early reports of successful deployments of Exchange 2003 clusters, including Microsoft's deployment, are encouraging. The challenge for Microsoft now is to continue driving complexity out of clusters so that installing and managing clusters is as easy as installing and managing standard servers. That day is not yet here.
Still, I remain positive about clusters. Clusters do a fine job, provided that administrators carefully plan cluster configurations and then appropriately manage the clusters. However, the road to clusters has been bumpy, and Microsoft didn't keep its promise about clusters in the past. Work is continuing to improve clusters, but in the interim, if you're interested in clustering Exchange servers, you need to consider all options before making a final decision.
Register
