PATROL Central Infrastructure

Transcription

1 PATROL Central Infrastructure Best Practices Guide Supporting PATROL Agent version 3.6 PATROL Central Operator Web Edition version PATROL Central Operator Microsoft Windows Edition version PATROL Configuration Manager version PATROL Console Server version PATROL Knowledge Module for Event Management/ PATROL Notification Server version PATROL Knowledge Module for Log Management version PATROL RTserver version PATROL Infrastructure Monitor version (formerly the PATROL Infrastructure Knowledge Module version ) Distribution Server version BMC Impact Integration for PATROL version PATROL Enterprise Manager Console Server Connection version PATROL Integration for HP Network Node Manager version February 28, 2005

2 Contacting BMC Software You can access the BMC Software website at From this website, you can obtain information about the company, its products, corporate offices, special events, and career opportunities. United States and Canada Address BMC SOFTWARE INC 2101 CITYWEST BLVD HOUSTON TX USA Outside United States and Canada Telephone or Telephone (01) Fax (01) Fax Copyright 2005 BMC Software, Inc., as an unpublished work. All rights reserved. BMC Software, the BMC Software logos, and all other BMC Software product or service names are registered trademarks or trademarks of BMC Software, Inc. IBM is a registered trademark of International Business Machines Corporation. Oracle is a registered trademark, and the Oracle product names are registered trademarks or trademarks of Oracle Corporation. All other trademarks belong to their respective companies. PATROL technology holds U.S. Patent Number BMC Software considers information included in this documentation to be proprietary and confidential. Your use of this information is subject to the terms and conditions of the applicable End User License Agreement for the product and the proprietary and restricted rights notices included in this documentation. Restricted rights legend U.S. Government Restricted Rights to Computer Software. UNPUBLISHED -- RIGHTS RESERVED UNDER THE COPYRIGHT LAWS OF THE UNITED STATES. Use, duplication, or disclosure of any data and computer software by the U.S. Government is subject to restrictions, as applicable, set forth in FAR Section , DFARS , DFARS , DFARS , and DFARS , as amended from time to time. Contractor/Manufacturer is BMC SOFTWARE INC, 2101 CITYWEST BLVD, HOUSTON TX , USA. Any contract notices should be sent to this address.

3 Customer support You can obtain technical support by using the Support page on the BMC Software website or by contacting Customer Support by telephone or . To expedite your inquiry, please see Before Contacting BMC Software. Support website You can obtain technical support from BMC Software 24 hours a day, 7 days a week at From this website, you can read overviews about support services and programs that BMC Software offers find the most current information about BMC Software products search a database for problems similar to yours and possible solutions order or download product documentation report a problem or ask a question subscribe to receive notices when new product versions are released find worldwide BMC Software support center locations and contact information, including addresses, fax numbers, and telephone numbers Support by telephone or In the United States and Canada, if you need technical support and do not have access to the web, call or send an message to support@bmc.com. Outside the United States and Canada, contact your local support center for assistance. Before contacting BMC Software Before you contact BMC Software, have the following information available so that Customer Support can begin working on your problem immediately: product information product name product version (release number) license number and password (trial or permanent) operating system and environment information machine type operating system type, version, and service pack or other maintenance level such as PUT or PTF system hardware configuration serial numbers related software (database, application, and communication) including type, version, and service pack or maintenance level sequence of events leading to the problem commands and options that you used messages received (and the time and date that you received them) product error messages messages from the operating system, such as file system full messages from related software 3

4 4 PATROL Central Infrastructure Best Practices Guide

5 Contents Chapter 1 Introduction 13 Purpose of this Guide Planning the Implementation Process Chapter 2 Analyzing the Management Environment 17 Analysis Tools Completing the Enterprise Analysis Chapter 3 PATROL Central Implementation Logical Design 23 Overview RT Cloud Logical Design RTserver Design Considerations Characterizing RTserver Traffic Deciding Initial RTserver Placement RTserver Backup/Failover Considerations Visualization Design Which PATROL Central Console is Appropriate? Which Locations Need PATROL Console Servers? Is One PATROL Console Server Enough? Logically Sizing the PATROL Console Server PATROL Console Server Failover Considerations PATROL Central Operator Web Edition Placement Visualization Performance Considerations Event Management Planning Notification Server Usage and Placement Centralized Customization Management Designing for PATROL Management/Upgrade/ Patching Using the Distribution Server Security Considerations Chapter 4 PATROL Central Environment Physical Mapping 39 Overview Hardware Requirements Single Server Environments RTserver Hardware PATROL Console Server Hardware Contents 5

6 PATROL Central Operator Web Edition Hardware PATROL Central Operator Microsoft Windows Edition Hardware Co-Hosting PATROL Components PATROL Console Server Platform Selection RTserver Implementation Tips RT Cloud Configuration PATROL Console Server Implementation Tips Clustering a PATROL Console Server Chapter 5 Developing the Implementation Plan 53 Order of Installation and Configuration Planning Ahead Appendix A Frequently Asked Questions 55 RTserver and RT clouds How do clients connect to an RTserver? How many agents can connect to a single RTserver? How many agents can connect to a single RT cloud? How many RT clouds can be connected to a single PATROL Console Server? How many RTservers can be connected in a single cloud? What is the best RT cloud configuration? When are multiple RT clouds recommended? When should hub-and-spoke RT cloud architecture be used? Which multi-cloud configurations should be avoided? Can RTserver versions 6.2, , and 6.6 be mixed in the same cloud? How should version 6.2-based hub-and-spoke clouds be migrated to ? How can RTservers be configured to communicate through a firewall? PATROL Console Server How many users can a PATROL Console Server support? How many agents can a PATROL Console Server support? Which versions of the PATROL Agent should be used with the PATROL Console Server? How many RT clouds can be connected to a PATROL Console Server? What can be done to prevent the PATROL Console Server from becoming overloaded? How can a PATROL Console Server be backed up? How is a backup PATROL Console Server started? Are the locations of PATROL Central files and directories documented anywhere? What should I do if I see a message in the PATROL Console Server log file indicating duplicate RTservers? PATROL Central Operator Web Edition How many users can PATROL Central Operator Web Edition support? How large a profile can PATROL Central Operator Web Edition support? Why are console-side KM commands inactive on PATROL Central Operator Web Edition? PATROL Central Infrastructure Best Practices Guide

7 PATROL Central Operator Microsoft Windows Edition How large a profile can PATROL Central Operator Microsoft Windows Edition support? What version of PATROL Central Operator Microsoft Windows Edition is recommended? PATROL Infrastructure Monitor Should I use the former PATROL Infrastructure Knowledge Module or PATROL 7 Knowledge Module to monitor my PATROL Central infrastructure? What versions of the PATROL Central infrastructure are supported by the PATROL Infrastructure Monitor? How can more than one RT cloud be monitored with the PATROL Infrastructure Monitor? Other Components & Questions Are there any OS dependencies for PATROL Central infrastructure? Is PATROL Central infrastructure supported on iseries? When should the Availability Checker be used in an enterprise implementation? Why can't all aspects of KM operation be managed with PCM? How are PCM rulesets used to best advantage? Appendix B Infrastructure Planning Forms 83 Stakeholder Roster Worksheet Location Analysis Worksheet Appendix C Sample Solution Planning Forms & Diagrams 87 Sample Scenario Example Stakeholder Roster Example Location Analysis Worksheet for Houston Example Location Analysis Worksheet for Austin Example Location Analysis Worksheet for New York Example Diagrams Glossary 97 Contents 7

8 8 PATROL Central Infrastructure Best Practices Guide

9 Figures Example of a Multiple RT Cloud Configuration Example of Multiple RT Clouds with Hub and Spoke Example of Cross-Linked RT Clouds Example of RT Cloud-to-Cloud Failover Case 1 "Before" Small Hub-and-Spoke Cloud Case 1A "After" One Cloud Case 1B "After" Small Multi-Cloud Case 2 "Before" Large Hub-and-Spoke Cloud MainCore, Inc. Enterprise MainCore, Inc. Houston Location MainCore Inc. Austin Location MainCore, Inc. New York Location Fig ures 9

10 10 PATROL Central Infrastructure Best Practices Guide

11 Tables Requirements for Small Single-Server PATROL Central Environment (Up to 500,000 managed objects) Requirements for a Medium Single-Server PATROL Central Environment (Up to 3 million managed objects) Requirements for One RTserver on a Dedicated Computer (Up to 750 RT clients) Requirements for Two RTservers on a Dedicated Computer (Up to 1000 total RT clients) Requirements for Two to Four RTservers on a Dedicated Computer (Up to 2000 RT clients) Requirements for a Medium PATROL Console Server Environment (Up to 3 million managed objects) Requirements for a Large PATROL Console Server Environment (Up to 10 million managed objects) Requirements for PATROL Central Operator Microsoft Windows Edition (based on profile size) Tables 11

12 12 PATROL Central Infrastructure Best Practices Guide

13 Chapter 1 1 Introduction This chapter presents the following topics: Purpose of this Guide Planning the Implementation Process Chapter 1 Introduction 13

14 Purpose of this Guide Purpose of this Guide The purpose of the PATROL Central Infrastructure Best Practices Guide is to provide BMC Software PATROL solution architects with a process for gathering technical requirements, identifying potential trouble spots, and documenting a PATROL infrastructure implementation that will function reliably and efficiently. While this document discusses some "do's and don'ts" that are covered in other PATROL documents, it generally does not duplicate information provided elsewhere. This document frequently refers to product manuals and white papers for operational details. Information presented in this document applies to the following components: PATROL Agent version 3.6 or later PATROL Central Operator Web Edition version PATROL Central Operator Microsoft Windows Edition version PATROL Configuration Manager version PATROL Console Server version PATROL Knowledge Module for Event Management / PATROL Notification Server version PATROL Knowledge Module for Log Management version PATROL RTserver version PATROL Infrastructure Monitor version (formerly the PATROL Infrastructure Knowledge Module version ) Distribution Server version Common Connect clients BMC Impact Integration for PATROL version PATROL Enterprise Manager Console Server Connection version PATROL Integration for HP Network Node Manager version Best Practice Recommendation BP 1 Always obtain the latest revision of this guide before you base a PATROL Central design on the guidelines it contains. Release-to-release changes in infrastructure components can significantly affect the success or failure of a PATROL implementation. Verify the supported platform list for all components before you plan a PATROL Central implementation. Addition or deprecation of platforms for individual components can significantly affect the success or failure of a PATROL implementation. While this guide does not answer every possible technical question or provide for every design contingency, it will almost always lead to a design that uses PATROL in the best way possible. Choosing not to follow the guidelines presented in this document, or neglecting to take into account the factors discussed herein, can lead to a PATROL implementation that is unstable, that requires an excessive amount of time to maintain, or that can experience a major failure. If, at the end of the design process, 14 PATROL Central Infrastructure Best Practices Guide

15 Planning the Implementation Process solution architects have doubts about the proposed implementation, they are encouraged to consult with BMC Software and the PATROL Line Of Business for design validation before proceeding. Failure to do so can result in lost time, added expense, and disruption of service. Best Practice Recommendation BP 2 Always consult with BMC Software and with the PATROL Line of Business before deviating from the Best Practices presented in this guide. Failure to do so can lead to major software failures and system outages. To view the latest BMC Software manuals, technical bulletins, flashes, and white papers visit the BMC Software Customer Support page at Planning the Implementation Process While small PATROL implementations can be supported by a single infrastructure server running a PATROL Console Server/RTserver pair, design of a large PATROL solution is more challenging and should be approached in a top down manner. Best Practice Recommendation BP 3 PATROL Central implementations involving up to 500 managed nodes can be supported by a single infrastructure server running one PATROL Console Server, one RTserver, and one instance of PATROL Central Operator Web Edition. For detailed information about hardware sizing, see Hardware Requirements on page 40. Solution architects should start with the "big picture" and work their way down to progressively greater levels of detail until all their objectives have been met. Chapters 2 and 3 in this document will discuss this process in detail. In general, though, there are four steps in the process. 1. Solution architects should first identify the implementation stakeholders in order to engage them in the design and review process. A solution diagram should then be built that provides PATROL support for the number of managed servers and consoles that the solution requires. Every infrastructure component should be treated as if it required a dedicated server, but with geography and network topology in mind. The diagram should indicate the speed of all network connections, note the locations of any firewalls that may be present, and reference any existing equipment to be used for PATROL infrastructure. Chapter 1 Introduction 15

16 Planning the Implementation Process 2. The number of RT clouds and RTservers needed to support the PATROL solution should be determined. Provision should not yet be made for recoverability or failover, but key considerations include the number of agents in the design common Knowledge Modules (KMs) in the design the number of active objects in the KMs the number of concurrent PATROL operators using the infrastructure the general makeup of Active Sessions the number of agents per profile small "application discrete" profiles group or Individual profiles security considerations 3. Failure scenarios should be considered and the need to provide failover capabilities for particular components should be identified. Where failover is not possible, single points of failure should be eliminated or the solution should be modified so that most failures cause only a partial loss of functionality or performance. 4. Hardware requirements should be determined. Factors in configuring infrastructure servers include the work each PATROL component must perform and whether or not components can safely coexist and interoperate on the same server. The design should be optimized to require as little hardware as possible without unduly affecting performance. 16 PATROL Central Infrastructure Best Practices Guide

