Managing Microsoft Exchange Server in a Cluster Environment
By Diane Garey (Issue 4 2000)
Running Microsoft Exchange in a high-availability cluster environment differs from running it on a stand-alone server. This article will describe the major differences when operating in a cluster environment. It will also discuss how to use the various methods available in VERITAS ClusterX for MSCS to enhance management, administration, and configuration of Exchange in a MSCS cluster environment using PowerEdge servers.
Microsoft Exchange Server is a business-critical messaging and collaboration application that major corporations depend on to enhance productivity and enable enterprise-wide employee communication. Organizations desiring high availability for Exchange can use Microsoft Exchange Server® 5.5 Enterprise Edition (Exchange 5.5 EE) in a Microsoft Cluster Service (MSCS) clustered environment.
Clusters, however, operate differently than stand-alone servers. Although much of the underlying hardware and operating system configuration is the same, the cluster configuration adds complexity not found in stand-alone server environments. This article discusses how applications differ in a cluster environment and the various methods that VERITAS ClusterX® for MSCS, a management tool for Microsoft clusters and clustered applications, enhances the management, administration, and configuration of Exchange 5.5 EE when operating in a MSCS environment using PowerEdge servers.
MSCS Clustering Increases Availability
Clustering, which integrates hardware and software technologies, enables a group of connected servers to operate as a single system and to present a single system image to clients. Clustering is a solution to a widespread computer issue—downtime. To overcome the negative effects of failure, several computers (or servers) are connected together so that the failure of one computer does not render all services running on that computer inoperable. Clustering provides the means to increase the overall availability of applications provided by the connected servers.
As part of Microsoft Windows 2000 Advanced Server and Windows NT 4.0 Enterprise Edition, MSCS clustering technology is used to increase the availability of business-critical applications and resources on Microsoft Windows servers. MSCS integrates with the core components of Windows 2000 and Windows NT, and provides a mechanism to monitor hardware and software resources, detect failure of such resources, and initiate a recovery of the resources on another server.
In addition to the operating system (OS) and MSCS requirements, the final software component of a cluster is the application. A clustered application has the ability to move from one cluster server to another via a failover. Each application group, sometimes called a virtual server, operates as an independent entity on the cluster.
The virtual server comprises all resources needed by the application, including the application services and/or executables. The virtual server can move independently among the clustered servers. Clients connect to the virtual server, rather than directly to a clustered server. This enables clients to automatically maintain connection to the application, regardless of which clustered server currently owns the application. It is particularly useful when a virtual server fails over—clients incur a brief downtime and then reconnect to the application.
Multiple applications can be installed on an MSCS cluster and the applications need not be aware that they are running on a cluster. However, cluster-aware applications receive additional benefits—such as quicker failover, earlier failure detection, smoother client reconnection, and easier installation.
This article discusses the cluster-aware version of Microsoft Exchange 5.5 Enterprise Edition, although the concepts apply to Microsoft Exchange 2000, Microsoft SQL Server, and other clustered applications.
Clusters operate differently than stand-alone servers. Most management applications were designed for stand-alone servers and manage them quite well. Few of them, however, have been designed to handle the unique characteristics of managing a cluster.
ClusterX for MSCS is a management application designed specifically for MSCS clusters. It addresses the cluster needs that can vary in subtle, yet significant ways from the needs of a stand-alone server. Two examples follow.
- Most clustered applications—once they are running-operate the same on a cluster and a stand—alone server. The applications, however, have different needs when they are started and stopped. Because the application operates as part of the underlying clustered system, it should be started and stopped by the cluster service. In some cases, if an application is stopped with the customary method (Net stop or in the Services Control Panel applet), MSCS immediately restarts the application because it believes the application was incorrectly taken off-line.
- The administration program of an application configures the properties of that application. However, the cluster management application administers the configuration of the application's cluster properties. Failover properties, which define how an application acts when a fault takes it off-line, are unique to the cluster. Many management applications assist with the application's properties, but not the application's cluster properties.
Clustering Microsoft Exchange
Microsoft Exchange 5.5 EE provides support for MSCS. Clustering Exchange 5.5 EE ensures that messaging services remain uninterrupted, even if a clustered server experiences a fault. For example, if the processor in a clustered node fails or the application experiences a fault, another node in the cluster replaces the failed node. Users on the failed node do not see a change in their e-mail service; they can continue to send and receive mail, and browse public folders.
ClusterX for MSCS has several features designed to improve administration of Exchange 5.5 EE in an MSCS environment:
- An Explorer-like view that finds and displays all clusters running Exchange 5.5 EE
- A dependency view that graphically depicts the resource dependency tree of an Exchange 5.5 EE clustered group
- An installation setup wizard
- Backup of the Exchange 5.5 EE group definition
- Generation of Simple Network Management Protocol (SNMP) traps and Windows events
- Report showing all resources and cluster properties of the Exchange 5.5 EE group
Auto-Discovery and Application-Driven Cluster Display
ClusterX automatically discovers clusters and several popular clustered applications. Given the user-defined search parameters, such as domains or specific cluster names, ClusterX scans the network for all servers configured as clustered nodes. Once discovered, ClusterX creates a cluster display—called the Cluster List —in the left pane of the management application. The Cluster List shows a hierarchy of application folders, domains, clusters, clustered nodes, cluster groups, and cluster resources.
Of particular interest, ClusterX categorizes applications into their own folders. Microsoft Cluster Administrator only shows cluster groups but not the underlying applications represented by the groups. ClusterX, however, delves deeper into the configuration to identify the applications that are configured on the cluster. ClusterX then fills the application folder with clusters that have the application configured on it. The folder can expand to show the cluster name, nodes, groups, and resources.
Figure 1 shows two clusters configured to run Exchange 5.5 EE. The Microsoft Exchange Server 5.5 folder shows both clusters along with status icons. The error icons indicate whether the group/resource is off-line, failed, or operating on a preferred node. Similar to other standard management applications, ClusterX depicts higher level items in the list with a down arrow when a subcomponent is in a failed state. The ClusterX Cluster List and status icons enable the administrator to quickly identify problems or potential problem areas in their clustered Exchange environment.
Figure 1. ClusterX Cluster List and Status Icons
A dependency is a property of a resource that defines the other resources that must be online before that particular resource can be brought online. The Microsoft tool provided with MSCS—Cluster Administrator—displays resource information only when the properties dialog box is viewed for a given property. To obtain a complete view of a group's dependency tree using Cluster Administrator, the administrator must open each resource property's dialog box and physically draw the tree.
Not only does ClusterX maintain the same resource property information, it greatly simplifies viewing and understanding a group's dependency tree. The ClusterX Dependency View automatically scans the dependency properties for a selected group and graphically displays them in an easy-to-understand picture.
ClusterX builds an intuitive and editable dependency tree. Most dependency issues are easily identifiable by visually inspecting the dependency tree. The view can help to locate which resource is not allowing the entire group to come online. Once identified, the problem can be easily rectified. Adding a dependency can occur by dragging one resource onto another; however, removing a dependency requires a right-mouse click followed by a menu selection.
For the Exchange administrator, the dependency tree of an Exchange 5.5 EE cluster group is known to be large and complex. It contains more than a dozen resources, some with multiple dependencies. To investigate a dependency issue using a nongraphical view would be time-consuming and prone to error. The simplicity of an interactive graphical view reduces both administration time and the probability of making incorrect changes.
Exchange 5.5 EE Installation Wizard
ClusterX offers installation wizards for several popular applications, file shares, and print spoolers that assist the administrator with the initial installation of a clustered application. The wizards offer a range of benefits, including fully configuring file share groups and initiating the setup of clustered print spoolers.
For Exchange 5.5 EE, ClusterX for MSCS initiates the setup of the clustered application. The wizard leads the administrator through a series of questions that help build the initial Exchange 5.5 EE cluster group. Then the wizard executes these steps:
- Prompts for the group name
- Requests the network name resource
- Asks for the IP address and verifies it as an available IP address
- Shows all the shared disks along with their ownership status (The administrator selects an available disk)
- Summarizes the information and requests confirmation; once confirmed the wizard creates the resources and assigns necessary dependencies
The wizard initiates the creation of a customized HTML document that explains how to complete the Exchange 5.5 EE installation process. This document contains instructions and tips that clarify the installation process. For example, the Exchange 5.5 EE installation process must begin on the clustered node that currently owns the Exchange 5.5 EE group, and the group must be online. The custom HTML document outlines these requirements before the administrator starts the Exchange 5.5 EE installation program.
Backing Up the Exchange 5.5 EE Group Definition
ClusterX for MSCS offers the ability to back up cluster configuration information. It saves configuration information such as group definitions, resource properties, cluster name, and node names. This information can be restored to the same cluster or to a different one. It also is useful in performing a compare against recent backup to determine if a configuration has changed. Additionally, it is useful during a support call: The backup file can be e-mailed to the support person, who can then review the file and learn about the cluster configuration.
ClusterX for MSCS allows administrators to back up the configuration for an entire cluster or a single cluster group. Because Exchange 5.5 EE resides in a single cluster group, administrators can back it up by selecting the group in the Cluster List, choosing the Backup option in the Utility View, and initiating the process. A few seconds later the Exchange 5.5 EE group configuration is backed up to disk and can be archived, e-mailed, or printed.
Generating SNMP Traps and Notification Events
Cluster Administrator, MSCS, and the Windows NT/Windows 2000 operating systems do not generate SNMP traps associated with cluster state changes. When an Exchange 5.5 EE cluster group fails from one node to another, no SNMP trap is generated. When an Exchange 5.5 EE resource is taken off-line, no SNMP trap is generated. Similarly, Windows events are infrequently generated when state changes occur in MSCS.
Cluster state changes that do not invoke notification can lead to serious consequences. An application could attempt to fail over and be unsuccessful. Unless notification of the failover occurs, downtime will be excessive. ClusterX addresses this issue by offering support for SNMP traps and by generating cluster-specific events. ClusterX-generated traps include notification of any of these events:
- An Exchange 5.5 EE cluster group fails
- An Exchange 5.5 EE cluster group is taken off-line
- A node joins an Exchange 5.5 cluster
These traps are then recognized by a higher level management application that can notify the administrator with an e-mail, phone call, or page.
In addition to generating SNMP traps, ClusterX creates dozens of events and places them into the ClusterX for MSCS Audit Log. Events created as a result of ClusterX commands are also forwarded to the Windows Event Log. Events show information very similar to standard Windows events, including date and time of creation, description of the event, which user and computer initiated the event, and the severity of the event.
Creating Reports for a Clustered Exchange 5.5 EE Cluster Group
Cluster Administrator shows some real-time cluster status and does not offer any reporting mechanism. ClusterX offers extended status information as well as more than a dozen reports. The reports contain information ranging from resource properties to node uptime statistics to cluster inconsistencies.
For Exchange 5.5 EE, ClusterX can generate reports containing detailed configuration information as well as a simple resource report. In Figure 2 , a Resource Parameters report shows the failover properties of resources in the Exchange 5.5 EE group. ClusterX provides quick and easy access to a variety of reports about the cluster environment, including detailed resource and group information.
Figure 2. ClusterX Provides Access to a Variety of Reports
ClusterX is Designed for Cluster Management
Clusters operate differently than stand-alone servers and cluster-aware applications running in an MSCS environment; they have unique requirements. For Exchange administrators who want to manage their clusters with a tool designed specifically for cluster management, VERITAS ClusterX for MSCS provides distinctive advantages with its configuration, administration, and notification capabilities.
Diane Garey (firstname.lastname@example.org) is a product marketing manager at VERITAS Software, a world-wide enterprise-class application storage management software provider. Ms. Garey is responsible for ClusterX and other Windows high-availability clustering products. She has degrees in Engineering and Business Administration from the University of New Brunswick in New Brunswick, Canada.