A year's experience
I am a cluster bigot. I developed this bias when I worked with VMScluster systems, which provide a secure, robust, and reliable platform for messaging deployments. When I began working with Microsoft Exchange Server, I wasn't able to cluster the messaging system because it lacked cluster support until Microsoft released Windows NT Server 4.0, Enterprise Edition (NTS/E 4.0) and Exchange Server 5.5, Enterprise Edition (Exchange 5.5/E) in November 1997. But when Microsoft made clustering available for Exchange, the company sealed the fate of my Exchange Server machine.
After searching for suitable equipment for a couple of months, I put my Exchange Server cluster into production in February 1998. For the most part, the cluster hums away without requiring many administrative interventions, but the implementation has hit some bumps along the way. I've learned a lot about creating, configuring, and maintaining an Exchange Server cluster in the past year.
Hardware Configuration Challenges
Exchange Server operates within Microsoft Cluster Server (MSCS) on an active/standby basis. Thus, an Exchange Server cluster must consist of two machines: a primary node and a secondary node. The primary node runs Exchange Server (i.e., it's active) under most conditions. The secondary node doesn't run Exchange Server until the primary node has a problem. Then, a cluster transition moves the set of Exchange services to the secondary node and makes it the active node. The secondary node takes on Exchange Server operations from the point of failure.
The first challenge in building an Exchange Server cluster is assembling suitable hardware. Microsoft recommends that you build a cluster using only hardware from the clustering categories of the Hardware Compatibility List (HCL—http://www.microsoft.com/ hwtest/hcl). The HCL lists all the systems that Microsoft has tested and certified to run MSCS, and Microsoft constantly updates the list to keep it current. Screen 1 shows a sample of the HCL's clustering-compatible systems.
Coming up with the right equipment to build an Exchange Server cluster is sometimes difficult. After looking around my department for HCL hardware, I built my cluster from hardware that was close to the list's requirements but not quite compliant. (Justifying hardware purchases is tough when you have noncompliant servers available.) However, I recommend sticking to the HCL in all production environments.
I call the cluster DBOIST-MSXCL. The cluster's primary node is DBOIST-CL0, a Digital Prioris MX 6200 that has two 200MHz Pentium Pro processors and 256MB of RAM. The cluster's secondary node is DBOIST-CL1, a Digital Prioris XL 5200DP that has two 200MHz Pentium processors and 256MB of RAM. Each node has an internal hard disk that runs NT, and the servers share a SCSI array that I based on a Compaq StorageWorks RA310 controller. The array holds a RAID 5 set that stores the Exchange Information Store (IS) and Directory store and a RAID 1 set that stores the cluster's transaction logs. A separate disk holds the Exchange binary files. At any time, the array is available only to the active node.
This configuration would never pass Microsoft's formal hardware-compatibility tests, because the two nodes aren't identical. Many applications store in the Registry parameters that vary depending on a system's hardware configuration. For example, the Exchange Performance Optimizer wizard analyzes a system's hardware and calculates parameters that it bases on the hardware analysis. The wizard writes these parameters to Registry keys (e.g., HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Services\MSExchangeISParametersSystem). The Registry values that Performance Optimizer calculates for a particular hardware configuration don't necessarily work for other systems. If the servers in a cluster are identical, the parameters for applications such as Performance Optimizer are appropriate for both of the cluster's nodes.
Prev. page
[1]
2
3
4
next page 