17 Chapter 2 Analyzing the Management 2 Environment This chapter describes how to complete the planning forms used to record information collected during analysis of the enterprise to be managed with PATROL. The forms can be found in Appendix B, Infrastructure Planning Forms. This chapter presents the following topics: Analysis Tools Completing the Enterprise Analysis Chapter 2 Analyzing the Management Environment 17

18 Analysis Tools Analysis Tools The Stakeholder Roster Worksheet provides a convenient place to note the people and groups who will be involved with the implementation and day-to-day operations using PATROL. Identifying contacts early in the process will aid in analysis and communication and help reduce missteps during implementation planning. The Location Analysis Worksheet provides a standardized format for recording relevant information about each logical and physical location to be managed. The analysis performed and the data recorded on this form will be used to develop a logical design for the PATROL implementation. The thoroughness of the analysis and accuracy of the information recorded will have a significant impact on the quality of the design and the overall success of the PATROL implementation. Use of this form will facilitate communication and review of the proposed design. Best Practice Recommendation BP 4 When planning a PATROL Central implementation, the minimum recommended PATROL Agent version is and version or later is preferred. These versions incorporate many performance and scalability improvements related to PATROL Central. If existing agents must be upgraded they should be upgraded to the latest Generally Available version. Completing the Enterprise Analysis The three key steps in the analysis and data collection stage are: 1. Identify project stakeholders 2. Diagram the enterprise to be managed by PATROL 3. Collect and record high-level sizing data for each management domain ACTION 1 Begin by completing the Stakeholder Roster. List all the groups or individuals who will participate or have an interest in this implementation of PATROL. If a group is listed, identify a person to serve as communications contact for the group. Refer to the roster during the remainder of the process when questions arise or when communicating about the progress of the implementation. Frequent communication will help highlight issues early in the process and reduce rework later. At a minimum, identify the people directly involved with: initial deployment and installation of PATROL 18 PATROL Central Infrastructure Best Practices Guide

19 Completing the Enterprise Analysis PATROL managed node configuration and change management ongoing user management, availability, and performance of PATROL Central infrastructure handling events and exception conditions raised by PATROL Document the role or primary interest of each stakeholder. Typical stakeholders will include System Administrators, Database Administrators, managers of business applications such as SAP, PeopleSoft, or Oracle Financials, Operations personnel, and PATROL Administrators. Key management sponsors or business partners may also be listed. Include anyone who will be directly involved in the implementation or needs to be kept informed of its progress. Make a high-level diagram of the entire business enterprise to be managed using PATROL, similar to the sample shown in Appendix C, Sample Solution Planning Forms & Diagrams. While it need not be overly detailed, it must indicate any widearea, lower-speed (less than 10 Mb/sec), or other non-local network links, and any firewalls, network switches, or other infrastructure that could impact connectivity. If portions of a physical location are isolated by local firewalls, identify each isolated area as a separate logical location and treat it as a physically separate location for the remainder of the analysis process. Make a copy of the Location Analysis Worksheet for each location shown on the diagram and write the name of each location in the field provided on each worksheet. Enter the firewall and network reliability information on each location worksheet. Some PATROL Central components must reside on the same LAN speed/quality network segment because WAN or other lower-speed/reliability connections will degrade performance. Accurate connectivity information is key to the design process. Enter the total number of nodes to be managed by PATROL on the worksheet for each location. Include all systems where a PATROL Agent will be installed in this count. This data is for environment sizing, so individual host names, OS vendors, and other similar details are unnecessary. List the name of each PATROL KM to be run on ANY managed node at each location. This information is vital to estimating the total number of objects to be managed and impacts PATROL Console Server placement and management profile definition. Note any KM which may have an unusually high number of Application Class instances. An example might be an operating system KM running on a large file server with an unusually large number of disk and file system instances. Enter on each worksheet whether or not PATROL Reporting will be used to aggregate data from managed nodes at that location. If events are to be forwarded from managed nodes to an event management tool, enter the name of the destination tool on the worksheet for each location. Chapter 2 Analyzing the Management Environment 19

20 Completing the Enterprise Analysis For each location where PATROL Central consoles are to be used, complete the Visualization Information section of the worksheet. To determine the number and placement of PATROL Console Servers, an estimate of the number of managed objects to be concurrently visualized is needed. The number of managed objects in a PATROL Console Server is the product of the number of concurrent console sessions multiplied by the number of managed objects in each session profile. The Visualization Information section of the worksheet is used to document estimates for these factors. Estimate by location the typical number of KMs needed per node, and enter that information on each worksheet. Using the object count guidelines in the following list, determine the total number of managed objects needed on the typical managed node for each location and enter the number on each location's worksheet objects per large application KM (for example, PATROL for Microsoft Exchange Servers or PATROL for BEA WebLogic) objects per medium-sized KM (for example, PATROL for Unix and Linux, PATROL for Microsoft Windows Servers, or PATROL for Oracle) 200 objects per small application KM (for example, PATROL for Compaq Insight Manager or PATROL for Dell OpenManage) NOTE If a KM was previously identified as likely to have an unusually large number of Application Class instances, increase the object count estimate accordingly. Estimate the total number of PATROL Central Operator Microsoft Windows Edition consoles to be installed at each location, add the estimated number of concurrent PATROL Central Operator Web Edition users, and enter the total on the worksheet. Estimate the expected number of concurrently active console sessions for each type of console at each location and record the information on the worksheet. Add the two numbers and record the total number of concurrent console sessions. Based on the monitoring and management needs of the console users, estimate the average number of managed nodes that will be defined in each concurrent console management profile and record it on the worksheet for each location. Multiply the number of managed nodes in the typical management profile by the number of managed objects on the typical managed node and record the result as the number of managed objects in the typical management profile. 20 PATROL Central Infrastructure Best Practices Guide

21 Completing the Enterprise Analysis The number of concurrent managed objects limits the number of console sessions that can be handled by a single PATROL Console Server. The object count is estimated by multiplying the number of managed objects in the typical management profile by the number of concurrent console sessions. Record the number on the worksheet for each location as the total number of concurrent managed objects. Chapter 2 Analyzing the Management Environment 21

22 Completing the Enterprise Analysis 22 PATROL Central Infrastructure Best Practices Guide

23 Chapter 3 PATROL Central Implementation 3 Logical Design To be successful, a PATROL Central implementation must be carefully designed and planned, giving careful attention to the limits and recommendations detailed in this chapter. This chapter presents the following topics: Overview RT Cloud Logical Design RTserver Design Considerations Characterizing RTserver Traffic Deciding Initial RTserver Placement RTserver Backup/Failover Considerations Visualization Design Which PATROL Central Console is Appropriate? Which Locations Need PATROL Console Servers? Is One PATROL Console Server Enough? Logically Sizing the PATROL Console Server PATROL Console Server Failover Considerations PATROL Central Operator Web Edition Placement Visualization Performance Considerations Event Management Planning Notification Server Usage and Placement Centralized Customization Management Designing for PATROL Management/Upgrade/ Patching Using the Distribution Server Security Considerations Chapter 3 PATROL Central Implementation Logical Design 23

24 Overview Overview In a general sense, the logical design step in the process involves adding to the enterprise diagram produced in the previous chapter and indicating where various PATROL Central infrastructure services will reside. The logical design phase is not concerned with the physical devices that will provide these services, only with their locations and in what numbers the services are needed. The first refinement to the enterprise diagram centers on designing domains which consist of managed nodes and one or more RTservers. In other documentation and/or presentations, these domains have variously been referred to as "messaging domains," "agent clouds," "RT clouds," and "clouds." The second refinement addresses the visualization needs of the enterprise. It includes numbers and placement of PATROL Central Operator Microsoft Windows Edition installations, PATROL Console Servers, and PATROL Central Operator Web Edition installation(s) (if browser-based visualization is needed). Design decisions may result in RTservers dedicated to supporting visualization components. These domains have also been referred to by several names, such as "console domain," "console cloud," "RT cloud," and "cloud." In this document, where the association of RTservers with managed nodes is important, the term "agent cloud" will be used. Similarly, "console cloud" will be used to specify the combination of visualization components and RTservers. If the association is not essential to the discussion, the more generic term "RT cloud" may be used to describe either agent or console clouds. RT Cloud Logical Design ACTION 2 Make a separate diagram to accompany each location worksheet, similar to the one shown in Appendix C, Sample Solution Planning Forms & Diagrams. These diagrams will be used to visualize the placement of infrastructure services for each location and will be needed when mapping the logical design to physical servers later. RTserver Design Considerations The central component of PATROL Central infrastructure is the RTserver message broker. Determining the placement and number of RTservers for each location is an iterative process. 24 PATROL Central Infrastructure Best Practices Guide

25 RTserver Design Considerations The first step involves high-level RTserver placement based on the number of managed nodes present and the characteristics of the message traffic the RTserver will handle. Once basic RTserver placement has been completed, a review of the enterprise will be conducted to identify potential points of unacceptable service interruption in the event of an RTserver outage, and to consider strategies to reduce the impact of any such outages. It is generally desirable to design a self-contained RT cloud for each location with 50 or more managed nodes, placing RTservers in the same geographical location as the managed nodes they support. Starting with the release of PATROL Central version 7.3, RTserver design decisions have become much simpler. Best Practice Recommendation BP 5 No RT cloud should include more than managed nodes. If PATROL Reporting will be used to aggregate data from a location, or if a Notification Server will be used, AND the RTserver will be installed on the same node as either one, that RTserver can support no more than 500 managed nodes. Typically, an RT cloud will need no more than two RTservers (a primary and a backup). Scalability is achieved by creating additional RT clouds rather than configuring "hub and spoke" RTservers to create larger domains. NOTE An exception to this general rule is presented in Appendix A, Frequently Asked Questions in the question When should hub-and-spoke RT cloud architecture be used? on page 62. In the case of managed nodes within DMZs, many companies have policies dictating the direction in which connections can be initiated to/from the DMZ. Typically, connecting to a node in the DMZ from the corporate intranet is permissible but connecting from a node in the DMZ into the intranet is not. In these scenarios, an RT cloud can be created for each DMZ and PATROL Console Server can be configured to connect to the RTservers in that RT cloud. For additional information that may affect the number and placement of RT clouds, see RTserver and RT clouds on page 57. Chapter 3 PATROL Central Implementation Logical Design 25

26 Characterizing RTserver Traffic Characterizing RTserver Traffic The type and volume of message traffic that RTservers must process impact the required number and placement of RTservers for each location. If only console traffic is handled, each RTserver can support a larger number of managed nodes. There are two optional PATROL components that when installed on the same computer as the RTserver will reduce the number of managed nodes per RTserver: PATROL Reporting and the Notification Server. Deciding Initial RTserver Placement Best Practice Recommendation BP 6 When creating a dedicated RT cloud for consoles, the primary RTserver should be placed on the same computer as the PATROL Console Server and the backup RTserver should be placed on a different computer. In cases where the PATROL Central Operator Web Edition is hosted on a separate computer, the backup RTserver for the console cloud can be hosted on the same computer as PATROL Central Operator Web Edition. ACTION 3 Using the traffic characteristics and best practice recommendations for guidance, update the solution diagrams for each location to reflect the number and placement of RTservers. RTserver Backup/Failover Considerations Failure of any component of PATROL Central infrastructure will affect components that rely on the one that fails. The severity of the impact and the time needed to restore functionality can be reduced by providing backup components to take over if a primary component fails. The process of automatic reconfiguration and resumption of service using backup components is called failover. When a failover occurs, the time required to restore full functionality depends on the service involved and varies considerably from service to service. For failure of a single service, the relative impacts and recovery times rank from least impact to most impact in the following order: 26 PATROL Central Infrastructure Best Practices Guide

27 RTserver Backup/Failover Considerations 1. An RTserver that is servicing managed nodes fails. In this case, all managed nodes connected to the failed RTserver will be shown as disconnected in their respective management profiles on all active consoles and the managed nodes will begin their failover process (if available). Since a managed node RTserver typically services only a portion of a given management profile, recovery times are shorter than for services which impact an entire management profile. 2. An instance of PATROL Central Operator Web Edition fails. When this happens, all browser-based sessions being served by the failed instance will cease to function. Only browser-based sessions will be affected; any PATROL Central Operator Microsoft Windows Edition sessions will continue to function. 3. An RTserver supporting a console cloud fails. When this happens, consoles served by the failed RTserver will be unable to communicate with the PATROL Console Server and will not be usable until the RTserver service is restored or the consoles and PATROL Console Server establish communication through a backup RTserver (if available). 4. A PATROL Console Server fails. As with a console RTserver failure, all console sessions served by the failed PATROL Console Server will cease to function. For more information, see PATROL Console Server Failover Considerations on page 30. The way in which a component goes offline also affects recovery time. If a component is stopped gracefully, all other components recognize the loss almost immediately and begin their respective failovers. If a component is lost unexpectedly due to a power or hardware failure, abrupt system shutdown, or physical network interruption, loss of the component may not be recognized by other components for several minutes and recovery time may be lengthened. Best Practice Recommendation BP 7 If a PATROL Central design includes backup RTservers, place a backup RTserver in each RT cloud. If a separate RTserver is provided to handle traffic between the PATROL Console Server and PATROL Central consoles (or PATROL Central Operator Web Edition) and redundancy is needed, place one backup RTserver in the console cloud. ACTION 4 Review the solution diagrams for all locations, looking for areas where an RTserver outage would create an unacceptable interruption of monitoring. If any such areas are identified, reconfigure the RT cloud and add backup RTservers to allow the infrastructure to continue to function if an RTserver service fails. Chapter 3 PATROL Central Implementation Logical Design 27

