An Approach to Exchange Cluster Configuration for AppManager White Paper July 2005

Transcription

1 An Approach to Exchange Cluster Configuration for AppManager White Paper July 2005 Contents AppManager Exchange Cluster Configuration... 1 Step 1: Active/Passive Failover Strategy... 2 Step 2: Drive Ownership Mapping... 2 The purpose of this white paper is to provide a step-by-step approach to Exchange cluster configuration in the NetIQ AppManager product (AppManager) environment once AppManager agents have been installed. While the basic process for installing AppManager agents is outlined below, please refer to the AppManager Installation Guide for complete details on the installation process. Step 3: Resource Dependency Mapping... 3 Step 4: Script Tabs for to Each Virtual Server... 5 Step 5: Resource Dependencies and Recovery Scripts... 5 Step 6: Scripts for each Node... 9

2 THIS DOCUMENT AND THE SOFTWARE DESCRIBED IN THIS DOCUMENT ARE FURNISHED UNDER AND ARE SUBJECT TO THE TERMS OF A LICENSE AGREEMENT OR A NON-DISCLOSURE AGREEMENT. EXCEPT AS EXPRESSLY SET FORTH IN SUCH LICENSE AGREEMENT OR NON-DISCLOSURE AGREEMENT, NETIQ CORPORATION PROVIDES THIS DOCUMENT AND THE SOFTWARE DESCRIBED IN THIS DOCUMENT AS IS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. SOME STATES DO NOT ALLOW DISCLAIMERS OF EXPRESS OR IMPLIED WARRANTIES IN CERTAIN TRANSACTIONS; THEREFORE, THIS STATEMENT MAY NOT APPLY TO YOU. This document and the software described in this document may not be lent, sold, or given away without the prior written permission of NetIQ Corporation, except as otherwise permitted by law. Except as expressly set forth in such license agreement or non-disclosure agreement, no part of this document or the software described in this document may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, or otherwise, without the prior written consent of NetIQ Corporation. Some companies, names, and data in this document are used for illustration purposes and may not represent real companies, individuals, or data. This document could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein. These changes may be incorporated in new editions of this document. NetIQ Corporation may make improvements in or changes to the software described in this document at any time NetIQ Corporation, all rights reserved. U.S. Government Restricted Rights: If the software and documentation are being acquired by or on behalf of the U.S. Government or by a U.S. Government prime contractor or subcontractor (at any tier), in accordance with 48 C.F.R (for Department of Defense (DOD) acquisitions) and 48 C.F.R and (for non-dod acquisitions), the government s rights in the software and documentation, including its rights to use, modify, reproduce, release, perform, display or disclose the software or documentation, will be subject in all respects to the commercial license rights and restrictions provided in the license agreement. Check Point, FireWall-1, Provider-1, SiteManager-1, and VPN-1 are trademarks or registered trademarks of Check Point Software Technologies Ltd. ActiveAgent, ActiveAnalytics, ActiveAudit, ActiveReporting, ADcheck, AppAnalyzer, Application Scanner, AppManager, AuditTrack, Chariot, ClusterTrends, CommerceTrends, Configuration Assessor, ConfigurationManager, the cube logo design, DBTrends, DiagnosticManager, Directory and Resource Administrator, Directory Security Administrator, Domain Migration Administrator, End2End, Exchange Administrator, Extended Management Pack, FastTrends, File Security Administrator, Firewall Appliance Analyzer, Firewall Reporting Center, Firewall Suite, Ganymede, the Ganymede logo, Ganymede Software, Group Policy Administrator, immarshal, Intergreat, Scripts, MailMarshal, Marshal, Migrate.Monitor.Manage, Mission Critical Software, Mission Critical Software for E-Business, the Mission Critical Software logo, MP3check, NetIQ, the NetIQ logo, the NetIQ Partner Network design, NetWare Migrator, OnePoint, the OnePoint logo, Operations Manager, PentaSafe, PSAudit, PSDetect, PSPasswordManager, PSSecure, Qcheck, RecoveryManager, Security Analyzer, Security Manager, Security Reporting Center, Server Consolidator, SQLcheck, VigilEnt, Visitor Mean Business, Vivinet, W logo, WebMarshal, WebTrends, WebTrends Analysis Suite, WebTrends for Content Management Systems, WebTrends Intelligence Suite, WebTrends Live, WebTrends Log Analyzer, WebTrends Network, WebTrends OLAP Manager, WebTrends Report Designer, WebTrends Reporting Center, WebTrends Warehouse, Work Smarter, WWWorld, and XMP are trademarks or registered trademarks of NetIQ Corporation or its subsidiaries in the United States and other jurisdictions. All other company and product names mentioned are used only for identification purposes and may be trademarks or registered trademarks of their respective companies.

