The release of Microsoft Exchange 2000 Server's first service pack, which Microsoft scheduled to release in June 2001, provides a more significant feature than just minor bug fixes. In Exchange 2000 Enterprise Server Service Pack 1 (SP1), Microsoft will deliver Windows 2000 Datacenter Server support for Exchange 2000. Last fall, Microsoft shipped Datacenter, which offers the promise of a total solution for data center deployment of Microsoft OSs and applications. The release of Datacenter support for Exchange 2000 raises two questions: How does Exchange 2000 leverage Datacenter, and will this ability really make a difference in your organization's mission-critical deployments?
What's in a Name?
When Microsoft shipped Win2K in December 1999, the company promised that it would later deliver a data center version of Win2K that would raise the bar for the OS. To do so, this data center version was to provide features and support that Microsoft intended to rival mainframe and UNIX environments.
Datacenter is the first Microsoft product that is available solely through OEMs. Vendors such as Compaq, Hewlett-Packard (HP), and Dell offer specific Datacenter product configurations that have been tested on a higher level of compatibility and reliability than the traditional Windows testing process. Each OEM's product must pass rigorous 14-day load and compatibility testing that pushes each hardware configuration to its limit.
Datacenter also offers improved support services. Microsoft requires each OEM to host a support team in which Microsoft and the OEM's engineers work together to provide support. This setup delivers an OS and hardware bundle that's closely tied to joint support programs between Microsoft and the OEM.
So how is Datacenter different from Win2K Server and Win2K Advanced Server? Datacenter's improved testing process and support are differentiating factors, but Datacenter also includes five key features that aren't available in the other Win2K server editions:
- Support for 32-way SMP systems—Win2K AS provides support for only 8-way SMP systems. Datacenter's support for 32 processors lets CPU-intensive applications scale well, and these applications will benefit tremendously from the additional CPU power.
- Support for as much as 64GB of physical memory—Through Datacenter's Physical Address Extension (PAE) architecture and the Address Windowing Extensions (AWE) API, applications can access as much as 64GB of RAM.
- Support for process control objects—Process control objects provide an API that lets developers permit operators and operation rules that are running the system to dynamically tune applications and services.
- Support for Winsock Direct—Winsock Direct is another new API available in Datacenter that lets applications leverage high-speed interconnects or System Area Networks (SANs) to facilitate interprocess communication or remote procedure calls (RPCs).
- Support for 4-node clustering—Four-node clustering is one of the most touted advantages of Datacenter over Win2K AS, which supports only 2-node clusters.
Microsoft designed each of these Datacenter features to let Win2K scale beyond its current limitations and enter the data center arena as a platform of choice.
Exchange 2000 on Datacenter
When deploying Exchange 2000 Enterprise Server on Datacenter, you must upgrade to Exchange 2000 Enterprise Server SP1 to garner full support from Microsoft. How well does Exchange 2000 Enterprise Server SP1 leverage each of Datacenter's key features?
Support for 32-way SMP. Microsoft and OEMs have tested Exchange 2000 Enterprise Server SP1, and it will run on a Datacenter-certified 32-way SMP system. (For more information about Datacenter certification, see Microsoft's Web site at http://www.microsoft.com/windows2000/upgrade/compat/certified.asp.) However, initial testing indicates that Exchange 2000 scales well only to a maximum of 8 processors on most implementations. By using process control objects and processor affinity to tune an implementation, some OEMs have been able to scale Exchange 2000 to as many as 12 processors. Therefore, SP1 doesn't help you take advantage of Datacenter's ability to scale to 32 CPUs because SP1 doesn't change Exchange 2000's inability to scale well past 8 CPUs.
OEMs plan to recommend hardware partitioning (another Datacenter feature) to their customers who want to scale Exchange 2000 to systems with more than eight processors. Based on Exchange 2000's constraints and Return on Investment (ROI), I recommend a scale-out rather than a scale-up strategy—one 32-processor system is more expensive than four 8-processor systems. The best way to achieve the lowest total cost of ownership (TCO) with Exchange 2000 is to deploy multiple 8-processor systems (i.e., scaling out) as opposed to fewer 32-processor systems (i.e., scaling up).
Support for as much as 64GB of RAM. Exchange 2000 Enterprise Server SP1 will run on PAE-enabled machines. However, Exchange 2000 doesn't make any calls to the AWE APIs to utilize virtual memory beyond a 4GB address space.
Duplicating Exchange 2000 behavior on Win2K AS, Exchange 2000 Enterprise Server SP1 on a Datacenter system can use the /3GB switch in boot.ini to allocate 3GB of RAM for Exchange application use and 1GB for the OS. (This feature was first available in Exchange Server 5.5 running on Windows NT 4.0, Enterprise Edition.) However, by default, Exchange 2000 won't use more than about 1GB unless you make registry setting changes because Exchange 2000's STORE database cache will allocate only 900MB—less than Exchange Server 5.5, which could allocate almost the entire 3GB for application use. I recommend using the /3GB PAE switch for all Exchange Server systems that have 1GB or more of RAM. This switch simply extends the application process address space to 3GB from Win2K's and NT's 2GB default setting. This switch also reduces the OS's address space to 1GB.
Be aware, however, that if you use the /3GB switch on PAE-enabled machines, all PAE- and AWE-enabled applications on the system are limited to the first 16GB of addressable physical memory, so they can't take advantage of the 64GB of RAM support. (This limitation doesn't affect Exchange but impacts any other PAE-enabled applications, such as Microsoft SQL Server, running on the Exchange 2000 server.)
Exchange 2000 would have required a major architectural rewrite to have been able to support a large memory space. Such a rewrite isn't likely to come until after the next Exchange 2000 release, when the application will have to include support for 64-bit OSs and applications.
Support for process control objects. Exchange 2000 Enterprise Server SP1 will pass requisite process control object tests and run on a process control objectenabled system. (These tests determine whether an application will run on a process control objectenabled machine, not whether the application uses process control objects.) Microsoft hasn't extensively tested Exchange 2000 with Datacenter's process control object features.
As I previously mentioned, some OEMs have used process control objects to achieve additional processor scalability, but this increased scalability isn't a result of Exchange 2000's capabilities. Rather, the increased scalability is a result of the ability to tinker with many parts of the OS that process control objects make possible. Exchange 2000 performance gains as a result of process control object support have been strictly manual and haven't resulted in major improvements to the application.
Support for Winsock Direct. Exchange 2000 Enterprise Server SP1 will run on Datacenter systems configured to use Winsock Direct. Although Exchange 2000 might benefit from Winsock Direct performance in SAN configurations, Microsoft has no current plans to perform benchmark testing. In addition, Exchange 2000 doesn't directly leverage the Winsock Direct API. A high-speed interface to accelerate remote process communication could benefit front- and back-end server communication with multi-tier Exchange 2000 configurations. However, Microsoft and Datacenter OEMs haven't conducted tests to determine whether Datacenter's support for Winsock Direct will produce performance gains in Exchange 2000 Enterprise Server SP1 on Datacenter.
Support for 4-node clustering. Exchange 2000 Enterprise Server SP1 will take advantage of 4-node, active/active clustering on Datacenter. (Thus, you must take into account several clustering configuration considerations during your cluster planning. For more information about these considerations, see "Clustering Exchange 2000, Part 1," December 2000 and "Clustering Exchange 2000, Part 2," January 2001.) Although Exchange 2000 Enterprise Server SP1 truly leverages Datacenter's 4-node clustering support, this support comes with caveats.
Exchange 2000 SP1 must overcome some hurdles before Datacenter clusters and OEM configurations can support it. First, Exchange 2000 hasn't received a Datacenter logo—a process that requires applications from Independent Software Vendors (ISVs), including Microsoft, to pass a battery of tests that a third-party company, VeriTest, conducts. This process should be complete for Exchange 2000 SP1 by the time this article goes to print.
Second, OEMs must pass the Win2K Datacenter Hardware Compatibility Test (HCT), the 4-node cluster HCT, and the application HCT. Any application that has kernel-mode components (Exchange 2000's ExIFS.sys driver is a kernel-mode component) must in turn be certified by an OEM. After an OEM and Exchange 2000 overcome these obstacles, the OEM can support Datacenter and Exchange 2000 SP1 deployments.
As a result of the architecture and implementation of Exchange 2000 clustering (through virtual servers that have storage groups—SGs—with databases), possible failover problems have led Microsoft to recommend only n+1 configurations for Exchange 2000 clustering. (An n+1 configuration means that the cluster contains n active nodes plus a standby node.) Microsoft testers recommend only n+1 configurations because such configurations always have an idle node that has plenty of virtual memory and no virtual servers running. Exchange 2000 Enterprise Server SP1 enforces cluster-support limitations by not allowing illegal configurations or not installing on existing cluster configurations that violate the configuration rules.
I disagree with Microsoft's recommendations for several reasons. You can manage virtual memory allocation by limiting the virtual servers and SGs per node, a distributed virtual server failover design can also alleviate allocation problems, and the ROI for n+1 configurations is very low and defeats much of the server-consolidation benefits. However, Microsoft has set support limitations on clustering for good reason—to make Exchange 2000 clustering a more reliable solution for customers. From this standpoint, I agree with Microsoft's recommendation.
The Opportunity for Server Consolidation
One of Microsoft's key goals for Exchange 2000 and Datacenter is to promote server consolidation. Although Exchange 2000 SP1 doesn't directly support many Datacenter features, its support for 4-node clustering is very important to Microsoft's and OEMs' shared vision for Exchange 2000 server consolidation.
As organizations work to achieve the reduced TCO, streamlined management, improved security, and improved real estate requirements of server consolidation, Exchange 2000 SP1 on Datacenter presents an option. My company is planning server consolidations in large sites in which 30 or more servers support 10,000 to 15,000 users. The plan calls for these servers to be consolidated into one or two 4-node Exchange 2000 Enterprise Server SP1 on Datacenter clusters in each site. This setup is in line with Microsoft's server consolidation goals for Exchange 2000. The time for long-awaited server consolidation projects might be now. Spend some time evaluating whether your Exchange deployment can benefit from Exchange 2000 SP1 on Datacenter.