28 Visualization Design Visualization Design This phase of the design process involves determining the placement and number of PATROL Console Servers (and optionally PATROL Central Operator Web Edition instances) to support the anticipated level of PATROL Central console usage. At this stage, placement decisions should be made without regard for the possibility of sharing hardware with other services. The only consideration should be logical placement of visualization services based on best practice recommendations. There are multiple PATROL Console Server placement scenarios that will work for nearly any given situation. The best practice recommendations presented here represent a compromise between implementation complexity, run-time performance, and recovery time in the event of a service outage. Starting with the release of PATROL Central version 7.3, the PATROL Console Server has the ability to visualize managed nodes from multiple RT clouds. This simplifies PATROL Console Server placement design decisions. Which PATROL Central Console is Appropriate? Generally, PATROL Central Operator Microsoft Windows Edition is the recommended management console for anyone other than a casual user. For users who do not depend on access to the console to perform their primary job function, or for those who do not access PATROL daily, PATROL Central Operator Web Edition may be appropriate. Due to the architectural and component differences, the consoles should not be viewed as completely interchangeable. Best Practice Recommendation BP 8 Do not attempt to use PATROL Central Operator Web Edition to visualize more than 200 managed nodes. Try to limit profiles to fewer than 100 managed nodes. Use PATROL Central Operator Microsoft Windows Edition to visualize larger numbers of managed nodes. Which Locations Need PATROL Console Servers? Begin by placing a single PATROL Console Server in the location with the highest concentration of managed nodes. If network bandwidth and reliability are high, a single PATROL Console Server may be able to service all console sessions. 28 PATROL Central Infrastructure Best Practices Guide

29 Is One PATROL Console Server Enough? If a location with console users does not have a local PATROL Console Server, examine nearby locations for excess PATROL Console Server capacity that can be used to service it. If no excess capacity exists, either an additional PATROL Console Server must be installed at the remote location or a PATROL Console Server (and potentially other PATROL Central infrastructure components) must be installed locally. Bandwidth and reliability of the network connection to the remote location must be factored into the decision to use a remote PATROL Console Server, since the network link is a single point of failure. The primary reason to install a PATROL Console Server where it would not otherwise be justified is for improved performance. If console users in a particular location only need to view managed nodes in the same location, the improved reliability and performance gained by keeping network traffic local may justify the additional administrative and equipment cost of an additional PATROL Console Server. Maintenance of multiple PATROL Console Servers requires additional administrative work. While PATROL Console Server 7.5 introduced an online backup capability, there are still no provisions for automatically copying data between PATROL Console Servers, nor is there any functionality to synchronize or reconcile changes when the same type of data (privilege assignments, for instance) has been changed on two or more PATROL Console Servers. Operational policies and manual procedures must be implemented to work around these limitations. To arrive at an optimal design, each location must be evaluated independently and PATROL Console Server placement decisions must be made on a case-by-case basis. Is One PATROL Console Server Enough? In some cases, more than one PATROL Console Server will be needed in a single location. Factors in this decision include the number of concurrent console sessions and the number of managed objects in concurrent management profiles. The total number of managed objects known to the PATROL Console Server at any given time imposes an absolute limit on the capacity of the PATROL Console Server. Since the actual number of concurrent objects is impossible to determine precisely, designs should not be sized to exactly match the managed object estimates on the location worksheet. Some headroom must be provided to avoid the risk of PATROL Console Server performance degradation or run-time failure. Starting with the release of version 7.3 of PATROL Central infrastructure, the number of concurrent managed objects known to the PATROL Console Server is limited by the resources of the hardware hosting the PATROL Console Server, most notably available virtual memory. Chapter 3 PATROL Central Implementation Logical Design 29

30 Logically Sizing the PATROL Console Server Version 7.3 of the PATROL Console Server also introduced overload protection. The overload protection feature allows the PATROL Console Server to reject additional operator connections when they will cause preconfigured limits to be exceeded. Best Practice Recommendation BP 9 Regardless of the estimated number of concurrent managed objects, plan for no more than 25 (on 32-bit hardware) or 100 (on 64-bit hardware) concurrent console sessions to be served by a single PATROL Console Server. Logically Sizing the PATROL Console Server ACTION 5 Review the solution diagram and worksheet for each location in light of the PATROL Console Server sizing factors just discussed. Determine whether or not it will be feasible to host the PATROL Console Server on 64-bit hardware. If such a system is available, there is no hard object count limit. In practice, however, it is best to plan for no more than 10 million concurrent managed objects in a single 64-bit PATROL Console Server. If the PATROL Console Server will be hosted on 32-bit hardware, there is a hard limit of 3 million concurrent managed objects in a single PATROL Console Server. Best Practice Recommendation BP 10 Add an additional PATROL Console Server when the estimated concurrent managed object count approaches 3 million (on 32-bit hardware) or 10 million (on 64-bit hardware) to leave headroom in the design for additional, unanticipated use. Update the solution diagram for each location to show the placement of primary PATROL Console Servers. PATROL Console Server Failover Considerations There are two ways to provide redundancy for the PATROL Console Server: Install the PATROL Console Server on high-availability cluster hardware, store the configuration files on a shared disk, and define a cluster failover package that includes the PATROL Console Server. Install a secondary PATROL Console Server on a separate node and use the online backup feature to periodically snapshot data from the primary PATROL Console Server. 30 PATROL Central Infrastructure Best Practices Guide

31 PATROL Console Server Failover Considerations The only way to provide transparent service restoration in the event of a PATROL Console Server failure is by using a high-availability cluster. In this scenario, the PATROL Console Server service will be restarted by the cluster management software. Once restarted, the console cloud will reestablish connectivity and console sessions will resume functioning. In the absence of high-availability hardware, a secondary PATROL Console Server allows PATROL Central availability to continue during planned outages of the primary PATROL Console Server or during a hardware or other failure local to the primary PATROL Console Server node. A secondary PATROL Console Server does not, however, provide unattended recovery for a failed primary PATROL Console Server. If a secondary PATROL Console Server is activated in order to recover from an outage, its configuration data (for example, profiles and impersonations) will only be current to the last time the configuration files for the secondary PATROL Console Server were copied from the primary PATROL Console Server. Depending on the configuration of the online backup feature in the primary PATROL Console Server and the network-shared disks between the primary and the secondary, administrator intervention may be required to copy the latest data to the backup PATROL Console Server and then restart it. NOTE Copying configuration files from a running or active PATROL Console Server is supported only by using the online backup capability. Copying configuration files into a running or active PATROL Console Server is not supported. When using the admin_copy tool, copying configurations between PATROL Console Servers requires that both PATROL Console Server processes be shut down. After a secondary PATROL Console Server has been started either by highavailability cluster management software or through manual intervention, additional time is required for console sessions to be reestablished. This additional time will vary with the number and size of the management profiles involved. The way in which a component goes offline also affects recovery time. If a component is stopped gracefully (PATROL Console Server or RTserver), other components recognize the loss almost immediately and begin their respective failovers. If a component is lost unexpectedly due to a power or hardware failure, abrupt system shutdown, or physical network interruption, loss of the component may not be recognized by other components for several minutes and overall recovery time may be lengthened. For more information, see the PATROL Console Server and RTserver Getting Started guide. Chapter 3 PATROL Central Implementation Logical Design 31

32 PATROL Central Operator Web Edition Placement Best Practice Recommendation BP 11 If uninterrupted access to the PATROL Console Server is required, plan to run it on highavailability hardware. If high-availability hardware is not available, consider whether or not a secondary PATROL Console Server adds sufficient value to offset the additional hardware and administrative cost. ACTION 6 Using these best practice recommendations and the keeping in mind the failover considerations discussed in this section, update the solution diagram for each location to reflect the presence of any secondary PATROL Console Servers. PATROL Central Operator Web Edition Placement When browser-based visualization is needed in the enterprise, at least one instance of PATROL Central Operator Web Edition must be installed. If browser-based visualization is not needed, PATROL Central Operator Web Edition is not required. A single instance of PATROL Central Operator Web Edition can serve concurrent browser sessions depending on the size of the management profiles being used. A conservative approach to sizing the initial design is recommended. Best Practice Recommendation BP 12 Install PATROL Central Operator Web Edition on the same node as the PATROL Console Server that provides its interface into the PATROL Central infrastructure. If that is not feasible, install the PATROL Central Operator - Web Edition as near as possible to the consoles it will serve. Plan for a single instance of PATROL Central Operator Web Edition to serve no more than 20 concurrent browser sessions. Only one instance of PATROL Central Operator Web Edition may be installed on any single node. Visualization Performance Considerations PATROL managed nodes should always be configured to preload the KMs used to manage them. Preloading KMs also reduces the time required to establish and initialize console sessions. Production managed nodes should be configured to run ONLY preloaded KMs. This prevents unanticipated loading and unloading of KMs when the management profile definition causes a connection to be initiated to the managed node. 32 PATROL Central Infrastructure Best Practices Guide

33 Event Management Planning NOTE Starting with version of PATROL Central Operator Microsoft Windows Edition, management profiles can be configured such that all KMs from an agent s preloaded KM list are loaded in the profile automatically. This feature allows profiles to automatically stay in sync with changes to the preloaded KM list on each managed node. Best Practice Recommendation BP 13 Configure preloaded and disabled KMs appropriately on each managed node to minimize the time required for agent startup and console session initiation. If there are distinct groups of console users, PATROL Console Server performance can be improved by configuring separate PATROL Console Servers for each group of users. This approach is only practical if the enterprise is large and complex, and if there is no need to share management profiles between groups. If the console user community is large but there is overlap in management profile use, it is better to host the PATROL Console Server on hardware with more capacity than to divide the console session workload between PATROL Console Servers. The additional manual effort needed to keep common management profiles synchronized usually outweighs the performance improvement provided by a second PATROL Console Server. PATROL Central Operator Microsoft Windows Edition is fully supported under Microsoft Windows Terminal Services. The memory requirement for each console session depends on the number of concurrent managed objects, and the CPU utilization depends on the activity of each console session. A good technique for sizing the Terminal Services host system is to configure a typical session and multiply its resource consumption by the anticipated number of concurrent console sessions. Event Management Planning Nearly all contemporary PATROL implementations are configured to generate and forward events to an operations center for resolution. Tools from BMC Software and other vendors are used to receive and manage resolution of events originating from PATROL. PATROL managed nodes can generate events for a wide variety of reasons, but many of these events, while useful when troubleshooting or reconstructing a problem scenario, are of little help or interest to an operations center. Deciding which events to forward and who should receive them is a key factor in satisfaction with PATROL. BMC Software provides a KM solution for event processing called the PATROL Knowledge Module for Event Management (KM for EM). This KM serves multiple functions, and when installed and preloaded on a managed node allows event processing and filtering to be done at the source of the event. It also facilitates Chapter 3 PATROL Central Implementation Logical Design 33

34 Notification Server Usage and Placement advanced configuration management from a central location using PATROL Configuration Manager (PCM). PCM is addressed in greater detail elsewhere in this guide, but it is important to note that some PCM functionality requires the KM for EM to be active on the managed node. There are two methods for forwarding events from PATROL Agents to event management products that are not part of the PATROL architecture. Both methods leverage the KM for EM on each managed node, but use different methods for forwarding events. "In-band" event propagation leverages the RT cloud and forwards events based on a subscription model. Implementation of in-band event propagation requires configuration of the PATROL Console Server and use of an add-in module, such as BMC Impact Integration for PATROL version , PATROL Enterprise Manager Console Server Connection version , or PATROL Integration for HP Network Node Manager version (These three products are known collectively as Common Connect.) "Out-of-band" event propagation relies on agent-to-agent communication using the direct connection port of the agent (the default is 3181). Most out-of-band implementations use the KM for EM in a special configuration commonly known as a Notification Server. Managed nodes forward trusted (filtered) events directly to the Notification Server consolidation point. Event Management applications receive events from the Notification Server. Best Practice Recommendation BP 14 Install and configure the PATROL KM for Event Management to be preloaded on all managed nodes. To minimize network traffic, configure the KM for EM on each managed node to create a trusted event for all events to be forwarded. PATROL KM for EM configuration is best administered using PCM. Notification Server Usage and Placement A Notification Server is a special configuration of a PATROL Agent running the KM for EM. A Notification Server receives event messages from a group of managed nodes, optionally pre-processes them, and forwards them to an event management system. 34 PATROL Central Infrastructure Best Practices Guide