3 AppManager Exchange Cluster Configuration The purpose of this white paper is to provide a step-by-step approach to Exchange cluster configuration in an AppManager environment once AppManager agents have been installed. While the basic process for installing AppManager agents is outlined below, please refer to the AppManager Installation Guide for complete details on the installation process. Basic steps to take prior to cluster configuration: 1. Install the AppManager agent and discover it on all active nodes. 2. The new NT_DynamicLogicalDiskSpace Script in AppManager removes the need to have all disk objects discovered; however, if you intend to discover all of the logical/physical disk objects on each node, you ll need to fail over to the passive node and repeat step one. 3. Restore nodes to their normal state if any were failed over for step two. 4. Prerequisite for Exchange: The owner of the AppManager for Exchange service (QExch2k1a) MUST be a Local Admin or Domain Admin on EVERY node in the cluster, with Logon as a Service rights in the Local Policy Settings. Contact NetIQ Technical Support if you want more information on permissions required. 5. Stop the agent service and then install the Exchange MO and any patches on each Virtual Server. 6. Discover Exchange on each Virtual Server using the Discovery_Exchange Script. Best Practice: Configuring AppManager for monitoring a multinode cluster This document is based on the configuration steps taken at two existing customer installations of sixand seven-node Exchange clusters running on Windows 2003 and Exchange 2003 that are monitored by AppManager using monitoring policies applied at the cluster group level. This approach permits consistent monitoring of all objects within a cluster group, while reducing the administrative overhead through the use of monitoring policies applied at the group level. Planning is the key to any successful implementation, so the first three steps involve the creation of charts that will map out what you will need to do in the steps that follow. Additionally, it is important to understand the relationship between the Virtual Server supported by the cluster and the underlying resources provided by those nodes on which the Virtual Server depends. While the tree view in the operator console of AppManager will display the nodes of a cluster as servers within a group, the monitoring policies and Script Groups that will be applied to that group are actually associated with the Virtual Servers supported by the cluster. The nodes that make up the cluster have ownership of drives that are critical resources for the Virtual Server. When the underlying resources change as a result of node failure or cluster reconfiguration, the active Scripts will follow the Virtual Server as it moves to whatever node now has the required resources. 1

4 Step 1: Active/Passive Failover Strategy In the example used for this document, the customer has a six-node cluster with four active and two passive nodes. Two of the active nodes are set to fail over to the first passive node and the other two active nodes are set to fail over to the second passive node. Each node is host to an Exchange Virtual Server. In the event that a Virtual Server s primary passive node is unavailable, the other passive node is its secondary failover point. In this installation, the customer elects to stop searching for an available node if both the primary and secondary failover nodes are unavailable. The example failover strategy for this installation would be mapped as follows: Active Node # Supporting Virtual Server On Primary Failover On Secondary Failover On Tertiary Failover Node #1 ExVServ1 Node #5 Node #6 Stop Node #2 ExVServ2 Node #6 Node #5 Stop Node #3 ExVServ3 Node #5 Node #6 Stop Node #4 ExVServ4 Node #6 Node #5 Stop Understanding the failover strategy is critical to mapping out the additional configuration steps. Step 2: Drive Ownership Mapping In the example, each node owns two drives. On failover, ownership of those two drives will be handed to one of the passive nodes. It is important to understand under what scenarios a particular node (both the active and passive nodes) could possibly have ownership of a particular set of drives. In this case, active Nodes 1 through 4 will never own additional drives (other than the Quorum drive) because the customer elects to stop searching if both passive Node #5 and Node #6 are unavailable. Since Node #5 and Node #6 can be the primary failover points for some of the active nodes and secondary failover points for the rest, they could each potentially own any of the drives that normally belong to Nodes 1 through 4 at some point in time. The drive ownership map is as follows: Node # Default Virtual Server Supported Default State Default Drives Owned Potential Drives Owned Node #1 ExVServ1 Active F: G: None Node #2 ExVServ2 Active H: I: None Node #3 ExVServ3 Active J: K: None Node #4 ExVServ4 Active L: M: None Node #5 Passive None F: G: H: I: J: K: L: M: Node #6 Passive None F: G: H: I: J: K: L: M: 2 White Paper

