In "8 Ways to Improve Your Exchange Cluster, Part 1," April 2004, InstantDoc ID 41630, I discuss how getting cluster-specific training, planning ahead, building in extra redundancy, and deploying a solid infrastructure are vital to a successful Exchange Server 2003 or Exchange 2000 Server cluster deployment. Now let's take a look at four more important factors: using the correct configurations, implementing the right security measures, minimizing the downtime and impact of failovers, and efficiently deploying Exchange service packs to your cluster.
5. Configuration
As I explain in Step 4 in Part 1, the stability of the Windows infrastructure underlying your cluster is key to the cluster's success. Properly configuring that infrastructure can also improve your cluster's performance. Important configuration steps include setting staggered boot delays for the cluster nodes, obtaining the applicable OS resource kit, and tuning memory.
Set staggered boot delays. When power returns after a power failure, each node in your cluster will attempt to access shared storage at the same time. To avoid this conflict, set your preferred passive node's boot delay to be longer than the active node's delay.
To access the delay setting on Windows 2000 servers, right-click My Computer and select Properties from the context menu. Click Advanced, then click Startup and Recovery. On Windows Server 2003 nodes, open the My Computer Properties dialog box, click Advanced, then click Settings under Startup and Recovery. In the Startup and Recovery dialog box, select the Display a list of Operating Systems for __ seconds check box and enter the desired delay in the scroll box. Set the active node to 5 seconds and the passive node to 20 seconds. Alternatively, you can manually edit the boot.ini file on each node to implement a specific delay.
Obtain the OS resource kit. The Microsoft Windows 2000 Server Resource Kit contains valuable tools for cluster administrators. The resource kit provides approximately 300 utilities that aid management of Active Directory (AD) and Win2K servers, and several of these utilities are specific to clusters. Among the most important are dumpcfg.exe, which manages and records disk signature information; the Cluster Tool (clustool.exe), which backs up and restores cluster configurations; and clusrest.exe, which restores the quorum database. The Microsoft Windows Server 2003 Resource Kit tools include new and improved cluster utilities such as the Cluster Server Recovery Utility (clusterrecovery.exe), which you can use when restoring resource checkpoint files, replacing a failed disk, recovering from disk signature changes, or migrating cluster data to a different disk in the cluster; and the Cluster Diagnostics and Verification Tool (clusdiag.exe), which provides diagnostic tests to verify a cluster's functionality and which assists in reading the cluster log files.
Copy the tools to a standard folder on each cluster node as part of your cluster installation. Having the tools readily available can reduce the amount of time you need to diagnose a clustering problem if one arises. See http://www.microsoft.com/windows2000/techinfo/reskit/default.asp for more information about obtaining resource kits or resource kit tools.
Tune memory. Exchange 2000 servers that run on Win2K Advanced Server or Win2K Datacenter Server and that have more than 1GB of RAM require you to add the /3GB switch to the startup line, as the Microsoft article "XGEN: Exchange 2000 Requires /3GB Switch with More Than 1 Gigabyte of Physical RAM" (http://support.microsoft.com/?kbid=266096) explains. However, using the /3GB switch reduces the number of available Free System page table entries (PTEs), a situation that can cause performance problems—most noticeably the server's loss of network connectivity or blue screens. Microsoft recommends that you monitor the Free System PTE counter under the Performance Monitor's Memory object. If the value drops below 10,000, modify the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management registry subkey's SystemPages entry, as the Microsoft article "XADM: An Exchange 2000 Server with the '/3GB' Switch in the Boot.ini File May Lose Network Connectivity Under a Heavy Messaging Load" (http://support.microsoft.com/?kbid=313707) describes.
Windows 2003, Standard Edition and Windows 2003, Enterprise Edition both support the use of the /3GB switch. However, both editions also support a new switch, /userva, which allows a custom environment size for the application virtual address space and lets you allocate PTEs from boot.ini (rather than from the registry). For Exchange 2003 servers that have more than 1GB of RAM, use /userva=3030 in conjunction with the /3GB switch. For more Exchange 2003 memory-tuning procedures, see the Microsoft article "How to Optimize Memory Usage in Exchange Server 2003" (http://support.microsoft.com/?kbid=815372). Both Windows 2003 and Win2K require a reboot after you make these memory changes.
Another way to reduce virtual memory usage is to minimize the number of storage groups (SGs). Additional virtual memory is used when an SG is mounted, but additional databases within an existing SG have little effect on the amount of virtual memory used.