35 Centralized Customization Management Best Practice Recommendation BP 15 Use a Notification Server or BMC Impact Integration for PATROL version , PATROL Enterprise Manager Console Server Connection version , or PATROL Integration for HP Network Node Manager version to centralize event pre-processing, filtering, and forwarding. If use of a Notification Server is permissible and RT clouds can be limited to 500 or fewer managed nodes, install a Notification Server on the same computer with the primary RTserver for each RT cloud. Regardless of its placement, a single Notification Server can service no more than 500 managed nodes. Centralized Customization Management The PATROL Configuration Manager (PCM) is a GUI-based tool used to define and distribute PATROL configuration settings from a central location to some or all managed nodes. PCM can be used to manage configuration options such as Preloading KMs Poll times Disabling selected application classes Best Practice Recommendation BP 16 Use PCM to centralize administration of managed node settings. Placement of PCM in the enterprise is dictated by the needs of its users. A single instance of PCM can propagate rulesets to all nodes across an enterprise, so its geographical or network location is not critical. Distribution of rulesets through a firewall requires an open port for PCM. Some managed node attributes cannot be controlled using PCM because of the way those attributes are implemented. An example is data collection blackout. Some KMs are hard-coded to assure that their data collectors are available continuously, so if data collection is stopped with PCM, the local KM code will automatically re-enable it. Always verify compatibility of KM attributes before attempting to control them with PCM. PCM implements locking on its configuration files, so only one modification session may be open at a time. If responsibilities for the enterprise are divided among multiple administrators, consider implementing separate PCM instances for each administrative team. Best Practice Recommendation BP 17 Include no more than 700 managed nodes in any agent group (agent.ini file). Configure PCM to allow no more than 20 concurrent ruleset distributions. Chapter 3 PATROL Central Implementation Logical Design 35

36 Designing for PATROL Management/Upgrade/ Patching Designing for PATROL Management/Upgrade/ Patching PATROL Central infrastructure consists of a number of interdependent services which must function together. The PATROL Infrastructure Monitor has been developed to provide proactive infrastructure monitoring and to raise alerts if critical services are interrupted. All PATROL Central implementations should use the PATROL Infrastructure Monitor. Best Practice Recommendation BP 18 Install one instance of the PATROL Infrastructure Monitor to monitor the health of PATROL Central infrastructure. A single instance can monitor all of the clouds in your environment. For more information, see Appendix A, Frequently Asked Questions. Using the Distribution Server Placement of the Distribution Server (DS) in the enterprise is dictated by the needs of its users. A single DS can deploy software to all nodes across an enterprise, so its geographical or network location is not critical. Distribution of software through a firewall requires an open port for the DS. Best Practice Recommendation BP 19 Use the Distribution Server to centralize PATROL software deployment to managed nodes. NOTE All components and patches for PATROL products are currently packaged for use with the Distribution Server. Best Practice Recommendation BP 20 Verify the compatibility of components, patches, and hot fixes with Customer Support before planning to deploy them with the DS. There are no universal best practice recommendations for defining distribution collections. Factors to consider, however, include The more components defined in a collection, the greater the chance for a version conflict and subsequent distribution failure Deployment times are higher for large collections than for small ones 36 PATROL Central Infrastructure Best Practices Guide

37 Security Considerations Small collections deploy more rapidly than large ones, but may require multiple reboots of the same computer (depending the software being deployed) Large collections may require more administrative effort than small ones, since the collection must be updated when any component in it changes Security Considerations PATROL security level settings are defined by each customer's security policy and are largely beyond the scope of this document except to state that PATROL Console Server supports the limited interoperability between consoles and agents running at different security levels. Starting with the release, the RT cloud connection to a PATROL Console Server can be configured with its own security level. All other components in that cloud (agents and consoles) have to be at the same security level, but RT clouds at different security levels can be connected to the PATROL Console Server transparently to the consoles and agents in those different clouds. For more information, see the PATROL Console Server and RTserver Getting Started guide. Chapter 3 PATROL Central Implementation Logical Design 37

38 Security Considerations 38 PATROL Central Infrastructure Best Practices Guide

39 Chapter 4 PATROL Central Environment 4 Physical Mapping This chapter presents the following topics: Overview Hardware Requirements Single Server Environments RTserver Hardware PATROL Console Server Hardware PATROL Central Operator Web Edition Hardware PATROL Central Operator Microsoft Windows Edition Hardware Co-Hosting PATROL Components PATROL Console Server Platform Selection RTserver Implementation Tips RT Cloud Configuration PATROL Console Server Implementation Tips Clustering a PATROL Console Server Chapter 4 PATROL Central Environment Physical Mapping 39

40 Overview Overview Once the logical design is complete, PATROL Central infrastructure components must be assigned to specific servers. To accomplish this, all components must be reviewed by type and assigned to computers in the solution diagram. This process typically requires several passes through the design as the capacities of existing servers and their abilities to host particular components are assessed. ACTION 7 Using guidelines presented in this section, determine the hardware needed to host all components identified in the logical design phase. Update solution diagrams to reflect CPU, memory, and disk capacity of all infrastructure servers. Hardware Requirements The servers needed to host PATROL infrastructure vary in configuration based on the components they are called upon to run and the workload they are required to bear. While these factors vary widely from one environment to another, broad guidelines are presented in the following sections to help with computer selection and configuration. Except as noted, these computers are dedicated systems that only run PATROL infrastructure and do not run major applications. Single Server Environments A single server hosting an RTserver, PATROL Console Server, and PATROL Central Operator Web Edition can be used to manage an environment of up to 3 million managed objects in a single RT cloud (with no more than 700 agents) provided the computer is sufficiently powerful. The hardware requirements for various singlecomputer configurations are described in Table 1 on page 41 and Table 2 on page 41. Best Practice Recommendation BP 21 It is not typically necessary to host the PATROL Console Server on a high-end system. The PATROL Console Server needs a fast CPU and a generous amount of RAM more than exceptional network and disk I/O performance, and a workgroup class server will usually suffice. 40 PATROL Central Infrastructure Best Practices Guide

41 Single Server Environments Table 1 Requirements for Small Single-Server PATROL Central Environment (Up to 500,000 managed objects) Resource Minimum Requirements Recommendation Processor Linux and Windows Linux and Windows Single Processor Intel Pentium III at 800 MHz Solaris Single Processor SUN Netra X1 at 500 MHz AIX Dual Processor Intel Pentium III at 800 MHz Solaris Dual Processor SUN 420R UltraSPARC II at 450 MHz AIX Single Processor IBM pseries POWER 3 II at 450 MHz Server Memory 512 MB 1 GB Disk Space 300 MB 300 MB Dual Processor IBM pseries POWER 3 II at 375 MHz Table 2 Requirements for a Medium Single-Server PATROL Central Environment (Up to 3 million managed objects) Resource Minimum Requirements Recommendation Processor Linux and Windows Linux and Windows Dual Processor Intel Pentium 4 at 2000 MHz Xeon Solaris Dual Processor SUN V240 UltraSPARC III at 1000 MHz AIX Quad Processor Intel Pentium III at 900 MHz Solaris Quad Processor SUN V480/880 at 900 MHz AIX Dual Processor IBM pseries POWER 4 at 1000 MHz Server Memory 3 GB 4 GB Disk Space 1 GB 2 GB Quad Processor IBM pseries POWER 4 at 1000 MHz Chapter 4 PATROL Central Environment Physical Mapping 41

42 RTserver Hardware RTserver Hardware If the requirements of a PATROL infrastructure server exceed the recommended capacity of a single computer or if special circumstances warrant, RTservers can be installed on separate computers (primarily to support one or more clouds of PATROL Agents). In such circumstances it is usually best to choose a computer with a relatively fast CPU and large memory in order to allow the RTserver to maintain high throughput under peak conditions. This need notwithstanding, a dedicated RTserver computer will typically have spare capacity for use by other PATROL infrastructure components such as a Notification Server or a PATROL Reporting aggregator. There are scenarios where multiple RTservers can be hosted on the same computer to reduce the hardware costs associated with hosting PATROL infrastructure. Table 3 shows the hardware requirements for a single RTserver running on a dedicated computer, separate from the PATROL Console Server or PATROL Central Operator Web Edition. Table 3 Requirements for One RTserver on a Dedicated Computer (Up to 750 RT clients) Resource Minimum Requirements Recommendation Processor Linux and Windows Linux and Windows Single Processor Intel Pentium III at 733 MHz Solaris Single Processor SUN UltraSPARC IIi at 400 MHz Single Processor Intel Pentium 4 at 1.4 GHz Solaris Single Processor SUN UltraSPARC IIe at 500 MHz AIX AIX Single Processor IBM pseries POWER 3-II at 333 MHz Server Memory 512 MB 1 GB Disk Space 300 MB 300 MB Single Processor IBM pseries POWER 3-II at 500 MHz Starting with the release of RTserver version , PATROL Central supports configurations with more than one RTserver on the same computer. Depending on its speed and workload (the total number of RT clients connected to all RTservers on the computer), a single computer can host up to four RTservers. Table 4 on page 43 and Table 5 on page 44 show the recommended hardware for different workloads: 42 PATROL Central Infrastructure Best Practices Guide

43 RTserver Hardware Table 4 Resource Processor Requirements for Two RTservers on a Dedicated Computer (Up to 1000 total RT clients) Recommendation Linux and Windows Single Processor Intel Pentium 4 at 1400 MHz Solaris Single Processor SUN UltraSPARC IIe at 500 MHz AIX Server Memory Disk Space Single Processor IBM pseries POWER 3-II at 375 MHz 1 GB 300 MB Chapter 4 PATROL Central Environment Physical Mapping 43

44 RTserver Hardware Table 5 Resource Processor Requirements for Two to Four RTservers on a Dedicated Computer (Up to 2000 RT clients) Recommendation Linux Dual Processor Intel Pentium 4 at 1400 MHz Solaris Single Processor SUN V210 UltraSPARC IIIi at 1 GHz or Dual Processor SUN 280R UltraSPARC III at 750 MHz AIX Single Processor IBM pseries POWER 4 at 1200 MHz or Dual Processor IBM pseries POWER 3 II at 375 MHz Windows Server Memory Disk Space No more than two RTservers can run on the same Windows-based computer. For more information on configuration, see RTserver Hardware on page GB 300 MB For more information about configuring more than one RTserver to run on the same computer, see the PATROL Console Server and RTserver Getting Started guide. When running more than one RTserver on the same computer, the number of backup and primary RTservers on the same system should be balanced. If two agent RT clouds are supported by two computers, for example, one computer should serve as the primary for cloud A and the backup for cloud B while the other computer serves as the primary for cloud B and the backup for cloud A. This distributes the workload across both RTservers and minimizes the impact of losing a single computer. 44 PATROL Central Infrastructure Best Practices Guide

45 PATROL Console Server Hardware PATROL Console Server Hardware Table 6 describes minimum and recommended hardware for PATROL Console Server version in medium (up to 3 million managed objects) and Table 7 on page 46 describes large (up to 10 million managed objects) environments. Best Practice Recommendation BP 21 It is not typically necessary to host the PATROL Console Server on a high-end system. The PATROL Console Server needs a fast CPU and a generous amount of RAM more than exceptional network and disk I/O performance, and a workgroup class server will usually suffice. An RTserver can be run on the PATROL Console Server computer to support a cloud of PATROL Central consoles, but all agent RT clouds should be hosted on other hardware. Best Practice Recommendation BP 22 Set PATROL Console Server overload protection limits based on the estimated workload of each PATROL Console Server in the solution design. For more information about overload protection and the type of limits that are available, see the PATROL Console Server and RTserver Getting Started guide. Table 6 Requirements for a Medium PATROL Console Server Environment (Up to 3 million managed objects) Resource Minimum Requirements Recommendation Processor Linux and Windows Linux and Windows Dual Processor Intel Pentium 4 at 1400 MHz Solaris Dual Processor SUN 280R UltraSPARC III at 750 MHz AIX Dual Processor Intel Pentium 4 at 2000 MHz Solaris Dual Processor SUN V240 UltraSPARC IIIi at 1 GHz AIX Dual Processor IBM pseries POWER 3-II at 450 MHz Server Memory 3 GB 4 GB Disk Space 1 GB 2 GB Dual Processor IBM pseries POWER 4 at 1200 MHz Chapter 4 PATROL Central Environment Physical Mapping 45