5 In addition, there is the cluster s Quorum Drive (Q:), which can be owned by any of the nodes in the cluster group depending on failover activity and configuration of the cluster s parameters. Step 3: Resource Dependency Mapping Since Scripts will be applied to the cluster through monitoring policies, every Script will be applied to every Virtual Server in the cluster. Therefore, it is important to ensure that the only Scripts that are active on a given node are the ones actually required by that node at the time. Any Scripts that are not required by that node will show in an inactive state. For the AppManager agent to permit a Script to be active, the defined resource dependency condition must be true. For example any node could own the cluster s Quorum Drive Q:. So, a dependency must be set so that if a particular node owns Drive Q:, the Scripts related to Drive Q: ownership will be active. If Drive Q: is not owned by the node, those Scripts will be inactive. To ensure that certain Scripts are always inactive, you need to create a resource dependency for each node that will always be false. This dependency can be set by using the AMADMIN_SetResDepedency Script. This Script will ensure the dependency condition is never met and, as a result, the Script will never run on that node. In this example, since a third failover causes the Virtual Server to stop searching, Node #1 will never own Drives H: and I: (normally owned by Node #2). A dependency was created in which to run any Script that should only run on nodes with Virtual Servers other than ExVServ1 (which normally runs on Node #1), Node #1 would first have to own Drives H: and I:. Since Node #1 will never own Drive H: and I:, the dependency condition will never be true and, as a result, those Scripts will always remain inactive. Similar dependencies need to be created for each node in the cluster group. Using the drive ownership map, you can determine the resource dependencies that you will need to apply for Scripts that should be active and inactive. For our example, the Resource Dependency Map is as follows: 3

6 Node # Default Virtual Server Supported Resource for Script to be Active Script Category Value Resource so Script will be Inactive Script Category Value Node#1 ExVServ1 Quorum KS EXNODEQ Node#1 ExVServ1 All Node#1 KSs EXVSERV1 All Node#2, 3 & 4 KSs EXNODE2 EXNODE3 EXNODE4 Node#2 ExVServ2 Quorum KS EXNODEQ Node#2 ExVServ2 All Node#2 KSs EXVSERV2 All Node#1, 3 & 4 KSs EXNODE1 EXNODE3 EXNODE4 Node#3 ExVServ3 Quorum KS EXNODEQ Node#3 ExVServ3 All Node#3 KSs EXVSERV3 All Node#1, 2 & 4 KSs EXNODE1 EXNODE2 EXNODE4 Node#4 ExVServ4 Quorum KS EXNODEQ Node#4 ExVServ4 All Node#4 KSs EXVSERV4 All Node#1, 2 & 3 KSs EXNODE1 EXNODE2 EXNODE3 Node#5 Quorum KS EXNODEQ Node#5 All Node#1, 2, 3 & 4 KSs EXVSERV1 EXVSERV2 EXVSERV3 EXVSERV4 Node#6 Quorum KS EXNODEQ Node#6 All Node# 1, 2, 3 & 4 KSs EXVSERV1 EXVSERV2 EXVSERV3 EXVSERV4 Notes about the columns in the above table: The first column is the node number in the cluster. The second column is the default Exchange Virtual Server supported by that node. The third column is the resources for the Scripts that you want to be active when the dependency is true. The fourth column is the Script category tab based on our sample naming convention.. 4 White Paper

7 The right two columns are dependencies that should never be met so that the associated Scripts never run. Step 4: Script Tabs for Each Virtual Server The next step is to create a tab for each Virtual Server in the cluster. These tabs will contain the Scripts that will be run on each Virtual Server. The values and actions for each Script may be unique for each server. Initially, just copy any Scripts to create the required tabs. In our example, the following tabs were created: ExVServ1 ExVServ2 ExVServ3 ExVServ4 ExNodeQ (for Scripts specific to the Quorum owner) Step 5: Resource Dependencies and Recovery Scripts There will be several resource dependencies that will need to be created on each node. At some point in the future, it will be inevitable that circumstances will require a cold start of the AppManager agent on a node. A cold start will DELETE ALL the resource dependency settings. It is very important to create Scripts that will allow a user to reset those dependencies quickly and accurately to ensure continued monitoring. Best Practice Suggestion: First create the recovery Scripts using copies of the AMADMIN_SetResDependency Script. Use them to set the initial resource dependencies rather than setting them individually, followed by creation of the recovery Scripts. This will permit you to validate your recovery Scripts the first time you set the dependencies. For our example, using the Resource Dependency Map created in Step 3 above, the following dependencies would be created for Node #1: 5