46 PATROL Central Operator Web Edition Hardware Table 7 Requirements for a Large PATROL Console Server Environment (Up to 10 million managed objects) Resource Minimum Requirements Recommendation Processor Linux Linux Dual Processor Intel/HP Itanium 2 at 900 MHz Solaris Dual Processor SUN V240 at 1280 MHz AIX Dual Processor IBM pseries POWER 4 at 1450 MHz Quad Processor Intel/HP Itanium 2 at 900 MHz Solaris Quad Processor SUN V480/880 at 900 MHz AIX Quad Processor IBM pseries POWER 4 at 1200 MHz Windows Due to the virtual memory limitations of 32-bit hardware, large PATROL Console Server configurations cannot be hosted on a single Windows computer. Server Memory 4 GB 6 GB Disk Space 3 GB 4 GB PATROL Central Operator Web Edition Hardware At the time this guide was written the Performance, Scalability, Reliability & Interoperability (PSRI) lab had not completed an assessment of the most recent release of PATROL Central Operator Web Edition. Hardware recommendations for hosting this component of PATROL infrastructure will be provided when an assessment is complete. Contact BMC Software and the PATROL Line Of Business for updated information. 46 PATROL Central Infrastructure Best Practices Guide

47 PATROL Central Operator Microsoft Windows Edition Hardware PATROL Central Operator Microsoft Windows Edition Hardware Table 8 lists hardware requirements for different profile sizes: Table 8 Requirements for PATROL Central Operator Microsoft Windows Edition (based on profile size) Resource Recommendation Small Profiles (up to 100 managed agents) Processor Single Processor Intel Pentium III at 500 MHz Memory 128 MB Medium Profiles (up to 500 managed agents) Processor Single Processor Intel Pentium III at 700 MHz Memory 512 MB Large Profiles (up to 1200 managed agents) Processor Single Processor Intel Pentium III at 700 MHz Memory 1 GB NOTE Profiles with 500 or more agents take several minutes to finish loading. Co-Hosting PATROL Components The following recommendations provide direction on which PATROL components can reside with one another on the same host: Chapter 4 PATROL Central Environment Physical Mapping 47

48 PATROL Console Server Platform Selection Best Practice Recommendation BP 23 All infrastructure components can now coexist with other infrastructure components provided the host has sufficient memory and CPU bandwidth. A Common Connect client (for example, the PEM CSE client) can be installed on the same host as the PATROL Console Server and RTserver. The system requirements of the PATROL Console Server are relatively high, so when possible place the PATROL Console Server and RTserver on a dedicated host. Try to keep that system free of other applications. If the underlying platform is supported by both components, an RTserver should be installed on the same host as the PATROL Console Server, and the PATROL Console Server and PATROL Central consoles should be configured to connect to this RTserver. This arrangement will minimize the overhead of communication between the console and the PATROL Console Server. Never install a PATROL Console Server or RTserver on a computer running any of the following products: PATROL End-to-End Response Timer version and earlier PATROL Central Alerts Web Edition (specific to version only) Always check product release notes to obtain the latest information about incompatibilities and configuration techniques for co-locating components. PATROL Central Operator Web Edition version cannot be installed on the same computer as PATROL Central Alerts Web Edition version See the following Product Flash for further information: htm PATROL Console Server Platform Selection Although there were circumstances under which prior releases of the PATROL Console Server performed better on 32-bit Intel servers than on Sun servers, this is no longer the case. Version of the PATROL Console Server can be implemented on either platform with equal efficiency. Best Practice Recommendation BP 24 Environments with up to 3 million managed objects or 25 concurrent users can be hosted on 32-bit hardware. Environments with up to 10 million managed objects or 100 concurrent users must be hosted on 64-bit hardware. 48 PATROL Central Infrastructure Best Practices Guide

49 RTserver Implementation Tips A PATROL Console Server on 32-bit hardware that supports 3 million objects requires more than 3 GB of application virtual memory. On Intel x86 hardware, RHAS 2.1 supports 3 GB of application virtual memory and RHEL 3.0 supports 4 GB. By default, Windows is limited to 2 GB of virtual memory but can be coaxed into supporting 3 GB by using an optional argument (/3GB) in the boot.ini file; versions of Windows that support this option include Windows Server 2003 Windows Server 2003, Enterprise Edition Windows Server 2003, Datacenter Edition Windows 2000 Advanced Server Windows 2000 Datacenter Server RTserver Implementation Tips The following recommendations provide direction on implementing PATROL RTservers: Best Practice Recommendation BP 25 When the environment or the hardware mandates the presence of multiple RT clouds, provide an RTserver for PATROL Central clients that is separate from the RTserver used by the PATROL Agents. The RTservers used to implement the console RT cloud can be hosted on the same computers as the PATROL Console Server and PATROL Central Operator Web Edition. Do not direct connect more than 700 PATROL Agents to a single RTserver or RT cloud. RTservers should be geographically close to the client computers they support. Place RTservers on the same side of a firewall as their connected clients. RT Cloud Configuration RTservers are capable of handling large numbers of client connections and can be configured to support messaging failover through appropriate client configuration. Their proper configuration is key to the performance and stability of a PATROL Central implementation. Chapter 4 PATROL Central Environment Physical Mapping 49

50 RT Cloud Configuration Two or more RTservers in the same infrastructure create what BMC Software refers to as an RT cloud (or sometimes a messaging domain). An RTserver can join an RT cloud in either of two ways: 1. By obtaining the names of other RTservers in an RT cloud from its configuration file (rtserver.cm) 2. By invitation from another RTserver When deciding which RTservers should establish connections with others, there are guidelines which will prevent and/or reduce unexpected performance and stability issues: Best Practice Recommendation BP 26 Ensure that communication between any two RTservers is unidirectional; never let the server_names variable in the configuration files of two RTservers contain one another's names. For the simple case of a cloud containing just a primary and a backup RTserver, set the server_names variable in the primary RTserver to UNKNOWN and set the server_names variable in the secondary RTserver to point to the primary RTserver. Plan and control the direction of initialization through firewalls. The preferred configuration consists of separate RT clouds within each DMZ, with the PATROL Console Server initiating connections to each through the firewall. If several DMZs or remote sites are linked into a single RT cloud using hub-and-spoke architecture, the directional connections should be configured as follows. To permit server RT-1 within the corporate intranet to contact server RT-2 on the other side of the firewall and invite it to join the RT cloud, put the name of RT-2 in the server_names variable on RT-1 and set the server_names variable on RT-2 to "UNKNOWN". This will prevent RT-2 from joining unless RT-1 establishes the relationship. Do not assign more than two RTservers to a server_names variable; experience has shown it to be of no benefit. If an RT cloud consists of just two RTservers, use the following guidelines: Set the max_client_conns to the same value in both RTservers. Configure all RT clients in the RT cloud to specify primary and backup RTservers in the same order (i.e., do not split the RT clients between the two computers). 50 PATROL Central Infrastructure Best Practices Guide

51 PATROL Console Server Implementation Tips PATROL Console Server Implementation Tips If the PATROL Console Server will host users, consider the following recommendations when you plan your implementation: Increase the configuration parameter threadpoolsize to 8 or 12. This configuration variable controls the number of threads created to handle concurrent requests. This recommendation is applicable only on computers with 4 or more processors, for example, computers that are capable of true multiprocessing. For more information on configuring the number of process thread pools, see the PATROL Console Server and RTserver Getting Started guide. Increase the configuration parameter autosavetimer. This parameter controls the frequency with which profiles open in read-write mode are automatically saved to disk. The default value is 7.5 minutes. With a large number of read-write profiles opened concurrently, the auto-save feature can generate a lot of additional disk I/O. Consider increasing this value to 10 or 15 minutes. For more information on configuring a management profile, see the PATROL Console Server and RTserver Getting Started guide. If you use the online backup capability, consider the maximum number of concurrent read-write profile users when determining the frequency of the online backup schedule, especially in cases where relatively large profiles (more than 200 agents) are opened for read-write use on a regular basis. Backup frequencies of once per hour or longer will minimize performance impact in large environments. Depending on the disk I/O performance of the PATROL Console Server computer, the backup frequency can be increased or decreased. Clustering a PATROL Console Server In a cluster configuration, applications can move from one cluster node to another when necessary. While the PATROL Console Server can be configured to support high availability clustered environments, there are several installation and configuration requirements: Chapter 4 PATROL Central Environment Physical Mapping 51

52 Clustering a PATROL Console Server Best Practice Recommendation BP 27 Install separate copies of the PATROL Console Server on local private disks of each participating host in the cluster. Use configuration overrides (environment variables) to direct each instance of the PATROL Console Server to a set of common directories on a shared drive containing all of the runtime configuration data. Use the same configuration information for all hosts in the cluster. Use the same impersonation database for all hosts in the cluster. Use the same access control database for all hosts in the cluster. Use the same Management Profiles for all hosts in the cluster. Use the same PATROL Console Server log files for all hosts in the cluster. Note that certain types of security-related configuration changes applied on one node are not automatically replicated to other nodes in the cluster by means of the environment variable overrides. The environment variable overrides allow sharing of the configuration data that is typically changed on a day-to-day basis. The security-related configuration changes are typically made once per node. These changes must be done manually for each node so that both nodes have equivalent security policy settings. For more information on replication, see the PATROL Console Server and RTserver Getting Started guide. 52 PATROL Central Infrastructure Best Practices Guide

53 Chapter 5 Developing the Implementation Plan 5 This chapter presents the following topics: Order of Installation and Configuration Planning Ahead Chapter 5 Developing the Implementation Plan 53

54 Order of Installation and Configuration Order of Installation and Configuration In order to minimize the implementation effort required, PATROL Central infrastructure components should generally be installed and configured in the following order: Best Practice Recommendation BP 28 Install the Distribution Server Perform the following steps for every RT cloud, one cloud at a time: A. Install RTservers B. Install PATROL Agents on all managed nodes Use PATROL Configuration Manager to configure all PATROL Agents Install the PATROL Console Server and configure it to service the required RT clouds Configure the PATROL Console Server for users Set RT cloud rights and privileges Planning Ahead As a matter of good planning, it is helpful to determine in advance those systems where special privileges are needed to install, configure, and test PATROL infrastructure. Whenever possible, early arrangements should be made for creation of the necessary accounts and privileges and for assistance from appropriate system administrators. If changes require that any systems be re-booted before they take effect, those activities should be coordinated in advance so that users are not interrupted and normal business is not disrupted. The Stakeholder Roster completed during the Analysis Phase can be used to identify people who may be affected. 54 PATROL Central Infrastructure Best Practices Guide

55 Appendix A Frequently Asked Questions A This appendix presents the following topics: RTserver and RT clouds How do clients connect to an RTserver? How many agents can connect to a single RTserver? How many agents can connect to a single RT cloud? How many RT clouds can be connected to a single PATROL Console Server?. 58 How many RTservers can be connected in a single cloud? What is the best RT cloud configuration? When are multiple RT clouds recommended? When should hub-and-spoke RT cloud architecture be used? Which multi-cloud configurations should be avoided? Can RTserver versions 6.2, , and 6.6 be mixed in the same cloud? How should version 6.2-based hub-and-spoke clouds be migrated to ?.. 68 How can RTservers be configured to communicate through a firewall? PATROL Console Server How many users can a PATROL Console Server support? How many agents can a PATROL Console Server support? Which versions of the PATROL Agent should be used with the PATROL Console Server? How many RT clouds can be connected to a PATROL Console Server? What can be done to prevent the PATROL Console Server from becoming overloaded? How can a PATROL Console Server be backed up? How is a backup PATROL Console Server started? Are the locations of PATROL Central files and directories documented anywhere? What should I do if I see a message in the PATROL Console Server log file indicating duplicate RTservers? PATROL Central Operator Web Edition How many users can PATROL Central Operator Web Edition support? How large a profile can PATROL Central Operator Web Edition support? Why are console-side KM commands inactive on PATROL Central Operator Web Edition? Appendix A Frequently Asked Questions 55

56 PATROL Central Operator Microsoft Windows Edition How large a profile can PATROL Central Operator Microsoft Windows Edition support? What version of PATROL Central Operator Microsoft Windows Edition is recommended? PATROL Infrastructure Monitor Should I use the former PATROL Infrastructure Knowledge Module or PATROL 7 Knowledge Module to monitor my PATROL Central infrastructure? What versions of the PATROL Central infrastructure are supported by the PATROL Infrastructure Monitor? How can more than one RT cloud be monitored with the PATROL Infrastructure Monitor? Other Components & Questions Are there any OS dependencies for PATROL Central infrastructure? Is PATROL Central infrastructure supported on iseries? When should the Availability Checker be used in an enterprise implementation? Why can't all aspects of KM operation be managed with PCM? How are PCM rulesets used to best advantage? PATROL Central Infrastructure Best Practices Guide

57 RTserver and RT clouds RTserver and RT clouds This section lists common questions and issues related to the RTserver and creating and implementing RT clouds. How do clients connect to an RTserver? Each PATROL component must be configured to talk to one or more specific RTserver processes. This configuration is performed by assigning one or more logical RTserver connection names to a configuration variable for each PATROL component that connects to an RT cloud. For example, to connect PATROL Central Operator Microsoft Windows Edition to an RTserver process, use the Windows operating system to assign an RTserver process address (such as "tcp:houston103.bmc.com:3348") to the environment variable called RTSERVERS. NOTE With the release of PATROL Agent version , it is possible to configure RTserver connection information with a PCM rule. The object name is "/AgentSetup/rtServers" and its value is the configuration string (for example, value = tcp:bmchost:2059,tcp:bmchost2:2059). With the release of PATROL Central Operator Microsoft Windows Edition version it is possible to configure RTserver connection information through the GUI. For more information, see the PATROL Console Server and RTserver Getting Started guide. How many agents can connect to a single RTserver? The recommended limit for the number of agents that connect to a single RTserver is 700. Each RTserver can handle no more than 750 connections for all types of client applications. In this context, a client application includes not only the PATROL Agent, but also any PATROL application that connects to the RT cloud. Examples of other applications that connect to the cloud include the PATROL Console Server, each PATROL Central console user, the PATROL Infrastructure Monitor, the PATROL Reporting aggregator, and many of the command line utilities described in the PATROL Console Server and RTserver Getting Started guide. Appendix A Frequently Asked Questions 57

58 How many agents can connect to a single RT cloud? In cases where only PATROL Central consoles are using the cloud, the recommended limit of 700 agents provides for an additional 50 RT connections for other types of PATROL applications. In cases where PATROL Reporting or Common Connect are using the cloud as well, the recommended limit for the number of agents is 500 (550 total RT clients). The RTserver configuration option max_client_conns controls the maximum number of connections to the RTserver. The default value for RT is 500, but it may be increased to any value less than or equal to 750. How many agents can connect to a single RT cloud? The maximum number of agents in a single RT cloud is the same as the maximum number of agents on a single RTserver: 700. Starting with the release of the PATROL Console Server version and RTserver version , scalability for enterprises with more than 700 agents is best achieved by adding RTservers to form new RT clouds rather than by adding RTservers to an existing cloud. Generally speaking, use of the hub-and-spoke RT cloud architecture is deprecated in favor of separate RT clouds that each link to the PATROL Console Server; an example of a multi-cloud configuration is provided in the question What is the best RT cloud configuration? on page 59. There is still one scenario in which hub-and-spoke architecture is appropriate, however, and that exception is presented in the question When should hub-and-spoke RT cloud architecture be used? on page 62. In the simplest scenario, a single RT cloud has only two RTservers (a primary and a backup) and all clients are typically connected to just one of the RTservers (each of which has max_client_conns set to the same value). How many RT clouds can be connected to a single PATROL Console Server? There is no fixed limit on the number of RT clouds that can be connected to a PATROL Console Server. The largest configurations tested in the Performance, Scalability, Reliability and Integration (PSRI) lab, however, consist of 10 RT clouds and most PSRI test cases are executed with 2-6 RT clouds. Scenarios that require more than 10 RT clouds should be reviewed by BMC Software and the PATROL Line Of Business before a design is adopted, and in no case later than the initial stages of technical evaluation. 58 PATROL Central Infrastructure Best Practices Guide

59 How many RTservers can be connected in a single cloud? How many RTservers can be connected in a single cloud? No more than 12 RTservers should be combined in the same cloud. Starting with the release of RTserver version , however, the recommended strategy to extend RT scalability is to create additional clouds of just a few RTservers rather than to add RTservers to an existing cloud. Typically, two RTservers in a single cloud are sufficient for most environments. The exception to this recommendation is a special case in which a hub-and-spoke design may be required; this exception is presented in question When should hub-and-spoke RT cloud architecture be used? on page 62. What is the best RT cloud configuration? The best advice for RT cloud configuration is to keep it simple. In previous releases, BMC Software recommended an RT cloud architecture based on a hub-and-spoke model. This RT configuration is no longer generally recommended, however, since a pair of RTservers can handle the same amount of traffic as 3-4 version 6.2 RTservers in a hub-and-spoke configuration. An exception to the no-hub-and-spoke rule still exists when several small, remote offices are interconnected, however, and this exception is presented in question When should hub-and-spoke RT cloud architecture be used? on page 62. In some circumstances only one RT cloud is necessary. These circumstances are determined by a combination of available hardware capacity and the size of the monitored environment, and are discussed elsewhere in this guide. When a single cloud is not sufficient, multiple clouds should be defined and PATROL Agents and PATROL Central consoles should be connected to separate clouds. Depending on the number of agents present, more than one cloud of agents may be necessary. This type of configuration separates agent-to-console-server message traffic from console-to-console-server message traffic. When using a dedicated cloud for consoles, the RTservers for that cloud can be hosted on the same computers as the PATROL Console Server and PATROL Central Operator Web Edition. Figure 1 on page 60 shows a multi-cloud configuration with three clouds. Appendix A Frequently Asked Questions 59

60 What is the best RT cloud configuration? Figure 1 Example of a Multiple RT Cloud Configuration Some other notes on RT cloud configuration: Configuration of multiple clouds is fundamentally an exercise in configuring the PATROL Console Server. For more information on multi-cloud configuration in the PATROL Console Server, see the PATROL Console Server and RTserver Getting Started guide. Keep the setting for max_client_conns the same for all RTservers in the same cloud. This ensures that if a failover occurs, the backup RT will be able to accept as many connections as the primary. 60 PATROL Central Infrastructure Best Practices Guide

61 When are multiple RT clouds recommended? If an environment has a single cloud or a dedicated cloud for consoles, place the primary RT server on the same computer as the PATROL Console Server and the backup RTserver on the same computer as PATROL Central Operator Web Edition. An exception to this rule exists for cases where platform support for the RTserver differs from that of the PATROL Console Server or PATROL Central Operator Web Edition. In such cases, RTservers must be placed on separate computers from the PATROL Console Server or PATROL Central Operator Web Edition. In the case of a two-rtserver cloud, all RT clients connected to the cloud should have the same RT locator string to ensure that they use the same RTserver for primary and backup. For instance, in Figure 1 on page 60 the order of RTservers for the "Consoles" cloud is the same in PATROL Central Operator Microsoft Windows Edition, in PATROL Central Operator Web Edition, and in the Acfg_7_1_0_RTCloud_Connection configuration instance for the PATROL Console Server. When are multiple RT clouds recommended? A single RT cloud can handle up to 750 RT clients. Of those 750 RT clients, typically no more than 700 are PATROL Agents. An additional RT cloud can be created in cases where a single RT cloud is not sufficient to handle the total number of RT clients. Additional clouds are also warranted any time a remote location has more than 50 PATROL Agents. In such remote-office scenarios, it is more efficient for the PATROL Console Server to connect to an RTserver stationed in the remote office rather than for agents in the remote office to connection to an RTserver in a central location. If there are multiple remote locations with more than 50 agents apiece, each remote office should have its own RT cloud hosted on hardware residing in the remote office (one primary and one backup RTserver). If the number of dedicated clouds for remote offices grows too large, several remote offices can be linked into a single cloud based on the hub-and-spoke architecture. Hub-and-spoke architecture is presented in the question When should hub-and-spoke RT cloud architecture be used? on page 62. If remote offices exist with fewer than 50 agents, the agents in those offices can be connected to an RTserver in another location. Keep in mind that an enterprise's security policies may require remote offices to connect to an RTserver in the DMZ rather than to one inside the corporate firewall. In some corporations, network security policies prohibit network connections that are initiated from less secure zones into more secure zones. This means that a PATROL agent in the DMZ is prohibited by company policy from connecting to an RTserver inside the corporate firewall. In the past, BMC Software recommended that these scenarios be addressed by placing one or more RTservers in the DMZ and another Appendix A Frequently Asked Questions 61

62 When should hub-and-spoke RT cloud architecture be used? behind the corporate firewall, and by configuring the RTserver behind the firewall to connect to the RTserver(s) in the DMZ. Starting with PATROL Console Server version , an alternative configuration is preferred. Instead of using RTserver-to- RTserver connections across the firewall, RTservers in the DMZ can be configured as a standalone RT cloud and the PATROL Console Server inside the firewall can connect directly to the RT cloud in the DMZ. For added security, the PATROL Console Server configuration for each cloud includes an option that prevents the PATROL Console Server from advertising its presence. For more information on this option, see the PATROL Console Server and RTserver Getting Started guide. When should hub-and-spoke RT cloud architecture be used? Starting with the release of PATROL Console Server version , use of hub-andspoke configurations has been generally deprecated. An exception exists, however, when the number of remote offices requiring a local RTserver (offices with more than 50 agents) exceeds 10. Under these circumstances, several remote offices can be joined into one cloud using a hub-and-spoke configuration when the following conditions are met: The total number of agents in the hub-and-spoke cloud does not exceed 700. The total number of RTservers in the hub-and-spoke cloud does not exceed 12. Keep in mind that each remote office should have two RTservers. The hub RTserver should be positioned on the same side of the WAN connection as the PATROL Console Server. Figure 2 on page 63 shows a simple example of hub-and-spoke architecture. 62 PATROL Central Infrastructure Best Practices Guide

63 When should hub-and-spoke RT cloud architecture be used? Figure 2 Example of Multiple RT Clouds with Hub and Spoke Building on the example in Figure 2, the cloud named "Agents 2" has been modified to use a hub-and-spoke configuration. The hubs are RTservers E and F. The RTservers in each remote office serve as spokes. In this example, all of the RTservers in remote offices should be configured with their server_names option set to Appendix A Frequently Asked Questions 63

64 Which multi-cloud configurations should be avoided? tcp:e:2059,tcp:f:2059. Note that the total number of RTservers in the "Agents 2" cloud is 10 (below the limit of 12). If each remote office has 50 agents, the total number of agents in the central office (those connected to RTservers E and F) should not exceed 500 (700 max - (4 x 50)). Which multi-cloud configurations should be avoided? In particular, there are three scenarios unique to the new multi-cloud capability that represent configuration mistakes. These scenarios can create performance problems, produce unreachable agents, or cause agents to report incorrect connection status. In the first scenario, more than one agent with the same RT service ID exists in different clouds. When this happens, all agents with the same RT service ID are able to connect to their RT cloud but the PATROL Console Server only accepts the first agent it sees. The other agents are ignored by the PATROL Console Server, which writes the following warning message to the PATROL Console Server log file: "Duplicate service name found: /cos/svs/patrol_agent_serviceid" where serviceid is the RT service ID of the duplicate agent (for more information on RT service IDs, see the PATROL Console Server and RTserver Getting Started guide). This cannot occur in a single cloud because the RTserver prevents agents with duplicate IDs from connecting in the first place. In a multi-cloud configuration, the PATROL Console Server enforces service ID uniqueness by ignoring duplicates. The default RT service ID for each agent is based on the host name of the computer where the agent is running. In some cases, configuring the agent's host to specify the fully qualified domain name is sufficient to insure uniqueness. Alternatively, the agent can be configured to use a specified service ID (e.g. PatrolAgent id youruniqueidhere). In the second scenario, the PATROL Console Server has been configured for two or more separate RT clouds but in fact the RTservers are in the same physical cloud. There are many conceivable configurations that may result in this scenario; Figure 3 on page 65 illustrates one such configuration. In this example the link from RTserver D to RTserver E creates one physical cloud, where the PATROL Console Server configuration indicates that there should be two separate clouds. 64 PATROL Central Infrastructure Best Practices Guide

65 Which multi-cloud configurations should be avoided? Figure 3 Example of Cross-Linked RT Clouds PATROL Console Server records the following types of log messages when it encounters this second scenario: ERROR:1/25/ :09:22 AM:::RT Cloud 'Agents - 1' has duplicate rtservers with RT cloud 'Agents - 2' WARNING:1/25/ :09:22AM:COS_BASE_SUBS:::cos_framework.cpp(663):Cloud[Agents - 2] RTServer[0]: /_C_8401 WARNING:1/25/ :09:22 AM:COS_BASE_SUBS:::cos_framework.cpp(663):Cloud[Agents - 2] Appendix A Frequently Asked Questions 65

66 Which multi-cloud configurations should be avoided? RTServer[1]: /_D_8293 WARNING:1/25/ :09:22 AM:COS_BASE_SUBS:::cos_framework.cpp(663):Cloud[Agents - 2] RTServer[2]: /_E_8312 WARNING:1/25/ :09:22 AM:COS_BASE_SUBS:::cos_framework.cpp(663):Cloud[Agents - 2] RTServer[2]: /_F_8927 ERROR:1/25/2005 9:23:19 AM:::RT Cloud 'Agents - 1' has duplicate rtservers with RT cloud 'Agents - 2' forcing disconnect. INFORM:1/25/2005 9:23:19 AM::11.221:Disconnecting from 'Agents - 2' In general, these types of messages are an indication that there is a problem either with the RT to RT configurations or the definition of the RT clouds in the PATROL Console Server configuration. To correct these problems, list the RTservers identified in each of the PATROL Console Server configuration entries for the cloud names listed in the message. For each of those RTservers, locate the server_names option in their respective rtserver.cm files. Based on the server_names values, map out the RT to RT connections and compare that to the list of RTservers from the PATROL Console Server configuration entries. Depending on what you find, correct either the PATROL Console Server configuration file or the RT to RT configuration to eliminate the redundancy. In this particular example, the problem is in the RT to RT configuration for Rtserver D. NOTE Changes to PATROL Console Server configuration require a restart of the console sever, and changes to RTserver configuration require a restart of the RTserver. In the third scenario, a PATROL Agent's RTSERVERS setting specifies RTservers in different clouds. Failover from one cloud to another is not supported for any PATROL application, including PATROL Agents. The symptoms in this case will be similar to those exhibited in the first scenario: the PATROL Console Server will ignore the agent's failover connection if the agent's reconnect notification from the second cloud arrives before its disconnect notification from the first cloud. Figure 4 on page 67 illustrates one such configuration. In this example, each PATROL Agent has been configured to use a backup RTserver in a cloud that is different from its primary RTserver. 66 PATROL Central Infrastructure Best Practices Guide