8 Script Name Script Source Dependency Logic Node1Set1 ExNodeQ Q: KSs active when the Quorum is owned by Node#1 Node1Set2 ExVServ1 F:,G: KSs active when node owns Drives F: & G:(default) Node1Set3 ExVServ2 H:,I: KSs will be inactive because drives are not/will not be owned by Node#1 Node1Set4 ExVServ3 H:,I: KSs will be inactive because drives are not/will not be owned by Node#1 Node1Set5 ExVServ4 H:,I: KSs will be inactive because drives are not/will not be owned by Node#1 The following resource dependencies would be created for Node #2: Script Name Script Source Dependency Logic Node2Set1 ExNodeQ Q: KSs active when the Quorum is owned by Node#2 Node2Set2 ExVServ2 H:,I: KSs active when node owns Drives H: & I: (default) Node2Set3 ExVServ1 F:,G: KSs will be inactive because drives are not/will not be owned by Node#2 Node2Set4 ExVServ3 F:,G: KSs will be inactive because drives are not/will not be owned by Node#2 Node2Set5 ExVServ4 F:,G: KSs will be inactive because drives are not/will not be owned by Node#2 The above Scripts were created in a similar fashion for Node #3 and Node #4 using dependencies on drive letters that will never be owned by these nodes for NodeXSet3 through NodeXSet5 Scripts. 6 White Paper

9 The above image shows the values tab of the AMAdmin_SetResDependency Script. Enter the Script category tab name and the drive letters that create the dependency condition based on the drive ownership map created in step two. Note: In this example we have entered two drive letters; however, a single resource dependency is all that is necessary for the process to work. If you enter multiple drive letters, make sure they are entered with colons, and separated by a comma and no space. For Node #5, the following Scripts were created: Script Name Script Source Dependency Logic Node5Set1 ExNodeQ Q: KSs active when the Quorum is owned Node5Set2 ExVServ1 F:,G: KSs active when node owns Drives F: & G: Node5Set3 ExVServ2 H:,I: KSs active when node owns Drives H: & I: Node5Set4 ExVServ3 J:,K: KSs active when node owns Drives J: & K: Node5Set5 ExVServ4 L:,M: KSs active when node owns Drives L: & M: Similar Scripts were created for Node #6, where the Script names would be Node6Set1 through Node6Set5. Best Practice Suggestion: First, create all the above Scripts in a tab that includes the name SRRecovery. In our example, the tab was called ExNodeSRRecovery so that it appears near the other Script tabs related to the Exchange cluster. 7

10 Second, within the recovery tab create individual Script Groups for each node that contain all the Scripts required to reset the resource dependencies for that particular node. This will permit you to drop a specific Script Group on any node of the cluster and know that all the required resource dependency settings have been applied to that node when needed. The above image shows an example of the Resource Recovery Scripts and Script Groups for each node. To verify that the correct resource dependencies have been placed on each node, drop the Script Group onto the appropriate node and then check the settings implemented. The settings can be easily viewed by going to the following menu: Troubleshooter > Client Resource Monitor Info > Application Monitoring Status Running this command will bring up a list of any current resource dependencies, similar to the image shown below. The status setting will indicate if the dependency is true or false (Active/Inactive). 8 White Paper

11 Step 6: Scripts for Each Node The next step is to copy the Scripts you want to apply to the virtual servers into each of the Script tabs created in step four. Configure the values for each Script as required for each specific virtual server and then create the Script Groups that will contain the individual Scripts. For clarity, use the same name for the same Script in each of the individual tabs. Once you ve created the Script Groups, you can then create the monitoring policy that will be applied to the cluster group. The Script Groups will then be applied to all the virtual servers in the cluster and the active jobs will follow the virtual server to any node in the cluster. Once the jobs appear, there will be one parent job with one child job for each node in the cluster. Open the parent job for each and validate that only the required Scripts for each node appear as active, and the ones that are not required for that node appear as inactive. This step will confirm that all the necessary resource dependencies are operating correctly. 9

12 The above image shows how Scripts residing in the EXNODEQ tab are only active on the node that currently owns the Quorum drive Q:. In this example, it is Node #5 after a failover from Node #1. Best Practice Suggestion: If you need to add any additional resource dependency settings or make changes to any Script, first remove the Script Group from the monitoring policy. Then apply the resource dependency and add the Script Group back to the monitoring policy. This step will ensure that the Script Group is reapplied correctly and associated with the newly added dependency settings. 10 White Paper