67 Which multi-cloud configurations should be avoided? Figure 4 Example of RT Cloud-to-Cloud Failover An agent can be manually moved from one RT cloud to another using a procedure outlined in the PATROL Console Server Release Notes (September 30, 2004). Refer to the section on "Failover of PATROL Agents From One RTserver Cloud to Another". Appendix A Frequently Asked Questions 67

68 Can RTserver versions 6.2, , and 6.6 be mixed in the same cloud? Can RTserver versions 6.2, , and 6.6 be mixed in the same cloud? Version 6.2 and RTservers can be used in the same cloud to facilitate incremental upgrade of an existing 6.2 cloud. Likewise, version and RTservers can be used in the same cloud as well. However, a cloud of mixed RT versions should only be used on an interim basis and not as a long-term solution. Versions and of RTserver are comparable in terms of scalability and performance, but version 6.2 is significantly less scalable than either version or A mixed cloud of and 6.2 RTservers will only be as scalable as the 6.2 RTserver, and should not be pushed beyond the capacity of RTserver 6.2. Even though the capacity of version exceeds that of version 6.2, the cloud as a whole is limited by its lowest common denominator. How should version 6.2-based hub-and-spoke clouds be migrated to ? RTserver version has greater capacity than version 6.2, and a migration to version may provide an opportunity to eliminate one or more existing RTservers. Review the size of the existing 6.2 environment and the hardware recommendations presented in this guide to determine if this is possible. If it is not possible to eliminate any existing RTservers, apply the following principles when migrating from a hub-and-spoke architecture: If existing hardware can be re-used, install RTserver version on top of existing 6.2 RTservers. If the migration is being performed in an incremental fashion, upgrade PATROL Console Servers and RTservers before changing the RT cloud architecture. Create one cloud for consoles and one or more clouds for agents. Remove the hub RTservers that only connected to other RTservers in the previous architecture. The following three figures show before-and-after scenarios for a small hub-andspoke design with four RTservers (Figure 5 on page 69). In this example there are two possible configurations for the "after" case depending on the hardware available (Figure 6 on page 70 and Figure 7 on page 71). 68 PATROL Central Infrastructure Best Practices Guide

69 How should version 6.2-based hub-and-spoke clouds be migrated to ? Figure 5 Case 1 "Before" Small Hub-and-Spoke Cloud In the first case, as illustrated in Figure 6 on page 70, the hub-and spoke implementation in Figure 5 can be reduced to just two computers. Appendix A Frequently Asked Questions 69

70 How should version 6.2-based hub-and-spoke clouds be migrated to ? Figure 6 Case 1A "After" One Cloud In the second case, as illustrated in Figure 7 on page 71, the small hub-and-spoke cloud in Figure 5 on page 69 can be divided into two clouds of two RTservers each: one cloud for consoles and one cloud for agents. 70 PATROL Central Infrastructure Best Practices Guide

71 How should version 6.2-based hub-and-spoke clouds be migrated to ? Figure 7 Case 1B "After" Small Multi-Cloud Figure 8 on page 72 illustrates a larger hub-and-spoke design with six RTservers. Appendix A Frequently Asked Questions 71

72 How should version 6.2-based hub-and-spoke clouds be migrated to ? Figure 8 Case 2 "Before" Large Hub-and-Spoke Cloud In this example, the number of RTserver computers can be reduced by two because hubs E and F can be removed. The resultant multi-cloud configuration is equivalent to that illustrated in Figure 7 on page 71: one cloud for consoles composed of RTservers A (primary) and B (backup), and one cloud for agents composed of RTservers C (primary) and D (primary). As part of this migration, all agents must be reconfigured to use RTservers C and D. 72 PATROL Central Infrastructure Best Practices Guide

73 How can RTservers be configured to communicate through a firewall? How can RTservers be configured to communicate through a firewall? The RTserver requires no special configuration in order to run through a firewall. For security reasons, however, it is better to configure the RTserver and the firewall to use a non-well-known port. Best Practice Recommendation BP 29 When running the RTserver through a firewall, it is best to configure the RTserver and the firewall to use a non-well-known port. PATROL Console Server This section lists common questions and issues related to implementing the PATROL Console Server. How many users can a PATROL Console Server support? PATROL Console Server capacity is not determined solely by the number of concurrent users it supports, since every user may not have the same profile. Profiles that only reference 10 agents, for example, have much less impact on system performance than those that reference 500 agents. The workload borne by the PATROL Console Server is based on the total number of managed objects contained in all management profiles open at the same time. The total number of managed objects can be determined by summing the application classes, instances, and parameters loaded on each agent in each profile. If an accurate count of the number of objects required for every profile is not available, a rough rule of thumb can be used to help estimate this number. Although the correct value varies considerably with the mix of KMs and the number of application instances, for preliminary sizing an OS KM and an application KM running on the same agent can be assumed to instantiate approximately 1000 managed objects. There is no hard-coded limit on the number of concurrent consoles that can connect to the PATROL Console Server, but there are practical constraints based on the total number of managed objects. On 32-bit dual CPU hardware the largest configuration supported is approximately 3 million managed objects. On a 32-bit computer the limiting factor is the fixed size of the virtual memory address space, which ranges from 2 GB to 4 GB depending on the OS. On 64-bit quad-cpu hardware the largest Appendix A Frequently Asked Questions 73

74 How many agents can a PATROL Console Server support? configuration tested by BMC Software has 10 million managed objects. Testing includes configurations with 100 concurrent profiles of 100 agents each (100 objects per agent) and configurations with 50 concurrent profiles of 200 agents each (100 objects per agent). The hardware requirements for an environment with 10 million managed objects are significant. Designs that support more than 100 concurrent users or more than 10 million managed objects should be reviewed by BMC Software and the PATROL Line Of Business before a design is adopted, and in no case later than the initial stages of technical evaluation. How many agents can a PATROL Console Server support? PATROL Console Server capacity is not determined solely by the number of concurrent agents it supports, since every agent may not have the same configuration or workload. The largest environments tested by BMC Software include configurations with 2000 agents distributed across four RT clouds and configurations with 4000 agents distributed across 10 RT clouds. In both configurations the aggregate workload on the PATROL Console Server was no more than 10 million managed objects. With agents in the environment, the total number of agents in all concurrently open profiles did not exceed 10,000. Beyond these limits it may be necessary to partition an environment into separate domains, where a domain is comprised of one or more PATROL Console Servers, a PATROL Central cloud, and 8-10 RT clouds for agents. The hardware requirements for an environment of agents are significant. Environments that require more than 10 RT clouds, more than 4000 physical agents, or a total of more than 10,000 managed agents across all concurrently open profiles should be reviewed by BMC Software and the PATROL Line Of Business before a design is adopted, and in no case later than the initial stages of technical evaluation. Which versions of the PATROL Agent should be used with the PATROL Console Server? The PATROL Console Server will work with any PATROL Agent version or later. However, a minimum agent version of is required for environments of several hundred agents or more. This version corrects several problems related to RTserver connection and scalability. The agent contains additional improvements related to scalability, including optimizations that can expedite profile loading in large environments. 74 PATROL Central Infrastructure Best Practices Guide

75 How many RT clouds can be connected to a PATROL Console Server? How many RT clouds can be connected to a PATROL Console Server? See the question How many RT clouds can be connected to a single PATROL Console Server? on page 58. What can be done to prevent the PATROL Console Server from becoming overloaded? Starting with the release of version , the PATROL Console Server includes several mechanisms to limit its workload. Before each profile-open request, the PATROL Console Server estimates the impact of that profile on the current workload. If the addition of the profile will exceed predefined workload thresholds, the openrequest is denied and a warning message is displayed to the user. The PATROL Console Server will also reject profile-open requests if the workload limit is exceeded after several profiles have been opened (for example, a large number of agents were added to a profile or KMs discovered a large number of new instances). For more information on the configuration options for this feature, see the PATROL Console Server and RTserver Getting Started guide. How can a PATROL Console Server be backed up? With the release of version , the PATROL Console Server provides two method of backup: online and offline. The online backup allows you to save your PATROL Console Server configuration data and management profile information without shutting down the PATROL Console Server process. The offline backup capability works properly only if the PATROL Console Server process is not running. In either case, the data that is backed up cannot be copied to an active secondary PATROL Console Server; the secondary PATROL Console Server must be stopped before the backed up data can be copied into the secondary s runtime directory. For more information about the process of backing up the PATROL Console Server, see to the PATROL Console Server and RTserver Getting Started guide. Appendix A Frequently Asked Questions 75

76 How is a backup PATROL Console Server started? How is a backup PATROL Console Server started? The online backup can be configured to run automatically on a periodic schedule, or it can be initiated on-demand from a command line utility called admincli. The offline backup is always initiated from a command line utility called admin_copy. For more information about starting a backup PATROL Console Server, see the PATROL Console Server and RTserver Getting Started guide. Are the locations of PATROL Central files and directories documented anywhere? Yes, see the PATROL Console Server and RTserver Getting Started guide. What should I do if I see a message in the PATROL Console Server log file indicating duplicate RTservers? The following error message displayed in the PATROL Console Server log file indicates that the two RT clouds identified by the variables name X and name Y are interconnected in some way by their RTserver to RTserver configuration: RT Cloud name x has duplicate rtservers with RT cloud name y In other words, there is actually only one physical RT cloud; however, the PATROL Console Server configuration indicates that there are two (or more). This is a configuration mistake that should be corrected. For an example of this problem and information on how to correct it, see the question Which multi-cloud configurations should be avoided? on page 64. PATROL Central Operator Web Edition This section lists common questions and issues related to implementing PATROL Central Operator Web Edition. 76 PATROL Central Infrastructure Best Practices Guide

77 How many users can PATROL Central Operator Web Edition support? How many users can PATROL Central Operator Web Edition support? A single instance of PATROL Central Operator Web Edition can handle a total of managed agents across all concurrently open profiles, or concurrent users with 100 agents per user. How large a profile can PATROL Central Operator Web Edition support? PATROL Central Operator Web Edition can handle profiles containing up to 200 agents, but an average profile size of no more than 100 agents is recommended. Above 200 agents per profile, response times deteriorate to unsatisfactory levels. For environments in which profiles contain more than 200 agents, PATROL Central Operator Microsoft Windows Edition should be used. Why are console-side KM commands inactive on PATROL Central Operator Web Edition? PATROL Central Operator Web Edition does not support execution of local commands from the browser. PATROL Central Operator Microsoft Windows Edition This section lists common questions and issues related to implementing PATROL Central Operator Microsoft Windows Edition. Appendix A Frequently Asked Questions 77

78 How large a profile can PATROL Central Operator Microsoft Windows Edition support? How large a profile can PATROL Central Operator Microsoft Windows Edition support? There is no hard-coded limit in PATROL Central Operator Microsoft Windows Edition on the size of a profile. It is best to limit profiles to no more than 500 agents, but larger profiles are possible. The largest profiles tested by BMC Software contain up to 1200 agents. The elapsed time between an initial open-profile request and the point at which current status and connection information is displayed for every agent varies with profile size and depends on the hardware used to host the PATROL Console Server. A quad CPU 900 MHz Solaris computer fully loads profiles at a rate of approximately 100 agents per minute. A dual CPU 2.4 GHz Windows computer fully loads profiles at a rate of approximately 300 agents per minute. For profiles consisting of several hundred agents, operators can typically begin to work with some agents within one or two minutes. What version of PATROL Central Operator Microsoft Windows Edition is recommended? Version or later of PATROL Central Operator Microsoft Windows Edition is recommended for use with PATROL Console Server version PATROL Infrastructure Monitor This section lists common questions and issues related to implementing the PATROL Infrastructure Monitor. Should I use the former PATROL Infrastructure Knowledge Module or PATROL 7 Knowledge Module to monitor my PATROL Central infrastructure? No. The PATROL Infrastructure Monitor or later should be used to monitor PATROL Central 7.5 infrastructure. This version of the product is both multi-cloud aware and significantly more efficient than the previous products. 78 PATROL Central Infrastructure Best Practices Guide

79 What versions of the PATROL Central infrastructure are supported by the PATROL Infrastructure Monitor? What versions of the PATROL Central infrastructure are supported by the PATROL Infrastructure Monitor? The PATROL Infrastructure Monitor supports RTserver 6.2, , and The PATROL Infrastructure Monitor can be used on version or of the PATROL Agent. How can more than one RT cloud be monitored with the PATROL Infrastructure Monitor? The PATROL Infrastructure Monitor can monitor multiple clouds from a single agent. For more details on configuring the PATROL Infrastructure Monitor, see the PATROL Infrastructure Monitor online Help. The PATROL Infrastructure Monitor can be placed anywhere in the enterprise where connectivity to all clouds is available, but the following best-practice recommendations should be considered: Place the PATROL Infrastructure Monitor on the same computer as the PATROL Console Server. If redundancy is an important consideration, a second instance of the PATROL Infrastructure Monitor can be installed on another computer, for example, on the computer where the secondary PATROL Console Server is installed. Appendix A Frequently Asked Questions 79

80 Other Components & Questions Other Components & Questions This section lists common questions and issues related to other components you may implement in your PATROL environment such as PATROL Configuration Manager. Are there any OS dependencies for PATROL Central infrastructure? OS dependencies vary from product to product and release to release. Review the release notes and system requirements for all PATROL infrastructure components to ensure that the implementation plan considers product-specific OS limitations and accounts for any required OS patches or reconfiguration. Is PATROL Central infrastructure supported on iseries? At this time there is no PATROL Agent for the IBM iseries platform that supports PATROL Central infrastructure. PATROL Agent version is targeted to support IBM iseries systems but at security levels 0 and 1 only; higher security levels will not be supported. Refer to the latest product roadmaps for current status and planned availability of PATROL Central infrastructure on IBM iseries. When should the Availability Checker be used in an enterprise implementation? The Availability Checker was not designed for enterprise-wide deployment and does not scale well to large numbers of managed nodes. It should only be used in single server implementations to help troubleshoot problems. For more information on sizing guidelines, see Single Server Environments on page PATROL Central Infrastructure Best Practices Guide

81 Why can't all aspects of KM operation be managed with PCM? Why can't all aspects of KM operation be managed with PCM? Some KMs implement configuration and management features that are not compatible with PCM. Although all BMC Software KMs are expected to be fully PCM compatible in the future, features that may not be PCM configurable in every KM today include Adjusting thresholds and poll times Activating and deactivating objects Managing events How are PCM rulesets used to best advantage? Try to apply the following guidelines when planning and using PATROL Configuration Manager: Create initial rulesets at the application class level Rules may apply to all instances of a class Rules may apply to individual instances Make localized versions of rules and rulesets for agents that require unique variations Rules may apply to all instances of a class Rules may apply to individual instances Build hierarchies of rulesets to avoid unnecessary duplication Don't be afraid to duplicate specific rules into different rulesets when it improves ease of use Use an effective naming convention for rulesets. This will add consistency to the way the tool is used by different users. Once an Agent has been configured and tested, use "Get Configuration" to save its configuration in the History ruleset folder. This consolidated ruleset will then be available to apply to other systems. Pick out parts of the ruleset to build other custom rulesets Use the AS_CHANGESPRING.km to create rulesets that use existing KM threshold values. Appendix A Frequently Asked Questions 81

82 How are PCM rulesets used to best advantage? Use AS_CHANGESPRING.km and the PATROL Development console to quickly and easily turn your config.default into a Standard "Agent Setup" ruleset. Use Changespring KM Commands primarily to migrate old configuration information to PCM rulesets Agent backups stored by system name and date/time Rulesets and backups may be compared (changes and/or errors) Purge deletes all current configuration information and does a complete "apply new" to the agent 82 PATROL Central Infrastructure Best Practices Guide

83 Appendix B Infrastructure Planning Forms B This appendix presents the following worksheets: Stakeholder Roster Worksheet Location Analysis Worksheet Appendix B Infrastructure Planning Forms 83

84 Stakeholder Roster Worksheet Stakeholder Roster Worksheet Stakeholder Roster Name Contact Phone/ Role/Interest Deployment/Installation Configuration/Change Management PATROL Support Operations/Event Management At a minimum, the following stakeholders must be identified: PATROL Deployment/Installation initial setup of PATROL infrastructure PATROL Configuration/Change Management configure KMs, define event filtering/forwarding, notification rules PATROL Support maintain PATROL infrastructure, perform maintenance & upgrades PATROL Operations/Event Management daily users of PATROL 84 PATROL Central Infrastructure Best Practices Guide

85 Location Analysis Worksheet Location Analysis Worksheet PATROL Location Analysis Worksheet Location Name: Is this location isolated by a network firewall? Speed and reliability of LAN/WAN connectivity to this location: Managed Node Information Number of managed nodes at this location: Knowledge Modules to be used at this location: Additional Infrastructure Services Will PATROL Reporting aggregate data from managed nodes at this location? Will PATROL Agents at this location forward events to an event management tool? If so, indicate which event management tool: Visualization Information Typical number of Knowledge Modules used on each managed node: Typical number of managed objects on each managed node: Number of PATROL Central Operator Microsoft Windows Edition consoles: Number of PATROL Central Operator Web Edition users (daily / infrequently): Number of concurrent PATROL Central Operator console sessions: Typical number of managed nodes in each management profile: Will management profiles include nodes at other locations? If so, indicate which other locations: Typical number of managed objects in each management profile: Estimated total number of concurrent managed objects: Appendix B Infrastructure Planning Forms 85

86 Location Analysis Worksheet 86 PATROL Central Infrastructure Best Practices Guide

87 Appendix C Sample Solution Planning Forms & C Diagrams This appendix includes forms and diagrams documenting the analysis and logical design steps for a hypothetical PATROL Central implementation at MainCore, Inc. This appendix presents the following topics: Sample Scenario Example Stakeholder Roster Example Location Analysis Worksheet for Houston Example Location Analysis Worksheet for Austin Example Location Analysis Worksheet for New York Example Diagrams Appendix C Sample Solution Planning Forms & Diagrams 87

88 Sample Scenario Sample Scenario MainCore has offices in Houston, Austin, and New York City. Their primary operations center is in Houston, with a secondary center in New York. Their main interest in PATROL is to monitor the operating system and Oracle databases on their servers. They will also use PATROL for Microsoft Exchange Servers to monitor two mail servers in Houston and two others in New York. The sample Stakeholder Roster includes contacts in the Systems Administration, Oracle DBA, and Accounting groups. Participation by the system administrators and DBAs will be needed for the actual implementation, and the Accounting group is interested because the Oracle databases being monitored support financial operations. The analysis of this environment resulted in the following conclusions that were used to complete the logical design: The network links between offices have sufficient bandwidth and reliability to permit those offices to share infrastructure components. The managed node count in both Houston and Austin are sufficiently small to permit one RTserver in each location to service both (a secondary is provided in each RT cloud for failover). An instance of the PATROL Infrastructure KM will be installed in both RT clouds and each configured to monitor the other. The New York office does not need any infrastructure components installed locally. The managed object counts were estimated using guidelines for OS and Oracle KMs. PATROL for Microsoft Exchange Servers was not used because there are only four instances of it in the enterprise (it is not used on a "typical" node). The estimated total concurrent managed object count is 1,440,000, which is within the capacity of a single PATROL Console Server. The estimated number of concurrent console sessions is 10, which is within the capacity of a single PATROL Console Server. The estimated number of concurrent PATROL Central Operator Web Edition sessions is 4, which is within the capacity of a single instance of PATROL Central Operator Web Edition. The Distribution Server and PATROL Configuration Manager will be located in Houston. 88 PATROL Central Infrastructure Best Practices Guide

89 Example Stakeholder Roster Example Stakeholder Roster Stakeholder Roster Name Contact Phone/ Role/Interest John Smith John Smith Janet Green John Smith Bill Landry Judy Jones Mary Ward Sam Leonard Deployment/Installation Configuration/Change Management PATROL Support Operations/Event Management System Administration Manager Operations/Event Management Director of IT Accounting Manager At a minimum, the following stakeholders must be identified: PATROL Deployment/Installation initial setup of PATROL infrastructure PATROL Configuration/Change Management configure KMs, define event filtering/forwarding, notification rules PATROL Support maintain PATROL infrastructure, perform maintenance & upgrades PATROL Operations/Event Management daily users of PATROL Appendix C Sample Solution Planning Forms & Diagrams 89

90 Example Location Analysis Worksheet for Houston Example Location Analysis Worksheet for Houston PATROL Location Analysis Worksheet Location Name: MainCore, Inc., Houston Is this location isolated by a network firewall? Yes Speed and reliability of LAN/WAN connectivity to this location: T1, reliable Managed Node Information Number of managed nodes at this location: 500 Knowledge Modules to be used at this location: 1.KM for Unix 2.KM for Windows 3.KM for Oracle 4.KM for Event Management 5.KM for MS Exchange (2 servers) Additional Infrastructure Services Will PATROL Reporting aggregate data from managed nodes at this location? Yes Will PATROL Agents at this location forward events to an event management tool? Yes If so, indicate which event management tool: PATROL Enterprise Manager Visualization Information Typical number of Knowledge Modules used on each managed node: 3 (OS, Oracle, KM for EM) Typical number of managed objects on each managed node: 1800 (2 * 900) Number of PATROL Central Operator Microsoft Windows Edition consoles: 3 Number of PATROL Central Operator Web Edition users (daily / infrequently): 0 Number of concurrent PATROL Central Operator console sessions: 3 Typical number of managed nodes in each management profile: 80 Will management profiles include nodes at other locations? Yes If so, indicate which other locations: Austin, New York Typical number of managed objects in each management profile: 144,000 (1800 * 80) Estimated total number of concurrent managed objects: 432,000 (144,000 * 3) 90 PATROL Central Infrastructure Best Practices Guide

91 Example Location Analysis Worksheet for Austin Example Location Analysis Worksheet for Austin PATROL Location Analysis Worksheet Location Name: MainCore, Inc., Austin Is this location isolated by a network firewall? Yes Speed and reliability of LAN/WAN connectivity to this location: T1, reliable Managed Node Information Number of managed nodes at this location: 400 Knowledge Modules to be used at this location: 1.KM for Unix 2.KM for Windows 3.KM for Oracle 4.KM for Event Management Additional Infrastructure Services Will PATROL Reporting aggregate data from managed nodes at this location? Yes Will PATROL Agents at this location forward events to an event management tool? Yes If so, indicate which event management tool: PATROL Enterprise Manager Visualization Information Typical number of Knowledge Modules used on each managed node: 3 (OS, Oracle, KM for EM) Typical number of managed objects on each managed node: 1800 (2 * 900) Number of PATROL Central Operator Microsoft Windows Edition consoles: 0 Number of PATROL Central Operator Web Edition users (daily / infrequently): 0 / 2 Number of concurrent PATROL Central Operator console sessions: 2 Typical number of managed nodes in each management profile: 80 Will management profiles include nodes at other locations? Yes If so, indicate which other locations: Houston, New York Typical number of managed objects in each management profile: 144,000 (1800 * 80) Estimated total number of concurrent managed objects: 288,000 (144,000 * 2) Appendix C Sample Solution Planning Forms & Diagrams 91

92 Example Location Analysis Worksheet for New York Example Location Analysis Worksheet for New York PATROL Location Analysis Worksheet Location Name: MainCore, Inc., New York Is this location isolated by a network firewall? Yes Speed and reliability of LAN/WAN connectivity to this location: T1, reliable Managed Node Information Number of managed nodes at this location: 40 Knowledge Modules to be used at this location: 1.KM for Unix 2.KM for Windows 3.KM for Oracle 4.KM for Event Management 5.KM for MS Exchange (2 servers) Additional Infrastructure Services Will PATROL Reporting aggregate data from managed nodes at this location? Yes Will PATROL Agents at this location forward events to an event management tool? Yes If so, indicate which event management tool: PATROL Event Manager Visualization Information Typical number of Knowledge Modules used on each managed node: 3 (OS, Oracle, KM for EM) Typical number of managed objects on each managed node: 1800 (2 * 900) Number of PATROL Central Operator Microsoft Windows Edition consoles: 3 Number of PATROL Central Operator Web Edition users (daily / infrequently): 2/ 0 Number of concurrent PATROL Central Operator console sessions: 5 Typical number of managed nodes in each management profile: 80 Will management profiles include nodes at other locations? Yes If so, indicate which other locations: Houston, Austin Typical number of managed objects in each management profile: 144,000 (1800 * 80) Estimated total number of concurrent managed objects: 720,000 (144,000 * 5) 92 PATROL Central Infrastructure Best Practices Guide

93 Example Diagrams Example Diagrams Figure 9 MainCore, Inc. Enterprise Appendix C Sample Solution Planning Forms & Diagrams 93

94 Example Diagrams Figure 10 MainCore, Inc. Houston Location 94 PATROL Central Infrastructure Best Practices Guide

95 Example Diagrams Figure 11 MainCore Inc. Austin Location Appendix C Sample Solution Planning Forms & Diagrams 95

96 Example Diagrams Figure 12 MainCore, Inc. New York Location 96 PATROL Central Infrastructure Best Practices Guide